dglasser@gmail.com [dglasser@gmail.com] wrote:
> On 1/10/07, Brummer, Byron <ByronBrummer@livenation.com> wrote:
> > Even worse is:
> >
> > svn log -r REV_IN_WHICH_PATH_DID_EXIST path
> >
> > when path no longer exists @HEAD or @BASE. I'd say the
> > peg version defaults are wrong...but that wouldn't help,
> > since there's no peg version in the system that will make
> > the above request return the entry.
>
> Just use
>
> svn log path@REV_IN_WHICH_PATH_DID_EXIST
I'd love to, but it doesn't work:
$ svn log -v file:///home/bbrummer/test/test_repo/test.txt_at_33
svn: File not found: revision 33, path '/test.txt'
$ svn log -v -r 33 file:///home/bbrummer/test/test_repo
-------------------------------------------------------------
r33 | bbrummer | 2007-01-10 23:24:54 +0000 (Wed, 10 Jan 2007) | 1
line
Changed paths:
D /test.txt
test
-------------------------------------------------------------
Peg version 32 is a valid peg for this object, but it still
fails to retrieve the delete revision:
svn log -r33 file:///home/bbrummer/test/test_repo/test.txt_at_32
svn: File not found: revision 33, path '/test.txt'
This isn't a PBKAC, it isn't a misunderstanding of how svn
works. It's a complaint that the svn works is logically
flawed and available workarounds to obtain the correct
logical result are non-trivial and non-obvious.
> Generally, operation rev (-r) defaults to peg rev if only the
> peg rev is specified; the reverse is not true.
Interesting. Where's this documented?
> For most commands, using a peg rev and not using -r is what you
> want to do (and in cases where that's not true, like svn cp,
> we're working to fix that -- see Hyrum fixing "svn cp file@REV"
> as we speak).
Except that log often is passed a range and thus @REV syntax
doesn't work.
Personally I see this command:
svn log -r10:20 path
As requesting all history from rev 10 through rev 20 related
to "path". If that history includes one peg version or ten
should not logically limit the above request (most
especially w/o notice that such filtering is happening).
Perhaps what svn should logically do is return all relevant
revision logs AND note with them when the peg version
changes. Or maybe even better:
svn log -r10:20 path@*
Which in nutty svn thinking would mean "At any peg version,
dammit!".
-Byron
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 11 01:03:50 2007