On 20 November 2013 22:27, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
>
>
> On Wed, Nov 20, 2013 at 12:41 PM, Frank Shearar <frank.shearar at gmail.com>
> wrote:
>>
>> On 20 November 2013 16:56, Chris Muller <asqueaker at gmail.com> wrote:
>> >>> 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.
>> >>
>> >> Mild talking past each other here. IntelliJ uses your favourite
>> >> version control system under the hood to store your code: it supplies
>> >> menus for driving, for instance, git to commit code and whatnot. It
>> >> does, in addition, store versions for every time you hit enter (or
>> >> after a period of time). These are distinct features. I'm not
>> >> proposing losing the versions button or using git to store the data
>> >> behind the versions button.
>> >>
>> >> I'm proposing that we keep the Monticello front end, add a few new
>> >> buttons, and rip out the storage of source on disk, replacing it with
>> >> git. I have yet to find a decent mapping of Smalltalk code to files,
>> >> but I'd put up with a crap one if it meant one less thing that we
>> >> didn't need to do.
>> >
>> > The "storage" you refer to is already encapsulated by MCRepository.  I
>> > would welcome a new MCGitRepository subclass if it were able to meet
>> > the minimum API requirements of MCRepository.  But I see no need to
>> > "rip out" any of the existing repository-types..
>> >
>> >> Smalltalk was 30 years ahead of its time in 1980. It's now a decade
>> >> behind other languages. That is a tragedy that, in my opinion at
>> >> least, largely comes from the Smalltalk community's extreme
>> >> insularity/NIH.
>> >
>> > Again, I don't think this group will be moved by this line of
>> > reasoning, even with such dramatic language ("tragedy?" c'mon).
>>
>> I would use stronger language. I think our current state of affairs is
>> a _disaster_.
>
>
> What specifically is broken?  Can you concentrate on process rather than
> component?
>
>>
>> > Something that would be much more convincing, to me at least, would be
>> > learning what having a MCGitRepository would do for MY goals and also
>> > the community at large.  For example, I'm intrigued by Git's forking
>> > capability.  How could that capability integrate into our ecosystem in
>> > a useful way to bring more development power to the community?
>>
>> I'm actually tired of the whole argument. So, in lieu of further talk,
>> I'm just going to carry on squirreling away on my stuff, chipping away
>> at the dependency nightmare we have (and if you think that's
>> hyperbole, you really ought to haul out graphviz and take a long, hard
>> look at the dependency graph. Go make yourself some coffee while dot
>> munges the file (which you can generate off
>> https://gist.github.com/frankshearar/5781906)).
>
>
> I don't want to keep on at you but I would suggest that the dependency
> nightmare is orthogonal to source code control.  It is about modularity, not
> versioning.  Do you agree?

I meant "I'm bowing out of the conversation and this is what I'm going
to do instead". Yes, they're orthogonal.

frank

>> Eventually we'll get to a place where I can not shiver in horror, and
>> then I can think again about the git problem. Even better, maybe
>> Camillo Bruni, Dale Henrichs and friends will have done the hard work
>> for me.
>>
>>
>> frank
>>
>
>
>
> --
> best,
> Eliot