Re: Changes to emacs-23 branch and the trunk

[Kenichi Handa]

In article <address@hidden>, Stefan Monnier <address@hidden> writes:

> > I'm going to fix the display-table related problem in >
> emacs-23 branch.  But, the diff of the change will
> conflict > with the trunk code.  As I'm afraid that it's
> not a simple > work to resolve that confliction, I want to
> apply the same > change to the trunk code by myself.

> It's basically easy:

>    cd .../trunk
>    bzr merge .../emacs-23
>    <resolve&commit>
   
>    cd .../emacs-23
>    <make-change>
>    bzr commit -m ...
>    cd .../trunk
>    bzr merge .../emacs-23
>    bzr revert .
>    <make-the-change-by-hand>
>    bzr commit -m "Merge by hand from emacs-23">

Thank you for the detailed procedure, but I'm not working
directly in emacs-23 and trunk branches but in "Task
Branches".  I have these branches:

trunk -- bound to upstream
emacs-23 -- bound to upstream
work -- made by "bzr branch trunk work"
work-23 -- made by "bzr branch emacs-23 work-23"

And, this is my workflow for Emacs 23:

A % cd work-23
  <make-change>
  % bzr commit -m 'my change'
  % cd ../emacs-23
B % bzr up
  <if there's no new change, go to step C)
  % cd ../work-23
  % bzr merge
  <resolve conflicts if any>
  % bzr commit -m 'merge emacs-23'
  % cd ../emacs-23
C % bzr merge ../work-23
  % bzr commit -m 'my change'
  <if it's refused by conflicts, do "bzr revert" and goto step B>
  <go to step A for another work>

So to apply your procedure in the above model, what I should
do is this, right?

A % cd work-23
  <make-change>
  % bzr commit -m 'my change'
  % cd ../emacs-23
B % bzr up
  <assuming that there's no new change>
C % bzr merge ../work-23
  % bzr commit -m 'my change'
  % cd ../work
  % bzr merge ../emacs-23
  <fix conflicts>
  % bzr commit -m "Merge by hand from emacs-23"
  % cd ../trunk
  % bzr up
  <assuming that there's no new change>
  % bzr commit -m "Merge by hand from emacs-23"

Does this surely records that the trunk already took in my
change for emacs-23?  I think that's necessary to avoid
future double merging.

---
Kenichi Handa
address@hidden