[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PROPOSAL] Merging Improved

From: Branko Čibej <brane_at_xbc.nu>
Date: 2003-04-11 09:03:39 CEST

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

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.