tags/vcszack's home pagehttp://upsilon.cc/~zack/tags/vcs/zack's home pageikiwiki2009-11-28T12:00:16Zdebcheckout hackinghttp://upsilon.cc/~zack/blog/posts/2008/10/debcheckout_hacking/2009-11-28T12:00:16Z2008-10-31T00:31:47Z
<h1>New features for debcheckout, ... now with TopGit support!</h1>
<p>Today I've spent some time hacking on <a href=
"http://upsilon.cc/~zack/blog/posts/2007/08/debcheckout/">debcheckout</a>,
which for weird reasons happens to be at the bottom of a stack of
chained things that I need to do in the forthcoming days. Also, I
had neglected <code>debcheckout</code> for a while, and the other
<a href="http://packages.debian.org/devscripts">devscripts</a>
folks where ready to shout at me because of that <img src=
"http://upsilon.cc/~zack/smileys/smile.png" alt=":-)" /> .</p>
<p>Well, it has been fun, and beside having fixed all the
outstanding bugs, <code>debcheckout</code> has grown some cute new
features:</p>
<ul>
<li>
<p>the ability to <strong>query a VCS repository</strong> (using
<code>-d</code>/<code>--details</code>) for details, at the very
minimum it will parse for you the <code>Vcs-*</code> fields, but it
is expected that in the future will be able to be more telling, and
it is already so for <a href=
"http://repo.or.cz/w/topgit.git">TopGit</a> ...</p>
</li>
<li>
<p>... and speaking about that, debcheckout now has <strong>support
for TopGit</strong>. In two ways: the first one is using
<code>-d</code>, which will tell you whether a GIT repo is
TopGit-enabled or not and, if it is so, also the <em>list of
available top-bases</em>. For instance:</p>
<pre><code> zack@usha:~$ debcheckout -d topgit
type git
url git://git.debian.org/git/collab-maint/topgit.git
top-bases debian/locations
topgit yes
</code></pre>
<p>or even more brutally</p>
<pre><code> zack@usha:~$ debcheckout -d git://git.debian.org/git/pkg-ocaml-maint/packages/ocaml-batteries.git
type git
url git://git.debian.org/git/pkg-ocaml-maint/packages/ocaml-batteries.git
top-bases features/flexi-build
topgit yes
</code></pre>
<p>The other way in which TopGit is supported, is that when
checking out a GIT repo which is detected to be TopGit's as well,
population of top-bases (i.e., <em>TopGit local
initialization</em>) is automatically performed.</p>
<p>... yes, a while ago I've fallen in love with TopGit, is it
<em>that</em> evident? <img src="http://upsilon.cc/~zack/smileys/smile.png" alt=
":-)" /></p>
</li>
<li>
<p>it is now possible to specify <strong>custom rules for
authenticated mode</strong>, this way you can use <code>-a</code>
also on packages not hosted on well known Debian/Ubuntu VCS
servers</p>
</li>
<li>
<p>finally, you can now ask <code>debcheckout</code> to
automatically enable <strong>remote tracking of remote GIT
branches</strong>, which is usually what a maintainer wants to do
when doing a fresh checkout</p>
</li>
</ul>
<p>Enjoy!</p>
<p><small>(ah, of course all this is not uploaded yet, but you can
grab a <a href=
"http://svn.debian.org/viewsvn/devscripts/trunk/scripts/debcheckout.pl?rev=HEAD&view=log">
preview</a> from devscripts' VCS or, better, doing
<code>debcheckout devscripts</code> which is soooo bootstrapy.
SCNR.)</small></p>
git-buildpackage from debian-only to debian+upstreamhttp://upsilon.cc/~zack/blog/posts/2008/03/git-buildpackage_from_debian-only_to_debian+upstream/2009-11-28T12:00:16Z2008-03-19T15:51:06Z
<h1>Moving a git layout from debian-only to debian+upstream</h1>
<h2>... and live happily with git-buildpackage</h2>
<p>Let's say you have a <a href="http://git.or.cz">git</a>
repository you have used thus far to maintain only the Debian part
of some package (i.e. no upstream sources on sight).</p>
<p><small>OK, you're right, that would be quite an uncommon
scenario for a git repository. In fact the truth is that you are in
such a situation because the git repo was obtained converting from
a subversion repo which was using the <tt>mergeWithUpstream</tt>
stuff of <a href=
"http://packages.debian.org/svn%2Dbuildpackage">svn-buildpackage</a>.</small></p>
<p>Now that you have git's space efficiency you want to change
this, import upstream sources, and possibly adhere to a branch
layout which is compatible with <a href=
"http://packages.debian.org/git%2Dbuildpackage">git-buildpackage</a>
(which is very simple in its minimal requirements: an
<q>upstream</q> branch containing just upstream sources and a
<q>master</q> branch containing a debianized source tree).</p>
<p>Out of the box <kbd>git-import-orig</kbd> won't work since don't
have the upstream branch. Creating it branching from master (or
somewhere else) won't work either unfortunately. Indeed after
branching you will need to remove the <tt>debian/</tt> dir from
upstream and when you will merge upstream with master you will be
merging the removal as well, bad idea.</p>
<p><small>By myself I've found some horrifying solutions involving
using <kbd>git-filter-branch</kbd> on the upstream branch merged
from master and then squashing all the history of that branch with
<kbd>git-rebase</kbd>, but they are so horrible that I won't
mention them here more than this.</small></p>
<p>The nice solution came from a hint by madduck on the <a href=
"http://madduck.net/blog/2007.07.11:creating-a-git-branch-without-ancestry/">
creation of branches without ancestry</a>. Here is the complete
recipe (assumed to be run from the master branch of the repo,
before creating any upstream branch):</p>
<pre><code>$ git-symbolic-ref HEAD refs/heads/upstream
$ git rm --cached -r .
$ git commit --allow-empty -m 'initial upstream branch'
$ git checkout -f master
$ git merge upstream
$ git-import-orig --no-dch ../foo_1.2.3.orig.tar.gz
</code></pre>
<p>In short: you should create an <a href=
"http://madduck.net/blog/2007.07.11:creating-a-git-branch-without-ancestry/">
upstream branch without any ancestry</a>, in it you should create
an empty commit, then merge it (vacuously) in master, and now
you're ready to call <kbd>git-import-orig</kbd> to the rescue.</p>
<p>Feature request on <a href=
"http://packages.debian.org/git%2Dbuildpackage">git-buildpackage</a>
to support this out of the box is on the go: <a href=
"http://bugs.debian.org/471560">Debian bug #471560</a>.</p>
debcheckout bitshttp://upsilon.cc/~zack/blog/posts/2007/08/debcheckout_bits/2009-11-28T12:00:16Z2007-08-17T08:13:04Z
<h1>debcheckout: some new bits</h1>
<p>Some new bits about <a href=
"http://upsilon.cc/~zack/blog/posts/2007/08/debcheckout/">debcheckout</a> (talk is
cheap, <a href=
"http://svn.debian.org/wsvn/devscripts/trunk/scripts/debcheckout.pl?op=file&rev=0&sc=0">
code here</a>):</p>
<ul>
<li>
<p><strong>authenticated mode</strong>. Consider svn (similar
arguments stand for other VCS). When checking out alioth
repositories using the svn:// prefix, the resulting local copy
can't be committed to, since it would require (assuming you have an
alioth account and the needed permissions) a svn+ssh:// access.
"authenticated mode" is precisely for that: when checking out
well-known repositories (only alioth's ATM) you can specify an
extra "-a" argument, with an optional "-u" to specify your user
name, and debcheckout will rewrite the repository URL so that the
resulting local copy can be committed to. ATM authenticated mode
works for svn, hg, bzr, git.</p>
</li>
<li>
<p><strong>destination dir</strong>. It is now possible to specify
where do you want to check out a package repository (so that we
avoid ending up with tons of anonymous "trunk" directories). The
syntax is the common "debcheckout PKG DESTDIR" idiom and DESTDIR,
if not provided, defaults to the package name. (Thanks to <a href=
"http://kitenet.net/~joey/blog/">JoeyH</a> for the idea and the
initial patch.)</p>
</li>
<li>
<p><strong>sorry about arch</strong>, but ATM it's almost
non-functioning, and I'm not willing to lose time on it, since
among all the VCSs supported by debcheckout it's the only one I've
never used. If you want support for it, please provide code!</p>
</li>
</ul>
<h2>(Perl) Tip of the day: Switch.pm</h2>
<p>With <a href="http://perldoc.perl.org/Switch.html">"use
Switch;"</a> you will win a switch statement for your Perl
programs, which can be used as follows:</p>
<pre><code>switch ($repo_type) {
case "cvs" { my $module = pop @cmd; push @cmd, ("-d", $destdir, $module); }
case /^(bzr|darcs|git|hg|svn)$/
{ push @cmd, $destdir; }
else { die "sorry, don't know how to set the destination directory for $repo_type repositories (patches welcome!)\n"; }
}
</code></pre>
<p>This is far better than a chain of if/elsif statements and has
even a sane semantics (e.g. no need of explicit breaks, possibility
to have higher-case branches, ...). Unfortunately, it is not
possible (using a simple syntax) to match a scalar value against an
array case branch. Therefore the only way to factorize branches is
(when possible) to rely on regexp alternative branches, as it is
done in the code snippet above.</p>
debcheckouthttp://upsilon.cc/~zack/blog/posts/2007/08/debcheckout/2009-11-28T12:00:16Z2007-08-15T14:14:05Z
<h1>Introducing debcheckout</h1>
<p>Cute little tiny teeny new addition to <a href=
"http://packages.qa.debian.org/devscripts">devscripts</a>:
<em>debcheckout</em> (not yet uploaded though, in the mean time you
can get it <a href=
"http://svn.debian.org/wsvn/devscripts/trunk/scripts/debcheckout.pl?op=file&rev=0&sc=0">
from here</a>. <em>It checks out the versioning repository used to
maintain a given package</em>.</p>
<p>Sample usage:</p>
<pre><code>$ debcheckout devscripts
declared svn repository at svn://svn.debian.org/devscripts/trunk
svn co svn://svn.debian.org/devscripts/trunk ...
A trunk/debian
A trunk/debian/control
A trunk/debian/links
A trunk/debian/dirs
A trunk/debian/compat
<snip>
U trunk
Checked out revision 749.
$
</code></pre>
<p>The information about where to find a repository is extracted
parsing (in a rather dumb way actually, but I really can't stand
<a href=
"http://packages.debian.org/unstable/libdevel/libapt-pkg-dev">libapt-pkg</a>
API!) <a href="http://upsilon.cc/~zack/blog/posts/2007/02/xs_vcs_browser/">Vcs-XXX
fields</a>.</p>
<p>Intended usages:</p>
<ol>
<li>
<p>NMU scenarios: when you're NMUing, please commit your patches
(if possible of course: directly to the repository if it has
already adhered to the [[!open your VCS
campaign|DD_wide_commit_on_alioth]] I'm sponsoring, or somewhere
else if you're using a distributed VCS); with debcheckout the first
step it's easy</p>
</li>
<li>
<p>ease the creation of patches: isn't it better to checkout a
repository, fiddle around, and then just invoke svn (or whatever)
diff instead of remembering (I always forgot that!) to first create
a .orig copy of the debianized source tree?</p>
</li>
<li>
<p>retrieving the bleeding edge version of a package which includes
the patch for a pending bug you have been waiting for ages</p>
</li>
</ol>
<h2>RFC</h2>
<p>Let me know what you think of debcheckout, feature requests,
whatever. In particular let me know if I did something wrong using
some VCS, since I'm not proficient in all VCSs supported by
debcheckout; for example: I'm quite sure the Arch part is not
working ... help is appreciated!</p>
<h2>Vcs-Cvs proposed convention</h2>
<p>debcheckout can also give the ground for standardizing the
VCS-specific meanings of the various Vcs-XXX fields. In writing it
I've noticed that almost all VCSs have de facto standards about
what to put in the field, with the notable exception of CVS. That's
probably because all modern VCSs rely on some URL-like identifier
for a repository location, while CVS does not. It needs a pair
URL/module to be checkout.</p>
<p>The format I'm currently supporting in debcheckout is a pair of
space separated values "CVSROOT MODULENAME"; later on I'm using
those values as in <tt>cvs -d CVSROOT checkout MODULENAME</tt>.
Also please note that if you do not put the heading ":pserver:"
string in the CVSROOT, users won't be able to checkout the
repository without providing a password.</p>
<h2>Tip of the day: Pod::Usage</h2>
<p>Perl's <a href=
"http://perldoc.perl.org/Pod/Usage.html">Pod::Usage</a> module is
cool. Finally I can write the usage string only once instead of
duplicating it in the manpage and in the string to be printed upon
--help. Ruby had something similar, but the output on console was
so horrible that I preferred duplicating stuff for Ruby
scripts.</p>
<p><strong>Update</strong>: I've changed the link to debcheckout.pl
so that it points to the "live" version in the devscripts
repository, since some patches are already flowing in ...</p>