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

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

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2005-07-14 08:50:53 CEST

"LUCAS DE RODRIGO IGNACIO" <idelucas@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
Received on Thu Jul 14 08:53:34 2005

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