Re: Workflow to accumulate individual changes?

[David Kastrup]

Giorgos Keramidas <address@hidden> writes:

> 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_ the file change history is important, we can generate it on the
source web page on the fly, from the VCS logs.  ChangeLog dates from a
time of VCS-less development.  If we really want to distribute this sort
of info, generating it from commits is quite more reliable.

One point of a distributed version control system is that non-privileged
users may clone their own repository and have all this historical data
in case they need to work with it.

My vote is for moving ChangeLog maintenance to proper commit message
maintenance: that is more important for a developer with version control
access, and again, DVCS use means that this info is available off-line
to the user/programmer.  With CVS, it wasn't.

> 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?

I don't consider it useful anymore to artificially split relevant change
info between ChangeLog and commit messages: all relevant version control
tools (graphical browsers etc) access the commit messages, and those are
there also offline.

There is no info we want in ChangeLog that should be missing from commit
messages.

The price Emacs developers pay for following the proposed hair-splitting
policies now is too high.  With CVS, off-line access to the ChangeLog
was a somewhat valid argument.  With DVCS, it isn't.

-- 
David Kastrup