[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: Karl Fogel <kfogel_at_red-bean.com>
Date: Wed, 23 Apr 2008 21:31:49 -0400

"Justin Erenkrantz" <justin_at_erenkrantz.com> writes:
> 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.

We're not differing about how common it would be, we're just talking
about different things. The number of folks who would use the feature
is irrelevant here. What's relevant is that, for those who *do* use it,
they are likely to use it often, and therefore will habituate to the
prompt, making it pointless.

> Yes, over time, it may change...

...and as it changes, the prompt becomes less and less useful :-).

> 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.

I'm not sure I fully understand the scenarios you're describing; I think
the interface may need to be spec'd out more for the above to be

> 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.

If Subversion is uncertain, it shouldn't even attempt the commit. And I
don't see why Subversion would have trouble being certain: we're
declaring a parseable format, right?

> 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

Yes, for people who work the way you do (I don't know how many that is),
for a temporary period while they get accustomed to the feature, the
prompt would actually serve a purpose. Thereafter, it would be only an
annoyance. I don't think we should design a permanent UI around a
temporary transition period, especially when the consequences of the
user making a mistake are not grave anyway.


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 03:32:13 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.