RE: Strange behaviour with confilcting binary files

That's the expected behaviour actually. Automatically merging a binary
file almost never produces useful output. Hence you need one less file
to resolve the conflict, since you are going to have to do it manually.
I agree, the docs should probably be updated.

Glenn McAllister
Sr. Associate, Technology, Canada| Sapient

277 Wellington Street West
Toronto, ON M5V 3E4 Canada
desk: +1.416.645.1543
mobile: +1.416.873.6666
fax: +1.416.645.1501
e-mail: gmcallister@sapient.com

-----Original Message-----
From: jcn [mailto:jcn@maxnet.co.nz]
Sent: Wednesday, September 01, 2004 6:24 AM
To: users@subversion.tigris.org
Subject: Strange behaviour with confilcting binary files

G'day All,

I'm seeing unexpected behaviour when a conflict occurs with binary files

with svn 1.1.0 rc2 (running at home on Win2k)
I've got the same bevaiour at work, where we are running a different
version, not sure which 1.06 or something i think..

 From looking at the documentation if a conflict occurs when updating 3
new files should be created and i should have a total of 4 version of
the file in the directory after the update.

file - working copy contatining the conflict flags
file.mine - my working copy
file.rOldRev - the base revision
file.rNewRev - the new file from the repo

It seems that svn does not create "file.mine" when encountering binary
files.
The working copy remains the same. I guess its because the merge logic
encounters binary data and doesn't quite know what to do.

Is this by design? There isn't any mention of it in the docs, i've tried

search on "conflict" and "binary".

The reason it has com to my attention is that i was writing a little app

that handles conflict / merging of word documents using words compare
merge features. Following the docs i had expected "file.mine" to be
there. I can certainly work around it as the working copy seems to end
up being what "file.mine" should be, but too me it would be more
consistent with the text file behaviour if the bianry working copy was
renamed "file.mine" and the working copy "file" disappeared.

I've managed to duplicate this behaviour using both the svn command line

client and tortisesvn.

Any feedback appreciated.
jcn

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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Sep 1 17:46:06 2004