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

How should 'svn log' behave with peg revisions?

From: <kfogel_at_collab.net>
Date: 2005-07-01 22:15:15 CEST

Please see S. Ramaswamy's post and patch here:


He's fixing issue #2287, by making 'svn log' able to take peg
revisions, e.g.:

   $ svn log -rN url_that_does_not_exist_in_head@X

Here's how that should work: Subversion would first go to rX, find the
relevant path as determined from the URL, and then show rN's log
information *of that object*.

Unfortunately, today, 'svn log' wrongly behaves as if it already
supports peg revisions via -r. For example, watch this sequence:

   $ svn log -v -r14998
   r14998 | lundblad | 2005-06-07 07:28:28 -0500 (Tue, 07 Jun 2005) | 8 lines
   Changed paths:
      D /trunk/notes/TODO-1.2.txt
      M /trunk/notes/locking/TODO.txt
   Cleanup in notes directory.
   The items removed were either done, irrelevant or put in the issue
   * notes/TODO-1.2.txt: Remove.
   * notes/locking/TODO.txt: Remove some items.

   $ svn log -rHEAD http://svn.collab.net/repos/svn/trunk/notes/TODO-1.2.txt
   subversion/libsvn_ra_dav/util.c:826: (apr_err=175007)
   svn: REPORT request failed on \
   subversion/libsvn_ra_dav/util.c:774: (apr_err=175007)
   svn: '/repos/svn/!svn/bc/15230/trunk/notes/TODO-1.2.txt' path not found

Good, we expected an error. After all, 'TODO-1.2.txt' is gone in HEAD.
But, I just happen to know that it was modified in r13902. What
happens if we try that?

   $ svn log -r13902 http://svn.collab.net/repos/svn/trunk/notes/TODO-1.2.txt
   r13902 | fitz | 2005-04-04 12:01:50 -0500 (Mon, 04 Apr 2005) | 2 lines
   * notes/TODO-1.2.txt: Update.

In other words, 'svn log' treated -r13902 as a peg revision, which
it's not. Subversion should have errored, on the grounds that it
couldn't find an object on which to trace history back to r13902. In
certain subtle situations (where objects with different identity but
the same name replace other objects at the exact same path) this means
that 'svn log' is actually incapable of expressing certain requests.

We've already fixed other commands, such as 'svn cat', to not treat -r
operands this way, and to use '@N' peg rev syntax instead. We just
hadn't gotten around to fixing 'svn log' yet -- that's what issue
#2287 is about.

If we make this change, 'svn log' will be consistent with other
commands. But, the behavior change will be unusually user-visible.
We could just say:

   "The old behavior was a bug, get used to the nice, shiny new
    consistency of everyone taking peg revs."

In fact, Ben Collins-Sussman and I think that's fine. But, it's
drastic enough that we thought we should ask here first.



To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 1 23:25:07 2005

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

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