On 06/11/2007, Alexander Klenin <klenin@gmail.com> wrote:
> Sorry for a delay -- I was overloaded at work.
> Now that I have actually installed recent nightly at work and tried to use it
> for several days, I have more comments.
>
> Good news: it is actually tolerable to work with, just slightly worse
> then before
> (for me, that is, I am sure novice users will find it much easier).
> To improve it, I suggest:
> 1) Put 'Merge' button at the bottom of the dialog, disable it on the
> first page --
> this will allow skipping the last page which contains rarely modified settings.
> 2) Create a (hidden?) option to start merge wizard from the second page
> (because 99% of time users would select first radio button on the first page).
> This will reduce common case back to a single dialog, while retaining
> interface simplifications.
> Anyway, even if you reject my suggestions,
> the current wizard is quite usable, just inconvenient.
Well that's strange. Just last night I was about to suggest almost the
same things, but with a small variation. Have a 'merge-meister' mode
(this is a term subversion uses) which might be in the settings
dialog, or a hidden registry setting. If that mode is selected then:
1. Go straight to the 2nd page, remembering the merge type from last
time. If it is wrong, just use the [back] button to go back and change
it.
2. Enable the Merge button on the 2nd page, so you can skip the last
page. But this should only happen in merge-meister mode, not for
normal users, otherwise they will miss the last page.
> Other good news: Revision range list and 'merge all' features look powerful.
>
> Bad news: these features do not (yet) work ;-)
> My most common use case is to merge all revisions from topic branch into
> either a review branch or trunk.
> 1) When merging a range of revisions from branch to trunk, only
> globally consecutive
> revision numbers gets translated into ranges. Correct behavior would be
> to make ranges from all revisions which are consecutive on the selected branch.
> This is a serious regression, as it essentially forces me to enter
> revision ranges by hand.
> I could take a look at fixing this, but not very soon, I am afraid.
>
> 2) Although 'merge all revisions' does what it is intended to do,
> it is not what users expect -- I already asked three developers at my company,
> and not one of them intuited it correctly.
> What I (and them) want it to do is to take all revision from
> selected branch not yet merged into the branch of the working copy.
I don't understand. These sound the same to me. What it is intended to
do is to merge all revisions which have not yet been merged. Of course
this will ONLY work correctly if you have the merge tracking
information to say which revs have already been merged.
Simon
--
___
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 Tue Nov 6 11:44:03 2007