Warning: Can't find ancestor for X copied from Y - mercurial

While running hg convert or hg graft I am seeing warnings similar to this:
warning: can't find ancestor for 'service/src/main/java/com/vtlr/web/sql/package
-info.java' copied from 'service/src/main/java/com/vtlr/sql/package-info.java'!
What does the warning mean?
Am I losing data in the conversion/graft? What can I do to correct the problem?
(I am running Mercurial 3.0)

Related

How to recover repository when hg recover aborts?

Due to unknown reasons an HG command failed with the message:
abort: abandoned transaction found - run hg recover!
But when I tried to use recover to get rid of the abandoned transaction, I got a different error:
$ hg recover
rolling back interrupted transaction
attempted to truncate path/to/file to 12345 bytes, but it was already 456 bytes
and it aborted. The actual file was named like:
_some_filename.cs.i
which is an internal HG data file. So it seems like the HG data records for some_filename.cs are badly clobbered. And indeed running hg verify shows errors like this:
# hg verify
checking changesets
checking manifests
crosschecking files in changesets and manifests
checking files
warning: revlog 'data/project/folder/some_filename.cs.i' not in fncache!
13691: empty or missing project/folder/some_filename.cs
project/folder/some_filename.cs#13691: manifest refers to unknown revision b269f6036278
project/folder/some_filename.cs#13741: manifest refers to unknown revision 651b96abf6da
...
(goes on for a long time)
which corroborates that the file is damaged but doesn't do anything useful to fix it.
hg recover --help doesn't show anything else that I can do...
And aside from the apparent damage to this one file, no ordinary HG commands work at this point. All of them report the repository is damaged. How can I recover from this?
I concluded that this was just a situation that HG was not designed to deal with. For whatever reason HG's internal data file (the .i file) was destroyed.
It was helpful to review the HG source code which produced the key error:
if fp.tell() < o:
raise error.Abort(
_(
b"attempted to truncate %s to %d bytes, but it was "
b"already %d bytes\n"
)
% (f, o, fp.tell())
)
(https://fossies.org/linux/mercurial/mercurial/transaction.py)
I'm not especially familiar with HG internals but this seemed to make it clear enough that HG was not able to handle the situation (understandably - arbitrary destruction of one of its data files leaves few options!).
The best workaround I could come up with was to manually copy the damaged .i file from another copy of the repository (on another PC). I didn't actually have local changes to that source file, so this seemed reasonable.
I copied the file (replacing the damaged original having made a backup first).
Then ran hg recover. This was now able to resolve the original "abandoned transaction" issue. Other HG commands work as well.
Worth noting that running hg verify still reports some errors (though many fewer). Perhaps the history of this single file is still not right; ultimately I think I will need to re-clone this repository but at least I can complete my immediate tasks without losing any work.

tortoisemerge with Hg reports all lines as changed

I'd like to use TortoiseMerge with Mercurial to resolve conflicts, but its reporting every line in theirs and mine as added as though its not comparing properly
here is my mercurial.ini:
[ui]
merge = TortoiseMerge
[merge-tools]
TortoiseMerge.executable=C:\Program Files\TortoiseSVN\bin\TortoiseMerge.exe
TortoiseMerge.args=/mine:$local /theirs:$other /base:$base -o /merged:$output
I'm using Hg 1.7.5
What's going on?
Update: When using KDiff or BeyondCompare, the base is always empty.
Thanks
Your setup appears correct.
This is symptomatic of having no copy of the file in the base revision, in which case Mercurial acts as if the file was present but empty.
There are a couple ways of figuring out what's going on here. If there are no copies or renames involved, you should be able to simply do:
$ hg log -r "ancestor(p1(), p2())"
..to determine the ancestor of the merge, then:
$ hg manifest -r <rev> | grep <your file>
..to determine if the file was in fact present.
Alternately, you can run 'hg merge --debug' or 'hg update --debug' to see what changeset and file it's choosing for the merge (including rename/copy details).
If you find that the file is present in the common ancestor Mercurial chooses, then you should report a bug (including your debug output) at:
https://www.mercurial-scm.org/wiki/BugTracker

Mercurial adding new file gives no match found error

I have a strange problem with updating Mercurial. Everytime when I add a file to my repository and then update another location of the repository (for example with in CI process), the error "no match found" occures. Then when I remove to whole folder and clone it again there are no problems and the new added file(s) are there. Updating and removing doesnt give problems
When I do "a" Verify the following is shown:
data/test.txt.i#54: missing revlog!
54: empty or missing test.txt
test.txt#54: b80de5d13875 in manifests
not found 3 integrity errors
encountered! (first damaged changeset
appears to be 54)
Any idea what could be causing this?
EDIT
The complete trace:
ThoughtWorks.CruiseControl.Core.CruiseControlException:
Source control operation failed:
abort: data/test.txt.i#b80de5d13875:
no match found! . Process command: hg
update --noninteractive at
ThoughtWorks.CruiseControl.Core.Sourcecontrol.ProcessSourceControl.Execute(ProcessInfo
processInfo) at
ThoughtWorks.CruiseControl.Core.Sourcecontrol.Mercurial.Mercurial.GetSource(IIntegrationResult
result) at
ThoughtWorks.CruiseControl.Core.IntegrationRunner.Build(IIntegrationResult
result) at
ThoughtWorks.CruiseControl.Core.IntegrationRunner.Integrate(IntegrationRequest
request)
The "repository corruption" is not patent here, since you can clone again, and retrieve the all content (old and newly added).
So the different points to check are:
1/ process conflict of some kind (something preventing data/test.txt.i#b80de5d13875 to be written, even so the file content is recorded)
2/ hg revlog and hg debugindex, to check out the versions actually recorded in your repo.
3/ hg verify to rule out any repo corruption.
4/ check the integrity of your repo

Mercurial internal:merge and binary file conflicts

Folks, I'm using internal:merge tool since I'm not a big fan of GUI diff tools. I really like it and the only thing I find a bit confusing and not quite convenient is its behavior for binary file conflicts.
It can't merge binary files and exits which is absolutely correct. However in the directory with the conflicting file "foo" it creates only "foo.orig" file.
Can it at least create "foo.other" as well so I can pick which version of file to use(mine or the pulled one)?
P.S. I asked the same question in Mercurial mailing list but noone replied me for several days, maybe I'll have more luck here :)
You have already gotten some input to your question on the Mercurial mailing list -- I went ahead and tried making the script suggested in the thread. It's been a long while since I've used Subversion, but I think this simple script does the trick:
#!/bin/sh
cp "$1" "$1.mine"
cp "$2" "$1.base"
cp "$3" "$1.other"
false
The final false command makes the script return a non-zero exit code, signaling to Mercurial that the merge failed. For Windows it looks like this (thanks Pavel):
#copy %1 %1.mine
#copy %2 %1.base
#copy %3 %1.other
exit 1
I saved the Unix version in ~/tmp/m.sh and tried it with no other merge settings configured than
[ui]
merge = ~/tmp/m.sh
I made a repository with two heads, each with a conflicting change to a JPEG file (mg.jpg). I also added a non-conflicting change to a text file (a.txt). Merging gave:
% hg --debug merge
searching for copies back to rev 1
resolving manifests
overwrite None partial False
ancestor 0848c2f8f8f8 local 845b8aa076bd+ remote f611c55aa8ec
mg.jpg: versions differ -> m
a.txt: versions differ -> m
preserving a.txt for resolve of a.txt
preserving mg.jpg for resolve of mg.jpg
picked tool '~/tmp/m.sh' for a.txt (binary False symlink False)
merging a.txt
my a.txt#845b8aa076bd+ other a.txt#f611c55aa8ec ancestor a.txt#0848c2f8f8f8
premerge successful
picked tool '~/tmp/m.sh' for mg.jpg (binary True symlink False)
merging mg.jpg
my mg.jpg#845b8aa076bd+ other mg.jpg#f611c55aa8ec ancestor mg.jpg#0848c2f8f8f8
merging mg.jpg failed!
0 files updated, 1 files merged, 0 files removed, 1 files unresolved
use 'hg resolve' to retry unresolved file merges or 'hg up --clean' to abandon
The nice thing is that the pre-merge could merge a.txt by itself and so no a.txt.* files were created:
% hg stat
M a.txt
M mg.jpg
? mg.jpg.base
? mg.jpg.mine
? mg.jpg.orig
? mg.jpg.other
You can probably fine-tune this script further to suit your needs -- if you do so, then consider adding the information to the Mercurial wiki or at least post your finding on the mailing list.

How to resolve merging conflicts in Mercurial (v1.0.2)?

I have a merging conflict, using Mercurial 1.0.2:
merging test.h
warning: conflicts during merge.
merging test.h failed!
6 files updated, 0 files merged, 0 files removed, 1 files unresolved
There are unresolved merges, you can redo the full merge using:
hg update -C 19
hg merge 18
I can't figure out how to resolve this. Google search results instruct to use:
hg resolve
but for some reason my Mercurial (v1.0.2) doesn't have a resolve command:
hg: unknown command 'resolve'
How can I resolve this conflict?
To highlight an answer in a comment for Hg 1.1+:
For Hg 1.1+ fix the file by hand and then do
hg resolve -m test.h
to mark the file as merged.
Valid for hg < v1.1 only
There is no need to call any hg commands. Unlike svn, Mercurial does not track conflicted files. If you call hg status, you'll see that the file is simply marked as modified.
Just fix the file by hand and commit.
Tracking conflicts was introduced in Mercurial 1.1, which is a newer version that you are using (you should really upgrade, Mercurial 1.1. was released in December 2008).
In that version you gained the resolve command which works similarly to svn resolve.
As I remember it, Mercurial would leave merge markers (the <<<< and >>>> lines) in your file when there is a conflict, unless you have configured a merge tool. This also applies to newer versions -- I have no merge tool configured and get the merge markers when conflicts occur. I can then manually fix the file and mark it resolved with hg resolve.