When we merge changes from our Mercurial feature release repositories into our trunk repository, we always have conflicts with our Maven POM files(pom.xml) and our Mercurial .hgtags file.
We always want to keep the trunk version - we never want the feature release repo version. Is there any way to tell Mercurial to always use the trunk version of these files when there are merge conflicts?
Update: Per the selected answer, this works:
[merge-patterns]
.hgtags = internal:local
pom.xml = internal:local
**\pom.xml = internal:local
For your pom.xml file set the merge tool to internal:local (or internal:remote if you're not updated to what you're calling trunk). Explained here.
Try this:
[merge-patterns]
pom.xml = internal:local
Related
I typically backup my git repositories using git clone --mirror <repository> as it creates a functionally identical repository.
What is the equivalent functionality in mercurial?
Just hg clone <repository>. Each repository works the same as any other. The repo you clone will automatically be the default repo to pull from in the future. There is no way to access remotely the repository-, account- or server-local configurations as found in the .hgrc files, which includes the URLs of other repositories or hooks.
I installed the shelve extension for hg by adding 'shelve=' to [extensions]. I can verify this by running 'hg help extensions' which has the following in the output:
enabled extensions:
extdiff command to allow external programs to compare revisions
fetch pull, update and merge in one command
shelve Manage shelves of pickled objects.
I then type 'hg shelve' in a repo of mine, and I get:
hg: unknown command 'shelve'
Mercurial Distributed SCM
...
I would expect the shelve extension to run...
Mercurial verison is 2.0.2
The Shelve extension is distributed with Mercurial 2.8 and later, as mentioned here.
There is an older third party shelve extension that you can use with Mercurial 2.0.2, but it is not distributed with Mercurial and must be installed separately.
Summarised Question:
Are github-hosted sub repositories within a mercurial/kiln repository possible, and if so are they automatically updated/cloned when the parent mercurial repository is operated on by a hg clone or hg commit command?
Detailed Question:
Following on from my question that was answered so excellently here , some of my third party code is in folders I downloaded a while ago from opensource efforts on github. Since at that stage I was not using version control, those folders where just standard folders that now been incorporated as sub repositories in mercurial.
This is obviously not ideal, as for one thing, new versions of the libraries may have bug fixes, or new features I wish to use in the future. I also may need to locally customise some of the libraries.
I can see from reading this link that it possible to have mercurial "know" about those git server urls (and revisions), so I can then have mercurial clone the github hosted libraries direct from their parent repos.
Am I right in saying that when I clone the parent (mercurial) repos, those files will be pulled from github, without having to separately manage this using git?
What is also not clear is, if I were to do this, and it transpired that code might need to be customized from within that github-cloned repository, would I need to use git to manage revisions of the local files, or would mercurial do that by proxy? eg id I were to hg commit -S would mercurial invoke git on my behalf to handle that?
Am I right in saying that when I clone the parent (mercurial) repos, those files will be pulled from github, without having to separately manage this using git?
Yes, clone of a Mercurial repository that contain subrepositories will trigger a clone of the subrepos too. It really happens on update. Mercurial notices the .hgsub file and issues the needed hg clone and git clone commands for you. It uses the information in .hgsubstate to know exactly what revision to checkout.
The subrepositories can be hosted anywhere. For a Git subrepository declared like
foo = [git]https://github.com/user/repo.git
Mercurial will simply issue the corresponding clone command:
git clone https://github.com/user/repo.git foo
It's then your reponsibility to later go into the foo repo and use Git to fetch new commits as necessary. After you fetch/pull new commits, you can make a top-level commit to record the new state of the subrepo in the .hgsubstate file. Use hg summary to see if a subrepo is dirty in this sense.
[...] would I need to use git to manage revisions of the local files, or would mercurial do that by proxy? eg id I were to hg commit -S would mercurial invoke git on my behalf to handle that?
When you edit files and make a top-level hg commit, Mercurial will make sure to commit the subrepo first (if you use hg commit -S or if ui.commitsubrepos=True). If you make a top-level push, then Mercurial will always push the subrepos first so that you always have a consistent set of changes on your server.
To ensure we use the trunk version of some files when merging we use internal:local:
[merge-patterns]
.hgtags = internal:local
pom.xml = internal:local
It seems in some cases, the merge does NOT use the local file, it does actually merge the changes from the remote repository. Why would this be happening?
The Mercurial "premerge" internal merge is actually successfully resolving merge conflicts for certain files before even launching a merge tool.
If the chosen merge tools premerge is
True then an internal merge is
attempted, and if it seems successful
then the result it will silently be
used without running the actual merge
tool
Check out this article on merge tool configuration for more info. Turning off premerge for a particular type of file (or directory) can be done using these modifications to your Mercurial.ini file:
[merge-tools]
<name>.premerge = False
<name>.args = --auto $base $other $other -o $output
<name>.executable = kdiff3
[merge-patterns]
**.xml = <name>
.hgtags = <name>
Note that kdiff3 should come with TortoiseHg by default, and <name> can be anything you want; call it, 'localFilesOnly' or something like that.
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.