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.
Related
In my repository somebody committed files that should be unknown (or ignored, according the .hgignore file).
How can I tell to Mercurial to no longer track those files but leave the files as unknown (or ignored) on remote working copies? (With remote working copies I mean working copies of the other users of the repository.)
More details: Specifically those files are .classpath and .project generated by Eclipse IDE when the project was imported as Maven/Gradle project. They have been added to the repository and committed. I want to do not track changes of that files but I don't want to ask everybody to re-import the project into Eclipse again. Renaming .classpath and .project to .classpath.template and .project.template does not resolve my issue.
That is tricky, as the file will be stored as deleted in the changelog when you tell hg to forget it - and on update it will be deleted in the working dirs of everyone who pulls and updates to a rev later than the one where those files have been removed from tracking.
If you can get by with everyone using hg revert -rTRACKED FILENAME where TRACKED is the changeset where the files are (still) tracked, it is not really nice but probably the easiest solution.
You might want to add all files you do not want to be ever tracked to add to your .hgignore so that these won't be added by hg addremove accidentially.
I need to control the version of a few files accessible via an SMB share. These files will be modified by several people. The files themselves are directly used by a web server.
Since these are production files I wanted to force the users to pull a local copy, edit them, commit and push them back. Unfortunately there is no Mercurial server on that machine.
What would be the appropriate way to configure Mercurial on my side so that:
the versioning (.hg directory) is kept on the share
and that the files on the share are at the latest version?
I do not have access to this server (other than via the share). If I could have a mercurial server on that machine I would have used a hook to update the files in the production directory (I am saying this just to highlight what I want to achieve - this approach is not possible as I do not control that server)
Thanks!
UPDATE: I ended up using an intermediate server (which I have control over). A hook on changegroup triggers a script which i) hg update to have fresh local files ii) copies them to the SMB share
EDIT 1 Following discussions in comments with alex I have looked at the verbose version of the command line output. The \\srv\hg\test1 repo has a [hooks] section with changegroup = hg update. The output from a hg push -v gives some insights:
pushing to \\srv\hg\test1
query 1; heads
(...)
updating the branch cache
running hook changegroup: hg update
'\\srv\hg\test1'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported. Defaulting to Windows directory.
abort: no repository found in 'C:\Windows' (.hg not found)!
warning: changegroup hook exited with status 255
checking for updated bookmarks
listing keys for "bookmarks"
If I understand correctly the output above:
a cmd.exe was triggered on the client, even though the [hook] was on the receiving server
it tried to update the remote repo
... but failed because UNC are not supported
So alex's answer was correct - it just does not work (yet?) on MS Windows. (Alex please correct me in the comments if I am wrong)
If I understood correctly, you are looking for two things:
A repository hook that will automatically update the production repo to the latest version whenever someone pushes to it. This is simple: You're looking for the answer to this question.
If you can rely on your co-workers to always go through the pull-commit-push process, you're done. If that's not the case, you need a way to prevent people from modifying the production files in place and never committing them.
Unfortunately, I don't think you can selectively withhold write permissions to the checked-out files (but not to the repo) on an SMB share. But you could discourage direct modification by making the location of the files less obvious. Perhaps you could direct people to a second repository, configured so that everything pushed to it is immediately pushed on to the production repository. This repo need not have a checked-out version of the files at all (create it with hg clone -U, or do an hg update -r 0 afterwards), eliminating the temptation to bypass mercurial.
What prevents you from mount your Samba share and run hg init there? You don't need mercurial server (hg serve or more sophisticated things) to perform push/pull operations.
After creating a symlink to a file I checked the file into my repo and it worked fine up to the point when I shared the repo with my teammate who is using Windows (his code goes into branch 'devui', mine is on the default branch).
If I switch from his latest changes (being on branch 'devui') to my default branch using hg upd default I get this message:
abort: could not symlink to '...<complete contents of symlinked file here>...':
File name too long: <symlink-filename>
This occurs after about half of the checkout so only a part of the files will be updated and the rest of the files (after the abort) is missing.
I also tried a fresh clone and hg upd -C default leading to the same result. In the moment my 'default' branch is in an unusable state and I cannot get back to my branch. I can get back to the revision before the 'devui'-branch was created though.
So my question is: Is it possible to skip the bad symlink, ignoring the abort and continue with the rest of the files? (I could recover that file easily).
I'm using mercurial 2.3 on MacOSX (via brew).
Thanks for your help.
This thread from 2010 (much older version of mercurial) suggests cloning the repo on a windows box, which may be unaffected by the problem, and reverting the symlink there.
I created a repository on a remote machine using:
hg init
hg add
hg commit
The repository was created.
I cloned the repository on a local machine with no errors reported; The files seem to be there
Now I'm trying to make a clone of the clone (as a working copy) using:
hg clone "path to original clone"
It returns:
destination directory: "name of repository"
abort: No such file or directory: "path to original clone"/.hg/store/lock
What am I doing wrong?
Thanks
What filesystem is used on the partition where the main repository is ?
Actually, when Mercurial is doing some operations, it needs to lock the repository. For doing this it creates a symbolic link to an nonexistent file, when the filesystem supports it, in the .hg repository, telling every other processes that the repository can't be modified at this time. When symbolic links aren't supported by the filesystem, a normal file is created.
However, there's some problems with some FUSE filesystems, typically SSHFS with the follow_symlinks option activated. FUSE reports that he knows about symbolic links, but since SSHFS follows the symbolic link and the file doesn't exist, the "state" of the link is marked as unknown thus Mercurial thinks the repository isn't correctly locked and abort the operation.
I see you're using Cygwin, so maybe it's the same kind of problem with tools designed for UNIX on a windows filesystem. It's a strange, coworkers of mine are using Mercurial via Cygwin just fine.
I don't know if it's the case for you, but I lost nearly half a day on this problem. Maybe this answers can help some people in the future.
Please paste in the actual command that's failing and the output including the actual path to the clone that you're cloning. When you do the clone use --debug and --traceback too.
As a workaround you can can always try hg init newclone followed by hg pull -R newclone pathtooriginalclone, which is effectively equivalent except it doesn't use local hardlinks when possible.
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.