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

Re: Another auto-close idea...

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Wed, 01 Apr 2009 20:39:19 +0200

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.


  oo  // \\      "De Chelonian Mobile"
 (_,\/ \_/ \     TortoiseSVN
   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
   /_/   \_\     http://tortoisesvn.net
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].

Received on 2009-04-01 20:39:38 CEST

This is an archived mail posted to the TortoiseSVN Dev mailing list.