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

Frank Shearar frank.shearar at gmail.com
Tue Nov 19 21:39:19 UTC 2013


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