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

RES: Re: flag to disable hook scripts

From: Daniel Yukio Yokomiso - SAO <Dyokomiso_at_sao.politec.com.br>
Date: 2006-02-03 21:38:30 CET

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

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