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: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 11 01:03:50 2007