[Gnu-arch-users] Re: Design proposal to kill pristine trees

[Pau Aliagas]

I think that I have most of the infrastructure ready to farewell pristine 
trees, pending to be merged in mainline.

The first part is the already known as `sparse revision libraries'.

ad-hoc revision libraries
-------------------------
The second part is what we could call `ad-hoc revision libraries': you can 
specify a path to store and find the revisions, apart from the default 
my-revision-library.

All the commands that manipulate revision libraries have a new option -d
or --dir to specify a different directory. This way we can store revision
libraries ad-hoc, wherever we need them.

This allows, among other things, to have a temporary revision library, 
that we can simply delete when we don't need it.

It also allows to have revision libraries close to the working dirs of the 
projects. This is useful if you have projects in different devices or 
computers because you could put a library in each device and use the same 
quota or use tha hard-links option to speed up gets and commits.

`find-cached-revision' and `make-cached-revision' hooks
-------------------------------------------------------
But different revision libraries wouldn't be worth a dime if they cannot 
be used in all the arch operations like get, what-changed, commit, etc.
In its current state, arch looks for revisions in the default 
my-revision-library. It's necessary that it can search in other locatins 
as well.

I considered two options:
a) convert my-revision-library to a multi-path and use the first entry as 
   the default.
b) add a way to tell arch in real-time where to look for the revision.

I have implemented b) for various reasons:
-it's a necessary step to reach a) if finally we decide it
-I think that mantaining a path for revision libraries, independent of the 
 archive, is impractical:
 * it can be a maintenace burden
 * as the seek would be sequential, it could look in remote filesystesm 
   and make it painfully slow in cases were it shouldn't.
 * you have to duplicate work:
   -you have to write a script to create revisions in the proper library
   -in the same script you could say where to look for the revision
    otherwise you have to mantain the path in another place. one day otr 
    the other you miss it. With an only script you do everything in one 
    place.

Implementation:
-add a way to read output from the hook script
 * done via a file descriptor that will be fix for the hook: fd 3
-add a new `cached-revision' hook
 * the hook script usually would add revisions on demand
 * if the script returns output, it's interpreted as the path where to 
   look for the revision.

Hook example:

-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<----
#!/bin/sh

# returns OK if $1 contains $2
strstr() {
        [ "${1#*$2*}" = "$1" ] && return 1
        return 0
}

# not often used archives
if [ strstr "$ARCH_ARCHIVE" "address@hidden" ]; 
then
       library = ~/.arch-cache

# network archives                 
else  if [ strstr "$ARCH_ARCHIVE" "address@hidden" ];
then
       library = /usr/share/proj_machine/proj-twice/.arch-cache

# the rest of the archive
else
        library = `tla my-revision-library`
fi

case $1 in

find-cached-revision)
        # return library path via fd 3 (no CR please)
        echo -n $library 1>&3

make-cached-revision)
        echo "make-cached-revision $ARCH_ARCHIVE/$ARCH_REVISION" |
        mail pau -s "cache revision $ARCH_ARCHIVE/$ARCH_REVISION in $library"
        # add revision to proper library
        tla library-add -d $library $ARCH_ARCHIVE/$ARCH_REVISION
        # return library path via fd 3 (no CR please)
        echo -n $library 1>&3
        break
        ;;

make-tmp-cached-revision)
        # add revision to proper library
        tla library-add -d $library $ARCH_ARCHIVE/$ARCH_REVISION
        # return library path via fd 3 (no CR please)
        echo -n $library 1>&3
        break
        ;;

esac
exit 0
-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<----

I think this is the best way to implement it and that we should not go for 
the multi-path solution as it would certainly be worse.

Next step would be to get rid off prisine trees as they are no longr 
necessary :)

I'm all ears.
Pau