We are moving to Mercurial from Subversion. With Subversion, we have http://trunk.myproduct.com for testing purposes. I am wondering what the standard name for a trunk-like site is for Mercurial. 'trunk' seems like a Subversion term. http://default.myproduct.com is the most obvious name, but is that what people generally use? I am looking for the most standard convention.
I'm not sure there is a convention. People using Mercurial generally have more repositories.
I've seen a "central" repository named as bits.example.com, example.com/hg, example.com/branches/1.x, and so on.
Name it whatever you like - just make sure you have a standard convention for which changes go to which repository, and when.
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 :)
I like Mercurial Queues for its flexibility and agileness. However, for my personal use, I think it's awkward the patches are not true Mercurial changesets. Is there any plan for this extension to use true changesets? Or are there any alternatives that do so?
There is a very interesting Mercurial extension that will address some of these issues.
Mercurial Evolve provides a new approach to safe yet still mutable history, combining the flexibility of MQ with true Mercurial changesets.
They also have an interesting concept of "obsolete" changesets which can enhance collaboration between developers.
As of right now it is not in production use, but is making rapid progress in becoming an officially released extension for Mercurial.
There is also a fuller description of the roadmap available.
The user's guide gives multiple examples of typical uses.
And this MQ->evolve reference guide gives mappings from MQ commands to mercurial evolve commands.
As long as you're careful not to share history prematurely, you can do a lot with hg rebase: You can develop normally in a branch, rearrange and collapse groups of changesets, and finally graft them to the tip of your regular development (the branch name disappears, unless you ask rebase to keep it). You could also simply rearrange default, but playing around in a branch is closer to the mq model. I experimented with mq but switched to using rebase, and I've never looked back. It does everything I could wish for. (What you could wish for is a different question, but you don't say).
To support working with rebase, you can use mercurial phases to keep your changesets from leaking prematurely.
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'd like to evaluate Mercurial for my working projects. But most of my projects very heavily rely on the presence of svn:externals-like support. I've searched over StackOverflow and googled for corresponding support in Mercurial. All I found is subrepo feature added in Mercurial 1.3, but the page for this feature said:
subrepos are an experimental feature for Mercurial 1.3. So don't do this on mission critical repositories!
I don't want to use something unstable.
Can anybody shed some light on the real status of this feature, and the plans of polishing/finishing it and when it will be called "stable" and ready for mission critical repositories?
The word in the #mercurial IRC channel is that subrepos will continue to work as they do, and support will grow. For example currently the 'hg status' command isn't subrepo aware -- it works, it just doesn't recurse, but that in the future it will be. However, the current behaviors, fileformats (.hgsub and .hgsubstate) will only be changed in backward compatible ways.
So, go ahead and count on it now, and look forward to it getting better.
P.S. As of mercurial 1.4.2 the subrepos can now be subversion repos, so you can use a mercurial parent and a svn kid.
I've had good luck with the feature in my (light) usage of it so far. It's come in handy in two places:
Backing up a tree of unrelated repositories with a single hg pull command.
Tying a project together with specific versions of its dependencies, so that a single hg clone gets buildable source code. This is closer to the typical svn:externals usage.
Here are a couple of the limitations I've seen with it so far:
In case #1 above, you have to commit all subrepos at once. This is only occasionally annoying, as Mercurial (like any DVCS) encourages frequent commits—so most repos aren't left sitting around in an incomplete state to begin with.
Only the most basic Mercurial commands are subrepo-aware: clone, push / pull, update / commit, and perhaps a couple of others.
Extension authors are going to need time to test their extensions against repositories with subrepos.
When the Mercurial team describes the feature as "experimental," they don't mean that it's suddenly going to decide to erase all your data. They just mean that they haven't coded around all the edge cases like name conflicts (e.g., one developer adds a subrepo called README, while another developer adds a text file called README).
I'm looking at the mercurial handbook, chapter 6 "Working with multiple branches". In there the author states that if you have separate versions/branches of the same software that it makes sense in an implied obvious way to host each branch of the software in a separate repository.
I know that Mercurial supports tags (which is the way that branches are done in subversion AFAIK). Why would you use different repositories instead of tags for branch managing?
Mercurial's tags are not the same as Subversion's branches. In Subversion, making a branch creates a separate copy of the code (with hardlinks at least, I think) while tags in Mercurial just point to a specific commit.
A while ago I wrote about Mercurial's branching models (of which branching-with-clones is one of four options), maybe you'd find it useful?
There are advantages in having different repositories in Mercurial, and problem in handling branches.
Branches mean multiple heads, the graphs are much more complicated then, and even the graphical representation may not be able to accommodate so many convoluted paths... and I don't even talk about the human brain!
On the other hand, having multiple repositories mean that each repository will have a much simpler structure, therefore easing the brain trauma of having to deal with multiple branches/merges (that you have anyway, since two developers working from the same changeset and onward develop concurrently).
Furthermore, with multiple repositories, you can read/edit any file on a given repository easily with whatever editor you are using (if you maintain the working dir up to date relatively to the tip).
On subversion you HAVE to deal with multiple branches, there is no other way around, and you have to use tags.
On Mercurial, tags are not supposed to move (it needlessly introduce changesets) and branches are handled off-the-shelf: you always have branches. However, since you can have multiple repositories, you are offered another dimension. It is your choice whether you use it or not, it made my life easier anyway.