<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Cees De Groot wrote:
<blockquote
 cite="mid330b6fd60601270922y3a962918y8e61136962bcec6b@mail.gmail.com"
 type="cite">
  <pre wrap="">On 1/27/06, Simon Kirk <a class="moz-txt-link-rfc2396E"
 href="mailto:Simon.Kirk@pinesoft.co.uk">&lt;Simon.Kirk@pinesoft.co.uk&gt;</a> wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Please excuse the verbosity.</pre>
  </blockquote>
  <pre wrap=""><!---->And please excuse me for snipping it all in my response :-).  </pre>
</blockquote>
Please excuse me for hacking and slashing your reply ;) We're all very
polite around here, very refreshing!<br>
<br>
Wow, I certainly generated a big thread. Thanks very much for all the
help and replies folks. :)<br>
<blockquote
 cite="mid330b6fd60601270922y3a962918y8e61136962bcec6b@mail.gmail.com"
 type="cite">
  <pre wrap="">The basic question is: can you do optimistic version control with MC
with a larger group. Modulo some performance problems (which, it turns
out, are related to source file writing and should be fairly simple to
remove), I think with MC(+MCC) you have everything you need in the
tools.</pre>
</blockquote>
I'm not sure what MCC is. Is it MC2? I have read in the list that the
performance of MC2 is vastly improved over MC.<br>
<blockquote
 cite="mid330b6fd60601270922y3a962918y8e61136962bcec6b@mail.gmail.com"
 type="cite">
  <pre wrap="">You cannot (should not?) name versions, but I've used "special
comments" in CVS with great success (I first used CVS when it was a
bunch of shell scripts around RCS, so I'm reasonably experienced with
the system), and with MC that shouldn't be any different.</pre>
</blockquote>
I may have mislead somewhat with any emphasis on CVS, though
- I'm talking more from the perspective of somebody who now uses svn -
therefore I no longer need to worry about tagging (or special comments
as you put it?) revisions in CVS, svn increments the revision number
repository-wide on every commit, but I digress somewhat.
<blockquote
 cite="mid330b6fd60601270922y3a962918y8e61136962bcec6b@mail.gmail.com"
 type="cite">
  <pre wrap="">The merge tool is simple but sufficient (and easy enough to extend - try to
extend CVS while you're working with it ;-))</pre>
</blockquote>
You have a good point about the extensibility of MC vs CVS, and it's
indeed nice to know that the system in hand can be modded for our needs
very well.&nbsp; However, in contrast to that it is my opinion a
fully-fledged scm should already meet the requirements that I loosely
specced out in my tome of an original email. Customisability is great,
but with the merge tool seems to be a case in point: I think the merge
functionality of Eclipse is a good model (well, certainly the best out
of all the merge tools that I previously used) to start with, but how
does MC compare? I can't categorically say as I haven't used MC enough
(I'm using it now so I'm sure I'll hit the point to be able to compare
soon), but the graphical "helpers" in Eclipse really make merging
clear. I hope the merging in MC and Squeak measures up.<br>
<br>
So I'll have to leave this here, for now: But I'll be happy to post my
interpretations of MC/Squeak merging compared to Eclipse/Araxis
Merge/diff/etc once I've got a bit more experience.<br>
<blockquote
 cite="mid330b6fd60601270922y3a962918y8e61136962bcec6b@mail.gmail.com"
 type="cite">
  <pre wrap="">, and branching support is very good.</pre>
</blockquote>
<blockquote
 cite="mid330b6fd60601270922y3a962918y8e61136962bcec6b@mail.gmail.com"
 type="cite">
  <pre wrap=""> Every MC version carries around its whole version history,
so developers can commit versions to private repositories and then a
final version to the shared repository; MC will see the gaps and just
skip over them.  </pre>
</blockquote>
That's good to know, as branching is integral to my development model.
I'm really thinking now that a large part of my worry with MC is that
the documentation just doesn't cater well to people like me. I've read
through the documentation on MC are wiresong.ca, and doesn't help much
in the description of how MC works. There are no diagrams describing
the branching model, or dependencies. A brief mention of the Merge
button
that Avi mentions in one of his replies to this thread. No mention of
comparisons between svn/cvs/$YOURSCMHERE and MC. These things would all
massively help the understanding of MC - and very importantly grease
the wheels of transition between the more commonly-used programming
languages and Squeak. Let's face it: the easier that transition is the
better, because I think Squeak has such massive potential and every
block that stops it being adopted is a Very Bad Thing (tm).<br>
<blockquote
 cite="mid330b6fd60601270922y3a962918y8e61136962bcec6b@mail.gmail.com"
 type="cite">
  <pre wrap="">[snip]
Note, by the way, that I would object against any single system under
development of a single 30-40 person team :-).  </pre>
</blockquote>
I may have mislead a bit here as well - it was a single system, but it
was
about 50 seperate CVS (then svn) modules which were combined using
J2EE/Tomcat/Eclipse cleverness into one coherant system :)<br>
<br>
I think the fact that it all worked smoothly was a testament to the
development system we'd put together ;)<br>
<br>
Cheers,<br>
Simon<br>
<br><br>
<P align=left><FONT style="BACKGROUND-COLOR: #ffffff" size=1>This message has been scanned for viruses by </FONT><A href="http://www.blackspider.com/"><FONT style="BACKGROUND-COLOR: #ffffff" color=#000000 size=1><U>BlackSpider MailControl</U></FONT></A></P>
</body>
</html>