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

Re: Log dialog: Date selectors, summary line, range selector and chan ge request

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: 2007-01-05 20:52:46 CET

Lübbe Onken wrote:

> I have a small annoyance with the date selectors in the log dialog.
> 1) Just try to enter a date manually (how old fashioned :)) by clicking on
> one of the date selectors. Immediately when you finished entering a number
> (day, month or year), the filter is applied and the cursor is placed in the
> text filter box. If I want to enter a from date like 01.06.2004, I have to
> place the cursor in the date selector three times. Not nice.

Changed in revision 8428.

> 2) It is also possible to get the date selector into a state where it
> doesn't accept a manually entered date at all. This happens when the entire
> date string is selected and not just a substring. No matter what you type,
> the date is ignored even when it's in the available date range. To me it
> looks like there is an edit box on top of the combobox which is active. The
> only way to recover is to click onto the arrow and select a date from there.
> Afterwards a date can be entered manually again (See 1)

Fixed in revision 8429.

> 3) Clicking on "today" in the calender view doesn't do anything. Is it
> supposed to do something?

Removed those in revision 8430.

> 4) In the summary line the revisions are given in the order: total, highest,
> lowest, selected. Wouldn't it be more intuitive to show the from - to range
> in the order lowest - highest instead?

Since the log dialog shows the revisions from top to down, I thought
'highest, lowest' was ok.
But I've changed it according to your suggestion in revision 8431.

> 5) Same for the revision range selector. I know that most of the time you
> want to view the latest N revisions (looking from now into the past), so
> there is a logic behind it. Human intuition (at least mine) sees from - to
> as an ascending range and not as descending. Look at the default settings in
> the merge dialog (from zero to HEAD). I know you can do reverse merges, but
> there's a reason for calling it reverse :). I'd like to have the same
> default in the log dialog. From low to high without influencing the sort
> order in the list.

Sorry, but the log dialog already shows the logs by default in "reverse"
order, because that's what people expect and that's what's useful. You
don't want to see the revision 1 on top, and therefore you select the
revisions from top to bottom.

> 6) There's a bug in this system. Show the TortoiseSVN log. Select from 8000
> to HEAD. The log shows "395 revisions, from 8000 to 8423". Click on "Next
> 100". The log shows "494 revisions, from 8000 to 8321". The number of
> fetched revisions is added to the count but subtracted from the "to" value,
> which is wrong when the revisions are shown in ascending order.
> 7) There is also no progress indicator if the revisions "from 8000 to HEAD"
> are fetched.

I'll do these tomorrow.

> Change request:
> ===============
> It could be a good idea to separate the "Next N" button into "Previous",

I really hope your kidding here :)
Seriously: more buttons? I think the log dialog is crowded as it is, we
really don't need any more options there.

And Lübbe, you should know better:
next time please post a separate mail for every issue. Your mail is
*very* long and discusses several issues.
After all, you yourself helped creating this page:
and the fourth section there states: "Only report one problem in each
bug report".


   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 Jan 5 20:52:55 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.