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

[Zenaan Harkness]

On Sat, 2004-09-11 at 09:16, Matthieu Moy wrote:
> Aaron Bentley <address@hidden> writes:
...
> 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?

Merging from different trees is I think the "can't be solved in the
general case" point that Tom made. This seems to be highlighted by
your diagrams above.

If merging from the "same archive" (?), empirical physical limit
questions show we can comfortably seralize all changes to the 'core
tree' (with say your lock proposal). It actually surprises me that
there is no locking already - actually "significantly impresses"
would be a better phrase ...

Serialization is not a performance problem in the (vastly) common
case, as per for example the Linux kernel usage of Bitkeeper:

 - how many Developers = D

 - how long to make a change, so how many Changes per time = C

 - therefore Volume of changes per time period:
   V = D * C / time in a week

and the point being that this number is so relatively low,
that you can say "lets all keep synchronized and serialized
(with a centralized branch)" and have a pretty small box keep
up with the load.

The empirical argument is that the Linux kernel is about as large
a single software project as it gets (code size and developer
count), and with a modern version control system, they're getting
10MB of changes into the primary trunk on a monthly basis.

It's impressive.

And I think the 10MB limit is purely people-based, nothing like
technology based.

So, we have a generalized overlapping transaction platform,
and some (at least I) would like a more specialized layer
on top of this (equivalent to our favourite modern SCM
competitor).

However I do feel as though there are opportunities to do better,
achieving something more useful with the (tla) platform as it
currently stands.

In the meantime I do just want to get my day job done though...