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.
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 use Tortoise 2.7.1 on a Windows 8.1 machine
I'm trying to push my project to the common repository (Windows Server 2003 R2) and it's aborting with the following message:
abort: empty or missing revlog for image/Thumbs.db
I must add that I recently disabled the creation of Thumbs.db and started to delete the existing ones.
After I got this error, I tried to add Thumbs.db to .hgignore and commit + push. As before, commit was good, but push still gave me the same message.
Any help would be highly appreciated.
Thanks,
Setnara
I had the same problem and solved it in this way:
remove the file ( image/Thumbs.db, in your case) from the disk
in Hg, "forget" for the file ( image/Thumbs.db )
in Hg, "commit"
added the file ( image/Thumbs.db ) again in the directory
in Hg, added the file
in Hg, "commit"
started to delete the existing ones
It looks like you also deleted (probably recursively) some files in the Mercurial repositories and it is (or they are) now corrupted.. :-(
If you can find the repository on the disk, you can check its state with the following command: "hg check" (I do not know if Tortoise has such a command in the menus) and this will tell you if you have a corruption or not.
If this is the case, I'd suggest to make a backup of your files, remove the corrupted repository, and to clone it again from the central common repository, then checkout the files and compare them with the saved ones (you might have worked on some files and not committed them).
Hope it'll help.
I have just had the same problem.
If you still have the files in the trash, there is a possibility that the files in question still exist. If this is the case, you can just restore the files and push.
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.
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 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.