[crossfire] crossfire source code control systems

[Alex Schultz]

Mark Wedel wrote:
> Key requirements (if it doesn't meet these, not usuable - probably everything 
> out there does)
> ---------------
> - Network based access (checkouts and commits - shouldn't be a need to log in to 
> a specific host to do a commit)
>   
Well, some/most distributed SCMs technically require 'logging into' a
host to push to it, however that process is usually handled completely
transparently via ssh, so I think that counts sufficiently as 'network
based access'.
> - Access control lists (limit specific people on who can do check ins).
>   
Most distributed SCMs (including bzr and Mercurial) I see tend to rely
on ssh authentication to deal with this. IMHO this is sufficient for
access control, though it isn't really an "access control list".
> - Supported by sourceforge, or secondarily, some other free hosting service (I'd 
> much rather someone else has to deal with any adminstrative issues of the 
> software, like update to latest version, etc)
>   
That is a trickier requirement and limits things a bit. Most mainstream
ones are just CVS and/or SVN. Launchpad.net (funded/ran by Canonical
Ltd.) provides bzr SCM. Also, Mercurial can run out of sf.net project
web space. However I've missed some hosting or something else can run in
project web space, I don't think we can look go beyond CVS, SVN, bzr,
and Mercurial with this requirement (not that it's a problem, just that
unless someone knows of something I've missed, that's something that
limits our choices).
> Top Features:
> -------------------
> - Efficient use of resources (network bandwidth, cpu, etc) - it shouldn't take 
> 15 minutes to check out the server, for example.
>   
I know bzr used to be really slow but apparently has been improved alot,
however I have heard it is not bandwidth efficent still. CVS and SVN are
both reasonable in speed. I don't know how Mercurial compares to CVS and
SVN, however speed is one of the primary aims of Mercurial so I would
assume it is pretty good. I'm thinking that some time I might try some
benchmarks with a variety of SCMs such as these on the crossfire tree.
> - Global revisioning - instead of each file having a revision that increases, 
> there is a global revision - this makes it very easy to get status right before 
> commits or back out changes.
>   
Every SCM I have heard of except CVS does this from what I've seen :)
> Other nice to have features:
> ----------------------------
> - Atomic checkins (killing your checkin while happening shouldn't leave 
> repository in inconsistent state - I don't think we have ever run into this, and 
> there are not a huge number of files in crossfire repository which is why this 
> is lower priority)
>   
I haven't heard of of a modern SCM that didn't have this :)
> - Maximum ability to do SCCS operations without access to repository (diffs, 
> status, etc).
>   
Well, for true maximum ability one essentially needs local branches.
> - good binary file handling (this may be a duplicate of efficient use of 
> resources. This also really comes in with the crossfire.[01] files in the lib 
> directory, which given how that file is constructed, not sure exactly how much 
> better the binary diffs can handle that)
>   
Unless the process for generating those files changes, then binary diffs
should handle it very much better. SVN, bzr, and Mercurial all support
this well from what I can see, and I don't know of any modern systems
that don't.
> - Ability to do local branches (and make those branches available to others)
bzr and Mercurial support this as do all other distributed version
control systems. SVN does not support this, however one can use local
SVK repositories with a central SVN repository very transparently, that
said I would personally not like to rely on SVK for local branches due
to it's dependency on numerous perl modules, and IMHO it just feels
'hackish'.

Alex Schultz