"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