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

Re: Property diffs as unidiff (Issue #1493)

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Mon, 10 Mar 2008 12:05:36 +0000

Daniel Shahaf wrote:
> Part of bite-sized issue #1493 ("Property Diffs/Merges Should Use
> libsvn_diff"; http://subversion.tigris.org/issues/show_bug.cgi?id=1493)
> calls for property diffs to be output as unified diffs. I'm interested
> in implementing it.
>
> The current propdiff output is generated by display_prop_diffs() in
> libsvn_client/diff.c. That function has enough context to generate
> a unidiff (if it called the memory-diff APIs), but if it generated
> a plain unidiff, patch(1) would choke trying (failing) to apply the
> propdiff hunks to a file.
>
>
> The output should be sufficiently different from unidiff that patch(1)
> wouldn't choke, but similar enough that people accustomed to reading
> unified diffs can read it easily. (The change could be as simple as
> s/@@/@@@/g or changing the '---'/'+++' headers; anything patch(1) will
> ignore is good.)
>
> The output format has come up before, and formats were suggested, but
> I didn't see a decision reached. (I could summarise the ideas I found
> in the archives if requested.) However, I want to implement it, and
> I can't complete that unless I know how to format the output.
>
>
> How should property diffs be formatted, in order to be human-readable,
> unified diffs, and ignored by patch(1)?
>
>
> Once the answer is agreed upon, I'll be happy to make a patch to
> implement it. Ideas, comments, pointers from anyone are welcome.

Daniel,

Thanks for your interest and apologies that you didn't get an answer to this
email last month. That would have been just because nobody had an answer to give.

Actually the most useful thing you could do is to choose and propose a format,
showing us how it satisfies these aims. (You'll get a much better response this
way, as it's much easier for several busy developers to quickly read your
proposal and say "Looks good" or "Doesn't work in such-and-such a case" than
for any of them to spend the time needed to research and write up a proposal.)

Look in the email archives for last year's Summer-Of-Code project on creating a
Tree-Aware Diff/Patch Format that can represent any Subversion change including
properties, and see if a format for property diffs was proposed there. If so,
it might be a good choice, or if no conclusion was reached the discussion might
provide some hints.

Thanks.
- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-03-10 13:06:01 CET

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.