Gabe
2.05.2009
6:05 PM

have you tried svnBridge? If you were really daring (and really sick of poor source control), you could even try adding git to the toolchain http://ayende.com/Blog/archive/2008/06/26/Git-to-CodePlex.aspx.

Haven't done it myself, but if I had to use TFS I'd be tempted :-)

Kevin Berridge
2.05.2009
6:32 PM

On this: "Now I'm greeted with a host of conflicts. I have never made code changes to my target branch. I have only merged to it. There should never be an incompatible change!"

I'm assuming no one else made any changes between the time you did a get and the time you merged and then checked in right? I've noticed this with TFS too. Why is it telling me there are conflicts because I added a method to a file, and I'm the only person who added anything to that file?! Shouldn't it be able to figure that out?

And the whole dialog verbage thing is a huge point of confusion. It's like Microsoft didn't think anyone would actually try to use branching and merging...

Alan Stevens
2.05.2009
7:52 PM

I feel your pain, Ben. For comparison, remember that I am still forced to use Source Safe over a WAN link. No matter how bad it is, it can always be worse.

Let's grab some TFS folk at the summit and see what they have to say about this behavior.

++Alan

Keith Bloom
2.06.2009
4:28 AM

I think integrated source control with VS is a real pain, leading to the stupidity that you have to manually check out a file to edit it out side of VS.

That said I've been using nothing but VS for years now and it may be better elsewhere.

As for branching and merging, it send shivers down my spine the thought of doing this in TFS.

J.P. Hamilton
2.06.2009
7:47 AM

TFS seems like just another example of MS arrogance to me. Did they even look at what was being done in the world before they wrote TFS? It is like they had so much confidence in themselves that they couldn't be bothered to do any research.

Eric Matz
2.06.2009
8:00 AM

This won't solve your branch/merge pain, but go get the latest TFS Power Tool which has integration with the Windows Shell:

msdn.microsoft.com/.../bb980963.aspx

mknopf
2.06.2009
8:55 AM

Ben, I feel your pain. Our (small) consulting firm was on TFS 2005 for 2 years and had all the issues you described here. I clearly remember so many check-ins that had "fighting with source control" as the comment.

We eventually gave up on TFS and migrated to SubVersion which we have been very happy with. I now work for NASA at Kennedy Space Center building software for base operations, we are using Visual Source Safe and I have to tell you that its WAY BETTER then TFS (even though both suck compared to SVN).

pfries
2.06.2009
11:10 AM

TFS doth sucketh, verily. For small-medium sized teams, I have had great experience with SourceGear's Vault. I haven't used their latest ALM tools but, if you're looking for a commercial product and haven't been shackled with TFS, I would recommend it. No, I'm not a shill for SourceGear, just like the product. I want to say MS should have bought them instead of building TFS, but I know they would have bloated it up beyond recognition.

WillieT
2.06.2009
11:58 AM

I was gonna say, could be worse, I'm stuck with VSS too. I'm new to the team and have brought it up. Forget merging, I can't even get a "sandbox" going correctly. Having worked with SVN before (I was the lead before) I sorely miss it, but not sure what exactly I can do about it. For instance, FF is banned here, it's only IE6 for us dev's!

Glad I read your post though, I was going to push for TFS as I was assuming it was better than VSS, but in retrospect maybe I'm better off now. Sigh...

Scott White
2.06.2009
1:01 PM

I have to use TFS at work and my biggest complaints are how you track defects and everything. Everything feels so canned and crappy. The web interface to TFS is even worse.

I'd much rather use SVN along with Trac or Jira.

James Humphry
2.06.2009
1:26 PM

Cry me a river.... Let's all go back to CVS!

Sumith Damodaran
2.06.2009
2:05 PM

Have you ever tried Dubbelbock, a great free tool for TFS explorer integration. works same as tourtoise SVN.

www.benday.com/.../displaywebpage.

Kedar Sirvahna
2.06.2009
9:07 PM

Mr. Ben,

It seems to me that you do not fully understand the power of Team Foundation Server. Compared to its competitors it is light years away. I agree its a1st / 2nd release product with hiccups but all in all it is a very productive product. Do you have any suggestions on superior products? Would you mind blogging about their pluses and minuses? Much appreciated...

--

Kedar

mknopf
2.07.2009
11:15 AM

