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

[Matthieu Moy]

Robert Collins <address@hidden> writes:

>> 1) Look at missing patches from all the contributors
>> 
>> 2) Merge all of them
>
> you should commit before hacking.
>
>> 3) Hack hack hack

'course ! I meant "Merge /and commit/ all of them" ;-)

>> 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.
>
> But B will eventually revert the patch, at which point C can merge that
> second revert. No problem in general. :}.

Yes and no:  C will have his  software broken and will try  to fix the
bug, which is a loss of time.  And when merging with the next merge of
B, he will get conflicts, which is also a loss of time :-(

> As to dealing with the DAG, you might look at missing --skip-present. 

I'm afraid this is exactly the opposite of what I'm looking for ;-). 

A source  in the DAG is  a "big" merge, and  it will often  be a merge
containing a patch from me:

 Me            A           B            C
              Patch-1---->Patch-1
Patch-1         \
   `-------------+---------------------Patch-1
                  `--------------------Patch-2

Here,  C's archive  is the  most up-to-date,  and all  patches  in his
version  are sources  of the  DAG. This  is the  archvie from  which I
should merge  to avoid  conflicts. Patch-1  is a merge  from me  so it
shouldn't  raise conflicts  (in fact,  it shouldn't  modify  my source
tree, just add  the patch-log), and Patch-2 will  only raise conflicts
if A or B have modified the same portion of file as me.

However, if  I try  "tla missing --skip-present  C", it won't  show me
C--patch-1.

> Oh, and perhaps have two  branches in each repository - experimental
> and devel -  where unless you are sure it's  'cooked', you don't put
> patches from  experimental into devel.  Then users can  track devel,
> and  coders  can track  experimental  or  devel  depending on  their
> resistance to breakage :}.

That's a separate problem. We could but probably we're just to lazy to
do it !

-- 
Matthieu