[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 17:41:20 CEST

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

This is an archived mail posted to the Subversion Dev mailing list.