[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: Charles Acknin <charles.acknin_at_gmail.com>
Date: 2007-03-13 18:52:55 CET

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

Right, why not having one single 'svn diff' that outputs one single
rich-format that is backward compatible with patch(1)? What's the
point of having one more "other format" if the rich-format fulfills
patch(1) and 'svn patch' needs?
It seems quite easy to extend unified-diff format to subversion needs
as patch(1) ignores any noise it can't understand. All that's left is
to define/design the format, isn't it?

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

That works too.


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:53:14 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.