2009/4/1 void pointer <rcdailey_at_gmail.com>:
> No because of 2 reasons:
>
> I do not want the update dialog to close for any reason
> I always want the progress dialog for adding files to close, but it would
> not because technically those are "adds" and would prevent it from closing.
If those are considered "adds" in this context then it is a bug. The
intent was to show when your working copy was being changed by a
remote operation in a non-trivial manner, i.e. adding files to it,
removing files from it or merging remote changes with your local
changes. Locally adding a file should be considered a local operation.
I have tested this on 1.5.8 (which is what I have here in work) and
the behaviour is not what I expected, so I think there is a bug in my
understanding of the priorities ;-) I am no longer sure that this can
be handled by a single combo box.
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.
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), 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.
Simon
--
: ___
: oo // \\ "De Chelonian Mobile"
: (_,\/ \_/ \ TortoiseSVN
: \ \_/_\_/> The coolest Interface to (Sub)Version Control
: /_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=1505494
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-04-01 11:58:44 CEST