node_id for 'create' operations being "_0" instead of the new node's id?

[LUCAS DE RODRIGO IGNACIO <id...@typsa.es>]

Hello,
    I'm new to the mailing list and to SubVersion in general (and to 
make matters worse, English isn't my primary language), so please bear 
with me. :) I've read through the issues list thrice and searched the 
mailing lists on several occasiones, but I haven't been able to find 
any reference to this problem. 

I'm developing an application which makes use of the SubVersion 
repository. I'm asking for history elements through svn_fs_paths_changed, 
and then comparing their IDs through svn_fs_compare_ids with a given 
ID. The problem is, it seems that whenever one of the history elements 
is a creation, no matter if both operations refer to the same node, 
svn_fs_compare_ids returns "unrelated". This, oddly enough, happens 
even when they are the SAME history element, if one of them was obtained 
via svn_fs_node_history + svn_fs_history_prev and the other with 
svn_fs_paths_changed.

Upon further investigation, it seems that creation history elements 
obtained through svn_fs_paths_changed present the following in their 
ID: their node_id component, instead of housing the ID of the node 
(file/directory) created (as seen in following operations on that 
node), contains "_0" (or, if more than one creation was present in 
the same revision, "_1", "_2" and so on). This almost looks like a 
temporary placeholder ID that should be replaced later on with the 
ID of the node being created on commit, but isn't. 

I'm not sure if this problem is widespread; or if it's working as 
intended and it's just that I'm doing something wrong. Particularly
since it seems that this would effectively prevent creations from 
appearing on history logs as long as one relies on ID comparison 
alone. Whatever the case, any help would be greatly appreciated. :)
Thanks in advance!
    Ignacio de Lucas


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: node_id for 'create' operations being "_0" instead of the new node's id?

["C. Michael Pilato" <cm...@collab.net>]

"LUCAS DE RODRIGO IGNACIO" <id...@typsa.es> writes:

> Hello,
>     I'm new to the mailing list and to SubVersion in general (and to 
> make matters worse, English isn't my primary language), so please bear 
> with me. :) I've read through the issues list thrice and searched the 
> mailing lists on several occasiones, but I haven't been able to find 
> any reference to this problem. 
> 
> I'm developing an application which makes use of the SubVersion 
> repository. I'm asking for history elements through svn_fs_paths_changed, 
> and then comparing their IDs through svn_fs_compare_ids with a given 
> ID. The problem is, it seems that whenever one of the history elements 
> is a creation, no matter if both operations refer to the same node, 
> svn_fs_compare_ids returns "unrelated". This, oddly enough, happens 
> even when they are the SAME history element, if one of them was obtained 
> via svn_fs_node_history + svn_fs_history_prev and the other with 
> svn_fs_paths_changed.
> 
> Upon further investigation, it seems that creation history elements 
> obtained through svn_fs_paths_changed present the following in their 
> ID: their node_id component, instead of housing the ID of the node 
> (file/directory) created (as seen in following operations on that 
> node), contains "_0" (or, if more than one creation was present in 
> the same revision, "_1", "_2" and so on). This almost looks like a 
> temporary placeholder ID that should be replaced later on with the 
> ID of the node being created on commit, but isn't. 
> 
> I'm not sure if this problem is widespread; or if it's working as 
> intended and it's just that I'm doing something wrong. Particularly
> since it seems that this would effectively prevent creations from 
> appearing on history logs as long as one relies on ID comparison 
> alone. Whatever the case, any help would be greatly appreciated. :)
> Thanks in advance!

This from libsvn_fs_fs/structure:

   Node-revision IDs
   -----------------
   
   In order to support efficient lookup of node-revisions by their IDs
   and to simplify the allocation of fresh node-IDs during a transaction,
   we treat the fields of a node-ID in new and interesting ways.
   
   Within a revision file, node-revs have a txn-id field of the form
   "r<rev>/<offset>", to support easy lookup.  The node-id and copy-id
   fields are unique base36 values as in the BDB implementation.
   
   New node-revision IDs assigned within a transaction have the txn-id
   field of "t<txnid>".  The node-id or copy-id field may be base36
   values if the node-revision is derived from a pre-existing node and/or
   copy; if the node-revision must have a freshly-assigned node-id or
   copy-id, it uses "_" followed by a base36 unique to the transaction.
   During the final phase of a commit, node-revision IDs are rewritten to
   have unique node-ID and copy-ID fields and to have "r<rev>/<offset>"
   txn-id fields.
   
   The temporary assignment of node-ID and copy-ID fields has
   implications for svn_fs_compare_ids and svn_fs_check_related.  The IDs
   _1.0.t1 is not related to the ID _1.0.t2 even though they have the
   same node-ID, because temporary node-IDs are restricted in scope to
   the transactions they belong to.

Note that I can't reproduce a scenario under which the _NNN ids are
more than temporary.

Also note that BDB does not use such a temporary ID system -- this is
specific to the FSFS backend.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org