>> 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: [email protected] [mailto:[email protected]] 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 <[email protected]> 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."
