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."
