On Wed, 16 Mar 2005 18:18:52 +0100, stéphane ducasse
<ducasse at iam.unibe.ch> wrote:
> Hi colin
> 
> marcus made this morning an interesting remark about MC. he said that
> what he would like is
> something that does not only save a version on the server but merge it
> with the latest version, check conflicts and commit it. I do not know
> if this is making sense to you but I wnated to pass you the idea.

Sure, that's basically what CVS does: it makes you merge as part of
the commit process.  It wouldn't be difficult to implement a policy
for Monticello that did this, but it's not the default we chose for
this reason: what you end up with is a version on the server that has
never been inside an image.  You have no idea if it's self consistent
in any way: is it loadable, do the tests pass, etc.  If every commit
is of a real, live image state, then the developer has a chance to do
some basic sanity checks after the merge but before the commit.

Still, it's a matter of taste.  One thing I've noticed is that on team
projects, about 1/4 of the versions I commit are simply merges - they
don't add anything except to merge my latest version with that of
another team member.  It's useful to mark those points, but it seems
silly to have to do it manually; maybe what we want is some simple
metadata flag to distinguish "merge versions" which are the result of
an automated merge process from "committed versions" which provide
some human-added value.

One thing MC2 does is impose greater separation between, I guess,
mechanism and policy - it tries to allow a wider range of development
styles, so that, for example, a changeset that patches 10 packages is
just as valid, and just as well supported, as a snapshot of a single
package version.  So it may well also end up being easier to customize
the system to your preferred commit styles , like the one Marcus
describes.

Avi