diff options
Diffstat (limited to 'Version_Control/vcs4/vcs4_rec.rst')
| -rw-r--r-- | Version_Control/vcs4/vcs4_rec.rst | 215 |
1 files changed, 215 insertions, 0 deletions
diff --git a/Version_Control/vcs4/vcs4_rec.rst b/Version_Control/vcs4/vcs4_rec.rst new file mode 100644 index 0000000..8efd4f4 --- /dev/null +++ b/Version_Control/vcs4/vcs4_rec.rst @@ -0,0 +1,215 @@ + +================================ +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! | ++----------------------------------------------------------------------------------+----------------------------------------------------------------------------------+ |