kfogel@collab.net wrote:
[snip]
> This is very interesting, that we need the (exclusive) write lock to
> copy the locks tree. Nothing else in svn_fs_fs__hotcopy requires the
> write lock, and I wonder if that fact shouldn't be considered part of
> the design requirements -- or at least the design recommendations.
>
> Is the write lock absolutely necessary? Or, if it is currently
> necessary, might there be some way we can change the way locks are
> written out, such that we can lose the need for the write lock here?
>
> Bleargh -- too many meanings of the word "lock" running around, but
> hopefully the above was clear.
>
> -Karl
Thanks for the review -- I'll clean it up. Is there a code style
analyzer/tool that would help me catch these for Subversion's style? I
believe I know the style guides, but since it's different than my work's I
keep slipping and have a hard time seeing them even when looking right at them.
Previously, I did think the write lock was necessary due to it being
implemented with multiple files -- but re-reading the code again, I don't
think so. The lock files are written out in child-first order and separated
by path elements. Even if the hotcopy grabs some locks-in-progress or
unlocks-in-progress, it should be fine. Thanks for the sanity check -- I'll
remove the write lock.
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 11 07:36:40 2005