On Wed, Apr 1, 2009 at 1:39 PM, Stefan Küng <tortoisesvn_at_gmail.com> wrote:
> void pointer wrote:
> > On Wed, Apr 1, 2009 at 4:58 AM, Simon Large
> > <simon.tortoisesvn_at_googlemail.com
> > <mailto:simon.tortoisesvn_at_googlemail.com>> wrote:
> >
> > I am beginning to see where you are coming from now, and my
> suggestion
> > is to compromise between your requirements for fine-grained control
> > and Stefan's requirement for simple UI. How about having two drop
> down
> > lists, one to handle the cases where remote changes will affect my WC
> > (update, switch, merge) and one to handle the cases where my WC is
> > only affected by what I am doing locally, even if it involves remote
> > access (add, revert, commit). The remote list would have all the
> > current options except (obviously) the local change one. The local
> > list would have 3 options: close manually, auto-close for local
> > operations (i.e. not commit) or auto-close if no errors.
> >
> >
> > This sounds like an acceptable compromise. I'd be happy with this.
>
> I think the local option only needs a checkbox: autoclose for local
> operations. We never auto-close on errors - an error is important
> information and must be shown to the users. Otherwise we would get
> flooded with confusing bug reports...
>
>
> > One thing you have not considered is that the choice may depend not
> > only on the dialog in question but also on the repository access
> > method. One reason for keeping the dialog open is to see what is
> > happening over a slow internet connection (like tigris.org
> > <http://tigris.org>), and
> > seeing a definite "Finished" rather than just the absence of a
> > progress dialog. OTOH repositories accessed via the LAN will have a
> > very much faster response, in which case you would likely only want
> > the progress dialog to show errors. To cope with that you would need
> > per-project settings, but implemented per-user, not using subversion
> > properties which are forced on every user. So even the fine-grained
> > per-dialog solution you proposed is not going to meet all
> > requirements. We need to keep this simple.
> >
> >
> > I'm not sure what you are trying to say here. Regardless of your
> > bandwidth, if the dialog disappears then I can safely assume (at the
> > very least) that no errors occurred. As far as a commit goes, this is
> > all I care about. I don't really care about each individual step. And
> > besides, if the progress is really going to take that long due to
> > bandwidth then I must have plenty of time to watch the progress since
> > the dialog wouldn't be closing anytime soon. Perhaps I am
> > misunderstanding what you are saying?
>
> You're not misunderstanding his arguments. But you're only considering
> what *you* might need/want and think is a required feature. The same way
> I'm arguing against your suggestion of extending the autoclose feature
> too much, you're now arguing against extending it even more. I'm just
> one step behind you :)
> You can maybe see now why we don't implement every feature request.
No I think I understand his argument perfectly well. I'm not arguing about
what I want, I'm arguing about what is logical. When local operations have
been configured to auto-close, I know that the only reason it will not
auto-close is in case of an error. What's so wrong about that?
And how am I arguing against auto-close? My main argument all along has been
that I need something more flexible. Yes, this need is personal but it is
also logical. I'm not the only beneficiary of such a change. My own ideas
for adding flexibility were shot down and that's perfectly fine. There's
hundreds of ways of making it more flexible. I like Simon's idea too.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=1510190
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-04-01 21:44:25 CEST