Re: Bazaar workflow for GRUB

[Colin D Bennett <colin@gibibit.com>]

[-- Attachment #1: Type: text/plain, Size: 3498 bytes --]

On Mon, 18 Jan 2010 18:15:37 +0000
Colin Watson <cjwatson@ubuntu.com> wrote:

> On Mon, Jan 18, 2010 at 09:49:15AM -0800, Colin D Bennett wrote:
> > Do you want to mention how GRUB committers should merge features to
> > the official trunk branch?  I think the appropriate process,
> > assuming (1) either a merge directive or a feature branch provides
> > the change the we want to merge, and (2) we already have a local
> > mirror branch of GRUB's trunk branch:
> > 
> >   # 1. Update local trunk mirror.
> >   cd trunk
> >   bzr pull
> > 
> >   # 2. Merge the feature branch or merge directive.
> >   bzr merge URL_OF_BRANCH
> >   # (Or bzr merge /path/to/merge_directive.patch)
> >   # If there are conflicts reported, fix them and use “bzr resolve”
> > to # mark them as resolved.
> >   [ make grub ... and test it ]
> > 
> >   # 3. Commit the change locally.
> >   bzr commit
> > 
> >   # 4. Push to the upstream trunk.
> >   bzr push :parent
> >   #   (The :parent argument can be omitted after the first time you
> > do #   this, since Bazaar will remember the given location from that
> >   #   point on as the “push location” for the local branch.)
> >   # Note that in the unlikely event that someone happened to commit
> > to # upstream trunk in the meantime since you did “bzr pull”, Bazaar
> >   # will tell you that the branches have diverged.  You should try
> >   # again, doing “bzr pull --overwrite” and go back to step 2.
> 
> I recommend using a checkout for trunk, because that way bzr takes
> out a write lock on the branch when you start committing and doesn't
> release it until it's finished; it also warns you immediately if
> you're out of date rather than making you commit and try to push
> before you find out. This is a much more robust workflow for shared
> branches in my experience.

Checkouts are ok if used carefully.  Your workflow below looks fine,
but beware if when you try to commit to the trunk checkout there are
new upstream changes, it may in some cases significant work to merge
with your feature work; in this case you'd probably want to be able to
commit the merged code and test it locally before committing again.
This is where I'd merge trunk back to my feature branch again and get
it clean again before proceeding with the commit to trunk.

I mainly afraid of trunk checkouts because it tempts people to
actually make code changes directly in the checkout, which is a recipe
for problems:  Before you could commit your changes at all, bzr would
require you to run 'bzr update' which would automatically merge your
uncommitted changes... oh, a bad automatic merge and you'd like to go
back to your code before the update? that's too bad: You can't
automatically undo it and get back to your (uncommitted) changes.

> The workflow for a trunk checkout, based on what you have above, is
> simply:
> 
>   # 1. Update local trunk checkout.
>   cd trunk
>   bzr update
> 
>   # 2. Merge the feature branch or merge directive.
>   bzr merge URL_OF_BRANCH
>   # (Or bzr merge /path/to/merge_directive.patch)
>   # If there are conflicts reported, fix them and use “bzr resolve” to
>   # mark them as resolved.
>   [ make grub ... and test it ]
> 
>   # 3. Commit the change.
>   bzr commit
>   # If someone happened to commit to upstream trunk since you did “bzr
>   # update”, Bazaar will tell you that you need to update again.
> 

Regards,
Colin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]