On Sat, Jan 3, 2009 at 11:47 AM, Georg Brandl <g.bra...@gmx.net> wrote: > 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.
Another advantage is the commit logs, which give the reviewer some insight into what the patch author was thinking. I groan internally whenever I see a patch which starts with 100 "-" lines followed by a complete rewrite of the code. Incremental diffs make it easier to follow the evolution of the code leading to a better review. For patch authors, it also conferrers the beauty of version control to their work. For example, if I review dislikes the last change, it's trivial to revert. -- Regards, Benjamin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
