> -----Mensagem original-----
> De: Ryan Schmidt [mailto:subversion-2006Q1@ryandesign.com]
> Enviada em: sexta-feira, 3 de fevereiro de 2006 16:23
> Para: Renaud Waldura
> Cc: users@subversion.tigris.org
> Assunto: Re: flag to disable hook scripts
>
> 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.
The process could:
1. Create a new directory "WC-${revision}" with the revision number given from the post-commit script.
2. Export/checkout that version of the repo to that local directory.
3. Update the main WC symlink to point to "WC-${revision}" if it isn't already pointing a later revision.
In this setup you don't have a main WC, just a symlink to the last revision. As this process will only be called by the post-commit hook we're sure that no concurrent calls will happen for the same revision number, so the only point of failure is step 3 (i.e. between reading the symlink, comparing the revision and updating it). Here you could use a file as a lock to prevent problems.
> 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.
The above solution won't give you any delays, other than waiting for the export/checkout to finish.
Daniel Yokomizo.
---------------------------------------------------------------------
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:42:43 2006