You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Ren Wang <re...@gmail.com> on 2015/11/26 15:32:15 UTC
getting file or directory property/metadata
How to get a file or directory property by using API, is it
svn_fs_node_prop()? I was trying to get svn:author (a default property) for
a file from the repository, but the API always returns NULL.
RE: FW: getting file or directory property/metadata
Posted by Ren Wang <re...@gmail.com>.
Thank you for the response. I just did a test, svn_fs_node_created_rev()
works great!
-----Original Message-----
From: Daniel Shahaf [mailto:d.s@daniel.shahaf.name]
Sent: Saturday, November 28, 2015 12:41 PM
To: Ren Wang <re...@gmail.com>; dev@subversion.apache.org
Cc: users@subversion.apache.org
Subject: Re: FW: getting file or directory property/metadata
[moving to dev@; please drop users@ from replies]
Daniel Shahaf wrote on Sat, Nov 28, 2015 at 17:26:52 +0000:
> 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.
I think the first sentence of the following docstring is wrong:
/** Set @a *revision to the revision in which @a path under @a root was
* created. Use @a pool for any temporary allocations. @a *revision
will
* be set to #SVN_INVALID_REVNUM for uncommitted nodes (i.e. modified
nodes
* under a transaction root). Note that the root of an unmodified
transaction
* is not itself considered to be modified; in that case, return the
revision
* upon which the transaction was based.
*/
svn_error_t *
svn_fs_node_created_rev(svn_revnum_t *revision,
It sounds as though it gives the answer to `svn log --stop-on-copy
--limit=1 -r 0:HEAD path@root`, but in fact it gives the "Last Changed
Revision" of path@root.
I think we need at least this patch:
Index: subversion/include/svn_fs.h
===================================================================
--- subversion/include/svn_fs.h (revision 1717002)
+++ subversion/include/svn_fs.h (working copy)
@@ -1775,2 +1775,2 @@
-/** Set @a *revision to the revision in which @a path under @a root was
- * created. Use @a pool for any temporary allocations. @a *revision
will
+/** Set @a *revision to the revision in which @a path under @a root was
last
+ * modified. Use @a pool for any temporary allocations. @a *revision
will
I didn't check the sibling functions for analogous docstring bugs.
I can't commit this myself due to an outstanding issue with my apache
account :-(
Cheers,
Daniel
RE: FW: getting file or directory property/metadata
Posted by Ren Wang <re...@gmail.com>.
Thank you for the response. I just did a test, svn_fs_node_created_rev()
works great!
-----Original Message-----
From: Daniel Shahaf [mailto:d.s@daniel.shahaf.name]
Sent: Saturday, November 28, 2015 12:41 PM
To: Ren Wang <re...@gmail.com>; dev@subversion.apache.org
Cc: users@subversion.apache.org
Subject: Re: FW: getting file or directory property/metadata
[moving to dev@; please drop users@ from replies]
Daniel Shahaf wrote on Sat, Nov 28, 2015 at 17:26:52 +0000:
> 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.
I think the first sentence of the following docstring is wrong:
/** Set @a *revision to the revision in which @a path under @a root was
* created. Use @a pool for any temporary allocations. @a *revision
will
* be set to #SVN_INVALID_REVNUM for uncommitted nodes (i.e. modified
nodes
* under a transaction root). Note that the root of an unmodified
transaction
* is not itself considered to be modified; in that case, return the
revision
* upon which the transaction was based.
*/
svn_error_t *
svn_fs_node_created_rev(svn_revnum_t *revision,
It sounds as though it gives the answer to `svn log --stop-on-copy
--limit=1 -r 0:HEAD path@root`, but in fact it gives the "Last Changed
Revision" of path@root.
I think we need at least this patch:
Index: subversion/include/svn_fs.h
===================================================================
--- subversion/include/svn_fs.h (revision 1717002)
+++ subversion/include/svn_fs.h (working copy)
@@ -1775,2 +1775,2 @@
-/** Set @a *revision to the revision in which @a path under @a root was
- * created. Use @a pool for any temporary allocations. @a *revision
will
+/** Set @a *revision to the revision in which @a path under @a root was
last
+ * modified. Use @a pool for any temporary allocations. @a *revision
will
I didn't check the sibling functions for analogous docstring bugs.
I can't commit this myself due to an outstanding issue with my apache
account :-(
Cheers,
Daniel
Re: FW: getting file or directory property/metadata
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
[moving to dev@; please drop users@ from replies]
Daniel Shahaf wrote on Sat, Nov 28, 2015 at 17:26:52 +0000:
> 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.
I think the first sentence of the following docstring is wrong:
/** Set @a *revision to the revision in which @a path under @a root was
* created. Use @a pool for any temporary allocations. @a *revision will
* be set to #SVN_INVALID_REVNUM for uncommitted nodes (i.e. modified nodes
* under a transaction root). Note that the root of an unmodified transaction
* is not itself considered to be modified; in that case, return the revision
* upon which the transaction was based.
*/
svn_error_t *
svn_fs_node_created_rev(svn_revnum_t *revision,
It sounds as though it gives the answer to `svn log --stop-on-copy
--limit=1 -r 0:HEAD path@root`, but in fact it gives the "Last Changed
Revision" of path@root.
I think we need at least this patch:
Index: subversion/include/svn_fs.h
===================================================================
--- subversion/include/svn_fs.h (revision 1717002)
+++ subversion/include/svn_fs.h (working copy)
@@ -1775,2 +1775,2 @@
-/** Set @a *revision to the revision in which @a path under @a root was
- * created. Use @a pool for any temporary allocations. @a *revision will
+/** Set @a *revision to the revision in which @a path under @a root was last
+ * modified. Use @a pool for any temporary allocations. @a *revision will
I didn't check the sibling functions for analogous docstring bugs.
I can't commit this myself due to an outstanding issue with my apache
account :-(
Cheers,
Daniel
Re: FW: getting file or directory property/metadata
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
[moving to dev@; please drop users@ from replies]
Daniel Shahaf wrote on Sat, Nov 28, 2015 at 17:26:52 +0000:
> 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.
I think the first sentence of the following docstring is wrong:
/** Set @a *revision to the revision in which @a path under @a root was
* created. Use @a pool for any temporary allocations. @a *revision will
* be set to #SVN_INVALID_REVNUM for uncommitted nodes (i.e. modified nodes
* under a transaction root). Note that the root of an unmodified transaction
* is not itself considered to be modified; in that case, return the revision
* upon which the transaction was based.
*/
svn_error_t *
svn_fs_node_created_rev(svn_revnum_t *revision,
It sounds as though it gives the answer to `svn log --stop-on-copy
--limit=1 -r 0:HEAD path@root`, but in fact it gives the "Last Changed
Revision" of path@root.
I think we need at least this patch:
Index: subversion/include/svn_fs.h
===================================================================
--- subversion/include/svn_fs.h (revision 1717002)
+++ subversion/include/svn_fs.h (working copy)
@@ -1775,2 +1775,2 @@
-/** Set @a *revision to the revision in which @a path under @a root was
- * created. Use @a pool for any temporary allocations. @a *revision will
+/** Set @a *revision to the revision in which @a path under @a root was last
+ * modified. Use @a pool for any temporary allocations. @a *revision will
I didn't check the sibling functions for analogous docstring bugs.
I can't commit this myself due to an outstanding issue with my apache
account :-(
Cheers,
Daniel
RE: FW: getting file or directory property/metadata
Posted by Ren Wang <re...@gmail.com>.
Thank you, svn_fs_node_created_rev() is what I am looking for.
-----Original Message-----
From: Branko Čibej [mailto:brane@apache.org]
Sent: Saturday, November 28, 2015 7:07 PM
To: users@subversion.apache.org
Subject: Re: FW: getting file or directory property/metadata
On 28.11.2015 18:26, Daniel Shahaf wrote:
> 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.
The docstring is correct, but it's not clear that "path under root"
means "node-revision identified by path under root". This is one of the many places where the DAG storage model leaks into public API semantics; what you get is literally the revision number in with the node-revision object was created.
-- Brane
Re: FW: getting file or directory property/metadata
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Branko Čibej wrote on Sun, Nov 29, 2015 at 01:06:32 +0100:
> On 28.11.2015 18:26, Daniel Shahaf wrote:
> > 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.
>
> The docstring is correct, but it's not clear that "path under root"
> means "node-revision identified by path under root". This is one of the
Thanks, I've incorporated that into r1717154.
> many places where the DAG storage model leaks into public API semantics;
> what you get is literally the revision number in with the node-revision
> object was created.
>
> -- Brane
>
Re: FW: getting file or directory property/metadata
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Branko Čibej wrote on Sun, Nov 29, 2015 at 01:06:32 +0100:
> On 28.11.2015 18:26, Daniel Shahaf wrote:
> > 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.
>
> The docstring is correct, but it's not clear that "path under root"
> means "node-revision identified by path under root". This is one of the
Thanks, I've incorporated that into r1717154.
> many places where the DAG storage model leaks into public API semantics;
> what you get is literally the revision number in with the node-revision
> object was created.
>
> -- Brane
>
Re: FW: getting file or directory property/metadata
Posted by Branko Čibej <br...@apache.org>.
On 28.11.2015 18:26, Daniel Shahaf wrote:
> 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.
The docstring is correct, but it's not clear that "path under root"
means "node-revision identified by path under root". This is one of the
many places where the DAG storage model leaks into public API semantics;
what you get is literally the revision number in with the node-revision
object was created.
-- Brane
Re: FW: getting file or directory property/metadata
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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
FW: getting file or directory property/metadata
Posted by Ren Wang <re...@gmail.com>.
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.
-----Original Message-----
From: Branko Čibej [mailto:brane@apache.org]
Sent: Thursday, November 26, 2015 11:13 AM
To: Ren Wang <re...@gmail.com>
Subject: Re: getting file or directory property/metadata
There have been two kinds of properties in Subversion since before 1.0. :)
A transacton property is like a revision property, but belongs to a transaction object, which may, when committed, become a new revision. We use transactions to build up tree and content changes, then commit them (which is a complex process) to create new revisions. At any time, there can be an number of open transactions; but only one revision at a time can be committed.
-- Brane
On 26.11.2015 16:01, Ren Wang wrote:
> BTW, what's transaction property? I noticed there is another API called:
> svn_fs_txn_prop()
>
> -----Original Message-----
> From: Ren Wang [mailto:renwang101@gmail.com]
> Sent: Thursday, November 26, 2015 9:58 AM
> To: 'Branko Čibej' <br...@apache.org>
> Subject: RE: getting file or directory property/metadata
>
> Thanks again. Glad to know there're two kinds of properties in subversion now.
>
> -----Original Message-----
> From: Branko Čibej [mailto:brane@apache.org]
> Sent: Thursday, November 26, 2015 9:47 AM
> To: users@subversion.apache.org
> Subject: Re: getting file or directory property/metadata
>
> On 26.11.2015 15:32, Ren Wang wrote:
>> How to get a file or directory property by using API, is it
>> svn_fs_node_prop()? I was trying to get svn:author (a default
>> property) for a file from the repository, but the API always returns NULL.
> You already got the answer to that question in a previous response:
> svn:author is a *revision* property, not a *node* property. You should be looking at the properties for the revision in which the file was last changed.
>
> -- Brane
>
>
Re: getting file or directory property/metadata
Posted by Branko Čibej <br...@apache.org>.
On 26.11.2015 15:32, Ren Wang wrote:
> How to get a file or directory property by using API, is it
> svn_fs_node_prop()? I was trying to get svn:author (a default property) for
> a file from the repository, but the API always returns NULL.
You already got the answer to that question in a previous response:
svn:author is a *revision* property, not a *node* property. You should
be looking at the properties for the revision in which the file was last
changed.
-- Brane