Jon Daley wrote:
> On Tue, 10 Jul 2007, Graham Bloice wrote:
>> In all the subsequent testing I've done, TortoiseMerge removed the
>> conflict
>> markers from the file. However, the user in question managed to
>> commit with
>> them still in place.
> Interesting. I guess I haven't used TortoiseMerge enough - what
> does it do when it removes the markers? ie. it leaves both sets of
> changes in, just takes one? It doesn't seem like it could do the right
> thing there. I thought "mark as resolved" ran "svn resolved" on the
> file, which means it does absolutely nothing to the file in question,
> just changes its status, and removes the extra files.
OK, I looked at this some more with both 1.4.3 and 1.4.4 which behaved the
same on Win XP.
The issue was identical whitespace changes made on both the trunk and the
branch. When the merge back from the branch to the wc of the trunk was done,
svn flagged a conflict, but TortoiseMerge, when set to "Ignore all
whitespaces" did just that, and didn't display the conflict. When the "Mark
as resolved" button was clicked, TM automagically decided that the identical
whitespace changes weren't really a conflict so removed the conflict markers
from the file.
To recreate:
1. In the "trunk" create a file that has the following four lines, with some
trailing spaces after the second one:
Line 1, a lead in
Line 2, with some trailing spaces
Line 3, with the number 1
Line 4, a lead out
2. Commit this, then branch the trunk.
3. In both the branch and the trunk, modify the file to remove the trailing
spaces from line 2. In the branch only, change the number at the end of line
3. Commit the changes.
4. Merge the changes from the branch into the trunk wc.
5. Use TortoiseMerge to Edit the conflict. Set TM to "Ignore all
whitespaces" and the conflict will be hidden. If you examine the file you
will see conflict markers around both lines 2 & 3.
6. Click on "Mark as resolved" and the conflict markers will be removed.
Now I understand what's going on I'm a little happier.
Q1. I'm still unsure about the behaviour of TM hiding a conflict, although if
the user has set it to ignore all whitespaces, what should it do when there is
a whitespace conflict?
Q2. I'm also a little mystified by the actual items marked as conflict in the
first place by svn. Sure the line was changed in both trunk and branch by
separate revisions, but the resulting line was identical, so why a conflict?
Q3. In addition, why did the conflict markers extend around the next line,
which was changed only in the branch.
I'll follow up with the last two questions on the svn list.
Regards,
Graham
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org
Received on Wed Jul 11 16:29:33 2007