732 Lab: Mil Mercurial - Auckland · 2012. 3. 7. · Lab Task 4 / 2012 •Reproduce the conflict...
Transcript of 732 Lab: Mil Mercurial - Auckland · 2012. 3. 7. · Lab Task 4 / 2012 •Reproduce the conflict...
/2012
732
08/03/
CO
MP
SC
I
Lab:M i l
eala
nd
Mercurial
klan
d | N
ew Z
eve
rsity
of A
uck
The
Uni
v
1
First: Recap/2012
p
• Distributed Version control
732
08/03/
CO
MP
SC
I ea
land
klan
d | N
ew Z
eve
rsity
of A
uck
The
Uni
v
2
DistributedV rsi n C ntr l
/2012
Version ControlAll developers have their own local repository
732
08/03/ (a.k.a. “decentralized version control”)
1. Developers work on their working copy
CO
MP
SC
I
2. Developers commit changes of the working copy to their own local repository first
eala
nd
3. Changes can be exchanged between repositories (“pushed” and “pulled”)
klan
d | N
ew Z
e
LocalRepository
NetworkWorkingCopyA
vers
ity o
f Auc
k
LocalWorkingC “Central”B
The
Uni
v LocalRepositoryCopy Central
RepositoryB
Push and Pull/2012
Push• Once developers have committed versions on their
l l it th h th t th
732
08/03/ local repository, they can push them to another repo
• Versions are pushed from local branches into corresponding remote branches
CO
MP
SC
I
p g• Like “commit” from one repo to anotherPull
eala
nd
• Latest versions are pulled from remote branchesand put into the corresponding local branches
• Like “update” from one repo to another
klan
d | N
ew Z
e Like update from one repo to another
LocalRepository
NetworkWorkingCopyA
vers
ity o
f Auc
k Repository
L l
py
Working “C t l”
The
Uni
v LocalRepository
gCopy “Central”
RepositoryB
DistributedV rsi n C ntr l
/2012
Version Control• Local and remote repositories are technologically
732
08/03/ identical.
• Chaining of repositories is possible.
CO
MP
SC
I
• Several personal repositories can be used:• Good for testing of new commits:
eala
nd
• one repo for development, one for staging
klan
d | N
ew Z
e
LocalRepository
NetworkWorkingCopyA
vers
ity o
f Auc
k
LocalWorkingC “Central”
The
Uni
v LocalRepositoryCopy Central
Repository
Mercurial/2012 • Open-source project, started around 2005
732
08/03/
j• Used for many open-source projects
CO
MP
SC
I
• Every developer has a repository, which is a folder• Repo folder contains working copy,
eala
nd
p g py,and a subfolder .hg which contains the version data
• Versions are identified locally by natural numbers
klan
d | N
ew Z
e
and globally by hash values,e.g. 5c240805ac2d9530b780cbd514574af398c0cdd6G d l (T i H )
vers
ity o
f Auc
k • Good tool support (TortoiseHg)• Fairly easy to use
The
Uni
v
6
Working with Hg/2012
g g
1. Start by cloning existing repo, or creating new one
732
08/03/
y g g p , g– New repo has only “default branch” (like trunk)– After cloning you have local copies of all branches
CO
MP
SC
I
f g y p fof parent repo
2. Modify working copy and commit to create new
eala
nd
y g pyversions in your local repo
3. Pull to load new versions from parent repo into local
klan
d | N
ew Z
e
repo– Does not change working
vers
ity o
f Auc
k copy– Pulled versions are
put in separate branch
The
Uni
v put in separate branch from your local versions 7
Most important tool: Tortoise xpl r r
/2012
explorer• Integrated
732
08/03/
gcontrol GUIfor mercurial
CO
MP
SC
I • In some of the lab tasks you are asked to explore the
eala
nd
to explore thefunctions a bit on your own and figure
klan
d | N
ew Z
e your own and figure out how certain things work!
vers
ity o
f Auc
k
• After all, every GUI is intuitive, right?
The
Uni
v
8
commit/2012 • Creates a new version on
h l l
732
08/03/ the local repository.
• Best practices:
CO
MP
SC
I • Always review your changes!M k t dd
eala
nd
• Make sure to add new(a.k.a. untracked)files
klan
d | N
ew Z
e files.• One commit should
be only one logical
vers
ity o
f Auc
k be only one logicalchange.
• Never break the build!
The
Uni
v
• Never break the tests. 9
Hg Pull/2012
gPull regularly to stay up to date.H itt d l l i
732
08/03/ Have you committed local versions
on some branch?1 If no you can update to the latest
CO
MP
SC
I 1. If no, you can update to the latest pulled version– Changes in working copy are
eala
nd
– Changes in working copy are merged with pulled version
– Unless you choose to
klan
d | N
ew Z
e Unless you choose to “discard local changes”
2. If you have committed local versions
vers
ity o
f Auc
k f yon some branch, they should be merged with pulled versions on
b h
The
Uni
v same branch10
Lab Setup/2012
p
• Create one repo: repo1
732
08/03/
p p• Create one file in the working copy of repo1• Add it to version control, can you figure out how?
CO
MP
SC
I
, y f g• Commit it.• Clone the repo: repo2
eala
nd
Clone the repo repo2
klan
d | N
ew Z
eve
rsity
of A
uck
The
Uni
v
11
Lab Task 1/2012
• Change a file in the working copy of repo1
732
08/03/
g g py p• Commit to repo1.• What is on repo2?
CO
MP
SC
I
p• Pull on repo 2. What do you see?• Update on repo 2
eala
nd
Update on repo 2
klan
d | N
ew Z
eve
rsity
of A
uck
The
Uni
v
12
Hg Push/2012
g
Push regularly to integrate your changes.
732
08/03/
g y g y gHave others committed versions on a remote branch
that you have committed to locally?
CO
MP
SC
I
1. If no, push will succeed and the local versions will be in the remote repo
eala
nd
2. If yes, i.e. others have committed versions on a branch you have
itt d t l ll
klan
d | N
ew Z
e committed to locally:– You need to merge your versions
with their versions
vers
ity o
f Auc
k with their versions– When local branches and corresp.
remote branches are merged
The
Uni
v remote branches are merged, push succeeds 13
Lab Task 2/2012
• Change something in the working copy of repo2.
732
08/03/
g g g py p• Commit to repo2• What is on repo1?
CO
MP
SC
I
p• Push in repo 2 to repo1. What do you see?
eala
ndkl
and
| New
Ze
vers
ity o
f Auc
kTh
e U
niv
14
Lab Task 3/2012
• Change a file in the working copy of repo1
732
08/03/
g g py p• Commit to repo1.• Change a different file in the working copy of repo2.
CO
MP
SC
I
g ff f g py f p• Commit to repo2• Pull on repo 2. What do you see?
eala
nd
Pull on repo 2. What do you see?• Push in repo 2 to repo1. What happens?
klan
d | N
ew Z
eve
rsity
of A
uck
The
Uni
v
15
Lab Task 4/2012
• Reproduce the conflict from Lab task 3:
732
08/03/
p• Use “merge” on repo2, applying it to the two latest
commits. Can you figure out how to do that?
CO
MP
SC
I
• Push in repo 2 to repo1. What happens?
eala
ndkl
and
| New
Ze
vers
ity o
f Auc
kTh
e U
niv
16
Lab Task 5/2012
• Change a file in the working copy of repo1
732
08/03/
g g py p• Commit to repo1.• Change a different file in the working copy of repo2.
CO
MP
SC
I
g ff f g py f p• Pull on repo 2. What do you see?• Update, using “merge local changes”
eala
nd
Update, using merge local changes• Now commit on repo2.• Push in repo 2 to repo1 What happens?
klan
d | N
ew Z
e Push in repo 2 to repo1. What happens?• What is the difference in the version space to lab
task 4?
vers
ity o
f Auc
kTh
e U
niv
17
Lab Task 6/2012
• Change a file in the working copy of repo1
732
08/03/
g g py p• Commit to repo1.• Change a different file in the working copy of repo2.
CO
MP
SC
I
g ff f g py f p• Commit to repo2 under a named branch tryout• Pull on repo 2. What do you see?
eala
nd
Pull on repo 2. What do you see?• Push in repo 2 to repo1. What happens?• What is the difference to before?
klan
d | N
ew Z
e What is the difference to before?
vers
ity o
f Auc
kTh
e U
niv
18
Lab Task 7/2012
• Reproduce the final situation of Lab Task 6:
732
08/03/
p• Use merge on repo2, on default branch and tryout
branch
CO
MP
SC
I
• Push in repo 2 to repo1. What happens?• Compare with Lab Task 4
eala
nd
p
klan
d | N
ew Z
eve
rsity
of A
uck
The
Uni
v
19
Extensions Tab/2012
732
08/03/
CO
MP
SC
I ea
land
klan
d | N
ew Z
eve
rsity
of A
uck
The
Uni
v
20
Extensions/2012 • Transplant: Moving a commit from one branch to
another
732
08/03/ another
• Strip: deleting one or several commits on a local repository
CO
MP
SC
I repository.
eala
ndkl
and
| New
Ze
vers
ity o
f Auc
kTh
e U
niv
21
Lab Task E1/2012
• Reproduce the conflict from Lab task 3:
732
08/03/
p• Strip one head. Can you figure out how to do that?• Push in repo 2 to repo1. What happens?
CO
MP
SC
I
p p pp• Stripping changes is NOT the standard way to deal
with conflicts, the standard way is merging.
eala
nd
y g g
klan
d | N
ew Z
eve
rsity
of A
uck
The
Uni
v
22
Lab Task E2/2012
• Reproduce the conflict from Lab task 3:
732
08/03/
p• Transplant one head to the other branch. Can you
figure out how to do that?
CO
MP
SC
I
• Strip one head, which one makes sense?• Push in repo 2 to repo1.
eala
nd
p p• Compare with merging.
klan
d | N
ew Z
eve
rsity
of A
uck
The
Uni
v
23
Work routine for committing/2012
g
• If you think you are ready to commit
732
08/03/
y y y1. Run tests. If they fail, do not commit2. Pull commits
CO
MP
SC
I
mm3. If there are changes, update to the latest commit,
back to 1.
eala
nd
4. Check all files that need to be committed.5. Commit
klan
d | N
ew Z
e
6. Push (this is crucial, commit alone doesnt make it available for others.
vers
ity o
f Auc
kTh
e U
niv
24
Version ControlBest Practices
/2012
Best Practices1. Complete one change at a time and commit it
732
08/03/ – If you committing several changes together you cannot
undo/redo them individually– If you don’t commit and your hard disk crashes
CO
MP
SC
I – If you don t commit and your hard disk crashes…– Continuous integration (see XP)
2. Only commit changes that preserve system integrity
eala
nd
y g p y g y– No “breaking changes” that make compilation or tests fail
3. Commit only source files (e.g. not .class files)
klan
d | N
ew Z
e
4. Write a log entry for each change– What has been changed and why
5 Communicate with the other developers
vers
ity o
f Auc
k 5. Communicate with the other developers– See who else is working on a part before changing it– Discuss and agree on a design
The
Uni
v
25
g g– Follow the project guidelines & specifications