[Gnu-arch-users] Re: sparse libs and merge fest fun

[Pau Aliagas]

On 14 Nov 2003, Miles Bader wrote:

> Pau Aliagas <address@hidden> writes:
> > I think that the default behaviour should be to build sparse revisions.  
> > People are usually less interested in older revisions IMHO.
> 
> I agree.
> 
> Of course I think the best interface is the one I suggested in my
> savannah bug report:

And someone listened your opinions, made them up a little and voila!

>   * default is only the one rev
> 
>   * --every=N option to allow adding `every N' revisions; the old
>     behavior is N == 1.  One nuance is that I think it should decide
>     _which_ options to add based on the patch number, i.e., add a given
>     revision in the range if (P % N) == 0, where P is the patch number,
>     so that they remain the same over time (as long as N is the same).
> 
>   * --until says that it's OK _not_ to add the specified revision (i.e.,
>     it's a boundary, not an explicit request); together with --every,
>     this would make it simple to automatically maintain a certain
>     frequency of revision entries, just by periodically doing `--every N
>     --until LATEST-REV' [BTW, that reminds me, it would be nice to have
>     a tla tree-revision command to match tree-version -- of course it's
>     simple enough to do `tla logs -f | tail -1', but still...]

My position is:
-make a good default: that needs help to setup good default parametres, 
 including hook scripts if necessary).
-give freedom to implement your and others strategies as there are as many 
 requiremnts as advanced users.

So, instead of hard-coding it, I opted to leave that decision to a hook
that get called whenever you look for a revision. Then it's up to you to
add one or N.

> > I can imagine someone having all the tla libraries being added recursively
> > or, by the same reasoning, the kernel revisions, looking at the I/O fest 
> > and running out of space.
> 
> Yes, it's happened to me several times ... :-)

Pau