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

Re: svn commit: r14678 - in trunk/subversion: libsvn_fs_fs tests/clients/cmdline

From: D.J. Heap <dj_at_shadyvale.net>
Date: 2005-05-11 07:35:51 CEST

kfogel@collab.net wrote:
> 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.


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

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.