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



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