There is a support for Mercurial in IntelliJ, but it does not handle renames correctly. I.e. renaming a file or moving a file to another package does not rename/move file in Mercurial.
This is absolutely annoying. Is there a better way to work with Mercurial in IntelliJ?
Thanks.
You have to register your Mercurial root in Settings | Version Control.
There you have to point to exact root directory, you can't use the "<Project>" mapping if the hg root is above it.
It may be caused by incorrect VCS roots configuration in IDEA, check the related issue with the solution in the comments.
Specifying the mercurial root directory explicitly instead of using the <Project> placeholder should help.
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.
For example I have a hg versioned project in this path: C:\src\sample_project
Now, lets this project have subfolders, and lets say I'm editing a file inside this project C:\src\sample_project\docs\index.rst.
Having the path of this file C:\src\sample_project\docs\index.rst what is the easiest and most effective way to check if the file is versioned by hg, by either using Windows shell commands, hg.exe or tortoise (thg.exe)?
I'll post my doubt as answer.
Command to check if file is versioned: hg status <path> and then if the first character in stdout of this command is ? or a (from abort: no repository found in...) I should assume that file is not versioned.
What you stated is a way, but there is a cleaner one imo. You can use:
hg status -u which lists all unknown (read: not tracked) files in your repository.
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.
TortoiseHg allows you to email a patch file of your changes to someone, but does it support applying patches?
If so, how do you apply a patch using TortoiseHg?
From Repository Explorer, Repository > Import...
It looks like there is no built-in support in TortoiseHg for this. Try this from a command prompt:
hg import my-patch-file.patch
That should apply the patch to your Mercurial repo and working copy.
First Stab Answer
You should be able to right-click on the patch file and choose "Apply patch..." - that's how it works for other TortoiseX clients. Make sure that you save the patch file to the same directory path it was generated from.
Downloading TortoiseHg 0.8.1 to test...
What may be also noteworthy is, that "Repository Explorer, Synchronize > Import..." (which internally does a "hg import") will automatically do a "commit" - this may not be always wanted behaviour.
Other possibility is to use unix "patch" command (on Windows perhaps use cygwin version) or use "hg import" directly with "--no-commit" option. Both will just make changes in working directory and you may review the changes and commit them later manually.
In 1.0, from Workbench:
Repository > Import...
I try to clone a local mercurial repository on windows.
I get this error:
C:\temp\toolkit1.1>hg clone \src\toolkit
destination directory: toolkit
updating working directory
abort: case-folding collision between sdk/Api.h and sdk/api.h
It looks like I changed capitalization of API.H at some point, but I don't know how to resolve this. Any tips?
I am using the version: 1.2.1
This is a problem that sometimes occurs when you work with a Mercurial repository on a case-insensitive file system (Windows). See the Fixing Case Collisions on the Mercurial wiki.
Probably the easiest is if you have access to a Unix computer check out the project there and remove the offending file, merging changes first (if any), then commit and push.
I fixed this by renaming the file in windows to Api.h.old. Committing that. Then renaming to Api.h with corrected capitalization. Commiting again.
Then clone worked.