On Tue, Jun 25, 2013 at 10:56 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> That's not quite true in general. It's more like:
>
> 1) If the copyfrom source is part of the operative revision range of
> the diff command, show a modification against the copyfrom source.
> Unless --show-copies-as-adds was passed, because then we always
> show copied files as an addition.
>
> 2) If the copyfrom source is not part of the operative revision range,
> history of the file isn't traced back to that revision, so it appears
> as an addition.
Well if our intention wasn't to provide interoperability here then I
have no idea why we made this choice because frankly I think it's poor
behavior.
> It could be argued that 2) is weird special case, and that it should
> behave like 1) (i.e. trace back to the copyfrom source anyway) and
> only show an addition with --show-copies-as-adds.
Yes, I'd agree with that.
However, I'll point out that --show-copies-as-adds doesn't, in my
opinion, behave properly when the copyfrom source is part of the
operative revision range. I'd argue in that case it should
effectively also behave as --stop-on-copy (which diff doesn't have)
since the delta of the file over that range should just be the
addition of the file since you told it to show copies as adds.
E.G. here's the behavior based on the example environment produced by
the script in the original post:
[[[
svn diff -r1:3 --show-copies-as-adds wc/f2
Index: wc/f1
===================================================================
--- wc/f1 (.../f1) (revision 1)
+++ wc/f1 (.../f2) (revision 3)
@@ -1 +1,2 @@
file 1
+added line
]]]
In fact I'm not even sure what the point of --show-copies-as-adds is
based on the behavior we have. I'm sure it was added for some reason
but the behavior of diff here seems utterly not what a user would
expect give the descriptions of the commands.
> Johan pointed out that svnlook diff seems to traverse to the copyfrom
> source even in case 2). If this is indeed the case, these commands are
> now behaving in contradictory ways :( However, I think it's too late
> to change either command now.
I'd call that a bug and fix it. In this case I'd probably make
svnlook match svn and fix svn diff --git to provide the behavior
because of what I mentioned before. svnlook should probably also grow
--git and some of the other diff options.
> I'm not quite sure if we can already recommend the --git diff option
> for widespread use.
Then we shouldn't have released with it enabled. Releasing a command
with an option and then saying we don't recommend people to use it is
like throwing a live hand grenade in the room of friends and saying
that you don't recommend that your friends occupy the room.
> I intend to get back to it once we can produce proper information for renames.
But it doesn't even properly handle the cases we can handle or at
least should be able to handle now. Renames has nothing to do with
the current issue, I don't see a reason to wait for that to fix this.
> It's never going to be fully interoperable
> with other VCSs in any case because Subversion needs to show all paths
> in --git diff headers relative to the repository root to avoid ambiguity
> in copyfrom paths. So instead of a/foo/bar.txt like git would show for
> any branch, for instance, we get paths like a/trunk/foo/bar.txt or
> a/branches/mybranch/foo/bar.txt with svn diff --git, depending on the
> branch the diff is made on.
Right, we really can't interoperate fully here, which is part of the
reason we never could agree on a format because once you get into
describing tree changes things diverge in ways that make it hard to
agree.
Received on 2013-06-25 23:20:40 CEST