MC, P2P, distributed collections

stéphane ducasse ducasse at iam.unibe.ch
Wed Mar 16 17:47:31 UTC 2005


>
> 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.


Oh yes, I would not like to have a commit without making sure my tests 
pass.
I'm spoiled I only used Envy, store or MC for code managing :) and CVS 
only for latex :)

> 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.

May be yes.

> 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.

Seems cool. I played a bit with the package browser of alex yesterday
and gave him feedback I think that the next version will be usable.

Stef

>
> Avi
>
>




More information about the Squeak-dev mailing list