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. 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. 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. 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 :) 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. Paul -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of silky Sent: Thursday, 4 November 2010 8:29 AM To: ozDotNet Subject: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it? On Thu, Nov 4, 2010 at 6:26 AM, Joseph Cooney <[email protected]<mailto:[email protected]>> wrote: > I've used TFS on and off since about 2006 (mostly because I was > working at MS, as they are fond of TFS), but haven't used TFS 2010. > It's biggest strength IMO is integration - requirements, work items, > bugs, builds, source code and project documentation all from within > Visual Studio. It's biggest weakness is that it's not a distributed > version control system (git, mercurial). Without sounding too argumentative; exactly why should I care that version control is "distributed"? The stated arguments seem to be that you don't need to be online to do commits, or that there is a local history, or some other such things. I really just don't ever find the need for anything like that; am I doing something significantly different to everyone else? I mean, I've glanced over this: http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ and it seems none of the benefits are really appropriate in a 'typical' environment. I guess what I'm asking is - is anyone, working in an office or alone, getting specific benefits from git or whatever, that come *purely* from it being significantly different from SVN, and exactly what are they? > If you're just going to use it as a revision control system you're > missing out on 80-90% of what TFS has to offer (and thus it might not > be worth it). TFS 2010 is a major update to the product (v2 really, > since > 2008 was really a v1.1) so I'm doubtless overlooking some cool > features there 'cause I haven't used it. > Joseph > > w: http://jcooney.net > t: @josephcooney -- silky http://dnoondt.wordpress.com/ "Every morning when I wake up, I experience an exquisite joy - the joy of being this signature."
