On Tue, Feb 26, 2008 at 3:21 PM, Chris Rose
<chris.rose_at_messagingdirect.com> wrote:
> I'm interested in tackling this issue, but there's a lack of explanation
> in commit.c as to why we need to lock the parent directory at all.
>
> To clarify, here's my scenario:
>
> We often have checked out working copies that are checked out into a
> non-wc directory. They all come from the same repository, however, and
> therefore it should be reasonable that we could commit changes in more
> than one of them in one commit. So, this appears to match the issue in
> question.
>
> What I'm not sure of is _why_ we lock the parent directory at all; it's
> clear that it's happening, it's just not clear why or what we need to do
> with it. It seems to me that once we have a set of targets, if they
> _do_ live inside other working copies it makes sense to lock those, but
> if they do not then it's not necessary. Am I correct in this assumption?
>
> So, my proposed change would be to build a list of candidate base dirs
> instead of a single one, and lock those that have a working copy
> administrative area, ignoring the ones that don't.
>
> Assuming this to be the case, I believe that the commit_test.py test #
> 25 verifies this, so I just need to reverse the test case on it to
> validate a positive test.
>
> Opinions?
My kneejerk reaction is that I'm hoping for future Subversion working
copies to be more discrete than current ones, not less so, and my
design goals for a WC rewrite would be to explicitly disallow
multiple-WC operations. So I'm not inclined to focus too much on
making multi-WC operations work better... But that may just be me.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-27 00:36:50 CET