 Hello, welcome back. Sorry for the delay. Let us get back to where we were at. What we had was, we had, if you go back to this picture, we had division 12 after which we made some changes and we pulled from A the set of changes from B and these were conflicting changes that is A had made changes as had B. Now, as soon as I did the merge, I had to merge to make this together, to merge these two divergent pieces of code, it gave me this little ui which tells me the left pane that you see here is the final file. So, I make changes to this. This will be the final version. The thing is A now has to decide saying, oh, this is the version that is needed and since this is A's repository, he can do anything he wants. So, let us, let us fix this. I have decided to say, I want to retain mine. A's original version was this, B's version was this. So, what I am doing now is, I will say, okay, I will retain the version that has been merged in this page. So, what I will do is, I will hit escape, queue and quit that. Let us look at the merged version. It has the version that I had saved. So, I say hg check in minus m merging from B. Now, if I look at again hg serve, I look at log, the head here and I look at the graph. Notice again that at this point, both of these had diverged and I have merged. So, the same thing is happening over and over again. In one case, there were two different files. Therefore, I did not have to go through that editor interface and manually edit the file. But in this case, both of us had changed the same file. So, if there are edits across different files, they will be merged automatically. But edits to the same file will have to be manually merged by the developer. I finished that, saved it, committed and everything is back. The only thing is, you have to remember, let us see what B looks like. B is still stuck at remove goodbye. It has not been merged. So, what I have to do with B is, I can now do hg pull minus u and now I no longer have to deal with this conflict worth business because A has already taken care of everything. So, hg is smart enough to realize upstream there was a divergence. The two are converged back using the merge operation and therefore, I do not have to do anything new. Everything is fine. So, now if I look at hg serve, go back to the log, get the graph, we are both at the same point. So, in short, this is the essence of merging. If we go back to the slides, so far what I have done is I have shown you how to do it using pull. So, I keep pulling, I merge and I pull from the other fellow. If I were to push, sometimes I make a change, somebody else makes a change. I push to a common server. The other person also pushes, then you will have a, when you push, it will say I cannot push because that fellow has made conflicting changes. So, then what you must do is, so you have three things. So, now let us consider this another scenario. So, let us say I have a server here and the server is a full-fledged repository. Now, A makes, A pulls from here. So, A has a version here. B also clones, B has a version. Now let us assume that the revision number is say some 10. So, now B is at 10, A is at 10. Now, A makes some changes and goes to 11. Now, A does a hg push. So, this is a hg pull minus u. Now, A does a push to the server and so the server is also at revision 11. Now, B also has made some changes locally. So, let us say B now goes to B colon 11. Now, B wants to push. So, if B tries to push, you will get an error. You cannot do a push. So, A does a push. Why? Because that fellow has gone to some other point. Why? Because B's origin was 10 and B is pushing all of its chain sets to A to server assuming that it is at the tip. A is not, server is now gone to some other point 11. Now, there may be conflicts, there may be changes. Who knows, God knows what will be happening. So, you saw the number of issues we had. We had to merge if they are the same file that is being edited. So, supposing A has made changes to the same file, B has made changes to the same file, then if B is going to push, which one is going to win? It is not obvious. So, in this situation, your hg push is going to fail and therefore, what B will have to do is, B will have to basically pull hg pull minus u to get server 11 and this will be two lines. So, B will have to do a merge, resolve any conflicts. So, then produce a unified and then B can push it back into this. B has to do a merge and the hg commit. Is this clear? So, I will repeat the steps. Server is there. A and B make clones. They are identical. They are all at revision 10. A goes to A11. A pushes. Server now has 11. B also has gone to B11, which is different from A11. Now, B tries to push. This whole operation fails. So, what is the solution? B now pulls hg pull minus u to generate servers 11 inside, which is going to diverge the heads 11. Now, you merge B11 and servers 11 using hg merge. Commit that to form B12. B12 is then pushed back to hg, via hg pushback and that will become 12. And now, hg, when A pulls, A will pull the version back. So, in fact, what will happen is, this will be called B11. Server 11 will be called 12. This will actually become revision number 13. So, I will maybe change that to 13. This will become 13. And this B11 will be somewhere inside here. You will see two branches. One will be there. The other will be there. They will all appear. Everything will appear. 13 will be there and A can now pull and A will also go to 13. Is this clear? So, basically, when you are working collaboratively, things can get a little more complicated and one has to be careful and make sure one updates properly and merges properly. But essentially, it is very simple. The advantage of doing this is it makes it very easy to collaborate with multiple number of people. So, if there are five people developing, it scales. A, B, C and D, let us say, are working. Each of them makes their changes. They push, they pull, they merge and then everybody pulls and everybody works at different times. So, ultimately it will work out. The other thing is, as developers you will always decide saying, hey, I am going to work on this, I am going to work on this. Because we are working on the same files, somebody will have to do the conflict merging and that fellow will shout at you. Why are you editing my files? I am supposed to be working on this. So, there is also some element of collaboration that involves communication between the developers. It cannot be done in isolation of that. HG only gives you the tools such that even if there is a bifurcation, there is a divergence, you are able to bring it back using merging. But still somebody has to does a manual merge. That is a process that requires to be done. Now, there is one step. If you read the HG push documentation, there is a push minus F. Do not use it. Do not ever use it unless you know exactly what you are doing. Never, never, ever use HG push minus F. What this will do is it will force the changes and that can be disastrous. So, do not do it. If you know what you are doing, your personal repository, you want to do something crazy, you can do it. But if not, do not do it. Bad idea. So, this is what we have discussed so far. We have discussed pulling and merging. If you are also pushing, if you push something which creates new heads, if you are not merged and you have pushed, it will create two heads, it will not allow you to push. So, therefore you have to do a merge, do a commit and then push it back. I have shown you a clear example of how to do that. And these are also things outgoing have not shown you. Outgoing will like incoming, HG outgoing will tell you what are the changes that are going to be pushed if you are going to send it to a server. And looking at the change graph is often very illuminative, especially if you have multiple developers. The branch will start going crazy and then once you start looking at it visually, it helps a lot. Again, this is again something I have demonstrated. When a HG push or a HG pull fails and you have conflicts, you will get a diff view with three panes. First is the current file. Second is the change sets that you have pulled. Third is the file before you made your changes. What I did was, I resolved all of the conflicts, saved it, then did a commit and a push. So, I will leave you with some basic advice. The general workflow when you are working in a multi-user, multi-developer project is first before you start making the changes for the day, you pull and update. Do not forget to update. Remember I made the same mistake. Do not forget to update. First you do a pull or you do a pull minus you. Update all the changes. Make all your changes locally. Commit. Make sure you commit because commits are the most important element of all of your work. And you can make multiple commits. No problem. Remember that merging, I only demonstrated with a single commit. But you can make multiple commits and still merge it. No problem. It will still work. The same idea, the same workflow. So, you make commits. If there are changes on the repository, you pull again from the repository. What happened in the second case that I demonstrated in my picture over here? B made changes. So, before you push, a good idea would be to basically pull. If there are changes upstream, pull it. Finish the merge. If not, you will have to do the same process. You push it there and say, oh, I cannot push. Instead you pull, check the changes, merge. If they are unnecessary, push. And the idea is you commit early, commit often. If you now wait for one year before you make your merging, it is too late. There will be too many change sets for you to merge. So, I will repeat this. Pull and update first. Make your changes. Commit. If there are any changes to the repository, pull and merge internally. Merge the change sets, push, back, upstream. And this way everybody can stay on sync. And you can collaboratively work with multiple number of developers. And remember to commit early and commit often. Make sure that you are making commits with reasonable, meaningful commit logs. Remember the advice given about commit logs, the first line should be a summary within about 60 characters. Subsequently, you write a paragraph about what the commit is, what changes, unless it is a trivial commit or you are just playing around like I am doing right now. So, somebody is asking some question before I summarize. In case of push from A to B, only log of A will change. What about data of A? I think you have gotten your facts wrong. When I push from A to B, log of A will not change. Log of B will change and the data of B will also change. Nothing will, A is intact. When I push, I keep my thing intact and I change that fellow. When I pull, I am pulling, that fellow is intact and I am getting the changes from him into me. And when I pull, everything comes in. All of the change sets that from the destination, whatever, what from the source, whatever changes are there will come into me. It will change everything. So, I will summarize quickly. So, we have learnt several commands in this over the course of the day. We have initialized new repositories using HG init. We have checked the status using status. You can get help using HG help or HG help command. HG commit to make snapshots and that is probably the most frequently used command, HG commit, which is why you use an alias HGCI. HG log to check the log, editing the global HGRC file on tilde slash dot HGRC, HG revert, HG diff, HG remove, HG add, HG remove, HG add. There are several things I did. HG move, HG RM, then HG parent, HG tip, HG clone. So, HG clone, HG serve, HG push, HG pull, update, merge. There is also something called resolve. So, supposing that three-payend editor did not come when you merge. There is a conflict. It will basically say I do not could not find a mechanism to merge. Ask you to manually edit the files, manually edit those files and then you type HG resolve and commit. That is another pattern. So, there are several references. I think these slides are shared with you. You can look at variety of these. There is various documents all available online, free resources. By now, you should have a rough understanding but a pretty good understanding of what is happening. There are lots of additional features. I obviously cannot get into every single feature. But what I have tried to do is give you an essence of the most important aspects that is creating repository, adding files, removing files, modifying files, checking in your code or your data, adding new data, removing stuff, reorganizing a directory, cloning it, sharing between two different clones, pushing to a server, pulling from a server. Then how do you deal with different sets of changes between one fellow and another fellow? So, two people have made conflicting changes, merging, resolving any merge conflicts, committing, pushing back. So, ultimately what you really need to remember is init, add, commit, status, diff, log, those are all easy ones. Pull, push, merge, update. Yes, update is very important, HG update. So, with this I think about 10 commands. In fact, of these 10 bulk of the time you will only be doing commit, commit, commit, commit is what you will be doing. Occasionally you will have the add. Infrequently depending on your use case you will either be pushing or not. So, but with this the idea is you can use this for any kind of workflow. You can use it for your own personal files, you can use it for distributed development between a bunch of people. So, it is a very powerful tool and as you have seen it is actually very easy. If you forget about all of the merging part, the merging part was the most complicated part today. The basic part is so simple, init, add, commit. That is all you need. And it works on any directory. So, you do not have to worry about I have to set up a server none of that. You simply have to create a directory and that directory can be worked. And you want to make a copy clone. There is one concept I have not dealt into which is called branches. But I think this is enough for now. If you read any of the documents that are available online they will go into detailed into branching. Branch is basically you are making a named sequence of changes that diverge from the original main. So, you can independently maintain branches which represent say a stable version of your software. But I do not want to get into the details of branches right now. I think the idea here is to give you a start, a beginner's idea and with this you should be able to read the basic documentation to get ahead and read up more on branching and other things, other advanced features. So, we will stop the session, this session on version control now. I will answer some questions for 15 minutes. First question is I do not want to track my file always. How to do that? Do not track it. It will just give you a question mark every time. So, supposing you have let us say, notice that there is this file called test.pyc. I do not want that file. I can create this additional file called hgignore. Each version control has its own syntax. So, I am used to hg. So, you need to tell it what syntax to use syntax colon glob which means it is going to use star.pyc as a globbing syntax. So, it will say anything with matching.pyc will be ignored. If I add this, I am sorry, just give me typo syntas. Syntax colon glob pyc. Now, notice that pyc file is ignored and it will be ignored. So, I am going to write this and the hgignore has to be tracked. So, I need to say hgadd.hgignore, hgcheck in. So, now if you notice the hg.pyc file is ignored. So, be careful about using ignore simply because you may accidentally ignore files you do not want. When we push or pull from SRC to desk, the update files are not reflected. MES, PNP, your question is when we push or pull from a SRC to a desk, the updated files are not reflected. Well, what happens is when you do a pull, unless you do a fresh update, a pull is not going to clobber your existing files. A pull is going to get all the changes, store it internally and only when you do an update, is it actually going to bring those files for you. So, the point is that is to prevent you from destroying your files, your existing files because if I pull and do an automatic update, it will overwrite existing things that you have. So, the idea is you do not want to forcibly update in case you do not want to do it. And so, if you are doing a pull, the idea is you explicitly ask for an update after you do the pull and each version control tool does it differently. For example, when you use git, git pull will actually overwrite, it will not care. There is some other command called git fetch which will do what is equivalent to git pull in, sorry, git fetch is equivalent to HG pull basically. There is a question from DOESC Srinagar. I think it is more efficient if you are able to question. So, my question is after doing the HG clone, I am able to pull the changes from the clone, but when I push the changes, so it gives me an error that your HTTP repository cannot be locked. So, I have included those permission entries inside my configuration file dot hgrc, but still it is not allowing me to push the clone changes. So, you are saying you have started the server, you have added the permission lines on the server and you are pushing from a clone, is that correct? Yes, I am able to pull, but I am not able to push. Did you restart your server after adding the permissions to your hgrc? You may have to restart your server. The second thing is I would suggest, yeah, you should restart your server. The other thing is it is a better idea to is that it is better to use pull as much as possible. So, if you keep, if you do not have a tool that manages your repository for you, HG serve is meant for, I think, I do not think it is meant for production. It is not a production server. It is an internal server that they have written for your convenience. If you are trying to use this on a large basis, it is better to invest in some other tool that does the hosting for HG, for Mercury. There are many such tools. I think Bitbucket is one of them. There are also other tools I would imagine that will allow you to post a version control repository. But it is a good idea if you are going to do it internally to allow people, tell people that they should pull and have one person who is responsible who will keep up to date a master server. That is you have one master server which one person is in charge of. He can pull from other people, merge it into the main master repository and make that master repository available. That way you eliminate the need to add everybody's permissions to push. That is one way of getting around this problem. However, if you are able to set the permissions then and restart the server it should work. But my pull does not create new heads and I am not able to perform the merge. Whereas push does create new heads and you can actually merge the files then. No, push is not going to create new heads and merge. Push in fact will bomb. It will tell you sorry I cannot. What you will have to do is you will have to pull, merge and then push back. You have no choice. We went through that whole example. If you push and it is going to create new heads it will not allow you to push. It will give you an error. So you will have to pull from the upstream server, merge it locally and then push it back. Only then will it allow you to push it. Thank you for your question. I will look at other questions on the chat session. So for removing files I think we went through this example once. So let me try something. So hgrm let us say new.sh. Someone is asking me how an example of removing. If I do hgrm new.sh let me just do it. Or why do I do this? I will make a clone. I have 19 versions. So now I am going to say hgrm new.sh, hg status, hg commit minus m removing done. There is an example of hgremove.