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

Re: Subversion 0.7 released.

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2001-12-04 19:10:11 CET

Por Favor, please keep the dev list cc'd on discussions like this. :-)

Billy Tanksley <btanksley@hifn.com> writes:

> From: Ben Collins-Sussman [mailto:sussman@collab.net]
>
> >One last comment: the binary heuristic is necessary to *prevent* the
> >munging of working copy data. If Subversion doesn't see a 'binary'
> >property attached to a file, it will attempt to run 'diff' and 'patch'
> >when merging changes during an update. If it sees the 'binary'
> >property, then it simply places the two files side-by-side: one from
> >the repository, and the one with your local mods.
>
> Two points.
>
> First, note the difference between 'binary' and "don't mess with my
> newlines". The two shouldn't be intertangled.

They're not necessarily tangled. If user wants newline substitution
in a binary file, they should be able to specify that. But I think
SVN should try to avoid that combination by default.

>
> Second, this is a purely implementational problem in CVS and
> possibly Subversion. I would recommend that it be one of the CVS
> quirks we fix, just as we fixed renames, directories, versions, and
> tags. There's no reason at all why Subversion should be unable to
> merge a file simply because it has zero bytes in it. This isn't RCS
> anymore. The one reason why Subversion shouldn't be able to merge a
> file (binary or not) is because the differences are too big -- and
> the user shouldn't have to tell Subversion that (and the user
> wouldn't have any useful input anyhow; it's purely an internal
> matter).

I think you're mixing up two ideas here.

When Subversion knows *exactly* what the source and destination files
are supposed to look like, it uses nothing but 'binary' patching. It
sends binary diffs over the network, and uses them to reconstruct
files on both ends. In that sense, we're already more efficient than
CVS.

But the scenario I was originally talking about is different: I'm
talking about *contextual* patching. This is the situation where I
have local mods on a file, I run 'svn up', and the server wants to
"merge" in some more changes without blowing away my own. This is
doable by the 'patch' program, and only because the patch format is
contextual and line-based.

That's why the binary-property is needed. Unless the svn client is
aware that a file is binary, it assumes it's okay to attempt
contextual merging. The binary-property toggles this behavior.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:51 2006

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

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