Svn commit messages (please)

hi,

It’s been mentioned in the past. And IIRC you already told that you were too lazy to add description to you commits.

But really that would be much comfortable for us juce users that try to keep up to date with the svn trunk.

here’s 2 scenarios:

  1. I want to benefit from the latest bug-fixes and/or enhancements but I’m not ready to use Cocoa yet.

  2. I haven’t done a svn update for some time and I’d like to keep up to date with the trunk but before updating I’d like to be sure that it won’t break my current build (be it because of minor or major changes in juce)

The absence of commit description in both cases is time-consuming and error-prone. You have to browse each diff and try to understand what was the purpose of each one.
In some cases it’s self-explaining, in others it can be difficult if you’re not familiar with the code and sometimes you can’t or don’t have the time to understand.

I’m working with SVN on a daily basis and even when working alone on some parts of the code your own commit descriptions can save you a lot of time.

I don’t want to sound like I’m trying to teach you something. Just that it would be kind of you.

P.S.: moreover and it’s not you fault, but the sourceforge svn is quite slow. It takes like 10s to fetch a diff for a single file just to realize that sometimes only indentation or whitespace have changed.

anyone?

Sorry! Can’t argue with any of that… When I first started using SVN I was quite good about commenting it, but got gradually lazier… I promise to try harder in future!

thanks :slight_smile:

For me it was the other way around (after having to go through my own commits trying to understand what the h-ll I did…). Now I comment every commit, and I’m glad to, as it has helped me on a number of occasions.

Commenting commits also has several other positive side-effects like:

  • forcing code review before commit. It often happens that not all modified files needs to be commited. This usually when I take the chance to revert changes that were not necessary for the problem: temporary tests, additional whitespace…etc
  • splitting commits into small incremental logical changes that are easier to understand/compose/apply/undo later if necessary

Thanks BTW for the latest commits :slight_smile: