Re: Bzr taskbranches and ChangeLog

[Tassilo Horn]

Eli Zaretskii <address@hidden> 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