Running Hg verify command on Mercurial repo returns below output:
hg verify
checking changesets
checking manifests
manifest#3270: changeset refers to unknown revision c33e42cadbba
crosschecking files in changesets and manifests
checking files
WebContent/WEB-INF/classes/labels.properties#3270: c7287124bd0a not in manifests
checked 5835 changesets with 100225 changes to 78258 files
2 integrity errors encountered!
(first damaged changeset appears to be 3270)
How can this issue be fixed ?
'''
Used hg strip 3270 to remove the changeset.
https://www.mercurial-scm.org/wiki/StripExtension
select changeset you want to remove > right click > Modify History > Strip … > press Strip button.
Now the hg verify does not complain about integrity issues.
This can be done via command line also
hg strip --keep --force --verbose --nobackup 3270
'''
Related
I've spent the last few hours doing an enormous merge in mercurial. After 131 files merged, my merge tool, meld, crashed showing a python traceback. Trying to quit meld, I've inadvertently also quit out of the mercurial merge.
I'd quite like to just continue the merge from where I left off, e.g. something like hg merge --continue but I can't find an option to do that.
If I re-run hg merge it warns about uncommitted outstanding changes. hg resolve doesn't list anything to resolve, but I am most likely only about 60% of the way through the merge.
Is there a command to continue the merge from where I was?
In TortoiseHg:
Select all files which are still marked as conflicted
Right-click on the files, and select "Restart merge"
Resolve the files
Commit the change
From command line:
hg resolve --all (continue the merge with all files that are still marked as conflicted)
Resolve the files
hg commit (commit the change)
hg resolve does nothing. To list files which have outstanding conflicts, use hg resolve --list. (The prefix U means that the file is unresolved, R is resolved.)
I'm trying to merge a trunk to a branch, but ending up with a lot of tree conflicts, leaving no files merged. To resolve the conflicts, I'm just opening the file and copying contents by hand which just defeats the purpose of a merge operation.
What is the right way to merge a trunk to a branch (in subclipse) ?
How was that branch created? Was it created by using svn cp, or were those files manually copied into that branch?
Let's look at the following:
$ svn mkdir trunk
$ vi trunk/foo trunk/bar
$ svn add trunk/foo trunk/bar
$ svn commit -m"Added foo and bar to trunk"
You now have two files on trunk.
$ svn mkdir --parents branches/1.0
$ cp trunk/* branches/1.0/
$ svn add branches/1.0/*
$ svn commit -m"Duplicated files onto branch"
What I have done is create two entirely different foo and bar on the 1.0 branch. These two files, according to Subversion have absolutely nothing to do with each other. If you make a change on the 1.0 branch, and attempt to merge these changes back to trunk, you will get a lot of conflicts with messages like "local add, incoming add".
What the above user should have done is this:
$ svn cp --parents trunk branches/1.0
$ svn commit -m"Branched trunk and not merely duplicate files"
Now, there's a relationship that Subversion understands between the files on trunk and on the 1.0 branch. Merging will go smoothly.
Here's another way to break a merge:
$ svn delete trunk/foo
$ svn commit -"deleted foo"
$ svn cat -rPREV trunk/foo#PREV > foo
$ svn add foo
$ svn commit -m"Added foo back in. Shouldn't have deleted it.
According to Subversion, there are now two completely different files named foo in the trunk. There's the file you deleted, and there's the file you added. These two files have nothing to do with each other. Imagine if I branched (the correct way using svn cp) to the 1.0 branch, then did my delete and copy of foo. The merge of the 1.0 branch back to trunk will have a conflict because the foo on the branch has no relationship with the foo on trunk.
To restore a file, you need to copy the revision that was deleted (or use svn merge -c).
$ svn cp -rPREV http://svn.repo/svn/trunk/foo#PREV .
$ svn commit -m"Actually old foo now has been restored! Merges will work"
If you branched incorrectly, or deleted and re-added files back to trunk, you will get conflicts. You can try using the --ignore-ancestory parameter, and you can use --dry-run to test your merge before running the actual merge.
If you manually merge, you can use svn merge --record-only to just record the fact you did a merge without actually doing one. This might help the next time you do a merge since you're at least recoding what you've manually done.
I've created a repository in the project's directory. I've added all the files and made some commits. Then I added new files to project and to repository. After that I returned to earlier version and now I can't update to last version. After hg update tip I'm getting this message:
abort: untracked file in working directory differs from file in requested
revision: '.DS_Store'
I'm new to mercurial. How can I fix this?
It means that Mercurial is unsure about what to do. You have a file with content something in the working copy. The file is not version controlled, so Mercurial will normally leave it alone when you update. However, the revision you're updating to also has a file with the same name, and the content differs from the something you already have in the file.
You can get this problem if you do
$ hg init
$ echo "a file" > a
$ hg add a
$ hg commit -m "added a"
$ echo "b file" > b
$ hg add b
$ hg commit -m "added b"
You now have two revisions, the latest has files a and b. If you update back to the first revision and create a different file b, then you get trouble:
$ hg update 0
$ echo "other b file" > b
$ hg update
abort: untracked file in working directory differs from file in requested
revision: 'b'
The normal solution is to commit before updating. You should generally not update with a dirty working copy ("dirty" means that hg status isn't empty). Mercurial does support such updates, but you should only use them if you know what you're doing.
So to continue the example above we can either commit the new b and then merge:
$ hg add b
$ hg commit -m "added new b"
$ hg merge
This gives a conflict in b since the two versions contain b file and other b file, respectively. Resolve the conflict and commit:
$ hg commit -m "merged two bs"
An alternative is to delete the file from the working copy. That is what I'll do in your case: .DS_Store files should not be tracked in the first place. They store some folder information on Mac OS X and this is not part of your source code. So you do
$ rm .DS_Store
$ hg update
The update resurrected the .DS_Store file. You now want to tell Mercurial that it should stop tracking the file:
$ hg forget .DS_Store
and you also want to tell Mercurial to ignore such files from now on:
$ echo "syntax: glob" >> .hgignore
$ echo ".DS_Store" >> .hgignore
$ hg commit -m "removed .DS_Store file, ignored from now on"
I deleted a few files on my local filesystem which I am not using anymore and are just junk. Unfortunately they are tracked by version control (Mercurial). Now I see a large red '!' saying it is out of sync because of the missing files. How can I tell Mercurial that it's OK to remove those files without reverting all of them and selecting delete on them individually?
Either tell it to forget those files:
hg forget XYZ
hg commit ...
Or use the addremove command, or addremove option for commit:
hg addremove
Hg commit ...
Or
hg commit --addremove ...
Use the help to find more info on these commands:
hg help forget
hg help commit
Basically, what I want to try is pulling hg revisions from a branch of an experimental repo into a clone of mainline. But I want to discard the branch name so I can push directly into the server-side mainline repo. It's probably best to give a simple example:
hg init hg_mainline
pushd hg_mainline
touch foo
hg add foo
hg commit -m 'foo'
popd
hg clone hg_mainline hg_experimental
pushd hg_experimental
hg branch bar_branch
touch bar
hg add bar
hg commit -m 'bar'
popd
pushd hg_mainline
hg pull ../hg_experimental
hg log
As you can see, the mainline now includes a rev with "branch: bar_branch." I don't want this revision to have a branch (i.e. it should be default).
It is okay if this requires rewriting history with rebase, transplant, or another tool. I have tried both of these, but couldn't get it working. The most recent revision hash may end up different between the two repos.
So I want the topmost revision of hg_mainline to look like:
changeset: 1:xxxxxxxxxxxx
tag: tip
user: ...
date: ...
summary: ...
with no named branch.
Again, it's okay if the hash isn't preserved from hg_experimental.
I am currently using hg 1.6.2+55-18e1e7520b67 from an Ubuntu PPA.
EDIT:
I also used 1.3.1. I tested the below on both, and the results here are the same.
I got it working with transplant, but only with the grep -v kludge.
hg transplant -s ../hg_experimental 1 --filter "grep -v '^branch:'"
With:
hg transplant -s ../hg_experimental 1
hg export didn't work either, with or without an appropriate grep.
The changeset patch looks like:
# HG changeset patch
# User Matthew Flaschen <EMAIL>
# Date 1282942390 14400
# Branch bar_branch
# Node ID b8e36efea72642f0a0194301489d5c48f619a921
# Parent 85d9b9773d4ec09676dfcc4af89c142c46279444
bar
I exported from experimental with:
hg export 1 -o '/tmp/%b_%H_%R'
and tried to import to mainline with:
hg import /tmp/hg_experimental_b8e36efea72642f0a0194301489d5c48f619a921_1
It fails with:
abort: no diffs found
EDIT 2:
As noted, the export method failed only because the files were empty. It works correctly with --git or with non-empty files.
The simplest solution is use hg export from the experimental repo, and hg import into the main repo. By default, hg import won't apply any branch information in the patch. The downside is that they'll show up as different changesets in the two repos -- hg incoming in the experimental repo will show the changes you just exported/imported -- so after you do this, you may be better off deleting and recreating the experimental repo if you plan on doing any more experimentation.
EDIT: From the hg_mainline repository:
hg export -r 1 -R ../hg_experimental | hg import -
EDIT2: From hg help diffs:
Mercurial's default format for showing changes between two versions of a file
is compatible with the unified format of GNU diff, which can be used by GNU
patch and many other standard tools.
While this standard format is often enough, it does not encode the following information: (snip)
creation or deletion of empty files
The test files are empty in your test script, so you need to either enter something into them, or use the --git option to hg export.
The transplant extension already scraps the branch name:
cd hg_mainline
hg transplant -s ../hg_experimental 1
should do it for you. If you're finding that's not the case you can always use the --filter modify the changesets (perhaps just using grep -v) on the way in.
I will note that if you can come up with a work flow that avoids transplant and retains hashes you're better off. Avoiding named branches entirely makes this easier -- anonymous branches perhaps with bookmarks work as well or better.