.. This document is © Martin F. Krafft <mail@martin-krafft.net>
   It is available under the terms of the Creative Commons
   Attribution-NonCommercial-ShareAlike Licence 2.5

==========================================================================
Modern version control systems for Debian packaging
==========================================================================

.. |event| replace:: LCA2008, Melbourne, Australia
.. |talkdate| replace:: 28 Jan 2008
.. |author| replace:: martin f. krafft
.. |authoremail| replace:: madduck@debian.org
.. |footer| replace:: |event| |bull| |talkdate|

.. container:: author

  |author| <|authoremail|>

  * `Debian`_ developer
  * Author of the book `The Debian System — Concepts and Techniques`_
  * `Ph.D. student`_, `Lero`_, `CSIS`_, `University of Limerick`_, Ireland

.. _Debian: http://debian.org/
.. _Ph.D. student: http://martin-krafft.net/phd/
.. _Lero: http://lero.ie/
.. _CSIS: http://www.csis.ul.ie/
.. _University of Limerick: http://ul.ie/
.. _The Debian System — Concepts and Techniques: http://debiansystem.info/

.. container:: event

  |event|
  |talkdate|

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.

Evolution of version control
============================
.. container:: center

  .. image:: vcs.png

This `mailing list post <http://marc.info/?l=vcs-pkg&m=119605540507443&w=2>`_
explains the graph a bit.

CVS-like version control systems
================================
.. class:: incremental

  - (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
===========================
.. container:: center

  .. image:: zentrale-vcs.png

Modern version control systems
==============================
.. class:: incremental

  - 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
============================
.. container:: center

  .. image:: verteilte-vcs.png

Potential problems during merges
================================
.. container:: center

  .. image:: cherry-picking.png

Why modern VCS merge better than the ancient cruft
==================================================
.. class:: incremental

  - 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**

    .. class:: incremental

      - 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
==============================
.. container:: center

  .. image:: cherry-picking.png

Introducing feature branches
============================
.. class:: incremental

  - 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
===========
.. class:: incremental

  .. container:: none

    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
  <http://madduck.net/blog/2007.10.03:packaging-with-git/>`_ …

Feature branches
================
.. class:: incremental

  - ``upstream-patches``

    .. class:: incremental

      - patches that are waiting for upstream inclusion
      - each commit is a contained patch
      - designed for cherry-picking, will be rebased!

  - ``deb/*``

    .. class:: incremental

      - patches/features that are Debian-specific
      - long-living branches
      - merged into ``master`` because Git is dumb

Other branches in use
=====================
.. class:: incremental

  - ``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
===============
.. container:: center

  .. image:: workflow.png

- ``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
==========================
.. class:: incremental

- 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

  .. container:: author

    |author| <|authoremail|>

    * http://people.debian.org/~madduck/
    * http://martin-krafft.net/phd/

.. include:: licence.en.rst
.. include:: common.inc
.. footer:: |footer|