[crossfire] crossfire source code control systems

[Mark Wedel]

Alex Schultz wrote:

> Indeed, that is an issue that prevents it from being usable on sf.net,
> though I have heard that project space of some other free hosts does
> allow this sort of usage, though I am unsure of if the web space
> provided is sufficient on those.

  Before we put the cart before the horse, we really need to figure out what 
system we will use.

  I see a lot of talk about mercurial, and it looks pretty good.  If we decide 
to go that route, we can then start to worry about this more.  SF does say you 
can drop them a note about getting more space.  And there may be other/more 
possibilities as mercurial gets more acceptance, etc.



> I think the main thing we need to figure out right now, is if we have a
> viable way to host systems such as Mercurial. One thing to note, is we
> could move to a more decentralized system, however:
>   1) We would still need some tree to be considered "official" or
> "authoritative" for the purposes of what we will release and such
> things. It would be possible to let a given developer handle that
> however I am unsure if that would work very well.

  An official tree is definitely needed - you have to have some way to know 
where to go to get the latest code.

  You just need that, for that matter, for people to do the initial pull from - 
there has to be an initial repository.

>   2) Many developers don't have the means to host a branch for others to
> pull from
> Anyone have any ideas for hosting such things?

  Well, re-hosting becomes easier - all anyone really needs is a static IP (or 
for that matter, dydns setup).

  I'd presume in such a setup, there would be a limited number of known/trusted 
sources.  But if these repositories are read-only, getting them set up may be 
easier (that said, you do need some form of shell access itself to do the pull, 
or at least make it most efficient, etc).

> 
> Also, bzr, which launchpad.net can provide hosting for, looks reasonable
> (see the chart) except that it is very slow to do a branch over http
> with (see Lalo's email: 2 hours), so would that sort of wait to make
> one's first local branch be acceptable to people, considering that to
> pull further updates is reasonable in speed, and that further local
> branches can be done from existing local branches? Also note, bzr can do
> cvs-style lightweight checkouts if that is reasonable to the people who
> won't wait 2 hours for their first local branch.

  Aspects of crossfire are odd from a SCCS system however.  In crossfire, we 
have the arch and maps trees, where you can easily have hundreds of files 
modified in a big change - if bzr is slow on checkouts, I'd think it would be 
slow on updates for the same reason?  Or is it more efficient when doing updates?