% $Cambridge: hermes/doc/talks/2012-04-staffsem/talk.tex,v 1.1 2012/04/18 10:20:28 fanf2 Exp $

% This file is included by notes.tex and slides.tex

\usepackage[english,british]{babel}
\usepackage{pgf,pgfarrows,pgfshade}
\usepackage{calc} % for frame column width calculations
\usepackage{ulem} % for strikeout
\usepackage{url}

\newcommand\image[2][]{\mode<beamer>{\includegraphics[#1]{#2}}}

\newcommand\notes[1]{\mode<article>{#1}}

\newcommand\deco{\mode<beamer>{
    \vspace{2mm}\hspace{15mm}
    $ \approx::\divideontimes::\approx $
    \vspace{2mm}
}}

% args: title, body
\newcommand\slide[2]{
  \frame{\frametitle{#1}#2}
}

% args: (optional) image width, image name, title, body
\newcommand\slideT[4][10cm]{
  \slide{#3}{
    \centering\image[width=#1]{#2}

    #4

  }
}
\newcommand\slideL[4][5cm]{
  \slide{#3}{
    \begin{columns}
    \column{#1}
      \image[width=#1]{#2}
    \column{10cm - #1}
      #4
    \end{columns}
  }
}
\newcommand\slideR[4][5cm]{
  \slide{#3}{
    \begin{columns}
    \column{10cm - #1}
      #4
    \column{#1}
      \image[width=#1]{#2}
    \end{columns}
  }
}

\DeclareUrlCommand\email{%
  \def\UrlLeft{<}%
  \def\UrlRight{>}%
  \urlstyle{tt}%
}

% first slide

\author[Tony~Finch]{
  Tony~Finch
  \email{fanf2@cam.ac.uk}
}

\institute[Cambridge UCS]{%
  University of Cambridge Computing Service%
}

\titlegraphic{%
  \raisebox{1pt}{%
    \includegraphics[height=20pt]{univ.jpg}%
  }%
  \hspace{6pt}%
  \includegraphics[height=22pt]{ucs.jpg}%
}

% title page

\title{
  Version Control Systems
}
\date{Wednesday 18 April 2011}

\begin{document}

\frame{\maketitle}

\notes{
  \begin{abstract}
    Version control systems -- the pragmatics.

    Following an introduction to the subject from Jon Warbrick.
  \end{abstract}
}

% down to business

\slideT{scmhistory.png}
    {Version control timeline}
{
  \mode<beamer>{~\\ \tiny}
  \url{http://codicesoftware.blogspot.co.uk/2010/11/version-control-timeline.html}
}

% http://www.hardwoodparoxysm.com/2012/02/01/the-palimpsest-of-kobe-bryant/

\slideR[3.5cm]{palimpsest.jpg}
    {SCCS -- ``source code control system''}
{
  \begin{itemize}
  \item 1972 -- SNOBOL, IBM OS/MVT
  \item 1973 -- C, Unix
  \item PWB $\rightarrow$ System V $\rightarrow$ Solaris
  \item Specified by POSIX
  \item GNU CSSC
    \\ ``compatibly stupid source control''
    \\ \url{www.gnu.org/software/cssc}
  \end{itemize}

  \deco

  \begin{itemize}
  \item \url{www.cam.ac.uk}
  \end{itemize}
}
\notes{

  SCCS was developed at Bell Labs. It was part of the Unix-based
  Programmers' Workbench (PWB), and from there it was inherited by
  System V Unix, thence commercial Unixes such as Solaris, and
  standardized as part of POSIX. The GNU project has a free clone
  called CSSC.

  It has some important proprietary successors which I'll come back to
  later.

  We use it in the Computing Service to manage some of the content on
  the main web server. I believe this was originally just because it
  comes with Solaris.

}

% http://1.bp.blogspot.com/-Vv2aVMm31wM/TtX6-jlwTsI/AAAAAAAAAHQ/_o9g2XgEtwA/s1600/Lock_%2526_Chain.jpg

\slideR[3cm]{lock.jpg}
    {RCS -- ``revision control system''}
{
  \begin{itemize}
  \item 1982 -- C, Unix
  \item free / open source
  \end{itemize}

  \deco

  \begin{itemize}
  \item Managed Mail Domains
  \item Hermes system configuration
  \item \sout{PWF} MCS Linux package lists
  \end{itemize}
}
\notes{

  Another imaginitive name.

  RCS has a similar mode of operation to SCCS. The repository is a
  subdirectory of the working directory. You have to lock a file
  before you can edit it, to prevent multiple concurrent edits from
  accidentally conflicting. Locks can be inconvenient, but they are
  simpler than merging changes and resolving conflicting edits.

  We use the locking feature for managed mail domains. A hypothetical
  more modern user interface would have nothing to do with version
  control.

  RCS is still used for configuration management in a couple of places
  mainly for historical reasons.

}

% http://en.wikipedia.org/wiki/File:Salix_cinerea_subsp._oleifolia_branch.jpg

\slideR[3cm]{branch.jpg}
    {CVS -- ``concurrent versions system''}
{
  \begin{itemize}
  \item 1986 -- shell scripts wrapping RCS
  \item 1990 -- reimplemented in C
  \begin{itemize}
  \item vendor branches
  \end{itemize}
  \item 1995 -- access repository over network
  \item 1996 -- \texttt{cvsweb} repository browser
  \end{itemize}

  \deco

  \begin{itemize}
  \item Hermes source code \\
    \& package configuration
  \end{itemize}
}
\notes{

  CVS is a big step towards modern version control. Unlike SCCS and
  RCS, the repository is separate from a checked out working copy.

  CVS is ``concurrent'' in the sense that multiple people can check
  out and edit a file at the same time. If someone else checks in
  changes to a file while you are editing, you must use the
  \texttt{update} command to merge those changes into your copy before
  you can check in your own changes.

  Remote access to a CVS repository usually uses \texttt{ssh}.

  I set up the Hermes repository soon after arriving, based on my
  experience of using it whe contributing to the Apache HTTP server
  and FreeBSD projects. It replaced some of our use of RCS.

  We use the ``vendor branch'' feature to help maintain local
  customizations to some of the software we run on Hermes, most
  notably David Carter's extensive improvements to the Cyrus IMAP
  server.

}

% http://www.stencilarchive.org/archives/var/albums/Europe/European_Artists/Banksy/Banksy_CA_LA_SoLittleToSay.jpg

\slideR[4.5cm]{banksy.jpg}
    {Subversion / \texttt{svn} -- ``CVS done right''}
{
  \begin{itemize}
  \item 2000 -- Cross-platform
  \item Apache APR, Berkeley DB, WebDAV
  \end{itemize}

  \begin{itemize}
  \item Multi-file changesets
  \item Cheap branches
  \item Better authentication \\
    \& access control
  \end{itemize}

  \deco

  \begin{itemize}
  \item DSpace / Unix Support / Development Group
  \end{itemize}
}
\notes{

  Subversion was intended to be an evolutionary improvement over CVS.

  With CVS you can commit changes for multiple files with one command,
  but the changes are recorded separately: each file has its own
  version counter, and if you are changing lots of files the revision
  timestamps will be different. Changes that copy or move files are a
  massive pain.

  Subversion fixes these problems. It has ``changesets'' that record
  modifications to several files as an atomic unit. Its other
  advantage is its greater friendliness to non-Unix developers.

  Subversion took quite a long time to become usable. Its repository
  storage was not particularly reliable until Subversion 1.1 was
  released in 2004, and it had very weak merge support until version
  1.5 was released in 2008.

  I'm not a big fan of it, since it is not a big enough improvement
  over CVS to be worth the effort of repository conversion, and it is
  much much slower to use.

  Our \texttt{svn} repository was set up by Tom De Mulder.

}

% http://www.juggling-for-beginners.com/image-files/juggling_passing_clubs.jpg

\slideR[5cm]{clubs.jpg}
    {Early distributed version control systems}
{
  \begin{itemize}
  \item 1991 -- \texttt{smoosh}
    \\ Sun WorkShop TeamWare
    \\ 1999 -- BitKeeper
    \\ \textit{Proprietary popularizer}
  \item 2001 -- GNU Arch / \texttt{tla}
    \\ \textit{Free but loony}
  \item 2003 -- Monotone
    \\ \textit{Merkle crypto hash tree}
  \item 2003 -- Darcs
    \\ \textit{Patch algebra \& Haskell}
  \item 2003 -- \texttt{svk}
    \\ \textit{Distributed Subversion}
  \end{itemize}
}
\notes{

  At Sun they took a different approach to concurrent development from
  CVS. Instead of having a central repository with multiple working
  trees, they based TeamWare on cloning SCCS trees which include both
  the working copy and the history files.

  This allows each developer to record the history of their
  work-in-progress by committing to their local repository, without
  affecting the central shared repository. They have an independent
  development branch.

  Promiscuous branching is only helpful if it is easy to merge two
  sets of changes back together. The \texttt{smoosh} program did this
  by combining SCCS history files.

  BitKeeper is basically ``TeamWare done right'' -- it has changesets
  rather than handling changes to each file independently. It is
  important because it was used to host Linux kernel development
  between 2002 and 2005, which did a lot to popularize distributed
  version control.

  The other programs listed on this slide were all a bit too weird to
  be popular.

  GNU Arch had a needlessly baroque command line interface and a
  prickly developer. It is no longer maintained, but it has a
  successor, Bazaar, about which more in a moment.

  Monotone provided a lot of inspiration for Git. It has exceptionally
  paranoid cryptographic integrity checking, which makes it rather slow.
  It is still maintained.

  Darcs was popular for a while amongst developers of a mathematical
  bent. Sadly it has problems scaling up to cope with large and/or
  long-running projects.

  SVK uses Subversion for repository storage. Adding DVCS features
  allows developers to make commits when not attached to the network.
  SVK has been displaced by \texttt{git}'s Subversion interoperability
  features.

}

% http://highpowerrocketry.blogspot.co.uk/2011/04/mirv.html

\slideR[4.5cm]{MIRV.jpg}
    {Current popular distributed version control systems}
{
  \begin{itemize}
  \item \texttt{git}
    \\ \url{www.git-scm.com}
    \\ \textit{Swiss-army chainsaw}
  \item Mercurial / \texttt{hg}
    \\ \url{mercurial.selenic.com}
  \item Bazaar / \texttt{bzr}
    \\ \url{bazaar.canonical.com}
  \item Fossil
    \\ \url{www.fossil-scm.org}
  \end{itemize}
}
\notes{

  From most popular downwards:

  The big beast of modern version control is Git, initially developed
  by Linus Torvalds and now maintained by Junio Hamano. It is very
  fast and handles large projects well. It has masses of features but
  they aren't particularly well organized. You have to know rather too
  much about its slightly peculiar data model to use it effectively.

  Both Git and Mercurial were created in response to a massive
  falling-out between Larry McVoy (creator of BitKeeper) and the Linux
  project in 2005. Mercurial is not as popular or fast as Git but is
  rather more user-friendly, especially for Windows users.

  Bazaar also dates from 2005 but took longer to attain a decent
  amount of performance and stability. It is now comparable to
  Mercurial. It is developed by Canonical and used a lot by the Ubuntu
  project.

  Fossil is written by the author of SQLite. As well as version
  control it also has a built-in bug tracker and wiki. It emphasizes
  easy deployment.

  They all provide multiple ways to share a repository, with
  differing degrees of convenience, performance, and access control:
  local filesystem, for small-scale use; via HTTP; via ssh; via custom
  protocols.

}

% http://previewnetworks.com/blog/tag/cloud/

\slideR[5cm]{Cloud.jpg}
    {Code hosting services}
{
  \begin{itemize}
  \item \url{github.com}
  \item \url{gitorious.org}
    \\ $\rightarrow$ \texttt{git}
  \item \url{bitbucket.org}
    \\ $\rightarrow$ \texttt{hg}, \texttt{git}
  \item \url{code.google.com}
    \\ $\rightarrow$ \texttt{svn}, \texttt{hg}, \texttt{git}
  \item \url{launchpad.net}
    \\ $\rightarrow$ \texttt{bzr}
  \item \url{savannah.gnu.org}
  \item \url{alioth.debian.org}
  \item \url{sourceforge.net}
    \\ $\rightarrow$ many
  \end{itemize}
}
\notes{

  An advantage of DVCS is that you can easily publish a copy of your
  repository on a code hosting service, without having to rely on them
  as the only authoritative copy (as was the case in the early days of
  SourceForge when the choice was between \texttt{cvs} and \texttt{svn}).

  Bitbucket started off as the Mercurial alternative to GitHub.

  Google Code started off supporting only Subversion, then added
  Mercurial, and later Git.

  Launchpad is Canonical's project hosting site.

}

% http://nvie.com/posts/a-successful-git-branching-model/

\slideR[5cm]{git.png}
    {Git in the Computing Service}
{
  \hspace{5mm} Speculation...

  \deco

  \begin{itemize}
  \item Repository hosting?
    \begin{itemize}
    \item CS internal
    \item Managed service
    \end{itemize}
  \item Config. management
    \begin{itemize}
    \item Starling
    \end{itemize}
  \end{itemize}
}
\notes{

  There is currently not much use of Git for collaboration within the
  Computing Service. It would help to have a central place to store
  shared repositories.

  There is a package called \texttt{gitolite} which would be suitable
  for CS internal Git hosting. Unfortunately it does not have any way
  to delegate management so it doesn't scale up to very large
  organizations. There is \texttt{gitorious} which could be the basis
  of a managed Git hosting service, but it doesn't support private
  repositories which is one of the main reasons for running our own
  rather than leaving it to GitHub.

  Ben Harris has been working on a system called ``Starling'' which
  uses Git for system configuration management. If it is successful it
  will replace Hermes's use of RCS and rdist, and motivate us to
  upgrade from CVS too!

}

% http://news.softpedia.com/news/Steve-Jobs-Tried-to-Hire-Linux-Creator-259963.shtml

\slideT{Linus.jpg}{}
{
  ~ \\
  ``I'm an egotistical bastard, and I name all my projects after
  myself. First Linux, now git.'' ---~Linus~Torvalds
}


\end{document}

% eof
