[squeak-dev] The Trunk: Monticello-cmm.575.mcz

Frank Shearar frank.shearar at gmail.com
Fri Nov 8 22:44:31 UTC 2013


On 8 November 2013 22:30, Chris Muller <asqueaker at gmail.com> wrote:
> The trunk is a huge part of the Squeak development process and
> ecosystem that deserves and needs representation somewhere in the
> system.  Access to it is reasonably needed by ReleaseBuilder,
> Installer, source.squeak.org's SqueakSource and
> MonticelloConfigurations.

Does noone else in the Squeak community use MCMs? I don't, but my
libraries are all very, very small.

> Squeak has been using its own flavor of Monticello for several years
> now, as does Pharo and GemStone.  So, to me, it feels fine to make it
> Monticello-For-Squeak, meaning to relax restrictions imposed by
> multiplatform so it can go as far as we want toward supporting the
> Squeak process.

It's not really germane to this discussion, but if I could flick a
switch and have us updating from github, I would do so without
hesitation. Monticello predates git by about 3 years, so we were right
on the bleeding edge there for a while, but git is now very, very far
ahead. It just makes so much sense to me to just use a world class
tool that _we don't have to maintain_. (*)

> Having said that, I must admit this really does make it
> Squeak-specific, no longer generic.  So, maybe an alternative should
> be to model our development process elements in a new package,
> SqueakDevelopmentProcess (?), which would depend on our Squeak's
> generic Monticello to represent the elements of our development
> process.

I'm not terribly concerned with Squeak-specific or otherwise. It's
just that it's _trunk_ specific. I'd rather see a
SqueakDevelopmentProcess package than see it in the Monticello
package.

frank

(*) Finding that switch to flick is pretty hard though, which is why I
don't rant and rave about this all the time. Filetree's OK, but
destroys the ability of browsing source on the git repository (but
gives you the proper fine-grained version control you'd want).
gitfiletree supplies a Pharo UI to filetree, and it would be
worthwhile to port that UI to Squeak, through ToolBuilderification.
Continuing this discussion would necessitate a subject thread change!

> On Fri, Nov 8, 2013 at 3:12 PM, Nicolas Cellier
> <nicolas.cellier.aka.nice at gmail.com> wrote:
>> I have same feeling as Frank,
>> a specific address of a specific repository for a specific usage has not
>> much thing to do in MC.
>> MC package should not integrate each and every possible usage of MC.
>> If this does not belong to ReleaseBuilder, then we can make it a System
>> thing...
>> If it's only for MCM, didn't we get a MCMcmUpdater defaultUpdateURL?
>>
>>
>> 2013/11/8 Chris Muller <asqueaker at gmail.com>
>>>
>>> MonticelloConfigurations has no dependency on ReleaseBuilder and I
>>> don't think we should introduce one.
>>>
>>> If you at least acknowledge "trunk" is a real-thing in the real world,
>>> then note existence of MCRepository>>#trunk.  Sure, we could make a
>>> class-var or something if that helps you feel better, but my opinion
>>> right now is that is not necessary because code can change if/when it
>>> needs to.  Let's not let maybe-future-pie-in-the-sky-perfect be the
>>> enemy of pragmatic progress in the present.
>>>
>>> On Fri, Nov 8, 2013 at 10:33 AM, Frank Shearar <frank.shearar at gmail.com>
>>> wrote:
>>> > On 8 November 2013 15:25,  <commits at source.squeak.org> wrote:
>>> >> Chris Muller uploaded a new version of Monticello to project The Trunk:
>>> >> http://source.squeak.org/trunk/Monticello-cmm.575.mcz
>>> >>
>>> >> ==================== Summary ====================
>>> >>
>>> >> Name: Monticello-cmm.575
>>> >> Author: cmm
>>> >> Time: 3 October 2013, 9:42:40.555 pm
>>> >> UUID: daeb51c6-0b6f-41db-883d-e9764e61d8c5
>>> >> Ancestors: Monticello-cmm.573
>>> >>
>>> >> - Integrate Berts suggestions.  Refactored and renamed the API for the
>>> >> new history and origin browsing functions to avoid ambiguity with other MC
>>> >> domain elements.  Went from "version" nomenclature to "history".
>>> >> - Related to those functions, browsing a list of patch operations is
>>> >> now abstracted from browsing a Patch.  MCPatch is now a MCOperationsList
>>> >> and, likewise, a MCPatchBrowser inherits from a MCOperationsBrowser.
>>> >> - Added well-known repository accessors for #trunk and #packageCache,
>>> >> and #trunkUrlString avoids scattering the hard-coded url string literal in
>>> >> so many places.
>>> >
>>> > I don't like this last item. MCHttpRepository has no business knowing
>>> > about any particular location, nor should we commit ourselves to any
>>> > particular repository implementation. For instance, it might make a
>>> > whole lot of sense to build a repository backed by Cassandra.
>>> >
>>> > I'm not convinced that ReleaseBuilder isn't the right place for this
>>> > info. Or, to avoid the double negative, I think ReleaseBuilder is the
>>> > place that should know about the trunk URL, because ReleaseBuilder's
>>> > the class responsible for this kind of thing. One kind of release we
>>> > build is a release candidate, for instance.
>>> >
>>> > frank
>>> >
>>>
>>
>>
>>
>>
>


More information about the Squeak-dev mailing list