Re: [Gnu-arch-users] Star-merge Fatally Wounded

[Matthieu Moy]

Aaron Bentley <address@hidden> writes:

> Here is an alternate scenario that does not involve user error:
>
> Brian:
[...]
> % tla star-merge A
>
> Albert:
[...]
> % tla star-merge B
<1> [...]
> Brian:
> % tla commit -s "merged latest A"

<2>

> Albert:
> % tla commit -s "merged latest B"

[...]

> 3. star-merge has all the information it needs to detect this problem.

I don't see how star-merge could do anything. When the second
star-merge is run, (<1> on the above scenario), none of Brian and
Albert can know that something is getting wrong. The first instant
when the problem becomes detectable is <2>, after the first commit,
because then, the patch "merged latest A" becomes visible from Albert.

I can see only two ways to solve the problem without adding more
communication (ie "Hey, brian, don't merge, I'm merging from you"):

* tla commit could check and refuse to commit (Stefan Monier's
  proposal in this thread)

* The *next* star-merge can tell you: "Hey, guy, you've made a
  terrible mistake with your last star-merge, but it's too late,
  you've already commited it."

None of them seem really satisfying to me. But I believe the
additional synchronization can be done from arch itself, using a
locking mechanisme on branches:

* Before getting any information from the FROM branch, the star-merge
  operation of Albert would put a lock on the REFERENCE branch. The
  lock would contain the information "Hey, Brian, don't merge, I'm
  merging from you". Then, the star-merge operation would continue
  normally.

* If Brian tries to star-merge during that time, he will get an error
  or a warning "Hey, this guy is merging from you _right now_. Are you
  sure you want to continue?"

* At commit time, Albert would release the lock.


To understand the problem better, I'd like to add another picture:
T1 and T2 are source trees, and A1 and A2 are archives. 'M' stands for
"star-merge", and 'C' stands for "commit".

The problematic situation is:

 T1     A1        A2      T2
 |      |          |       |
 |      |    M    A2-1     |
 |     -+---------'|       |
 |<---' |          |       |
 |     A1-1--.     |       |
 |      |     `----+-.M    |
 |-.C   |          |  `--->|
 |  `->A1-2        |       |
 |      |          |       |
 |      |          |   C --|
 |      |         A2-2<-'  |
 |      |          |       |

The situation is problematic because the sequence of arrows from A2-1
to A1-2 crossed the one between A1-1 to A2-2. With more
synchronization, this would give ('L' stands for "get the lock", and
X correspond to an archive locked with respect to A2):

 T1     A1        A2      T2
 |--.   |          |       |
 |   --.|          |       |
 |  L.-'X          |       |
 |<--'  X          |       |
 |------+---       |       |
 |      X   `----. |       |
 |      X    M    A2-1     |
 |     -+--------' |       |
 |<---' X          |       |
 |      X          |       |
 |      X          |       |
 |-.C   X          |       |
 |  `->A1-2        |       |
 |      |          |       |

Now, this solution also has a lot of drawbacks. What if Albert finally
decides not to merge, and "rm -rf" his source tree, for example? Also,
how could the case of a shared archive with multiple users trying to
star-merge from the same or from different archives at the same time?

Well, I'm afraid the problem is more complex than it seems to be :-(

-- 
Matthieu