[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: Sander Striker <striker_at_apache.org>
Date: 2003-04-11 09:40:14 CEST

> From: Branko Cibej [mailto:brane@xbc.nu]
> Sent: Friday, April 11, 2003 9:04 AM

>> 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.

Ok.
 
> 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.

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.

>> 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?

 
>> 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.

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 09:41:01 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.