On Nov 9, 2005, at 22:28, Phil Endecott wrote:
>> I would definitely recommend spawning off another process
>> somehow, but simply "svn update &" may be too simplistic. If Bob
>> commits r100 at 12:00:00 and the svn update process gets spawned
>> at 12:00:01 and takes 10 seconds to complete, and Joe commits
>> r101 at 12:00:02 firing off another svn update process at
>> 12:00:03, then Joe's update process will probably throw an error
>> that the working copy is in use / dirty / whatever it says
>
> If the update instead waited for the working copy to be unlocked,
> rather than failing immediately, there wouldn't be a problem.
The exact message printed if you try to update a working copy twice
simultaneously is this:
svn: Working copy '.' locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
details)
The point is that a human must decide if it is appropriate to run svn
cleanup. It is not appropriate if there is another task updating the
working copy. It is appropriate if there merely was another such task
and it has crashed or terminated improperly.
If, as you suggest, svn update simply waited for the working copy to
be unlocked, it would wait all day if the previous update in fact had
a problem.
> Is this an issue only when the hook script is backgrounded, or does
> it also appy in the normal case?
I do not know how Subversion handles the timing of the situation
where two people try to commit different changes at about the same
time. I have a hunch that Subversion handles only one commit at a
time, so the problem would not exist if you did not background the task.
> Is there a lock somewhere that is not released until the post-
> commit hook has finished? I had assumed that the locks were
> released at the point of commit.
I'm talking about locks relating to the working copy, not the
repository. Whenever you say svn update (and probably other svn
commands), the working copy is locked to prevent another process from
trying to work on the same working copy. When the first task is done,
it's supposed to unlock the working copy again.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 10 16:04:20 2005