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
transactions.
> 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:
if(change->change_kind==svn_fs_path_change_add)
{
change->node_rev_id=NULL;
SVN_ERR(svn_fs_node_id(&(change->node_rev_id),root,path,pool));
}
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. :)
Ignacio
---------------------------------------------------------------------
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