[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: LUCAS DE RODRIGO IGNACIO <idelucas_at_typsa.es>
Date: 2005-07-14 09:28:00 CEST

Thanks a lot for your quick reply!

> [...]; 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.

This is pretty much as I suspected, only it seems that that rewrite
isn't working correctly in my case. What is very strange, though,
is that svn_fs_node_id and svn_fs_paths_changed return different IDs;
which would seem to imply that something weirder than a rewrite,
failed or not, is going on (as one would expect only one of the IDs
to survive, in either case).

> 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.

I'm assuming this applies to comparing IDs from pending transactions,
since those IDs aren't to survive beyond the scope of their

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

Damn. Thanks a lot for trying, though. Since I'm pretty much testing
stuff right now, I think I'll just delete the repository and start
over, and see if it gets any better.

For the record, in the meantime I've implemented a workaround which
seems to work pretty well. When using svn_fs_paths_changed, I'm
simply checking for each node-rev if they correspond to a create
operation, and just retrieving its ID via svn_fs_node_id if that's
the case. Something like this:


This seems to be working just fine, and I'm assuming doesn't generate
a significant overhead, so I'm ready to call it done if nobody
else is having this problem.

Thanks a lot for your time and help. :)

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 14 09:28:56 2005

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.