I created a Drupal repository for myself, and am putting it up for general use by whoever wants.

There are two Drupal branches for now, available at bzr://bzr.wyz.biz/drupal/6-downloads and bzr://bzr.wyz.biz/drupal/6-patched . There's a web interface for casual browsing at http://bzr.wyz.biz/.

(Hey - I couldn't resist picking this hostname. 3*3 letters, of which 3 z's and 'one and a half' vowel. Isn't it just perfect? :p)

Why this repository:

A smaller reason: it's easier than installing Drupal and all needed contrib modules automatically, and keeping up to date on all those modules. (Just 'bzr update' your checked-out tree, from the shell prompt of your host.)
But the important one: because the distributed versions of contrib modules just don't work for me out of the box, too often. I end up modifying a lot of modules myself, sometimes by applying patches I found in issue queues (but mostly having to create my own modifications/patches). The patches usually end up in Drupal contrib downloads some time after I create issues for them on drupal.org, but there are always changes (temporarily?) lingering around.

A setup with multiple VCS branches:

• obviously is a nicely centralized place for maintaining patches. (And for patches that are not 'generally applicable' enough, I'd just create different branches in Bazaar, but I haven't encountered the need for that yet.)
• is a low-overhead way of making sure relevant patches are applied to all drupal installations.
• makes it easy to merge 'upstream updates' (to Drupal core and contrib modules) with applied patches. (See my setup below.)

I'm sure there are also other ways of keeping websites up to date. For instance, the Ægir hosting system tracks full site updates, not only source code. I haven't tried it out and maybe I should... but I don't think it tackles the problem of 'keeping my patches applied, across updates'. (Yet?) And I don't know if I could live without that any more.

Why Bazaar:

For now, I think it's the DVCS that best suits my needs, and I've made a story on the decision process.

The working model:

There are two branches on bzr.wyz.biz. Maintaining two branches helps keep 'official' updates to contrib separate from other patches, and simplifies the process of updating patched modules. (Which is equivalent to 'reapplying the patches to updated modules'.) Read on for details.

See the graphic above.

The first branch in the bzr.wyz.biz repository is 'drupal/6-downloads', which holds drupal core plus contributed modules as downloaded from drupal.org (i.e. not patched by myself).
This is (originally) a branch of FourKitchens' drupal/6 branch which has apparently grown to be 'the default Drupal core Bazaar repository'. (After all, why duplicate work?)

This branch has a working tree, though you won't notice that. I use the tree to download contrib modules. Preferrably real releases (using drush1). I 'wget' -dev releases when I need the newest functionality in websites on a site, or when I need to patch a module and the patch would change between the current release and the current -dev release. These downloaded modules are committed to the branch.

There is an extra file 'README-DOWNLOADS.txt' in the branch root, documenting which '-dev' versions of which modules the branch holds.

When there are updates to drupal core, these are 'bzr merge'd from the upstream FourKitchens branch and committed. Since there is no overlap between manually downloaded & updated (contrib) files and files present in the upstream branch, this should never generate merge conflicts. It's pretty safe. (This is why I choose to use a working tree on the server. I could also have used a checkout on my own computer to do download/merge upstream files and then commit to the branch on bzr.wyz.biz, but that would just be slower...)

The second one is 'drupal/6-patched', which obviously holds the same tree with all patches (and other modifications) applied. It's (originally) a branch from 'drupal/6-downloads' (hence the grey arrow).

This branch (like most brances stored in a repository) has no working tree. For development/patch/merge work, I have created a checkout (or 'bound branch', if you like) of 'drupal/6-patched' on my laptop. (This is what the 'branch plus working tree' on the bottom right of the above picture represents.) I download patches from whereever I find them and/or make modifications myself, and commit these to the (local checkout, and automatically to the bound) 'drupal/6-patched' branch.

There is an extra file 'README-PATCHES.txt' in the branch root, documenting these modifications. (The README-DOWNLOADS.txt file is supposed to never be changed in 'drupal/6-patched', because that only documents modifications made in 'drupal/6-downloads'.)

When there are updates to modules on drupal.org, these are not downloaded to the 'drupal/6-patched' tree. Instead, they are first downloaded and checked in to 'drupal/6-downloads'. I then merge the updates from there into my checkout tree. This will update patched files without problems, except if a patch has modified the same lines in a file as the new update does. This almost never happens, so updating the 'drupal/6-patched' branch with new versions of contrib modules (or Drupal core) is usually very easy. (And if not... I need to spend some time figuring out whether the patches still apply, and how they should be modified.) After that, the updates can be committed to the 'drupal/6-patched' branch.

For the purposes of illustration, below is how the 'bzr qlog' command shows the history of changes to 'drupal/6-patched'.

• The 'green line' represents the change history of the FourKitchens Drupal Core branch; at the moment of the first checkin to 'drupal/6-downloads' (r8), it diverged.
• The 'blue line' represents the change history of 'drupal/6-downloads'; at the moment of the first checkin to 'drupal/6-patched' (r9), it diverged.
• Adding new modules (or updating modules or merging core changes) to 'drupal/6-downloads' is represented by blue dots. These updates are usually merged (via my working tree and committed) into 'drupal/6-downloads' soon afterwards. The commit is represented by a grey dot, and the 'merge' by the diagonal line leading from blue to grey. For instance, r8.1.3 to r18, and r8.1.5 to r21.
• When a new core update came out (by pure coincidence one day after 'drupal/6-downloads' had diverged), it was committed by FourKitchens to their branch (in this graphic, numbered r7.1.1). I then merged the changes from there and committed them to 'drupal/6-downloads' (r8.1.1) and again merged the changes into my development tree and committed them to 'drupal/6-patched' (r10).

Using the repository

The '6-downloads' branch is only there for easy merging; I always use '6-patched' for the websites I run.

Since a website tree does not need local history or other operations than 'bzr update', I usually do a 'bzr checkout --lightweight bzr://bzr.wyz.biz/drupal/6-patched' (which uses up the least space and checkout time).

There is one thing about 'using the same tree for all your websites' which is at the same time an advantage and a disadvantage: you have all modules immediately present on each website. This can make you feel lost when seeing the 'module list' admin screen. And what's worse: it gets terribly slow. I recommend the 'System module' (inside the 'util' project, preferrably v6.x-3.x or higher) for keeping you from wanting to jump off a cliff at some point...

Site directories in sites/ cannot be 'bzr ignore'd --at least, not without cluttering up .bzrignore in the main repository with useless cruft. So: your own sites/* directories (and maybe some added sites/all/*/* directories) will always show up as 'unknown' when you do a 'bzr status', and that is the way it should remain, I guess.

As for code development: I have only two branches, for as long as I am not doing any larger development of features / new modules yet. ('6-patched' contains mostly small fixes, which will hopefully 'disappear' as they are applied to the official upstream revisions. So there is not a lot of use for keeping changesets separate in separate branches.) Once I start doing some serious longer-term hacking, you'll probably see other branches appearing in the repository; I haven't given that a lot of thought yet.

Is it for you?

Check it out and see if you like this mechanism for your own use.

You're welcome to track the trees at bzr.wyz.biz. Especially if you are a PostgreSQL or PHP5.3 user (and use the contrib modules I use), using this 'drupal/6-patched' tree will save you some time/grief, as compared to downloading and testing all contrib modules yourself.
I'm open to feedback; it may help me keep the repository up to date if I know people are using it. And if someone wants write access, to be able to add modules to 6-downloads / patches to 6-patched: we may be able to work that out. Drop me a line.

1. 1. not that that matters in any way; I could have used wget, but drush is a little easier