[crossfire] crossfire source code control systems

[Alex Schultz]

Kevin R. Bulgrien wrote:
>> 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.
>   
Well, to me it seems unclear how well CVS would keep track of merging
things from the mainline, plus it's nice if this history locally of
changes in a large project, is copied to the mainstream. Also,
downloading the cvsroot isn't exactly nice on sf.net, due to the
different modules, one must rsync all of the modules in order for cvs to
work properly on it, and that's over 800MB of data to transfer, and even
if one was about to figure out a hack to get only the server module and
some cvsroot files so cvs would like it, it would still be 184MB to
transfer. Various distributed SCMs can deal with pulling the history and
everything on their own, and can transfer the crossfire server tree
history and all in as little as 77 MB. Even if sf.net had a nicer way of
getting the cvsroot, it just doesn't seem to me CVS would handle the
merges very well or keep track of them in a useful way. Also, one thing
that distributed SCMs would allow easily that I don't think would work
well in CVS at all, would be:
A developer is planning on making a variety of experimental game-balance
changing changes and wants to test them out locally, so the developer
makes a couple different (temporary-until-merged-to-mainline) local
branches for different aspects of the changes that he wants to be able
to merge to the mainline separately easily. The developer also wants to
test them all at once, so the developer makes another local branch and
pulls the changes from all of those other ones, and builds a test server
with that. Also, the developer could very very easily make that local
branch viewable to others so they could get it to test out it's balance.
That is IMHO something very useful that I can see happening with
crossfire, that would be pretty trivial with distributed SCMs, that I
don't think could be done very well at all with CVS.
> 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.
>   
> 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.
The issue in those two paragraphs is warranted IMHO, however I
personally feel that if moving to another SCM, it could be dealt with
very trivially by using the SCM conversion program 'tailor', to keep a
read-only CVS mirror perfectly in sync, history and all. That could even
be setup to be done automatically every time a change is put in the
mainline tree with many SCMs. Therefore people who just want read-only
repository access can stick with CVS perfectly fine.
> 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.
Well, the universal version number thing has bitten me a couple times,
when wanting to figure out how a revision changed a variety of files
when the changes were too big to show up in sf.net cvs mail. That said,
that is only a minor annoyance.
> 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.
Well, I have never heard of any distributed SCMs trashing repositories,
however even if the very unlike event something were to the nature of
people having local branches has a side affect of causing highly
redundant backups, so the repository would be trivial to restore, even
if the hard disk crashed where the mainline was kept and the server
backups were lost. To me it seems that the highly unlikely chance that
of server failure and backup loss at a single source, is more likely
than the repositories getting trashed at 5+ separate places at once.
> 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. 
>   
Yep, and there are valid reasons to move code around to make things more
organized, not every 6 months, but every 5 years or so at least, and
actually currently the archetypes module in CVS is currently littered
with large numbers of empty directories from when things were poorly
organized. That said, it's only a minor annoyance, but it's yet another
thing contributing to CVS being annoying.

Alex Schultz