I have starting using Mercurial for my (our) versioning needs. I have now come to the point that I need to create a feature branch. However, now that I have started working on it -- and I try to push my changes, I keep getting a warning about new remote heads. That's stupid, I know that there will be new remote head(s) that's what a branch after all is?
How am I supposed to create branches and push them without this problem, without using force push as it is surely not the right way to go, right?
I thought about using separate repositories, but that feels just stupid especially for feature branches.
Any help welcome!
To date, the best guide out there is Steve Losh's "A Guide to Branching in Mercurial".
Mercurial will always complain about creating new heads on the remote. You must use either --force or --new-branch when creating a new head.
When using TortoiseHg, the same can be accomplished via the Synchronize view of the Workbench. Click Options and then select the Allow push of a new branch or Force push or pull option, as needed.
The reason it behaves this is way is that the Mercurial developers wanted to make it a conscious decision to create a new head on the remote. Their view is that typical workflows should merge changes prior to pushing.
This tutorial by Joel Spolsky helped me a bunch when I just started out with mercurial. It might be helpful for you as well:
http://hginit.com/
Related
We've worked out a repository structure we'd like to maintain and under that structure will prevent RepoA from being able to pull from RepoB. How can I setup a repo so that it can only push to a certain repo but not pull from it?
You can technically push/pull from any location and would probably try to avoid mucking with that flexibility unless you're good at writing hooks. And, if anyone has write access to UAT, you cannot prevent any changes from being pushed to UAT as you will need to do that when some new bits need to enter the UAT branch for testing.
What it sounds like you are trying to do is preserve a "stable" while allowing work to continue on an "anonymous" branch (your alpha) that was cloned from UAT. Eventually, you have to merge that back into UAT, so I would really just give a few senior-level developers write access to UAT and trust that they follow the proper procedure when working with the branches.
I suggest reviewing the Guide to Branching and the Managing Releases section of the Hg Book before trying to invent a new way to seemingly protect your branches.
Edit: I did find a similar question for preventing the default push, but allowing pulls. It shows you the basics on implementing a preoutgoing hook, which is not what you want, but similar in nature.
Does anybody have any advice about using Mercurial as a front end for Perforce? What I would like to do is to use Mercurial to handle really granular changes and then, once I'm done something, push it back up to the Perforce server.
I found this article http://www.dehora.net/journal/2008/01/05/using-mercurial-with-perforce/ but it doesn't suggest any tooling to help out with the integrations. Does any exist? I suppose I am looking for it pull any new changes from Perforce, integrate them into my local Mercurial then roll up all the Mercurial commits I've made since last integration and push them up to Perforce. Similar to git-p4.
I got an error when I followed the link you gave. But I suggest you look into the perfarce extension (I love the name!). I have not used it myself, but it's my understanding that this is what people use to bridge the gap between Mercurial and Perforce.
See also the wiki page on Perforce concepts. It seems to have a lot of good info.
As Martin says, Perfarce is what you want. I've used it at a previous job, and in general it works pretty well if you're just working with a single perforce branch into a single mercurial clone. If you start cloning multiple times from your original Mercurial clone, then things start getting complex. Not impossible, just complex.
In general it works by bundling all changes since you last pulled from Perforce. Creating a single perforce changelist from them. Tagging that changelist's comment with the hash of the Mercurial version and committing it to perforce. It then re-imports that change from Perforce and merges it into your Mercurial tree, and because they're both the same there's no merge.
Basically it works quite well for pull/edit/commit/update workflows. Unfortunately it's not any help when it comes to integrations (unless I missed something) as perforce branches aren't converted to Mercurial ones. It wouldn't know what to merge.
Subversion shop considering switching to Mercurial, trying to figure out in advance what all the complaints from developers are going to be. There's one fairly common use case here that I can't see how to handle.
I'm working on some largish feature, and I have a significant part of the code -- or possibly several significant parts of the code -- in pieces all over the garage floor, totally unsuitable for checkin, maybe not even compiling.
An urgent bugfix request comes in. The fix is nice and local and doesn't touch any of the code I've been working on.
I make the fix in my working copy.
Now what?
I've looked at "Mercurial cherry picking changes for commit" and "best practices in mercurial: branch vs. clone, and partial merges?" and all the suggestions seem to be extensions of varying complexity, from Record and Shelve to Queues.
The fact that there apparently isn't any core functionality for this makes me suspect that in some sense this working style is Doing It Wrong. What would a Mercurial-like solution to this use case look like?
Edited to add: git, by contrast, seems designed for this workflow: git add the bugfix files, don't git add anything else (or git reset HEAD anything you might have already added), git commit.
Here's how I would handle the case:
have a dev branch
have feature branches
have a personal branch
have a stable branch.
In your scenario, I would be committing frequently to my branch off the feature branch.
When the request came in, I would hg up -r XYZ where XYZ is the rev number that they are running, then branch a new feature branch off of that(or up branchname, whatever).
Perform work, then merge into the stable branch after the work is tested.
Switch back to my work and merge up from the top feature branch commit node, thus integrating the two streams of effort.
Lots of useful functionality for Mercurial is provided in the form of extensions -- don't be afraid to use them.
As for your question, record provides what you call partial commits (it allows you to select which hunks of changes you want to commit). On the other hand, shelve allows to temporarily make your working copy clean, while keeping the changes locally. Once you commit the bug fix, you can unshelve the changes and continue working.
The canonical way to go around this (i.e. using only core) would probably be to make a clone (note that local clones are cheap as hardlinks are created instead of copies).
You would clone the repository (i.e. create a bug-fix branch in SVN terms) and do the fix from there.
Alternatively if it really is a quick fix you can use the -I option on commit to explicitly check-in individual files.
Like any DVCS, branching is your friend. Branching a repository multiple ways is the bread and butter of these system. Here's a git model you might consider adopting that works quite well with Mercurial, also.
In addition to what Santa said about branching being your friend...
Small-granularity commits are your friend. Rather than making lots of code changes in a single commit, make each logically self-contained code change in its own commit. Then it will be a lot easier to cherry-pick changes to merge between branches.
Don't use Mercurial without using the Mq Extension (it comes pre-packaged in the default installation). In addition to solving your specific problem, it solves a lot of other general problems and really should be the default way that you work (especially if you're using an IDE that doesn't integrate directly with Hg, making switching branches on the fly a difficult way to work).
I've read a lot about Mercurial and branching in it, however, I am still very much a version control newbie.
I'm currently working on a project, where I have been tasked to work on a new module.
I have a "main" repository, which contains the latest code from the rest of the project, and a cloned repository (call it "task") where I am doing my work now.
I am a bunch of commits into my task, and find that I would like to do a little "experiment" with the way my program reads/stores/handles configuration data.
Now, if I understand VC best-practices correctly, this would be a great time to branch.
If I start into this experiment, and I like where it's going, I will want to merge it back into my "task" repository on the "default" branch pretty quickly.
On the other hand, if I don't like how it's going, I'll probably just scrap the branch.
The way I am most comfortable branching is through cloning, however I don't think this would be the best approach in this situation, as I'll only be changing a few files, but apparently using named branches is permanent, which doesn't seem appropriate here either.
What is your advice / best practice for this kind of situation?
I'm relatively new to Mercurial, but I know exactly the situation you are describing. I did some research on this before, and my conclusion was that the easiest way was to clone my repository.
See this answer for some more insight.
Also, this is a great guide to branching in Mercurial :)
Go with a clone, no doubt about it. A named branch in Mercurial is something that even the Mercurial folks say you don't need all that often. One of the beautiful things about DVCS is the fact that you can easily clone the repo and try some new and different things, and if they work, great, merge it back in to the main repo, otherwise, delete it all.
I personally use a "Branch By Feature" approach with Mercurial, which means that I will make a clone of my primary repo for each feature I'm working on. This includes spikes and experiments.
I need some opinions here.
I'm working on a Django project using buildout to get the dependencies, etc...
I use mercurial as DVCS.
Now... I need to customize one of the dependencies, so I can do one of the following:
(* The changes may not be useful for everyone else.)
1- Do a fork of the project in (github, bitbucket, etc...) maintain my version, and get the dependency with (mercurial or git) recipe.
2- Clone the project, put it in the PYTHONPATH, erase DVCS dirs and add it to my projects version. So every change will be private. Here I need to erase all the info from their DVCS or something.
Any other you can think of.
I'm missing something? I'm too off?
Thanks!
Esteban, take these steps: I'll talk in mercurial-speak, but this is all do able in git too.
clone their project
make your clone of their project a subrepo in your project
That gives you the best of all worlds. You can edit code in your project and their project without paying attention to which is which, and when you commit the changes to your code go into your repo along with a pointer to a new changeset in your clone of their project. Then when you want to update your clone of their project you can do so in place and merge simply.
So this is pretty much what you said in '1' but there's no need to do a fork or host that repo publically. Just edit their clone as a subrepo of your project and never push (which wouldn't work anyway since you don't have write access to their repo).
Your option two's primary drawback is that as they modify and improve their project on which you depend you'll have a hardtime pulling their improvements in and merging them with yours.
Well if you're using DVCS then all your commits are kept as change sets, and people can choose to apply your change set or not. So as long as you comment that change, people can choose apply the change or not as they see fit. What's more if they don't want that change, but want your other changes, they can pick and choose. So the truth is the DVCS takes care of the problem for you (provided the people pulling from you are using the DVCS properly).
Personally, I recommend forking, but like I said, it doesn't really matter.
You ask this question in a rather confusing way, and I don't know if you really understand the point of a DVCS.
The whole point of a DVCS is to allow you to have your own private repository. You do not need to publish your repository on github or bitbucket or any of those places unless you want to, but I certainly would not erase the DVCS information.
If the upstream project makes changes you do want in addition to your own private changes, you will have a devil of a time merging them unless you keep the DVCS information around.
Using Mercurial, you can include a project in yours by using the Mercurial subrepo feature.