I'm working on my thesis and storing changes in mercurial. I'm not getting an error that I've got multiple heads, which I'm confused about -- I've only got one working repository which I push occasionally to bitbucket. Here's what happened:
$ hg commit -m "Fixing up..."
abort: No such file or directory: /Users/me/Dropbox/thesis/thesis_tex/simple.pdf
$ hg commit -m "Adding in page headers"
created new head
...one more commit, not having realized that having created a new head was a problem...
$ hg push
pushing to ssh://hg#bitbucket.org/...
searching for changes
abort: push creates new remote heads!
(did you forget to merge? use push -f to force)
$ hg heads
changeset: 26:3823a395b1ce
tag: tip
user: me
date: Fri Aug 26 09:39:45 2011 -0400
summary: Adding...
changeset: 24:c7c6517d4281
user: me
date: Thu Aug 25 16:34:42 2011 -0400
summary: Fixing up...
How can I easily get rid of the other head, without messing up my working directory? Why did a second head get created? Is there a problem with keeping mercurial repositories in dropbox folders?
How can I easily get rid of the other head, without messing up my working directory?
Merge the branches with hg merge.
Is there a problem with keeping mercurial repositories in dropbox folders?
This seems redundant to me, since Dropbox keeps a 30-day history on your files. I'd choose either Hg+Bitbucket (or whatever Mercurial hosting) or Dropbox, but not both.
Edit: Why not use Mercurial and Dropbox? Here's why.
Ben Hughes said it well:
By keeping your Mercurial repo on Dropbox you’re version controlling your version control system files. If you somehow manage to cause a conflict with files in your .hg directory, things could get messy. Recoverable, but messy.
I disagree with #Matt Ball on the dropbox matter.
I think redundancy is your friend. Also the purpose of Hg and the dropbox is slightly different in your case.
Dropbox backs up for you automatically (as well as tracking file changes and letting you work on any machine with internet and making it easy to share your work.) and Hg lets you work offline and commit in logical chunks (as well as working as backup when you sync).
I have used Hg in my dropbox folder without problem for at least a year and I have not experienced any problems.
If you work on more than one machine and have the dropbox/Hg combo on all machines I suggest that you let dropbox do the syncing.
Related
I have a repo on a network drive (served by Windows server), with local repos pushing/pulling to it on the various machines I work on.
I just dealt with this problem, and solved it by cloning the repo from the network drive to a local disk, pushing, then cloning it back again. The machine from which I did this had not problem pushing further changes after this.
Now I just tried pushing from my laptop, and this happens:
% hg --debug push "Z:\[main repo]"
pushing to Z:\[main repo]
query 1; heads
searching for changes
all remote heads known locally
listing keys for "bookmarks"
2 changesets found
list of changesets:
2ed25c8975482734e3b9eed828573fd711d26fd8
19a424c011ffd0c887cf1d54ed0b537a6c1af714
adding changesets
add changeset 2ed25c897548
add changeset 19a424c011ff
adding manifests
adding file changes
adding GEM.py revisions
transaction abort!
rollback completed
abort: No usable temporary file name found
[command returned code 255 Thu Mar 09 18:51:11 2017]
The only info pertaining to this error message I have found so far is this, and I definitely have no files named con.*in my project. There are several named con*.py but they have never been a problem, and both the laptop and my workstation are running Windows 7, and I've been working on this project for a few years now.
I have happily pushed from this laptop for over a year, and it was never a problem. I don't really have any good idea where to even start looking. Could it be connected to the fact that my workstation had the main repo opened at the same time? It was definitely not doing anything to it at the time.
Update:
I ran hg verify, and this is what it returns -- no problem as far as aI can tell
% hg --debug verify
repository uses revlog format 1
checking changesets
checking manifests
crosschecking files in changesets and manifests
checking files
73 files, 74 changesets, 226 total revisions
[command completed successfully Fri Mar 10 08:58:02 2017]
I had faced the same error as well.
I just ran tortoise hg as as administrator and that fixed it for me
I don't have an answer yet but I would try the following:
Update to the latest mercurial version (4.1) and try again
Verify the repo integrity with hg verify
Although I understand it always worked as is, try to rename all the con.py files. The thing with CON is that it represents a device, I think it comes from DOS times :-)
If I understand correctly, you push to Z:[main repo] where Z: is a Windows share. Try to push to the same repo in another way, with ssh (requires some setup, yes)
Good luck, very bizarre problem :-/
We are using Kiln as our mercurial server and I there are three developers working on the same repo and i get this issue often and I am not quite sure what is happening.
Every once in a while I will do an hg pull.
Then when I run hg up I get the following message
abort: crosses branches (use 'hg merge' to merge or use 'hg update -C'
to discard changes )
ok so I run hg merge and I get
abort: outstanding uncommitted changes (use 'hg status' to list
changes)
ok so I run hg status and I get something like this
! Safemail 3.0\CSM3.0\AddinSetup\Release\AddinSetup.tmp
! Safemail 3.0\CSM3.0\Outlook2007Addin\Outlook2007Addin_TemporaryKey.pfx
no idea what to do with that.
If I run hg commit again it says no changes.
Finally if i run hg heads I get
changeset: 51:daea74a29d5c
tag: tip
parent: 49:b88e6e522672
user: Rahul Chandran
date: Mon Jan 23 13:30:54 2012 -0800
summary: added login code
changeset: 50:cb6f6e1eec5e
parent: 46:d83431c322ad
user: dthompson#Jabberwock.lan
date: Mon Jan 16 22:10:11 2012 -0600
summary: Adjusted Email-PDF formatting
Clearly I do not come from a DSCS background and I am probably missing some basic understanding of what is going on . Any help appreciated.
What I do know is that the code that my co worker checked in via a push has like no files in common with my changes. I would not expect like a merge conflict or some such in a non distributed source control system . essentially I am having some trouble understanding what is happening here exactly
Check out the help for hg status. It will tell you that ! means:
! = missing (deleted by non-hg command, but still tracked)
So you deleted some files that are tracked in your repository. If you didn't mean to track them in the first place (they look like good .hgignore candidates) you can hg forget FILENAMES; hg commit them. If, instead, you do mean to track them you can hg revert FILENAMES them (to get them back into your working dir from your repository.
Once hg status agrees you have no uncommitted changes you'll be able to hg merge.
Consider taking a little time to read the first few chapters of the (free) Mercurial book. These basic concepts are easy when presented well and in order, but horribly frustrating when you try to pick them up piecemeal from google searches and Stack Overflow questions. It's worth the 30 minutes to save you hours.
I'm new to Mercurial, and I made the mistake of making different changes on different systems before the main repository was up to date. (I understand this is what Mercurial is built for, but my thick brain is struggling to resolve the issue.)
Now on my primary development server, everything is up to date and committed. However...
$ hg push
abort: push creates new remote branches: 4f2672f039d7!
(use 'hg push --new-branch' to create new remote branches)
I don't really want a new branch. I just want all the changes to be merged.
$ hg heads
changeset: 459:ff5f94e44aba
branch: 4f2672f039d7
tag: tip
parent: 458:e63d02baf4cf
parent: 455:267abda62069
user: mike#...
date: Tue Sep 13 14:25:16 2011 -0400
summary: Images from prof
changeset: 455:267abda62069
parent: 453:a74757e26357
user: mike#localhost.localdomain
date: Tue Sep 13 09:08:12 2011 -0400
summary: images for FLC
Point me in the right direction?
EDIT: (adding detail)
When I try to merge, I get the following result:
$ hg merge
abort: branch '4f2672f039d7' has one head - please merge with an explicit rev
(run 'hg heads' to see all heads)
I have tried hg merge ff5f94e44aba, and all of the revs listed above, and each one returns the same result:
$ hg merge 267abda62069
abort: merging with a working directory ancestor has no effect
It looks like you've accidentally created a branch with a silly name. What you most likely want to do is reapply your changes with a branch name that makes better sense. There's no totally automatic way of doing this, but you can extract each changeset as a patch, revert to the point where you messed up and reapply those changes on the proper branch.
Basically what you need to do is look at the changelog; probably by running hg out to see what's missing from the central repository. Make a note of each of the revs that you want to keep.
Next update to the last good revision. Make sure that you are on the branch you wanted your commits to be on.
Now you will apply each of the changes you made and commit each one. You can automate this process something like this:
BADREVS="123 124 125 126"
recommit() { hg di -c $1 | patch -p1; hg ci -m "$(hg log -r $1 --template '{desc}')";}
for rev in $BADREVS; do
recommit $rev
done
Now you've got your changes in your local repository twice; once as the commits on the weird branch and again on the right branch. You can push those changes to the central repo using hg push -b GOODBRANCH so that only the changes to the right branch go up; Alternatively, you can install the strip extension to remove the changes you didn't want from the local repo and then you can push as normal.
By the sound of it; you will still have to deal with the changes made to the central repository before you can push, since you pushed changes from another repo. You probably want to do this merging after you clean up the change history in the local repo.
Pull from remote and then update / merge / commit first. Then you won't make new branches.
I've had this happen when I missed a merge. I like the TortoiseHg workbench for this because it can be a little easier to find what you missed through visualization.
A good way to avoid this in the future, how I stopped getting this error, is the fetch extension. Set your post pull to fetch and it will automatically merge for you, which is very nice. If there's a conflict it brings up whatever conflict resolver you use.
I'm a VERY happy user of bitbucket and mercurial after years of putting up with subversion (and CVS, SourceSafe and others; anybody remember SCCS?). I've considerable project history now in my local hg repo, pushed daily to bitbucket and thence to my home machines.
Problem is, my company wants me to maintain a copy of this history in subversion. And I've hit a stone wall trying to set this up. I've installed hgsubversion, I think correctly. And I've used svnadmin to create an empty svn repository ready to hold the hg history.
But now what? The instructions say to start by pulling a clone (of nose? what's that? I assume this means checkout a copy of the new empty svn directory. OK did that.
But now what? I assume the next step is to push my real local hg clone to the empty svn repo I just checked out. But nothing I've tried will do this. Pull fails as follows, reporting "unrelated repository" (as I recall I gate it the URL of my master local hg repo to get around the "Needs a URL" popup on everything else I've tried.
found new changeset 139d02f4b233
examining 4e97a23b6815:342df9e52cec
abort: repository is unrelated
[command returned code 255 Mon Apr 25 11:29:33 2011]
The result of all this fumbling around is a directory with .hg, .svn and .hgignore entries and nothing else.
So, I feel I'm missing something basic that hundreds of others must have tried by now. Can someone please help me get started? Thanks!
PS: Currently the intent is to maintain SVN permanently as the team repo and push changes there from Hg periodically which would remain the main client for me indefinitely. In case this matters...
You can use the convert extension:
hg convert --dest-type svn mercurialrepo svnrepo
And hgsubversion allows you keep both of them in sync ( bidirectional)
Answered here at SO already:
Converting from Mercurial to Subversion
Migrating from Mercurial to Subversion
Perhaps look at the answers to this question.
Hgsubversion is for working with a repository cloned from SVN using Hg, not the other way around.
I committed a bunch of changesets locally (23-28) and then I realized that I wanted to go back to revision 25, so I ran "hg up -r 25" to go back. Then I started working from there and committed a few changesets. Now I'm ready to push my changes to the server, but when I try to do that it complains with "abort: push creates new remote heads on branch 'default'!". I thought someone else may have committed to the repository so I did a hg pull, but did not get any changes.
Here is the revision tree that I am working with
23
|
24
|
25
/ \
26 29
| |
27 30
| |
28 31
|
32
|
33
|
34
|
35
Is it possible to remove revisions 26,27, and 28? How can I fix things so that I can run "hg push" without errors? Should I have used a different command to go back to revision 25?
Let me just throw in a voice of dissent on Lasse's answer. Mercurial is a system about building an immutable history. Think of a scientist working in his or her lab book on numbered pages in pen. Everything is important, even the stuff you wish you didn't write and don't want at this second. The strip command isn't enabled by default for a reason -- it violates the immutability that is a mercurial goal.
The more "Mercurial" way to address this would be to merge 26 into 35, selecting entirely the options from 35, so you're back down to one head. Then your push will still have only one head, but all of history is preserved.
Alternately you had the option to 'hg push -r 35' which would have given you no warning or error nor required -f because you'd be leaving the repo repo with only one head.
There's nothing wrong with strip, but it's not part of the traditional toolset or mindset in Mercurial.
Well, there's two ways I know of.
Note: Please make a backup, or a clone to experiment on, I do not take responsibility for any lost work
First, if you got MQ extension enabled, you can strip those off. I only know how to do that using TortoiseHg, but I'll find the right commands after posting here.
To do this, you would execute this command:
hg strip 26
Secondly, you can create a new clone locally of only some of the changesets, again I only know how to do that using TortoiseHg.
To do this, you would execute this command:
hg clone SOURCEDIRECTORY CLONEDIRECTORY -r35
Then, from your clone, after verifying that it contains the changesets you want, you push against the target repository.
As for answering what you should've done instead, you could've deleted your original clone and re-cloned from the server to get a clean clone only containing up to changeset 25, but of course you could use the strip command to get rid of the excess changesets then as well.
There's nothing inherently wrong with having multiple heads - Mercurial is just checking it's what you want. In this case, you might want to keep the abandoned development path for future reference. If so, just force the push (with hg -f push) and create the abandoned branch. If you just want to forget everything about it, #Lasse's answer is just fine.