Comments on: $log$ substitution check-in policy published

By: jkalmbach

jkalmbach — Fri, 09 Jul 2010 11:12:33 +0000

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.

By: czar

czar — Wed, 07 Jul 2010 21:36:27 +0000

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!

By: czar

czar — Wed, 07 Jul 2010 21:27:46 +0000

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…

By: jkalmbach

jkalmbach — Wed, 07 Jul 2010 21:08:54 +0000

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}”…

By: czar

czar — Wed, 07 Jul 2010 21:02:36 +0000

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