> With a distributed SCM, you'll install your maps dir as a local branch, > branched from the maps mainline. Then you can make your own changes and > commit them -- you even get local revision control for your stuff. And > when you need to update your maps, you just merge from the mainline; that > *may* cause conflicts, but it's guaranteed to never lose your changes (as > they will, at the very least, be in the history).
This is an interesting thread, but I cannot help but think that people do not really know key things about CVS. CVS can handle precisely this sort of scenario quite handily. I did it just this weekend when I downloaded, ironically, the CVS CVS repository in order to give them a patch on docs. In my sandbox, I created my own sandbox that was for a local repository and in the same directory tree. cvs update at the top of the directory tree just worked. Remote things updated from remote repositories and local things updated from local repositories in one fell swoop. My opinion obviously means little as I'm not a project developer, but if crossfire went away from CVS, I would be very sad, as I have zero interest in dividing my brain into SCM compartments for every open source project out there that I dabble in. I can currently twiddle around and contribute (what very little I have) precisely because CVS is practically universal. There are nitpicky things about CVS, but I suspect if people tried to get their heads around it almost all issues that seem significant can be dealt with adequately in CVS. I admin a VC system at work, and spent a while looking at other systems and gave it up in the end, even after giving svn a go. Do not want to train people that don't care a hoot about version control, and just want to do work. Maybe your team is all about VC, but mine wasn't, and I saw no reason to subject myself and them to a whole host of new problems by tossing something that works really well, including branching. I don't get the comments about CVS branching being inadequate. To me its all about following CVS best practices and not necessarily the horde of people who don't do it according to those practices. It's just not that hard. The whole atomic commit/universal version number thing is far, far more an issue with highly concurrent development. If you haven't gotten bit yet, you likely never will, so it ends up being a non-reason if you ask me. Why take on a learning curve for a "feature" that really has almost zero chance of giving you a decent ROI. Besides, CVS will never trash your repository. How many times have there been svn issues that will trash your repository, even if it is only the doozer that forgets the backend is a database that cannot simply be copied from one system to another if the database version is a bit different. Also, one of those tools on the list was not even version 1.0. At work we are on CVS because every other tool (several) they used trashed the repository. In perhaps going on ten years now, not one byte has been lost to CVS malfunctions. Now those were commercial tools, and not ones on your list, but... if it ain't borked, don't fix it is what I say. Features aren't sexy enough if you ask me. Yeah, the whole "permanent directory" thing is hosed, but then so is the doofuss that goes in every six months and changes everything all around because they just had a girlfriend change. Shrug, ok, end of rant, do what you will, but I suspect it will cut down on participation because people won't be bothered to learn a system they don't already know how to use, and I don't see contributors flocking to the doors as it is. Just my ten cents... Kevin Bulgrien _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
