I have a problem with my mercurial main repo. My colleague created a bunch of subrepositories for dependancies, and since then, I can't update my local repo. I decided to try a checkout in an empty directory but I have the same error :
hg clone https://user#bitbucket.org/company/repo
http authorization required
realm: Bitbucket.org HTTP
user: user
password:
destination directory: repo
requesting all changes
adding changesets
adding manifests
adding file changes
added 1116 changesets with 12636 changes to 2410 files
updating to branch default
cloning subrepo deps/gtest from https://bitbucket.org/company/gtest.git
abort: Le fichier spÚcifiÚ est introuvable
"Le fichier spÚcifiÚ est introuvable" means "The specified file cannot be found", but the message is in french so it must come from Windows, because if it came from hg it would be in english
Here is what I have when using the --debug option
updating: .hgignore 1/1274 files (0.08%)
getting .hgignore
updating: .hgsub 2/1274 files (0.16%)
getting .hgsub
updating: .hgsubstate 3/1274 files (0.24%)
getting .hgsubstate
subrepo merge 000000000000+ 4d1310a16bfd 000000000000+
subrepo deps/gtest: remote added, get https://bitbucket.org/springbeats/gtest.git:a6772271f71672e889776bfe49ec4efd9da036df:git
cloning subrepo deps/gtest from https://bitbucket.org/company/gtest.git
deps/gtest: git clone https://bitbucket.org/company/gtest.git C:\Users\Bob\Documents\Newdir\repo\deps/gtest
abort: Le fichier spÚcifiÚ est introuvable
Does anyone has an idea of what going on ?
Main problem here is Bitbucket, which (nobody in Mercurial-hosting world really) can't support and handle nested repositories (and subrepos for the same reason), not the Git-nature of subrepos. For BB subrepos can be only siblings of superrepo
In order to avoid such type of problems, you have to use additional [subpaths] hack, described on Subrepository Wiki-page for Mercurial 2.* and in this message originally
Indeed, the problem was that hg couldn't find git.
I just realized that git wasn't on my PATH, so I fixed that and everything worked.
The solution was easy but the error message wasn't clear.
Related
I did a clone of a mercurial repo with "hg clone url" then when I try to switch to another branch using "hg checkout branch_name" I'm getting the error "abort: untracked files in working directory differ from files in requested revision"
So what's going on here? There are no local changes. I just did a fresh clone and immediately tried to switch branches.
I've some code on my laptop I would like to upload through Mercurial on my BitBucket repository.
I'm using a Linux CentOS 6 machine.
The problem is that if I type $hg push, I get the following error message:
pushing to default-push
abort: repository default-push not found!
What should I do?
Thanks
Mercurial doesn't know where you want to push to. Mercurial first looks for the destination in the push command (which could be either a repo on the filesystem, or a remote hg server):
hg push remoterepo
If it doesn't find a destination in the command, it will fall back on the defaults.
Normally, assuming this repository was cloned, the hgrc file (in .hg/) will indicate the default repository to be used.
However this assumes that the repository was created by cloning an existing repo.
If not, you can edit .hg\hgrc and add the default destination eg:
[paths]
default-push=http://yourserver/
I do have a copy of code which does not have the .hg and its not connected with repository. (v1.1). The code was actully pulled from repo only, but during the development somehow the .hg files got deleted and its disconnected from repo.
hg status shows the error message (.hg not found).
In the repository it has the v1.0 code, since the v1.1 is in the zip file and does not connected with repo, I am not sure how to push the v1.1 code to the repository.
I am using kiln mercurial repository.
I'd simply do the following:
Re-clone the repository
Delete all files except those in the .hg folder
Copy the v1.1 files in
Test that it compiles and works
Commit the changes (including deleted and added files)
Push
This will give you a repository with only one commit between v1.0 and v1.1 but that's the best that you can get if you've deleted the .hg folder.
I just did hg pull on a repository and brought in some changesets. It said to run hg update, so I did. Unfortunately, when I did that, it failed with the following error message:
abort: integrity check failed on 00manifest.i:173!
When I run hg verify, it tells me there are a number of issues with things not in the manifest (with some slight path obscuring):
>hg verify
checking changesets
checking manifests
crosschecking files in changesets and manifests
somewhere1/file1.aspx#172: in changeset but not in manifest
somewhere2/file1.pdf#170: in changeset but not in manifest checking files
file3.csproj#172: ee005cae8058 not in manifests
somewhere2/file1.pdf#171: 00371c8b9d95 not in manifests
somewhere3/file1.ascx#170: 5c921d9bf620 not in manifests
somewhere4/file1.ascx#172: 23acbd0efd3a not in manifests
somewhere5/file1.aspx#170: ce48ed795067 not in manifests
somewhere5/file2.aspx#171: 15d13df4206f not in manifests
1328 files, 174 changesets, 3182 total revisions
8 integrity errors encountered!
(first damaged changeset appears to be 170)
The source repository passes hg verify just fine.
Is there any way to recover from an integrity check failure or do I need to re-clone the repository completely from the source (not a huge issue in this case)? What could I have done to cause this, so I don't do it again?
Well, since the first damaged changeset is 170, you could clone your local repository to 169 and then pull from the source. That means only pulling 5 changesets.
hg clone -r 169 damagedrepo fixedrepo
cd fixedreop
hg verify
And then:
hg pull originalsource
As for manual recovery of repository corruption, this page expounds on that better than I can. See section 4:
I have found corruption once in a while before, and although the above
documentation says it is usually from user error, my instances were on
removable USB drives with empty working directories. Sometimes things
just don't get written correctly or are interfered with somehow: it's
not always user error. But I always have multiple copies I can reclone
from so I've been able to get away with basic fixing.
If the simple fix of a partial local clone and pulling from the server doesn't fix it, you're down to 2 options after backing up your changes (if any) to a bundle or patches:
Manually hacking at Mercurial's files.
Doing a new full clone from the server. Usually the easier and faster of the two.
Beware: This method will change all hashes.
Actually there is another way to recover the repository when it is corrupted like this -
You can do a complete rebuild of the repository by using the convert extension. See Section 4.5 on https://www.mercurial-scm.org/wiki/RepositoryCorruption#Recovery_using_convert_extension
First enable the convert extension by adding the following to your ~/.hgrc file
[extensions]
convert=
Then convert the bad repo to create a fixed repo:
$ hg convert --config convert.hg.ignoreerrors=True REPO REPOFIX
This worked for me when I had the experience of suddenly finding that there were missing files in the manifests - "error 255".
Try remove your file 00manifest.i from repo and next use hg remove 00manifest.i and hg commit commands. Worked for me.
What we ended up doing was making a new copy of our 'central' repository, deleting the .hg folder in this copy, creating a new repository there (hg init), and then working with this as the central repository.
Be aware however this is only an appropriate solution if you don't need your changeset history other than as a reference (which we don't). You can still use your old central repository for this purpose.
I can't get Tortoisehg (1.0) to work with subrepos
I have a directory structure like this:
root
.hg
.hgsub
.hgsubstate
Customer1
Project1
.hg
foo.txt
Project2
.hg
Customer2
Project3
.hg
the .hgsub file under root looks like
Customer1\Project1=Customer1\Project1
Customer1\Project2=Customer1\Project2
Customer2\Project3=Customer2\Project3
If modify the file Customer1\Project1\foo.txt and commit from the root it works
>hg ci -m "command line commit"
committing subrepository customer1\project1
in Tortoisehg customer1\project1 is displayed with status S (subrepo)
but when commiting I get a message
abort: customer1/project1: no match under directory!
Is this scenario not supported or am I doing something wrong?
The doc says:
"TortoiseHg 1.0 introduced rudimentary support for subrepositories, and only in the commit / status tool. When Mercurial considers a subrepo as dirty, it will appear in the commit tool as a special entry in the file list with a status of S. If a subrepo is included in the file list of a commit, the subrepo is committed along with the other changes, updating the .hgsubstate file in the main repository root."
I had pretty much the same problem and started trying a whole bunch of variations and I finally got it working for me by using a forward-slash (/) on both sides of the equals sign and not a back-slash (\) anywhere.
So try...
Customer1/Project1=Customer1/Project1
Customer1/Project2=Customer1/Project2
Customer2/Project3=Customer2/Project3
Also, when it was not working, my .hgsubstate file only had a bunch of zeros in it. When it started working, it had a genuine GUID in it.
I was able to get past this problem by committing using the command line for the main repo.
hg commit -m 'Updated subrepo'
I had the same problem:
In one of my repositories committing of one of my changed subrepo modules failed with message
"abort: mysubrepo: no match under directory!"
The reason:
TortoiseHG fails to commit to the subrepository because it handles folder names case-sensitive!
Example:
Your original repository:
C:\Shared\MySubRepo
Cloning this as a subrepo into another repository by command line
hg clone C:\shared\mysubrepo <--- Note the lower cases!
will create a subrepo folder mysubrepo inside your parent repository.
Adding it to the .hgsub file as usual (I always use the platform independent '/' instead of '\', so I don't think that's the reason for the error).
Trying to commit with --subrepos TortoiseHG will end up with the "no match under directory!" error. However, commiting by command line works.
After renaming the subrepo folder mysubrepo to MySubRepo (as the original folder with upper cases) TortoiseHg could commit successfully!
Maybe you have to edit the folder name also in the hgrc file, but I'm not sure if this is really neccessary, because I renamed it in the file before figuring out, that there are canse-sensitive differences in the folder name iteself. Also removing the repository from TortoiseHg Workbench's repository registry and readding it may be needed (and/or restart of the Workbench as well).
I think your problem is with specifying "Customer1\Project1" as a sub repository because Customer1 should be a nested repository as well.
Customer1 and Customer2 should both have '.hgsub' files describing the subrepos inside them (Project1/2)
Remake your Customer1 repository elsewhere and clone Project1 and Project2 into it. Add Project1 and Project2 entries to the '.hgsub' file within Customer1.
Then do the same for a Customer2 repository.
Remember that nested repositories can themselves be nested so create a 'root' repository and then clone Customer1 and Customer2 into it remembering to add entries to the .hgsub file.
Commit 'root' and you should be fine.
The key is to push changes from all instances of a subrepos to its clone master so that other clones that include that subrepos are able to pull that revision if needed.
I have all master repos in the same parent folder on my machine so it makes putting relative paths inside '.hgsub' files such as '../Project1' or '../Customer1' a simple way to push changes to my local clones from our central server.
As far as using TortoiseHG, you will be fine with v1.0 as it will create and manage the '.hgsubstate' file in a nested repository as long as you have already created the '.hgsub' file!
Adding my 2 cents.
I was receiving this error abort: customer1/project1: no match under directory on Windows in the following scenario:
repo was in a folder named MyFolder (note the upper case)
repo had a subrepo
some files (only some!) in the parent repo were commited using myfolder/filename.ext (note the lowercase)
Everything works fine, commandline commits work fine, but Tortoise complains.
Rename the files (find the lowercase ones using hg status --all and you're fine)