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 20:28:06 2006