[ANN] TortoiseHg-0.3

[Steve Borho]

[cc'ing tortoisehg-discuss]

On Sat, 2008-02-02 at 20:07 -0800, Brad Schick wrote:
> Steve Borho wrote:
> > New in this release is an improved changelog viewer and a new
> > data-mining tool (combination of annotate and grep).  Now that
> > TortoiseHg has a credible changelog viewer we are removing hgview and
> > hgk from the binary installer.  
> Nice job. Good to see so many new dialogs available. Since I haven't 
> been contributing for a while, all I have is feedback. Mostly small stuff:
> 
> -In the changeset browser I'd personally rather see the file selection 
> panel on the left side

I followed the convention of hgk and hgview in this respect, but now
that you mention it having the files on the left would be more natural.
I suspect hgview simply followed hgk's lead, and hgk followed... some
bad gitk interface design.

>  and when selecting a file only see the diff for 
> that one file. That would provide an easy way to copy and paste just one 
> file's diff. 

That is debatable.  I prefer the more concise format where simple
changesets are entirely visible by default.  Why would you need to
cut-paste entire diffs when you can export/email patches or revert files
directly from the context menu?

> Currently its also a bit odd when you have a few small 
> diffs that fit on a single screen and clicking the files does nothing. 
> The "description" could continue to show all.

That's just the way Gtk handles jump-to-mark.

> -With a large diff the changeset browser and log viewer are very slow 
> and consumes 100% of the cpu until ready.

Yep, the changeset viewer uses a modified version of hgview's patch
parser to fill the file list and patch window.  It's much faster in
total time than extracting the diffs one at a time (my first
implementation), but it is true that large diffs can stall the interface
for several seconds.  Hgk handles this well, but it has a high per-file
overhead as it's parsing diffs.  It's total time is much worse, but it's
responsive while it's loading.

It would be nice to move this processing to a gobject idle thread so the
files are added to the display as they are parsed.

> -Also with a large diff selecting a file in the changeset browser 
> doesn't scroll the diff.

You must be getting a traceback.  Can you check if you get errors when
this occurs?  There's no other reason for it not to scroll.

> -Would be nice to have a way to cancel running datamining searches. I 
> ran two regexp searches that consumed 100% of the cpu and didn't end 
> until I killed python (which I now can't repro).

Anyone know how to stop a Python thread?

> -Some keyboard shortcuts are broken. Alt-Q for example no longer closes 
> dialogs.

Can you figure out which changeset broke this?

> -Seems like the user + password for the sync dialog shouldn't be in two 
> separate popups.

ui.prompt() and ui.getpass() are two different API calls.

> -The browse button the "serve" dialog doesn't do anything on my setup 
> (firefox under windows)

Works for me with firefox on Windows.  Are you getting any errors in the
tracelog window?  Does it behave differently if firefox was already
started?

> -Formating on some of the dialog like 'merge' and 'update' is a bit 
> rough. Text is flush left with the boarder.

Patches welcome, or make a note on the TODO page on the Wiki.

> -On windows running external tools like editors and diff tools opens a 
> blank console (cmd.exe) window.

Really?  I haven't seen this.  Can you file a bug report for this?

> -On the status dialog, right click then "log" does nothing.

And a bug report for this?

> -I'd like to see the shell integration be optional and have all the 
> dialogs exposed as hg extension(s). hgtk is fine, but and extension 
> would be a bit better IMO.

There's instructions on the FAQ for disabling the shell extensions.  I
wasn't able to make them optional at install time this time around, but
it is a goal.

> But overall its nice progress. I'll try it under Gnome next week.

Thanks, I believe it is progressing quite well.

-- 
Steve Borho (steve at borho.org)
http://www.borho.org/~steve/steve.asc
Key fingerprint = 2D08 E7CF B624 624C DE1F  E2E4 B0C2 5292 F2C6 2C8C