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

Re: [E-devel] cvs, servers and stuff.

On 8/18/06, Eugen Minciu <minciue@gmail.com> wrote:
OK. I'm done supporting git now ;) Time for other ideas.
>From what has allready been presented I find anoncvs mirrors as a better approach to tarballs, as many of us actually don't have the bandwith to download a dist tarball every week.

CVS has hooks from what I can see.Yay. So after every commit we could set something up on the server to:

Idea 1:
1) export the directory main directory (like apps/e)
2) make an archive of the export.

Idea 2:
The zip utility can update only a part of the archive that has changed. You could run something like zip -u e17 path/to/e17. I made a zip of the whole e17 module, changed a single file then ran update. It ran and updated everything in 11.5 seconds on my laptop. On your machine it could probably happen in less then 5.

Again, you could combine this with the above and generate archives like apps_entrance.zip or whatever, which would update in less then a second.

Thus, you could store just one version of the file at all times. People don't get confused with versions, they're always in sync with the repo and they can easily check if they're up to date with the help of md5 hashes. I could even write you some script which checks to see if a user is up to date and downloads the modified archives.

Except that this would cause the file to be redownloaded every time a
change happens. This will eat up far more bandwidth than using an anon
repo (anoncvs, assuming users update) or with a base tarball with diff

(Just a random note, both Portage (Gentoo) and BitBake (OpenEmbedded)
keep the checked out CVS tree around and simply update it for a new
build. They also keep around the source tarballs that they download,
although some people delete them for more space (although they of
course shouldn't).)

Justin Patrin