Distributed Version Control

Size: px

Start display at page:

Download "Distributed Version Control"

Griselda Harmon
6 years ago
Views:

1 Distributed Version Control David Grellscheid Workshop on Advanced Techniques for Scientific Programming and Management of Open Source Software Packages March 2014

2 Version management In any project, there are tedious bookkeeping tasks that need to be done: Backup of consistent project snapshots Documentation of changes Sharing of changes Distributed development by multiple people and/or in multiple locations Bug tracing through development history

3 Task automation The bookkeeping can be done by hand: copy things into renamed files locally: keep versions in a DB of some form centrally: a server keeps the DB, clients do the work distributed: each client holds a full copy of the DB

4 Tool history Only showing commonly used free/oss tools: local: RCS (1982) central: CVS (1990), SVN (2000) distributed: Darcs (2002), Bazaar, Git, Mercurial (all 2005)

5 Frontends and visualization Mercurial has built-in hg serve Many other GUI frontends available, try a few to find something you like Github / Bitbucket additionally give full project management tools, but keep a second repo elsewhere!

6 Terminology Working copy Repository (local, remote) checkout, checkin update, commit pull, push branch, merge

7 Working directory one version of the project, visible to be edited manual.tex sunshine.py README clouds.py rain.py is based on one version in the repository, usually the last one 3 4 5

8 Working directory one version of the project, visible to be edited manual.tex sunshine.py README clouds.py rain.py 5 is based on one version in the repository, usually the last one 3 4 5

9 Working directory one version of the project, visible to be edited manual.tex sunshine.py README clouds.py rain.py 5 is based on one version in the repository, usually the last one each WD has its own copy of the full repository!

10 Changes working copy can be changed as usual manual.tex sunshine.py README clouds.py rain.py 5 changes are then checked in / committed as a new version 3 4 5

11 Changes working copy can be changed as usual manual.tex sunshine.py README clouds.py rain.py 6 changes are then checked in / committed as a new version changeset

12 Backtracking older versions can be looked at at any time clouds.py rain.py 3

13 Remote work clone repositories to other locations / devices / people clone

14 Remote work clone repositories to other locations / devices / people clone each clone has all features, not distinguishable

15 Remote work development can happen anywhere 7 8

16 Remote work development can happen anywhere 7 8 push 7 8

17 Remote work development can happen anywhere

18 Remote work development can happen anywhere update

19 Remote work development can happen anywhere

20 Branches unlike in SVN, branches are a natural feature

21 Branches unlike in SVN, branches are a natural feature $ & ~

22 Branches unlike in SVN, branches are a natural feature $ & ~

23 Branches unlike in SVN, branches are a natural feature each distinct changeset has a unique ID! $ & ~

24 Branches unlike in SVN, branches are a natural feature push each distinct changeset has a unique ID! $ & ~

25 Branches unlike in SVN, branches are a natural feature $ & ~ $ & ~

26 Merging merging is automatic as far as possible $ & ~ $ & ~

27 Merging merging is automatic as far as possible $ & ~ merge $ & ~

28 Merging only need to fix some conflicts by hand $ & ~ m $ & ~

29 Merging only need to fix some conflicts by hand $ & ~ m push $ & ~

30 Merging consistent state after push $ & ~ m $ & ~ m

31 Merging consistent state after push $ & ~ m $ & ~ m

32 Merging consistent state after push $ & ~ m $ & ~ m

33 Typical usage patterns Technically, every repo is the same By agreement, designate one repo as central Tarballs or other distributions are built only from there Interaction with central repo: only push/pull from developers, no direct commits Can pipeline even more: put code-review, tester, build manager repos in between

34 Typical usage patterns Think about release lifetime Typically, separate release and feature branches Carefully put checkins in the right place!

35 Typical usage patterns Think about release lifetime Typically, separate release and feature branches Carefully put checkins in the right place!

36 Which branch for which checkin? Pick the innermost appropriate branch Release branch 2.1.x Main development for 2.2.0

37 Which branch for which checkin? Pick the innermost appropriate branch Release branch 2.1.x Main development for Experimental new feature

38 Which branch for which checkin? Pick the innermost appropriate branch Release branch 2.1.x Main development for Experimental new feature merge

39 Which branch for which checkin? Pick the innermost appropriate branch Release branch 2.1.x Main development for 2.2.0

40 Typical usage patterns If a bugfix is localizable, fix it there!

41 Typical usage patterns If a bugfix is localizable, fix it there!!

42 Typical usage patterns If a bugfix is localizable, fix it there!!

43 Typical usage patterns If a bugfix is localizable, fix it there!!

44 Typical usage patterns If a bugfix is localizable, fix it there!!

45 Summary Distributed VCS are so easy to use that there s no reason not to do so!

46 Summary Distributed VCS are so easy to use that there s no reason not to do so!

47 Summary Distributed VCS are so easy to use that there s no reason not to do so! Don t even think of writing outside version control!

CSCI 2132: Software Development. Norbert Zeh. Faculty of Computer Science Dalhousie University. Subversion (and Git) Winter 2019

CSCI 2132: Software Development Subversion (and Git) Norbert Zeh Faculty of Computer Science Dalhousie University Winter 2019 Version Control Systems A version control system allows us to Record the history