[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: flag to disable hook scripts

From: Renaud Waldura <renaud+subversion_at_waldura.com>
Date: 2006-02-03 23:11:21 CET

Thank you for sharing your setup, Ryan. Very interesting, and I'm sensitive
to your argument of "keeping good code in the trunk". My solution totally
fails in that regard.

> their working copies through the Linux machine's web server, and once
> they're satisfied with their changes, they check them in.

How is this done? With a Windows/Mac SVN client? Eg. TortoiseSVN.
How's that working over SMB?

> You could devise a process whereby the asynchronous update script can

I vaguely remember doing something like this with named pipes on Unix. It

----- Original Message -----
From: "Ryan Schmidt" <subversion-2006Q1@ryandesign.com>
To: "Renaud Waldura" <renaud+subversion@waldura.com>
Cc: <users@subversion.tigris.org>
Sent: Friday, February 03, 2006 11:22 AM
Subject: Re: flag to disable hook scripts

> On Feb 3, 2006, at 19:33, Renaud Waldura wrote:
>>> We currently update a working copy in our post-commit hook, and this is
>>> quite a bad idea. :-)
>> Ryan, could you elaborate a bit? I'm about to do the same thing. What
>> else should be done instead?
>> A word about our setup: Java developers compile/run/test locally, then
>> commit to the repository (classic programming model). But our HTML
>> developers (who outnumber Java developers 3 times over) don't run an app
>> server locally. They check files out, edit them, and commit them to the
>> staging server to see their changes, where an appserver runs.
>> I was therefore writing a post-commit hook to update a WC that is read
>> by the appserver, so that HTML developers see their changes right away,
>> as expected. They work with one finger on the F5 (refresh) key.
> We're a web development company, so everything in our repository is a PHP
> web site. We have one central Linux development server, and everyone has
> their own working copies in their public_html directories in their home
> directories on this server. They mount this on their Windows or Mac
> workstations over Samba. Anyone can test their working copies through the
> Linux machine's web server, and once they're satisfied with their
> changes, they check them in.
> We want to keep our trunk and release branches filled with only good
> code, so we wanted to avoid the setup you're talking about, where people
> have to check in before they can test.
> But we also needed one central working copy of each project that was
> always up to date, for the bosses and other non-technical people to look
> at to see how the projects are coming along, and also for the clients to
> look at. For this reason we put in the post-commit hook to update these
> working copies. Some of the web sites are large, though, comprising
> thousands of files, and updating such a working copy causes much disk
> cache thrashing on the server as it has to read entries in each .svn
> directory. This makes the process slow, often taking several minutes to
> complete, during which time the developer is just waiting for his
> Subversion client to give control back to him so that he can do his next
> task. I've found myself forgetting what I wanted to do next while waiting
> for the hook to complete. In our setup this isn't only a problem for the
> big sites, because if someone commits a change for the big site, the .svn
> entries for the small sites have fallen out of the disk cache too, so
> updating them is slow too.
> A better approach, which I haven't gotten around to trying out here yet,
> would be to have the post-commit hook fire off an asynchronous process as
> others have already suggested, but such a process must be careful not to
> step on itself. If I commit a change, and this causes the central working
> copy to begin updating itself, and this will take two minutes, but one
> minute after my commit someone else commits a change, then two processes
> will be trying to update the same working copy. Subversion detects this,
> and the second update will fail with an error message that the working
> copy is locked. When the first update process completes, it will unlock
> the working copy, but it will now not be up to date; it will be missing
> the second developer's changes, which won't appear until the next commit,
> which could be in 5 minutes but could just as easily be in 5 hours.
> You could devise a process whereby the asynchronous update script can
> detect that another update script is already running from a previous
> commit, and wait until it's done before updating the working copy again.
> Or, you could disconnect the update process from the commit by running it
> in a cron task every 5 minutes, say. But even 5 minutes might be an
> intolerable delay if you're going to go the way you're suggesting, where
> the developers must use this working copy to see if their changes work.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 3 23:13:58 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.