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?


> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131120/d35624d9/attachment.htm