Mercurial is bad for community code reviews

[Arne Babenhauserheide]

Am Dienstag, 18. Dezember 2012, 16:46:41 schrieb anatoly techtonik:
> There is no sense in making secure reviews when anybody with access right
> can commit changeset under your name, 

That is why I use the GnuPG extension. You cannot fake that without stealing 
my private key.

> so there is no point to develop
> security-concerned branch if this thread. What is needed is a system like
> in Git that has separate committer and author metadata, but enhanced to
> have changesets annotated with several reviewers (maybe even authors).

Why not just use the commit message for that? If you’re prepared to change 
history, you can just add a final line to the messages saying 

“reviewers: …”

Or even split it:

“--- review notes ---

foo bar baz”

> > which does not show the signature changesets, but annotates the revisions
> > instead.
> 
> You need to store annotations somewhere, because they are not present in
> original changeset until it is reviewed. It is a separate layer of
> metadata, which is added on top of the first layer (layer that's limited to
> the context of single author and commit/pull problem domain).

You can either represent this layer within the existing structure (as tags and 
GnuPG signatures do it). Then the representation of history makes sure that 
you see what you need (for example tags are simply shown as tags on the 
history).

Or you can add a different kind of storage. But this different storage would 
only be useful if you want to be able to get rid of the information at some 
point.

> Featurecreeping over this idea - the second layer of metadata could provide
> information specific for review processes - changeset history, squash and
> refactoring traces, review history in the form of level-2 log messages.

You can already do that: Have a look at mutable-hg:

→ http://hg-lab.logilab.org/doc/mutable-history/html/

That is about the most intriguing evolution in version tracking I saw in the 
last few years.

> It can evolve into a concept of MQ-like feature branch for collaborative
> work over changesets.

That’s exactly what mutable-hg provides.

> > You can just add them all as author (-u "Author 1, Author 2, …").
> 
> Nice hack.

s/hack/core feature/ :)

> > Are there more features you’d like to have than the ones you already asked
> > about?
> 
> Hmm.. Not sure. A pony?

There’s one a few streets down the road, but I can’t give it to you :)

I ask, because it looks like we’re pretty close to the solution you wish for. 
So if we can just get around those few rough corners, it could be exactly the 
right system for you.

Best wishes,
Arne
--
singing a part of the history of free software: 

- http://infinite-hands.draketo.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 316 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20121218/cbe44237/attachment.asc>