> 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?
> 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?
Are NODE-IDs guaranteed to be the same after a dump/load?
> 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.
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 08:55:12 2003