[Gnu-arch-users] Re: designing how to kill pristine trees

[Pau Aliagas]

On Fri, 3 Oct 2003, Tom Lord wrote:

>     > > Have a look at `src/tla/libarch/local-cache.[hc]'.
> 
>     > > The vague problem statement is to implement the functions declared in
>     > > the .h in such a way that they "work well".
> 
>     > At a first glimpse and applying logic, if we want to get rid of 
> pristine 
>     > trees, we have to make the revision library mandatory.
> 
>     > Is that an issue? I don't think so, we could even have a default path 
> for
>     > it if not supplied, so that the user shouldn't have to type it the first
>     > time.
> 
> :-)

So, we agree :)
 
> Yes, it is at least in the neighborhood of various issues.  We can
> walk through this slowly over several messages if you really want to
> work on this improvement.  I probably have a few useful
> recommendations to make and, anyway, in this kind of area where the
> devil is really in the details of how various decisions play out
> against how a user uses his homedir, local disks, etc. --- "many
> eyeballs" applied to the _design_ effort is potentially a big help.

Yes, it's not damn difficult, but it's easy to make mistakes. I've seen it
in the sparse revisions case. More eyeballs are welcomed; brains and 
fingers much more :)

> (In other words: please think out loud on this one -- trying to keep
> each increment to the design short.  And let's see how it goes.
> People replying should try to keep their replies short and to the
> point too.  I've changed the subject: line and started a new thread.)

> A default path for the default local cache is fine.  ~/.arch-cache
> perhaps[1]?  It's not obvious to me that the cache should be the same
> thing as a revision library (even if they overlap in implementation)[2].

Ok, let's assume that your idea of keeping two caches is the right one.

If this is the initial way to go, we are almost saying that we'd move 
pristine-trees to a common directory. That's an easy one, I think.
+Pro: pristine-tree sharing among working dirs.
-Con: still no sharing with revisions in library.
 * Solution: hardlink pristine trees to revisions

So we would need to take two steps:
-move pristine trees to common dir
-hardlink them to revisions in library

But once you hardlink them to the revisions in the library, why do you 
need them?

> [1] ~/.arch-cache rationale
> 
>     I'm assuming we agree that it goes in the homedir and should be 
>     hidden.
> 
>     Why not ~/.arch-params/cache?
> 
>     Because users should be able to copy ~/.arch-params without
>     copying a cache.

Sound fine. Don't mix cache with params.

> [2] not the same thing as `my-revision-library'
> 
>     The cache is to be semi-automagically managed to make it roughly
>     space-bound yet effective as a source of handy known-good
>     revisions.  A revision library is more explicitly managed to lock
>     down certain revisions.  Won't users sometimes want _both_ a cache
>     and a revision library? (I'm pretty sure I would.)

Whilst I understand that you can have that need, in fact it makes no
difference. Generating revisions or pristine-trees automatically is the
same thing.

If you want to prune you'll have to do it manually (or via a shell
script) be it in one case or the other. If we automate it, we can do it 
for both cases. Andif this is the main shostopper, I'll kinkdly create the 
command library-prune :)

People who really would care about cached revisions are, unfortunately, a 
minority, probably very well represented in the current list; most of 
people would never care. Why make things more complicated? If you want to 
manage cahed revisions, use the library commands :)

Pau

PD: probably I won't be able to answer til sunday afternoon CEST time