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

Re: Improved patch format - SoC

From: Peter Samuelson <peter_at_p12n.org>
Date: 2007-04-02 06:42:57 CEST

[Branko ??ibej]
> No, diff looks at two files. plain 'svn diff" looks at the the file in
> the working copy, and at what that file looked like when it was last
> updated from the repository, e.g., it's most recent "ancestor".
>
> Merge, on the other hand, looks at three files: The file you're merging
> from, the file you're merging to, and the common ancestor of these two
> files. You could say that 'diff3 + patch == merge', but 'diff' and
> 'diff3' don't produce the same results.

No, diff + patch _also_ looks at 3 files: diff looks at 2 files, and
patch looks at a third file. The third file may be the same as the
first file, similar to the 'merge -rHEAD:nnn filename' case.

> I was of course referring to binary diff/patch/merge. Since you can't
> do inexact binary patch/merge in general, it's not useful for code
> exchange, so you might as well not bother with a generic binary diff
> format.

I think the point of supporting binary diffs in a next-gen patch format
is that a single human-readable, human-editable format could serve some
of the same purposes dumpfiles serve now.

> One more thing ... I think it would be a big mistake if we (the
> Subversion project) invented a new diff/patch format ourselves, in
> isolation. We should make an effort to coordinate with other
> projects, like Mercurial, Arch, Git (brrrr....), OpenCM, etc. etc.,

That's been tried before, several years ago when Subversion and Arch
were young, and as I recall, it quickly broke down into a flamewar when
Tom Lord insisted that unique file IDs absolutely _had_ to be supported
(so that diffs to a file can be tracked through arbitrary renames and
merges across multiple repositories) - and several other people saw no
need for them.

All I'm saying is, if you get the distributed rcs people involved again
to design a One True Portable Changeset Format, I wouldn't be surprised
to see the process bog down as everybody attempts to add their own
requirements that have little to do with Subversion. Everybody, that
is, who isn't too busy peddling their own existing patchset formats, of
which I imagine there are some.

Received on Mon Apr 2 06:43:10 2007

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.