5 thoughts on “$log$ substitution check-in policy published

  1. czar

    I read the doc explaining why the current revision# is not available (code runs prior to check-in), however $log$ appears to show the correct value. Why does $log$ show the correct revision number, but $revision$ uses “+1”?

    here’s an example:

    * $Revision: 3798+1 $
    * $log$
    * Revision 3799 2010/07/07 13:12:39 czar
    * testing checkin only

  2. jkalmbach Post author

    The default log-pattern just adds “+1” to the last changeset.
    So to be correct: The log-entry should also have been the format “{6}+1” instead of “{7}”…

  3. czar

    Interesting, since $log$ is showing the correct changeset# without using quote “+1”. Personally, I prefer how $log$ does not show “+1”. I thought maybe you improved that feature in a later release, updating $log$ but not $revision$ (since the behavior is different between the two).

    Here is how my file (changeset 3799 after check-in). You can see $revision is 3789+1 whereas $log$ shows ‘revision 3799’.

    * $Revision: 3798+1 $
    * $log$
    * Revision 3799…

  4. czar

    fabulous feature by the way. we need this so files get tagged and marked with our developer comments, before we hand them to a client. thank you!

  5. jkalmbach Post author

    The “$log$ entry is incorrect; even if it seems to be correct.
    In some scenarious, it might lead to the wrong changeset (if two people check-in almost at the same time, then one $log$ entry will be wrong.


Leave a Reply

Your email address will not be published. Required fields are marked *

Captcha *