Version control support! Wheee!

[pietzcker]

Hi,

am just downloading V6.40 - has anyone already gotten UC to work together with Mercurial/TortoiseHg? Seems to be a favorite nowadays, surely is mine...

Cheers,
Tim

[Mofi]

Don't know anything about Mercurial/TortoiseHg, but found the TortoiseHg FAQ. And according to the explanation on this page following may work

---

Add these lines to your personal Mercurial.ini file

[extdiff]
cmd.UltraCompare = C:\Program Files\IDM Computer Solutions\UltraCompare\uc.com
opts.UltraCompare = -d

Now run the Global Settings tool. On the TortoiseHg tab, you should see UltraCompare available in the drop-down list for Visual Diff Command. Select UltraCompare, apply, then close.

---

I'm not sure about the command line parameter. Is a directory or a file comparison started by Mercurial/TortoiseHg, or both?

If above does not work because Mercurial/TortoiseHg calls the comparison tool with files as well as with directories, don't use opts.UltraCompare (or let it blank) and specify instead of uc.com a batch file which finds out if the parameters are files or directories and then calls uc.com accordingly.

Note: uc.com can call uc.exe only when directory of uc.exe is specified in environment variable PATH. Something I don't like and therefore I have already sent an enhancement request because I think, uc.com can find uc.exe itself by first using its own path (uc.exe is normally in the same directory as uc.com) and if not found, try itself to find uc.exe using the directories specified in environment variable PATH. Last uc.com could look also into the registry for HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\uc.exe to get the path of uc.exe. I write this here with the hope that other UC Prof. users also request from IDM an uc.com finding uc.exe without the need to add the UltraCompare directory to environment variable PATH. A workaround for using uc.com without UC program directory in PATH is to use a batch file which contains at top:

set PATH=C:\Program Files\IDM Computer Solutions\UltraCompare;%PATH%

or calls instead of uc.com directly uc.exe with the command:

start "UltraCompare" /wait "C:\Program Files\IDM Computer Solutions\UltraCompare\uc.exe" ...

[pietzcker]

Sorry to resurrect this post after such a long time. I have been trying around and am halfway there.

I have been quite successful with these settings in Mercurial.ini:

Code: Select all

[ui]
merge = UltraCompare

[extdiff]
cmd.UltraCompare = C:\Programme\UltraCompare\uc.com

[tortoisehg]
vdiff = UltraCompare

[merge-tools]
UltraCompare.executable = C:\Programme\UltraCompare\uc.com
UltraCompare.args = $base $local $other
UltraCompare.priority = 1
UltraCompare.gui = True
UltraCompare.binary = True
UltraCompare.checkconflicts = True
UltraCompare.checkchanged = True

However, this only works if the path that the repository I'm merging to does not contain a space in the pathname.

With a path like D:\test\test-merge, UC loads the files happily, and the 3-way merge works perfectly. UC loads the following files:

Code: Select all

Erster Dateiname: c:\Dokumente und Einstellungen\Install\Lokale Einstellungen\Temp\letter.txt~base.ft4bzc
Zweiter Dateiname: D:\test\test-merge\letter.txt
Dritter Dateiname: c:\Dokumente und Einstellungen\Install\Lokale Einstellungen\Temp\letter.txt~other.aj_ywn

But with a path like D:\Eigene Dateien\Tim\test\test-merge, UC gets confused:

Code: Select all

Erster Dateiname: D:\Eigene Dateien\Tim\test\test-merge\ c:\dokume~1\install\lokale~1\temp\letter.txt~base.lm3i7r D:\Eigene
Zweiter Dateiname: c:\Dokumente und Einstellungen\Install\Lokale Einstellungen\Temp\letter.txt~other.gxw4h6

I have already tried to add quotes around the path placeholders, but to no avail:

Code: Select all

UltraCompare.args = "$base" "$local" "$other"

Any other ideas?

[fgeurts]

Have you tried setting the path name using the DOS short names. When I have a large number of adds or commits to do, rather than tying up UES I run the commands in a batch file with the path as follows, because space in the names here too cause a problem.

C:\PROGRA~2\IDMCOM~1\UESTUDIO\GNU\cvsnt\cvs.exe -d :pserver:fg193045@nix.aus.sun.com:/export/p..........

Cheers...

Frank

[pietzcker]

I don't think I can. The problem is the path of the repository, and that variable is filled automatically by TortoiseHg. The workaround would be to avoid a path or filename with spaces in it, but that's not really nice.

