Sander Striker wrote:
>>>>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.
>
Or we could simply declare that the UUID defines the repository; if the
UUID changes, it's arguably no longer the same repository (and such a
change would cause problems for more than just merges, anyway). That's
why "svnadmin load" has an option to restore the UUID from the dump file.
>>>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?
>
I don't think so, at least not in general.
>>>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.
>
What I proposed was for the dumper to convert NODE-CHANGE-PK to
PATH@REV, and the loader to convert back. That would mean dump and load
has to know about the semantics of svn:merged.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 11 17:42:07 2003