Re: Merge Conflit Incoming Delete, Local Edit on Merge

On 17.09.2013 20:51, Bob Archer wrote:
>> -----Original Message----- From: Stefan Küng
>> [mailto:tortoisesvn_at_gmail.com] Sent: Tuesday, September 17, 2013
>> 2:28 PM To: users_at_tortoisesvn.tigris.org Subject: Re: Merge Conflit
>> Incoming Delete, Local Edit on Merge
>>
>> On 17.09.2013 19:41, Bob Archer wrote:
>>> I am doing a merge and the following condition occurs. Here are
>>> the docs for this:
>>>
>>> 4.6.3.5. Local edit, incoming delete upon merge
>>>
>>> 1. Developer A working on trunk moves Foo.c to Bar.c and commits
>>> it to the repository. 2. Developer B working on a branch modifies
>>> Foo.c and commits it to the repository.
>>>
>>> There is an equivalent case for folder moves, but it is not yet
>>> detected in Subversion 1.6 ...
>>>
>>> 1. Developer A working on trunk moves parent folder FooFolder to
>>> BarFolder and commits it to the repository. 2. Developer B
>>> working on a branch modifies Foo.c in her working copy. A merge
>>> of developer A's trunk changes to developer B's branch working
>>> copy results in a tree conflict: . Bar.c is marked as added. .
>>> Foo.c is marked as modified with a tree conflict.
>>>
>>> Developer B now has to decide whether to go with developer A's
>>> reorganisation and merge her changes into the corresponding file
>>> in the new structure, or simply revert A's changes and keep the
>>> local file.
>>>
>>> To merge her local changes with the reshuffle, Developer B must
>>> first find out to what filename the conflicted file Foo.c was
>>> renamed/moved in the repository. This can be done by using the
>>> log dialog for the merge source. The conflict editor only shows
>>> the log for the working copy as it does not know which path was
>>> used in the merge, so you will have to find that yourself. The
>>> changes must then be merged by hand as there is currently no way
>>> to automate or even simplify this process. Once the changes have
>>> been ported across, the conflicted path is redundant and can be
>>> deleted. In this case use the Remove button in the conflict
>>> editor dialog to clean up and mark the conflict as resolved.
>>>
>>> If Developer B decides that A's changes were wrong then she must
>>> choose the Keep button in the conflict editor dialog. This marks
>>> the conflicted file/folder as resolved, but Developer A's changes
>>> need to be removed by hand. Again the log dialog for the merge
>>> source helps to track down what was moved.
>>>
>>> -----
>>>
>>> The help seems to talk about a move rather than an edit not a
>>> delete.
>>>
>>> I am in the check for modifications dialog and the conflict is
>>> listed with a status of normal, tree conflict. Ok fine. I know
>>> why this is a conflict, because the incoming merge deletes this
>>> file that was editing in the target path. The doc seems to imply
>>> that the edit conflicts dialog will have a "remove" button. There
>>> is no such button... There is only "Accept current working copy
>>> state (mark as resolved)", "Resolve Later", "Show Log", "Show
>>> Branch Log".
>>>
>>> So, I'm not sure what action I need to take from the CFM dialog
>>> to tell TSVN that the correct action is to delete the file which
>>> is what the incoming merge was. If I select "Resolved"... it
>>> appears that the local working copy file stays in place. This is
>>> what I have done, then going back to the working copy and TSVN ->
>>> Deleting it? Is this correct? It seems there should be an action
>>> I can take in the CFM or Merge dialog to confirm the delete is
>>> the correct status?
>>
>> Yes, marking the conflict as resolved and then deleting it is the
>> correct way to resolve this the way you intend.
>>
>> I'm investigating why the remove button does not show...
>>
>> Stefan
>
> Thanks. It seems if I also chose "Delete..." in the CFM dialog it
> does the same thing. I figured it would still show as conflicted if I
> did that.

Well, took me longer than it should have: the reason the "delete" button
isn't there is that the only way to automatically resolve a tree
conflict is to accept the working copy state - any other resolve results
in an svn error.

Maybe in svn 1.9 this will get better, but for now you have to resolve
this manually.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest interface to (Sub)version control
    /_/   \_\     http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3064739
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].