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

Re: Unresolved conflicts and Update

From: Rob Davies <rob_at_softease.com>
Date: 2004-07-08 18:32:41 CEST

Ben Collins-Sussman wrote:

> On Thu, 2004-07-08 at 10:40, Rob Davies wrote:
>>The problem is that it allows the update, but doesn't modify the
>><filename>.mine file that is still in existence from the previous
>>update. As a result, the .mine file shows code prior to any
>>changes you made since the first update, and can result in code
>>loss via, e.g., TortoiseMerge if you click "Save" before realising.
> That's not true, I just tried to reproduce.
> If a file is in conflict, and has three fulltext files lying around, and
> then you run 'svn up' again and receive *another* conflict, you end up
> with 6 fulltext files lying around. The original '.mine' file isn't
> deleted or overwritten or touched at all; svn just creates a new .mine
> file with a slightly different prefix:


> ...notice that I now have 'eyemodule.py.mine', was was the original file
> before the first conflict, as well as 'eyemodule.py.2.mine', which is
> the file after the first conflict, but before the second conflict. No
> data loss.

Ah! Thanks, Ben... that sheds a little new light on the problem.

Hrm, the difficulty I now have is that both Subversion and
TortoiseSVN are working "correctly", but that Tortoise expects
that any conflicting files will be of the first order conflict
(so <filename>.mine), and so throws *that* filename at
TortoiseMerge, rather than the new .2.mine file.

I'll post this on the TortoiseSVN dev list and see what they reckon.

Thanks for the clarification. :D

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 8 18:31:05 2004

This is an archived mail posted to the Subversion Dev mailing list.

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