[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Pau Aliagas
Subject: [Gnu-arch-users] Re: designing how to kill pristine trees
Date: Mon, 6 Oct 2003 20:12:34 +0200 (CEST)

On Mon, 6 Oct 2003, Tom Lord wrote:

>     > From: Pau Aliagas <address@hidden>
> Thanks for that.

And I only intended to post a quick summary :)

>     > * my opinion
>     >   My opinion is that we should eliminate pristine trees and move to 
>     >   revision libraries excusively.
>     >   If we need temporary libraries and long-lasting libraries we could 
>     >   consider adding multiple paths for them, to classify them by its a 
>     >   priori endurance, but I think this would be over-engineering as it can
>     >   be done now just removing them.
> I think that the idea of a revlib path, rather than a single revlib,
> is inevitable.    That's a pretty lightweight change and interacts
> nicely with boilerplate hook scripts that manage these things.

Good! In my opinion this would solve the question of keeping pristine 
trees around. We could keep revisions in a temporary library instead.

> You left out the recent idea of keeping pristines as .tar.gz under
> {arch}.   I think that such a mechanism is a great enabler for "one of
> my revlibs as pristine-tree-killing cache."
> On a commit, this should work out to something like "update the
> relevent revlib then tar zcvf it into {arch}."

My concern is performance: revision libraries are optimal and the only 
drawback can be addressed with mutliple paths and a hook script.

Slowing down gets, commits and diffs just to keep a tar.gz (or the current
pristine trees) sounds unnecessary and worse than revlibs. Why complicate
the code and slow down everything when we already have the perfect


reply via email to

[Prev in Thread] Current Thread [Next in Thread]