tags:

views:

21

answers:

1

I went back to take a look at an earlier revision by doing:

hg update -r 10

Then, I wanted to go back to the tip by doing:

hg update

But I got this message and am not sure how to respond to it:

tool kdiff3 can't handle binary
tool tortoisemerge can't handle binary
tool winmergeu can't handle binary
tool docdiff can't handle binary
no tool found to merge target/classes/com/mypackage/MyClass.class
keep (l)ocal or take (o)ther?
+6  A: 

The main problem here is that you have .class files in your repository.

These are binary, and seeing as Mercurial thinks that you've changed it, almost certainly the result of compiling code you also have in your repository.

Keeping binary files in the repository is fine if those files are considered "from external sources", like libraries or whatnot that you download and want to keep alongside the source code.

However, the output of compiling source code in the repository should not be kept in the repository, since this will lead to problems like you have now.

It is basically telling you that after you updated to an older version, that particular file has changed, so it is no longer identical to the file you had in your repository for that older version.

And then it asks you whether you want to keep the modified copy, or update to the new one you have in the repository. "Local" here means "modified version from the old repository version", and "other" means "new version in the repository."

I would answer O for other in this case, but I would also try to get rid of those .class files from the repository altogether.


An example of why this happens can be that you have the following scenario (note that I'm no Java developer so I might get the exact details for Java wrong):

Revision 1, you commit:

  • TestClass.java
  • TestClass.class (the result of compiling TestClass.java)

Revision 2, you commit:

  • TestClass.java (with some changes from revision 1)
  • TestClass.class (again, the result of compiling the new TestClass.java)

Then you update back to revision 1:

  • Restore TestClass.java from revision 1
  • Restore TestClass.class from revision 1

Then you compile:

  • Build new TestClass.class, same source code, but probably contains things like timestamps of compilation which makes the file binary different, but semantically similar

Then you try to update back up to revision 2:

  • Merge conflict for TestClass.class due to it being binary

Here's a batch file (for Windows) that will reproduce your case:

@echo off
setlocal

rd /s /q test
md test
cd test

hg init .

rem ------------------------------------
rem Add .CS file and compile it
rem Producing main.exe
echo class Program { public static void Main() { } }>main.cs
csc /target:exe main.cs

hg addremove
hg commit -m "1"

rem ------------------------------------
rem Change and recompile and commit
echo class Program2 { public static void Main() { } }>main.cs
csc /target:exe main.cs

hg addremove
hg commit -m "2"

rem ------------------------------------
rem Update back to revision 1
hg update 0

rem ------------------------------------
rem Compile
csc /target:exe main.cs

rem ------------------------------------
rem Try to update up to revision 2
hg update 1

Output:

[C:\Temp] :test
Microsoft (R) Visual C# 2010 Compiler version 4.0.30319.1
Copyright (C) Microsoft Corporation. All rights reserved.

adding main.cs
adding main.exe
Microsoft (R) Visual C# 2010 Compiler version 4.0.30319.1
Copyright (C) Microsoft Corporation. All rights reserved.

2 files updated, 0 files merged, 0 files removed, 0 files unresolved
Microsoft (R) Visual C# 2010 Compiler version 4.0.30319.1
Copyright (C) Microsoft Corporation. All rights reserved.

tool beyondcompare3 can't handle binary
tool bcomp can't handle binary
tool beyondcompare3 can't handle binary
tool kdiff3 can't handle binary
tool diffmerge can't handle binary
tool tortoisemerge can't handle binary
tool docdiff can't handle binary
 no tool found to merge main.exe
keep (l)ocal or take (o)ther? interrupted!
Lasse V. Karlsen