I spent yesterday searching via Google and looking through SO for an answer but couldn't find anyone having the exact problem I'm having.
A while ago, I created a branch at Rev 176 in my local Mercurial repo and at Rev 196 created the named branch, "Port to VS2010." See the TortoiseHg screen cap below. I've been able to successfully push the other, "006-x86 and x64 Builds" branch to the remote repo but whenever I try to push the new branch, I get this error in the log:
abort: push creates new remote head 207852dab969!
hint: merge or see "hg help push" for details about pushing new heads
Short of merging or forcing it, how can I push this branch? It represents a tentative solution that will probably never be needed, but I wanted to keep it around just in case.
(Note: You'll notice three gaps in the Rev column. They represent immaterial changsets for the "006-x86 and x64 Builds" branch. I removed them in order to shorten the image.)
Update:
Per Lazy Badger:
acs_FromBuildServer_edited% hg heads -T "{node|short} {branch}\n"
% hg heads -T "{node|short} {branch}\n"
24af28a99211 006-x86 and x64 Builds
69be2af28b7c Port to VS2010
207852dab969 default
86e00db4ba95 005-No Register CardContext
9df44947cc8b 004-Hack typedef boost shared_ptr
81055bcdb3cc 003-Use boost shared_ptr
6358126f4757 002-Add Meyers Fix
1e23ed012883 001-Solution
bcc01f6fbef4 default
[command completed successfully Fri Feb 12 11:15:36 2016]
acs_FromBuildServer_edited%
Actually, you only have two choices. You can merge or you can force it. I think in your case you want to force it.
Typically, you don't want to force a new head because other developers might not be aware of the new head. Since this is an experiment you just want to keep for posterity then it's fine to force it. If you find out you need it you would merge it at that time.
It seems you have possible mix of two unrelated problems
anonymous branching (2 heads of some branch)
pushing new (not existing on remote) branch
New (named) branch have to be pushed with added option to default push command (--new-branch in CLI) or "Allow push to new branch" checkbox in THG GUI
Pushing additional head in bad idea in common, better to find this new head in pre-existing branch and merge
Well, as expected, you have two heads of default branch
207852dab969 default
...
bcc01f6fbef4 default
and according to error message head 207852dab969 (r195) is new, not pushed yet. No, closing branch will not allow you to push branch. If you don't want to merge or force push, you can move diverged history (from branchpoint) to another named branch
My production code is in the default branch, new features go into named branches which get merged with default when the new features are OK. I recently merged a development daytemp into default and started to work on the branch separate processes. I pushed what I had to bitbucket, this is the status it shows now:
I realized there was a bug in default so, at another computer, I pulled, updated to default and fixed the bug. I commited to commit a7cf17ca158e ("bug: all bars were displayed...") and wanted to push to bitbucket. This is what Tortoise HG on that computer shows:
Can you please help me to understand where the problem is? From the mercurial docs I understand that I have a fairly standard situation (I have two heads, one for default and one for separate processes) so I do not understand which new one bitbucket warns me I would be creating when pushing.
EDIT it turned out that, following Vince's comment, there indeed was a new head hidden down the graph.
Output hg outgoing:
changeset: 152:ce343f208e48
parent: 150:ebd10baed373
user: wojtek
date: Thu May 15 06:21:43 2014 +0200
summary: bug: time string when no connection
changeset: 161:a7cf17ca158e
tag: tip
parent: 159:dd4af8e3f7d5
user: wojtek
date: Fri May 16 19:55:54 2014 +0200
summary: bug: all bars were displayed after a day (not cleaned up)
Than changeset 152 was the culprit. After merging it with the current default the push went fine.
What do you have when doing an hg outgoing?
Could you have another default head in your current repo, not visible in that scope, but attempted to be pushed as well? What I'm saying is the 2 heads may already be in your local repo.
As noted in hg help push
By default, push will not allow creation of new heads at the destination,
since multiple heads would make it unclear which head to use.
and
Use --new-branch if you want to allow push to create a new named branch that is not present at the destination.
It's irrelevant (for Mercurial) are these new heads in single branch or in different, they are anyway additional heads
Default push-settings in TortoiseHG's Workbench doesn't have checkbox'ed "new-branch" option for any repository. Just enable it before pushing changes, which contain changeset in not-existing before on remote repository branch "separate process". Just enable new-branch using before first push of any new branch
Someone accidentally mashed their l key while merging .hgtags a couple weeks ago, and we started getting messages about how .hgtags#eed03ad8bbe7, line 1: node 'll005a7e9815cb34a143f349469b6b3c27174af7f6' is not well formed.
I went and fixed the tags file, and everything seemed hunky dory, but now when people clone they get that message. Is there a way to turn it off? Do I have to edit history and tell everyone in the company to blow away all their repositories and re-clone?
I think (but aren't certain) that Mercurial looks at the .hgtags file in all heads when parsing. Check hg heads to see all heads and add a commit to each one that still has the malformed file and new cloners should be okay. People who have their own branches that still have the malformed data in the tip will get that message until they merge the fix into their branches (be they named or anonymous/bookmark)
Disclaimer: there's a 50% chance I'm wrong about that. :)
My branch2274 was branched from default. Rev. 415 was the first commit and it shares an ancestor with the rev. 412 on the default branch.
Branch2274 is a bug fix which needs merging into default soon BUT I did a very silly thing - I merged in changes from a feature branch (at rev. 418)
In simple terms, I need to undo whatever changes were brought in by rev. 418. There seems to be a lot of ways to attempt this but I'm struggling to get any of them to work:
Mercurial queues attempt:
I've tried importing revs 415, 416, 417, (skipping 418), 421, 428 into a patch queue so I can apply it to rev 425.
Problem: tortoisehg will only allow me to import revs 428, 421 but importing 417 is greyed out but importing 418 just gives me the error "abort: cannot import merge revision 418"
Transplant attempt:
patching file Portal/Instructor/Login.aspx.vb
Hunk #1 FAILED at 18
1 out of 1 hunks FAILED -- saving rejects to file Portal/Instructor/Login.aspx.vb.rej
applying 66b6b089ee01
abort: Fix up the merge and run hg transplant --continue
patch failed to apply
[command interrupted]
Login.aspx.vb has been changed on default and I understand why the merge has failed.
How do I 'fix up' the merge?
Alternatively, is there a simpler way for me to take rev. 418 and tell mercurial to undo the changes it brought in with a new commit on case2274?
In the interests of not leaving a question unanswered (!), I managed to resolve this and the ultimate answer is that there's no simple way to resolve it automatically. Transplant deals in patches, differences between two files but doesn't take into account the common ancestry of the two files so struggles to know what to do when a file has been changed by two people in the same place.
The solution is to load the file in your text editor and load the .rej file which lists the failed parts of the patch. I just had to put my additions in a sensible place in the code file.
Running:
hg transplant --continue
..allowed me to apply the other patches.
If anyone cares to spend some time expanding this answer with a little insight or a few relevant links, then the answer is theirs.
I look at Mercurial repositories of some known products, like TortoiseHg and Python, and even though I can see multiple people committing changes, the timeline always looks pretty clean, with just one branch moving forward.
However, let's say you have 14 people working on the same product, won't this quickly get into a branch nightmare with 14 parallel branches at any given time?
For instance, with just two people, and the product at changeset X, now both developers start working on separate features on monday morning, so both start with the same parent changeset.
When they commit, we now have two branches, and then with 14 people, we would quickly have 10+ (might not be 14...) branches that needs to be merged back into the default.
Or... What am I not seeing here? Perhaps it's not really a problem?
Edit: I see there's some confusion as to what I'm really asking about here, so let me clarify.
I know full and well that Mercurial easily handles multiple branches and merging, and as one answer states, even when people work on the same files, they don't often work on the same lines, and even then, a conflict is easily handled. I also know that if two people end up creating a merge hell because they changed a lot of the same code in the same files, there's some overall planning failure here, since we've placed two features in the exact same place onto two developers, instead of perhaps trying them to work together, or just giving both to one developer in the first place.
So that's not it.
What I'm curious about is how these open source project manage such a clean history. It's not important to me (as one comment wondered) that the history is clean, I mean, we do work in parallel, that the repository is able to reflect that, so much the better (in my opinion), however these repositories I've looked at doesn't have that. They seem to be working along the Subversion model where you can't commit before you've updated and merged, in which case the history is just one straight line.
So how do they do it?
Are they "rebasing" the changes so that they appear to be following the latest tip of the branch even though they were originally committed a bit back in the branch history? Transplanting changesets to make them appear to' having been committed in the main branch to begin with?
Or are the projects I've looked at either so slow (at the moment, I didn't look far back in the history) at adding new things that in reality they've only been working one person at a time?
Or are they pushing changes to one central maintainer who reviews and then integrates? It doesn't look like that since many of the projects I looked at had different names on the changesets.
Or... What am I not seeing here?
Perhaps it's not really a problem?
It's not really a problem. In a large project even when people work on the same feature, they don't usually work on the same file. When they work on the same file, they don't usually modify the same lines. And when they modify the same lines, then a merge should be done manually (for the affected lines).
This means in practice that 80+% of the merges can be done automagically by Mercurial itself.
Let's take an example:
you have:
[branch 1] [branch2]
\ /
\ /
[base]
Edit: for clarity, by branch I refer here to unnamed branches.
If you have a file changed in branch 1 but the same file in branch 2 is the same as in base, then the version in branch 1 is chosen. If the file is modified in both branch 1 and branch 2 the files are merged line by line using the same algorithm: if line 1 in file1 in branch 1 is different than line 1 in file1 in base but branch 2 and base have the line 1 equal, line 1 in branch 1 is chosen (and so on and so forth).
For the lines that are modified in both branches, Mercurial interrupts the automated merging process and prompts the user to choose which lines to use, or edit the lines manually.
Since deciding which lines to use is best done by the person(s) who modified those lines, a good practice is to have the person that implemented a feature perform the merge. That means that if me and you work on the same project, I implement my feature, then make a pull from a central/common repository (get the latest version that everyone uses), then merge my new version with the pulled changes, then publish it to the common repository (at this point, the common repository has one main branch, with my merged changes into it). Then, you pull that from the server and do the same with your changes.
This implies that everyone is capable of doing whatever they want in their local repository, and the common/official repository has one branch. It also means that you need to decide on a time frame when people should merge their changes in.
I used to have three or four repositories on my machine already compiled on different product versions (different branches of the repository) and a few different branches in my main repository (one for refactoring, one for development and so on). Whenever I would bring one branch to a stable state (say - finish a refactoring) I would pull from the server, merge that branch into the pulled changes, then push it back to the server and let anyone know that if they made any changes to the affected files, they should pull first from the server.
We used to synchronize implemented features every Monday morning and it took us about an hour to merge everything, then make a weekly build on the server to give to QA (on bad days it would take two member of the team two hours or so, then everyone would pull the week's changes on their machine and use them as a new base for the week). This was for an eight-developers team.
In your updated question it seems that you are more interested in ways of tidying up the history. When you have a history and want to make it into a single, neat, straight line you want to use rebase, transplant and/or mercurial queues. Check the docs out for those three and you should realise the workflow for how its done.
Edit: Since Im waiting for a compile, here follows a specific example of what I mean:
> hg init
> echo test > a.txt
> hg addremove && hg commit -m "added a.txt"
> echo test > b.txt
> hg addremove && hg commit -m "added b.txt"
> hg update 0 # go back to initial revision
> echo test > c.txt
> hg addremove && hg commit -m "added c.txt"
Running hg glog now shows this (diverging) history with two branches:
# changeset: 2:c79893255a0f
| tag: tip
| parent: 0:7e1679006144
| user: mizipzor
| date: Mon Jul 05 12:20:37 2010 +0200
| summary: added c.txt
|
| o changeset: 1:74f6483b38f4
|/ user: mizipzor
| date: Mon Jul 05 12:20:07 2010 +0200
| summary: added b.txt
|
o changeset: 0:7e1679006144
user: mizipzor
date: Mon Jul 05 12:19:41 2010 +0200
summary: added a.txt
Do a rebase, making changeset 1 into a child of 2 rather than 0:
> hg rebase -s 1 -d 2
Now lets check history again:
# changeset: 2:ea0c9a705a70
| tag: tip
| user: mizipzor
| date: Mon Jul 05 12:20:07 2010 +0200
| summary: added b.txt
|
o changeset: 1:c79893255a0f
| user: mizipzor
| date: Mon Jul 05 12:20:37 2010 +0200
| summary: added c.txt
|
o changeset: 0:7e1679006144
user: mizipzor
date: Mon Jul 05 12:19:41 2010 +0200
summary: added a.txt
Presto! Single line. :)
Also note that I didnt do a merge. When you rebase like this, you will have to deal with merge conflicts and everything just like as if you did a merge. Because thats pretty much what happens under the hood. Experiment with this in a small test repo. For example, try changing the file added in revision 0 rather than just adding more files.
I'm a Mercurial developer, so let me explain how we/I do it.
In the Mercurial project we accept contributions in form of patches sent to the mailinglist. When we apply those with hg import, we do an implicit rebase to the tip of the branch we are working on. This help a lot with keeping the history clean.
As for my own changes, I use rebase or mq to linearize things before I push them, again to keep the history tidy. It's basically a matter of doing
hg push # abort: creates new remote head
hg pull
hg rebase
hg push
You can combine the pull and rebase if you like (hg pull --rebase) but I've always liked to take one step at a time.
By the way, there are some disagreements about this practice of linearizing the history -- some believe that the history should show how things really happened, with all the branches and merges and whatnot. I find that as long as you don't mess with public changesets, then it's okay and useful to linearize history.
The Linux kernel is stored in thousands of repositories and probably millions of branches, and this doesn't seem to pose a problem. For large projects you need a repository strategy (e.g., the dictator–lieutenants strategy), but having many branches is the main strength of the modern DVCSes and not a problem at all.
Yes, we'll have to merge and to avoid heads on the main repository, merging should be done on the child repositories by the developer.
So before you push your code to the parent repository you first pull the latest changes, merge on your side and (try to) push. This should avoid unwanted heads in the master repo
I don't know how the TortoiseHg team does things, but you can use Mercurial's rebase extension to "detach" a branch and drop it on the top of the tip, creating a single branch.
In practice, though, I don't get concerned about multiple branches, as long as I don't see more heads than there should be. Merging is not really a big deal.