cmpilato@collab.net writes:
> Robert Pluim <rpluim@bigfoot.com> writes:
>
> > svn diff doesn't quite work the way I expect though. tags/testtag is
> > an 'svn cp' of rev 37, committed at rev 39.
> >
> > $ svn diff file:///home/rpluim/testrepo/tags/testtag/1000 1000_at_38
> > svn: Filesystem has no item
> > svn: 'file:///home/rpluim/testrepo/tags/testtag/1000' at rev 38 wasn't found in repository.
> >
> > ? Why is it using the rev of the second target here?
>
> Under-the-hood, "1000" is being converted to "the URL of '1000'". I
> know, that doesn't seem to be documented in 'svn help diff', but...
>
I might document that if I get inspired, except that this behaviour
isn't consistent:
$ svn diff file:///home/rpluim/testrepo/trunk/foo/1000_at_36 1000_at_38
Index: 1000
===================================================================
--- 1000 (revision 36)
+++ 1000 (revision 38)
@@ -44,3 +44,5 @@
### See http://subversion.tigris.org/issues/show_bug.cgi?id=668
### for what else will soon be customized in this file.
init
+mid
+end
But if you specify the first target the same way:
$ svn diff 1000@36 1000@38
rpluim: ~/wc-test/local-wc1/foo
$
I'm okay with it not working, since it's probably not really supposed
to anyway, but maybe we should do start checking this more
rigourously?
> > I could agree that 1000@38 is illegal syntax, however:
> >
> > $ svn diff file:///home/rpluim/testrepo/tags/testtag/1000 file:///home/rpluim/testrepo/trunk/foo/1000_at_38
> > svn: Filesystem has no item
> > svn: 'file:///home/rpluim/testrepo/tags/testtag/1000' at rev 38 wasn't found in repository.
> >
> > I thought that not specifying the rev => HEAD?
>
> This looks like it might be a different bug. Perhaps sussman has an
> idea of what's happening here?
Well, in svn_opt_args_to_target_array it looks like the
if (extract_revisions)
...
portion, line 619 or so in subversion/libsvn_subr/opt.c is not quite
right. It skips the unspecified rev for the first URL, and then
returns a start_revision of "38" for the second url. Removing
if (temprev.kind != svn_opt_revision_unspecified)
makes things work in this case, but I haven't checked what else that
might break ('svn merge' should be the only thing that's affected,
since it's the only other caller that sets extract_revisions to true).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 18 15:43:37 2003