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

Re: Re: Merge dialog

From: Simon Large <simon.tortoisesvn_at_googlemail.com>
Date: 2007-10-19 11:10:47 CEST

On 19/10/2007, Alexander Klenin <klenin@gmail.com> wrote:
> On 10/19/07, Stefan Küng <tortoisesvn@gmail.com> wrote:
> > On 10/19/07, Alexander Klenin <klenin@gmail.com> wrote:
> > > I agree that clutter should be reduced.
> > > However, I think wizard interface is not the answer, as it forces
> > > some unnecessary and arbitrary decision order.
> > > In particular, I strongly dislike an idea that each time user requests a merge,
> > > he must answer some question *before* he can proceed.
> >
> > Aehem: you *always* have to fill in the url and revisions for the
> > merge before you can proceed. Whether you enter them on one dialog or
> > two shouldn't really matter.
> Well, there are already three dialogs involved --
> merge dialog, repo-browser to select URL and log dialog to select revision.
> Adding yet another step will definitely hinder at least my workflow.

Well you don't *have* to use the log dialog to fill in revisions, or
the repo browser to chose URL, you can enter by hand. But if you are
going through those dialogs, clicking on Next a couple of times is
hardly a significant time penalty. We could have a keyboard shortcut
for Next (Enter?) to speed up.

I guess we could add a Finish button to the URL page which takes you
directly to the action buttons, skipping the merge settings, but it's
another button for very little gain.

> > > I perform about a dozen merges daily at work, it would certainly be
> > > very annoying.
> > What kind of merges are those? Merges of trunk to your branch? Then
> > use the "Merge All" command.
> No, they are the other way around -- I, as a project manager,
> merge topic branches into trunk
> (and sometimes from one trunk to another one, in a cross-project merge).
> At the moment, I can not imagine a workflow that requires frequent merges
> from trunk to branch.

If you develop a feature branch, you need to keep it up-to-date with
trunk changes before doing the final merge back. Each time you do that
update you are doing a trunk-branch merge, and you certainly benefit
from auto-merge in that case.

> > > How about tabs control?
> > Yuck! Way too ugly.
> Hm, what prevents us from making it beautiful? ;-)
> Tabbed interfaced are popular these days.
> > And that doesn't help *guiding* the users.
> Well, it will, on the one hand, hide rarely-accessed info from
> unexperienced users,
> and, on the other hand, would not require those who already learned a tool
> to do unnecessary extra work.

I think it would be a mistake to hide anything. Users need to be aware
that the options are there even if they stick with the defaults and
usually click through them.


  oo  // \\      "De Chelonian Mobile"
 (_,\/ \_/ \     TortoiseSVN
   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
   /_/   \_\     http://tortoisesvn.net
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Fri Oct 19 11:29:19 2007

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.