Re: [Gnu-arch-users] [PATCH] arch speedups on big trees

[Aaron Bentley]

On Wed, 2004-01-28 at 13:40, Tom Lord wrote:
> 2) "sliding" libraries -- that try to keep the number of revisions in
>    a version constant by recycling old revisions (honoring the locking
>    protocol)

Sliding libraries seem to be a generalization of "current revision"
libraries.  If "current revision" libraries are significantly easier to
implement, it might be worthwile to do that instead.

I'm planning on revising build_revision so that it can work backwards
from a recent revision to an older revision.  If that works out, the
need for keeping several revisions in a library will be reduced.

> 5) Remove all code related to pristine trees.   The above features 
>    turn that into dead code, more or less.

I'm always in favour of generalizing code to reduce the number of
special cases, and this approach sounds good to me.  Since generalized
code is exercised more, it's less likely to be buggy.

In tla--devo--1.2, greedy libraries are still underused.  My
address@hidden/tlasrc--greedy--1.2 branch contains updates.
http://sourcecontrol.net/~abentley/archives/tlasrc/

> 6) If users balk at the edge cases resulting from having a non-default
>    library path that doesn't include the "special string" for in-tree
>    libraries, then perhaps add that implicitly to the end of the
>    add-path.

These changes will make some form of greedy library required.  It will
change the form of nasty surprise from "dammit, I didn't want a
pristine," to "dammit, I need to explicitly add a revision before I can
continue".  This is true whether or not the "special string" is always a
member of the library path.  

A user without greedies will be unable to work, and if they configure
their libraries, it's not hard to set up a greedy.

> I think that will give you 90% of what you want and it also truly
> kills pristines (though introduces in-tree libraries).
> 
> It's also a nifty plan because it's (finally!) an occaision where we
> can probably wind up _removing_ more code from tla than is being added

Say, what about unifying cmd_get() with find_or_make_local_copy()?  Is
there any reason for duplicating functionality this way?

Aaron

-- 
Aaron Bentley
Director of Technology
PanoMetrics, Inc.