Getting back to a working copy of WebKit:

$ svn up
svn: REPORT request failed on '/repository/webkit/!svn/vcc/default'
svn: REPORT of '/repository/webkit/!svn/vcc/default':…
…413 Request Entity Too Large (http://svn.webkit.org)

Combine svn and http transport… And the approximate size of a working copy is around 800MB…

Oh. Now. http://git.debian.org/ has pkg-webkit/upstream.git and pkg-webkit/webkit.git (Debian packaging).

Considering the first one, the history from June 2007 until takes 120MB (du -sh .git). There are two branches: filtered (180MB, .git included), and svn (460MB, .git included).

Also, checking ccache is installed and ready to be used (e.g. by prepending $PATH by /usr/lib/ccache) is always a good idea. Using colormake might also be interesting (once installed, set $MAKE to colormake, done).

So: Can I has a wokking copy?

Sure:

# Fetch
$ git-clone git://git.debian.org/git/pkg-webkit/upstream.git
$ cd upstream

# Check local branches
$ git-branch
* filtered

# Check all branches
$ git-branch -a
* filtered
  origin/HEAD
  origin/filtered
  origin/svn

# Work on the full sources, and make sure
$ git-checkout -b svn origin/svn
$ git-branch
  filtered
* svn

# Set the build environment, and build
$ ./WebKitTools/Scripts/set-webkit-configuration --release
$ ./WebKitTools/Scripts/build-webkit --gtk

# In case the build is interrupted, “make” from there
$ cd WebKitBuild/Release
$ sudo make install

The goal is to lump some commits together because they should have been just one. That's the kind of thing that can be done with svk by calling svk push -l.

Setup

A (remote) origin branch, a local master one, regularly pulled and pushed. Some commits are in the master branch, and they should be pushed into origin as a single commit. The log diff can be seen by using git-log origin/master..master.

Create a single, equivalent commit

git-checkout -b merger origin/master
git-merge --squash master       # HEAD isn't modified (squash commit),
                                # fast-forward
git-commit -m 'Commit message'
git-log origin/master..merger   # Shows the wanted diff

Apply that diff to master

git-checkout master
git-reset --hard origin/master  # Reset master to origin/master
git-log origin/master..master   # Shows nothing
git-rebase merger master        # Apply the (only) additional commit
                                # from merger to master
git-log origin/master..master   # Shows the wanted diff

Finition

git-push origin master
git-branch -D merger

Some bits of work, but a nice occasion to handle some git commands.

Now the git repositories put under ~/public_git are visible through gitweb, here are the URLs for my git repositories out there:

• http://git.debian.org/?p=users/kibi-guest/debootstrap.git;a=summary
• http://git.debian.org/?p=users/kibi-guest/deblog.git;a=summary

My debootstrap branch is quite useless, now that upstream told me to do things differently, but at least it contains a working debootstrap for GNU/kFreeBSD.

DebLog is a Perl module to access build logs. It is not yet finished, but it can help fetch some logs and compare them. See the scripts/ directories for examples.

SVN with git. One package: git-svn; two tools: git-svnimport, git-svn.

First thought: Oh, I don't need to modify things, let's use git-svnimport. Bad guess. After some revisions fetched from blender.org, the download gets stalled, and no way to resume. That's documented in bug #436930.

After having asked on #git/irc.freenode.net, it looks like git-svnimport is quite unmaintained and that git-svn is the way to go.

git-svn clone https://svn.blender.org/svnroot/bf-blender

Far better, but after 6000+ revisions, interrupted download, and impossible to resume it. Damn (but thinking about it, I might have used the wrong command). Another way to do that:

git-svn init https://svn.blender.org/svnroot/bf-blender

# Get 10 revisions
git-svn fetch -r BASE:10

# Get the rest
git-svn fetch -r BASE:HEAD

Using -r BASE:HEAD is quite interesting since only the needed revisions are fetched.

Important: Don't forget to use git-svn and not git.

Now, two branches: master, local, and git-svn, remote. Go!

$ du -sh .git/
1.1G    .git/

$ time git gc
real    67m14.503s
user    7m26.616s
sys     0m57.740s

$ du -sh .git/
221M    .git/

And all the project's history is there! The branches, tags, trunk are all available as directories, but it is also possible to have them as remote branches, using the following options: -T trunk -b branches -t tags.

To share easily one's git branches, it is possible to store $foo.git repositories in ~/public_git on alioth, the repositories being then available at git://alioth.debian.org/~$login/$foo.git.

Edited: missing ~ before the login name...

Summary of my setup

1. Install ikiwiki

2. Choose a hierarchy for the blog entries. It is blog/$year/$month/$day/$title.mdwn right now, and tags are stored under tags/.

3. Enable some plugins. Currently:

   • sidebar: integrate a menu bar on each page;

   • tag: ease the creation of tags and links;

   • pagestats: needed to generate automatically the list of the tags;

   • prettydate: specify a string format for the Posted/Last edited dates;

   • shortcut: enable many interesting shortcuts like [[debbug NNNNNN]] or [[debpkg package]].

4. Create some placeholders:

   • index.mdwn;
   • tags.mdwn;
   • tags/*.mdwn (one for each tag),

5. Write a configuration file: ikiwiki.setup, enabling these plugins, and containing some basic information like origin and target directories.

6. To do:

   • learn the syntax for real;
   • automate the creation of index.mdwn placeholders under blog/$year, blog/$year/$month, and so on. Extend a module to do so?
   • poke the author of the calendar plugin so as to get the code;
   • report that shortcuts containing slashes aren't working;
   • integrate it in git.

The idea is to have backups of working files easily, as well as easing some tasks like sending bugreports with attached files, ensuring msgcat has been run, fetch the new templates.pot file from the server, etc.

Various thoughts on using git to manage localization.

• hierarchy:

  • l10n.git

  • l10n.git/po: upstream PO files.

  • l10n.git/po-debconf: debian debconf screens.

  • l10n.git/scripts: scripts to ease the manipulation of translations, update of working files, etc.

• ideas:

  • adaptation of bubulle's script for this layout, maybe using ReadLine to ask for the package, version, and file to send;

  • same kind of scripts for sending RFR (or RFRn), LCFC (or LCFCn) from the commandline.

  • script to which a TAF or MAJ mail can be piped, so that the appropriate file is fetch from the server;

  • script to which a diff can be piped, so that it gets applied (if possible) and commit'd in the tree, automating the addition of the submitter's mail in the log;

  • script(s) to check for missing msgcat invocations, incomplete translations and so on.

• open questions:

  • how to handle the tagging of the released (BTS'd) files? Will tagging with $package/$version/$bug be too much?

  • how to handle the Mail-Followup-To header for the second kind of scripts? Sounds like not that possible, after all.