Ben (response to #19)

After working with TFS for 2 years and then migrating to SVN (not to even mention my horrible experience with CVS) I have found that SVN is by far the better choice, especially when you consider its price (COMPLETELY FREE!!!!!) and the tools used to interact with it (AnkhSVN and TortuseSVN) are also COMPLETELY FREE (I didn't see the value in the VisualSVN plugin so i didn't buy it, but man I LOVE VisualSVN Server!!!)

Right now here at Kennedy Space Center we are on the NASA network and therefore our computers (all of them including DEV and source control servers) are owned by Lockheed Martin (they have the contract to manage them) and are under a Federal Mandate. That mandate prevents our developers from having IIS or any kind of web server, any kind of Database server, as well as ADMIN rights on our own machines (this is a Federal Law since we work for the government).

This introduces some very interesting constraints when it comes to developing software hence the VSS requirement. However I am hoping we will be able to build our own internal network that is not on the NASA pipe and therefore eliminates all the issue is described above, once that happens we will use SubVersion for sure. But in the meantime its "welcome to working under the Federal Governments guidelines"

Erik Lane
2.07.2009
2:00 PM

I'm so glad to see posts, as well as comments, like this and makes me even more thankful that we opted for SVN over TFS.

Robz
2.09.2009
12:12 PM

Ben, I feel your pain. Oh wait, I mean I FELT your pain. :D

"Dear MS: I trusted you for source control w/TFS2005. I trusted you for 3 years! Today you failed me and that trust can never be repaired. "

twitter.com/.../1119180977

"Good morning SVN. Good bye TFS."

twitter.com/.../1152090261

Jason Barile
2.10.2009
12:44 PM

As far as locking files, this is the big difference between SVN's model and TFS's model, where the server knows about the state of files and what exists and what doesn't. You can always check out the file for editing first, then open it with any editor you like. If you edit it from within VS, it's going to use the editor for that file type specified under tools/options. If you open it from Windows Explorer or the cmd prompt, of course you can open it with whatever you like. The key is that before you edit it, you should check it out for editing, which unlocks the file.

When you tried merging the new file from the branch back up to the integration branch, had you added it to source control yet & checked it into the child branch? If not, then it would still be in the "pending add" state and the merge operation wouldn't include it. Just trying to understand your scenario better here.

Is your integration branch the parent or child of your working branch? I'm assuming it's the parent here. I agree it's frustrating that trying to merge just the new file from the working branch to the integration branch shows no branch targets. TFS 2008 SP1 has the same behavior. It's because the file itself was never branched (since you created it in the child branch). If, however, you select the parent folder of the file (which WAS branched), TFS merge will correctly detect the new file and merge it back up to the parent branch. But I completely understand why you'd want this to work the way you assumed it would. As a user, I don't think you should need to understand the subtle details of why it doesn't detect a branch target... it should just work.

Where you're branching a file, what would you prefer to see happen there? I think what you'd rather have happen is what I described above. If you branch that file from the working branch into the integration branch, then what you end up with is a single file in your integration branch that is essentially a branch "grandchild" of the integration branch. Typically what I'd do here is to merge from a folder at the highest point in your child branch that includes all the changes you want to merge back into the integration branch. Comments aren't doing this justice... it's be easy to explain with a picture.

re: Merge language changing based on picking a single or multiple files - good call... that's annoying. This experience has been updated in TFS 2010, but TFS 2008 SP1 is still essentially the same as what you show here.

Matt Mitrik
2.10.2009
5:11 PM

I'm not exactly sure how you're performing the merge between the dev branch and the integration branch, but if you merged at the branch roots, and the range of changesets you were merging contained the files added on the branch, they should be merged to the integration branch. I've heard of other people running into problems here if their workspace wasn't up to date, or they specified a list of changesets or a range that didn't include the adds.

A few tips for keeping the number of conflicts down in the future:

1. Avoid baseless merge. I think you tried to avoid doing this until you got stuck with the merge not bringing changes over. Performing baseless merges will always conflict because there is no base for the server to use as a reference point.

2. Forward integrate / rebase before merging to a parent. This doens't truly eliminate conflicts, it just forces them to surface on the branch with changes (in this case, your dev branch). That way, you can try out resolving them, perform a local build on the dev branch, and when that is successful, check-in on the dev branch. After that, you should be able to merge to the parent branch (here, integration) and not have to deal with conflicts or wonder if your build will be broken.

Regarding merging multiple files - you're right, this could definitely be improved. I'll put an item on our backlog to track it for a future release.

James Humphry
2.11.2009
10:03 PM

From reading Jason and Matt's posts it seems like you've been spending too much time blogging and not enough time learning the tool your employer has asked you to use. I guess that is directly related to your professionalism as a software developer.

Eric Popelka
2.12.2009
2:46 PM

@James

troll detected

Simon
2.16.2009
5:20 AM

the solution to all your TFS woes is SVNBridge

OmarV
2.20.2009
6:02 PM

Ben,

I was going through your post and thinking what I was going to comment. Then I got to the comments and Eric, Jason and Matt already said what I wanted to say.

I have seen people have the same frustrations you've had and believe me, you are just a few minutes of training away from not being as frustrated. As James said, being in consulting you will probably end up at another engagement where your client will ask you to use TFS and I think I can help you ease that pain... but you'll have to show me some of basic SubVersion stuff in exchange ;-). I have heard a lot about SVN and never had an opportunity to work with it. If you are going to the summit we could get together at lunch, we really don't need that much time. think I have an old TFS2005 VPC I can bring with me. And if I don't have it anymore, TFS2008 is not much different in regards to the issues you had, we could use a 20008 VPC.

