Hi Adrian,
On 11/11/2016 12:58 AM, Adrian Parker wrote:
> Hi, I'm not sure if what I'm seeing is expected.
>
> I just made a brand new repository. I've a trunk folder to which I svn add and commit a file (foo.c). I then create a new branch from trunk. I edit line 1 of foo.c in both the trunk and branch, making sure they've different values. I commit that change. Now when I Merge the branch back to trunk I get a tree conflict (as expected).
>
> Repeating the same steps *sometimes* (but not always, it seems random to me) that merge will let me Edit Conflicts during the merge so I can see a side-by-side diff and choose what I want the end result in any given conflicted file to look like.
>
> But other times when I repeat the same steps I get a dialog like you see attached to this message.
>
> This dialog only lets me accept the current working copy, or resolve later. If I resolve later, clicking Edit Conflicts on the file later opens the same dialog you see attached. If I accept the current working copy it seems that all future merges for this file from the branch to trunk ignore the changes that caused this tree conflict.
>
> Short of knowing ahead of time what files between trunk and a branch have edited the same line, how do I resolve this issue with minimal effort?
In such cases I normally select to resolve the tree conflict later,
manually compare both versions of the file (using Winmerge) and merge
the required changes. Afterwards resolve the conflict by using the
working copy version.
Note that you can alternatively already in the first step select to
resolve the conflict using the working copy state and then merge the
changes manually (saving you the separate last step). The later process
only has the slight disadvantage that you loose the list of files to
compare/merge manually (since all conflicts are resolved as merged -
hence when going that way I normally write the files down in Notepad).
> Why on one Merge will it let me edit conflicts, but on another Merge I don't get the Edit/Resolve conflicts option during the Merge?
This should be due to the fact that in one case the tree-conflict got
resolved automatically and you are then only presented with the text
conflict or where the file modifications are only local and not yet
committed to the repository.
There are different situations where you can run into this scenario. For
example:
- You added a file on trunk, created the branch based on that version
and only afterwards modified the content of both files.
- You first created a branch from trunk, then added the file on trunk,
performed a catch-up merge on the branch with trunk and afterwards
edited the files.
- You added the file on trunk, created the branch, modified the file on
trunk, modified the file in your working copy (but didn't commit it yet)
and then perform the catch-up merge with trunk.
...
> If there is a conflict in a file because the same line was edited in both a branch and trunk, then when doing the merge I should always be able to edit conflicts and see the side-by-side diff. Or if I choose "Resolve later" in the dialog presented then doing Edit Conflicts later should show the side-by-side diff (but it doesn't).
As far as I'm aware the situation boils down to limitations in SVN <=
1.9 of tracking/handling deletes/moves/renames. In theory the behavior
you describe here is what I'd expect too, but the internal design of SVN
doesn't handle this yet. There's some development going on in 1.10 which
hopefully will improve the situation and get closer to the behavior we
all would like to see.
--
Regards,
Stefan Hett
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3193501
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2016-11-11 11:51:07 CET