Call for useful SVN commit log messages ;)

[verwilst]

Today I was ( as I regularly do ) checking out the latest commits, but the svn log was still very vague.. Seeing "minor fix", "some fixes", "additional fixes", doesn't give me the warm fuzzy feeling when i see a bug that has been bothering me or a feature that i was missing just got implemented

Just regard your svn commit messages as a kind of micro blog with readers such as me doing frantic svn up's to see if anything sweet is added

[richlv]

for the record, there are 10 (ten for binary addicts) _completely_ identical svn commit messages... that make absolutely no sense to me =)

- [DEV-285] fixes related to dropdown changes (Artem)

there are several problems with these messages :
1. nobody except core devs have access to DEV issues, so we can't refer to that in case commit message is unclear;
2. they are non-descriptive - what fixes ? ideally, each message would at least briefly mention _what_ it fixes (fixed incorrect blinking, fixed inaccessible thisnadthat menu, fixed identation hereandthere - generic examples ;> );
3. they are freakin identical. imagine scouring svn log to find a particular commit that fixed a particular issue.

few things that could help those who follow svn, and in the end would help devs themselves :

1. either make DEV issues public, or never ever mention them anywhere. if needed, open a ZBX issue (but don't make them as nondescriptive, add some meat so that reader can find out what actuall it means - i remember sonmebody recently complained about going to tracker to find out something about vague commit message only to find an issue containing only the same vague message in it's title );
2. write descriptive messages, of course - if needed, svn diff your changes. that would also bring a side effect with less accidental changes (for example, agentd support for -t userparameters was fixed, then broken few revs later with another funny commit message "misc fixes". i think it's still not fixed in svn...).
i have had a few wtf moments myself when doing svn diff before commit - that helped me to catch seriously braindamaged commits.

for example, i still have no idea what "dropdown changes" actually means (ok, i have a guess that's the change from all -> not selected - but there's probably more), because initial messages that committed these changes were something like "configurable dropdown" with a reference to DEV issue.

i wasn't going to post this on forum, but looking over the frontend to find out what those few commits just introduced, finding nothing slightly annoyed me - but what finally got me were these 10 (ten) identical messages

[nelsonab]

I was talking to a coworker who was telling me how the big G (Google) did things in his group. He was saying that anything which was to be checked into their repos your code was reviewed by a peer. Who would often ask for more comments, it sounded like every variable which was not absolutely self evident may have been commented. While this may have been a royal pain in the ass for the person writing initially over time it pays HUGE dividends. If there was a logic error, the documentation helps make those errors evident, also when someone else had to maintain the code they could come up to speed fast.

Clear, easy to understand and descriptive comments, it's a best practice.

[xs-]

i couldn't agree more

[Alexei]

We are working on this!

[verwilst]

Actually Alexei, I have noticed that the commit messages have improved greatly the last few days! Great work!!

[Alexei]

It's nice to hear this! Thanks!

[richlv]

i wanted to add that even i see improvement in commit messages
while occasionally a search is required to find out what exaclt was merged, it's usually now quite clear what a commit did.