[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Delete revision of an object has no peg revision?

From: Brummer, Byron <ByronBrummer_at_LiveNation.com>
Date: 2007-01-11 01:02:59 CET

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

    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
    Changed paths:
       D /test.txt


    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,


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jan 11 01:04:15 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.