Richard Levitte - VMS Whacker <[EMAIL PROTECTED]> writes: > In message <[EMAIL PROTECTED]> on Mon, 19 Jun 2006 20:13:48 +0100, Bruce > Stephens <[EMAIL PROTECTED]> 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? [...] _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