OmarV
2.22.2009
12:29 PM

Yeah, I know. I just have not had the opportunity to work with it. Some of my coworkers at Notion have but not me. I would have already read a lot about it otherwise and would have it installed, etc. if I had to know it before going to a client's site that uses SVN. You know how consulting is, you work full time at your client's site and you do reasearch and studying before and after work to maintain the level of service. See you at the summit!

Fangspeen
3.19.2009
4:16 AM

I would love to hear about the out come of this discussion you plan on having.

Please keep us up to date.

Having used SVN, and then been made to use VSS. I eventualy got my coworkers convinced to atleast move over to TFS2005. I would have to dis aggree with any one claiming that VSS is less painfull.

We Recently migrated to TFS2008 SP1 which resolved some of my more serious gripes with TFS, how ever many of your issues have plagued me also, especially since I have to help my coworkers resolve these issues when they arise. Most frequently this leads to them circumventing source control by:

* Checking out every file in a project and replacing it with some obscure version they "backed-up" to their local file system at some point and then checking the whole project back in again!

* Checking out individual files and manually copy and pasting changes from another branch before checking back in!

* Applying changes manually to each branch instead of even attempting a merge!

I tell you some days I just want to curl up in a corner and cry.

OmarV
3.26.2009
11:20 AM

I was not able to get with Ben at the MVP Summit but I emailed him afterwards and we are planning on doing this over LiveMeeting. Hopefully we can do it next week... Ben?

drventure
3.30.2009
2:41 PM

Good stuff. I made all the same comments about TFS when I evaluated it, only to be told halfway through my (not flattering) presentation that TFS had already been decided on.

Sigh.

And SVN is freakin' FREE. But it's open source, and everyone +knows+ how scary that stuff is....

Josette Rigsby
4.06.2009
1:41 PM

I didn't read all of the comments, but I hate IDE integration. I'm definitely a SVN (or even Perforce) fan. I use TFS @ my new company. However, I use the power toys file system integration. It's not quite double click, but it's better than opening VS.

jwc
4.15.2009
5:13 PM

I'm gonna 2nd the motion for SourceGear Vault. Much more sophisticated than TFS. But you still have to have a tool to check files out I think.

Anyway, yes TFS is a real pain in the neck. MS seems to have missed a step called "see what the state of the art is" when they set out to build it.

rob
5.15.2009
5:43 PM

As someone previously mentioned... a few minutes understanding what is going on (and how to use the tool) would eliminate these confusing/frustrations.

We can all go back and forth about particular messages and wording that needs edited, and that's fine. But the core of what you are complaining about is realy a non-issue regarding TFS. TFS is not VSS. It is not a simple little tool to help you with check-ins. It's a complicated beast that needs to be well understood. If that breaks your model, then it isn't for you. If you need to use it in a prefessional manner, then it's more than capable of delivering what you expect.

The system is amazingly extendable. I realize not everyone wants (or has the chance) to take time to understand how to extend it. But there are plenty of free/open source solutions to solve many of the common "complaints".

The assumptions you have made about TFS's "failures" are no more than misunderstandings by the user. There are legit reasons you are expiriencing the situations that you see. If you don't have the time to understand that, and another off the shelf tools matches your world better then go for it. All that means is that someone with a different view would write a differnt post about a different WTFery. And the rest of us who need to get some serious development done (and need an enterprise level source system that plays very nicely with it's ticketing/tracking/notifications/etc and happens to be a plug-in to our IDE) will continue enjoying TFS and the great features that it has provided to our team.