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
Received on Wed Sep 1 17:07:36 2004