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

Re: Move Tracking in the Update Editor

From: Branko Čibej <brane_at_wandisco.com>
Date: Fri, 30 Aug 2013 16:56:17 +0200

On 30.08.2013 13:03, Julian Foad wrote:
> I'm working on how the update editor can handle moves. It's more
> complex than the commit editor, because there can be multiple
> instances of the "same" repository node in the WC, so moves are not
> necessarily unique.
> This is a copy of my notes in progress. I could use some suggestions
> or thoughts if you have any?

It strikes me that if for update-like edits, which are driven by the
server, the once rule is interpreted in terms of WC paths, not node URLs
or node IDs; then the server already has all the information it needs to
transform the working copy.

Take your first multiple source example:

| |
+-- A mv--\ |
| \ |
+-- B mv--\ \ |
            \-\--> +-- C

The working copy really doesn't have to know that both A and B became C.
It only has to represent the final state. this can be described as:

    move A, C; delete B


    move B, C; delete A

and any text modifications are applied after the move. The only real
difference between the two descriptions is that one of them /may/ be
more efficient, in the sense that the delta that represents the text
modifications on C may be smaller. But that's a minor optimization; if
the server can do it, fine; if not, we're still better off than in the
copy+delete case, especially for deep directory trees.

-- Brane

Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com
Received on 2013-08-30 16:56:57 CEST

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