Your example is flawed. You keep referring to r33, in which test.txt was
removed, and the path did not actually exist (anymore).
'svn log -v -r 32 file:///home/bbrummer/test/test_repo' should work
'svn log -r33 file:///home/bbrummer/test/test_repo/test.txt_at_32' does not
work because you're correctly pegging at r32, and then try to look
forward to r33, where the file no longer exists.
> -----Original Message-----
> From: Brummer, Byron [mailto:ByronBrummer@LiveNation.com]
> Sent: Wednesday, January 10, 2007 7:03 PM
> To: David Glasser
> Cc: C. Michael Pilato; Danny van Heumen; Michael Sinz; Subversion
Users;
> dev@subversion.tigris.org
> Subject: RE: Delete revision of an object has no peg revision?
>
> 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: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
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:12:57 2007