[Gnu-arch-users] Re: patch-log sizes

[Pau Aliagas]

On Wed, 17 Dec 2003, Dustin Sallings wrote:

> 
> On Dec 17, 2003, at 0:26, Pau Aliagas wrote:
> 
> > Isn't all this soved by cacherev?
> >
> > You have 1000 log entries in a project. You tag another branch and
> > cacherev base-0. You don't need the old patches anymore. so you can
> > "retire" the old archive.
> 
>       That's kind of what I'm asking.  I seem to recall reading a while back 
> that cacherev should take care of ``almost'' everything, but I never 
> found out what that meant.  Is it just the inability to check out older 
> revisions (or is that possible)?

You need access to the archive when you get or commit changes.

In the case of commit, you always end up hitting the archive to store the 
patchset.

In the case of get, arch tries very hard to use existing caches before 
reading from the archive:
-it looks for a cached revision in the library (now you can even have 
 different library paths). If it finds it, you do not hit the archive.
-if there's not a cached revision available, it looks for it in the 
 archive. As it needs to get a full tree and not only a patch, it has to 
 look for the closest ancestor that is stored. If you never cache a 
 revision, it will need to go up to the first import and apply all the 
 patches to the one requested. If you cache from time to time, it will 
 stop in the first cached revision.

So the trick is to cache revision to avoid going too backwards. You can
take advantage of this feature to "backup" old archives that you are not
going to use any more. You use the trick of recycling archive + tagging +
cacherev and you are done. Then you backup your old archive. If some day
you need, you restore it.

This caching in the archive is useful because the cached revision is 
available to everybody independently of the revision libraries. The 
drawback is that it takes space (bad for mirrors).

In day to day operations, sparse non-greedy revision libraries are the way 
to go.

Pau