Frank,
No I meant what I said .... I'm not talking in a literal sense, but a functional sense ....
With Metacello I can 'clone' version 3.0.6 of Seaside30, i.e., make a local copy of all of mcz files that make up version 3.0.6 in local directory. If I load the files into an image I can edit the files including add new files, etc. and then 'commit' version 3.0.7 to my local directory, which includes new versions of files and a new version of the configuration. I can 'push' my local files (mcz and config) to the common repository and even 'pull', but when it comes to 'merge' it all falls apart, because 'merge' is not supported at the Metacello level. Monticello does a great job with merging and Metacello needs to step up to the plate on merge:)
Totally agree with you about builds...if customization is required, then each person around the world that does "a build" is not guaranteed to et exactly the same results...
Dale
----- Original Message ----- | From: "Frank Shearar" frank.shearar@gmail.com | To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org | Cc: "VWNC" vwnc@cs.uiuc.edu, "Janko Mivšek" janko.mivsek@eranova.si, Pharo-project@lists.gforge.inria.fr | Sent: Saturday, January 28, 2012 1:45:04 PM | Subject: Re: [squeak-dev] Re: [Smalltalk for small projects only? | | 2012/1/28 Dale Henrichs dhenrich@vmware.com: | > Janko, | > | > Metacello itself needs work to make it usable by groups of | > developers ... the lack of merge capability is a real hindrance to | > being able to have multiple folks work on the same project and use | > Metacello ... | > | > I imagine that a Metacello configuration is the moral equivalent of | > a git repository. It should be possible to find "moral | > equivalents" of the various git operations: clone, push, pull, | > branch, checkout, merge, commit. It is something that I will be | > looking into in the not too distant future, since I want to | > improve the usability of Metacello for groups of developers. | | Um, do you mean Metacello or Monticello? Metacello seems like the | maven of Java world: "Here's what this artifact contains, its | dependencies, where you can find them, etc. etc." | | > I agree that integrated tools is another area that needs | > attention.... when it is time to commit your work there are just | > too many different windows and browsers that you have to monkey | > with to save your work ... | > | > Another area that shouldn't be neglected is the notion of basing | > things on a minimal core image and automated builds for | > individuals ... We've got folks doing good things with Jenkins but | > I sense that with each installation there are things that still | > need to be customized in the build process itself. It should be | > dead simple, like compiling a c file when you know the path to an | > image... | | A build should be a single command, with no customisation required at | all. This is especially important in large projects. Being able to | customise/parameterise a build means having an artifact but not | knowing what went into building it. | | Otherwise, I agree. Luckily, more and more folks are starting to use | Metacello, and building images up from some small base. | | frank | | > I think we may focus too much on the in-image tools and not enough | > on the external tools that are just as important. | > | > We need to make it easy for a developer (in a team of developers) | > to check out a version of a minimal1 image, do a reproducible | > build of the correct version of the project, then fire up the | > image and do his or her development thang, | > commit/push/pull/merge/bang and then the next developer does | > pull/merge/build/boom to pick up the changes for her image and so | > on ... This involves more than just in-image tooling. | > | > Dale | > | > ----- Original Message ----- | > | From: "Janko Mivšek" janko.mivsek@eranova.si | > | To: Pharo-project@lists.gforge.inria.fr | > | Cc: "Dale Henrichs" dhenrich@vmware.com, "The general-purpose | > | Squeak developers list" | > | squeak-dev@lists.squeakfoundation.org, "VWNC" | > | vwnc@cs.uiuc.edu | > | Sent: Saturday, January 28, 2012 12:16:55 PM | > | Subject: Re: [Smalltalk for small projects only? | > | | > | Dale, | > | | > | I agree with you that source code management is where we are | > | weak. A | > | process therefore, as James already said. | > | | > | In SCM VisualWorks is ahead in my opinion, even that Store is | > | also | > | not | > | perfect yet. But it would be useful to reuse some of ideas in | > | Monticello | > | based SCM tools too. With Metacello we got a good packaging tool, | > | so, | > | where to go to be even better? I think SCM tool integration into | > | code | > | browser can be next and relatively easy step. As Store is | > | integrated | > | into VW code browser. | > | | > | Janko | > | | > | S, Dale Henrichs piše: | > | > Janko, | > | > | > | > I think the limitation for Smalltalk lies in source code | > | > management | > | > tools/styles ... | > | > | > | > With a file-based language 200 engineers can contribute to the | > | > project ... each engineer can checkout a version of the system | > | > work in isolation then commit his or her work to the shared | > | > repository resolve conflicts and move on .... other engineers | > | > can | > | > easily integrate the work and so on ... the source code | > | > management | > | > tools scale ... | > | > | > | > In the mid nineties at ParcPlace systems the image was passed | > | > around from engineer to engineer so that he or she could | > | > integrate | > | > their work into the production image... this doesn't scale... | > | > | > | > There have been proprietary source code management tools that | > | > have | > | > been created over the years. You can bet that the large | > | > companies | > | > that are invested in Smalltalk are using systems that are based | > | > on | > | > these proprietary systems, but you can also bet that they've | > | > had | > | > to customize those systems for their needs... | > | > | > | > The file-based SCM systems work out of the box and don't care | > | > what | > | > language or even development process that is being used ... | > | > they | > | > are managing files ... | > | > | > | > There is no standard SCM for Smalltalk and none of the | > | > file-based | > | > SCMs really fit Smalltalk. When we are arguing about whether | > | > git | > | > or mercurial is better on the Pharo list, I will retract that | > | > statement:). | > | > | > | > Without a standard SCM, the first thing that a 200 person | > | > engineering groups needs to do to start using Smalltalk is | > | > figure | > | > out (for themselves) how to share their work and keep 200 | > | > individual images in synch ... I'm not necessarily convinced | > | > that | > | > anyone has really solved this one. | > | > | > | > Personally I believe that the problem is surmountable, but for | > | > whatever reason the Smalltalk community hasn't focussed on | > | > seriously addressing the SCM issue .... in the last 30 years or | > | > so:) | > | > | > | > Being able to repeatably build images based on a minimal core | > | > image | > | > is certainly headed in the right direction, but we still have a | > | > ways to go on the tools front ... | > | > | > | > Dale | > | > | > | > | > | > | > | > ----- Original Message ----- | > | > | From: "Janko Mivšek" janko.mivsek@eranova.si | > | > | To: Pharo-project@lists.gforge.inria.fr, "Squeak" | > | > | squeak-dev@lists.squeakfoundation.org, "VWNC" | > | > | vwnc@cs.uiuc.edu | > | > | Sent: Saturday, January 28, 2012 7:46:32 AM | > | > | Subject: [squeak-dev] Smalltalk for small projects only? | > | > | | > | > | Hi guys, | > | > | | > | > | Ralph Johnson in his InfoQ interview made an interesting | > | > | observation: | > | > | | > | > | 2:55 minute: "Smalltalk made an fundamental error ... image | > | > | ... | > | > | you | > | > | can | > | > | build something with 4-5 people what 50 people can build in | > | > | Java, | > | > | but | > | > | if | > | > | you take 200 people in Java ... it is really designed for | > | > | small | > | > | systems | > | > | ... " | > | > | | > | > | Are we because of the image really destined for relatively | > | > | small | > | > | projects and small systems (of Java 50 people project size)? | > | > | | > | > | Are we really not able to scale to bigger projects/systems | > | > | because of | > | > | that? | > | > | | > | > | Ok, there are few exceptions of course (JPMorgan, OOCL, ..), | > | > | but | > | > | still... | > | > | | > | > | [1] http://www.infoq.com/interviews/johnson-armstrong-oop | > | > | | > | > | Best regards | > | > | Janko | > | > | | > | > | | > | > | -- | > | > | Janko Mivšek | > | > | Aida/Web | > | > | Smalltalk Web Application Server | > | > | http://www.aidaweb.si | > | > | | > | > | | > | > | > | > | > | | > | -- | > | Janko Mivšek | > | Svetovalec za informatiko | > | Eranova d.o.o. | > | Ljubljana, Slovenija | > | www.eranova.si | > | tel: 01 514 22 55 | > | faks: 01 514 22 56 | > | gsm: 031 674 565 | > | | > | |