[crossfire] crossfire source code control systems

[Kevin R. Bulgrien]

> 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