[Gnu-arch-users] Completely distributed development

[Matthieu Moy]

[ Xpost on gnu-arch-users and xtla-el-dev ]

Hi all,

We're  having   some  (minor)   troubles  with  merging   with  xtla's
development.

Our  approach  is  completely   distributed.  No  real  main  archive,
everybody merge from everybody from  time to time. The typical session
is:

1) Look at missing patches from all the contributors

2) Merge all of them

3) Hack hack hack

4) Commit

5) if (!too_tired) goto 3)

6) sleep.

Now, let's take a problematic case.

"A" writes something stupid (Err,  to be honest, this is inspired from
a real situation in which I was "A" ;-).

"B" comes and merges the stupid patch from "A"

"A" reverts his stupid patch.

At this  point, "A"'s  archive is OK,  and "B"  has the bug.  Now, "C"
comes in the game and merges both the wrong patch and the revertion of
the  patch.  (calling star-merge  on  the  latest  patch) His  archive
doesn't have  the bug. Now,  "C" continues merging from  his partners,
and merges from "B". Then, he merges the wrong patch again, and at the
end of the merge, he has no missing patch and a bug in his local tree.

So, the question is: How to avoid that?

In our example, if "C" had merged from "B" first, he would have merged
the wrong  patch, and the wrong  patch would have  disapeared from the
list of missing patches from "A"  for "C". Then, "C" would have merged
the remaining missing patches,  which contain the patch revertion.

So,  in our typical  session above,  we should  add "1.1)  compute the
version  to  merge first".  We  can't  avoid  conflicts introduced  by
concurrent edition of  the same portion of file,  but we can eliminate
those introduced by a wrong merging strategy.

The answer is : Merge first  the patches that haven't been merged from
other partners yet.

More formally, we can consider the set of patches as a directed graph.
Vertices are  the revisions,  and an  edge A ->  B corresponds  to the
relation "A contains the patch of B". A directed edge induces a timing
relation : A was created after B, so, we can be sure there's no cycles
here.  We have  therefore a  DAG.  At least  one of  the revisions  is
therefore a "source". (A vertice with no ingoing edge)

So, our problem has (theoretical) a solution :-)

I'm now  looking for  a _practical_ solution:  What's the best  way to
compute the first  patch to merge? Has tla a feature  to do this? Will
it have in the future? Do we have to implement it in the front-end? 

I'd like to be able to type something like

$ tla unmerged-missing version1 version2 version3 version4

That would list the candidates for a clean merge. 

Thanks for reading till the end, thanks for any kind of advice, ...

--
Matthieu