Malcolm Rowe wrote:
>
> # Mark the file as schedule-deleted
> svn rm wc/foo
> # Now both of these show the addition of an empty file
> # The repos->BASE one is definitely wrong, since changes in the
> # WORKING tree should not affect diffs against BASE, but shouldn't the
> # repos->WORKING diff show nothing? (The repository and WORKING trees
> # are identical, after all.)
> svn diff -r0 wc
> svn diff -r0:BASE wc
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"? I don't; I interpret
it as "The file was touched in some unspecified way but is identical to how it
was." 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 think "patch" will ignore this, which is fine.
> + svn diff -r0:BASE wc
> Index: wc/foo
> ===================================================================
> --- wc/foo (revision 0)
> +++ wc/foo (revision 1)
> @@ -0,0 +1 @@
> +xxx
That one is not empty, but is correct, I think: isn't this the way we currently
represent both "create this file from nonexistent to the specified content" and
"change this file from empty to the specified content"? I hope we could do
better and distinguish the two cases, but I think that's a secondary concern.
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.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Feb 13 16:27:40 2006