[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