So now we have this new conflict system:
* If diff3 can't merge successfully, then copies of all three
fulltexts (old-textbase, new-textbase, working) are dropped into
the working directory. The working file gets conflict markers.
The only way to tell SVN that you've resolved the conflict is to
remove the three fulltext files (and 'svn resolve' is a shortcut
for that.)
But there are two long-standing behaviors that we've had for a year or
longer:
* If properties can't merge successfully, create a .prej file that
describes the conflict. Again, you have to either remove the
.prej or run 'svn resolve' to signal that the conflict is fixed.
* If the file is some binary type, don't attempt a contextual merge.
Instead, move the locally-modified working file off to the side,
and install the new file from the repository.
It's this last bullet-point that I'm calling into question now. In
the case of binary files, we're actually *losing* information at the
moment. After the update, the user has fulltexts of new-textbase and
working, but old-textbase is completely gone. (And binary files seem
to necessitate the use of 3rd-party 3-way-merge tools much more often
than text files, e.g. the MS Word Merge tool.)
Karl and I had a chat about this, and think this should be changed.
The locally-modified working file shouldn't be touched at all;
instead, the old and new fulltexts should be copied out for
examination. So then our binary situation is *almost* like our text
situation: all three fulltexts are present after the update.
So here's my final question: should we now put the binary file into a
'conflicted' state, and track the fulltexts as usual?
* argument against: it's not conflicted. we didn't even attempt to
do a merge. how would we even know what a conflict looks like?
* argument for: a conflicted state would force the user to
recognize that his locally-modified working file is incomplete;
we don't want to encourage people to ignore patches from the
server, just because the patches aren't automatically merged.
I think I'm advocating the conflicted state here, but I wanted to see
what others think, as a sanity check.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 15 16:49:56 2002