#261 Add commit (build) number to ChangeLog


It would be nice to have commit number next to date in ChangeLog.


  • Maarten Brock

    Maarten Brock - 2008-12-20


    I don't quite follow. Do you want us to predict the revision number every time when we enter the text into the changelog? I don't think we are willing to do that.

    And if you only want to know to which revision the changelog belongs, it is automatically recorded at the bottom of the file (unless you view it online).

    I've set this pending so it will auto-close in a few weeks.


  • Maarten Brock

    Maarten Brock - 2008-12-20
    • status: open --> pending
  • Patryk

    Patryk - 2008-12-29

    > Do you want us to predict the revision number every
    > time when we enter the text into the changelog?
    Yes, but I didn't know it needs to be predicted, I supposed it is known at that time or can be added automatically (by some script). There is sometimes a confusion when changes are announced in log and it's not known in which snapshot they "take effect".

  • Maarten Brock

    Maarten Brock - 2008-12-30

    Changes are often announced with a revision number. That should help.

    And next to each snapshot is the head of the 'corresponding' changelog (yellow diamond CL) which shows the most recent changes upto that revision.

    Subversion can automatically adapt the revision inside a file as it does at the bottom of the Changelog, but it cannot log it once and leave it unchanged thereafter.

  • Raphael Neider

    Raphael Neider - 2008-12-30

    I also like the idea of having a commit number along with the ChangeLog entries.

    Rationale: I sometimes find myself skimming through the logs wondering about the details of a change. I then count entries and hope no intervening commit outside the sdcc/ branch messed up the revision numbers. It is not practical to first use svn blame on the ChangeLog to determine the revision and then checkout (or diff) the requested revision.
    Partly for this reason I imported the repository into git and browse the sdcc history there, using svn only to check in changes.

    Another benefit of revision numbers in the ChangeLog would be cross-references: If I state "reverted chenges from r5293..r5295" there is no easy way to find or even jump to the corresponding ChangeLog entries (except the slow svn blame/annotate). Having the number in the log would even allow to do this off-line.

    I propose to augment the ChangeLog, adding the revision number once per entry like
    YEAR-MONTH-DAY Committer Name <committer AT email.tld> [r1234]
    YEAR-MONTH-DAY Committer Name <committer AT email.tld> [r1234,r1236]
    (if multiple commits are covered). The first form can surely be automatically extracted using a script based on the output of svn blame, the second form can be maintained by hand: Issuing an svn up before editing the ChangeLog and/or committing the change does not seem to be too much overhead, especially as svn forces the local copy to be up-to-date on check-in anyway.

    Even if not every developer is willing to add the revision number, having it available every 5th log entry or so would already help a lot.
    I would like to hear more developers' (and users') opinions on both adding revision numbers in general and the format to use (if any): [r1234], [1234], {r1234}, {1234}, #1234, ...

    I do not think this is an essential feature, but I think the use/cost relation is quite favourable. Does anyone know of projects that do give revision numbers in their ChangeLogs?

    Kind regards,

  • Raphael Neider

    Raphael Neider - 2008-12-30
    • status: pending --> open
  • Patryk

    Patryk - 2008-12-31

    frief: that's seems to be it! But why in some commits the list of affected files is missing there?

  • Raphael Neider

    Raphael Neider - 2008-12-31

    The list gives the subversion commit message, which can be completely different from the ChangeLog entry. The file list is, however, just a single click away: The revision number links to the detailed changeset, including the list of files changed by the commit.

    So I guess this is settled then, setting this to pending once more.


  • Raphael Neider

    Raphael Neider - 2008-12-31
    • status: open --> pending
  • SourceForge Robot

    • status: pending --> closed
  • SourceForge Robot

    This Tracker item was closed automatically by the system. It was
    previously set to a Pending status, and the original submitter
    did not respond within 14 days (the time period specified by
    the administrator of this Tracker).


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks