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

Re: [RFC] Target aware commit message processing

From: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: Wed, 23 Apr 2008 17:23:20 -0700

On Wed, Apr 23, 2008 at 5:02 PM, Karl Fogel <kfogel_at_red-bean.com> wrote:
> The point is, it's 100% common *when the user has edited the lines*.

I think we're differing about how common this would be - given this is
a feature that doesn't exist in the CLI, I'm betting most folks would
be acclimated to passing the proper args at the command line. Yes,
over time, it may change...

However, there are quite common scenarios where we may not be able to
parse the lines properly. What happens when the log message doesn't
have the special log lines? What do you do? Do you assume that you
use the original set or that the user intended to commit nothing? I
can actually see both cases as reasonable interpretations - think of
the '-F' case but also think of a user who wants to abort a commit
after starting it and has already saved the log message.

Plus, the current collapsing logic in the log template isn't
consistent nor perfect. I'm not sure if we'd be able to properly
support *adding* files (like p4 does, IIRC) because we're so focused
on producing the smallest and most compact subset possible in the
template.

All I'm advocating is that before we go off and do something that the
user may or may not have intended, we confirm that we're doing the
'right' thing. Adding an extra prompt to commit if isn't what we
started with is being conservative rather than being aggressive and
assuming that we'll parse their intentions correctly 100%. I simply
have no faith that we'll get it right. GUIs have a direct path -
doing the confirmation in Tortoise would be stupid - but for the CLI
we'd have to intuit the user's intentions via way of parsing an
intermediate file.

> The prompt being proposed here doesn't have that property. It's both
> part of the expected procedure, and *not* part of any unexpected (thus
> unwanted) procedure. Since it doesn't have the latter property, it does
> no good.

No, because if we do a switch *now* in 1.6 where we've always said
"this will be ignored" and suddenly we don't ignore it, we've given
folks a loaded gun and would lead I feel to unpredictable behavior.

For example, in my typical use case, I write my log message and delete
the lines from the 'ignore' section after I've completed the log
message for each file. I like this new feature, but our precedent
makes silent acceptance and intuition of what the user intends when
they muck with those lines a bit dangerous. -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-24 02:23:32 CEST

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.