tags:

views:

237

answers:

3

I have just switched from svn to mercurial and have read some tutorials about it.
I've still got some confusions that i hope you could help me to sort out.
I wonder if I have understood the folder structure in a mercurial repo right.
In a svn repo I usually have these folders:

svn:

branches (branches/chat, branches/new_login etc)
tags (version1.0, version2.0 etc)
sandbox
trunk

Should a branch actually be another clone of the original/central repo in mercurial?
it seemed like that when I read the manual.

And a tag is just a named identifier, but you should clone the original/central repo whenever you want to create a tag?

How about the sandbox? should that be another clone too?

So basically you just have in a repo all the folders/files that you would have in the trunk folder?

mercurial:

central repo: projects folders/files (not in any parentfolder)
tag repo: cloned from central repo at a given moment for release 
  (version1.0, version2.0 etc)
branch repo: cloned from central repo for adding features (chat, new_login etc)
sandbox repo: experimental repo (could be pushed to central repo, or just deleted)

is this correct?

+2  A: 

I'm not totally sure that I'm understanding all your questions, I think you're just confused a bit with some of the terminology, but I'll take a stab at them.

Should a branch actually be another clone of the original/central repo in mercurial?

Yes, a branch is just a clone that starts at a particular revision. If you make different changes in one clone, that's basically when it becomes a "branch" as compared to a "clone".

And a tag is just a named identifier, but you should clone the original/central repo whenever you want to create a tag?

A tag is just a more human-friendly way to remember a particular revision, a certain point in the repository's history. You can tag something as "version 0.8" so that you don't have to remember that you released version 0.8 at revision 427. There's no reason to make a clone as part of this, unless you need a branch (say, to integrate a bugfix for people running version 0.8, without releasing your trunk code to them as well). You can always make the clone later from the tag if it becomes necessary, you don't have to do it at the time of creation.

How about the sandbox? should that be another clone too?

Assuming "sandbox" is just "somewhere for me to play around", that's just a branch. So originally, it's a clone, yes.

So basically you just have in a repo all the folders/files that you would have in the trunk folder?

Yes, all these other concepts of branches, "sandbox", etc are all handled by features of Mercurial, not files like you had to use in subversion.

Did you read The Mercurial Book? I found it very helpful in picking up the concepts.

Chad Birch
yes i've skimmed through it very quickly. they talked a lot about different commands which i find helpful, however i tend to use GUI for handling the merge, clone etc. right now im using Netbeans and Bitbucket and it works great!
never_had_a_name
+4  A: 

The main thing to remember is that branches are no longer directories in a DVCS like Mercurial (or Git).

Mercurial offers 4 branch models (details in this SO question and in this article):

  • clone
  • bookmark
  • named branch
  • anonymous branch

The ConvertExtension uses by default named branch (but you have option to use cloned or tagged branches)

Try out some SVN to Mercurial Conversion cases, and see what works best in your case.
Once a SVN repo has been imported in one Mercurial repo (with named branches in it), you still can clone whatever branch you need in a separate repo:

hg clone -r <branch-head-rev> <repo> <new-repo>
VonC
+1  A: 

There are four modes of branching in mercurial: anonymous, clone, named, and (with extension) bookmark.

Depending on what you want to do (start parallel feature development, experimenting in a sandbox, etc) you would choose one or another. Mercurial itself does not impose any one method or workflow and just provides the mechanisms for you to choose from.

This article explains it a whole lot better. It made it clearer for me.

Santa