Re: [Gnu-arch-users] Libraries and changesets

[Aaron Bentley]

On Wed, 2003-12-31 at 13:06, Tom Lord wrote:

> BTW, do you keep local mirrors of my archive or other remote archives
> that you use?  In combination with an agressively pruned revlib, they
> will give you pretty much the space performance that you'd expect from
> a "compressed revlib" or a "revlib stored as changesets".  If you
> revlib prune relatively sanely (e.g,. getting rid of only old
> revisions you are pretty sure you don't need any more) this will also
> have excellent speed.

Doh!  Yes, a local mirror would be a lot like a revlib-via-changeset,
though not greedy.  Making a local mirror sounds like a big deal at
first-- after all, I don't mirror kernel.org, I just grab the patches
for the latest revision.  But when you realize an entire mirror can be
smaller than two copies of the latest revision. . .

> If nothing else in particular is going on, then a typical star-merge
> will want to add two new revisions to your revlib.   The first time
> you do this, paying the cost of full copies, 20M growth sounds about
> right.
> But after that, the overhead should be closer to 2M plus the size of
> any files changed in the new revisions.  

Yes, I generalized incorrectly because tla-devo--1.2--patch-50 was
retrieved before patch-43.

> And there's absolutely no good reason, if all you're doing is
> "tracking the latest" and maybe doing a little hacking, to never prune
> your revlib.  By tossing old revisions, you can keep your revlib
> _at_a_constant_size_ and continue star-merging indefinately.

Distributed development with Arch is much more complicated than local
development.  You need not just archives, but revlibs, local mirrors,
and pruning scripts.  It seems like it almost needs its own howto, so
people can get started with sensible defaults before they gain a
comprehensive understanding.

> (a) it should be easy to automate the heck out of pruning your revlib

With local mirrors, it might 
"rm -R ~/greedylibrary/*".  With a few key revisions in a non-greedy
library and a local mirror, that just might suit me.

> (b) depending on how comfortable you are with the idea, consider
>     using the --link options to `get' and `buildcfg' for your
>     project trees

I'll probably do that, but I'm glad I looked into vim's hard-link
behaviour first.

Aaron
-- 
Aaron Bentley
Director of Technology
PanoMetrics, Inc.