Ben Collins-Sussman <sussman@collab.net> writes:
> Well, now I've run into a head-on philosophical collision between the
> way our commit-system works and the way this new access-baton system
> works. :-(
>
> The commit process harvests committable items; every time it finds
> one, it locks the directory. After the commit succeeds, it calls
> svn_wc_process_committed on each committed item, possibly recursively.
> After *every* item is done being loggily 'bumped', it then unlocks all
> the locked directories at once.
>
> So now I've got a legitimate situation whereby two directories, one an
> immediate child of the other, are both locked. (They were both
> committed.) svn_wc_process_commited comes along into the first
> directory (using an existing access baton), writes and runs a log, and
> then decides it needs to recurse. At the bottom of the function is a
> loop over entry-children. This loop tries to obtain a new access
> baton for the child directory, so that it can recurse; bang, failure,
> because the child dir is already locked.
No, it doesn't happen very often. The initial commit processing
removes children. So
$ svn ci foo/ foo/bar/
will only lock foo/ in pre-commit processing.
The one time it does occur is in the copy-modify-commit case. There
is a new regression test in my most recently posted patch that adds
this case to the test suite. The modifications to the locks in that
patch allow them to handle this case without a problem.
>
> Yes, there are many solutions to this problem -- but somehow it means
> coming up with a second kind of lock, or somehow changing our commit
> system. But this isn't trivial stuff. It seems like it would be best
> to reverting the access baton stuff for Alpha, and then jump right
> back on the problem next week.
I would not like to leave the current code in for alpha. I would
prefer to apply my most recent patch or revert what is there.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 15 20:13:19 2002