<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Nov 21, 2013 at 4:52 PM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com" target="_blank">siguctua@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 dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="im">On 21 November 2013 02:14, J. Vuletich (mail lists) <span dir="ltr"><<a href="mailto:juanlists@jvuletich.org" target="_blank">juanlists@jvuletich.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There is a simpler way, using Git as it is meant to be used. Take a look at <a href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/commit/3deff0d7b9707258766d6f003b783077664a4023#diff-5fe4c9854ae64b52029283e0648affd4" target="_blank">https://github.com/Cuis-<u></u>Smalltalk/Cuis-Smalltalk-Dev/<u></u>commit/<u></u>3deff0d7b9707258766d6f003b7830<u></u>77664a4023#diff-<u></u>5fe4c9854ae64b52029283e0648aff<u></u>d4</a> . We've been using this for a couple of years, and it works nicely.<div>
<div><br></div></div></blockquote></div><div>This is simpler, yes, but much less integrated than filetree.<br></div><div>Because having separate file per method, means git can produce proper diff on a per-method basis, while if you just store fileouts, git can often give you false diffs<br>
</div><div>(try changing order of methods fileout which will turn whole diff to be red/green,<br></div><div>while there could be no changes at all).<br></div></div></div></div></blockquote><div><br></div><div>And the fact that git requires one file per method to generate proper diffs is my #1 reason for wanting /not/ to use a file-oriented SCM for Smalltalk. I can only conclude that put up with the line-oriented diffs that git/subversion/mercurial/sccs/rcs/cvs produce is that the macro preprocessor in C and C++ makes it impossible in general to derive the structure of C and C++ programs form their source. You yourself, Igor (and I agree with you except that a macro system is very useful) were complaining about how awful the C.C++ macro system is (and it is). hat a mad world we live in :-).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div><div class="h5"><div> </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div>
<br>
Quoting Frank Shearar <<a href="mailto:frank.shearar@gmail.com" target="_blank">frank.shearar@gmail.com</a>>:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 20 November 2013 16:56, Chris Muller <<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>
</blockquote>
<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>
</blockquote>
<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>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>
</blockquote>
<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>
</blockquote>
<br>
I would use stronger language. I think our current state of affairs is<br>
a _disaster_.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>
</blockquote>
<br>
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/<u></u>frankshearar/5781906)</a>).<br>
<br>
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.<br>
<br>
frank<br>
<br>
<br>
</blockquote>
<br>
<br>
<br></div></div>
Cheers,<br>
Juan Vuletich<br>
<br>
<br>
</blockquote></div></div></div><br><br clear="all"><div class="im"><br>-- <br>Best regards,<br>Igor Stasenko.
</div></div></div>
<br><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>
</div></div>