In changeset it shows that I have 12 changes to be pushed but when I click push to mercurial repo it says "no outgoing changesets to URL". this is my first attempt at using TortoiseHg for code push. please assist.
It was an issue with description, I had an extra space in the beginning of the description while committing code to my local web server. which prevented it from being pushed to global repo.
Related
I have a Mercurial repository on BitBucket, and I use SourceTree to keep it synced with my local repository. When I want to make a new branch, what I usually do is create the branch on BitBucket and then open SourceTree and pull the latest changes, and then I update my working repository to the new branch. Then, when the changes are complete I merge the branch into default and push the changes back to BitBucket.
Lately, when I make a new branch on BitBucket and click pull in SourceTree it says there are no changes to be pulled. If I make changes in my local repository and try to push them it says there are no changes to be pushed.
However, if I use the command line interface to pull/push the changes it works correctly. I used this process 5+ times for other branches, and it just now stopped working, as if SourceTree is no longer connected to my BitBucket repository. Does anyone know how I can fix this?
It turns out all I had to do was update to the most up-to-date version of SourceTree.
Edit: I updated from version 2.6.10 to version 3.0.12.
For some reason TortoiseHG stopped considering my pushed changesets as having a phase of public; it's keeping them as "default."
Is there any way to force TortoiseHG to "sync up" with the remote repository, and get this straight?
Is there a way in Kiln?
It looks like this was a recent change in Kiln. As of version 3, pushed changes to a branch repository will show up as draft if they're not a part of the main, central repository from which the branch was created.
I am making say 4 local commits in HgSVN, then I updated my local code to an earlier revision, I added changes to it, did local commits, merged with server code and when tried to push, I was not allowed because of the 4 local commits not merged.
How to delete/remove these 4 local commits from HgSVN history and push the code ?
What should be done in this scenario ?
using HgCommit for saving code to the local machine and
HgWorkbench for pushing the local changes to the server
Your main big problem: you prefer do nor read docs and use tools blindly. Otherwise you have to know one of the biggest limitation of HgSubversion: it is not possible to push back to Subversion mergesets from Mercurial
"...Mercurial merges cannot be pushed to Subversion"
Also, HgSubversion page on Mercurial wiki clearly states:
The important point to note is that hgsubversion cannot push merge changesets to a svn repository. This means you should not try to merge this new head -- if you do so, hg push to svn will fail. Instead, you should rebase the changesets that you want to push to the Subversion repository (see Rebasing changes below)
Just several days ago, when I push to a hg repository, something like 'xxx does not appear to be an hg repository' appears after push finishes. The output looks like this:
pushing to http://xxx/scm/hg/jewelry
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files
abort: 'http://xxx/scm/hg/jewelry' does not appear to be an hg repository:
---%<--- (no content-type)
---%<---
!
The push is actually finished, so this can't be a big deal, except that it's really annoying.
So did anyone come across this?
BTW, the hg version on client side is 2.1 & server is 2.3. But this does not seem to be a version problem because it just came out from nowhere several days ago.
I'm not certain but it looks like someone has installed a hook on the server to run something after the push and their hook is broken? Do you see any extra detail if you add --debug to the push? Any chance someone recently added a server side changegroup hook? Perhaps 'notify' to send out emails?
I am in the process of setting up some third-party subrepositories under a Mercurial repository. One subrepo is another Mercurial repo hosted on Bitbucket.
Since it is a public repo, and I am not a contributor to it, I don't wish to push back to it. However I would like to still have the repository automatically cloned when I clone the parent repository. For one thing, I'd like to have access to the collective history of the subrepository so I can see what may or may not have changed over time.
So, I made an entry in the parent repo's .hgsub file as follows:
thesubrepo = https://bitbucket.org/user/repo
and cloned the repo using
$ hg clone https://bitbucket.org/user/repo thesubrepo
I made a commit to record the subrepo state. I then went to push my parent repo back to it's server (Kiln) only to discover that it was trying to push the subrepo I back to the Bitbucket server. The push to the Bitbucket subrepository appears to not do anything, though.
I did not observe this behaviour when I made a Git subrepo in the same manner (hosted on Git hub) using an entry in .hgsub like this
abc = [git]git://github.com/xyz/abc
Is it best for me just to do this by not setting up a subrepository, and just let Mercurial store the files as files? Or (preferably) is there some setting somewhere that I can use to tell Mercurial to never actually push the contents of this subrepo back to it's source location?
I'd rather be able to configure it to only push those subrepos manually, so if anyone can shed some light on this, I would appreciate it.
I found a reference to commitsubrepos = no in another stack overflow answer, which as far as i can tell is about commits, and not pushes of sub repositories. I then looked this up on the mercurial website, in the hope there might be some reference to a setting pertaining to pushing subrepos, but... no
You cannot (currently, as of version 2.0) ask Mercurial to not push subrepositories.
The fundamental problem is that Mercurial must ensure that you have a consistent state on the remote repository when you push. It would be unsafe if you could push back to Kiln and then have a changeset there that references a revision on Bitbucket that isn't there. Mercurial doesn't know if a changeset you have locally is published or if you created it — so it has to (try to) push.
We're currently working on a concept called phases. With that in place, Mercurial will begin tracking if a changeset is created locally or already published. That can be used for subrepositories too: if there are only changesets in the "public" phase in a subrepo, then there's no need to try pushing!