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

Re: RFC: Log Message Templates via new hook.

From: <kfogel_at_collab.net>
Date: 2005-05-26 05:58:53 CEST

Mark Phippard <MarkP@softlanding.com> writes:
> That is essentially what I proposed as well. I proposed that TSVN be able
> to invoke the hook without passing any of the paths. It would have to be
> documented for hook providers to be aware of this. I further suggested
> that if the hook provider ultimately wanted to have the list of paths in
> the commit message, there could be an agreed-upon substiution variable
> placed in the template that the hook returns to the client, such as
> $FILES$.
> TSVN could then have a button to replace the variable with the file list
> and/or do it automatically when the user submits the commit.

Does this really solve anything?

If the substitution does not happen while the log message is being
written, then the user never sees the final version of their log
message (and it's highly unlikely, I would think, that an unadorned
list of files is what anyone wants in a log message, since that
duplicates information already stored by the repository).

In other words, if the user can't use the list of files at the time
they're writing the log message (with or without template), then what
good is the substitution variable?

And if the idea is that the user would hit a button to insert the
now-known list of files into the log message, then the variable isn't
needed -- TSVN can just insert, either at the end of the message, or
at the beginning, or at the current editing insertion point. The user
can read the template and know where the file list should go; there's
no need for the client to provide a special substitution variable.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 26 06:37:06 2005

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.