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 :-).


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