Re: Workflow to accumulate individual changes?

[Juanma Barranquero <lekktu@gmail.com>]

On Thu, Dec 31, 2009 at 14:43, Giorgos Keramidas
<keramida@ceid.upatras.gr> wrote:

> I think it's very useful to see file changes in the ChangeLog.  It helps
> a lot when an Emacs user downloads a tarball of the sources from the FTP
> site, because file changes are visible without full access to the
> original branch itself or access to a bzr client.

If we were using the commit log to put ChangeLog entries, the
ChangeLog could be reconstructed as part of making the release tarball
by a simple

  bzr log --gnu-changelog -r ...

> Maybe we can try to strike a balance between not keeping the ChangeLog
> up to date at all and making it difficult to commit *one* changeset that
> includes both ChangeLog updates _and_ file updates by committing the
> ChangeLog updates separately?

That breaks the idea that commits should try to respect the ACID
(atomicity, consistency, isolation, durability) principle.

> To avoid doubling the revisions we keep in the repository, by following
> *every* single commit with a ChangeLog update, we can batch ChangeLog
> updates.  So a developer can work in his own local branch and commit
> several local changes before updating the ChangeLog.  Then a single
> ChangeLog commit on top of those can be stacked on top of the batch of
> local changes, right before they are pushed to the trunk.

Personally, I find this idea ugly.

    Juanma