On 4/1/07, Branko Èibej <brane@xbc.nu> wrote:
> Nicolás Lichtmaier wrote:
> > == Introduction ==
> >
> > The diff/patch tools have been great tools. The format they use
> > (called "unified diff")
>
> Correction: "unified diff" is in fact a later addition to the set of
> diff formats (the original diff didn't have it), and is by no means
> universally accepted as "the standard". IIRC the GCC project, for
> example, insists that patshes be submitted in context-diff, not
> unified-diff format.
Nope.
"If you are accessing the SVN repository at gcc.gnu.org, please
configure your svn to use GNU diff and generate patches using the
"-up" or "-c3p" options. "
We've found some people like unified, some people like context, and
almost everyone likes one or the other better for different
circumstances.
>
> [...]
>
> > Just as Subversion took the best of CVS concepts and created a better
> > version control system, we should take this format and enhance it so
> > that it can serve Subversion needs. Those new needs are three:
> >
> > * The ability of describe tree modifications (renames, deletions, etc.),
>
> This is more complicated than it looks, if you insist on compatibility
> with current diff/patch. Diff is file-based, whereas tree modifications
> are not.
>
> For example, patches are separable: you can take a patch which contains
> diffs of several files, split it apart, and apply each file's hunk
> separately. When you add tree-modification metadata to such patches,
> this is (in general) no longer true; and to be safe, a patch program
> that accepts such an enhanced diff format should be able to warn you
> that you're missing some tree modifications when you apply a patch.
>
> I certainly don't know how to do this by simply extending, e.g., unidiff.
1. include the tree modifications as a whole (IE a block that cannot
be split, such as just a base64 blob.
2. include a checksum of the entire patch at the beginning of the tree
mod section (which would appear like a comment/unrecognized hunk to
regular patch).
3. If the patch checksum doesn't match, something has munged with it
or you are missing data.
> [...]
>
> > * The patch should convey all the meaning implied in a 'svn merge'
> > operation that is considered reasonable. A patch should be like
> > tearing the merge action into two steps, i.e.: 'diff + patch = merge'.
>
> diff + patch != merge
>
> I don't know how that misconception came about, but merge typically
> looks at three sources, not two (and note that there's a prototype 4-way
> merge in Subversion's source tree).
>
> If you want a format that can convey all the meaning of a merge
> operation, then I thing you're better off breaking compatibility with
> the current format.
Why?
All you need to know are the parents.
>
> [...]
> > * Support for binary diffs. Binary diffs would just be diffs created
> > with the binary diff algorithm already present in subversion, and then
> > encoded in base64 to get a text representation. The algorithm name
> > should be stated to allow for change in the future.
>
> This one is tricky. The fundamental reason for the success of the
> diff/patch pair is that the most common diff formats contain enough
> context to allow inexact patches.
I seriously disagree with this statement. The fundamental reason for
success of diff/patch, is, IMHO, that it is easy to transport, and
still readable in it's basic form. So you can send them to people and
they can tell what you are doing to the file with only a minimum of
understanding of the format.
> [...]
>
> To sum up: To do what you propose, you'd have to first invent theory
> that I at least haven't seen yet. I don't think this project is suitable
> for a two-month summer hack ...
>
I do believe it is. Nobody says we have to have a perfect result. We
simply want something that is useful in 90% of the cases, to 90% of
our users.
I don't believe you have to *invent* anything to do that, it's already
done by others.
Received on Tue Apr 3 05:51:19 2007