Mercurial is bad for community code reviews

[anatoly techtonik]

On Tue, Dec 18, 2012 at 2:11 PM, Arne Babenhauserheide <arne_bab at web.de>wrote:

> Am Dienstag, 18. Dezember 2012, 11:09:19 schrieb anatoly techtonik:
> > This is the most unfortunate. I wonder if it is possible to add a second
> > layer of meta information about changesets when they are merged without
> > breaking history link with original changeset?
>
> You could setup a workflow where the reviewers sign changesets after
> review.
>
> That would also reflect very well,  what the code reviewers actually do.
>
> To start it in a currently active project, get the maintainer to sign a
> given
> release and then require everyone who accepts a pull-request to sign it.
>
> To make that simpler, add a hook which enforces that all pushed heads are
> signed:
>
> http://code.google.com/p/hghooklib/wiki/CheckGpgSig
>
> The effect is that
>
> (a) You get a safer workflow (everything is signed with GnuPG)
> (b) The reviewers get credit for what they actually do: Sign off changes
>
> To make this more convenient it could be useful to have an extension which
> can
> check from whoma given changeset was signed off: Just check for the
> topologically next signature(s) after the changeset.
>
> hg reviewer REV → who committed and signed the signature(s) for this REV
>

GnuPG requirement is too strict for an open source project, and this still
pollutes the history requiring one more changeset per review. How to record
chagesets done by several people? How to make onsite merges with reviewer
names on BitBucket? There should be a native version control support for
distributed reviews.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20121218/06a43585/attachment-0002.html>