Re: Issue #2381 - Cannot commit multiple WC paths which lack a common parent directory

Julian Foad wrote:
> 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.

That's my belief, as well, but I'm glad to hear someone echo it. At a
guess I'd say that what needs to happen in there is that a more minimal
lock target set should be sussed out.

Unless someone can tell me why a directory being committed might
required its _parent_ to be locked iff that parent is a working copy?

>> 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.

That's what's going on in that test! I see, now.

I'll admit, the python test suite leaves me crosseyed in confusion; I
see all kinds of references to 'A' and so forth. I might end up doing
it all by hand, sadly.

> - Julian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: dev-help_at_subversion.tigris.org
>

-- 
Chris Rose
Developer    Planet Consulting Group
(780) 577-8433
crose_at_planetci.com