On Tue, Mar 13, 2007 at 05:57:31PM +0100, David Anderson wrote:
> Yes, an augmented diff representation would ideally store information
> about both structural changes (directory add/remove...) and metadata
> tweaks. In my perfect world, this augmented representation would be
> backwards compatible with the unified diff format, in much the same
> way that SVK does it: by tagging on some extra data that GNU
> diff/patch politely ignore, but that convey extra information for
> readers who understand it. That doesn't prevent coming up with another
> format that might be more readable and whatnot, but imo backwards
> compatibility with GNU diff/patch for the basic delta information is
> important.
>
Personally, I think that sticking with patch's format is more of a
crutch than anything else. In particular, I'd like to introduce a
specific 'patch-compatible' output format for diff that e.g. represents
file copies as diffs from nothing rather than diffs from the copyfrom
source, since the latter, while good for review, doesn't actually give
you output that works with patch(1)
Since we're talking about perfect worlds, mine includes three different
patch outputs:
1. 'svn diff', for reviews.
2. 'svn diff --format=patch', for producing something we can apply with
patch.
3. 'svn diff --format=svnpatch', for producing something we can apply
with a hypothetical 'svnpatch' tool. There's no reason this can't be
human-readable and use unified diffs as well.
(We only produce #1 today)
It may be that #1 and #3 can be the same format: we'd either need to
replicate the human- and computer-readable parts of the tree-delta,
or make the hypothetical svnpatch tool read the human-readable parts.
> However, you're more than welcome to apply for the augmented diff
> representation task, and either convince us that patch management
> should be in the svn core, or develop a streamlined patch manager as a
> separate tool. In any case, having a diff representation that can
> contain all the information on all kinds of changes svn can make is a
> prerequisite.
>
+1, with the emphasis on the last sentence.
Regards,
Malcolm
- application/pgp-signature attachment: stored
Received on Tue Mar 13 18:31:06 2007