Get the new PortableApps.com Platform 10.0: Gorgeous themes, a full portable app store and advanced functionality
Announcing the World's Best Flash Drive: The PortableApps.com Companion

TortoiseHg Portable 2.4 Development Test 1

kAlug's picture
kAlug
Developer
(Homepage) - June 9, 2011 - 6:25pm

Application: TortoiseHg
Category: Development
Description: TortoiseHg is a set of graphical tools for the Mercurial distributed revision control system.

Download TortoiseHg Portable 2.4 Development Test 1 [18.2 MiB download / 26.7 MiB installed]
(MD5: 785806755727b07cae03369ea4556e90)

Release Notes:
2.4 Development Test 1 (2012-05-21): updated TortoiseHg to v2.4 (Mercurial 2.2.1)
2.3.1 Development Test 1 (2012-03-18): updated TortoiseHg to v2.3.1 (Mercurial 2.1.1)
2.2.2 Development Test 1 (2012-01-04): updated TortoiseHg to v2.2.2 (Mercurial 2.0.2)
2.2.1 Development Test 1 (2011-12-22): updated PAL to 3.0 Dev; updated TortoiseHg to v2.2.1 (Mercurial 2.0.1); switched to custom TortoisePlink portable build
2.2 Development Test 1 (2011-11-09): updated PAL to 2.2/tip; updated TortoiseHg to v2.2 (Mercurial 2.0)
2.1.4 Development Test 1 (2011-10-23): updated TortoiseHg to v2.1.4 (Mercurial 1.9.3); added option to disable Python bytecode files creation
2.1.2 Development Test 1 (2011-08-02): updated TortoiseHg to v2.1.2 (Mercurial 1.9.1); added PYTHONDONTWRITEBYTECODE
2.1.1 Development Test 1 (2011-07-07): updated TortoiseHg to v2.1.1 (Mercurial 1.9+10); bundled Visual Studio runtimes; fixed code to set the location of PuTTY.rnd; changed path to TortoisePlink.exe in order to support directories with spaces in the name.
2.1 Development Test 1 (2011-07-02): updated TortoiseHg to v2.1 (Mercurial 1.9); added AppCompactor.ini.
2.0.5 Development Test 2 (2011-06-12): added App\TortoiseHg to %Path%; added the entire HgRc.d directory to the search path.
2.0.5 Development Test 1 (2011-06-10): initial release


( categories: )

2.0.5 Development Test 2

  • Added the App\TortoiseHg directory to %Path%. The command prompt should now work properly.
  • Compressed application with UPX.
  • Added the entire HgRc.d directory to the search path. This enables automatic merge tools detection.

Did you set the working directory?

Nice!

I'm glad to see this as a portable app. Just out of curiosity, how did you keep it from creating its shell-integration Registry entries? All I could find in your launcher was the -nofork command-line option.

Portability looks good, PortableApps Format validation passed, and all functionality seems to be intact. Oh, and help.html displayed correctly for me in Iron.

Nice work. Smiling

"The question I would like to know, is the Ultimate Question of Life, the Universe and Everything. All we know about it is that the Answer is Forty-two, which is a little aggravating."

Thank you!

Good to know that everything worked fine for you.
Regarding the shell extension, I simply didn't installed it.

Did you set the working directory?

2.1 Development Test 1

Updated to TortoiseHg 2.1 / Mercurial 1.9.
Tip: to use custom extensions, put them somewhere in the Data directory and use ~, e.g. Data\customExtension -> customExtension=~/customExtension.

Did you set the working directory?

2.1.1 Development Test 1

Updated to TortoiseHg 2.1.1 / Mercurial 1.9+10.
Also bundled the Visual C++ Run-Times and fixed some paths.

Did you set the working directory?

Still working well

I've continued using this and it's working quite well. As far as I can tell, everything does what it's supposed to; I've done things ranging from pushing to pulling to patching to cloning, and it's all succeeded.

There was one bit of weirdness - I tried pushing changes shortly after being added to a project on SourceForge and TortoiseHg completely failed. It wouldn't even put up a password dialog. I ended up having to create a SSH key, launch Pageant, and then TortoiseHg properly pushed the changes. Oddly enough, it's requested my password ever since, and the SSH key hasn't been necessary. I don't know if that's TortoiseHg itself or a bug with the portable package, but I thought I'd mention it.

Oh, speaking of Pageant, I'd be appreciative if you could create a launcher for that too. I'm fairly sure it doesn't need anything special - I had no trouble running it directly from App\TortoiseHg - but a launcher would be nice to have.

Thanks!

"The question I would like to know, is the Ultimate Question of Life, the Universe and Everything. All we know about it is that the Answer is Forty-two, which is a little aggravating."

Only one problem

