Martin v. Löwis schrieb:
I don't know about others, but downloading and applying a patch doesn't bother me (it's actually much quicker than doing a whole new SVN checkout).
Same here. In fact, when I had to backport patches before the usage of svnmerge.py, I would always apply the original patch multiple times, rather than trying to use svn merge.
Integrating patches is only tedious if they don't apply cleanly anymore, in which case I usually ask the contributor to regenerate it (which they often can easily do as they had been tracking trunk in their own sandboxes).
You could clone one of the existing DCVS mirrors and open a branch on a public hosting service (bitbucket.org, launchpad, etc.). The annoying thing, though, is that it requires your co-workers to learn the DVCS in question.
We (as his co-workers) would continue to request patches. So the DVCS better has a convenient way to generate a patch (even from multiple DVCS commits). I think that's what (git) people call "feature branch": a branch with the sole purpose of developing a single patch.
One good thing is also that a big change is usually split up into multiple commits, and each commit can be exported as a single patch. I for one am much better at reviewing small, isolated changes, than glorious rewrites of a whole module, and I suspect I'm not alone in this. So it's much better to have a large change chunked into small, manageable bites that can even be applied individually without having to pull in everything at once.
-- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.