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

Re: Moves in FSFS

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Thu, 19 Sep 2013 14:58:43 +0100 (BST)

Branko Čibej wrote:
> On 19.09.2013 12:09, Julian Foad wrote:
>> Branko Čibej wrote:
>>> On 17.09.2013 12:55, Julian Foad wrote:
>>>> branch the trunk:
>>>>
>>>>    r20:
>>>>      trunk
>>>>        /A
>>>>        /B
>>>>      branch
>>>>        /A (pointer to /trunk/A)
>>>>        /B (pointer to /trunk/B)
>>>>
>>>> modify branch/A:
>>>>
>>>>    r30:
>>>>      trunk
>>>>        /A
>>>>        /B
>>>>      branch
>>>>        /A
>>>>        /B (pointer to /trunk/B)
>> [...]
>>
>>    r40: move A to C, and move B to D

I meant on the branch...

>>  So the repository in r40 looks like:
>>
>>    r40:
>>      trunk
>>        /A
>>        /B
>>      branch
>>        /C
>>        /D

... but it will make the problem even clearer if we also do it on trunk at the same time, ending up with:

  r40:
    trunk
      /C (was moved from /trunk/A_at_30)
      /D (was moved from /trunk/B_at_30)
    branch
      /C (was moved from /branch/A_at_30)
      /D (was moved from /branch/B_at_30)

>> Now we query: for each path in 'branch' in r20, where is "it"
>> (the same node-line) in r40?  The query is to be answered without
>> scanning all intervening revisions sequentially.
>
> Fine, but this has nothing at all to do with moves. It's the
> forward-history search problem, [...].  I don't know why you're
> trying to optimize that as part of the move design.

Although I'd *like* a more optimal solution, I acknowledge that talking about the cost may be distracting us from the semantics.  So forget I mentioned that.

The key point here is that there needs to be a *unique* solution for where branch/B_at_20 has been moved to in r40.  With copies, of course, there is not a unique solution when we follow history forward because there can be multiple copies, but following moves forward through history must produce a unique path (at each revision).

The specific difficulty is that branch/B_at_20 does not yet have its own copy-id, it shares it with trunk/B_at_20.  I'm saying that if you try to specify an algorithm that traces the moves that lead from branch/B_at_20 to branch/D_at_40 using just (node-id, copy-id), you will go looking at the parent directories to see if there any copies involved, and if the nodes you're looking at are lazy-copied, and in doing so you will calculate a derived attribute that is equivalent to "node-line-id".

- Julian
Received on 2013-09-19 15:59:40 CEST

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