[crossfire] crossfire source code control systems

[Mark Wedel]

Alex Schultz wrote:
> Ok, I just made up a table of the criteria that Mark listed, and a
> couple others, for CVS, SVN, Mercurial, Bzr, and Darcs (anyone want any
> others on the table?). If anyone has any revisions or wants to add any
> other SCMs feel free to make them.
> Currently storing it in my namespace on the wiki at:
> http://wiki.metalforge.net/doku.php/user:rednaxela:scmtable
> Make sure to read the numerous footnotes when looking at the table.

  Few notes on this:

  I was looking over the sourceforge documentation, and hosting mercurial or 
darcs on the project web space and getting the data via the webserver looks to 
be a violation of their terms of usage.

  In particular, two things stand out - the quota for the web space is 100 mb, 
and they don't want bandwidth intensive use (specifically say to use the file 
release mechanism for file releases, not the web space).  Crossfire, with CVS 
history and all, uses about a gigabyte of space. The file access rules might be 
another issue.

  OTOH, mercurial makes it much easier to have children, given it is a 
replicated system.  So one could easily have sourceforge or the like the 
definitive location, but not allow the read-only access from there, instead, 
various sites could have branches that make it available, and they just do 
pullovers nightly or whatever.  But the sourceforge is certainly an issue, but 
if we decide something not officially supported by sourceforge is best, we can 
then start the process of seeing what would work.

  Also, I'm not sure if I'd put a yes in the symbolic tagging for SVN - IIRC, 
SVN doesn't actually have symbolic tags, rather, you make a new repository of 
your tag.

  Thus, we'll end up with like 50 repositories.  That approach isn't bad, but i 
really like to be able to do something like a 'cvs log', see for what version 
the symbolic tag was done, and thus what has been done after that (if a bug was 
reported with the last version as having the bug, has it already been fixed?) - 
with SVN, from what I gather, you'd need to go to the repository for that 
tag/release, see the version there, then go back to the head branch and see the 
changes since that time.

  There may be ways to do that with scripts they have, and I may be wrong in 
that, but that is what I gather (Actually, when I think about this, I don't 
think there is anything preventing changes in that copied repository, so even 
that may not be accurate, eg, I make a rel-1-10 repository, then someone checks 
in a change there for a 1.10.1 release instead of making another repository)

  Also, for SCCS operations without access to repository, my understanding again:
SVN: yes - like mercurial, it stores all the change log information, etc, when 
you check out, so you can do diffs, see changed files, revert to last pristine 
file without network connection (or maybe it only stores a subset of the tree, 
but from my reading of the SVN docs, it suggest you can do diffs, unget, and see 
what files you have modified in your local directory without need for connection 
to repository, so I'd mark it as a yes for that)

mercurial: same as SVN, and you don't need a branch - that is the downside to 
footnote 12 - no light weight checkout.  OTOH, I think this means checkins are 
more lightweight - it can just send the diffs to the server.  It's sort of a 
tradeoff - more time for the initial checkout but less time for future 
operations (I think it was the SVN doc which said this was intentional - disk 
space has become much cheaper/more available than network bandwidth, so it makes 
sense to try and cache as much data locally as reasonable).