* Bruce Momjian:
>> The fact that you're still thinking in "patch application" means you're
>> still stuck in the CVS worldview. To "apply a patch" in a distributed
>> SCM(*) really means to merge a branch into the main development branch.
>> Of course, you can still see the entire "diff -c" if you want.
>
> How do I modify the patch before application if it comes from a branch?
You refuse to merge until you reach a point which is acceptable. One
large project even gets so far as to ask the submitter to clean up
history before merging it, so that all that polishing is gone and does
not show up after the merge. In the official tree, there's just a
clean sequence of incremental patches.
I'm not really sure if this is the right model for every project.
Personally, I'm a fan of the write-after-approval approach: per ACL,
everybody has got full write access, but most developers might only
apply their patches after some review and a formal go-ahead. This has
the advantage that everyone can fix obvious mistakes or back out wrong
patches if necessary, and it nicely distributes the integration
overhead.
But obviously, there are fairly successful projects which use very
different models, and switching just because the technology is there
to do things differently doesn't make much sense. But once you run
into problems like tagging a release taking hours, you should really
contemplate a move to Subversion. 8-P
