Upload
minty
View
43
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Revision Control with TortoiseHg. Team version. (Team use). CS2103 – Software Engineering. Prepared by: Steve Teo (past tutor) Contributors: Tong Huu Khiem (current tutor). Before we begin…. Red, bold text are important things. Notes clarify things and provides more in-depth knowledge. - PowerPoint PPT Presentation
Citation preview
Revision Control with TortoiseHg
(Team use)
Team version
Prepared by: Steve Teo (past tutor)Contributors: Tong Huu Khiem (current tutor)
CS2103 – Software Engineering
Slide 2
Before we begin…
These gray boxes have notes inside
Red box means instructions.Follow them.
Red, bold text are important things.
Notes clarify things and provides more in-depth knowledge
These instructions is tested with version 2.4.2 of TortoiseHg
Except the titles, of course
Slide 3
Moving on from individual use…• Version control is important for an individual developer.• Regular revision control helps a developer manage his/her code,
increasing productivity.• The Mercurial Revision Control System offers the advantage of
having a local repository With a local repository, commits and other repository operations can be
done offline at any time. Developers, especially those who have used RCSs such as Subversion
(which lacks the local repository feature), will find regular versioning with Mercurial a joy, not chore.
• However, you have yet to fully utilize the capabilities of a Revision Control System if you’re using it alone.
Slide 4
… to team use of a RCS• RCS is used to manage the codebase of software development
projects (which consists of teams of developers) in the industry, making it crucial to learn how to use it properly now.
• The Mercurial Revision Control System is fully capable of supporting team projects.
• Adopting a RCS for team use requires the establishment of a workflow and making sure team members follow it.
• In this first part, we shall learn a workflow to get a good grasp of it before proceeding with the practical itself.
Slide 5
Objectives• Learn the Central Repository Model
Role of the team’s centralized repository Basic team workflow
• Putting everything into practice Setup a Google Code Repository Checkout a remote repository Sync a local repository with a remote repo Configure username for identity purpose Push changesets Pull-Update changesets Merge changesets Resolve merge conflict
• Unleash Mercurial’s full power
Central Repository Model
Slide 7
The missing link• Every team member will have their own local repository.
However, there is no mechanism yet to share code changes with one another.
Team Leader
Team Leader’s
Local Repo
Member C
Member C’s Local Repo
Member A
Member A’s Local Repo
Member B
Member B’s Local Repo
Slide 8
• In the Central Repository Model, there is a central (remote) repository owned by the team
• Team members download (‘pull’) and upload (‘push’) changes between their own local repositories and the central repository.
• A team member’s local repository cannot share changes directly with other members’ local repositories.
• Developers can choose to push their changes to the central repository only when they are confident of their changes.
• Thus, it is not guaranteed that the central repository will always have the latest code.
• However, it is expected to contain the latest stable code.
Central Repository Model
Slide 9
Team’s Central Repo
Team Leader
Leader’s Local Repo
Member C Member C’s Local Repo
Member AMember A’s Local Repo
Member BMember B’s Local Repo
Central Repository Model
Basic team workflow
Slide 11
Push• Update your changes from the local repo to a remote repo
Member A’s Local Repo
Team’s Central Repo
push changes
Slide 12
Revision/changeset• A revision is the set of changes whenever a push is
performed. Each revision is given a number. A revision is also known as a changeset. In this tutorial, we will use both terms interchangeably.
• A revision contains other important information such as the author of the changes and the summary of each change.
• Each successful commit will result in a new revision.• Each revision will definitely have one or more revision for
its parent except for the first revision, which will have zero.
Slide 13
Pull• Retrieve new changes from the remote repo to your local repo
Member A’s Local Repo
Team’s Central Repo
pull changes
Slide 14
Update/Merge• Pulling changes only retrieves changes from the remote
repository into the local repository. However, the working copy is not updated in a Pull operation.
• You need to update the working copy to the latest version by using the Update command. If there are multiple heads (i.e. same file modified by multiple persons), you need to use the merge command instead.
updateMember A’s Local RepoMember A’s
Working Copy
Slide 15
• There are a few ways of doing a pull and update in one shot.• In Step 3 of “Putting everything into practice”, we will
show you how you can set up such behavior using TortoiseHg itself.
• For the command line gurus, you can use the hg fetch command to do pull and update in one shot (need to enable the fetch extension first).
15
Pull+update?
Slide 16
Pulling and pushing (Diagram)
16
Member B Member B’s Local Repo
Member A Member A’s Local Repo
2. push changes3. Te
lls h
im to
pul
l
1. makes some changes and commit
Team’s CentralRe
po
4. pull and merge
Slide 17
• In the above model, Member A commits some changes and pushes them to the Central Repository.
• Member A then informs the team to pull his changes off the Central Repository. Member B decides to do so and merges the changes from the Central Repository into his own repository.
• If any other member wishes to have the latest stable code, all they have to do is to pull off the Central Repository.
17
Pulling & pushing (explanation)
Putting everything to practice
Setup a Google Code RepositoryStep 1
Slide 20
Setup a Google Code Repository• In this guide, we shall use the excellent open source hosting site
Google Code as an example. However, note that your code will be available for checkout by anyone.
• There are other Mercurial repository-hosting sites such as BitBucket at https://bitbucket.org/, which offers free private repositories as long as access to the repository is kept to 5 users.
Note for CS2103/T students: Your project tutor will set up the Google Code account for you. Instructions under step 1 are for your information only. But you should follow from Step 2 onwards.
Slide 21
Setup a Google Code RepositorySign up for a new project at http://code.google.com/hosting/
Choose Mercurial as your version control system
Slide 22
Go to Source tab -> Checkout
Remember to note down the repository URL
Take note of your repository URL
Access your password
Setup a Google Code Repository
Slide 23
Remember of your googlecode.com password, too
You need this password to push changeset to Google Code
You can access all the project you have here
Setup a Google Code Repository
Slide 24
Browse the code in your repository by going to Source tab-> Browse
Setup a Google Code repository
Files will shows up as you commit code
Slide 25
View all the changes in your project by going to Source tab-> Browse
A commit graph will shows up as you commit code
Setup a Google Code repository
Slide 26
Add your team members as Owners under the Administer tab -> Sharing
Emails of your team members go here
Setup a Google Code repository
Slide 27
Remember to create a Google group for your team and add it to the activity notification under Administer tab-> Source
Add your team’s google group email here
Setup a Google Code repository
Step 2Clone a repository
Slide 29
If you already have an existing repository of the project on Google Code (set up by one of your team members), you can clone it from the Google Code repository to your hard disk. Otherwise, skip to Step 3
Right-click on a new folder and select TortoiseHg - Clone
Clone a repository
Slide 30
Cloning allows you to duplicate the entire repository, copying all the existing contents to the destination as well as the whole revision history.
Paste the Google Code repo URL here. This slide explains where to find the Google code repo URL.
Clone a repository
Step 3Sync a local repositorywith a remote repo
Slide 32
If you have an existing local repository, you can also configure it to sync with the repo on Google Code
Click Synchronize
Sync a local repository with a remote repo
Slide 33
Choose https
Use the relative URL
Use “code.google.com”
Use “default” for alias
Add the Google Code repository URL as the default path
Sync a local repository with a remote repo
Save
Slide 34
You can also configure Post-Pull behavior for repositories
Select Post Pull
Update option will make TortoiseHg automatically update your repository whenever you pull some change
Sync a local repository with a remote repo
Step 4Configure username for accountability
Slide 36
In a team setting, you need to establish an identity so that you and your teammates know what you guys committed
Configure username for accountability
Select a repository and choose Repository Settings
Slide 37
Unser Commit group, enter the username & email that you want to associate your commits with
Use “name <email>” here
Configure username for accountability
Slide 38
You can also set the username in the global settings. If there are no repository-specific settings specified, Mercurial will use the global settings.
This affects every repository on your computer
Configure username for accountability
Slide 39
From now on, your name will show up in subsequent commitsThis commit username can be different from your Google Code username
Commits now have the author which you have just specified
Configure username for accountability
Step 5Push changeset
Slide 41
After making some commits to our local repository, we are ready to push all of them into our Central Repository for the first time.
Right click on your local repo and choose Hg Workbench
Push changesets
Slide 42
In Hg Workbench, we will first preview the commits that are to be pushed.
Click Detect outgoing changes. This will compare the local and
remote repository, finding changes to be pushed
Push changesets
Click here to preview which changes will be going to the repo
Slide 43
These are the changes that is going to be pushed
Click Push to upload these to Google Code
TortoiseHg will find all the changes that need to be pushed
Push changesets
Slide 44
Then you will need to authenticate TortoiseHg to reach your Google code repository
Enter your Google code username
Push changesets
Slide 45
And your Google code password, as well. This is not your Google password. This slide explains where to get this password.
Push changesets
Enter your Google Code password
Slide 46
If the commits are pushed successfully, there will be no errors. You can look at the output log for more info in any case.
Push changesets
Success
Slide 47
You can also do a quick verification of the success of your commits by detecting changes for pushing again
Push changesets
Click here
This directly push changes, without checking. Not
recommended for now
Your commit was pushed
Slide 48
Push changesetsGo to your Google code repository, check the Source tab-> Changes
You should see that your commits were pushed successfully here
Slide 49
If you find it a chore to enter your login details every time you push changes or pull from a private repository which you have pull access from, you can store your login details using TortoiseHg.
Push changesets
Click “Synchronize” to open the sync panel at the bottom
Click on the lock to open the security panel
Key in your Google account details
Step 6Pull & Update changeset
Slide 51
Let’s say Greg have pushed his code. Now his friend, Holly decides to pull the changes into her currently empty local repository.
Pull & update changes
Again, open Hg Workbench
Slide 52
In Hg Workbench, you can check for new changes from repository
Pull & update changes
Check for changes from Google Code
Slide 53
When new changes are detected, you can accept and download them
Pull & update changes
Click to download changes below
Slide 54
The changes have been pulled into the local repository. However, we still need to update the working copy to the latest changes.
Pull & update changes
This means there are changes that is more up-to-date (2 and 3). You will need to update
Slide 55
You can update in Hg Workbench or right-click on the repository and use the popup menu
Pull & update changes
Click Update to open the update dialog
Slide 56
Use the default option to update to the latest changes
Pull & update changes
Slide 57
Once updated, everything is fine again. No more error message
Pull & update changes
Slide 58
• Finding it so troublesome to pull and then update? You can configure TortoiseHg to update for you by simply configuring the Post-Pull behavior as listed in Step 3: Sync a local repository with a remote repo
• Summary: Pulling only pulls the changesets into the local repository. You still need to update the working copy with the new changesets. Keep repeating this to yourself: Pull and Update
Pull & Update changes
Step 7Merge changesets
Slide 60
Merge changesets• You may encounter this common scenario
Greg pushed his code to the repository. Then Holly & Rowley pulled and updated Greg’s code. Rowley then made some changes, committed and pushed them. Meanwhile, Holly also made her own changes and was about to push the code.
• This can be summarized in the following timeline
Slide 61
Merge changeset
Greg
Holly
Rowley
Pushed
Pulled & Updated Commit new code
Pushed
Try to push
Commit new codePulled & Updated
time
Team Repository (Google Code)
Slide 62
In this situation, Rowley can’t push. He must merge his changes with Holly’sThis is how Google Code look like after Rowley has pushed his code
Merge changesets
Slide 63
Here, Holly check her code and detected one that need to be pushed
Merge changesets
Slide 64
When she push, however, there was an error. This is because she needs to pull Rowley’s code first
Merge changesets
Slide 65
Holly proceeds to pull Rowley’s code, seeing one changeset
Merge changesets
Slide 66
After Holly have pulled Rowley’s code, the repository look like thisNow, she need to merge her changes (4) with Rowley’s (5)
Merge changesets
The newly pulled changeset
Slide 67
Holly first select Rowley’s change and proceed with the merge
Merge changesets
Use Merge with local… to merge the new incoming changesets with yours
Slide 68
A summary of the upcoming merge is displayed on the 1st step of the merging process.
Merge changesets
Slide 69
Mercurial proceeds to merge and the merge results are shown on the 2nd step of the merging process.
Merge changesets
Slide 70
The process of Merging must be finalized with a commit to save the merge on the 3rd step of the merging process.
Merge changesets
Slide 71
The merge is done. Holly will now need to push the finalized merge commit back to the repository on Google Code
Merge changesets
The commit for the merge
Slide 72
The merge commit and Holly’s own commits earlier are marked for pushing
Merge changesets
Slide 73
And then they’re pushed to the remote repository
Merge changesets
Slide 74
• Has this whole section been mind-boggling? Remember, the goal of merging is to combine changes between changesets. Once the merge is complete, it has to be committed and then pushed back to the remote repository.
• Summary of merging steps : Pull the incoming changesets from the remote repository Merge the latest incoming changeset with the local working copy Commit the merge into the local repository Push the merge back to the remote repository
• Find out more about Mercurial’s merging: http://tortoisehg.bitbucket.org/hgbook/1.6/a-tour-of-mercurial-merging-work.html
Merge changesets
Step 8Resolve merge conflict
Slide 76
• The merging scenario which was described in Step 7 is an example of a happy flow. There were no merge conflicts and this should be the case most of the time.
• In some cases, a merge conflict can result when two people were working on the same file and decided to commit their changes. When Mercurial merges both of their work, it realizes it cannot do so automatically on its own and thus requires intervention from the one who initiates the merge.
• Merge conflicts are settled by a user selecting which portion of the changed code should be in the finalized file.
• Merge conflicts can be avoided in Software Projects through proper software engineering and individual ownership of classes. However, should such a conflict occur, Mercurial is capable of handling it.
Resolve merge conflict
Slide 77
• Let’s look at a more specific example:Rowley and Holly both started with the same code. Rowley then edited one file, committed and pushed it. At the same time, Holly also edit that file, committed and was about to push it. This creates a situation where Holly need to merge her changeset and Rowley’s, as we have seen in the last section about merge
• Normally, if Holly and Rowley change different files, say file A for Rowley and file B for Holly, TortoiseHg will automatically merge, using the newer version of file A from Rowley and a newer version of file B from Holly
• However, since they both change one file, TortoiseHg can’t figure out whose version to use. This situation causes a merge conflict
Resolve merge conflict
Slide 78
Merge changeset
Rowley
Holly
Pulled & Updated Commit new code
Pushed
Try to push
Commit new codePulled & Updated
time
One file, project.txt for example
Create version A of project.txt
Create version B of project.txt
Slide 79
In this real example, Rowley and Holly started from Holly’s version of the code, where she add Stylizer.h and Stylizer.cpp
Resolve merge conflict
They both started from this revision
Slide 80
• Both Rowley and Holly decides to edit these files in their own way
Resolve merge conflict
Stylizer.hStylizer.cpp
Added a function called Stylize
[Stylizer.h], add:void Stylize(fstream one_file);
[Stylizer.cpp], add:void Stylizer::Stylize(fstream one_file){};
Added a function called Style_file
[Stylizer.h], add:void Style_file(fstream one_file);
[Stylizer.cpp], add:void Stylizer::Style_file (fstream one_file){};
Slide 81
Holly has edited the file and pushed her changeset to Google Code
Resolve merge conflict
Holly’s new changeset
Slide 82
While pushing his commit, Rowley got an errorThen he proceeds to do a pull
Resolve merge conflict
Slide 83
After Rowley pulled, he saw that Holly have one changeset that he doesn’tNow he need to merge his change with Holly’s
Resolve merge conflict
The changeset Rowley pulled
Slide 84
Again, this is done using the Merge with local option
Resolve merge conflict
Use Merge with local… to merge the new incoming changesets with yours
Slide 85
A dialog box shows up, summarizing the upcoming merge
Resolve merge conflict
Slide 86
However, a conflict showed up while mergingRowley now need to resolve this before continuing
Resolve merge conflict
Click here to resolve the merge conflict
Slide 87
The Resolve conflicts dialog shows up
Resolve merge conflict
Actions:Mercurial Resolve – Let Mercurial resolve it automatically (trivial)Tool Resolve – Let the default merge tool resolve itTake Local – Takes the version of the file in local working copy.Take Other – Take the other version of the file which is not the local working copy.Mark as Resolved – Marks the file as resolved
Slide 88
For example, if you use Tool Resolve, TortoiseHg will launch kidff3 and you can resolve the conflict there
Resolve merge conflict
Slide 89
After all conflicts are resolved, close the dialog box and commit the merge, similar to Step 7: Merge changeset
Resolve merge conflict
Slide 90
And this is how it is in Google code repository
Resolve merge conflict
The conflicted merge
Slide 91
• The example above was the resolution of a simple merge conflict.
• Even though Jane and Steve edited the same file, their changes were on different lines. Mercurial or the default Diff program was smart enough to resolve it automatically on its own. Therefore, Steve did not need to choose which changes he wanted.
• In other complex cases, you and your team mates could have edited the same section of code. In those cases, you have to use the Diff program to select which sections of code you want in the final merged code.
• As mentioned in the beginning of this step, you can avoid most of those cases by maintaining individual ownership of files and proper software engineering.
Resolve merge conflict
Unleash Mercurial’s full power
Slide 93
• So far, you were introduced to the Central Repository Model.• The Central Repository Model is an adaptation of the Centralized
model supported by a group of RCS called Centralized Revision Control Systems (CRCS for short), of which the most notable is Subversion (SVN for short).
• In CRCS, there is a central repository hosted on a remote server but no local repositories. Developers synchronize changes directly to the central repository and a network connection is required for most repository operations.
Centralized Revision Control System
Slide 94
• Compare this with the Central Repository Model on Slide 9
Team’s Central Repo
Team Leader
Member C
Member A
Member B
Centralized Model
Slide 95
• Mercurial belongs to a group of RCS known as Decentralized Revision Control Systems (DRCS), which includes Git.
• DRCS uses the Decentralized Model: repositories are decentralized and repository configuration is flexible.Hence the workflow can vary differently from team to team.
• In the general model, every team member has his/her own remote repository in addition to their own local repository. There is no such thing as the central repository.
Distributed Revision Control System
Slide 96
Pulling & Pushing in Decentralized Model
Member B
Member B’s Local
Repo
Member A
Member A’s Local
Repo
Member A’s
Hosted Repo
1. pull and merge
3. push changes
4. se
nds p
ull r
eque
st
2. makes some changes and commit
Member B’s
Hosted Repo
5. pull and merge
6. push changes
Slide 97
Pulling & Pushing in Decentralized Model• You can see that Member A pulls the latest changes off Member B’s
hosted repository and merges the changes with his local repository. Now that his local repository is updated, he then commits his own changes and pushes them to his hosted repository.
• Member A then informs the team to pull his changes off his hosted repository. Member B decides to do so and merges the changes from Member A’s hosted repository into his own local repository.
• Each of the members does not pull off from one another’s local repository. Instead, they pull off changes from one another’s hosted repository.
Slide 98
Advantages of DRCS in brief• Presence of the local repository allows you to commit code and
push the changes only when you are ready• No need for an Internet connection to commit changes or access
your local repository, which means full benefits of version control anytime anywhere.
• Flexible organization of repositories as workflow does not always have to be centralized
• You can choose whether or not to pull from repositories and condemn your friend’s buggy code until it is fixed.
• And many many more…