Re: Bzr taskbranches and ChangeLog

[Eli Zaretskii]

> From: Tassilo Horn <address@hidden>
> 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.