Bazaar workflow for GRUB

Bazaar workflow for GRUB

[BVK Chaitanya]

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

Hi,


Attached is the initial version of workflow document for GRUB
contributions.  I am yet to get right DVCS right, so I suspect it
might have minor differences from what other developers are following
already.

Let me know your comments.


-- 
bvk.chaitanya

[-- Attachment #2: wf.org.txt --]
[-- Type: text/plain, Size: 5158 bytes --]

GNU GRUB Workflow

GNU GRUB project recently switched its VCS from subversion to modern
distributed VCS, Bazaar.  Distributed nature of Bazaar provides much
better support for working off-line and independently than Subversion.
So GRUB developers now recommend below workflows for contributors.

* For Occasional Contributors

This workflow is recommended for users/developers who want to fix
just-one GRUB issue.  This involves a trunk checkout, some local
commits (as necessary for fixing the issue) and sending the patch to
[[http://lists.gnu.org/archive/html/grub-devel][grub-devel]] mailing list.  GRUB maintainers would take care of
committing it to the trunk.

If any changes are suggested by others in the mailing list, developer
can then implement them as many times as necessary and can send the
updated patch.

Note that, since GNU GRUB project is based on volunteer work, a patch
may not immediately get committed into the trunk.  So after a patch is
mailed to the mailing list and accepted by others, it is safe to
assume it would be eventually gets committed to the trunk.

An example workflow would look as below:

#+BEGIN_SRC shell-script
$ bzr branch http://bzr.savannah.gnu.org/r/grub/trunk/grub grub
$ cd grub

# ... hack hack hack ...
grub$ bzr commit -m 'fixed my issue'

# ... ah, you forgot adding somefile ...
grub$ bzr commit -m 'added missing somefile'

# create a patch and send to mailing list
grub$ bzr diff -r submit: > ~/my-issue-fix.diff

# update as per review comments
grub$ bzr commit  -m 'updated as per review comments'

# create a new patch and resend to mailing list
grub$ bzr diff -r submit: > ~/my-issue-fix-updated.diff
#+END_SRC

Notice that GRUB 2 is =trunk/grub= directory, instead of =trunk= itself.


* For Regular GRUB Contributors

Regular GRUB developers are advised to work in separate branches for
each bug fix or feature they work on.  They need to merge the trunk
periodically into their branches until their work gets reviewed and
merged into the trunk.  So it would be more beneficial to keep a
pristine trunk locally.

For example:

#+BEGIN_SRC shell-script
# Make a pristine trunk mirror
$ bzr branch sftp://username@bzr.sv.gnu.org/srv/bzr/grub/trunk/grub/ trunk

# Create feature branches from trunk
$ bzr branch trunk feature-foo
$ cd feature-foo

# ... hack on feature-foo ...
feature-foo$ bzr commit -m 'initial foo support
# ... hack more ...
feature-foo$ bzr commit -m 'more of foo'

# create a patch for review
feature-foo$ bzr diff -r submit: > ~/feature-foo.diff

# add code review suggestions
feature-foo$ bzr commit -m 'added code review suggestions'

# its too long, pull-in trunk
feature-foo$ bzr merge ../trunk

# resolve conflicts
feature-foo$ bzr commit -m 'merged trunk'

# send updated patch for review again
feature-foo$ bzr diff -r submit: > ~/feature-foo-updated.diff

# when review finishes, push it to branches
feature-foo$ bzr push sftp://username@bzr.sv.gnu.org/srv/bzr/grub/branches/feature-foo
#+END_SRC

Workflow for multiple features would also look similar to above,
except that pristine trunk checkout is not necessary.

Sometimes it might be useful to push partially complete feature
branches to bzr.sv.gnu.org/srv/bzr/grub/branches before it can be
reviewed.

** Experimental Branch

When a feature development is complete, i.e. code is reviewed and
accepted, it goes through a staging branch, =experimental= where it
gets tested for sometime before it is migrated into the trunk.

This staging area would allow the trunk branch always in a valid and
releasable state.

** Handling inter-dependent features

Sometimes one feature may depend on another feature which is not yet
merged into the trunk; in these scenarios also, it is advised to
create all feature branches from trunk.  A dependant branch can pull
in its dependencies appropriately.

A dependant branch can be committed to trunk only after all feature
branches it depends on are committed into trunk.  Any changes happened
in its dependencies can be pulled in later by performing a periodic
trunk merge.

Taking =bzr diff= of a feature branch can become tricky if it has
merges from multiple feature branches, so developers should try to
minimize such dependencies across features.

** Using Per Developer Branches

GRUB developers can make use per developer branches to share their
incomplete works with others or to be able to work from different
machines at different places.  After creating a per developer branch,
following /centralized/ workflow model using "bzr checkout" is
sufficient.

For example:

#+BEGIN_SRC shell-script

# Create a per developer branch
$ bzr branch sftp://username@bzr.sv.gnu.org/srv/bzr/grub/trunk/grub/ \
    sftp://username@bzr.sv.gnu.org/srv/bzr/grub/branches/feature-foo

# Checkout a copy
$ bzr checkout sftp://username@bzr.sv.gnu.org/srv/bzr/grub/branches/feature-foo
$ cd feature-foo

# ... hack hack hack ...
feature-foo$ bzr commit -m 'commit message'
#+END_SRC

In this model, every =bzr commit= updates the repository at the
server.  In cases when internet connection is not available,
developers can make use of "bzr commit --local" command to commit
locally.

Re: Bazaar workflow for GRUB

[Bruce Dubbs]

BVK Chaitanya wrote:

> Attached is the initial version of workflow document for GRUB
> contributions.  I am yet to get right DVCS right, so I suspect it
> might have minor differences from what other developers are following
> already.

I can't comment on details, but thank you for this.  It is very helpful 
to me.

   -- Bruce

Re: Bazaar workflow for GRUB

[Colin D Bennett]

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

On Thu, 14 Jan 2010 15:01:41 +0530
BVK Chaitanya <bvk.groups@gmail.com> wrote:

> Hi,
> 
> 
> Attached is the initial version of workflow document for GRUB
> contributions.  I am yet to get right DVCS right, so I suspect it
> might have minor differences from what other developers are following
> already.
> 
> Let me know your comments.
> 
> GNU GRUB Workflow
> 
> GNU GRUB project recently switched its VCS from subversion to modern
> distributed VCS, Bazaar.  Distributed nature of Bazaar provides much
> better support for working off-line and independently than Subversion.
> So GRUB developers now recommend below workflows for contributors.
> 
> * For Occasional Contributors
> 
> This workflow is recommended for users/developers who want to fix
> just-one GRUB issue.  This involves a trunk checkout, some local
> commits (as necessary for fixing the issue) and sending the patch to
> [[http://lists.gnu.org/archive/html/grub-devel][grub-devel]] mailing
> list.  GRUB maintainers would take care of committing it to the trunk.

I would avoid using the word “checkout” except when an actual Bazaar
checkout (heavyweight or lightweight) is being used.  I think the
workflow you describe (avoiding checkouts) keeps things simpler since
checkouts behave differently than branches in some cases, and branches
with the “pull” command can do everything that a regular checkout can.

> If any changes are suggested by others in the mailing list, developer
> can then implement them as many times as necessary and can send the
> updated patch.
> 
> Note that, since GNU GRUB project is based on volunteer work, a patch
> may not immediately get committed into the trunk.  So after a patch is
> mailed to the mailing list and accepted by others, it is safe to
> assume it would be eventually gets committed to the trunk.
> 
> An example workflow would look as below:
> 
> #+BEGIN_SRC shell-script
> $ bzr branch http://bzr.savannah.gnu.org/r/grub/trunk/grub grub
> $ cd grub
> 
> # ... hack hack hack ...
> grub$ bzr commit -m 'fixed my issue'
> 
> # ... ah, you forgot adding somefile ...
> grub$ bzr commit -m 'added missing somefile'
> 
> # create a patch and send to mailing list
> grub$ bzr diff -r submit: > ~/my-issue-fix.diff

Why not use “bzr send -o ~/my-issue-fix.patch” to create a merge
directive+patch+revision bundle?  The benefit of bzr send over plain bzr
diff is that individual revisions within the change are preserved,
which can provide richer history.  Merge directives can simply be
applied with “bzr merge my-issue-fix.patch”.

As well as including detailed revision data (including file move/rename
operations), a merge directive also indicates to Bazaar the base
revision of GRUB trunk that the patch's revisions are made against;
making merging it much easier in case other changes have been made to
GRUB trunk in the interval before the patch is committed to trunk.
Bazaar will automatically do a real three-way merge with a merge
directive, whereas applying a patch with the regular “patch” command
would not have as much information and would make the user do much more
work in the even of a conflict.

It is also easy to discard sub-revisions when merging a revision bundle
into mainline, if for some reason the committer so desires.

> # update as per review comments
> grub$ bzr commit  -m 'updated as per review comments'
> 
> # create a new patch and resend to mailing list
> grub$ bzr diff -r submit: > ~/my-issue-fix-updated.diff
> #+END_SRC
> 
> Notice that GRUB 2 is =trunk/grub= directory, instead of =trunk=
> itself.
> 
> * For Regular GRUB Contributors
> 
> Regular GRUB developers are advised to work in separate branches for
> each bug fix or feature they work on.  They need to merge the trunk
> periodically into their branches until their work gets reviewed and
> merged into the trunk.  So it would be more beneficial to keep a
> pristine trunk locally.
> 
> For example:

I would recommend or at least mention the option of creating a shared
repository before branching the remote branch.  Whenever a branch is
downloaded to a directory underneath a shared repository in the
directory hierarchy, its revisions are stored in the shared repository
instead of directly in the branch directory.  This means the you can
cheaply clone the branch (or download other remote branches related to
it, for instance) and the common revisions will not be duplicated on
your hard disk or re-transferred across the network.

Before executing the “bzr branch” command, run “bzr init-repo .” in a
directory under which you wish to put your branches.  After this, all
other commands will be the same whether a shared repository is in use
or not.

> #+BEGIN_SRC shell-script
> # Make a pristine trunk mirror
> $ bzr branch sftp://username@bzr.sv.gnu.org/srv/bzr/grub/trunk/grub/
> trunk
> 
> # Create feature branches from trunk
> $ bzr branch trunk feature-foo
> $ cd feature-foo
> 
> # ... hack on feature-foo ...
> feature-foo$ bzr commit -m 'initial foo support
> # ... hack more ...
> feature-foo$ bzr commit -m 'more of foo'
> 
> # create a patch for review
> feature-foo$ bzr diff -r submit: > ~/feature-foo.diff

Again I would strongly recommend using bzr send instead of bzr diff.

> # add code review suggestions
> feature-foo$ bzr commit -m 'added code review suggestions'
> 
> # its too long, pull-in trunk
> feature-foo$ bzr merge ../trunk
> 
> # resolve conflicts
> feature-foo$ bzr commit -m 'merged trunk'
> 
> # send updated patch for review again
> feature-foo$ bzr diff -r submit: > ~/feature-foo-updated.diff
> 
> # when review finishes, push it to branches
> feature-foo$ bzr push
> sftp://username@bzr.sv.gnu.org/srv/bzr/grub/branches/feature-foo
> #+END_SRC
> 
> Workflow for multiple features would also look similar to above,
> except that pristine trunk checkout is not necessary.
> 
> Sometimes it might be useful to push partially complete feature
> branches to bzr.sv.gnu.org/srv/bzr/grub/branches before it can be
> reviewed.
> 
> ** Experimental Branch
> 
> When a feature development is complete, i.e. code is reviewed and
> accepted, it goes through a staging branch, =experimental= where it
> gets tested for sometime before it is migrated into the trunk.
> 
> This staging area would allow the trunk branch always in a valid and
> releasable state.
> 
> ** Handling inter-dependent features
> 
> Sometimes one feature may depend on another feature which is not yet
> merged into the trunk; in these scenarios also, it is advised to
> create all feature branches from trunk.  A dependant branch can pull
> in its dependencies appropriately.
> 
> A dependant branch can be committed to trunk only after all feature
> branches it depends on are committed into trunk.  Any changes happened
> in its dependencies can be pulled in later by performing a periodic
> trunk merge.
> 
> Taking =bzr diff= of a feature branch can become tricky if it has
> merges from multiple feature branches, so developers should try to
> minimize such dependencies across features.
> 
> ** Using Per Developer Branches
> 
> GRUB developers can make use per developer branches to share their
> incomplete works with others or to be able to work from different
> machines at different places.  After creating a per developer branch,
> following /centralized/ workflow model using "bzr checkout" is
> sufficient.
> 
> For example:
> 
> #+BEGIN_SRC shell-script
> 
> # Create a per developer branch
> $ bzr branch sftp://username@bzr.sv.gnu.org/srv/bzr/grub/trunk/grub/ \
>     sftp://username@bzr.sv.gnu.org/srv/bzr/grub/branches/feature-foo
> 
> # Checkout a copy
> $ bzr checkout
> sftp://username@bzr.sv.gnu.org/srv/bzr/grub/branches/feature-foo $ cd
> feature-foo
> 
> # ... hack hack hack ...
> feature-foo$ bzr commit -m 'commit message'
> #+END_SRC
> 
> In this model, every =bzr commit= updates the repository at the
> server.  In cases when internet connection is not available,
> developers can make use of "bzr commit --local" command to commit
> locally.

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.

When you are done pushing your change to upstream trunk, running
“bzr missing” in your local trunk mirror should indicate there are no
extra or missing revisions in your local trunk.


Good work on the document!

Regards,
Colin

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

Re: Bazaar workflow for GRUB

[Colin Watson]

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.

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.

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: Bazaar workflow for GRUB

[Colin D Bennett]

[-- 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 --]

Re: Bazaar workflow for GRUB

[Robert Millan]

On Mon, Jan 18, 2010 at 12:48:56PM -0800, Colin D Bennett wrote:
> 
> I mainly afraid of trunk checkouts because it tempts people to
> actually make code changes directly in the checkout,

I think this is fine for small changes.  Bigger efforts can easily use a
branch (either local or published) and then merge it into trunk.

We had worse problems with the situation Colin Watson described.

-- 
Robert Millan

  "Be the change you want to see in the world" -- Gandhi

Re: Bazaar workflow for GRUB

[BVK Chaitanya]

On Mon, Jan 18, 2010 at 11:45 PM, Colin Watson <cjwatson@ubuntu.com> wrote:
>
> 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.
>

These are the exact features I want for the trunk branch.  How
different is a checkout from a branch?  Can i create feature
*branch*es from a *checkout*, like in:

bzr checkout sftp://bvk@bzr.sv.gnu.org/srv/bzr/grub/trunk/grub trunk
bzr branch trunk feature-foo

How different would such a feature branch be, from regular branch?


thanks,
-- 
bvk.chaitanya

Re: Bazaar workflow for GRUB

[Colin Watson]

On Tue, Jan 19, 2010 at 09:57:07AM +0530, BVK Chaitanya wrote:
> On Mon, Jan 18, 2010 at 11:45 PM, Colin Watson <cjwatson@ubuntu.com> wrote:
> > 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.
> 
> These are the exact features I want for the trunk branch.  How
> different is a checkout from a branch?

The best answer is probably to point you at 'bzr help checkouts'.

> Can i create feature *branch*es from a *checkout*, like in:
> 
> bzr checkout sftp://bvk@bzr.sv.gnu.org/srv/bzr/grub/trunk/grub trunk
> bzr branch trunk feature-foo

Yes.

> How different would such a feature branch be, from regular branch?

No difference.

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: Bazaar workflow for GRUB

[BVK Chaitanya]

On Mon, Jan 18, 2010 at 11:19 PM, Colin D Bennett <colin@gibibit.com> wrote:
>>
>> * For Occasional Contributors
>>
>> This workflow is recommended for users/developers who want to fix
>> just-one GRUB issue.  This involves a trunk checkout, some local
>> commits (as necessary for fixing the issue) and sending the patch to
>> [[http://lists.gnu.org/archive/html/grub-devel][grub-devel]] mailing
>> list.  GRUB maintainers would take care of committing it to the trunk.
>
> I would avoid using the word “checkout” except when an actual Bazaar
> checkout (heavyweight or lightweight) is being used.  I think the
> workflow you describe (avoiding checkouts) keeps things simpler since
> checkouts behave differently than branches in some cases, and branches
> with the “pull” command can do everything that a regular checkout can.


Yes, I will replace checkout with "copy" or something.

Yes, I wanted to keep it simple so I suggested bzr branch (instead of
bzr checkout) everywhere.  GRUB branch is small (about 15MB), so IMO
there is not much to gain in checkout than a branch.


>>
>> # create a patch and send to mailing list
>> grub$ bzr diff -r submit: > ~/my-issue-fix.diff
>
> Why not use “bzr send -o ~/my-issue-fix.patch” to create a merge
> directive+patch+revision bundle?  The benefit of bzr send over plain bzr
> diff is that individual revisions within the change are preserved,
> which can provide richer history.  Merge directives can simply be
> applied with “bzr merge my-issue-fix.patch”.
>

I haven't seen anybody sending "bzr send" patches in the ML, so I
didn't want to introduce something new.  Is its format compatible with
regular patch tool?

>
> It is also easy to discard sub-revisions when merging a revision bundle
> into mainline, if for some reason the committer so desires.


bzr revert --forget-merges?


>
> I would recommend or at least mention the option of creating a shared
> repository before branching the remote branch.  Whenever a branch is
> downloaded to a directory underneath a shared repository in the
> directory hierarchy, its revisions are stored in the shared repository
> instead of directly in the branch directory.  This means the you can
> cheaply clone the branch (or download other remote branches related to
> it, for instance) and the common revisions will not be duplicated on
> your hard disk or re-transferred across the network.
>
> Before executing the “bzr branch” command, run “bzr init-repo .” in a
> directory under which you wish to put your branches.  After this, all
> other commands will be the same whether a shared repository is in use
> or not.


I will add an entry for this.


>
> Do you want to mention how GRUB committers should merge features to the
> official trunk branch?


Yeah, I completely forgot about this one.  I need to add a new section.


thanks,
-- 
bvk.chaitanya

Re: Bazaar workflow for GRUB

[Michal Suchanek]

2010/1/19 BVK Chaitanya <bvk.groups@gmail.com>:
> On Mon, Jan 18, 2010 at 11:19 PM, Colin D Bennett <colin@gibibit.com> wrote:

>>>
>>> # create a patch and send to mailing list
>>> grub$ bzr diff -r submit: > ~/my-issue-fix.diff
>>
>> Why not use “bzr send -o ~/my-issue-fix.patch” to create a merge
>> directive+patch+revision bundle?  The benefit of bzr send over plain bzr
>> diff is that individual revisions within the change are preserved,
>> which can provide richer history.  Merge directives can simply be
>> applied with “bzr merge my-issue-fix.patch”.
>>
>
> I haven't seen anybody sending "bzr send" patches in the ML, so I

Perhaps they did not know or did not need to. AFAICT there isn't any
rebase feature in bzr so sending these is the only option for longer
lasting local branches.

> didn't want to introduce something new.  Is its format compatible with
> regular patch tool?

Yes, they do include something that looks like a regular patch.
Did not try applying it, though.

Thanks

Michal

Re: Bazaar workflow for GRUB

[Colin D Bennett]

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

On Tue, 19 Jan 2010 11:52:27 +0100
Michal Suchanek <hramrach@centrum.cz> wrote:

> 2010/1/19 BVK Chaitanya <bvk.groups@gmail.com>:
> > On Mon, Jan 18, 2010 at 11:19 PM, Colin D Bennett
> > <colin@gibibit.com> wrote:
> 
> >>>
> >>> # create a patch and send to mailing list
> >>> grub$ bzr diff -r submit: > ~/my-issue-fix.diff
> >>
> >> Why not use “bzr send -o ~/my-issue-fix.patch” to create a merge
> >> directive+patch+revision bundle?  The benefit of bzr send over
> >> plain bzr diff is that individual revisions within the change are
> >> preserved, which can provide richer history.  Merge directives can
> >> simply be applied with “bzr merge my-issue-fix.patch”.
> >>
> >
> > I haven't seen anybody sending "bzr send" patches in the ML, so I
> 
> Perhaps they did not know or did not need to. AFAICT there isn't any
> rebase feature in bzr so sending these is the only option for longer
> lasting local branches.

There is actually a ‘rebase’ plugin for bzr (“bzr branch lp:bzr-rebase
$HOME/.bazaar/plugins/rebase” to install for a user).  I'm not sure how
‘bzr send’ is in some way more useful if a rebase operation was not
available, however.

> > didn't want to introduce something new.  Is its format compatible
> > with regular patch tool?
> 
> Yes, they do include something that looks like a regular patch.
> Did not try applying it, though.

The output of ‘bzr send’ normally includes three parts:

1. Merge directive.  This specifies what branch the patch is against
as well as other information about it.  This can be the only part if the
changes are available in a publicly accessible branch.

2. Patch.  This is standard unified diff format and can be applied with
the patch command.

3. Revision bundle.  This contains the actual complete revision data
for the changes.  Each individual committed revision including log
messages, renamed files, merge history, etc., is included in the
revision bundle.  This is a chunk of binary data encoded to ASCII.
When the revision bundle is provided, no public branch containing the
patch's changes is required to be available.

In short, the ‘bzr send’ output can be treated as a standard patch for
review purposes as well as for application using the patch command,
but using ‘bzr merge’ for merge these special patches provides richer
history and much better automatic merges than would be obtained by
using the standard patch command.

Regards,
Colin

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

Re: Bazaar workflow for GRUB

[Michal Suchanek]

2010/1/19 Colin D Bennett <colin@gibibit.com>:
> On Tue, 19 Jan 2010 11:52:27 +0100
> Michal Suchanek <hramrach@centrum.cz> wrote:
>
>> 2010/1/19 BVK Chaitanya <bvk.groups@gmail.com>:
>> > On Mon, Jan 18, 2010 at 11:19 PM, Colin D Bennett
>> > <colin@gibibit.com> wrote:
>>
>> >>>
>> >>> # create a patch and send to mailing list
>> >>> grub$ bzr diff -r submit: > ~/my-issue-fix.diff
>> >>
>> >> Why not use “bzr send -o ~/my-issue-fix.patch” to create a merge
>> >> directive+patch+revision bundle?  The benefit of bzr send over
>> >> plain bzr diff is that individual revisions within the change are
>> >> preserved, which can provide richer history.  Merge directives can
>> >> simply be applied with “bzr merge my-issue-fix.patch”.
>> >>
>> >
>> > I haven't seen anybody sending "bzr send" patches in the ML, so I
>>
>> Perhaps they did not know or did not need to. AFAICT there isn't any
>> rebase feature in bzr so sending these is the only option for longer
>> lasting local branches.
>
> There is actually a ‘rebase’ plugin for bzr (“bzr branch lp:bzr-rebase
> $HOME/.bazaar/plugins/rebase” to install for a user).  I'm not sure how
> ‘bzr send’ is in some way more useful if a rebase operation was not
> available, however.

It contains the revision bundle.

With rebase you can send a series of patches which apply on the latest
trunk and each have their own description.

Failing to rebase you get only one huge merged patch and have to rely
on the revision bundle to provide the description and separation of
the changesets.

Thanks

Michal

Re: Bazaar workflow for GRUB

[Robert Millan]

On Tue, Jan 19, 2010 at 09:51:21AM +0530, BVK Chaitanya wrote:
> 
> I haven't seen anybody sending "bzr send" patches in the ML, so I
> didn't want to introduce something new.

Please don't let this stop you if you think "bzr send" is useful.  Most
of us are relatively new to Bazaar, so we might be just missing it.

-- 
Robert Millan

  "Be the change you want to see in the world" -- Gandhi