Doubts w.r.t. development models using Bazaar

[Andrew Bennetts]

Rohit Rai wrote:
[...]
>     That is the model we use for developing Bazaar, and it works very
>     well.  People do their  individual development on their own branch -
>     this can be either totally distributed, or it can be a bound branch
>     shared by a team if they want to work more closely as in cvs/svn.
>     When their work has got to a good stage of completion they post a
>     bundle to the list for others to review.  
> 
>  
> Will the record log that developer XYZ had made the particular change be
> maintained when the PQM commits the paatch to the main repository, or
> everything on the main repository will show up as a commit/development done by
> the PQM. That is important with statistical point of view in a software
> company.At one location I have seen similar flow using SVN, but finally in the
> log we notice that all the commits are made by PQM, and the name of the
> original developer are lost.

The full history is preserved when you do a merge.  The "bzr visualise" command
(part of the bzr-gtk plugin) displays this quite nicely:
    http://samba.org/~jelmer/bzr/bzrk.png

(The main line of development is the lefthand line, all the other lines are
things that have been merged in.)

The output of "bzr annotate" also takes advantage of this, so you'll tend to see
lines attributed to their author, rather than to the person who merged them in.

>     We have a great tool Bundle
>     Buggy that keeps track of things that need review and what comments
>     have been made:
[...]
> 
>  
> The tool's cool :)  What happenes when the patch is rejected?

They are removed from the main listing, but they're still accessible from the
"Rejected" link: http://bundlebuggy.aaronbentley.com/?selected=rejected

>     It's more of a toolkit than the integrated solution of Aegis, but
>     being able to mix central control and close cooperation with
>     distributed work is a very nice feature of Bazaar.
> 
>     --
>     Martin
> 
> I have been wondering about this thing for long, and these are a few questions
> I came up with,
> 
> But then I see quite few problems in this approach too, and wonder will the
> existing tools actually work in this manner,
> 
>  1. First problem is the commit time of the patch may be prolonged at reviewer
>     of gateway post

I'm not sure exactly what you mean here.  The original commits (including their
timestamps) will be part of the history included in the merge when the reviewed
branch is eventually merged.

>  2. Will all the histroy of modifications by the developer and his log comments
>     be maintained?

Yes.  "bzr log" will even show them by default.

>  3. There are a few interesting use cases when, Developer writes a patch and
>     sends it to the reviewer and coninues writing his next patch. What code
>     base should he write this patch against. The global base or his modified
>     base?
>      1. Suppose he writes it against the global code base, in the meanwhile,
>         the reviewer and gatekeeper  approve the patch1 and it makes to the
>         global repos. Does the next patch that the developer sends apply to the
>         global repos when it is sent?
>      2. Suppose he works against his local copy and generates patch2, in the
>         meanwhile his patch1 is rejected and returned to him, he has to revert
>         that patch and keep patch2, how does that work? Does the patch2 apply
>         to the global codebase when approved?

It's best to try keep separate changes in separate branches.  Because bzr makes
it easy to make and merge branches, and preserves history, it's easier to follow
this policy than with systems like SVN.

>      3. How important is the sequence of patches?

Important in what sense?  Are you asking about what happens if you want to merge
only some revisions from a branch, but not all?

>  4. There are few other problems with respect to applying the patch at the
>     global repos and it requiring manual help and stuff.
>  5. can you think of more???
> 
> Regarding to why I am thinking all this, you may visit my blog, http://
> mytechrantings.blogspot.com where I have starteed writing a series of articles
> for the next generation software factory and role of Open Source systems in
> this.

I hope I've helped.

-Andrew.