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 _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
