================================ Version Control using Hg Part 4 ================================ .. Prerequisites .. ------------- .. Version Control using Hg Part 1, 2, 3 .. Author : Primal Pappachan Internal Reviewer : Date: Jan 27, 2012 ====== Script ====== +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | *{{{ Show the first slide containing title, name of the production team along | Hello friends and welcome to the fourth part of tutorial on 'Version Control wit | | with the logo of MHRD}}}* | | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | *{{{Show the slide 'Prerequisite'}}}* | Please make sure that you have gone through the following tutorials before you | | | continue on this tutorial | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | *{{{Show the slide containing the objectives}}}* | At the end of this tutorial you will be able to | | | #. Clone existing repositories | | | #. Share your repositories with peers | | | #. use version control for collaborating with your peers | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | *{{{Show the slide 'Cloning Repositories'}}}* | When motivating the use of version control systems, we spoke a lot about | | | collaboration and sharing our changes with our peers. Let us now see how we can | | | share our project with our peers and collaborate with them. | | | | | | For this purpose let us create a central repository, a copy of our repository, | | | which is different from the one in which we are working. The clone command is | | | used to clone or replicate an existing repository. | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | ``$hg clone SOURCE [DEST]`` | The syntax of the clone command is -- hg clone SOURCE [DEST], where the | | | optional argument DEST is being represented in brackets. The clone command can | | ``$ hg clone book book-repo`` | be used to replicate already existing repositories, either on your own machine | | | or on some remote machine somewhere on the network. Since, hg maintains a copy | | | of the full repository with every copy of the repository, the two copies that | | | we have are exactly equivalent. | | | | | | In this example book-repo shall be our central repository we are sharing with | | | peers. | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | *{{{Show the slide 'Sharing Repositories'}}}* | A mercurial repository can be shared in multiple ways. We shall use the http | | | protocol to share the repository. Mercurial comes inbuilt with a tiny server | | | that can be used to share your repository over the network. To start sharing | | | the repository, we say | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | ``$cd ../book-repo`` | This will start serving the repository on the network on the port 8000. Anybody | | | | | ``$hg serve`` | | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | Open the url http://localhost:8000 in browser. | Now if your friend Primal wishes to clone the repository, use | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | ``$ hg clone http://my-ip-address:8000 book-primal`` | Now if Primal makes some changes to the repository and tries to commit it fails | | | obviously as access rights haven't been taken care of. | | | | | | By this process, we share a central repository; work on our local copies. It | | | doesn't make much sense to allow anybody to make changes to a public | | | repository, by default. We will need to make changes to the settings of the | | | repository to allow this. To set the write permissions, add the following lines | | | in .hg/hgrc | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | ``[web]`` | This will allow anybody to push to the repository, now. Primal can now push and | | | his changes will appear in the central repository. | | ``push_ssl=False`` | | | | | | ``allow_push=*`` | | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | *{{{Show the slide 'Sharing Changes'}}}* | Use hg push to push your commits (changesets) to the central repository. The | | | changes made by Primal will appear in the central repository. | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | ``$ hg push`` | Let us now pull these changes into our original repository that we have been | | | working with. | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | *{{{Show the slide 'Pulling Changes'}}}* | Before pulling the changes, we can use the command hg incoming to see the | | | changes that have been made to the repository after our last pull and the | | | changesets that will be coming into our repository after we do a pull. | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | ``$ hg incoming`` | To now pull these changes, we use the pull command. | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | ``$ hg pull`` | These changes do not affect our working directory. To see this, we could use | | | the hg parent command. | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | ``$ hg parent`` | As you can see, the parent is still our last commit, and the changes are still | | | not in your working directory. | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | *{{{Show the slide 'Pulling Changes'}}}* | To get these changes we do the update as suggested by hg. | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | ``$ hg update`` | As expected the update command updates the parent to the latest changes that we | | | just pulled from the remote repository. | | | | | | #. Updates to the tip if no revision is specified | | | #. tip is the most recently added changeset | | | #. Can specify revision number to update to | | | | | | For example | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | ``$ hg up -r1`` | hg tip shows the tip of the repository | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | ``$ hg tip`` | What happens when two users have made simultaneous changes to the same file, | | | by editing different parts at the same time. | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | *{{{Show the slide 'Simultaneous Changes'}}}* | With simultaneous changes, following things happen | | | #. The logs of both repositories will be different | | | #. The repositories have diverged | | | #. hg push fails, in such a scenario | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | ``$ hg push`` | Don't take the advice given by mercurial. Using the -f would be disastrous. We | | | will leave out a discussion of that, for this course. | | ``pushing to http://192.168.1.101:8000`` | | | | | | ``searching for changes`` | | | | | | ``abort: push creates new remote heads!`` | | | | | | ``(did you forget to merge? use push -f to force)`` | | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | *{{{Show the slide 'Merging'}}}* | We will now need to pull the new changes that have been pushed to the | | | repository after the last pull and merge them with the changes. | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | ``$ hg pull`` | We have now pull the changes from the central repository and merged them with | | | the changes in our repository. But, hg is warning us not to forget to commit. | | ``$ hg merge`` | | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | ``$ hg commit`` | We can now push this changes to the central repository. We could also check the | | | changes that will be pushed, before pushing them, using the hg outgoing | | | command. | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | ``$ hg outgoing`` | The changes have now been successfully pushed! Let us look at the web interface | | | of the repo, to see that the changes have actually taken place. | | ``$ hg push`` | | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | Show the Change graph in browser. | What will happen if we edited the same portion of the file, at the same time? | | | How would merges work? This will be the last thing that we are going to see in | | | this part of the spoken tutorial. | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | *{{{Show the slide 'Simultaneous Conflicting Changes'}}}* | Let's say both of us edit the same part of the same file. | | | #. hg push fails | | | #. So we first do hg pull | | | #. followed by hg merge | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | ``$ hg commit`` | What happens now actually depends on how Mercurial is configured and the | | | programs available in your machine. You will either get a diff view with 3 | | ``$ hg push`` | panes or merge will insert markers in your file at the points where the | | | conflicts occur. | | ``$ hg pull`` | | | | If you get a 3 pane view, the first pane is the actual file, where you make | | ``$ hg merge`` | changes, to resolve the conflicts. The second pane shows the changes that you | | | made, to the file. The last pane shows the changes that you pulled from the | | | original repo. Once you are satisfied with the changes, save and quit. | | | | | | Once you are done, you need to tell mercurial that you have resolved the | | | conflicts manually. | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | ``$ hg resolve -m filename`` | You will now need to commit your changes, just like the simple merge that we per | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | ``$ hg commit -m "Merge heads."`` | We could look at the graph of the changes, in our web interface, which makes | | | clear how the merging has occurred. | | ``$ hg push`` | | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | Show the change graph in browser. | Here's an advice on the Work-flow to be followed. | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | *{{{Show the slide 'Advice: Work-flow}}}* | That brings us to the end of this tutorial on Mercurial. What we have covered | | | is nothing close to all the features of Mercurial. We've only scratched the | | | surface, but let's hope that this will get you started and you will be able to | | | organize your work and projects, better. | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | *{{{Show the 'summary' slide'}}}* | | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | | In this tutorial, we have learnt to, | | | | | | #. Clone repositories, using hg clone, | | | #. Serve our repositories via http using hg serve, | | | #. push changes to a repository using hg push, | | | #. check the changesets in a repository after last pull, using hg incoming, | | | #. pull changes from a repository using hg pull , | | | #. update the working directory, using hg update, | | | #. merge two heads, using hg merge, | | | #. and resolve conflicts using hg resolve. | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | *{{{Show the slide 'Evaluation'}}}* | Here are some self assessment questions for you to solve | | | #. Mention the easiest way to get started on sharing your repository by providi | | | #. Suppose Joey and Melissa have made simultaneous changes to the same file in | | | #. What are the commands involved in the process of merging changes? | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | *{{{ Show Solution of self assessment questions on slide }}}* | And the answers, | | | | | | #. hg serve | | | #. No, whenever we've done a merge, hg parents will display two parents until w | | | #. hg pull, hg merge, hg commit -m "Merged Remote changes" | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | *{{{Show the slide 'Additional Reading'}}}* | It is strongly recommended that you to go through the following topics, once | | | you are comfortable with using Mercurial on a day-to-day basis. | | | | | | #. .hgignore | | | #. hg rollback | | | #. hg bisect | | | #. hg backout | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ | {{{ Show the Thank you slide }}} | Hope you have enjoyed this tutorial and found it useful. Feel free to play | | | around with Mercurial and read the documentation given by hg help command. When | | | you are ready to move on, please proceed to the third tutorial on 'Version | | | Control using Hg' | | | | | | Thank you! | +----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+