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
or
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. [email protected]
