github et al (was [squeak-dev] The Trunk: Monticello-cmm.575.mcz)

Igor Stasenko siguctua at gmail.com
Fri Nov 22 01:22:27 UTC 2013


On 22 November 2013 02:04, Eliot Miranda <eliot.miranda at gmail.com> wrote:

>
>
>
> On Thu, Nov 21, 2013 at 4:52 PM, Igor Stasenko <siguctua at gmail.com> wrote:
>
>>
>>
>>
>> On 21 November 2013 02:14, J. Vuletich (mail lists) <
>> juanlists at jvuletich.org> wrote:
>>
>>> There is a simpler way, using Git as it is meant to be used. Take a look
>>> at https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/commit/
>>> 3deff0d7b9707258766d6f003b783077664a4023#diff-
>>> 5fe4c9854ae64b52029283e0648affd4 . We've been using this for a couple
>>> of years, and it works nicely.
>>>
>>> This is simpler, yes, but much less integrated than filetree.
>> 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
>> (try changing order of methods fileout which will turn whole diff to be
>> red/green,
>> while there could be no changes at all).
>>
>
> 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 :-).
>
>
In fact, git under the hood operates with things which completely
orthogonal to files,
the entities it uses is just a tree of binary blobs (objects), and there's
even API for operating with them, but need additional work.
It is completely unnecessary to map methods to files and then inventing the
way how to deal with metadata (FileTree uses JSON for that), Camillo can
give more details
on that, because he was working on more advanced git integration,
which directly operates with repository bypassing need of using files
or need to go to command line and manually do git commit etc.



>
>>
>>
>>>
>>> Quoting Frank Shearar <frank.shearar at gmail.com>:
>>>
>>>  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_.
>>>>
>>>>  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)).
>>>>
>>>> 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
>>>>
>>>>
>>>>
>>>
>>>
>>> Cheers,
>>> Juan Vuletich
>>>
>>>
>>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko.
>>
>>
>>
>>
>
>
> --
> best,
> Eliot
>
>
>
>


-- 
Best regards,
Igor Stasenko.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131122/f7bcfcfa/attachment-0001.htm


More information about the Squeak-dev mailing list