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

Binary file diff (was Re: Roadmap for 1.1)

From: Shawn Harrison <harrison_at_tbc.net>
Date: 2004-04-02 21:05:48 CEST

----- Original Message -----
From: "Sander Rijken" <sr@sander.yi.org>

> Binary files aren't neccesarily unmergable, with the right merge
> program, some binary files can be merged. So what we need is a 'word
> diff' program

Word has "compare documents" built into it, which works extremely well for
comparing a revised document with the original. But the corresponding "merge
documents" is horribly broken: Rather than marking conflicts as conflicts
for the editors to resolve (which would be the sensible thing to do), it
tries to be smart and succeeds only in making an unmitigated mess out of any
document that is merged from two or more revisions. This fact creates quite
a nice amount of work for freelance editors at our publishing house: Merging
revisions is not particularly difficult, but it does currently require a
human being with a little training. (Maybe it's just as well that it needs a
person, given the job situation in the economy....)

Other types of binary files cannot be expected to be merged by any automated
process. For instance, how would you merge two different graphic designers'
work with graphics files or page layouts? Perhaps there is a way to do
comparisons and mark conflicts, but for non-textual information I don't see
how to do it. So there really is a need for the option to have at least
advisory locks.

In fact, advisory locks would be more than sufficient: This is how cvs watch
works, yes? (Query: Does CVS watch change a property of the repository or
only of the working copy? It would make sense to me to have a property of
the repository files.) This fits with the philosophy that users should be
smart rather than stupid and should be allowed to hang themselves if they
don't think. It wouldn't take too long for the newbies to figure it out, and
would provide a source of entertainment for the more experienced team
members --- kind of a hazing process for new members.

OTOH, I don't suppose that executives would appreciate being hazed. So maybe
lock enforcement, as a property of the repository, is eventually needed. But
I would make it a lower priority than the sort of advisory locking that CVS

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 2 21:06:17 2004

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.