On 02.04.2010 07:17, Steve Borho wrote: > On Thu, Apr 1, 2010 at 11:06 PM, Yuki KODAMA <[email protected]> wrote: >> On Fri, Apr 2, 2010 at 13:39, Steve Borho <[email protected]> wrote: >>> On Thu, Apr 1, 2010 at 11:28 PM, Yuki KODAMA <[email protected]> wrote: >>>> On Fri, Apr 2, 2010 at 13:21, Mark Tolonen <[email protected]> >>>> wrote: >>>>>> I installed 1.0.1 to Windows XP 32-bit box. >>>>>> But the installer appends "C:\Program Files\TortoiseHg\" to PATH >>>>>> environment variable, >>>>>> not "C:\Program Files\TortoiseHg". As a result, we can't use "hg" >>>>>> command via Windows >>>>>> command prompt. >>>>> >>>>> It works either way. I have Windows XP and the same PATH entry and it >>>>> works. >>>>> >>>>> Windows doesn't care if you put multiple backslashes in a row, e.g., this >>>>> works: >>>>> >>>>> dir "C:\Program Files\\\\\\\TortoiseHg\\\\\\\\\\\\\\\\\\\" >>>>> >>>>> (although it *is* picky about only a single one after the colon, at least >>>>> on >>>>> XP) >>>> >>>> Yeah, you're right, Mark. Thanks for replying. >>>> This is trivial issue, we won't need to ship 1.0.1-1 (installer fix >>>> version). >>>> But if possible, I hope this issue will be fixed for 1.0.2. >>> >>> (dropping hg-user mailing list) >>> >>> Phew. I was quite curious about this because the PATH mechanism >>> hasn't changed since 1.0. The trailing slash is a side-effect of the >>> way Windows Installer treats directory variables; it always appends >>> the trailing slash for easy concatenation. I'm not sure if there's an >>> easy way to strip it. >> >> Does 1.0 installer append trailing backslash to PATH? >> WiX source codes were changed very often, so I couldn't follow all of them.
Yes, there were quite some changes in the installer sources in stable, even more in default. So make sure you look only at changes in the stable branch. I recommend to make a 'stable only' local clone using hg clone http://bitbucket.org/tortoisehg/stable#stable thg-stable so you can see the stable changes *alone*. For example I fixed a hefty bug in 1.0 with component GUIDs that were illegally shared between the thg and hg installer. Luckily this can only manifest if both installers are installed on the same machines, which isn't recommended anyway, since both install a command line hg. And I quite liberally reformatted the xml sources, so that changes should be easier to review now (even more in the default branch). But the single change steps done in the installer changes should be easily checkable. I strongly recommend to use a graphical diff tool like the kdiff3 (installed as the default visual diff tool) when checking diffs of the xml sources. The formatting changing steps (e.g. indentation changes) are a snap to review with kdiff3. These are impossible to review when only looking at the standard patches. BTW, working with xml sources is almost impossible without a syntax highlighting editor (I use Notepadd++). > 1.0: > <Environment Id="Environment" Name="PATH" Part="last" System="yes" > Permanent="no" Value="[INSTALLDIR]" Action="set" /> > > 1.0.1: > <Environment Id="Environment" Name="PATH" Part="last" System="yes" > Permanent="no" Value="[INSTALLDIR]" Action="set" > /> Specifically for the 1.0.1, this time around, I even tested the exact msi's built by Steve on the three most important platforms before the msi's were published. A novelty on the TortoiseHg project. I bet the 1.0.1 release is the best tested release ever of TortoiseHg. hg and hgtk command line worked perfectly fine when entered a plain cmd.exe console right after installing the now published 1.0.1 msi's on Windows XP x86 SP3, Windows 7 x86 and Windows 7 x64 (all clean installs with 1.0 preinstalled, so the 1.0 upgrade was tested with the final msi's). And I did a lot of testing with several close-to-1.0.1 stable nightlies built by Steve and myself before the 1.0.1 release. On all six supported platforms. Yuki, as soon as you get your Microsoft CodePlex sponsored MSDN subscription as well, you should install something like the gratis VirtualBox and install a clean Windows XP in a virtual machine there for installer testing. You don't even need a lot of harddisk space for a VirtualBox virtual machine instance, as it only eats up as many bytes as really needed by the install (the hard-disk sizes reported to the virtual Windows are virtual as well. So if you do a virtual harddisk of 80 GB it the image file will *not* eat up 80 GB on your pysical harddisk). Testing installs on our - ususally quite loaded and tweaked - developer Windows installs is almost pointless for finding install bugs. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Tortoisehg-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tortoisehg-discuss
