On Mon, Feb 13, 2006 at 03:27:00PM +0000, Julian Foad wrote:
> I don't get the result you describe from this part of your script. Here's
> what I get:
>
> >+ svn diff -r0 wc
> >Index: wc/foo
> >===================================================================
>
> Do you think that shows "the addition of an empty file"?
Yes, I do. Consider what the patch format would look like for a new file
that has no changed hunks compared with the empty file. (Also q.v. 'touch
foo; svn add foo; svn diff').
Also see the comment in libsvn_client/diff.c:diff_file_added() that
suggests that 'patch' should treat it as an added empty file, though I
couldn't seem to get that to work when I tested it.
Howver, it doesn't really matter whether we agree on what it represents,
because:
> I don't think this is a good output; I think it
> is silly to output a header without some further indication of what
> happened.
>
I agree; see r18630 for the result.
> >+ svn diff -r0:BASE wc
> That one is not empty, but is correct, I think.
Yes - it was broken in 1.3.0, which is what I was basing my comments on.
I'd forgotten I'd already fixed it in trunk (silly me!).
> Later:
> >>If you apply the diff that results using patch, it won't DTRT, for
> >>example.
>
> (Results from what, I'm not sure, but...)
>
> >If that's the main criteria, just let me know. I'm just trying to
> >work out if schedule-delete files are intended to be handled in any
> >non-obvious manner.
>
> Nobody knows what the main criterion is. We need to balance "patch",
> readability, backward-compatibility, and, I hope, potential for "svn-patch"
> programs that understand more from the output than "patch" does.
>
Sure, though patch(1)-ability is pretty high on the list. Also note
that almost all of the changes I've been making are at the semantic,
not presentation layer (i.e. in libsvn_wc, not libsvn_client), so they've
been wrong whatever the output format.
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 28 12:06:45 2006