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

Re: [PATCH] truncate EDITOR_EOF_PREFIX with previous EOL

From: <kfogel_at_collab.net>
Date: 2005-07-22 00:50:55 CEST

Olleg Samoylov <olleg@mipt.ru> writes:
> kfogel@collab.net wrote:
> > For Subversion's repository, how hard would it be to write a
> > pre-commit script that takes the log msg from the txn, removes all
> > leading and trailing blank lines and guarantees that the log message
> > ends with a single newline, and writes it back to the txn before the
> > commit? About fifteen minutes? Thirty? :-)
> How hard apply a patch? About two minutes? One?

You're missing the point, though.

We can put anything we want into our pre-commit script -- that affects
only us, not other projects. We can make any project policy we want
for ourselves. But making such decisions for *other* projects (i.e.,
by putting a patch into Subversion itself) is different, and must be
approached with much more care.

> I can't undestand official position of subversion
> developers. Obviously this is bug because svn don't work as
> expected. When I write 1 line message to log, I expect 1 line message
> in log. Clear and simple.
> They are several patches to fix. Ones fix "svn commit", others "svn
> log". Based on two opinion must or not log messages always ended with
> EOL.
> But all patches rejected and I advised to write hook script to fix this.
> I can't undestand. Can anyone explain me?

I wasn't advising you to write a pre-commit script. I was asking the
other developers here if they wanted this pre-commit script in
Subversion's *own* repository. You inspired my proposal, but my
proposal was not directed at you.

As for the "official position" of the svn developers, it is often the
case that there is no official position, and that we try to figure out
the best thing to do by discussing matters. That's what's happening

At this point I've begun to suspect that two or more different
problems are being combined here, and would appreciate a concise bug
report that states exactly what is wrong with Subversion: what was the
expected behavior, and what was the actual behavior?


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 22 01:42:58 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.