[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Manual merges.
Re: Manual merges.
Fri, 21 Oct 2011 19:40:55 +0200
KMail/1.13.7 (Linux/2.6.30-2-686; KDE/4.6.5; i686; ; )
On Friday 21 October 2011, Bob Friesenhahn wrote:
> On Fri, 21 Oct 2011, Stefano Lattarini wrote:
> >> Should I perhaps file a bug that the ChangeLog file should be generated?
> > That would be a good idea in the long(ish) term. In fact, I pesonally see
> > ChangeLogs as a relic of the pre-VCS era; they were surely VERY useful to
> > track regressions and bugs and backward-incompatibilites back then, but
> > today that we have the "real" project history in the VCS repo, and lots of
> > tools to view and analyze it, the ChangeLogs (as well as the GCS rules to
> > write them) are becoming more and more of a nuisance.
> ChangeLogs may seem like a nuisance but many more people have access
> to source tarballs than network-based version control systems.
This situation is much ameliorated if one uses a distributed VCS, though.
But I can see how accessing a ChangeLog entry from two yars ago can be
easier (and musch faster!) that accessing the corresponding commit message
with SVN or CVS, so I got your point.
> It has been shown time and time again that version control systems
> come and go (or move) while the source code lives on.
Still, when a project changes its VCS system, the pre-existing history
is usually preseved by a proper conversion (for example, I can still
access all the automake project history, even that of when its version
control system was CVS).
> It is typical that ChangeLog messages are considerably higher grade
> and more detailed than commit messages. However, the version control
> system also offers capabilities (e.g. change sets) that the ChangeLog
> does not offer.
For the moment, I'd be happy to just make the automake's ChangeLog
automatically generated, as other GNU projects have already done
(e.g., coreutils and grep).