Save work.

Signed-off-by: Pierre Habouzit <madcoder@debian.org>

diff --git a/01-import-upstream.txt b/01-import-upstream.txt
new file mode 100644 (file)
index 0000000..e730991
--- /dev/null
+++ b/01-import-upstream.txt
@@ -0,0 +1,10 @@
+$ git checkout upstream
+$ rm -rf *
+$ tar xf ~/tokyocabinet-1.1.15.tar.gz --strip 1
+$ git add .
+$ git commit -as
+
+$ mv ~/tokyocabinet-1.1.15.tar.gz ../tokyocabinet_1.1.15.orig.tar.gz
+$ pristine-tar commit ../tokyocabinet_1.1.15.orig.tar.gz `git rev-parse HEAD`
+
+That's it

diff --git a/Makefile b/Makefile
new file mode 100644 (file)
index 0000000..37e899e
--- /dev/null
+++ b/Makefile
@@ -0,0 +1,4 @@
+git.pdf: git.tex
+       git clean
+       pdflatex $<
+       pdflatex $<

diff --git a/git.tex b/git.tex
new file mode 100644 (file)
index 0000000..703730e
--- /dev/null
+++ b/git.tex
@@ -0,0 +1,138 @@
+\documentclass[10pt]{beamer}%{{{
+
+\mode<presentation> {
+  \usetheme{Warsaw}
+  \setbeamercovered{transparent}
+}
+
+\usepackage[english]{babel}
+\usepackage[utf8]{inputenc}
+\usepackage{graphicx}
+
+\usepackage{times}
+%\usepackage[T1]{fontenc}
+\newcommand{\git}{GIT}
+
+
+\title{Packaging with \git}
+
+\author{Pierre Habouzit}
+
+\institute{FOSDEM 2008 - Debian Room}
+
+\date{23 Feb. 2008}
+
+\AtBeginSubsection[] {
+  \begin{frame}<beamer>{Why choosing \git}
+    \tableofcontents[currentsection,currentsubsection]
+  \end{frame}
+}
+
+\begin{document}
+
+\begin{frame}
+  \titlepage
+\end{frame}
+%}}}
+\section{Why choosing \git}%{{{
+
+\begin{frame}{It's a DSCM [1/2]}
+  I've packaged with SVN on svn.debian.org for a long time…
+  \uncover<2->{\alert{well, it sucks}:}
+  \begin{itemize}
+    \item<3-> I wasn't able to work without network access;
+    \item<4-> I couldn't work incrementally: you have to get other's patches;
+    \item<5-> I couldn't "try and see" and maybe discard some work without
+              reverting patches: SVN never forgets;
+    \item<6-> I like having the full upstream source at hand, but svn explodes
+              doing that for large sources (KDE …).
+  \end{itemize}
+\end{frame}
+
+\begin{frame}{It's a DSCM [2/2]}
+  With \git, as a DSCM, most of the issues are gone.
+  \begin{itemize}
+    \item<2-> Offline work is possible, in fact you always work offline;
+    \item<3-> Incremental work is possible;
+    \item<4-> \git{} allow you to completely erase a wrong idea if you didn't
+              shared it yet;
+    \item<5-> \git{} storage is extremely efficient: the marginal cost of
+              commits decreases with the number of commits.
+  \end{itemize}
+
+  \vspace{1ex}
+
+  \uncover<6->{
+    GNU libc version 2.7 weights weights 115Mo unpacked. The full glibc
+    history (from before 1984) weights less than \alert{120Mo}.
+  }
+
+  \vspace{1ex}
+
+  \uncover<7->{
+    My experience shows that \git{} storage, for a project with quite some
+    history, is smaller than 2.5 times the size of the last upstream release
+    (unpacked).
+  }
+\end{frame}
+
+\begin{frame}{A real maintainer toolbox}
+  Though \git{} is special, because it was designed by a {\bf Maintainer}.
+  This has several implications:
+  \begin{itemize}
+    \item<2-> \git{} operations to look at the history are blazingly fast;
+    \item<3-> \git{} operations to integrate patches are blazingly fast;
+    \item<4-> \git{} supports advanced merging features;
+    \item<5-> \git{} has advanced patch manipulation features.
+  \end{itemize}
+
+  \vspace{1ex}
+
+  \uncover<6->{
+    In other words, \git{} is a suitable replacement for both SVN and
+    quilt\footnote{or your prefered patch system}.
+  }
+\end{frame}
+
+%}}}
+\section{Repository layout}%{{{
+\begin{frame}{The repository layout: upstream}
+  First of all, my repositories contain upstream sources.
+  \begin{enumerate}
+    \item<2-> if upstream uses a public SVN or \git{} repository, I track
+              their SCM under the {\tt upstream/*} namespace.
+    \item<3-> if upstream tarballs differ from the SCM, I also add a
+              {\tt upstream/tarballs} branch that replicates the tarball
+              directly.
+    \item<4-> if upstream only releases tarballs, I only have an
+              {\tt upstream} branch that is the successive import of tarballs.
+
+    \item<5-> last and not least, {\tt pristine-tar} helps me saving the
+              pristine upstream tarballs inside git.
+  \end{enumerate}
+\end{frame}
+
+\begin{frame}{The repository layout: upstream}
+  \vspace{1ex}
+  {\bf Demo}: tokyocabinet packaging:
+  \begin{itemize}
+    \item Step 1: importing upstream;
+    \item Step 2: backuping the orig.tar.gz.
+  \end{itemize}
+\end{frame}
+
+\begin{frame}{The repository layout: patches}
+  Second of all, instead of using quilt, I use a private git branch to hold my
+  patch queue (usually called {\tt \$origbranch+patches}). There are many
+  reasons to that:
+  \begin{itemize}
+    \item<2-> I only use one tool: \git{};
+    \item<3-> quilt doesnt know about diff3, hence isn't very practical for
+              partially merged patches;
+    \item
+    \item
+  \end{itemize}
+\end{frame}
+%}}}
+\end{document}
+% vim:tw=78: