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

Re: summer of code 2007

From: David Anderson <dave_at_natulte.net>
Date: 2007-03-13 18:17:15 CET

On 3/13/07, Malcolm Rowe <malcolm-svn-dev@farside.org.uk> wrote:
> 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)

Uh, the output of `svn diff` can be applied with GNU patch. I do that
all the time. It's not perfectly identical in formatting and general
looks to GNU patch, but the unified diff does apply fine.

> 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.

Given the above, I'd keep `svn diff` outputting patch-compatible files
(which can be augmented to carry extra metadata: the unified diff
format ignores stuff it doesn't recognize, and that characteristic is
used by SVK to add extra metadata), and have a flag output another
format, if we decide we want one.

Then, `svn patch` applies either unified, unified+augmented tacked on
metadata, or this "another format". GNU patch still applies the first
and second quite happily.

- Dave

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 13 18:17:30 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.