732 lab: mil mercurial - auckland · 2012. 3. 7. · lab task 4 / 2012 •reproduce the conflict...

25
/2012 732 08/03/ COMPSCI Lab: M il ealand Mercurial kland | New Ze versity of Auck The Univ 1

Upload: others

Post on 23-Jan-2021

3 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: 732 Lab: Mil Mercurial - Auckland · 2012. 3. 7. · Lab Task 4 / 2012 •Reproduce the conflict from Lab task 3: 732 08/03 • Use “merge” on repo2, applying it to the two latest

/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

Page 2: 732 Lab: Mil Mercurial - Auckland · 2012. 3. 7. · Lab Task 4 / 2012 •Reproduce the conflict from Lab task 3: 732 08/03 • Use “merge” on repo2, applying it to the two latest

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

Page 3: 732 Lab: Mil Mercurial - Auckland · 2012. 3. 7. · Lab Task 4 / 2012 •Reproduce the conflict from Lab task 3: 732 08/03 • Use “merge” on repo2, applying it to the two latest

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

Page 4: 732 Lab: Mil Mercurial - Auckland · 2012. 3. 7. · Lab Task 4 / 2012 •Reproduce the conflict from Lab task 3: 732 08/03 • Use “merge” on repo2, applying it to the two latest

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

Page 5: 732 Lab: Mil Mercurial - Auckland · 2012. 3. 7. · Lab Task 4 / 2012 •Reproduce the conflict from Lab task 3: 732 08/03 • Use “merge” on repo2, applying it to the two latest

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

Page 6: 732 Lab: Mil Mercurial - Auckland · 2012. 3. 7. · Lab Task 4 / 2012 •Reproduce the conflict from Lab task 3: 732 08/03 • Use “merge” on repo2, applying it to the two latest

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

Page 7: 732 Lab: Mil Mercurial - Auckland · 2012. 3. 7. · Lab Task 4 / 2012 •Reproduce the conflict from Lab task 3: 732 08/03 • Use “merge” on repo2, applying it to the two latest

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

Page 8: 732 Lab: Mil Mercurial - Auckland · 2012. 3. 7. · Lab Task 4 / 2012 •Reproduce the conflict from Lab task 3: 732 08/03 • Use “merge” on repo2, applying it to the two latest

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

Page 9: 732 Lab: Mil Mercurial - Auckland · 2012. 3. 7. · Lab Task 4 / 2012 •Reproduce the conflict from Lab task 3: 732 08/03 • Use “merge” on repo2, applying it to the two latest

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

Page 10: 732 Lab: Mil Mercurial - Auckland · 2012. 3. 7. · Lab Task 4 / 2012 •Reproduce the conflict from Lab task 3: 732 08/03 • Use “merge” on repo2, applying it to the two latest

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

Page 11: 732 Lab: Mil Mercurial - Auckland · 2012. 3. 7. · Lab Task 4 / 2012 •Reproduce the conflict from Lab task 3: 732 08/03 • Use “merge” on repo2, applying it to the two latest

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

Page 12: 732 Lab: Mil Mercurial - Auckland · 2012. 3. 7. · Lab Task 4 / 2012 •Reproduce the conflict from Lab task 3: 732 08/03 • Use “merge” on repo2, applying it to the two latest

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

Page 13: 732 Lab: Mil Mercurial - Auckland · 2012. 3. 7. · Lab Task 4 / 2012 •Reproduce the conflict from Lab task 3: 732 08/03 • Use “merge” on repo2, applying it to the two latest

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

Page 14: 732 Lab: Mil Mercurial - Auckland · 2012. 3. 7. · Lab Task 4 / 2012 •Reproduce the conflict from Lab task 3: 732 08/03 • Use “merge” on repo2, applying it to the two latest

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

Page 15: 732 Lab: Mil Mercurial - Auckland · 2012. 3. 7. · Lab Task 4 / 2012 •Reproduce the conflict from Lab task 3: 732 08/03 • Use “merge” on repo2, applying it to the two latest

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

Page 16: 732 Lab: Mil Mercurial - Auckland · 2012. 3. 7. · Lab Task 4 / 2012 •Reproduce the conflict from Lab task 3: 732 08/03 • Use “merge” on repo2, applying it to the two latest

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

Page 17: 732 Lab: Mil Mercurial - Auckland · 2012. 3. 7. · Lab Task 4 / 2012 •Reproduce the conflict from Lab task 3: 732 08/03 • Use “merge” on repo2, applying it to the two latest

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

Page 18: 732 Lab: Mil Mercurial - Auckland · 2012. 3. 7. · Lab Task 4 / 2012 •Reproduce the conflict from Lab task 3: 732 08/03 • Use “merge” on repo2, applying it to the two latest

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

Page 19: 732 Lab: Mil Mercurial - Auckland · 2012. 3. 7. · Lab Task 4 / 2012 •Reproduce the conflict from Lab task 3: 732 08/03 • Use “merge” on repo2, applying it to the two latest

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

Page 20: 732 Lab: Mil Mercurial - Auckland · 2012. 3. 7. · Lab Task 4 / 2012 •Reproduce the conflict from Lab task 3: 732 08/03 • Use “merge” on repo2, applying it to the two latest

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

Page 21: 732 Lab: Mil Mercurial - Auckland · 2012. 3. 7. · Lab Task 4 / 2012 •Reproduce the conflict from Lab task 3: 732 08/03 • Use “merge” on repo2, applying it to the two latest

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

Page 22: 732 Lab: Mil Mercurial - Auckland · 2012. 3. 7. · Lab Task 4 / 2012 •Reproduce the conflict from Lab task 3: 732 08/03 • Use “merge” on repo2, applying it to the two latest

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

Page 23: 732 Lab: Mil Mercurial - Auckland · 2012. 3. 7. · Lab Task 4 / 2012 •Reproduce the conflict from Lab task 3: 732 08/03 • Use “merge” on repo2, applying it to the two latest

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

Page 24: 732 Lab: Mil Mercurial - Auckland · 2012. 3. 7. · Lab Task 4 / 2012 •Reproduce the conflict from Lab task 3: 732 08/03 • Use “merge” on repo2, applying it to the two latest

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

Page 25: 732 Lab: Mil Mercurial - Auckland · 2012. 3. 7. · Lab Task 4 / 2012 •Reproduce the conflict from Lab task 3: 732 08/03 • Use “merge” on repo2, applying it to the two latest

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