[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnu-arch-users] Re: Design proposal to kill pristine trees
From: |
Pau Aliagas |
Subject: |
[Gnu-arch-users] Re: Design proposal to kill pristine trees |
Date: |
Mon, 13 Oct 2003 19:17:35 +0200 (CEST) |
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
- Re: [Gnu-arch-users] Re: Design proposal to kill pristine trees, (continued)
- Re: [Gnu-arch-users] Re: Design proposal to kill pristine trees, Tom Lord, 2003/10/08
- [Gnu-arch-users] Re: Design proposal to kill pristine trees, Miles Bader, 2003/10/08
- [Gnu-arch-users] Re: Design proposal to kill pristine trees, Tom Lord, 2003/10/08
- [Gnu-arch-users] Re: Design proposal to kill pristine trees, Miles Bader, 2003/10/08
- [Gnu-arch-users] Re: Design proposal to kill pristine trees, Tom Lord, 2003/10/08
- [Gnu-arch-users] Re: Design proposal to kill pristine trees, Pau Aliagas, 2003/10/09
- [Gnu-arch-users] Re: Design proposal to kill pristine trees, Miles Bader, 2003/10/10
- [Gnu-arch-users] Re: Design proposal to kill pristine trees, Pau Aliagas, 2003/10/10
- [Gnu-arch-users] Re: Design proposal to kill pristine trees, Miles Bader, 2003/10/10
- [Gnu-arch-users] Re: Design proposal to kill pristine trees, Pau Aliagas, 2003/10/10
- [Gnu-arch-users] Re: Design proposal to kill pristine trees,
Pau Aliagas <=