[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Workflow to accumulate individual changes?

From: Karl Fogel
Subject: Re: Workflow to accumulate individual changes?
Date: Thu, 31 Dec 2009 14:47:44 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.91 (gnu/linux)

David Kastrup <address@hidden> writes:
>_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
>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.

+1 all over this.

Our commit logs should follow the same structure ChangeLog entries
currently do, and we should not maintain separate ChangeLog files.
There would be zero information loss; also much less confusion, and much
less time wasted discussing how to maintain the same information in two

reply via email to

[Prev in Thread] Current Thread [Next in Thread]