On Nov 9, 2005, at 21:05, Phil Endecott wrote:
> Dear All,
>
> I have been thinking about using a post-commit hook to keep a
> public "latest snapshot" of part of the repository up to date.
> This could be as simple as putting
>
> cd /latest/snapshot/; svn update
The hook script runs with no environment. You'll need to call any
executables by their complete path, e.g. /usr/bin/svn. You can test
your hook script on the command line by running something like env -
i /path/to/hooks/post-commit . This is useful for debugging because...
> in the post-commit hook. I've done some quick experiments which
> have not been very sucessful, so I have some questions:
>
> - Where do error messages from the hook scripts go? (Using Apache.)
...error messages go nowhere. You can redirect them to a log file if
you so desire, like
cd /latest/snapshot
/usr/bin/svn update 2>/path/to/svnupdate.log
> - Access is normally via Apache; is the nested call to svn OK, or
> does /latest/snapshot/ need to be a file: checkout, or what? (One
> of my experiments led to a runaway svn process, making me think
> that something recursive was going on.)
It should be ok, but I would recommend using a file:/// checkout
instead because it will be faster. Make sure you have a FSFS
repository, as BDB repositories have problems with concurrent access
over different protocols.
> - (Possibly related to the above:) I rquire HTTP AUTH for both read
> and write to the repository. How can the apache user, who runs the
> hook script, authenticate itself in the nested call?
You would need to figure out where the Apache user's home is, set up
a .subversion directory with cached authentication credentials
inside. It'll be easier if you just use a file:/// checkout and
bypass all that.
> - Only part of the repository is being tracked in this snapshot. I
> could make the update conditional by checking if it has changed
> using svnlook, maybe something like: "snvlook changed | grep -q
> something || svn update". But maybe an svn update when nothing has
> changed is just as fast - any comments?
In the script I wrote I first got a list of all paths changed by the
commit, then I had a mapping of snapshot working copies to repository
paths, and updated only the relevant working copies. I'm not sure if
this ended up being faster or slower than just updating everything
all the time. The problem in our setup was (and continues to be) the
RAM cache, which keeps getting thrown out and used for other things.
In testing, everything is very quick because data about the working
copy files remains in the server's cache. As soon as it's in
production, though, and our 10 developers are using Apache and
sending mails and everything else, the cache thrashes about and it
takes forever to do things.
> - I don't want this to slow down commits if I can help it. Is it
> OK to background the hook script, i.e. to have "svn update &" in
> the post-commit file?
I would definitely recommend spawning off another process somehow,
but simply "svn update &" may be too simplistic. If Bob commits r100
at 12:00:00 and the svn update process gets spawned at 12:00:01 and
takes 10 seconds to complete, and Joe commits r101 at 12:00:02 firing
off another svn update process at 12:00:03, then Joe's update process
will probably throw an error that the working copy is in use /
dirty / whatever it says, and when all's said and done, by 12:00:15,
the snapshot will be up to date with r100 but will never update to
r101—not until Sally commits r102 at 15:34:00.
While I have thought of these issues, I have not yet programmed the
correct solution to them; if someone else has gone that extra mile,
I'd sure like to hear what the best solution is.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 9 21:47:24 2005