[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
>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.
+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
places.
- Re: Workflow to accumulate individual changes?, (continued)
- Re: Workflow to accumulate individual changes?, Giorgos Keramidas, 2009/12/31
- Re: Workflow to accumulate individual changes?, Juanma Barranquero, 2009/12/31
- Re: Workflow to accumulate individual changes?, Alfred M. Szmidt, 2009/12/31
- Re: Workflow to accumulate individual changes?, Juanma Barranquero, 2009/12/31
- Re: Workflow to accumulate individual changes?, Richard Stallman, 2009/12/31
- Re: Workflow to accumulate individual changes?, Óscar Fuentes, 2009/12/31
- Re: Workflow to accumulate individual changes?, David Kastrup, 2009/12/31
- Re: Workflow to accumulate individual changes?,
Karl Fogel <=
- Re: Workflow to accumulate individual changes?, Chong Yidong, 2009/12/31
- Re: Workflow to accumulate individual changes?, Óscar Fuentes, 2009/12/31
- Re: Workflow to accumulate individual changes?, Juanma Barranquero, 2009/12/31
- Re: Workflow to accumulate individual changes?, Eli Zaretskii, 2009/12/31
- Re: Workflow to accumulate individual changes?, Stefan Monnier, 2009/12/31
- Re: Workflow to accumulate individual changes?, Juanma Barranquero, 2009/12/31