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

"svn info", "Last Changed Rev", and inconsistencies with "svn log"

From: Nik Clayton <nik_at_ngo.org.uk>
Date: 2006-06-27 14:53:13 CEST

Hi,

[ not subscribed, I'd appreciate cc's on replies ]

Following a conversation in #svn-dev malcolmr suggested I post this here
to raise the issue and get further comment.

I've run in to an inconsistency with how the _fs and _ra layers treat
changed revisions, best illustrated by differing output from "svn info"
and "svn log".

The shell script, at

     http://pastebin.ca/73034

will create a test repository. Run "mkrepo.sh /tmp/repo" to create it.
  Some directories and files in the repository are created by direct
repo copy, rather than WC copies. One of those (assuming you created it
in /tmp/repo) is

     file:///tmp/repo/branches/test2/foo

This was copied from /trunk/foo, which was itself created in r2. The
copy created r5. "svn log" and "svn info" of this file disagree over
when the file was last changed. If you run

     svn log file:///tmp/repo/branches/test2/foo

you'll see that the most recent change (with log message) to the file
was in r5. If you run

     svn info file:///tmp/repo/branches/test2/foo

then you see

     Last Changed Rev: 2

If you don't want to run this yourself you can see the output at

     http://pastebin.ca/73047

2 != 5

malcolmr explained that this is because although the name of the node
changed in r5, the contents last changed in r2, and "svn info" is
showing when the contents changed. Now that I know the reasoning I
understand it, and I'm not suggesting it be abandoned.

However, it's counter-intuitive, and I'd like to suggest that the "svn
info" output be augmented to also include information about when the
node name changed, and not just when the contents changed. Especially
since the other "svn info" output gives no indication that it's
retrieving information about the node under a different name.

In addition, it seems to be a shortcoming of the svn_ra interface that
this information is not more easily accessible. Using svn_fs doing

     svn_fs_revision_root(root_p, fs, youngest_rev, pool);
     svn_fs_node_history(history_p, root_p, "/branches/test2/foo", pool);
     svn_fs_history_prev(prev_history, history_p, 0, pool);
     svn_fs_history_location(path, revision, prev_history, pool);

will result in "revision" containing 5.

The closest svn_ra equivalent I can find is

     svn_ra_stat(..., dirent, ...)

and then inspecting dirent->created_rev, which will contain "2".

The approaches that we came up with on IRC seem kludgy.

The first is to use svn_ra_get_log() with a limit of 1.

The second is to use svn_ra_get_locations() and just use the first
location from the list it returned. As there's no limit parameter that
may be expensive.

The third is svn_ra_get_file_revs(), which looks interesting, but
doesn't have a limit parameter either, so may be even more expensive.

Finally, the context in which I'm doing this. I'm the maintainer of
SVN::Web, a Subversion web frontend. The previous author wrote it to
the svn_fs interface. I've got a side project to convert to the svn_ra
interface, and ran in to this issue. With the /branches/test2/foo
example above, SVN::Web would[1] try and create a link that looked
something like:

     /svnweb/checkout/branches/test2/foo?rev=2

Of course, the file doesn't exist at that location in r2, and if the
user follows that link they'll get a 404.

So I need a cheap way of finding the most recent interesting rev using
the svn_ra interface.

N

[1] This is on a development branch, the production release of SVN::Web
doesn't have this functionality, so doesn't have this bug

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 27 15:03:24 2006

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.