github et al (was [squeak-dev] The Trunk: Monticello-cmm.575.mcz)

Eliot Miranda eliot.miranda at gmail.com
Tue Nov 19 21:24:54 UTC 2013


Hi Frank,

On Fri, Nov 8, 2013 at 2:44 PM, Frank Shearar <frank.shearar at gmail.com>wrote:

> 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_. (*)
>

Here's an example of why surrendering one's source code control to
something else is a really bad idea for an IDE:

"When doing a git clone, I do get the following:


Philippe at gravitation7 ~
$ git clone --depth=1 https://github.com/pharo-project/pharo-vm.git
Cloning into 'pharo-vm'...
remote: Counting objects: 17493, done.
remote: Compressing objects: 100% (12363/12363), done.
remote: Total 17493 (delta 4271), reused 17137 (delta 4143)
Receiving objects: 100% (17493/17493), 19.28 MiB | 1.88 MiB/s, done.
Resolving deltas: 100% (4271/4271), done.
Checking connectivity... done
error: unable to create file
mc/VMMaker-oscog.package/GeniePlugin.class/instance
/primSameClassAbsoluteStrokeDistanceMyPoints.otherPoints.myVectors.otherVectors.
mySquaredLengths.otherSquaredLengths.myAngles.otherAngles.maxSizeAndReferenceFla
g.rowBase.rowInsertRemove.rowInsertRemoveCount..st (Filename too long)
Checking out files: 100% (17525/17525), done.
fatal: unable to checkout working tree
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry the checkout with 'git checkout -f HEAD'

Pretty weird error I'd say.

Anyone knowing what this is related to?"

IMO having Monticello under our own control is a key strength.  yes, it's
effortful to maintain but I don't see why we can't summon that effort.  I
do fear that if we don't we just become like everything else and soon
enough we're just another scripting language.  The Smalltalk team had a
name for this, something like "error 22", meaning depending on the success
of other projects or infrastructure.  It's a bad idea, unless its bedrock.

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


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131119/62d8d7c2/attachment-0001.htm


More information about the Squeak-dev mailing list