[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Merge Conflit Incoming Delete, Local Edit on Merge

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Tue, 17 Sep 2013 20:28:02 +0200

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

-- 
        ___
   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=3064732
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2013-09-17 20:28:24 CEST

This is an archived mail posted to the TortoiseSVN Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.