Karl Fogel <kfogel@newton.ch.collab.net> writes:
> As for revs 2452, 2470, and 2504: I'm leaning toward reverting them
> for Alpha.
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.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 15 19:54:02 2002