MacOs Yosemite
I try clone repository with sourcetree. It began cloning but through some minutes it show me alert "Confirm Delete Repository" with text "You opted to delete repositories on disk but the repository "(null)" contains uncommitted files which will be lost forever if you delete this repository. Are you sure you want to delete the repository on disk?" So i can't clone
I try clone with terminal. After cloning terminal write message: "remote: Connection to bitbucket.org closed by remote host." But it's not clong all my repository and subrepository.
How I can get repository from bitbucket? I have 2 repositories, that I cloning 2-3 monthes ago on my macbook, and it was all good. Repository is cloned on my work under my account too without problems. But now I try get 2 new repositories on my mac, and I have same issues, that I described
In sourcetree I got such error:
hg clone ssh://hg#bitbucket.org/{my_repository}
requesting all changes
adding changesets
adding manifests
adding file changes
added 19 changesets with 115 changes to 58 files
updating to branch default
cloning subrepo framework from ssh://hg#bitbucket.org/{my_repository}
requesting all changes
adding changesets
adding manifests
adding file changes
added 1004 changesets with 4877 changes to 2384 files (+3 heads)
remote: Connection to bitbucket.org closed by remote host.
Completed with errors, see above
Related
I've just created a new Mercurial repo on my private server, but I can't push to it, and I can't figure out why.
Here's what I see:
% hg push
pushing to ssh://hg#mydomain.com//var/repos/myrepo
abort: no suitable response from remote hg!
On the server, the repo exists, and I can clone it locally:
root#mydomain:/tmp# hg clone /var/repos/myrepo repoclone
updating to branch default
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
I created the repo with hg init myrepo. It's owned by hg:hg, mod 755.
My workstation and server are both running
Mercurial Distributed SCM (version 4.4.1)
What else might be wrong?
Discovered you can add --debug to hg push.
% hg --debug push
pushing to ssh://hg#mydomain.com//var/repos/myrepo
running ssh 'hg#mydomain.com' 'hg -R /var/repos/myrepo serve --stdio'
sending hello command
sending between command
remote: This account is currently not available.
abort: no suitable response from remote hg!
I guess the server user must have a shell.
nano /etc/passwd
Changed
hg:x:999:1002:Mercurial repo owner:/home/hg:/usr/sbin/nologin
to
hg:x:999:1002:Mercurial repo owner:/home/hg:/bin/bash
And now it pushes!
I performed a histedit fold on my local repo after which I tried pushing the changes to Bitbucket, but the push fails with the message:
remote has heads on branch 'default' that are not known locally
abort: push creates new remote head
(pull and merge or see 'hg help push' for details about pushing new heads)
How do I go about doing a fold on the remote repo without running into this problem?
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 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.
When remotely updating a Mercurial Repository, I am getting the following error from the hg update command that is being run on the remote server after the push. I looked around online for some help for this however was unsuccessful in finding anything useful. At this point, I am hoping for some ideas and / or insight as to what would be causing this problem.
The error is just below. It occurred when pushing two changesets. One changeset included an unrelated index.html file change. The other changeset was a merge, which included the index.html change as well as the renaming of the two image files.
levinaris#server01:/home/web/repository$ hg push
pushing to ssh://10.10.1.12//home/web/repository
searching for changes`remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 2 changesets with 1 changes to 1 files
remote: abort: Operation not permitted: /home/web/repository/html/images/image.gif
remote: warning: changegroup hook exited with status 255
Additional details:
Both images are 10385 bytes in size. (yes, this error occurs on two images I have)
The two images had their names changed in changesets that were already pushed and hg updated due to case-folding collisions when attempting to pull the repositories down to Windows PCs.
The target server has the following hook in /etc/mercurial/hgrc:
[hooks]
changegroup = hg update
As a work-around, I did the following:
Deleted image.gif.
Deleted another image file that produced the error.
Ran hg update - success!
Ran hg revert html/image/image.gif
Ran hg revert html/image/otherimage.gif
At this point, I am trying to better understand the cause of this problem, so that I can ensure a solid, easy-to-use implementation in my environment. I really appreciate your help!!
After using hg --debug update in the hook, I received this output:
levinaris#server01:/home/web/repository$ hg push
pushing to /home/web/staging/repository
searching for changes
adding changesets
adding manifests
adding file changes
added 2 changesets with 1 changes to 1 files
resolving manifests
overwrite False partial False
ancestor 58a5edb95c9a local 58a5edb95c9a+ remote 3aafb97b148c
searching for copies back to rev 6
html/index.php: remote is newer -> g
html/images/otherimage.gif.casefolding: update permissions -> e
html/images/image.gif: update permissions -> e
abort: Operation not permitted: /home/web/staging/repository/html/images/image.gif
warning: changegroup hook exited with status 255
Additional Permission Information:
All 3 files in the 2 changesets have 775 permission with the webuser:dev user:group.
My Global hgrc file has the webuser trusted
[trusted]
users = webuser
Is it possible that the permissions that file on the server were such that it couldn't be overwitten by the person doing the push?
If, for example, two different people have done that push (and thus update) the second person isn't going to be able to overwrite the files created by the first person's push triggered update.
Maybe try changing the hook to this for a test (you don't actually have those single quotes on your hook, right?):
[hooks]
changegroup = hg --debug update
If it is a permissions issue the usual fix is to put everyone who will be pushing and updating into the same group (I call mine 'hg') and then using the sticky group bit on all the directories in the repo to make sure new files have that group.