We merge Maven pom.xml files from one repository to another.
The pom.xml files list a version in this form:
<version>5.0.17-SNAPSHOT</version>
Where we have a conflict on this line we always want to use the local file's version of the conflict. Is there a way to automatically take the local file version of the change?
For any other conflicts, we would like to continue to use the standard manual merge process.
Sure. Check out the Merge Tool Configuration wiki page and you'll see that something like this should do it:
[merge-patterns]
pom.xml = internal:local
Related
We just switched to Mercurial from SVN. I have some local properties file like jdbc.properties that refers to my local database and is never checked into repository. When I try to pull files Mercurial complains there are uncommited files. How to best deal with this situation
Regards
If you never want to commit jdbc.properties to your repository, you should ignore it.
Check out the link for more information - in short, you'll have to create a text file called .hgignore in your working directory, and input the files names of the files you want to ignore.
Then, you'll never see the files again when you try to commit, and Mercurial won't complain about uncommitted files anymore.
If the application won't work without the config file and you want some version of it in the repository, you might not want to ignore it.
Because if you do, you can't just clone the repository and start your app - it will complain about the missing config file.
Plus, you probably want to have your configuration files under source control as well - just without "secret" data like usernames and passwords.
Maybe this approach is something for you then.
The example shown there is in MS Visual Studio (because that's what I'm using), but you can something similar in any other stack.
I version controlled a project settings folder a couple months back on my default branch, and then over time created many branches off default. Now I've decided that I'd rather not have the project settings folder version controlled as it creates a lot of problems when switching between branches.
So I've hg forget'd this project settings folder which lets me keep the files on my local machine but removes them mercurial. However, when switching from one of the old branches which still have this folder versioned back to the default branch it actually removes the files from the local machine, which is bad.
How do I prevent that?
The folder is also in .hgignore on default now.
It's impossible to do.
But the common practice is to keep config.ini.dist in your repository and build environment-specific config by some build-system right after you check source code out.
The standard way to deal with this is to version control a template config file and ignore the real config file. The real config file can then include the template file, or maybe the template file is copied over once in a while.
The underlying reason for your problems is that running:
$ hg forget config.ini
is exactly the same as running:
$ hg remove config.ini
$ hg cat config.ini > config.ini
The forget command leaves the file behind in your working directory, but what you commit is still a file removal. This means that afterwards, Mercurial cannot distinguish between "file was forgotten" and "file was removed" — only the removal is committed, so the two commands look exactly the same.
First off, I would prefer not to check in the generated files at all but my manager insists. So, given those constraints I would like to create a mercurial "merge-patterns" that will always take "their files" in all directories named "generated" in my working repo. I have read the hgrc documentation and a related post and here is what I think it should look like:
[merge-patterns]
generated/** = internal:other #keep their files
And this is placed in my root .hg/hgrc file. When I run the hg update with the merge conflicts this is what I get:
> hg update
couldn't find merge tool internal:other #keep their files specified for generated/**
merging generated/file.sv
So I modified the "merge-patterns" to look like this:
[merge-patterns]
**/generated/** = internal:other #keep their files
And here is what I get:
> hg update
merging generated/file.sv
So, I no longer get the "couldn't find merge tool internal:other" warning but it is still trying to merge the generated files.
Any ideas on how to get this to work?
Additional notes:
We are using Mercurial version 1.7.5 as we were having problems with newer versions and subrepos.
I am working with subrepos so here is what the structure of my main repo looks like:
I believe the problem is simply the comment! Mercurial is searching for a tool named
internal:other #keep their files
and that's unlikely to exist :-) Try moving the comment to a line above:
[merge-patterns]
# keep their files
generated/** = internal:other
I haven't tested this out, but I believe you still need the first pattern you used — the warning went away with your second try because the pattern no longer matched inside the subrepo. Even when you start the merge from the top-level, the subrepos are merged as if hg merge was executed inside the subrepo.
I am new to Mercurial HG. My friends created a repo and I am going to use it.
I installed TortoiseHG and trying to get the latest code. I found that when using Clone operation, it will pull all code to my local, including the histories (Am I right?). This is not needed for me. I just wanna get the latest code. Is there an operation for this?
In short, no.
In a bit longer: Mercurial doesn't yet support “shallow” clones where you only get part of the history. So each time you clone you pull in the entire repository with all changesets.
Additionally, unlike Subversion, there is no way to make a “narrow” clone where you only checkout a portion of a repository. For example, if a repository has directories foo/ and bar/, there is no way to get only the bar/ directory. In other words, Mercurial always operates on project-wide snapshots.
The easiest way to achieve what you want:
hg archive [destination folder]
Once you cloned a repository, to get the code of the "tip" (the last version of the current branch - the default one if not precised) you just need to update.
You have an update action in TortoiseHG. Once done, you can look at the files in the folder.
If you wanted another state of the repository (an old version, or an old tagged state) then it's still the update command, with other parametters (see the docs or the TortoiseHG interface).
If you only want the latest code, and you don't intend to do anything related to the repository with it, like commit, or diff to older versions, or whatever, then you it depends on where you got the code from and how.
If he is using one of the hosting services, like bitbucket, there's usually a download link which gives you just the source code.
For instance, if you go here, there's a "Get source" link up and to the right which gives you a few choices in the file format (zip or whatnot.)
If you got the files somewhere else, you need to explore the interface you got them from. Try just pasting the link you cloned from into your browser and see what you get.
Sure. Clone the repository, then delete the .hg subdirectory.
I might be a bit late but actually it is possible to forget some history with Mercurial. You just need to enable convert extension from Your mercurial.ini file or .hgrc file.
[extensions]
hgext.convert=
Now you are able to use convert extension to "clone" only changesets starting from the revision specified.
hg convert --config convert.hg.startrev=[wheretostart] path_to_full_history_repo path_to_new_repo
Just note that this is not the same operation with hg clone. That's why the source repository must be a local repository. For example if we have a repository in folder MyProject and we want to forget all the changes done before revision 100. We can use the following command:
hg convert --config convert.hg.startrev=[100] MyProject MyShrinkedProject
If You are going to use this shrunken repository on a "central server" remember to take care of that everybody clones it before they continue working. Repositories are not compatible with each other anymore.
Mercurial now supports shallow clone using remotefilelog extension. Extension is bundled with mercurial probably since version 4.9. Older versions need to download the extension e.g. from github.
You have to enable it on the server e.g:
[extensions]
remotefilelog =
[remotefilelog]
server = True
serverexpiration = 14
and on client
[extensions]
remotefilelog =
[remotefilelog]
cachepath = /some/path
cachelimit = 5 GB
Than you can do shallow clone with much smaller footprint a and faster clone speed:
hg clone --shallow ssh://user#server/repo
I create the hg repository with my source tree. I want to keep the first version of some files such as Makefile in the repository and then hg don't see it modified even through I modified it.
Original problem is that ./configure usually modifies the Makefile but I don't want the build files to committed in the repository. So I want to keep only first version of configure and Makefile in the repository so that everybody who clone my repository can run ./configure by themself and not bother the repository
I tried hg remove or hg forget but those are stop tracking and also delete the files in the next revision of reporitory.
.hgignore doesn't do the things too.
I think of hg revert everytimes I run ./configure or make but it's not efficient way.
Are there any better ways?
Its usually good form to not track the configure script at all. There are some reasons for this:
Its huge. I've seen code bases where the configure script and helper macro libraries were more than ten times the size of the actual code being compiled.
When other developers make changes to configure.in(.ac), they are going to need to commit a new configure script. If three people do that, there's a good chance that Mercurial will require at least one of them to manually resolve a merge conflict in configure itself. Keep in mind, configure is machine generated, attempting to read it (much less resolve merge conflicts) may make your eyes bleed.
Generally, you'll offer a program in source form via two methods:
Download of a release archive (e.g. foo-1.2.3-rc2.zip), this can contain the configure script.
Downloading the repository directly using Mercurial. If they want to work with that, they'll need to have autoconf installed.
In the root of my repositories, I usually include a file called autogen.sh that runs all of the steps needed (aclocal, autoconf, ...), which also handles alerting the user if they need something installed. I.e. Could not find tool aclocal, please install the autoconf package.
Its really best to just go with the autogen.sh method. This means only tracking configure.in (or configure.ac) and the associated Makefiles (from Makefile.in). Let each build configure their own, and provide a distclean target to remove all files configure generates. Finally, provide a maintainer-clean target to remove anything that the configuration suite itself generated, e.g. configure.
That should help make nightly builds easy.
You could try and setup a pre-commit hook which would always restore the original Makefile content if found in the changeset.
The SO question illustrates reading the content of the changeset to be committed.
Make sure to use the pre-commit hook, and not precommit.