Modern version control systems for Debian packaging
martin f. krafft <madduck@debian.org>
- Debian developer
- Author of the book The Debian System — Concepts and Techniques
- Ph.D. student, Lero, CSIS, University of Limerick, Ireland
LCA2008, Melbourne, Australia
28 Jan 2008
Introduction
Distributed VCS are hip!
- Why?
- How can we use them to maintain Debian packages?
Disclaimer: I'm a Git. I don't see noteworthy differences in the concepts behind Git and other "modern VCS". There may be, but not in this talk.
CVS-like version control systems
- (conceptually) snapshot-based, a revision corresponds to the state of the tree at a given time
- can be represented changeset-centric (CVS vs. SVN)
- merging consists of computing diffs and applying patches
- a commit (changeset or snapshot) has only a log message as meta information
Centralised version control
Modern version control systems
- commit-based, there is no snapshot of a tree at a given time
- a tree is identified by the set of commits it contains
- every commit is identified by a unique hash
- merging consists of identifying the set difference and applying the commits in the reduced set
- every clone is autonomous and can be fully used offline
- can also be run in a centralised fashion
Commit-based version control
Potential problems during merges
Why modern VCS merge better than the ancient cruft
- both approaches have the same goal: infuse changes made in one tree into another
- both approaches can run into merge conflicts and might require human help
- modern VCS use the history to determine what to merge
- given two commits in an ancestry hierarchy, A and B, where B is supposed to be merged into A
- modern VCS find the common ancestor C of both and only apply the commits between C and B to A
Common ancestors during merges
Introducing feature branches
- Isolated development of features (bug fixes, anything, really…)
- Separate branches, so features can be developed using the full VCS power
- Merged into master because Git is actually stupid
- Still allows for easy separation
My workflow
With credits especially to
- Manoj Srivastava, who introduced me to feature branches
- and Pierre Habouzit, who provided a lot of input and showed me how he uses Git for packaging,
I now want to show you my workflow …
Feature branches
- upstream-patches
- patches that are waiting for upstream inclusion
- each commit is a contained patch
- designed for cherry-picking, will be rebased!
- deb/*
- patches/features that are Debian-specific
- long-living branches
- merged into master because Git is dumb
Other branches in use
- upstream, into which I import or clone upstream's code
- master the main "debianisation" branch, basically ./debian/
- build the integration branch for building the package
The big picture
- upstream-patches is a temporary branch which gets rebased
- deb/* feature branches are long-living, commit targets
Live demonstration?
Do you want to see this in action?
Working with other distros
- Why not use the same repository as e.g. Fedora?
- Additional feature branch families:
- distro/*: non-upstream changes applicable to all distros
- fedora/*: the deb/* (or debian/*) counterpart
My only friend, the end…
Thank you for your attention!
- Mailing list: http://lists.madduck.net/listinfo/vcs-pkg
- "Homepage": http://wiki.debian.org/VcsPackaging
martin f. krafft <madduck@debian.org>
Licence
These slides, their design, and the content are © martin f. krafft and released under the terms of the CC by-nc-sa 2.5 licence.
reStructuredText sources: slides.rst and ui/base/*.
Slides based on the S5 presentation system.