Difference between revisions of "Mercurial"From Globulation2
Revision as of 12:56, 21 August 2010
ContentsBrowsing Globulation Project Repository using Mercurial systemNOW a cross-platform software are available to get a powerful GUI -Graphical User Interface- it's call HgTurtoise More information there. You can Set HgTurtoise with the parameters below.HgTurtoise seems more complicated than broswing the web, but the Branch Graphic representation is exelent, and really a Must have on MS_Windows_O.S.
Getting a Copy of the Mercurial RepositoryNOTE: FEEL FREE TO VISIT THE MERCURY MAN PAGE ONLINE since it not available with all shell. Anonymous Mercurial AccessSee the Mercurial sources download instructions Pushing changes via HTTPSMember access is performed using the Mercurial over HTTPS method. Access can be given by providing User:Nct with a username and password by emailing him at stephane [at] magnenat [dot] net. When you have commited changes locally (hg commit --message="what you have changed"), you can push the changes to the server using: hg push -r branch https://hg.globulation2.org/glob2-new/ (change "-r branch" to the branch you wish to commit to, for example "-r default") Mercurial NewbiesIf you've never used Mercurial, you should read some documentation about it; a useful URL is http://www.selenic.com/mercurial/wiki/index.cgi/QuickStart. Using Mercurial is not complex but you have to understand what is going on. The best way to start is to ask a friend to show you the way, or pop onto the glob2 development IRC channel and ask there. A quick overview of MercurialBasically you have to know that there is not total order on a mercurial repository. Each revision except the initial revision has at least one parent. Different revisions can have the same parent(s). A revision will have more than one parent, if and only if it is a merge of those parents. If two or more revisions share a parent, we have infact different branches in the repository. The new mercurial feature allows to give a revision a sticky tag that is past to almost all its children. Exeptions are merges. If you merge branch A into branch B, this revision will belong to branch B. So when you merge the default branch into a development branch, the result will belong to the development branch. This is good because you can keep track of approved changes, during your development now and then.
Branches might have names, unless you give them a name.Their names don't have to be unique but it is strengthy recommended to don't use an already given name branch to another. So multiple branches were supported all the time. The new feature just allows to name them. You can put the branchname everywhere you can put a revision number. So all commands that have '-r' or '-rev' option accept a branchname too. Mercurial will then search the latest revision in that branch and path its number to the command. (At least that's what I think it does.)
If every branch (named or not) has the same "latest revision", our repository will have exactly 1 head. Otherwise we will have more heads and mercurial will suppose that we merge the heads. But most of the time this would be inappropriate, and we shouldn't do it. The latest revision is always called tip, and mercurial defaults to think that we want to work on it. This is also very sad, if it does belong to an other branch. I really recomment that you only pull the branch you want to use. You can do this, because the clone and pull commands have a '-r' option. I pull the whole repository on my computer and than pull the branches that I want to work on, from that local repository to different working repositories. I suggest everyone should do this. So there is one incoming repository, one or more working repository and one outgoing repository locally on my computer. Our "trunk" or default branch is called "default". You can try everything with mercurial locally before pushing to the remote repository. hg log hg diff hg branches hg heads hg tags hg incoming hg outgoing hg status are very helpful to get information. Try "hg help" for details. hg serve //and browsing to localhost:8000 is very good for a graphical overview of the repository structure. If you prefer using a GUI tool, go for Tortoise-HG. And you definitely have to set up a merge tool for those case when you have to merge manually. Branching of should look like this:
hg revert --all -r <revision from which you want to branch of> hg branch <branchname> hg commit -m "message"
Using -r/--rev (or 'clone src#rev dest') implies --pull, even for local source. repositories. hg clone -r <branchname> <location of the repository> <name that you want your repository to have>
'Ppulling is implicitly engage when -r option is set within the clone command. hg pull -r <branchname> <location of the repository> | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||