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

Re: short question about merge [PROPOSAL] vs. tree-deltas

From: Tom Lord <lord_at_emf.net>
Date: 2003-04-17 01:08:52 CEST


>>>> Let's suppose that the trees for ANCESTOR and ORIG have:

>>>> dir1/file1 == node_N.copy_C.rev_R
>>>> dir2/file2 == node_N.copy_C.rev_R

>>>> (Note that the two file-rev nodes are identical.)


>>> This can't happen AFAIK.


>> At present two files can only share the same node revision id if they
>> are the result of copying directories, in which case the files will
>> have the same basename. [....]

>> can occur.

That's what I thought. I haven't seen it in svn, but can imagine, an
interface that _might_ be able to hide that duplication of nodrev ids
with some virtual nodes. If there is such an interface -- please
point me to the code.

> From: =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <brane@xbc.nu>

> Yes, that can occur... (sorry Sander, I didn't think of lazy
> copying). However, in that case, it's the same file, there's
> nothing to merge

Tree deltas and ambiguity about "corresponding files" between two
trees. _Maybe_ I'll have more to say about that soon. Honestly: I'm
still puzzling it out and the outcome might be "Ain't gonna work" (my
pretty strong _bet_) or "Oh crap -- works perfectly well" (which I'll
cop to if that's the conclusion I reach.)


> I was simply responding to Sander's point, but from a brief
> look at Tom's scenario it appears that the file names don't
> really matter. So whether these two files have the same
> basename doesn't affect the his question.

Just as an intermediate core-dump of my puzzling things out:

Your going to wind up with, _at_best_, the ability to fairly cheaply
compute a copy/rename history of any given noderev. That's a pretty
non-trivial problem actually -- it's going to impact various commands
and it's hard to do without screwing up the cost of copy. I still
don't see any way to do it without really screwing the _worst_case_
space consequences of copy --- but let's assume that probabilisticly,
you can make that rename/copy history computable without too many

You absolutely need such history for v.a.p. tree-deltas.

Then the question is: does that history give you results that are
unambiguous, useful, easy to control, unsurprising, etc.... And my
_bet_, based on analysis so far, is "no". But again -- in problem
spaces like this, there's always surprises. And I may wind up doing
nothing more than "double-checking Sander's math" and endorsing his
approach. But if I had to bet my last $50 ...... :-)


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 17 00:58:58 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.