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

Re: Log message templates

From: John Szakmeister <john_at_szakmeister.net>
Date: 2004-07-28 11:32:34 CEST

On Tuesday 27 July 2004 21:28, Mark Phippard wrote:
> Ben Reser <ben@reser.org> wrote on 07/27/2004 09:21:27 PM:
> > On Tue, Jul 27, 2004 at 03:37:43PM -0400, Greg Hudson wrote:
> > > On the other hand, I've long felt that it would be a good idea to
> > > be able to set arbitrary rev-props in a commit. If we had a good
> > > syntax for that, it would be almost as convenient as your proposed
> > > -id flag.
> >
> > +1 I totally agree.

+1 from me as well.

> Would it be OK if I enter this in the issue tracker? Or have one of
> you maybe already done it?
> For the most part, I think it would be a good way to solve the problem
> in a way that would be generally useful for other problems. The one
> issue it does not address, that I think would be hard to address with
> this proposal, is the idea of making some of these arbitrary properties
> mandatory, just as --message is mandatory. Perhaps the configuration
> area could provide a list of required name:regex pairs that would cause
> the values to validated and required?

I was going to say that you could probably do this through a pre-commit
hook in conjunction with svnlook. But it appears that svnlook doesn't
deal with arbitrary revprops. It can only deal with those exposed
through svnlook's commands (author, log, date). However, I see no reason
why we couldn't extend svnlook to provide this capability. That way the
pre-commit hook could not only check for the existence of those
properties, you could check their validity as well.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 28 11:32:55 2004

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

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