[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: Daniel Shahaf <d.s_at_daniel.shahaf.co.il>
Date: Mon, 10 Mar 2008 19:52:10 +0200

Julian, all,

I am sorry if I appeared to be asking everyone to do my research or write
up my proposal. That was not my intention, and I had done the research
(and most of the proposal) before I posted. I said in the original email
that I had already done the research (albeit it was hidden in masses of
text).

On the other hand, I assumed an attitude of "Hi. You've never met me
before, but this is how I think this bug which has been open for years
must be fixed." would not yield a positive response. (And I was right
expecting a miscommunication ;)

Hence I chose the middle way (not post the research right away, but
indicate that I had already done it and was willing to post it). I'll
know what to do next time, however -- thanks for correcting me.

Back to technical topics, now.

Charles Acknin wrote on Mon, 10 Mar 2008 at 14:40 +0100:
> On Mon, Mar 10, 2008 at 1:05 PM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
>> 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.

As Charles says, the new patch format will not include human-readable
property diffs. As you (Julian) suggest, I list below several proposed
formats, some mine and some from the archives.

>
> Well I can tell right away that the work that's been done wrt the new
> patch format during last year's GSoC is not what Daniel is looking
> for. Indeed, the new patch format was designed to serialize any
> change of a tree and make it *transportable* between working copies
> (as opposed to visually readable for code review) for later patch
> application.
>

[ not in any particular order ]

1. Using bogus filenames.

      Index: some/path/trunk/svn:ignore
      --- some/path/trunk/svn:ignore
      +++ some/path/trunk/svn:ignore
      @@ -1,2 +1,2 @@
       Makefile
      -*.O
      +*.o

This format would mislead patch(1) into attempting to patch nonexisting
files. No harm done, but being ignored by patch(1) would be better.

2. Change the diff header:
Drop the '---'/'+++' headers and rename the 'Index:' header. [1]

      Path: some/path/trunk
      Property: svn:ignore
      @@ -1,2 +1,2 @@
       Makefile
      -*.O
      +*.o

The hunks are unchanged, only the diff header is. Further tweaks to the
header are possible, for example:

      Property: svn:ignore (on 'some/path/trunk/')
      ----- svn:ignore some/path/trunk/
      +++++ svn:ignore some/path/trunk/
      @@ -1,2 +1,2 @@
       Makefile
      -*.O
      +*.o

The format originally proposed in [1] is:

      Index: foo/bar.c (property 'svn:keywords' changed)
      ======================================================
      @@ -0,3 +0,3 @@
       Date
      -Revision
      +Id
       Author

(In my testing, patch(1) happily applied patches with 'Index:' but
without '---' and '+++' lines. It seems necessary to tweak all
three indicators.)

3. Change the hunk headers:
Use '@@@' instead of '@@'.

      Property: svn:ignore
      --- some/path/trunk/
      +++ some/path/trunk/
      @@@ -1,2 +1,2 @@@
       Makefile
      -*.O
      +*.o

The reverse of the previous option. My patch(1) ignores it:

      % diff -u foo1 foo2 | sed s/@@/@@@/g | patch
      patch: **** Only garbage was found in the patch input.
      % diff -u foo1 foo2 | patch
      patching file foo1
      %

Using a different character than '@' should have the same effect:

      Property: svn:ignore
      --- some/path/trunk/
      +++ some/path/trunk/
      %% -1,2 +1,2 %%
       Makefile
      -*.O
      +*.o

4. Tez Kamihira's draft changeset format [2] includes property diffs
in a hunk titled "@@ properties: @@".

I do not see how this format scales to multi-line properties. It gives
the following example, which seems to assume that all properties are
one-lined. (For example, it does not allow one property's diff to have
multiple hunks.)

However, I have not read the proposal fully.

       ---- ./foo.txt 2005-05-23 10:58:17.583015024 +0900
       ++++ ./bar.txt 2005-05-23 10:59:12.976593920 +0900
       @@ id: i_abc @@
       @@ -1,3 +1,4 @@
        aaaaaaaaaa
       +bbbbbbbbbb
        cccccccccc
        dddddddddd
       @@ properties: @@
       -zzz: xxx
       +zzz: yyy

[end of proposals]

Most of the ideas in options (2) and (3) are orthogonal, and may be used
independently of each other.

Daniel

[1] http://svn.haxx.se/dev/archive-2006-05/0884.shtml and thread
[2] http://svn.haxx.se/dev/archive-2005-05/1255.shtml

---------------------------------------------------------------------
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 20:10:44 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.