git, submodules and extensions

Hi,

in general I'd really like to move to git+github. That aside I think the
popular DVCSs (git, hg, bzr) won't work for PHP. Let me explain why oh
and please correct me if I'm wrong - I'd be happy if this can be
solved.[1]

How does a DVCS work? (just the relevant part)

The DVCS systems treat the whole tree as a single project tightly bound
together. This has some benefits like moving files (or with some systems
even chunks of files) around shouldn't break merges. But on the
down-side one always has to checkout the whole project including all
components.

What's the problem with PHP here?

In PHP we have our extensions. Over the recent years we got used to use
PECL as incubator platform and as place to dump unmaintained extensions.
For adding/dropping extensions to/from the core we did some cp/symlink
magic on the CVS server and, by doing this, kept the commit history of
the extensions - at least more or less.
This isn't possible with the DVCSs as all files of the tree build the
project. And we can't add directories including their history but the
PHP tree would have to include all extensions we ever might want to add
so everybody has to check them out... which gives us a big bunch of
useless stuff there...

what are the solutions offered by the DVCs and why won't they work?

- Using script magic to rewrite history when adding/removing extensions.
  That's a really bad approach.

- "submodules". Submodules are in a way similar to svn:external but
  instead of referencing the repository location a specific commit is 
  referenced. This means after each commit to an extension the master
  project needs a commit to be informed about the new commit ID of the
  extension state. When doing that one also has to keep in mind to push
  all parts else other developers find a reference to an commit which
  isn't available. See [2] for an introduction to git submodules,
  including a 15 minutes webcast. The main purpose, as I see it, there
  is to have externally developed libraries and update them from time 
  to time but treating these libs as truly external parts from the
  master project.
  
  Considering the amount of commits touching different extensions at
  once we have this seems rather troublesome.

Possible solutions I see:

- Add a bunch of scripts around the DVCS to help us here, sounds like
  no fun at all

- Change our processes to develop extensions externally as much as
  possible and bundle "releases" from time to time. Pain for migration
  and quite bad for API changes (or when changing error messages which
  appear in different tests...)

- Migrate to svn, as planned, then developers can use their git if
  they want.

Anything unclear or other ideas?

johannes

[1] While writing this I talked to my brother who pointed me to
    http://www.selenic.com/mercurial/wiki/index.cgi/ForestExtension
    maybe that would work, so BitBucket+hg? :-)
[2] http://book.git-scm.com/5_submodules.html