Is there perhaps a tool (needs to be an .exe or .com) that will simply output all the parameters it has been passed, so I can analyze what's going on? I could set up this tool as another third-party merge tool and then see what TortoiseHg is passing to it.

[Mofi]

You can use Process Explorer from SysInternals. Click with right mouse button on a running application to open the context menu and click on Properties. On tab Image you see the Command line as used for starting the application.

[pietzcker]

Great idea!

Process explorer shows the following command line:

Code: Select all

"C:\Programme\IDM Computer Solutions\UltraCompare\uc.exe" " "c:\dokume~1\tim~1.pie\lokale~1\temp\test.txt~base.akr6au" "E:\Eigene Dateien\test\test-merge\test.txt" "c:\dokume~1\tim~1.pie\lokale~1\temp\test.txt~other.b92442"


Note the extraneous " between the executable and the three parameters. If I remove that ", UC starts up just fine. Looks like the command line generated by TortoiseHg is wrong.

EDIT: I've just tried it with a working, i.e. space-less repository. Now there is no extraneous " in the command line:

Code: Select all

"C:\Programme\IDM Computer Solutions\UltraCompare\uc.com" "c:\dokume~1\tim~1.pie\lokale~1\temp\test.txt~base.e7vryp" "E:\test\test-merge\test.txt" "c:\dokume~1\tim~1.pie\lokale~1\temp\test.txt~other.u_qxme"

[pietzcker]

I've posted this problem in the Mercurial bugtracker, and the developers seem to be have found the problem (on Mercurial's side). Apparently shell quoting isn't working quite as it should on Windows.

http://mercurial.selenic.com/bts/issue2076 and http://selenic.com/pipermail/mercurial- ... 19506.html

for details, in case anyone is interested

[pietzcker]

Uh oh. Looks like the problem is on UltraCompare's side after all:

If I specify uc.com as the recipient of the command, then the command line gets garbled (as shown in the examples above). If I send the command line to uc.exe directly, everything works. So it seems that uc.com somehow messes up the command line if it contains quoted strings with spaces in them.

Can anyone reproduce this?

Cheers,
Tim

[mwb1100]

Just for future reference, I've used the following simple .c program to help figure out what was going on when trying to configure UE (or any other program) to launch a tool:

Code: Select all

#include <stdlib.h>
#include <stdio.h>


int main( int argc, char** argv)
{
    int i = 1;
   
    for (i = 0; i < argc; ++i, ++argv) {
        if (!(*argv)) {
            *argv = "(null)";
        }
        printf( "arg[%d]: \"%s\"\n", i, *argv);
    }

   return 0;
}


[Mofi]

Indeed, this problem is caused by uc.com. I have installed UltraCompare in C:\Programs\Compare and I use most often F:\Temp as test directory. So I don't need double quotes. But for testing I created "C:\Program Files\Compare" and copied the UltraCompare program files into this directory. Further I created "F:\Temp\Test Dir" and copied three files with the names "Test 1.txt", "Test 2.txt" and "Test 3.txt" into this directory. Next I started Process Explorer for looking on the command lines of uc.com and uc.exe and opened a command prompt window in directory "C:\Program Files\Compare". The UltraCompare directory is not in my PATH environment variable and therefore I used in the command prompt window

set PATH=C:\Program Files\Compare;%PATH%

because (in previous versions) it was not possible to use uc.com without having the UltraCompare program directory specified in PATH.

First I executed the command line:

uc.com "F:\Temp\Test Dir\Test 1.txt" "F:\Temp\Test Dir\Test 2.txt" "F:\Temp\Test Dir\Test 3.txt"

which worked and uc.exe was called by uc.com with

"uc.exe" "F:\Temp\Test Dir\Test 1.txt" "F:\Temp\Test Dir\Test 2.txt" "F:\Temp\Test Dir\Test 3.txt"

It looks like uc.com has added extra double quotes around the first argument - the executable name of uc.exe.

Next I executed from the command prompt window

"C:\Program Files\Compare\uc.com" "F:\Temp\Test Dir\Test 1.txt" "F:\Temp\Test Dir\Test 2.txt" "F:\Temp\Test Dir\Test 3.txt"

and this time I got the same error message as you. Process Explorer showed my that uc.exe was called from uc.com with the command line

"C:\Program Files\Compare\uc.exe" " "F:\Temp\Test Dir\Test 1.txt" "F:\Temp\Test Dir\Test 2.txt" "F:\Temp\Test Dir\Test 3.txt"

Next I called uc.com from within the command prompt window with

