Hi, I would just like to say I disagree with this assessment of merging in TFS.
In TFS, you would also merge the 19 changes from Trunk into the Feature branch first, resolve conflicts & checkin, then merge Feature branch back into Trunk. This generally works well. Cherry-picking merges is a different story, but can also be straightforward. It is true that a merge results in a new single 'mushed' changeset in the target, but this doesn't mean you lose the context of the original checkins - In VS 2010, the History view shows the originating changesets as a tree (even after the source branch has been deleted), and the Branch Visualisation tool can help you track a changeset across multiple branches. That isn't to say TFS is without its problems. The trouble we have with TFS merges tends to be with deletes, renames, changes you DON'T want to merge, partial merges (for changesets that span multiple branch-points), forgetting to Get Latest of a target branch before merging, rollbacks, cherry-picking non-sequential changesets, and occasionally poor auto-merging. Thankfully, some of this has substantially improved in TFS 2010 since they changed to 'slot' mode when dealing with deletes, renames, and undeletes, as well as a proper rollback command. But these problems only occur occasionally and we manage to deal with them. I have not used other source control systems (other than VSS - does that count? ;) so maybe I am missing something in the comparison, but as someone who comes from a background of merging code _manually_ for many years, I think TFS merging is generally fine I don't think it is broken. Branch Visualization: http://www.edsquared.com/2010/03/17/Branching+And+Track+Changes+Visualization+In+TFS+2010+Is+Awesome.aspx 'Slot' mode: http://blogs.msdn.com/b/mitrik/archive/2009/05/28/changing-to-slot-mode-in-tfs-2010-version-control.aspx -----Original Message----- From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Paul Stovell Sent: Thursday, 4 November 2010 6:11 PM To: ozDotNet Subject: RE: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it? >> Broken how? Let's say you decide to implement a new feature in a TFS branch. You branch the trunk to FeatureX. Over the course of a week, you make 13 check-ins to that branch. During this time, the rest of your team made another 19 changes to the trunk. The feature is now stable, so you decide to merge. In TFS, this is done by doing a giant compare on the two directories, AND'ing them together, and seeing what falls out. You aren't just merging a check-ins - you're merging the state of two file system directories after 32 different check ins in a single attempt - you better get it right, because if you get 90% of the way in and screw it up, it will take a long time to recover. When you're done merging, you're left with a huge pending check in that touches every file involved in those 13 commits. You have to come up with a nice paragraph that sums up the 13 changes you're mushing in, because when you delete the branch, you'll probably lose the history of those branched changes. You should also remember to associate it with all of the work items/bugs/stories those 13 check ins touched, since this huge check in is really associated with all of them. In Mercurial it works different. You'd pull the 19 changes made to the trunk to your local repository - they'd be replayed, one-by-one, against your files. You'll still do the merges (leaving alone that Mercurial does a much better job of merging than TFS out of the box), but since you're dealing with one or two commits at a time, the merges are pretty simple, and if you screw up, you don't have to start the whole thing again. Once you've merged the trunk into your branch, you'd just push everything back to trunk. Now all the changes are replayed against trunk, and trunk has all 32 commits, with their history and dates exactly as you wrote them when you checked them in during the week. It's a much more elegant model. Paul -----Original Message----- From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of silky Sent: Thursday, 4 November 2010 4:51 PM To: ozDotNet Subject: Re: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it? On Thu, Nov 4, 2010 at 5:40 PM, Paul Stovell <paul.stov...@readify.net> wrote: > Hi Silky, > > I think in some ways you have to experience it - the proof is in the > tasting. But here are some things I like about it that work even for > small, local teams. > > 1. How many times did you make a small change, then delete it > and try something else, only to realize that you didn't check in > during that time since it wasn't "ready" to share with the team? Since > most of your interaction with source control is just to your hard > disk, you're more likely to use it. On my current project with > Mercurial I'm averaging a commit every 10 minutes - lots of small changes. Never. I don't ever try the wrong thing. Seriously though, as I said to Joseph, I agree this is a legitimate benefit, and I like it. > 2. How many times have you done an SVN update/TFS "get latest", > tried to merge, made a mistake, and lost changes in the process? With > Mercurial that doesn't happen -it forces you to commit your local > changes first, then merge them with the server changes. If it fails, > you can roll it back and try again until you're successful - you never lose > changes. This I've legitimately never done. Merging with SVN is pretty nice, at least I think so. You just go around resolving conflicts. Not so tough. Don't disagree that it could be better, but I don't think there is an issue here particularly. > 3. Merging in DVC's works fantastically. By comparison the > merging approaches of TFS and Subversion are broken. To even use a > DVCS you're using branching and merging, since the server and your > local machine are entirely different repositories. In TFS and SVN, > branching and merging is a scary concept only used in the most dire of > circumstances. Broken how? > Those advantages apply in the most connected corporate environment - > when I'm forced to use TFS I wish it had better support for these three > features. > Prior to using Mercurial I just accepted that the way SVN made me work > was fine, and the occasional loss of code or busted merge was a fact of life. > Now I find it frustrating to work with TFS/Subversion and sometimes > wonder if a folder full of "copy of .".zip files would be more > effective J > > There are other advantages to do specifically with open source > projects - for instance, instead of sending a patch, people can put > their repository online to share with others, and you can cherry pick > the changes you want from them. The patching system really fails once a patch > gets a little old. Right, I'm not interested in these, and neither are the majority of small enterprises, I would venture. I don't deny it's a benefit, and it's a good one, but not one that I care about. Anyway, I do appreciate these comments, and I may actually take a look, having been slightly convinced. > Paul -- silky http://dnoondt.wordpress.com/ "Every morning when I wake up, I experience an exquisite joy - the joy of being this signature." ********************************************************************************************** Important Note This email (including any attachments) contains information which is confidential and may be subject to legal privilege. If you are not the intended recipient you must not use, distribute or copy this email. If you have received this email in error please notify the sender immediately and delete this email. Any views expressed in this email are not necessarily the views of IRESS Market Technology Limited. It is the duty of the recipient to virus scan and otherwise test the information provided before loading onto any computer system. IRESS Market Technology Limited does not warrant that the information is free of a virus or any other defect or error. **********************************************************************************************
