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
helps.
----- 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