Unresolved conflicts and Update

[Rob Davies <ro...@softease.com>]

I haven't managed to find anything on this in the list archive,
so either it ain't there or I'm plugging in the wrong keywords. :]

There seems to be a problem with Subversion (1.0.4 r9844)
regarding Updating a file that is currently marked as "Conflicted".

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.

Would it be possible to have Subversion refuse the update of an
unresolved file, or update the .mine file to the current state of
the file (potential dangerous, former would likely be a better idea)?

Or, alternatively, if I've missed something, could someone please 
advise? :)

Thanks,

Rob.

P.S.: In case it helps, the working copy is running on NTFS on a 
WinXP Pro machine (there're no problems with file or security 
permissions, though, to prevent an update to the .mine file).

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Unresolved conflicts and Update

[Stefan <st...@tigris.org>]

Rob Davies wrote:

> [snip]
> 
>> ...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.

Hmmm - TSVN uses the svn_client_status() API function to get the paths 
to the conflicted files. The question is now if that API function should 
return the paths to the new files or to the old ones...

Those paths I'm talking about are returned in the status struct
status->entry->conflict_new
status->entry->conflict_old
status->entry->conflict_wrk

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

I'm reading this list too ;)

Stefan



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Unresolved conflicts and Update

[Rob Davies <ro...@softease.com>]

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:

[snip]

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


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Unresolved conflicts and Update

[Ben Collins-Sussman <su...@collab.net>]

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