[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Adding an Inspection Id to each Log Message.

From: Ryan Schmidt <subversion-2006c_at_ryandesign.com>
Date: 2006-08-16 21:10:25 CEST

On Aug 16, 2006, at 16:00, Reedick, Andrew wrote:

> Ryan Schmidt wrote:
>> You could use the database to store more things as well. You could
>> put the entire log message into it, for example, so that you could
>> then use the database to perform searches on the log messages. You
>> could store other unversioned properties there as well.
> Don't forget that it will be necessary to keep the two data sources in
> sync. It is possible to change log messages after the commit, so
> you'll
> need a post-revprop-change hook to update the database. Having two
> data
> sources to keep in sync is the biggest drawback to using commit
> messages
> to pass information to custom hooks or DBs.

Which I said:

> On Aug 16, 2006, at 01:38, Ryan Schmidt wrote:
>> There is no way to search log messages, so there is no facility
>> for you to find code without an inspection ID. I suggest you set
>> up a separate (e.g. MySQL) database in which you have a record for
>> each revision. You can write a post-commit hook and a post-revprop-
>> change hook that write into this table whenever anybody includes
>> an inspection ID in their log message. From this you can determine
>> which revisions lack the property.

> Which is why I suggested this,
> http://svn.haxx.se/users/archive-2006-08/0448.shtml, the ability to
> parse out custom arguments on the command line (such as --bug_id or
> --inspection_id) instead of relying on commit messages.

Yes, you did; that, however, does not exist in Subversion yet,
whereas what I proposed can be done with today's Subversion.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Aug 16 21:12:52 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.