subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <...@daniel.shahaf.name>
Subject Re: FW: getting file or directory property/metadata
Date Sat, 28 Nov 2015 17:26:52 GMT
Ren Wang wrote on Fri, Nov 27, 2015 at 10:04:38 -0500:
> Thanks, that makes sense.
> 
> Here is another question. How to get the latest revision id for
> a node? I see the svnlook is calling svn_fs_node_id() to get node id,
> but couldn't find a reference to get the latest revision of id for
> a node.
> 
> From the subversion client side, I can see the latest version id
> showing on the subversion client panel, such as on TortoseSVN, I guess
> it must has an interface on the repos or fs layer.
> 

The term is "revision number", not "revision id".  The FS layer concepts
"node id", "node-revision", and "node-revision id" have nothing to do
with revision numbers.  I'm not sure how you ran into svn_fs_node_id(),
but in any case, tracing 'svn log' would have given you the answer:

[[[
% svnadmin create r
% svnmucc put -mm r/README.txt file://$PWD/r/foo 
r1 committed by daniel at 2015-11-27T22:19:05.115711Z
% svn mkdir -qmm file://$PWD/r/bar 
% ltrace -l '*fs*' svn log -v file://$PWD/r/foo 2>&1 >/dev/null | grep -v __
libsvn_repos-1.so.1->svn_fs_type(0x7f300d8d1310, 0x7f300d8d1338, 0x7f300d8d1028, 0) = 0
libsvn_repos-1.so.1->svn_fs_open(0x7f300d8d12d0, 0x7f300d8d1338, 0, 0x7f300d8d1028 <unfinished
...>
libsvn_fs-1.so.1->svn_fs_type(0x7ffd09a0e620, 0x7f300d8d1338, 0x7f300d8d1028, 0x7f300d8d1028)
= 0
libsvn_fs-1.so.1->svn_fs_version(0x7ffd09a0e640, 0x7f300b63b340, 0x7f300b63b350, 0) = 0x7f300b63ad30
libsvn_fs-1.so.1->svn_fs_initialize(0, 0x7f300b63b340, 0x7f300b63b350, 0) = 0
libsvn_ra_local-1.so.1->svn_fs_set_warning_func(0x7f300d8d3730, 0x7f300b8744d0, 0, 8) =
0x7f300d8d3730
libsvn_ra_local-1.so.1->svn_fs_get_uuid(0x7f300d8d3730, 0x7f300d8d1118, 0x7f300d8d1028,
8) = 0
libsvn_ra_local-1.so.1->svn_fs_youngest_rev(0x7ffd09a0e8a0, 0x7f300d8d3730, 0x7f300d8dc028,
0x7f300d8d10f0) = 0
libsvn_ra_local-1.so.1->svn_fs_youngest_rev(0x7f300d8aefc8, 0x7f300d8d3730, 0x7f300d8dc028,
0x7f300d8d10f0) = 0
libsvn_ra_local-1.so.1->svn_fs_youngest_rev(0x7ffd09a0e930, 0x7f300d8d3730, 0x7f300d8dc028,
0x7f300d8d10f0) = 0
libsvn_repos-1.so.1->svn_fs_youngest_rev(0x7ffd09a0e8f0, 0x7f300d8d3730, 0x7f3005787028,
0) = 0
libsvn_repos-1.so.1->svn_fs_revision_root(0x7ffd09a0e7a0, 0x7f300d8d3730, 2, 0x7f3005787028
<unfinished ...>
libsvn_repos-1.so.1->svn_fs_node_history(0x7f3005781120, 0x7f300577a5c8, 0x7f30057870c8,
0x7f3005787028 <unfinished ...>
libsvn_repos-1.so.1->svn_fs_history_prev(0x7f3005781120, 0x7f30057889a8, 1, 0x7f3005775028
<unfinished ...>
libsvn_repos-1.so.1->svn_fs_history_location(0x7ffd09a0e5c0, 0x7f3005781110, 0x7f3005775858,
0x7f3005775028) = 0
⋮
]]]

The last three lines compute what you need.  (But read on for another
option.)

The 'grep -v __' is to hide functions that aren't part of the public
API.

To be fair, though, the same trick with 'svn info' would have lead you
to svn_fs_node_created_rev(), which is documented to return "the
revision in which @a path under @a root was created", but in fact
returns the revision in which it was last modified.

Cheers,

Daniel


Mime
View raw message