Stefan Küng <tortoisesvn_at_gmail.com> wrote:
> On 12.08.2009 17:56, Stefan Fuhrmann wrote:
> > Stefan Küng<tortoisesvn_at_gmail.com> wrote:
> >
> >> On 12.08.2009 12:40, Stefan Fuhrmann wrote:
> >>> * Log dialog
> >>> - speed up display of larger (>1000)
> >>> revision lists
> >>
> >> The list control is already virtual, so the only speedup would be by
> >> changing the whole filtering?
> >
> > Sizing the columns seems to be expensive.
> > There are a number of ways that we could
> > change that. Something along the lines of
> >
> > - auto-size only upon request (double-click
> > on separator in header)
> > - smallish default sizes
> > - heuristics to pick a good column width
> > (max of default, header, top row in bold + margin)
> > - storing column widths
>
> Or, just resize the colums to the visible rows.
> I just committed a change in r16908 which should speed up this part a
lot.
Yes, it's much faster now. Thanks!
> >>> * Explorer context menu and / or log
> >>> - "Bisect" to automatically and semi-
> >>> automatically find offending revisions
> >>
> >> What do you mean by "offending revisions"? What would such a feature
> >> actually do?
> >
> > GIT introduced this feature. The basic idea
> > is to specify a "good" (working) revision
> > and a "bad" (broken) revision plus some script.
> > Using bisection (based on length of actual
> > history not rev number arithmetics), the
> > first "bad" revision can be found.
> >
> > The script is used to decide upon "good" or
> > "bad". For TSVN, I would like to support
> > fully automatic operation (user specifies
> > test and optional cleanup scripts etc.)
> > as well as guided operation where the user
> > has to press either to 'good' or 'bad' button.
>
> So "working" or "good" means a commit that is tested, while "bad" is one
> that hasn't been tested yet. A bad revision can then be marked as good
> as soon as it was tested.
> Or am I completely wrong in my understanding of this feature?
Example. When I updated to r16848, which was
HEAD at that time, I suddenly found the repo
browser broken. The newest revision that I was
sure would work was r16829.
To track down the root cause, I had to
find the revision that introduced the problem.
So I tested
16841 -> broken
16836 -> broken
16834 -> broken
16832 -> o.k.
and found that r16834 somehow caused or at least
triggered that issue. Note that some revisions
in that range were made to other branches, e.g.
r16833.
I had to remember the revisions I already tried
and it took a number of clicks per revision to
get & test it. The whole point of the bisect feature
is to make the revision selection, the WC update
and optionally the test itself automatic. Even
without the test automation, it would have been
- initial selection of the revision range
- start bisect
- for each revision to test:
- <F5>, <ENTER> in Visual Studio (build & debug)
- kill / close app
- hit the 'good' or 'bad' button
This may seem like a marginal feature but it
is actually very useful and held to be one of
GIT's killer feature.
-- Stefan^2
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2383208
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-08-13 11:12:32 CEST