Sander Striker wrote:
>>From: Branko Cibej [mailto:brane@xbc.nu]
>>Sent: Friday, April 11, 2003 12:51 AM
>>
>>
>
>
>
>>>>From: Branko Cibej [mailto:brane@xbc.nu]
>>>>Sent: Friday, April 11, 2003 12:25 AM
>>>>
>>>>
>>>>I /think/ that recording NODE-ID@REVISION[:REVISION] would be sufficient
>>>>(assuming we have atomc renames that preserve node id's): Perhaps even
>>>>NODE-CHANGE-PK[:NODE-CHANGE-PK], which is semantically the but a) avoids
>>>>one index lookup when pulling the MRCA or MRMR from the repository, but
>>>>b) makes history comparison harder (without making assumptions about the
>>>>strucutre of the NODE-CHANGE primary key).
>>>>
>>>>
>>>>
>>>>
>>>Going from PATH to NODE-ID is indeed a minimal change to presented
>>>format in the proposal. +1. But, will that also work for out of repository
>>>merges though?
>>>
>>>
>>You've already got a disambiguation mechanism for that:
>>
>> [REPOS-UUID::]NODE-ID@REVISION[:REVISION]
>>
>>
>
>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.
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.
>>
>>
>
>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.
>Are NODE-IDs guaranteed to be the same after a dump/load?
>
They're not, that's exactly what I said above. :-)
>>What happens to thre repos UUIDs of out-of-repos merge sources when
>>those souces get reloaded is something I don't want to contemplate.
>>
>>
>
>We would need a rewrite tool that rewerites OLDUUID to NEWUUID. Or
>we must do one indirection and record the non-local repository UUIDs
>somewhere and use keys to that in the merge history.
>
>
Oh, right -- we already hav a "uuids" table, for this very purpose. So
yes, you'd not put the actual UUID into the recode in svn:merge, you'd
just use its index in the uuids table. Index 0 is always this
repository; other indexes aren't used yet, but we can declare that
they're invariant to dump/load.
--
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 09:04:21 2003