I have been tracking 2.6.16.x here because Xen doesn’t have patches for 2.6.17 yet (why on earth that is, I don’t know.) But I need a few 2.6.17.x patches to the qla2xx driver. So I figure this is an opportunity to learn git.
I learned git, but then quickly learned that I can’t just pull random commits from one branch to another. I have to use git cherry-pick, which doesn’t actually pull the commit unmodified — it takes a diff, and commits a new patch based on that diff. So I expect problems later when I bump the local branch to 2.6.17.
This seems depressingly like arch/baz/bzr, and is a good reason for me to stay with darcs for now. This same operation with darcs would have been trivial, AND darcs would have automatically pulled in prerequisite patches rather than giving a merge failure and making me find them manually.
Heh, I just don’t understand arch or git. So perhaps it’s not all my fault after all :-)
But most probably the kernel tree is still too large to be tracked with darcs. ;)
Darcs isn’t optimized for this use case, so it isn’t as fast as git, but it is usable and I have used it for this.
I’ve never used darcs or bzr so I have no comments on them. Just with respect to tla/baz, applying manually selected changesets from another branch shouldn’t complicate future merges from that branch. When you pull foo–bar–patch-20 and commit it to your branch (say, as foo–mine–patch-10), the patch log in foo–mine does record the fact that it has foo–bar–patch-20 applied.
So if you later do a tla/baz star-merge on the foo–bar branch, it skips the patch-20 changeset because that’s already present and doesn’t need merging in. Having said that, I’ve never used git so I don’t know its behaviour in this regard.
A tip is to hunt down a Fedora repository, pick a srpm kernel from updates/5, and cherry pick a few xen patches there (need only two, the main one, and the compile fixes one – the others are mostly RH adaptations). PS! Requires a newer hypervisor than the one in sid, I use 3.0-unstable (so far no problems). Fedora is actively maintaining Xen in their kernels so it should be mostly up to snuff.
Forgot to mention, this is a tip for getting Xen up and running with 2.6.17.