We have a sub-repository in mercurial that was created using hg convert. For about three weeks we've had people modifying and checking in changes (using Tortoise under Windows) before we noticed that we have two versions of the originally converted files:
e.g.
Dir\Project/FileName.ext
Dir/Project/FileName.ext
I've tried hg rename, hg forget, hg remove, but when we always seem to end up with both files gone, or both files present. I've also looked at the case folding suggestions, but they don't appear to apply.
Any suggestions on fixing would be appreciated. If we lose the history on the \ version that would not be the end of the world.
Thanks
I've seen this happen with converted SVN repositories (using hgsubversion but I bet hg convert has the same issue). In the cases I've seen it there was an svn properties change for the path which apparently resulted in a "filename containing backslashes" (not path) being stored in svn.
In the first case I saw it was a directory path which caused me to immediately encounter the problem - a zero-length file was created with the directory path on Windows, and then later in the update Mercurial aborted because it was unable to create the directory of the same name.
I expect the sequence that created the double entries is something like:
Update to revision which contains filepath with backslashes
The new file shows as untracked because the Mercurial manifest currently contains a path with backslashes, but when looking at the working dir it normalises all file paths to forward slashes - so it doesn't appear in the manifest.
User adds the "new" file.
On subsequent updates, both paths are updated but one overwrites the other in the working directory. If you've been lucky the new version is the one that's ended up in the working dir.
You probably can't fix this on Windows but you should be able to remove the backslash versions on Linux (or other UNIX-like OS with case-sensitive filesystem) by single-quoting the filename e.g. hg rm 'Dir\Project\FileName.ext'. If you update to a revision with the problem on Linux you should see files actually named 'Dir\Project\FileName.ext' in the root of the working directory.
Just make sure that the backslash version is the one that should be removed - if not you may need to manually merge them together to get the result you want.
Related
I know it is strange but I was updating my testcases and thought of removing all the untracked files from the testcase so ran hg purge, but apart from deleting untracked file it deleted tracked files for 230+ testcases too.
Is there any way to revert back to original or can I get the files back? These files are on the server so I can get it by pulling it from server, but this is not helpful as I have to update it again.
If you have modified Working Directory ("modified" by any way) you can easy discard changes and return to the state of clean "."-changeset using
hg up -C -r .
And yes, follow-up to #torek, hg purge must not touch tracked files, because, according to it's wiki
extension purges all files and directories not being tracked by
Mercurial in the current repository
but I can see one possible case, why it's may happen. Next para in description shed some light on topic
With the --all option, it will also remove ignored files
(and some pure speculation below...)
If you had files in .hgignore and added these files into repository by hand (you can hg add ignored files), purge probably may delete these files.
You can (rather easy) verify my idea after returning to good state of repo
Install|add hg-isignored extension (Bitbucket, will disapper soon due to BB-refugee from HG) and check ignorance state of versioned, but deleted by extension files (at least some of) - you'll see result and used pattern from .hgignore
Try (again) hg purge --print in order to get list of purged files. If lists (deleted and ignored versoned files) will have intersections, then you'll get answer on question "Why?"
I can't see any other reasons for such behavior of extension
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 don't want this file to be removed from other developer's machines, but I don't want it tracked anymore either. It is basically a setting file, that shouldn't have been checked in in the first place.
I think I have to tell the other developers to back up this file. Then I can do a remove, and add it to the .hgignore. Then they have to put the file back into their working directory.
It seems like hg forget would only work for my machine, and then next time another developer does a pull it would wipe out their file.
Any tips?
They don't need to back it up. It's backed up in the repository. You might want to get them to commit their latest version before they pull from you so they don't lose their latest changes. When they lose their file they can just do hg log <file> and then hg revert <latest revision - 1> <file> to get it back.
It seems like hg forget would only work for my machine, and then next time another developer does a pull it would wipe out their file.
Yes, non-versioned file will be saved (some time) only in your WC
If you don't want kill file and just ignore, you can
use -X filename on commit by hand (or write in aliases section)
install (on all workplaces) Exclude Extension (semi-automated solution from p.1)
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.
I have a mercurial repository, and inside it a file that ends with '>>'. When doing a hg clone from this windows repository, I get the following error:
abort: The filename, directory name, or volume label syntax is incorrect: C:\Users\Path\To\Repos/More/Path/file>>
Is there a way to fix it? It seems to do with the '>>' being confused for a redirect, although I'm also unsure of why it switched from using \ to /.
The problem is that on Windows, a filename can't contain the > symbol. You should probably try and find the push to the repository that added the file in question and do a partial rollback to get rid of that file. Then, never name a file that way again :)
EDIT: You might try performing a pull from a Linux machine or VM if you have it, and then renaming the file without the weird characters, then commit and push back to the repository. I'm not sure if you tried that already.