Page History

...

• A switched path points to the same or a different revision of any node

  • No Format
    WC: (A@10, X=^/A@10)

  • No Format
    WC: (A@10, X=^/A@11); repo: (^/A@10 and ^/A@11 are the same node-rev)

• A non-switched path points to a different revision of a moved node

  • No Format
    WC: (A@10, B@20); repo: (mv ^/A@10 ^/B@20)

    
    

The WC does not (currently) know about node-copy-ids, and so does not know that it has multiple instances of the same node, except in the simple case where the URL@REV is the same.

...

During an update, multiple instances of one repository node can move to the same target path, and one instance can move to multiple target paths.

Multiple Sources

• No Format
  WC: (A@10, B@20); repo: (mv A@10 → B@20 → C@30)

• No Format
  Update to r30; A moves to C, and also B moves to C.

  
  

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

...

This case is similar to Multiple Sources, with one important difference. If we assume an editor in which each move is labelled by a move-id, the consumer cannot recognize such a conflict just by examining the move-ids.

• No Format
  WC: (A@10, B@20); repo: (r10: mkdir A; r20: mv A B; edit B; r30:

  edit

  edit B)

• No Format
  Update to r30; A moves to B (with

  Update to r30; A moves to B (with

  edits), and also the existing B is updated.

• No Format
  These changes conflict. A typical resolution would be to merge them: put both sets of local mods into the same B.

  
  

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

Multiple Targets

• No Format
  WC: (A@10, X@10, Y=^/X@10); repo: (mv A@10 → X/A@20)

• No Format
  Update to r20; A moves to X/A and also to Y/A.

  
  

|                   |
+-- A  mv--\        |
|         \ \       |
+-- X      \ \      +-- X
|           \ \-->  |   +-- A
|            \      |
+-- Y         \     +-- Y
               \-->     +-- A

...

Many-to-many move, combining multiple sources with multiple target paths:

• No Format
  WC: r10 (A, B=^/A, X, Y=^/X); repo: (mv A@10 → X/B@20)

• No Format
  Update to r20; A and B both move to X/C and to Y/C.

  
  

With a many-to-many move, there is the possibility that the sources and destinations can be logically paired according to their path-wise nearness. Example, starting from

 WC (

...

trunk1→^/trunk@10,

...

 trunk2→^/trunk@20) and repo (mv trunk/A@10 → trunk/B@20) 

:

|                     |
+-- trunk1            +-- trunk1
|   |                 |   |
|   +-- A   mv--\     |   |
|                \->  |   +-- B
|                     |
+-- trunk2            +-- trunk2
    |                     |
    +-- A   mv--\         |
                 \->      +-- B

...

• The consumer (client/WC) may want to know whether a given move is unique before executing it, so that it can choose to warn or raise a conflict (for example).
• Each move-away is (logically) accompanied by its own edit. For example, with

  No Format
  WC (A@10, B@20), repo (A@10 → B@20 → C@30)

  , one edit applies to A (r10:30) and another edit applies to B (r20:30).
  

...

• Move is a local operation. For example, we can make pairings in this many-to-many move scenario:

  • No Format
    WC: (trunk1=^/trunk, trunk2=^/trunk)

  • No Format
    Repo: (mv trunk/foo to trunk/bar)

  • No Format
    Update: mv trunk1/foo → trunk1/bar; mv trunk2/foo → trunk2/bar.

    
    

Current WC semantics include:

...