Mercurial Tagging/Branching Strategy_问答_开发者

My current project is broken down into 3 parts: Website, Desktop Client, and a Plug-in for a third party program. We had started out originally with Subversion for our source control but decided to try Mercurial after reading Joel Spolsky's final post. Considering we haven't really used the majority of svn's potential before, we figured starting fresh with some basic ideas of how source control worked would make this transition easy.

However, after setting up our initial repository, we're lost as to how tagging and branching should work on a project like this.

Essentially, we're working on all 3 of these parts at the same time. We want a release to be a combination of the 3 parts. Currently we're working in one repository.

For the Plug-in part, we have the first iteration finished which we've been referring to as Plug-In v0.1. For the first official build of the other two parts, we'd also like to refer to them as Website v0.1 and Desktop Client v0.1. When all three parts are at v0.1, we'd like to have a Full Project v0.1.

Our problem is we're not sure how to manage all of this in the Hg repository. Would the best way to handle this be to create 3 separate repositories for the 3 stable versions 开发者_开发知识库and then 3 more repositories for the current developments? Currently we have this all in one repository. Should we do this in branches (are branches any different from cloning repositories?) and tags?

Any help is greatly appreciated.

I'd highly recommend Steve Losh's blog entry A Guide to Branching in Mercurial, where he describes several approaches to branching supported by Mercurial.

Using Mercurial's named branches feature is probably the closest match to branching with SVN.

It definitely sounds like you want seperate repos for the 3 parts, if you need to tie the 3 together in releases it may also be useful to have these 3 repositories be subrepos of an overall project repository.

You can keep them in one repository or separate the projects. For me, it would depend on how much of the code, if any, is shared between the applications. If code isn't shared between the components, use a different repository for each.

Separate repositories would allow you to easily tag each component with the version (v0.1) and then continue forward with development as needed. When you are ready to release a combined product, just pull from the desired tag for each repository and you'll get the full product release. If you have deliverables for the application that are not related to either of the three components, you can also create a repository for the combined product to keep that data. You can handle branching for each of the components through branches or cloned repositories.

If you keep the components in a single repository, it will still work but your tags and branches will get much messier. When the plug-in gets to v0.1, create a tag for that like "plug-in v0.1". Do the same thing for the desktop and web clients. Then when you want to release the product, you will need to pull from three different tags which has each component at v0.1.

I would opt for the separate repositories. The decision is more complicated if there is shared code but you could find ways to take your dependencies as libraries rather than code.

For your questions about branching, this article is a good guide to the different options and pros/cons.

Try using Joel's Tutorial on Mercurial. This might yield a bit more or how to use it. There really isn't a "Branching" as used in SVN and really, it might be a good idea to stop trying to use Mercurial as if it was SVN. Instead of Branching, you have your own local Repositories.