Greg Stein <gstein@lyra.org> writes:
> On Tue, Jan 22, 2002 at 02:31:50PM -0600, Karl Fogel wrote:
> >...
> > And there are many other ways to solve this, in addition the one Mike
> > pointed out.
> >
> > -1 on Subversion parsing the log message. Let's please not go there.
> > In the same sense that some changes are "bug sources", this has the
> > potential to be a very fertile "unexpected behavior source", while
> > adding no functionality that can't be gotten in other ways.
> >
> > If someone wants to write their pre-commit hook scripts to parse log
> > messages, that's different. But Subversion itself shouldn't ship with
> > that functionality built in.
>
> If the client is going to insert a bunch of lines (e.g. with the files that
> are being changed), then the client better remove the lines that it
> inserted.
>
> The last thing that we want is to ship a system that inserts a bunch of
> stuff into the log message and then ends up dumping all of that into the
> logs on the server.
Agreed.
In general everything that appears in the editor when it starts should
be determined by the project, not by subversion. I think we should run
an optional, client side script, and this should get the all the file
names that were specified on the original command line. This script
will generate the initial log message in whatever form the project
requires. After exiting the editor, a second optional, client side
script should be run which can do any post-processing required.
If there are no scripts, the log message starts blank.
We can ship subversion versions of these scripts that create
subversion format log messages.
--
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:58 2006