Julian Foad wrote on Mon, 10 Mar 2008 at 20:55 -0000:
> Hi Daniel.
>
> I assume you intended this to go to <dev_at_s.t.o>; it looks like a public
> response but for some reason I had to re-add the list address manually.
>
When I send directly to dev_at_s.t.o, it takes half a day to appear.
Sometimes less, if I'm subscribed at the time of sending. I sent the
previous message (and this one too) through gmane to see if it appears
faster this way. They sent me the authorization autoreply after 70
minutes, and the message appeared in the archives shortly after I replied
to gmane's autoreply.
>
> Daniel Shahaf wrote:
>> Julian, all,
>>
>> I am sorry if I appeared to be asking everyone to do my research or
> [...]
>> 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.
>
> No, no, I didn't think that. I must have missed the implication that you'd
> already researched, though. Whatever, it's no problem!
>
Okay,
>
>> 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.
>
> My first thought on your list below is: can you eliminate some of them
> already with a few tests, deductions or Googling? All the ones that cause
> "patch" to throw an error are probably non-starters. For example, can you
> find out whether any common implementations of "patch" exit as soon as they
> try to patch a non-existent file? If any do, you can cross option (1) off the
> list. You already said you can't see option (4) working; I haven't looked at
> the details but assuming you're right you can cross that off the list too.
> How about (2) and (3)?
>
I'm sure that every reasonable implementation of patch will at least warn
on option (1), since (syntactically) it is a valid unidiff. I'm skipping
option (4) as you say.
Regarding (2) and (3): I looked at GNU patch, Sun OS's patch, and
OpenBSD's patch. (I have access to the first two, and read the source of
the last.) They all require unified patches' headers to start with
exactly three '-' or '+' signs (respectively), and they all insist on
(exactly) two @-signs at the start of a hunk header. Except Sun OS's, the
other two also look for a "Index:" or "Prereq:" line in the patch.
GNU patch skips (without user interaction) if the hunk header is changed,
but prompts the user if the target file does not exist or if the diff
header was changed. Sun OS's patch prompts in the first three cases but
not in the fourth (diff header changed). However, if both the diff header
and hunk header are changed:
---- foo1 2008-03-10 23:02:48.975179000 +0200
++++ foo2 2008-03-10 18:29:17.533954000 +0200
%% -1 +1 %%
-foo1
+foo2
then both GNU's and Sun's patch(1)s skip the patch uninteractively (each
for a different reason). (They both print a message that no patch was
found in the input.)
I won't be surprised if some patch(1) out there will parse two or four
+-signs as a legitimate unidiff header. (I didn't search to see if such a
patch(1) implementation exists.) I also did not consider other patch(1)
implementations.
I guess all patch(1)s will ignore a "Property:" header.
Daniel
> Thanks.
> - Julian
>
>
> [...]
>> [ 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 23:23:12 CET