I have a rather big repository that I started when I was new to Hg.
Recently I learned that the "bookmark" environment is much more fitting for what I am doing compared to the "branches" I introduced.
Now:
Is there a way to convert branches into bookmarks?
As far as I know mercurial doesn't support this.
Nevertheless I would be very happy if there exists a workaround for that.
Thank you for your help!
Related
We are switching to Mercurial. We are have been using SVN for a number of years. I recall reading somewhere that Twitter only have two branches in their source control. A production branch and a dev branch. This I think will suit us because we offer a service and there is only one instance of it running and we control it completely so we dont have to worry about versions. Just bring able to do fixes for production and maybe merge that change into dev if the issue exists in the dev branch too.
Is this approach appropriate for Mercurial? Are there any hidden gotchas that we should be aware of? We plan do follow a more traditional layout with release branches for the one or two products that we have that we retail.
Yes, no gotchas. The most recognized branching model, for both Git and Mercurial, can be found here, which gives an outline of a more complexe structure than you are thinking of using.
And even when your environment continue to grow, mercurial will still be able to handle your changing needs.
Are there any hidden gotchas that we should be aware of?
Yes, they are, if you will have more than one simultaneous tasks in devel you'll get hardly readable and understandable history with a lot of anonymous branches in devel rather fast
Yes, Mercurial achieves fully your approach. May be the workflow you are proposing is this. The Mercurial code or the Python code are some examples of development with really few branches.
In Mercurial the default branch is used as default when cloning, so is usually used as the development branch. Other branches are used as feature or stable branches, but is up to you. Actually for not so long features and issues one may use bookmarks on the development branch.
And remember to commit often :)
my company is using mercurial and the client is using TFS. we need a 2 way sync process??
if there are some changes in TFS these should be reflected in mercurial and vice versa
need some solution
like if v made some batch process etc
thnx in advance
I have not seen anything about an hg-tfs process, but there is one for git (git-tfs)... Kinda hokey, but may provide an option in conjunction with hg-git.
You'd still have to write up some scripts and such to automate the communication between the servers.
Alternatively, maybe the git-tfs project could be a good starting place for a new hg-tfs project :)
We had to do a one-time conversion of a TFS repo into Mercurial, and didn't find any good way to do it. Initially we wanted to use [tfs2svn], and then hg convert the SVN repo.
Alas, tfs2svn isn't stable when it comes to complex renames and branching. I managed to convert a small repo that way, but had to write a custom tfs2hg utility to convert another repo, with 2 years worth of history.
If you find a solution, please post an answer.
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/
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.
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.