Julian Foad <firstname.lastname@example.org> wrote on 10/13/2004 12:27:03 PM:
> > * Should lock-messages be required?
> > People seem to agree that they shouldn't be required, but still
> > discussing UIs for configuring this.
> Despite them being temporary (compared to commit log messages) I think
> that handling them in the same way is appropriate. There are plenty of
> people who don't want supply commit log messages, and they currently
> have to write '-m ""'. I believe that a far greater proportion of
> people will not want to give lock messages, and if it is considered too
> arduous for them to have to write '-m ""' then I think we should allow
> both lock and commit messages to be configurable in the same way.
> I suggest that we leave lock messages out of the initial implementation,
> as there will be enough other problems to solve. I can't see any reason
> not to make them a later additional feature.
I think that lock messages are a nice feature, as well as an improvement
over "competitive tools" like CVS, VSS and PVCS. I have not seen any
indication that adding the feature adds any complication to the design.
The only discussion seems to be on whether it ought to be required. While
I personally think they ought to be required, it seems like it would be
rather simple to enforce this rule with a pre-hook script if truly needed.
After all, if you want to require a comment, you probably would like the
comment to be useful, perhaps referencing a bug ID for example. This sort
of validation could only be enforced via hook script anyway. So I say,
add the feature, do not require it, and let hook-scripts and GUI tools,
with preferences, decide to require it. For example, in TSVN you can
define a preference as a repository property that indicates the minimum
characters in a commit message. They could do something similar for lock
messages and it is a simple way for someone that wants to enforce a
message to do so.
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Oct 13 19:48:36 2004