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

Re: Auto-close: Suggestion for new behavior

From: Simon Large <simon.tortoisesvn_at_googlemail.com>
Date: Thu, 5 Mar 2009 15:34:01 +0000

2009/3/5 void pointer <rcdailey_at_gmail.com>:
> On Thu, Mar 5, 2009 at 7:39 AM, Stefan Küng <tortoisesvn_at_gmail.com> wrote:
>>
>> void pointer wrote:
>> > I have a particular type of "auto-close" behavior that I find a need for
>> > that is not exactly supported by TortoiseSVN 1.5.9.
>> >
>> > I want all local operations to close, and all remote operations that do
>> > not involve a merge, delete, or *remote* add. Local adds should not
>> > count as remote adds and thus should close.
>> >
>> > The interesting thing here is that we can easily replace the autoclose
>> > combo box with a collection of check boxes. For example, you can have 2
>> > auto-close sections: Local and Remote. The GUI would look something like
>> > the image attached. Perhaps by providing auto-close functionality in the
>> > way that my mockup does, we eliminate any future need to provide yet
>> > more auto-close combinations.
>> >
>> > Let me know what you think of this Stefan. If I have time and if we come
>> > to an agreement on something, I may help out and implement this for you.
>>
>> Good idea. But some comments on your screenshot:
>>
>> * the wording is a little bit unclear. it doesn't mention that
>>  if an action which is not checked for autoclose forces the dialog
>>  to stay open and prevent the autoclose
>> * local operations can also have warnings and errors
>
> These are all very valid points. However, the mockup was for demonstration
> purposes only and by no means was meant to be an accurate final
> representation of what the dialog or panel would look like.
>
>>
>> From what I remember, you wanted this because the 'add' you did locally
>> did not autoclose the dialog. But in 1.6, adding files won't even show a
>> dialog anymore. So maybe this improvement is not really necessary.
>
> Not only this, but I wanted *all* local operations to close as well as
> anything that remotely did not have any deletes, adds, or merges, or
> conflicts. If this can be achieved in 1.6 with the changes you've mentioned
> then my problem is solved.

Doesn't "Auto-close if no merges, adds or deletes" do what you want?
IIUC the options get progressively more trigger-happy about closing
and are:
Close manually - never auto-close
Auto-close for local operations - auto-close for local ops like
add/revert provided there are no errors, manual close for all remote
ops.
Auto-close if no merges, adds or deletes - local ops as above,
auto-close for remote ops unless there is M/A/D or conflict or error.
Auto-close if no conflicts - local ops as above, auto-close for remote
ops unless there is a conflict or error.
Auto-close if no errors - always auto-close unless there is an error.

The order in the drop-down list is probably incorrect as it doesn't
reflect this progression, and the help file is also incorrect as it
doesn't mention local ops.

> However, I have to ask, how many people actually
> email you asking for a specific auto-close setup? If you get a lot of these,
> setting up auto-close settings like I've demonstrated in my mock-up would
> provide support for *all* possible combinations and thus fixes any future
> combination requests.

AFAIR I was the last person to request anything in this area (I asked
for auto-close for local ops) and that was 2-3 years ago.

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=1272576
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-03-05 16:34:10 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.