>> >> 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, ...
>
> No it doesn't.  And the fact that all the ones you mention do isn't a
> strength.  All IDEs I know of surrender the *storage* of the repository to
> something else, a file system, a database, a remote directory.  But lots of
> Smalltalk environments keep firm control of their own source code control,
> Store in VisualWorks, Orwell and later Team/V in Digitalk, Monticello in
> Squeal/Pharo.  Just the addition of the simple version scheme in Squeak
> changes & sources files puts it head and shoulders ahead of VisualWorks in
> the ease of investigating history, undoing changes, etc.  This is vital to
> the ease of programming, its flow, etc.  Squeak doers a great ob.  We
> surrender that to something else at our peril.
>
> One of the things we're not doing is trying to solve looking at long-term
> history (ie. some kind of server that serves the long-term history of
> packages).

Yes we are!  The history-providing prototype has been running on box4
for > 2 months now.  Did you not see the announcement?

   http://forum.world.st/ANN-New-source-squeak-org-prototype-td4707006.html

In fact, Eliot, YOU were one of the persons I did this for because you
(and Tim) had expressed interest in it before.  It's in trunk now, why
don't you give it a try?

1) Add this repository to Monticello:

    MCHttpRepository
        location: 'http://box4.squeak.org:8888/trunk'
        user: 'id'
        password: 'pw'

2) Add the above repository to a package you wish to enable history for.
3) In a browser's class or methods pane, select 'browse mc history' or
'browse mc origin'.

Your timing is impeccable because, as of this very moment, I'm
preparing a new version of this prototype which provides this for not
just Trunk but all projects including VMMaker, Etoys, Inbox, etc.

> Something I'm really excited to see the Pharo folks looking at is richer
> change analysis than just method history, i.e. being able to spot method
> refactorings, class renames and class hierarchy refactorings.
>
>
>> (*) Squeak being the exception
>
>
> Smalltalk being the exception actually.  Smalltalk has proved powerful
> enough for it to provide its own source code control, and that's been a
> great strength.  AT work I have to use a thin skin above Mercurial that is
> the solution for Newspeak and I despise it.  Compared to Monticello, it's
> junk.
>
>>
>> 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.
>
>
> But the net effect is the same.  By relying on something external the system
> broke.  And it's not easy for the Pharo community to get it fixed.  They'll
> have to wrk-around the problem, and compromise something they want in their
> name mangling.  I live with crap like this all the time in building the VM
> (mingw and cygwin are awful things to depend on).  At least in the VM
> building context (and Newspeak) it is only a few souls who have to suffer.
> I hope we don't inflict this kind of thing on the general Squeak community.
>
>>
>>
>> > "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
>
>
>