On 3/20/2012 10:54 AM, Hartmut Kaiser wrote:
Nobody has shown to me that SVN is not capable of doing this - or Mercurial or ...put your favorite VCS name here...
I haven't finished catching up with all the messages on this thread but this was too bizarre to go past. As is usual with "Turing equivalency" statements it is irrelevant in practice. Yes, everything that is done in C++ can be done in C, or in Basic, or in JavaScript, or in Cobol, or in Assembly, or on a Turing machine with I/O added. But that doesn't make those alternatives a convenient or even practical replacement for C++ in all cases. Similarly, there is nothing that any version control system does that cannot be done with a network file server. The question is not what any of them *can* do its how convenient, pleasant, reliable and efficient it is to do what is needed with each of them (I include the learning curve issue under "convenient"). I'm really quite agnostic on the issue -- the limited amount of experience I have with git does not weigh heavily against learning Mercurial from scratch. So far, though, there really has not been a single substantive argument that I can remember being made for Mercurial -- only *against* git, apparently based on atypical personal experience including the blunder of trying to pick up use of a tool never mastered after several months without the elementary precaution of copying the local repository first. (Coincidentally, I was in pretty much the same situation only a few days ago. An old client using git to distribute to Heroku asked me to add some patches. Since I had some tests and tools in there I updated my old repository rather than cloning a new one -- after backing it up for safety, which is just a matter of copying the top directory). Note that this would not be an option with a non-distributed VCS like svn -- the best you can do is back up your local sandbox. I do have sympathy for your stance given your experience, but it does seem to be quite atypical. I have to wonder whether at least part of the problem wasn't a poorly structured repository. Topher Cooper