Re: [Gnu-arch-users] Completely distributed development

[David Allouche]

On Sat, Jun 05, 2004 at 12:35:42AM +0200, Matthieu Moy wrote:
> 
> "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.

How was the reversion done?

It looks like it was done with simple:

   tla replay --reverse REV
   tla commit

instead of the (in that case) more correct:

   tla replay --reverse REV
   tla sync-tree [*]
   tla commit

If there had been a sync-tree, merging B->C would have caused a conflict
because the patchlog of the bad patch would have already been present in C.

> 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.

That also holds if sync-tree is used. So your problem seems solved.

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

Seems like a useful operator for fully-distributed development... But it
must be implemented carefully to behave consistently when commits occurs
concurrently. The listing of existing revisions of each version must
only be fetched once.

> 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 can see how that could be implemented:

  0. Vx is revision x, one of the versions we want to merge with
     m is the count of Vx versions
     n := 0
  
  1. for every revision R in missing revsions of Vn

     for every version W!=Vn for which R contains a patchlog

         set W.notsource

  2. Increment n

  3. If n == m, END
  
  4. If Vn.notsource, goto 2

  5. goto 1
  
> 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. 

This operator should return a list of REVISIONS to merge with. These
revisions would be the last revision for each source version at the time
that version was handled in step 1.

Yet, I think your problem can be more simply solved by correct reversion
of erroneous patches.

-- 
                                                            -- ddaa