[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Merging branches with identical binary files

From: Karl Fogel <kfogel_at_red-bean.com>
Date: Wed, 04 Jun 2008 11:37:31 -0400

"Dominik Ruf" <dominikruf_at_googlemail.com> writes:
> I have just tried to merge 2 branches with some identical binary files.
> Subversion says that there is a conflict between each of the 2 files.
> This forces me to check if they are really identical which would be
> unnecessary if subversion would realize that they are equal.
>
> Is there a cogent reason why these files are treated as conflicts.

This is a deep question. Consider the following scenario:

On branch B1, we make several edits to file B1/F that result finally in
a state F(S). On B2, we make a completely *different* set of edits,
many of which individually would conflict with edits on B1/F, but in the
end it all leaves B2/F in state F(S) as well.

When you merge from B1 to B2 (or vice versa), what should happen?

It's odd to say that B1 now "has" all of B2's edits, or vice versa. Yet
the final result is the same, and I think most users would want & expect
the merge to succeed, since the file content is the same.

You don't say what version of Subversion you're using, or what client.
In Subversion 1.5, there is an interactive conflict resolution
mechanism. In future releases, maybe we should make that interface tell
the user that the files are the same, to save time. Or maybe we should
make allowing the merge the default, with a configuration option to
disallow and fall back to conflict resolution.

Thoughts?

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-06-04 17:38:11 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.