gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Robert Collins
Subject: Re: [Gnu-arch-users] Completely distributed development
Date: Sat, 05 Jun 2004 15:37:57 +1000

On Sat, 2004-06-05 at 08:35, Matthieu Moy wrote:
> [ 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

you should commit before hacking.

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

But B will eventually revert the patch, at which point C can merge that
second revert. No problem in general. :}.

As to dealing with the DAG, you might look at missing --skip-present. 
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
:}.

Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]