"uc.com" "F:\Temp\Test Dir\Test 1.txt" "F:\Temp\Test Dir\Test 2.txt" "F:\Temp\Test Dir\Test 3.txt"

which resulted in the same problem because uc.com called uc.exe with the command line

"uc.exe" " "F:\Temp\Test Dir\Test 1.txt" "F:\Temp\Test Dir\Test 2.txt" "F:\Temp\Test Dir\Test 3.txt"

So uc.com has definitely a problem when its name (argument 0) is itself double quoted.

I knew from tests with previous versions of UltraCompare that uc.com called uc.exe by always using just uc.exe and appending the other parameters. This was the reason why uc.com could be used only when UltraCompare program directory was specified in the environment variable PATH or uc.com was called with working directory set first to UltraCompare program directory. Therefore I suggested IDM to improve that by analyzing argument 0 which contains uc.com or just uc or "C:\Program Files\Compare\uc.com" or any other variation, replace .com by .exe or append .exe if there is no .com and test if the uc.exe exists. If this is the case, call uc.exe with that argument. Because of the inserted double quotes I closed the command prompt window and re-opened it resulting in a new copy of PATH without UltraCompare program directory in PATH.

I executed now

uc "F:\Temp\Test Dir\Test 1.txt" "F:\Temp\Test Dir\Test 2.txt" "F:\Temp\Test Dir\Test 3.txt"

and this worked. uc.exe was called with

"uc.exe" "F:\Temp\Test Dir\Test 1.txt" "F:\Temp\Test Dir\Test 2.txt" "F:\Temp\Test Dir\Test 3.txt"

So it looks like the IDM developers have in the meantime improved call of uc.exe according to my suggestion. They have just make a mistake because the code is not working correct if uc.com was called with double quotes.

Please report that problem quickly for being fixed in UC v7.10.

[pietzcker]

I have reported it, and IDM support was also able to reproduce it. Apparently, it's also causing problems with TortoiseSVN.

I still don't completely understand what uc.com is actually needed for. In what situations do I need it as opposed to just calling uc.exe? Just so I can receive an error or status message in the command line window (or via stdout/stderr)?

[Mofi]

I still don't completely understand what uc.com is actually needed for. In what situations do I need it as opposed to just calling uc.exe?

Using uc.com makes only sense when running multiple compares from within a batch file where uc.exe writes the output of the compare into a results file because of using -o "output results.txt". Starting Windows applications from within a batch file results in immediately continue of batch file execution after calling the Windows application. Using uc.com avoids this problem because it waits until uc.exe terminates. Of course using

start "UltraCompare" /wait uc.exe ....

could be also used and therefore uc.com is not really needed except when the batch file also evaluates the result of every compare. I have created for testing purposes a batch file which runs dozens of compares with different parameters to test the output results. The main problem with such batch files calling uc.exe several times is that UltraCompare is opened always with the window as last closed by the human user and steals the focus from other applications (minimized window on last exit does not help). So when I execute this batch file, I can't work the next 10 minutes until the batch file finished. I suggested IDM that UltraCompare should run without opening a window when command line contains -o or -op resulting in a completely automatic compare with writing results into an output file and exiting automatically. But it is not really easy to write a Windows application mainly designed to work with GUI to work based on the command line options without opening a GUI window (except for error messaging dialogs). It is possible as Regedit demonstrates, but it is very hard to code as far as I know from some articles I read as I once wanted to write such an application (and have giving up this idea after reading the articles and just wrote a pure console version).

There are also maybe other users calling UltraCompare just once in a batch file and evaluating the result (equal or different) to decide how to continue. Such batch files need uc.com because result of uc.exe can't be evaluated from within a batch file.

[pietzcker]

Thank you very much. This is very helpful for me. Is there a reference on what uc.com will output to the console (or which return values it uses)? Specifically, is there a way to find out whether a merge operation was successful or if the user aborted UC without saving the results?

[Mofi]

Unfortunately the documentation on output of uc.com is very poor. There is the power tip Command line quick difference check. Which errorlevels are set by uc.com if at all is not documented. The other power tip Command line tips shows the command lines needed for UC prior version 6.40. I just reported by email that this power tip is not up-to-date (= incorrect for UC v6.40 and later).

Attached is an encrypted RAR file which contains my command line test set I created for beta testing UC v6.40. The password to unpack this RAR archive is ShowMeMofisTestSet. With that test set you can quickly run specific tests (look into the 2 batch files) and find out what you need.

I think, uc.com is not helpful when a user has to do something manually in UltraCompare. But I have never run tests with user interactions.