Bzr taskbranches and ChangeLog

Bzr taskbranches and ChangeLog

[Tassilo Horn]

Hi,

while reading http://www.emacswiki.org/emacs/BzrForEmacsDevs I don't get
exactly how to deal with ChangeLog entries when working with
taskbranches.

For example, I've just created a local branch bug-16090 which fixes that
bug.  It's complete, but I want to wait with pushing until Stefan had a
look, so I'll surely need to merge from trunk some times.

With git I would commit my changes (no ChangeLog entries right now)
locally, then keep rebasing onto master until Stefan gives his go, then
write the ChangeLog entry, commit that too, squash that commit with the
code change commit, and then push one single commit with the code and
ChangeLog changes.

How do I do something similar with bzr?

When I get the emacswiki page right, I should write my ChangeLog entry
to some temporary file, and then commit locally providing the entries
(without author/date line) as commit message.  Then I keep on merging
from an updated trunk until Stefan gives his go, and then I use the
commit message from the log to create a real ChangeLog entry.  Finally,
I commit that and push.

Correct?  But doesn't that lead to a log like

  - ChangeLog commit
  - Merge commit
  - [...]
  - Merge commit
  - Original code commit


e.g., the eventual ChangeLog commit might be far off the original code
commit it is documenting?

Bye,
Tassilo

Re: Bzr taskbranches and ChangeLog

[Xue Fuqiao]

Maybe bzr's changelog_merge plugin can help with this.  See `bzr help
changelog_merge'.

Re: Bzr taskbranches and ChangeLog

[Tassilo Horn]

Xue Fuqiao <xfq.free@gmail.com> writes:

> Maybe bzr's changelog_merge plugin can help with this.  See `bzr help
> changelog_merge'.

That sounds exactly like what I'm looking for.

Thanks,
Tassilo

Re: Bzr taskbranches and ChangeLog

[Tassilo Horn]

Tassilo Horn <tsdh@gnu.org> writes:

>> Maybe bzr's changelog_merge plugin can help with this.  See `bzr help
>> changelog_merge'.
>
> That sounds exactly like what I'm looking for.

Hm, do you use that plugin?  It doesn't seem to work as advertised
here.  I have put

  [/home/horn/Repos/el/emacs/]
  changelog_merge_files = ChangeLog

in my ~/.bazaar/locations.conf and updated my trunk and merged into my
taskbranch, but now the ChangeLog entries I have received from the trunk
are on top of my own entry whereas it should be the other way round.

Bye,
Tassilo

Re: Bzr taskbranches and ChangeLog

[Tassilo Horn]

Hi again,

