[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Star-merge Fatally Wounded
From: |
Matthieu Moy |
Subject: |
Re: [Gnu-arch-users] Star-merge Fatally Wounded |
Date: |
Sat, 11 Sep 2004 01:16:21 +0200 |
User-agent: |
Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) |
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
- [Gnu-arch-users] Star-merge Fatally Wounded, David Allouche, 2004/09/10
- Re: [Gnu-arch-users] Star-merge Fatally Wounded, Aaron Bentley, 2004/09/10
- Re: [Gnu-arch-users] Star-merge Fatally Wounded, Tom Lord, 2004/09/10
- Re: [Gnu-arch-users] Star-merge Fatally Wounded, Aaron Bentley, 2004/09/10
- Re: [Gnu-arch-users] Star-merge Fatally Wounded, Adrian Irving-Beer, 2004/09/10
- Re: [Gnu-arch-users] Star-merge Fatally Wounded, David Allouche, 2004/09/11
- Re: [Gnu-arch-users] Star-merge Fatally Wounded, Jan Hudec, 2004/09/11
Re: [Gnu-arch-users] Star-merge Fatally Wounded, David Allouche, 2004/09/10
Re: [Gnu-arch-users] Star-merge Fatally Wounded, Tom Lord, 2004/09/10
Re: [Gnu-arch-users] Star-merge Fatally Wounded, Zenaan Harkness, 2004/09/10