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

Frank Shearar frank.shearar at gmail.com
Wed Nov 20 10:21:19 UTC 2013


On 20 November 2013 00:08, Chris Muller <asqueaker at gmail.com> wrote:
> 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..

It's obviously a much more complicated equation than just age. Had I
suggested using git in 2007 you'd have said "what is this unproven new
fangled nonsense?" My point is that in the distributed version control
world there are exactly two players, and not a lot to choose between
them: git and mercurial. Almost noone uses anything else. Why is that?

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

I don't believe I ever suggested that it would be a trivial change.

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

But your file system's not integrated directly into the Smalltalk environment.

Yes, the domain model in Monticello is very simple. The domain model
for git is, too. That's not an interesting part of the problem.
Consider: if you want any kind of tool to review changes, you have to
write it yourself. Because that really common task that everyone else
already has a tool for? You don't.

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

"There is only Smalltalk" is, in my opinion, the biggest reason why
we're now 10 years behind everyone else. Seriously.

frank

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