glob2-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [glob2-devel] mercurial switch


From: Kieran P
Subject: Re: [glob2-devel] mercurial switch
Date: Thu, 19 Apr 2007 11:04:26 +1200

I think putting the data and maps on Savannah is both an improvement and a
regression. It is an improvement because then anyone can update them and a
regression because it is not possible to sync new versions, old ones need to
be deleted.

You should be able to run a command to overwrite whats currently there, via scp. It would be more an inprovlement than a regression.

So here is my suggestion: we can try to put graphics into mercurial too,
provided people refrain to abuse on commits with graphics (like posting
suggestions on ml first and only committing graphics when the community
agrees).

I thought the reason why didn't put them in the repository was because of space and bandwdith, and that was on Savannah. Whats it going to do on your server? One person downloads 25 times, commit a 100mb file, bam. Bandwidth and space gone. Its easier on Savannah where they handle the space and bandwidth.

For the maps, we do not commit them now as they might be invalidated in the
future. For the future, I suggest providing very few maps with glob2 but
adding a maps browser that can download them from the web on demand.

True, most maps are going, but again, they are easy to replace when the time comes, especially on Savannah. Kyle could hold the old maps <= a23, and the new ones could be on Savannah.

If the mercurial rep gets too big, we split binary files out of it again or
reconsider hosting solution.

Ok, if thats the way you want to go, then I'm fine. As long as it works in the end is the main thing (putting them in murcurial would also mean we could remove syncdata and maps, and releases would be far eaiser (no mkdata/maps, then syncing and checking everything). One download of CVS, make dist, then upload that file for people to test. A week later, when all bugs fixed, another make dist and release. Thats the easiest method.

Does everyone agrees?

I agree with putting them in murcurial as a trial, and keeping <= a23 files on kyles server (they overtime would fade out usage, no one would download old CVS revisions and need to use syncmaps or data)

--
Kieran.P
http://qlwiki.linuxsolutions.co.nz/
reply via email to

[Prev in Thread] Current Thread [Next in Thread]