[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: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-07-08 18:06:10 CEST

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:

$ svn st
? eyemodule.py.r2
? eyemodule.py.r3
? eyemodule.py.r4
? eyemodule.py.2.mine
? eyemodule.py.2.r3
? eyemodule.py.mine
C eyemodule.py

...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.

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:07:23 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.