On Wed, Feb 4, 2009 at 6:38 PM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> On Wed, 2009-02-04 at 16:36 -0500, Mark Phippard wrote:
>> At a minimum this is a bug. When it is working I suspect the behavior
>> will be unexpected, but at least explainable. I am attaching script,
>> but let me explain. We stumbled on this testing Subclipse tree
>> conflict resolution work.
>>
>> Suppose you delete a folder that has child folders. Do not commit
>> yet. Now commit the delete of one of the children, but not the
>> parent. The parent is now out of date, so it cannot be committed, so
>> you update. This creates a tree conflict (the unexpected part)
>> because the parent has to be updated but it is scheduled for delete.
>> The bug is that the update of the folder is skipped so you are in the
>> issue-3334 "loop" where you cannot commit the folder because you
>> cannot update it.
>>
>> I tried this with the issue-3334-dirs branch and it still fails. Here
>> is the output:
>
> Mark,
>
> What version of the issue-3334-dirs branch did you use? I ask because I
> saw some code in Paul's commits today that specifically looks for cases
> where the only "edits" are deletes of children, and treats those as
> different from other "edits" of a directory tree. Maybe that code is
> meant to handle this case.
>
> - Julian
Julian,
That change I made in r35667 fixed the case where we have an incoming
tree delete, but some paths under that tree with local edits.
The problem Mark is seeing is where the tree delete is *local* and the
incoming edits are under that tree. I think this is fundamentally the
same problem I am talking about here:
http://svn.haxx.se/dev/archive-2009-02/0065.shtml and that solving
that will solve Mark's problem.
Paul
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1107940
Received on 2009-02-05 16:43:42 CET