simple generation of the release news items (r18476 - htdocs/trunk/news - Fix unstable version warning)

[Christian Stimming]

Am Freitag, 11. Dezember 2009 schrieb Geert Janssens:
> > BTW if you write a svn commit message and quote a bugzilla bug number, I
> > recommend writing "bug #1234", i.e. with the hash sign in front of the
> > number. Our trac website is set up to turn those numbers (those with
> > hash) into hyperlinks into bugzilla, just as "r123" is turned into
> > hyperlinks to the respective commit log page in trac.
> 
> I copied the bug title directly from bugzilla and didn't pay attention to
>  the # sign, sorry.

No problem.

> I wanted to correct this with:
> $ svn propedit --revprop -r18488 "svn:log"
> But I am not allowed to do so:
> svn: Revprop change blocked by pre-revprop-change hook (exit code 1) with
> output:
> Sorry [gjanssens], you cannot change [svn:log]

Yes, changing existing commit messages is not allowed. Even though this seems 
unconvenient, there are a whole bunch of good reasons why this is so. Really. 
Just to name a few:
- The commit messages itself are not version controlled, so if you 
accidentally remove an important one, it is really gone; 
- Trac doesn't parse the svn log messages of the whole repository each time 
but instead keeps its own cache; you would have to trigger Trac to refresh its 
cache of the changed revision
- Other version control systems like git consider the commit message as part 
of the actual commit, which means if you change the message, you change the 
whole commit, which blows up the whole idea of distributed versioning where I 
can rely on the fact that "my copy of the SVN trunk history" will stay the 
same except for newly added commits etc. etc.

So yes indeed, we must live with suboptimal worded commit messages :-)

Regards,

Christian