Chris Rose 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.
I hardly know how this WC stuff works but here's my thoughts until you hear
from someone who knows better:
I would expect that we need each file target to be in a parent WC directory
that is locked, whereas each directory target only needs to be locked itself
and it doesn't matter about its parent directory. If any of these directories
that you need to lock isn't a WC (doesn't have a working copy administrative
area), that's an error, not to be ignored.
> 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.
Yes, I'm pretty sure that's right. That test #25 ("attempted commit from
multiple wc fails") actually tests commits from two WCs one of which is inside
the other, which is an allowable scenario. It would be good also to test two
WCs that are not nested, to be sure that works as well.
- Julian
---------------------------------------------------------------------
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 15:43:42 CET