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

[Pau Aliagas]

On Mon, 6 Oct 2003, Tom Lord wrote:

>     > From: Pau Aliagas <address@hidden>
> 
>     >> {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
>     > mecahanism?
> 
> The "lifetime management" problem -- i.e., "when to discard and
> reclaim space" -- is insoluable absent a copy in {arch}.   tar is
> pretty fast.

> It would also be reasonable to make an option to skip that step for
> users who have terabyte disks and who would therefore reasonably
> prefer revlibs that grow "forever".

Arch has everything in place, nothing new has to be added.

Managing automatically revlibs to reclaim space, as you say, cannot be
done automatically in a 100% satisfactory way, but approaches can be 
"enabled" via hook scripts:

-casual users, users whose needs are not extreme like emacsen or linuxk 
 kernel guys, can have a default enabled that keeps only the latest 
 revision (or some other compromise).
-high-demanding users will have full control of what happens and will be 
 offered different script examples to fulfill their SCM dreams.

If we remove the pristine trees, we can address, without any limitation, 
both groups of users. Slowing down things to keep tar.gz in the tree and 
making that the general case will buy us nothing. What for?

Tom, what I see is that arch is so good and well thought that it can do
even better without pritine trees. Pristine trees are a hack that has 
served us well, but it's time to farewell them and use the more advanced 
revlibs all over the place. We'll chase the problems later on.

Pau