Hi,
I think it never occurred to us to do it differently. Our previous source control experience was with Panvalet, which was in no way distributed. It made sense to us to have an official integrated image and having that on an official integration box was a relatively foolproof way of achieving that.
The process we used went like this. Once a team was ready to checkin, they would verify that they had the latest version of the system, resolving any conflicts that may have been created and then run the test suite on their computer. Once they passed there, the process was repeated on the integration machine. We ran all of the unit tests and a subset of the acceptance tests. The complete acceptance suite was run overnight. After the tests ran successfully, we did some ENVY magic to mark the updated code as the new master. About once a week, a build was formally marked as an edition or some such name.
We constantly monitored the time needed to run the test suite and uses that as a driver for speed optimization. At one point we created the ability to run the tests both A-Z and Z-A, so we would fire off both and stop them when they overlapped.
If a test failed during the overnight acceptance test run, it was promoted to the integration test suite.
chet
Chet Hendrickson
[email protected]
Tel 248.345.7258
http://www.hendricksonxp.com
> On Apr 9, 2017, at 9:50 AM, [email protected] [extremeprogramming] <[email protected]> wrote:
>
> Hello all,
>
> I have a few historical questions after being away from this group for more than 10 years...
>
> Because I've never more than played with Smalltalk I'm not familiar with how version control works in Smalltalk. I knew that there was something called Envy/Developer but I never really looked into it. Consequently I never really understood why C3 used a central (but manual) integration server. Coming from a C++/CVS background I didn't understand the need. At XP2000 there was a presentation about something called Team Streams, which looked suspiciously like what CVS was already doing at the time, CVS was clearly much, much more primitive than the Smalltalk tooling on other respects.
>
> I've long been annoyed by the fact that the term CI has come to mean 'using a build server' to many people and recently there's been a movement to popularise the original concept under the name Trunk-based development. Unfortunately the peopl e behind it seem to be unaware that that is what we used to call CI in the early days. There have been some misunderstandings on the Wikipedia CI page too. This has led me to delve a bit more deeply into the early history of CI.
>
> From a description of Smalltalk version control by Stephan Eggermont and from skimming through an old Envy manual online I get the impression it worked like this:
>
> It used versioning on method, class, subapplication and application level. Each version was numbered, tracked its ancestors and was linked to an author. Unpublished and still mutable versions were referred to as editions. All versions (and editions?) were stored in a central server and were visible to other developers, subject to access control rules. People could mix and match versions into their own versions. Presumably there was some logon mechanism. If people paired they probably worked on both parties' stories during one session and had to switch between versions.
>
> If i t was possible to switch between two developers' working sets at one machine, what was the integration machine still needed for?
>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.