On Tue, Nov 19, 2013 at 4:08 PM, 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..
>
> >>> 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.
>

+1.  well said.


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


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