[crossfire] crossfire source code control systems

Mark Wedel mwedel at sonic.net
Sat Aug 12 02:50:59 CDT 2006


  The recent discussion on the release cycle lead to another conversation about 
what source code system could be used.

  There seemed to be a lot of opinions on what should be used without any real 
clear test to see what is needed.  I think a better way would be to define what 
crossfire needs are, and then see what system meets those needs best.

(as an aside, at current time, it seems like we'll stick with CVS for now, as 
there isn't any system that clearly seems better, and CVS is working for us 
right now.  Second aside is other than official support from sourceforge, 
mercurial seems better than SVN).

  Please note that this list probably isn't complete.  Before we start going 
over what each system provides, we should first make sure this list complete. 
Also, it is probably reasonable that some of these perhaps move between 
categories I put them in - these categories are just from my point of view.

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)
- Multiplatform (*nix & windows at minimum)
- Access control lists (limit specific people on who can do check ins).
- Read-only access to everyone.
- 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)
- E-mail notification of commits.
- Ability to convert to CVS to whatever the new format is.

Top Features:
-------------------
- Readily available/easily installable software (shouldn't need to do a dozen 
steps to be able to install/use the software)
- Tracking of when merges are done.
- Good branch handling (fairly vague here, as not sure what would be considered 
good in this case, as I don't think CVS is that great as is).
- Efficient use of resources (network bandwidth, cpu, etc) - it shouldn't take 
15 minutes to check out the server, for example.
- 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.
- support for symbolic tagging within the repository (and not have to create 
another repository as the tag)

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)
- Maximum ability to do SCCS operations without access to repository (diffs, 
status, etc).
- 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)
- Ability to do local branches (and make those branches available to others)

  I know I'm forgetting something, which is why I'm sending this out.





More information about the crossfire mailing list