[Monotone-devel] Re: Subversion Update Command Considered Harmful

[Bruce Stephens]

Richard Levitte - VMS Whacker <address@hidden> writes:

> In message <address@hidden> on Mon, 19 Jun 2006 20:13:48 +0100, Bruce 
> Stephens <address@hidden> said:
>
> monotone> 
> <http://willowbend.cx/2006/06/19/subversion-update-command-considered-harmful/>
> monotone> 
> monotone> I'm not quite sure what it's saying, except that review is
> monotone> important, and that CVS and subversion don't make it so
> monotone> easy.  I'm not sure why he argues that that makes git
> monotone> better.
>
> To me, it connects with what is suggest in the monotone manual,
> commit-then-update-and-maybe-merge.

Very much so, I think, especially with extra certs or something so
that one can mark revisions that have been reviewed.

> Other than that, I think the classic thing, to have the diffs of each
> new change sent to a mailing list works well for review.

It works for us (well, we email the diffs to one or two chosen
reviewers (random developers who're likely to know the area of code)
but it's the same principle).  

It feels like something that could be helped by an SCM, though.  If
the code's committed somewhere, then presumably it would be easy to
persuade some buildbots to do their thing on the code.  If the code's
committed, then reviewers can easily commit minor alterations (rather
than emailing suggested changes back, which sometimes just seems to
end up in a confused mess for us).  Generally, it just feels write to
commit things routinely, even when you don't much want people to look
at them, yet.

One thing the email process does give is a way to abandon a diff (if
it's just not worth reviving).

Now I come to think of it, if monotone had a variant of explicit_merge
that let me say that the merge should look exactly like one of the
revisions, that would be sufficient.  That's probably not too hard to
implement, either.  Does that seem useful to anyone else?

[...]