simple generation of the release news items (r18476 - htdocs/trunk/news - Fix unstable version warning)
stimming at tuhh.de
Sun Dec 13 15:30:43 EST 2009
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.
> 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
> 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 :-)
More information about the gnucash-devel