We can call TortoiseHg from Pageant. The problem is, how to tell Pageant to close?
Regarding your problem, I never had it (and I use passwords too). Maybe it's related to Pageant?

Did you set the working directory?

I don't think the original

I don't think the original issue was with Pageant, since I didn't try running it until after I'd struggled with TortoiseHg for awhile. It's probably just a newb/one-time issue, so if nobody else experiences it, go ahead and ignore.

To shut down Pageant, maybe just send the WM_QUIT message? I know that's a bit messy, but it doesn't look like Pageant provides a built-in way to shut down cleanly.

"The question I would like to know, is the Ultimate Question of Life, the Universe and Everything. All we know about it is that the Answer is Forty-two, which is a little aggravating."

True

I've checked the Pageant's source, and really there's no way to tell it to close.
I've come with this:

!include WinMessages.nsh
FindWindow $R0 Pageant Pageant
SendMessage $R0 ${WM_CLOSE} 0 0 # just close Pageant, or
SendMessage $R0 ${WM_COMMAND} 16 0 # use its internal mechanism, closing passwords dialogs too

Did you set the working directory?

2.1.2 Development Test 1

There are two decisions to be made:

  1. What's the best way to handle Pageant?
  2. Should PYTHONDONTWRITEBYTECODE be permanent or added as a option in AppNamePortable.ini?

Did you set the working directory?

For Pageant, I'd say your

For Pageant, I'd say your second method is probably best if that's what Pageant uses internally.

SendMessage $R0 ${WM_COMMAND} 16 0 # use its internal mechanism, closing passwords dialogs too

What does PYTHONDONTWRITEBYTECODE do? My quick web search didn't turn up much.

"The question I would like to know, is the Ultimate Question of Life, the Universe and Everything. All we know about it is that the Answer is Forty-two, which is a little aggravating."

Other instances; .py[co] files

We need to be careful to not close other instances. I'd like to know what John has to say about it.
The PYTHONDONTWRITEBYTECODE environment variable prevents the writing of .py[co] files. This is useful to avoid writing unnecessarily to the device. It's mostly useful with plugins cloned from a repository: the presence of new files can require a manual pull/merge.

Did you set the working directory?

Maybe use SingleAppInstance

Maybe use SingleAppInstance to make sure there are no other instances?

I'd say PYTHONDONTWRITEBYTECODE should be on by default if it gives things a major speed boost, but it would be nice to have the ability to turn it off as well.

"The question I would like to know, is the Ultimate Question of Life, the Universe and Everything. All we know about it is that the Answer is Forty-two, which is a little aggravating."

Pageant instances

I meant other instances of Pageant, including local ones.
I'll put PYTHONDONTWRITEBYTECODE as an option on AppNamePortable.ini.

Did you set the working directory?

Drop Pageant?

I've been thinking on removing Pageant from THGp, and somehow include it on PuTTY Portable. Opinions, please.

Did you set the working directory?

That is where it should be

I've been meaning to get round to improving PuTTY Portable to work nicely with pageant. Pageant should be in there, not in this.

I am a Christian and a developer and moderator here.

“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1

Yes

But then we have some problems:

  1. Multiple launchers
  2. Centralized data management (mostly for Plink)

Did you set the working directory?

Why multiple launchers?

I don't see why we would need multiple launchers. I would have Pageant be an add-on installer for PuTTY which just contains App\PuTTY\pageant.exe, and have PuTTY Portable launch it if it exists.

What data does plink need to deal with? (Is it that registry key?) My memory also suggests that TortoiseHg keeps its own copy of plink?

I am a Christian and a developer and moderator here.

“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1

Pageant is useful for more

Pageant is useful for more than just PuTTY though. I regularly use it with FileZilla, and I know it is also compatible with WinSCP (and probably more still that I don't know about).

It might be worth releasing as a standalone app, with the potential for any compatible apps to run it if it is installed.

Standalone Pageant; The usual

1. Pageant is useful to other apps standalone. Maybe we could replace launching PuTTY with Pageant; you could then run PuTTY from within Pageant.
2. The usual PuTTY settings. Regarding Plink, yes, but there isn't much difference between them:

TortoiseSvn Documentation
This is a version of the popular Plink program, and is included with TortoiseSVN, but it is compiled as a Windowless app, so you don't get a DOS box popping up every time you authenticate.

[...]

TortoisePlink does not have any documentation of its own because it is just a minor variant of Plink.

Did you set the working directory?

Posted on Mercurial sites

Hi everybody,

Thanks a lot for the effort put into this package. I tried it today and so far it works great! So I wanted to make more people aware and have posted about it here:

https://plus.google.com/108957994038017966408/posts/P65phN6BQW2
http://selenic.com/pipermail/mercurial/2011-December/041092.html
http://sourceforge.net/mailarchive/message.php?msg_id=28504179

Keep up the good work, it's very valuable!