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

Re: [TSVN] Merging from deleted branch to trunk

From: SteveKing <steveking_at_gmx.ch>
Date: 2005-01-19 20:42:27 CET

Will Dean wrote:
> At 18:22 19/01/2005 +0100, you wrote:
>
>> For me, "preview" means that I can see the _result_ before actually
>> doing something (like print). But with a dry-run, you can't see what
>> the result would be, you can only see which files _might_ get changed,
>> not how they get changed.
>
> Yes, it's a lousy half-baked feature, so perhaps having a lousy
> half-baked name for it is actually appropriate.

I don't think it's a half baked feature, and I definitely don't think
it's lousy. It does what it is intended for: it shows the user what to
expect in a merge.

>> So if you're not comfortable with a tooltip, we could extend the label to
>> dry run (does not modify files)
>> instead. But I want to keep the term "dry run".
>
> Yes, I think you're probably right.
>
> I suspect that the 'design by committee with SK's veto' approach is
> going to mean that nothing ever gets changed in the merge dialog, so I
> shall probably give-up talking about it soon.

This weeks discussion about the merge dialog was huge. I didn't comment
on those because I wanted to wait and see what you guys would agree on.
But as you might have noticed, there isn't an agreement on a 'best'
solution yet. So I don't understand why you suddenly accuse me of
vetoing - I have told you my opinion, nothing more, nothing less.

You also have to understand that what you might think of being more user
friendly or more clear isn't always that clear to people who understand
the merging stuff. I for example don't want to have two dialogs for two
different merge scenarios (URL1/URL2 and URL1 with range). That would
confuse me a lot. Also suddenly renaming the "dry run" - I mean I'm used
to that term, it's used in Subversion, mentioned in the docs and the
book, and "dry run" is a term widely used for "trying something out first".

Another point: making it easier for users to understand merging is
definitely a good idea. But _never_ do it so that certain cases aren't
possible anymore (for example by assuming something which should be
configurable).

After 1.1.3 got released, I will post here some suggestions on how _I_
think the dialog could be improved, using a lot out of this weeks
discussions. You then can comment on that and maybe we can come to an
agreement. If not, well then the dialog will have to stay as it is until
we do. Because I refuse to change something just to have to change it
over and over again...

Stefan

-- 
        ___
   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 Wed Jan 19 20:43:36 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.