Re: source mgt....[_HAS_ gcc relevance]

[Tom Lord <lord@emf.net>]

       The advantage of the SCM-assisted merges is really that when
       you trust the other side, it becomes a non-issue.

It helps even when you don't implicitly trust the other side.

A remote, less-than-implicitly-trusted developer submits a patch.  You
kick it back with comments.   Meanwhile, your mainline has gone on.

Before resubmitting, that developer has to update his patch to reflect
the new head-of-mainline.

If that remote developer has his own repository, but a true,
first-class branch of your mainline, then he can use SCM-assisted
merges to keep his patch up-to-date.

A similar case occurs if you accept his patch, but then there's still
more to be done with it -- further development.  In that case, there's
effectively back-and-forth merging between your mainline and his
remote branch.  "star topology merging" handles exactly that case.

In relation to these features, it's interesting to read the recent
narrowly-on-topic traffic on the gcc list (Mark and Zack's
coordination with everyone else, comments about forming intermediate
merges, and calls for help with testing branches).  I think that some
of the issues around synchronizing work would be somewhat relaxed by
applying these features; intermediate merges would be well
facilitated and _partially_ automated (regardless of access writes of the
authors); testing branches could be made more effectively
automated (again, orthogonally to access rights).

-t