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

Chris Muller asqueaker at gmail.com
Wed Nov 20 00:08:46 UTC 2013


Frank wrote:

>>> hesitation. Monticello predates git by about 3 years, so we were right...
> Monticello was great, back in the day.
> And now, 7 years of git later, I'd...

One thing that's usually not a big factor with a lot of Smalltalkers
-- the "age" of the software.  In fact that seems a strange thing to
focus on given you're using a 30-year old language in the first
place..

>>> ahead. It just makes so much sense to me to just use a world class
>>> tool that _we don't have to maintain_. (*)

It's fine to be impressed with "successful" (translation: used by lots
of developers) bedrock software but we should not trick ourselves into
thinking there's "nothing to do" to use it.  The _interface_ to the
SCM...

> The given error is unfortunate, but that's not even git's fault -
> "Filename too long" says it all. That super long filename comes from
> filetree, so the error's existent is a confluence of a particular
> source->file mapping together with a file system limitation.

... is not necessarily easier to "maintain" than SCM integrated
directly into the Smalltalk environment.  In fact, the domain model is
probably the simplest part of Monticello.

I think other IDE's use external SCM because they're not an integrated
development "environment" at all.  They're a cluster of tools.
Smalltalk is a true integrated environment which I believe ironically
makes using integrated SCM not only possible but just as easy as
interfacing to external.

 - Chris


On Tue, Nov 19, 2013 at 3:39 PM, Frank Shearar <frank.shearar at gmail.com> wrote:
> On 19 November 2013 21:24, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>> 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:
>
> An IDE _always_ (*) surrenders source code control to something else!
> And it works just fine for emacs, Eclipse, Netbeans, Visual Studio,
> IntelliJ, ...
>
> (*) Squeak being the exception
>
> The given error is unfortunate, but that's not even git's fault -
> "Filename too long" says it all. That super long filename comes from
> filetree, so the error's existent is a confluence of a particular
> source->file mapping together with a file system limitation.
>
>> "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.
>
> Monticello was great, back in the day. But why do we _have_ to saddle
> ourselves with the effort of maintaining it ourselves? What else might
> we _better_ do if we didn't spend all our time NIHing everything?
>
> And now, 7 years of git later, I'd consider git to be bedrock. Git
> _has succeeded_. It and mercurial have gutted the competition: darcs,
> monotone, bazaar, ...
>
> frank
>
>>> > 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
>>
>>
>>
>


More information about the Squeak-dev mailing list