I'm trying to use subrepos but I keep having strange issues when pushing/pulling changes to the server. I feel like this is a bug, but I'm not sure.
I've determined that after committing my changes locally, the best way to get my changes to the server is with hg pull -u on the server drive. What I do is cd to the root of my repo on c:, and cd to the root of the server repo on z:, and then use the command hg pull -u c: from z:.
(The reason I've found is that you can't use -u with push, and if you don't update, then the current revision ends up being behind the most recent (say the one you pushed is 100, but it will still be on 99), and then later when you commit more changes you get weird merge problems because you worked off of 99 which now has to be merged back into 100+.)
Ok but that's not the bug. The bug is that when I do hg pull -u c:, it seems to be working but then errors out like this:
Z:\>hg pull -u c:
pulling from c:
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
new changesets e8003f274ea0
abort: repository c:/SomeProject not found!
So, this seems like a bug to me, because the path c:/SomeProject is just wrong, the path should be c:SomeProject. Once this happens I have to manually update the errored subrepo.
Maybe it has something to do with how I've setup the subrepos? I make my .hgsub file by enumerating the folders in my project directory and writing FolderName = FolderName to a text file for each one. So it looks like:
SomeProject = SomeProject
SomeOtherProject = SomeOtherProject
etc.
Maybe it should be formatted differently?
I recently upgraded from version 2.something to version 4.4.2 and was surprised to find that this still happened.
I ended up reporting it as a bug and it was fixed in the next version.
Related
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.
I am using Mercurial(TortoiseHG) as version-control system for our source code. I am unable to remove a file from the repository, from the command-line. I see several people on web, giving solutions like:
1. hg rm
2. hg remove
These commands do the operation of removal from the directory. However, when I pull the repository at a seperate place, the above file(supposed to be deleted) still shows up. I tried pusing the repo after performing the above commands as well, with:
hg push
But the files are not really removed from the repository. Do I need to configure anything extra for this removal operation?
I generally have the habit of committing at the leaf-level, and thus wasn't committing the root repo folder all the while. Sorry for the miscommunication.
A coworker got this error after pulling from the repo. I searched for an answer online on how to solve it but couldn't find anything. I figured out a way to solve it so posting it below for anyone else with the same issue.
I asked everyone else working on the repository to check their user cache folder (C:\Users\username\AppData\Local\largefiles on Windows) to see if they had a file with that id ("XXX" from the title).
One of them did, the original author of the file.
I asked him to send it to me, I remote connected to the server that has the central repo. I then copied the file both to the server's cache and into .hg\largefiles
The user could then pull again and push and everything worked.
LF extension seems not compatible with keyword extension.
With these both extensions, at the commit, the LF is NOT put in the configured folder on the PC and then raises this error at push.
If you disable the keyword extension, it's perfectly working.
Unfortunately, I've not found any additional explanations.
If someone could provide a stable solution, it will be great.
It looks like hg pull is happily sparse, but hg push is not; thus you need all largefiles for every revision not already present on the new remote, so that it can populate for history and allow clients to successfully pull at any revision. Which makes sense.
When migrating to a new hg server, I hit this issue. The "within Mercurial" solution was to download all largefiles, for all commits, to my local repo, and then push to the new server repo:
$ hg lfpull --rev 1-tip
$ hg push newbox
(Disclaimer: my Mercurial-fu is weak, I only use it for this one largefile repo)
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.