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

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


On 22 November 2013 11:03, Frank Shearar <frank.shearar at gmail.com> wrote:

> On 22 November 2013 01: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.
>
> Git is not a file-oriented SCM. Igor's comment says that filetree is
> doing exactly the right thing, as far as versioning things goes: a
> single method is a single code datum so goes into a separate object.
> Monticello happens to do exactly the same thing.
>
> Absolutely..
For curious, you can download an image here:
https://ci.inria.fr/pharo-contribution/job/FileSystem-Git/PHARO=30,VERSION=development,VM=vm/lastSuccessfulBuild/artifact/FileSystem-Git.zip

And here is piece of code (from test suite) which demonstrates, that you
don't have to work with files to work with git :)
(it actually uses #fileNamed: (imo should be #named: instead), because if
you look how it is handled internally in GitTreeEntry, it has no any
special handling and can be arbitrary string):

setUp
    | commit1 commit2  blob1 blob2 tree1 tree2 stamp |
    super setUp.
    stamp := GitStamp new
        name: 'Homer Simpson';
        email: 'homer at nuke.com';
        yourself.
    reference := (FileSystem memory / 'test.git').
    basicRepository := GitRepository on: reference.

    blob1 := (GitBlob bytes: 'testBlob' in: basicRepository) store;
yourself.
    blob2 := (GitBlob bytes: 'second test Blob' in: basicRepository) store;
yourself.
    tree1 := GitTree
        entries: {
            GitTreeEntry
                fileNamed: 'blob1'
                hash: blob1 hash
                in: basicRepository}
        in: basicRepository.
    tree1 store.

    tree2 := GitTree
        entries: {
            GitTreeEntry
                fileNamed: 'blob2'
                hash: blob2 hash
                in: basicRepository}
        in: basicRepository.
    tree2 store.

    commit1 := (GitCommit in: basicRepository)
        tree: tree1;
        message: 'message1';
        author: stamp;
        committer: stamp;
        store;
        yourself.

    commit2 := (GitCommit in: basicRepository)
        tree: tree2;
        message: 'message2';
        author: stamp;
        committer: stamp;
        parents: { commit1 hexHash };
        store;
        yourself.

    basicRepository
        updateRef: basicRepository headsDir / 'branch1' to: commit1 hexHash;
        updateRef: basicRepository headsDir / 'master' to: commit2
hexHash.
    GitFSCK validate: basicRepository.

    repository := FileSystemGitRepository on: reference.



> frank
>
> > 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
> >
> >
> >
>
>


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


More information about the Squeak-dev mailing list