Please can someone guide me through a process here?
I'm a bit of a newb in Mercurial so I'll post a pic to be more specific.
Here's the tree of our repo right now:
We have 2 branches: processors and extra libraries.
We created extra libraries after processors to test certain issues. Then we closed it and continue working on processors.
Now it occurred the need to change back to extra libraries in #645 to push some new stuff for testing. Is this possible now? and how can I do it with TortoiseHG?
Thanks in advance!
PS: Sorry for the silly question but I want to be very careful on this repo..
Closed branch is usual branch, which just have some additional meta-info in branch-head.
If you want to "reopen" closed branch, you have
Update to head's changeset (645)
So some (needed) changes in working dir and commit: changeset 658 will be new head of active named branch, tip of repository and closed named branch will become open
Related
I have the following situation:
I have some changes on a branch, and another dev had closed and pushed the same branch.
When I tried to push I got the "push creates new remote head" message, but when I pulled there was nothing to pull, and when I attempted to merge I got the message that the branch only had one head.
The solution to this problem was to merge, but specify a revision using -r
I merged to the revision where my colleague had closed the branch, and then I was able to commit and push and all was good again.
The issue was that mercurial will not merge with a closed head, unless you specify the revision.
When searching SO I couldn't find this specific problem with this solution, so I thought worth adding in the hope that it will help someone else.
2 main branches:
stable - used for release and for hotfixes.
default - used for all other development and all features
Please see revisions 8 and 9 specifically. I added a 2 separate features in revisions 3 and 4, worked on them separately, merged them into default in revisions 7 and 8. They are not complete at this time.
My question is, did I do this correctly considering that I am not done with the features and did not close the feature branches? The connected blue and pink lines at revision 8, along with the blue extension at revision 9 are confusing me.
I'm pretty new to source control, so any explanations are appreciated.
You just have two heads on your tree, which are at revisions 8 and 9 specifically now. You could run "hg heads" on the command line in that directory to see some textual information about them both. At this point, you could update to either head, make changes and commit, then update to the other head, make changes and commit, etc. Also, you could merge your feature branch into the default and then just have one head. It depends on how long you want to keep your feature branch separate.
More interestingly, are you planning to keep using the "stable" branch? If so, I guess that you could "hg update" to r1, and then merge things from your other branches to there.
Side note: You may be interested in reading about "hg flow", and its branching model. See for example:
https://andy.mehalick.com/2011/12/24/an-introduction-to-hgflow
http://www.carl-berg.se/post/hgflow-git-flow-for-hg
I worked for three weeks on the default branch, committing frequently. I would now like to update to a point 3 weeks ago and push/pull etc with default as if those 3 weeks never existed. Ideally, I could say "Mercurial, please treat all work over the past 3 weeks as a new feature branch" so I can continue working on default until I fix what needs to be fixed. Then I can return to my feature branch.
I know I should have just started a feature branch 3 weeks ago, but we all mistakes...
As long has you've haven't pushed to a public repo you can:
update to the point 3 weeks ago
create the named branch
rebase 'ahead commits' on default to the named branch.
You may want to the change the 'Phase' of the named branch to secret so you don't push it accidentally.
If you haven't used Rebase before you will have to enable the extension in File -> Settings -> Extensions.
Otherwise if you have pushed then:
update to the point 3 weeks ago.
Just commit changes (create two heads on default)
When you've done, before pushing merge one default head onto the other default branch.
I'd recommend cloning to a new, local repository from the revision 3 weeks ago. Work on this new repository and then, when ready, push back to parent (the local one).
I like working with clones rather than branches since it allows me to have a simpler view of the statuses. In my case, have an eclipse work space for each repository that I can switch between.
This might not be exactly what you asked for, but it's a valid solution to your need.
I hope this helps.
Im reading Mercurial, the definitive guide, and it mentions that in large projects, its useful to have your project split up into feature branches. Ive drawn a quick picture of what i think is happening when you want to merge the Feature Branch with the Master Branch.
Is my diagram correct + does the Feature Branch continue to exist? Im assuming yes.
The active named branch can be explicitly closed using:
hg commit --close-branch
This tends to be done if a line of work was not going anywhere. If you want to re-open a branch of the same name on top of a closed branch, you need to force that branch open again using:
hg branch <name> --force
However, they implicitly become inactive if you merge from your feature branch into another branch and the feature branch has no un-merged change-sets (as in, the last thing on that branch is the merge into another branch). The destination of this merge does not have to be the "mainline" in order to deactivate the branch, inactivity is purely based on any un-merged change-sets.
They become active again if you subsequently create change-sets on them at a later date. This tends to be the common situation, if you are working on features off-mainline and merging in frequently.
Do note that a closed branch is not the same as an inactive branch.
I'm sorry, but I couldn't really understand your diagram so I hope the above sentences make sense.
Also, do not confuse named branches with anonymous branches, which are when a single branch has multiple "heads".
I love the flexibility of named branches but I have some concerns about the prolifieration of heads.
Even when the branch is closed, it still shows up in the heads. I have an idea for how to clean up the output from "hg heads"
My question to the gurus: "What am I missing?"
First off you may ask, Why might I want to totally hide the head of a named branch? For various reasons:
the feature is a bad idea
the feature is a good idea that is not ready for merging to tip, but maybe in a few months
the branch is a patch release to an older tagged version
edit: It turns out the prolifiration of heads is a symptom of the older version of mercurial I was using. Closing the branch hides the head of the branch it on newer Mercurial versions.
My idea is to have a "dead" head branch onto which all these closed branch heads will be merged.
The dead head would be parented by changeset 0 and serve the sole purpose of bundling up the stray heads that are not needed right now.
The deadhead has only other deadhead children, which never get merged back into the default branch.
You can use hg commit --close-branch to mark a branch as closed:
http://www.selenic.com/mercurial/hg.1.html#commit
Closed branches will not show up in hg branches or hg heads by default (only if the -c/--closed option is specified), so I'm not sure how you're seeing "clutter"?
What exactly would you gain by merging things?
There seems to be a downside to leaving dead heads which is not solved by later versions of Mercurial.
Suppose you have a lot of closed branch heads and only a single non-closed active branch. Suppose further that at some later point you make a bad commit (rev bad) on top of the non-closed head (rev good). Before you push you'd like to clone your repository dropping that bad commit. That is usually a simple thing to do -
hg clone --rev good BadRepo FixedRepo
This unfortunately does not pull the closed branch heads since they are not ancestors of rev good. All those branches which were closed will not be closed in the cloned repository. I tested this with Mercurial 2.3.1.
Thoughts?
p.s. The hgflow extension does close feature and release branches before merging. This avoids the closed heads problem.
Regarding the clone being an ugly approach, it has worked quite well and easily for me. The clone replaces the repository with the bad commit. The clone is a local effort. That bad repository is just discarded. I usually realize I've made a bad commit very soon after.
The -b option is just a way to rephrase the --rev by using a branch name instead of a change set identifier. Using the --rev option does pull the entire topological tree under the revision. If the revision is the head of the branch then the --rev clone is the same as the -b clone. -b leaves the same problem that I described with the --rev option. Branches which were closed in the original repository get reopened if they were left as heads.
If the pattern is to leave closed heads then they will soon greatly outnumber relevant heads. Getting those closures into a clone is quite an effort unless you do a full clone.
I feel I've muddied the waters with why I might do a partial clone. I'll restate my concern about closure heads more carefully.
For any partial clone from repository X to repository Y, if there exists a branch B in repository X with a closure head and that branch is included in the clone for purely topological reasons, then branch B will not be closed in repository Y. Further if the merging pattern is to generally leave closure heads then the number of closure heads is of order development time.
This is a concern to me so I close my branches before I merge. I use hgflow (http://nvie.com/posts/a-successful-git-branching-model). A possible partial clone would be to clone the development branch and follow that with a pull of the master branch (e.g. if you wish to eliminate dead ends). If feature and release branches had been closed after their final merges then those branches would be reopened in the clone.