now I assumed that the changelog_merge plugin would DTRT (which it
didn't) I committed my changes including those in the ChangeLog.  Then,
as documented on emacswiki, I did

  $ cd ../trunk
  $ bzr update
  $ cd ../bug-16090
  $ bzr merge
  $ bzr status
  $ bzr commit -m "Merge from trunk."

Now the result is that "bzr missing" tells me that I have 2 extra
revisions and no missing ones.  However, "bzr log" doesn't show me the
commits I've just merged, but the changes are here.  The commits seem to
be amalgamated in the merge commit that's on top of the log right now.
Is that how it is supposed to be?

Bye,
Tassilo

Re: Bzr taskbranches and ChangeLog

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Date: Fri, 20 Dec 2013 21:50:50 +0100
> 
> while reading http://www.emacswiki.org/emacs/BzrForEmacsDevs I don't get
> exactly how to deal with ChangeLog entries when working with
> taskbranches.

As Xue pointed out, a large part of the solution is the
changelog_merge plugin.  With some bzr distributions, it comes
bundled.  It will do its job silently without you having to do
anything at all.

However, you need to remember one thing: changelog_merge puts the
merged entries above (i.e., before) your local ones.  So you will need
to move them forward before committing to Savannah, because our commit
policy is to have the ChangeLog entries in the (reverse) order of
commits.

> For example, I've just created a local branch bug-16090 which fixes that
> bug.  It's complete, but I want to wait with pushing until Stefan had a
> look, so I'll surely need to merge from trunk some times.
> 
> With git I would commit my changes (no ChangeLog entries right now)
> locally, then keep rebasing onto master until Stefan gives his go, then
> write the ChangeLog entry, commit that too, squash that commit with the
> code change commit, and then push one single commit with the code and
> ChangeLog changes.
> 
> How do I do something similar with bzr?

When I work on a feature branch, I usually don't write ChangeLog
entries, only the commit messages.  Then I merge to the trunk (a bound
branch), test the changes there, write the ChangeLog entries there,
and commit upstream.  If someone commits between my merge to the trunk
and commit to Savannah (whcih will require me to "bzr update" before
committing upstream), and those commits touch the ChangeLog files
where I added my entries, I move my ChangeLog entries to the top of
the file before committing.

> When I get the emacswiki page right, I should write my ChangeLog entry
> to some temporary file, and then commit locally providing the entries
> (without author/date line) as commit message.  Then I keep on merging
> from an updated trunk until Stefan gives his go, and then I use the
> commit message from the log to create a real ChangeLog entry.  Finally,
> I commit that and push.
> 
> Correct?  But doesn't that lead to a log like
> 
>   - ChangeLog commit
>   - Merge commit
>   - [...]
>   - Merge commit
>   - Original code commit
> 
> 
> e.g., the eventual ChangeLog commit might be far off the original code
> commit it is documenting?

First, while waiting for approval, you only need to merge from trunk
if the changes there touch the files you modified, or if a lot of
structural changes were made (like files deleted or renamed).
Otherwise, no need to merge from trunk, just leave your branch alone
until you get the approval to push.  Bzr (like git and hg) is very
good at merging, so no need for the "merge fever".

And second, with the workflow I described above, the problems with
ChangeLog are never a concern.  Commit messages are good enough to
keep the information about your work, if you need that later.  In
general, I find that I can write ChangeLog entries before the final
commit upstream just by looking at the output of "bzr diff", and don't
need to consult my commit messages, except in very rare cases.  In
fact, you can just walk the "bzr diff" hunks one by one in an Emacs
buffer, and invoke "C-x 4 a" from there: Diff Mode usually does TRT
with that.

Re: Bzr taskbranches and ChangeLog

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Date: Sat, 21 Dec 2013 08:50:33 +0100
> Cc: emacs-devel@gnu.org
> 
> Hm, do you use that plugin?

I do, all the time.

> It doesn't seem to work as advertised here.  I have put
> 
>   [/home/horn/Repos/el/emacs/]
>   changelog_merge_files = ChangeLog
> 
> in my ~/.bazaar/locations.conf and updated my trunk and merged into my
> taskbranch, but now the ChangeLog entries I have received from the trunk
> are on top of my own entry whereas it should be the other way round.

That's what this plugin is supposed to do, since your entries
"arrived" in that branch before the merged ones.  There's no better
strategy in the general case, when there are changes in ChangeLog not
only at the top.  And when you merge to your bound branch, the result
will be exactly right: your entries will be at the top.

As I mentioned in my other mail, you need to move your entries to the
top of the file before committing upstreams.

Re: Bzr taskbranches and ChangeLog

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Date: Sat, 21 Dec 2013 09:03:54 +0100
> 
> now I assumed that the changelog_merge plugin would DTRT (which it
> didn't) I committed my changes including those in the ChangeLog.  Then,
> as documented on emacswiki, I did
> 
>   $ cd ../trunk
>   $ bzr update
>   $ cd ../bug-16090
>   $ bzr merge
>   $ bzr status
>   $ bzr commit -m "Merge from trunk."
> 
> Now the result is that "bzr missing" tells me that I have 2 extra
> revisions and no missing ones.  However, "bzr log" doesn't show me the
> commits I've just merged, but the changes are here.  The commits seem to
> be amalgamated in the merge commit that's on top of the log right now.
> Is that how it is supposed to be?

Yes.  By default, "bzr log" hides all the individual commits on
another branch that you merged, and shows only a single merge commit.
To see the revisions from another branch, do "bzr log -n0" or
"bzr log --include-merged".  (These are slow, so you may wish to
install the history_db plugin, which makes them as fast as the default
"bzr log".)  You will see the same in the trunk branch regarding your
changes in the feature branch that you merged: they appear as a single
merge commit.  See "bzr help log" for more fun.

Re: Bzr taskbranches and ChangeLog

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

> As Xue pointed out, a large part of the solution is the
> changelog_merge plugin.  With some bzr distributions, it comes
> bundled.  It will do its job silently without you having to do
> anything at all.
>
> However, you need to remember one thing: changelog_merge puts the
> merged entries above (i.e., before) your local ones.  So you will need
> to move them forward before committing to Savannah, because our commit
> policy is to have the ChangeLog entries in the (reverse) order of
> commits.

Ah ok, then it does work as it's supposed.  I've read the "emit OTHERS
first" in its docs as if my changes were kept on top.

>> For example, I've just created a local branch bug-16090 which fixes that
>> bug.  It's complete, but I want to wait with pushing until Stefan had a
>> look, so I'll surely need to merge from trunk some times.
>> 
>> With git I would commit my changes (no ChangeLog entries right now)
>> locally, then keep rebasing onto master until Stefan gives his go, then
>> write the ChangeLog entry, commit that too, squash that commit with the
>> code change commit, and then push one single commit with the code and
>> ChangeLog changes.
>> 
>> How do I do something similar with bzr?
>
> When I work on a feature branch, I usually don't write ChangeLog
> entries, only the commit messages.  Then I merge to the trunk (a bound
> branch), test the changes there, write the ChangeLog entries there,
> and commit upstream.  If someone commits between my merge to the trunk
> and commit to Savannah (whcih will require me to "bzr update" before
> committing upstream), and those commits touch the ChangeLog files
> where I added my entries, I move my ChangeLog entries to the top of
> the file before committing.

Ok, I see.

> First, while waiting for approval, you only need to merge from trunk
> if the changes there touch the files you modified, or if a lot of
> structural changes were made (like files deleted or renamed).
> Otherwise, no need to merge from trunk, just leave your branch alone
> until you get the approval to push.  Bzr (like git and hg) is very
> good at merging, so no need for the "merge fever".

Ok, even better.

> And second, with the workflow I described above, the problems with
> ChangeLog are never a concern.  Commit messages are good enough to
> keep the information about your work, if you need that later.  In
> general, I find that I can write ChangeLog entries before the final
> commit upstream just by looking at the output of "bzr diff", and don't
> need to consult my commit messages, except in very rare cases.  In
> fact, you can just walk the "bzr diff" hunks one by one in an Emacs
> buffer, and invoke "C-x 4 a" from there: Diff Mode usually does TRT
> with that.

Yes, that's what I've usually done, too.

Thanks,
Tassilo

Re: Bzr taskbranches and ChangeLog

[Jarek Czekalski]

I created an entry about ChangeLog in the wiki, but it's mainly pointing 
to this thread. Improvements welcome.

http://www.emacswiki.org/emacs/BzrForEmacsDevs#toc20

Jarek

Re: Bzr taskbranches and ChangeLog

[Eli Zaretskii]

> Date: Sat, 21 Dec 2013 09:49:13 +0100
> From: Jarek Czekalski <jarekczek@poczta.onet.pl>
> 
> I created an entry about ChangeLog in the wiki, but it's mainly pointing 
> to this thread. Improvements welcome.
> 
> http://www.emacswiki.org/emacs/BzrForEmacsDevs#toc20

Done.

Re: Bzr taskbranches and ChangeLog

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> I created an entry about ChangeLog in the wiki, but it's mainly
>> pointing to this thread. Improvements welcome.
>> 
>> http://www.emacswiki.org/emacs/BzrForEmacsDevs#toc20
>
> Done.

Thank you both, that makes it much clearer.

Bye,
Tassilo

Re: Bzr taskbranches and ChangeLog

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> It doesn't seem to work as advertised here.  I have put
>> 
>>   [/home/horn/Repos/el/emacs/]
>>   changelog_merge_files = ChangeLog
>> 
>> in my ~/.bazaar/locations.conf and updated my trunk and merged into
>> my taskbranch, but now the ChangeLog entries I have received from the
>> trunk are on top of my own entry whereas it should be the other way
>> round.
>
> That's what this plugin is supposed to do, since your entries
> "arrived" in that branch before the merged ones.

Yes, now I got it.

> There's no better strategy in the general case, when there are changes
> in ChangeLog not only at the top.  And when you merge to your bound
> branch, the result will be exactly right: your entries will be at the
> top.
>
> As I mentioned in my other mail, you need to move your entries to the
> top of the file before committing upstreams.

I'll do so, and in the future I'm going to use the "write ChangeLog
only before publishing upstream" tactics.

>> Now the result is that "bzr missing" tells me that I have 2 extra
>> revisions and no missing ones.  However, "bzr log" doesn't show me
>> the commits I've just merged, but the changes are here.  The commits
>> seem to be amalgamated in the merge commit that's on top of the log
>> right now.  Is that how it is supposed to be?
>
> Yes.  By default, "bzr log" hides all the individual commits on
> another branch that you merged, and shows only a single merge commit.
> To see the revisions from another branch, do "bzr log -n0" or "bzr log
> --include-merged".

Ah, thanks.

Bye,
Tassilo