<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 20, 2013 at 12:41 PM, Frank Shearar <span dir="ltr"><<a href="mailto:frank.shearar@gmail.com" target="_blank">frank.shearar@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 20 November 2013 16:56, Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>> wrote:<br>
>>> No it doesn't. And the fact that all the ones you mention do isn't a<br>
>>> strength. All IDEs I know of surrender the *storage* of the repository to<br>
>>> something else, a file system, a database, a remote directory. But lots of<br>
>>> Smalltalk environments keep firm control of their own source code control,<br>
>>> Store in VisualWorks, Orwell and later Team/V in Digitalk, Monticello in<br>
>>> Squeal/Pharo. Just the addition of the simple version scheme in Squeak<br>
>>> changes & sources files puts it head and shoulders ahead of VisualWorks in<br>
>>> the ease of investigating history, undoing changes, etc. This is vital to<br>
>>> the ease of programming, its flow, etc. Squeak doers a great ob. We<br>
>>> surrender that to something else at our peril.<br>
>><br>
>> Mild talking past each other here. IntelliJ uses your favourite<br>
>> version control system under the hood to store your code: it supplies<br>
>> menus for driving, for instance, git to commit code and whatnot. It<br>
>> does, in addition, store versions for every time you hit enter (or<br>
>> after a period of time). These are distinct features. I'm not<br>
>> proposing losing the versions button or using git to store the data<br>
>> behind the versions button.<br>
>><br>
>> I'm proposing that we keep the Monticello front end, add a few new<br>
>> buttons, and rip out the storage of source on disk, replacing it with<br>
>> git. I have yet to find a decent mapping of Smalltalk code to files,<br>
>> but I'd put up with a crap one if it meant one less thing that we<br>
>> didn't need to do.<br>
><br>
> The "storage" you refer to is already encapsulated by MCRepository. I<br>
> would welcome a new MCGitRepository subclass if it were able to meet<br>
> the minimum API requirements of MCRepository. But I see no need to<br>
> "rip out" any of the existing repository-types..<br>
><br>
>> Smalltalk was 30 years ahead of its time in 1980. It's now a decade<br>
>> behind other languages. That is a tragedy that, in my opinion at<br>
>> least, largely comes from the Smalltalk community's extreme<br>
>> insularity/NIH.<br>
><br>
> Again, I don't think this group will be moved by this line of<br>
> reasoning, even with such dramatic language ("tragedy?" c'mon).<br>
<br>
</div></div>I would use stronger language. I think our current state of affairs is<br>
a _disaster_.<br></blockquote><div><br></div><div>What specifically is broken? Can you concentrate on process rather than component?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">> Something that would be much more convincing, to me at least, would be<br>
> learning what having a MCGitRepository would do for MY goals and also<br>
> the community at large. For example, I'm intrigued by Git's forking<br>
> capability. How could that capability integrate into our ecosystem in<br>
> a useful way to bring more development power to the community?<br>
<br>
</div>I'm actually tired of the whole argument. So, in lieu of further talk,<br>
I'm just going to carry on squirreling away on my stuff, chipping away<br>
at the dependency nightmare we have (and if you think that's<br>
hyperbole, you really ought to haul out graphviz and take a long, hard<br>
look at the dependency graph. Go make yourself some coffee while dot<br>
munges the file (which you can generate off<br>
<a href="https://gist.github.com/frankshearar/5781906)" target="_blank">https://gist.github.com/frankshearar/5781906)</a>).<br></blockquote><div><br></div><div>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?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Eventually we'll get to a place where I can not shiver in horror, and<br>
then I can think again about the git problem. Even better, maybe<br>
Camillo Bruni, Dale Henrichs and friends will have done the hard work<br>
for me. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
frank<br>
<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>
</div></div>