> From: Branko Cibej [mailto:brane@xbc.nu]
> Sent: Friday, April 11, 2003 9:04 AM
>> I meant, given something like UUID::NODE-ID@REVISION in my svn:merged property,
>> will I know what path that relates to in the remote repository?
>
> Ah! You'd have to ask the remote repository about that. We record the
> committed-path of every node revision.
Ok.
> Come to think of it, thought, the NODE-CHANGE primary key contains both
> the node ID and the branch (copy) id, so it might be better to record
> node-changes. Getting a path from a node change is even simpler than
> from a node-id+revision.
>
>>> Oh, yes: one other thing to worry about here are dump/load cycles. If
>>> you use node id's instead of paths, then the dumper has to convert them
>>> to paths and the loader has to convert back, because node IDs aren't
>>> preserved across a reload.
But that won't help for remote repositories. You don't even know when a
remote repository will be dumped/loaded and you might be stuck with IDs
that are invalid afterwards.
>> I wonder, if we use PATH@REVISION, we should be able to get a tree delta
>> from the server which does take renames into account, no?
>
> Yes. But you'd have to talk to the server.
But we'd have to do that anyway to figure out the commited-path, right?
So why not do it the other way around? Given PATH@REVISION, return
NODE-CHANGE.
Or is asking the server only needed for remote repositories?
>> Are NODE-IDs guaranteed to be the same after a dump/load?
>
> They're not, that's exactly what I said above. :-)
Then isn't PATH@REV 'safer' than NODE-CHANGE?
Or, we should write out the ids when dumping and on load use that
data, so we are sure that the ids are stable across dump/load. Hmmm.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 11 09:41:01 2003