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

[TSVN] Re: Small bug in commit dialog

From: Simon Large <slarge_at_blazepoint.co.uk>
Date: 2005-02-10 11:37:02 CET

SteveKing wrote:
>> I would vote for treating conflicts as errors, for the purposes of
>> deciding whether or not to close. I think others disagree with
>> this.
>
> The problem I see here is:
> If we make the dialog not close on conflicts, then we will end up with
> more requests like the one from Lübbe. Then users want a separate
> option to not close the dialog not just for conflicts, but for merges,
> adds (I'd like to see what new files were added!), deletes (why the
> hell was my file removed and who did that?), moves (hey, I want my
> file here, not there!), ... which would never end.

Choosing where to set the bar is difficult. Personally I think we should
always leave the dialog open if there is any condition which requires
user action (ie. conflicts), and definitely if there is an error.

I can see Luebbe's point of wanting to see merges too. The progress
dialog is the only place you ever see that those have happened. After
the merge, check for modifications will only tell you that the the file
is up to date. But once we add one option, then it invites requests for
more, as Stefan says. _If_ we really want a middle level, then I would
group them like this:
No change / updates
Merge / Add / Delete
Conflict / Error

So the combo box has:
Manual close
Auto close on simple updates
Auto close if no conflicts or errors

> I was afraid the first time I added the "Don't close on conflicts"
> option that something like this would happen. I admit it took some
> time until this came up, but it did.

I think that one is my fault. Recursive overlays were just too slow to
use then, so if a conflict came up it would be very easy to miss it,
which I think is dangerous. When the external cache becomes mainstream,
then that problem goes away, but only if the user has enabled recursive
overlays. So even then I think conflicts should always prevent
auto-closure.

But to be honest, I never use auto-close at all now because I think the
summary info is useful, and it's easy to dismiss the dialog when
finished. And it's hard to spot possible bugs when the evidence
evaporates ;-)

Simon

-- 
       ___
  oo  // \\      "De Chelonian Mobile"
 (_,\/ \_/ \     TortoiseSVN
   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
   /_/   \_\     http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Thu Feb 10 11:45:59 2005

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.