On Tue, Jun 25, 2013 at 11:20:02PM +0200, Ben Reser wrote:
> 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.
The problem you're seeing here is that --show-copies-as-adds doesn't
work for repos-repos diffs yet:
http://subversion.tigris.org/issues/show_bug.cgi?id=2543#desc13
The test mentioned in that link still has these comments:
# Repos->repos diff after the rename
### --show-copies-as-adds has no effect
exit_code, diff_output, err_output = svntest.main.run_svn(None, 'diff',
'-r', '2:3',
pi2_path)
So that's a known bug.
> > 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.
Consistency is good. Generally, I won't object to such changes being made.
But I'd be careful about changing this output in a patch release.
We can change it in 1.9, of course, and document the change.
I would prefer adding a --diff-copy-from option for 'svn diff',
to make it match the current 'svnlook diff' behaviour:
$ svnlook diff -r4 repos
Copied: trunk/alpha2 (from rev 2, trunk/alpha)
===================================================================
--- trunk/alpha2 (rev 0)
+++ trunk/alpha2 2013-06-26 09:44:59 UTC (rev 4)
@@ -0,0 +1,2 @@
+alpha
+mmm
$ svnlook diff -r4 repos --diff-copy-from
Copied: trunk/alpha2 (from rev 2, trunk/alpha)
===================================================================
--- trunk/alpha 2013-06-26 09:44:37 UTC (rev 2)
+++ trunk/alpha2 2013-06-26 09:44:59 UTC (rev 4)
@@ -1 +1,2 @@
alpha
+mmm
> > 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.
The --git option is supported in the sense that the current functionality
provided is implemented correctly. However, the functionality isn't very
useful because it is incomplete, at least in terms of the lofty goals we
were aiming for. That's because at the time the option was added we didn't
have a good way of extending it further. We lacked proper copyfrom reporting
for diffs (probably fixed by Bert in 1.8) and also lacked rename tracking
(fixed for working copies in 1.8, but not for diffs involving the server).
These problems prevented us from making diff --git show copies and moves
properly, especially for repos-repos diffs.
> > 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.
Which cases do you mean exactly?
> Renames has nothing to do with
> the current issue, I don't see a reason to wait for that to fix this.
I did in fact intend to add 'rename' headers to diff --git diffs in 1.8,
but I forgot about doing it. Sorry. It would only have worked for WC-WC
diffs anyway, though.
Received on 2013-06-26 11:52:00 CEST