project directory structure (git for smalltalk)

On 28 February 2012 06:49, Otto Behrens <[hidden email]> wrote:
Two things:
* For lexically close methods, it's just pgup/pgdown
* For lexically remote things - and they shouldn't be too remote or
your class is doing too much - it's just a search away.

In both cases it's a lot cheaper to hop around methods than it is to
have 20 files open, or the horror of trying to navigate between tiny
files on github.

So, yes, I do find myself scrolling a lot, which is exactly why I want
class-per-file, because that kind of navigation is an order of
magnitude cheaper than spawning browsers or opening files.

> When I'm in the browser, I miss textual search, comparing methods and
> driving from the keyboard. When I'm in a file with a load of methods,
> I miss the ability to ask for senders, or follow senders one after the
> other. I also miss automatic formatting, method categorising, running
> tests, refactoring and other things.

Indeed! The difference is that of a bunch of text and interacting
objects. And the answer is that I want _both_.

> For me, having the ability to select multiple methods in a browser to
> compare the code between them would fill a large gap. Then, to be able
> to do contextual text searches from the keyboard would be cool. I
> probably have to learn more keyboard short-cuts in the image, but how
> do I navigate using the keyboard?

Certainly in Squeak the answer is "you don't". There's precious little
keyboard-only stuff available.

frank

Dale Henrichs wrote

With method-level file granularity, I can point to a single method in my project with a single url[1]. I think that this is incredibly powerful for working with folks in a distributed environment ...

I just found this thread...
+1 to file per method. Git is csm. The method is the logical unit in the image, and we lose power if we go less granular than that. Dale's post about blame/history/etc on github per method is cooool!

As to the readability/navigability, that's a tool issue. If you want to use Vim or emacs and seeing the code per class would make more sense (I buy that), write a plugin that brings in each method in the class in a split view. Attached is a screenshot of MCFileTreeAbstractReader's definition and class-side methods in Vim...

As for navigating in github, will people be editing code directly in the github files, or only from the image and committing via mc? If only from the image, could we have commits create a summary file per class that combines all the methods? It should be not-a-smalltalk-file, like txt or something, so people know not to edit it...

Cheers,
Sean

----- Original Message -----
| From: "Sean P. DeNigris" <[hidden email]>
| To: [hidden email]
| Sent: Sunday, June 3, 2012 8:29:03 AM
| Subject: [Metacello] Re: project directory structure (git for smalltalk)
|
|
| Dale Henrichs wrote
| >
| > With method-level file granularity, I can point to a single method
| > in my
| > project with a single url[1]. I think that this is incredibly
| > powerful for
| > working with folks in a distributed environment ...
| >
|
| I just found this thread...
| +1 to file per method. Git is csm. The method is the logical unit in
| the
| image, and we lose power if we go less granular than that. Dale's
| post about
| blame/history/etc on github per method is cooool!

Having lived with this per method model for a while, it is really nice to have the per method granularity ... Even to the level of `git status` which lists each file modified/added/deleted gives you a perfect overview of the _method-level_ changes made to all of the packages in the repository in one view!

|
| As to the readability/navigability, that's a tool issue. If you want
| to use
| Vim or emacs and seeing the code per class would make more sense (I
| buy
| that), write a plugin that brings in each method in the class in a
| split
| view. Attached is a screenshot of MCFileTreeAbstractReader's
| definition and
| class-side methods in Vim...

missed the attachment ...

|
| As for navigating in github, will people be editing code directly in
| the
| github files, or only from the image and committing via mc? If only
| from the
| image, could we have commits create a summary file per class that
| combines
| all the methods? It should be not-a-smalltalk-file, like txt or
| something,
| so people know not to edit it...

In practice there are times, when it is simply easier and convenient to edit a file directly on disk (no image already running with the particular package loaded or during a porting session when the particular method/definition won't load at all...and so on). The vast majority of the time, though you are doing all of your edits from within the image where you can run tests....

The class comments are stored in markdown files on GitHub, so it is actually easier to edit the comments in GitHub so that you can fine tune the markdown:)

With git integrated into the image, it should be just as simple to edit an "open package" as it is to edit a "loaded package"...

Dale

Ah, yes....with package/class/method structure it is easy to create Smalltalker friendly views with file-based tools, since they come from a long line of directory structure semantics ....

The tools that excites me is a github web api aware Amber browser running on top of a github repository ... you can do browsing/senders/implementors within a package or repository context including live editing of source all running in a web-browser ....

Dale

----- Original Message -----
| From: "DeNigris Sean" <[hidden email]>
| To: [hidden email]
| Sent: Tuesday, June 5, 2012 1:43:40 PM
| Subject: [Metacello] Re: project directory structure (git for smalltalk)
|
|
|
| On Jun 5, 2012, at 2:15 PM, Dale Henrichs [via Smalltalk] wrote:
|
| missed the attachment ...
| Trying to attach again (just a little mockup, but shows how easy it
| is to have a customized view on top of very granular scm). The first
| time was through Nabble, so you can also see it at
| http://forum.world.st/project-directory-structure-git-for-smalltalk-tp4420849p4633038.html
|

On Sun, Feb 26, 2012 at 8:10 PM, Dale Henrichs <[hidden email]> wrote:

>  Why bother with git at all?
>
> Monticello versions individual packages (source files), it is not an SCM[1]. In many respects Monticello is closer to RCS[2] than Git[3].

RCS? Them's fightin' words!

> Git manages versions of entire directory structures...making it possible to version collections of packages along with the entire range of ancillary files that are typically required for modern software development.
>
> Monticello manages versions of a single package. A single file.... If you find yourself needing to do anything beyond managing a single mcz file, Monticello does not help. Need I say more?

Yes, I think there's quite a bit to be said on this point.
Monticello's versioning capabilities are actually very similar to
those of git, but oriented toward classes and methods rather than
files and directories. As you've pointed out elsewhere, it makes no
sense to map a Smalltalk package to a single file. It's much more
useful to map individual methods to files. The Smalltalk equivalent of
RCS would be the .changes file—it records all the variants of a
method, but it doesn't keep baselines of which variants belong
together.

If you consider a package the equivalent of a git repository,
Monticello is the functional equivalent of git, though neither are
full-fledged SCMs according to the criteria you linked to on
Wikipedia.

I do understand the inadequacy of Monticello for the task before you,
but frankly, the requirements of GLASS go beyond the design goals of
both Monticello and git. GLASS is more similar to a Linux
distribution, than any single project managed by git. If you tried to
manage any large collection of git-based projects, say, Ubuntu, using
just git, you'd quickly run into the same issues.

Colin

Colin,

I believe I also said (in my presentation if not in that specific email) that Monticello has fueled the upsurge in Squeak/Pharo .... so there:)

more comments below....

----- Original Message -----
| From: "Colin Putney" <[hidden email]>
| To: [hidden email]
| Sent: Wednesday, June 6, 2012 10:00:16 AM
| Subject: Re: [Metacello] Re: project directory structure (git for smalltalk)
|
| On Sun, Feb 26, 2012 at 8:10 PM, Dale Henrichs <[hidden email]>
| wrote:
|
| >  Why bother with git at all?
| >
| > Monticello versions individual packages (source files), it is not
| > an SCM[1]. In many respects Monticello is closer to RCS[2] than
| > Git[3].
|
| RCS? Them's fightin' words!
|
| > Git manages versions of entire directory structures...making it
| > possible to version collections of packages along with the entire
| > range of ancillary files that are typically required for modern
| > software development.
| >
| > Monticello manages versions of a single package. A single file....
| > If you find yourself needing to do anything beyond managing a
| > single mcz file, Monticello does not help. Need I say more?
|
| Yes, I think there's quite a bit to be said on this point.
| Monticello's versioning capabilities are actually very similar to
| those of git, but oriented toward classes and methods rather than
| files and directories. As you've pointed out elsewhere, it makes no
| sense to map a Smalltalk package to a single file. It's much more
| useful to map individual methods to files.

Absolutely ... as long as a project can be managed in a single package git and Monticello are indistinguishable ... When it comes to multiple packages that need to be managed together as a unit git provides superior features to Monticello ....
 
| The Smalltalk equivalent
| of
| RCS would be the .changes file—it records all the variants of a
| method, but it doesn't keep baselines of which variants belong
| together.
|
| If you consider a package the equivalent of a git repository,
| Monticello is the functional equivalent of git, though neither are
| full-fledged SCMs according to the criteria you linked to on
| Wikipedia.

But Smalltalk projects in general have evolved to the point where many projects involve multiple coordinated mcz files and Monticello has the bare minimum of support for multi-file projects.

Metacello was invented to bridge the multiple file gap, but if Monticello is RCS, Metacello is CVS, an adequate but flawed solution to the problem.

git does an excellent job of managing sets of files ... probably the best available at the moment especially when combined with the collaboration tools available on github.... the combo of git/github is really hard to beat.

|
| I do understand the inadequacy of Monticello for the task before you,
| but frankly, the requirements of GLASS go beyond the design goals of
| both Monticello and git.

Well Metacello/Monticello has been adequate for GLASS over the last few years. git/github provide superior features (not available with Metacello/Monticell/SqueakSource) so it is the natural progression ...

BTW, the FileTree repository structure (used for git) is not much more than an unzipped .mcz file and leverages the image-based Monticello classes, so only the repository-side of Monticello is being replaced by git ... the image-side of Monticello is still the best way to manage the import/export of Smalltalk code!

The most complex projects managed by GLASS involve Seaside/Magritte/Pier/Moose and none of those projects are exclusively used by GLASS ... the problems faced by GLASS are no different than those faced by the Squeak/Pharo users of those projects ...

| GLASS is more similar to a Linux
| distribution, than any single project managed by git. If you tried to
| manage any large collection of git-based projects, say, Ubuntu, using
| just git, you'd quickly run into the same issues.

Take a look at any Ruby project out in the wild ... Rails is probably an order of magnitude more complex than anything we've done in Smalltalk and it is all managed sing git/github, so I think you are underestimating the capabilities of git/github ...

Of course the Seaside/Magritte/Pier/Moose/Rails are spread across multiple git repositories ... in the Ruby world, you've the Bundler that performs a similar function to Metacello when it comes to coordinating between separate git projects .... Even in the git/github universe there is a need for Metacello (at least a subset of Metacello) ...

It's getting the full set of tools to work in harmony that is the challenge ...

Dale

On Wed, Jun 6, 2012 at 11:12 AM, Dale Henrichs <[hidden email]> wrote:

> Absolutely ... as long as a project can be managed in a single package git and Monticello are indistinguishable ... When it comes to multiple packages that need to be managed together as a unit git provides superior features to Monticello ....

Nope. You're comparing apples to oranges again. A Monticello package is equivalent to a git repository. As soon as you have a git-based project that has multiple repositories, e.g. for libraries, plugins etc you're back to the same problems Monticello has with multiple packages.


> But Smalltalk projects in general have evolved to the point where many projects involve multiple coordinated mcz files and Monticello has the bare minimum of support for multi-file projects.

Yes. When Monticello was designed, packages were a novelty in Squeak, and all projects were just a single package. That enabled us to create more larger, more sophisticated, cross-dialect projects that can be deployed in lots of different configurations.

> Metacello was invented to bridge the multiple file gap, but if Monticello is RCS, Metacello is CVS, an adequate but flawed solution to the problem.

Monticello is not RCS. Metacello is bundler or pip or dpkg or rpm.

> git does an excellent job of managing sets of files ... probably the best available at the moment especially when combined with the collaboration tools available on github.... the combo of git/github is really hard to beat.

Yup, it's great. Squeaksource is the equivalent of SourceForge; we need a Github for Smalltalk. In the meantime, if we can make some sort of use of Github, that would be good.


> Well Metacello/Monticello has been adequate for GLASS over the last few years. git/github provide superior features (not available with Metacello/Monticell/SqueakSource) so it is the natural progression ...
>
> BTW, the FileTree repository structure (used for git) is not much more than an unzipped .mcz file and leverages the image-based Monticello classes, so only the repository-side of Monticello is being replaced by git ... the image-side of Monticello is still the best way to manage the import/export of Smalltalk code!

But you're using the versioning part of git too right? Not just storage, but history tracking, merging etc.

> The most complex projects managed by GLASS involve Seaside/Magritte/Pier/Moose and none of those projects are exclusively used by GLASS ... the problems faced by GLASS are no different than those faced by the Squeak/Pharo users of those projects ...

> Take a look at any Ruby project out in the wild ... Rails is probably an order of magnitude more complex than anything we've done in Smalltalk and it is all managed sing git/github, so I think you are underestimating the capabilities of git/github ...

Not so. The Rails ecosystem is probably several orders of magnitude larger and more complex than Seaside, but the basic structure is the same. And the whole ecosystem doesn't fit into a single git repository. That's why RVM and Bundler are necessary. They serve the same purpose as Metacello.

> Of course the Seaside/Magritte/Pier/Moose/Rails are spread across multiple git repositories ... in the Ruby world, you've the Bundler that performs a similar function to Metacello when it comes to coordinating between separate git projects .... Even in the git/github universe there is a need for Metacello (at least a subset of Metacello) ...

Right. Here's the mapping, as I see it:

method………. file
class -> directory
package -> repository


> It's getting the full set of tools to work in harmony that is the challenge ...

Yes.

I'm a bit ambivalent here. I certainly applaud any effort to put Smalltalk code in Github. It would be great to have the human and search-engine visibility that provides, and it helps to make Smalltalk less alien to rest of the world. On the other hand, I've been down that road with DVS, and I think it results in worse experience for pure-Smalltalk projects that don't need interoperability with the code-in-files mainstream. Obviously, we'd like some sort of best-of-both-worlds hybrid, but I'm not sure that exists, and I worry that it's likely to end up being the worst of both worlds.

Either way, I think it's helpful to understand the situation clearly, and I think inaccurately talking down Monticello isn't going to help.

Colin

Colin,

There is some fundamental miscommunication going on here there are several levels of conversation going on so I'd like to pull back and tug at the one thread that I think is most important and fundamental, namely:

  A Monticello package is equivalent to a git repository.

I'm not sure how you can make that statement, so perhaps we should come to an understanding of why this statement is true or false before continuing on with the conversation.

Here's a link to a git repository (on github)[1] that I am currently using for Metacello development. In this _single_ git repository I am storing approximately 20 packages.

Each of the .package files in that git repository does represent the equivalent of a single Monticello package, but I am able to manage 20 packages in a single "version" of the git repository along with documentation[2] and a license file[3].

These are all artifacts in the same git repository and are all versioned together in one commit ...

With git I have first class named branches[5] and tags[6] that are all directly addressable and comparable and mergable...

A Monticello package doesn't even come close to providing this set of features!

Now tell me who is comparing apples and oranges...

Dale

[1] https://github.com/dalehenrich/metacello-work/tree/issue_28/repository
[2] https://github.com/dalehenrich/metacello-work/tree/issue_28/docs
[3] https://github.com/dalehenrich/metacello-work/blob/issue_28/license.txt
[4] https://github.com/dalehenrich/metacello-work/blob/issue_28/README.md
[5] https://github.com/dalehenrich/metacello-work/branches
[6] https://github.com/dalehenrich/metacello-work/tags
----- Original Message -----
| From: "Colin Putney" <[hidden email]>
| To: [hidden email]
| Sent: Wednesday, June 6, 2012 12:26:41 PM
| Subject: Re: [Metacello] Re: project directory structure (git for smalltalk)
|
|
|
|
| On Wed, Jun 6, 2012 at 12:19 PM, Colin Putney < [hidden email] >
| wrote:
|
|
|
|
| Right. Here's the mapping, as I see it:
|
| method………. file
| class -> directory
| package -> repository
|
|
| Whoops, sent that by accident before it was finished:
|
|
| method file
| class directory
| package git repository
| Monticello git
| Metacello Bundler, pip, brew, npm, apt, rpm
|
|
| You can see the equivalence most clearly in the last line: all those
| tools have very similar domain language - package, dependencies,
| mapping SCM versions of projects to actual deployment structures
| etc.
|
|
| Colin

Colin,

I can only imagine that you might be confusing the FileTree package and git ... if that's the case I can understand how you would make the following statement:

  A Monticello package is equivalent to a FileTree package.

and I whole-heartedly agree.

Dale
----- Original Message -----
| From: "Dale Henrichs" <[hidden email]>
| To: [hidden email]
| Sent: Wednesday, June 6, 2012 1:21:33 PM
| Subject: Re: [Metacello] Re: project directory structure (git for smalltalk)
|
| Colin,
|
| There is some fundamental miscommunication going on here there are
| several levels of conversation going on so I'd like to pull back and
| tug at the one thread that I think is most important and
| fundamental, namely:
|
|   A Monticello package is equivalent to a git repository.
|
| I'm not sure how you can make that statement, so perhaps we should
| come to an understanding of why this statement is true or false
| before continuing on with the conversation.
|
| Here's a link to a git repository (on github)[1] that I am currently
| using for Metacello development. In this _single_ git repository I
| am storing approximately 20 packages.
|
| Each of the .package files in that git repository does represent the
| equivalent of a single Monticello package, but I am able to manage
| 20 packages in a single "version" of the git repository along with
| documentation[2] and a license file[3].
|
| These are all artifacts in the same git repository and are all
| versioned together in one commit ...
|
| With git I have first class named branches[5] and tags[6] that are
| all directly addressable and comparable and mergable...
|
| A Monticello package doesn't even come close to providing this set of
| features!
|
| Now tell me who is comparing apples and oranges...
|
| Dale
|
| [1]
| https://github.com/dalehenrich/metacello-work/tree/issue_28/repository
| [2] https://github.com/dalehenrich/metacello-work/tree/issue_28/docs
| [3]
| https://github.com/dalehenrich/metacello-work/blob/issue_28/license.txt
| [4]
| https://github.com/dalehenrich/metacello-work/blob/issue_28/README.md
| [5] https://github.com/dalehenrich/metacello-work/branches
| [6] https://github.com/dalehenrich/metacello-work/tags
| ----- Original Message -----
| | From: "Colin Putney" <[hidden email]>
| | To: [hidden email]
| | Sent: Wednesday, June 6, 2012 12:26:41 PM
| | Subject: Re: [Metacello] Re: project directory structure (git for
| | smalltalk)
| |
| |
| |
| |
| | On Wed, Jun 6, 2012 at 12:19 PM, Colin Putney < [hidden email]
| | >
| | wrote:
| |
| |
| |
| |
| | Right. Here's the mapping, as I see it:
| |
| | method………. file
| | class -> directory
| | package -> repository
| |
| |
| | Whoops, sent that by accident before it was finished:
| |
| |
| | method file
| | class directory
| | package git repository
| | Monticello git
| | Metacello Bundler, pip, brew, npm, apt, rpm
| |
| |
| | You can see the equivalence most clearly in the last line: all
| | those
| | tools have very similar domain language - package, dependencies,
| | mapping SCM versions of projects to actual deployment structures
| | etc.
| |
| |
| | Colin
|

----- Original Message -----
| From: "Colin Putney" <[hidden email]>
| To: [hidden email]
| Sent: Wednesday, June 6, 2012 2:30:50 PM
| Subject: Re: [Metacello] Re: project directory structure (git for smalltalk)
|
|
|
|
| On Wed, Jun 6, 2012 at 1:21 PM, Dale Henrichs < [hidden email] >
| wrote:
|
|
| Colin,
|
| There is some fundamental miscommunication going on here there are
| several levels of conversation going on so I'd like to pull back and
| tug at the one thread that I think is most important and
| fundamental, namely:
|
|
| A Monticello package is equivalent to a git repository.
|
| I'm not sure how you can make that statement, so perhaps we should
| come to an understanding of why this statement is true or false
| before continuing on with the conversation.
|
| Here's a link to a git repository (on github)[1] that I am currently
| using for Metacello development. In this _single_ git repository I
| am storing approximately 20 packages.
|
| Each of the .package files in that git repository does represent the
| equivalent of a single Monticello package, but I am able to manage
| 20 packages in a single "version" of the git repository along with
| documentation[2] and a license file[3].
|
| These are all artifacts in the same git repository and are all
| versioned together in one commit ...
|
|
|
| Right. All these "packages" are in the same repository, and are all
| versioned together in one commit. That makes the whole lot of them
| equivalent to a single package in Monticello. If you want to achieve
| the same thing with Monticello, you'd just create a single package
| called "Metacello". Then it would behave just like your git
| repository.

Stop right there!

With the git repository I can have my single version and a set of independent packages, too ... with git I can load a subset of the packages from the repository and that is a crucial and important difference. There is a significant difference in BEHAVIOR: I am not REQUIRED to use a single package for every project when I use git.

So I will agree that:

  a Monticello package is equivalent to a git repository containing a single FileTree package

but:

  a Monticello package is NOT equivalent to a git repository containing multiple FileTree packages

You have to admit that there is a significant difference here!  

There are a fairly large number of Monticello projects that consist of multiple packages ... it is a very common phenomenon today ... look at Seaside/Magritte/Pier/Moose/Zinc/AST/RFB/etc./etc. the list goes on and on...

So git allows one to manage a SET of INDEPENDENTLY LOADABLE packages in a single commit. Multi-package projects are common where the developers WANT the option to load only the relevant packages.

Git in combination with FileTree packages gives you all of the ADVANTAGES of using Monticello without being required to constrain your project to a single Monticello package.

Dale

----- Original Message -----
| From: "Colin Putney" <[hidden email]>
| To: [hidden email]
| Sent: Wednesday, June 6, 2012 4:10:20 PM
| Subject: Re: [Metacello] Re: project directory structure (git for smalltalk)
|
|
|
|
| On Wed, Jun 6, 2012 at 3:31 PM, Dale Henrichs < [hidden email] >
| wrote:
|
|
|
| Stop right there!
|
| With the git repository I can have my single version and a set of
| independent packages, too ... with git I can load a subset of the
| packages from the repository and that is a crucial and important
| difference. There is a significant difference in BEHAVIOR: I am not
| REQUIRED to use a single package for every project when I use git.
|
| So I will agree that:
|
| a Monticello package is equivalent to a git repository containing a
| single FileTree package
|
| but:
|
| a Monticello package is NOT equivalent to a git repository containing
| multiple FileTree packages
|
| You have to admit that there is a significant difference here!
|
| There are a fairly large number of Monticello projects that consist
| of multiple packages ... it is a very common phenomenon today ...
| look at Seaside/Magritte/Pier/Moose/Zinc/AST/RFB/etc./etc. the list
| goes on and on...
|
| So git allows one to manage a SET of INDEPENDENTLY LOADABLE packages
| in a single commit. Multi-package projects are common where the
| developers WANT the option to load only the relevant packages.
|
| Git in combination with FileTree packages gives you all of the
| ADVANTAGES of using Monticello without being required to constrain
| your project to a single Monticello package.
|
|
| Yes, it's true that you can load parts of a git repository into your
| image, while leaving other parts on disk only. That's an artifact of
| the distinction between the image and the git working copy, not a
| feature of git's versioning model or a difference in behaviour
| between git and Monticello. In typical (i.e., non-Smalltalk usage)
| you can't effectively deal with sub-sections of a repository. The
| only thing you can do, really, is use git archive to export a
| directory from your repository to another place in the file system.
| If you wrote a tool to automate that for you, and then sync changes
| from that external tree back into your working copy, you'd have
| something like FileTree for languages that store source code in
| files.

I'm not sure what point you are making here ... I think you are saying that you agree with me:

  a Monticello package is NOT equivalent to a git repository
  containing multiple FileTree packages

In the end it doesn't matter why they are "NOT equivalent" ... git in combination with FileTree (a Monticello repository, leveraging existing Monticello technology that is superior) is superior to Monticello when working with multi-package projects .... a very common situation these days.

FileTree which was written by Otto Behrens 6 months ago is an excellent bridge between in-image Monticello (have I mentioned how excellent the in-image Monticello model is?) and git ... making it possible to leverage git and github for Smaltalk development (without having to reinvent all of the wheels) ... I have been using FileTree successfully in virtually all of my Smalltalk development since January.

This is not a case of "what one could do", this is a case of "we have working code right now".
|
|
| You could also write some code to enable the same sort of hack with
| Monticello. Instead of loading a full version, you'd establish some
| sort of convention equivalent to the directory structure you're
| using with Git. Your tool would then pull all the definitions out of
| a Monticello version, select the ones that match the convention and
| load only them. Then to save a new version, you'd pull the
| definitions out of the parent version, update them with whatever
| changes are in the image, and save a new version. Monticello already
| has most of the code to do that; it'd be a pretty straight-forward
| addition to MC or maybe Gofer.
|
|
| Alternatively, you could use a two-image system. Then you'd load a
| version into your tools image with Monticello, then use something
| like Spoon or GemTools to push a subset of package to the remote
| image/gem. That would be a closer analogue to the set up you've
| between the git working copy and the image.
|
| Understand, I'm not trying to say that what you're doing with git
| isn't worthwhile.

Colin ... I understand that there is lots of code that could be written in many different ways to solve the same problem ... The big value that I see is that the Smalltalk community can leverage some very good technology: git/github and use if OFF THE SHELF with no need for us to attempt the DUPLICATE it's functionality.

I am putting code where my mouth is and between FileTree and the modifications to Metacello (that are basically FUNCTIONAL right now) I'm building a bridge between the existing Metacello/Monticello/mcz/SqueakSource ecosystem and the Metacello/Monticello/FileTree/git/github ecosystem.

|
| I just want to set the record straight on
| Monticello—remember, you started off saying that Monticello is not
| an SCM and it's more like RCS than git. That's just not true, and
| setting up those misconceptions as the starting point for this
| discussion limits it quite a bit, I think.

Colin, I apologize if I hurt your feelings with the RCS statement. It was one of many analogies I have used along the way ... and if it bothered you, then it was an analogy in poor taste.

I hope that you now understand that my primary motivation is to IMPROVE the support for collaborative, multi-package Smalltalk projects and it really looks to me that git/github is a tough combination to beat ...

I see this as an opportunity for Smalltalkers to leverage mainstream tools without sacrificing the advantages that Monticello brings to the table.

It's also an opportunity to make Smalltalk more accessible to the millions of programmers who are very comfortable with using git/github for everyday development.

I am in the final phases Metacello development[1] before I will be able provide a pre-release version with git/github support and there are plans in place for following on with an in-image git/github api ... so development is proceeding apace.


Dale

[1] https://github.com/dalehenrich/metacello-work/issues?milestone=1&page=1&sort=updated&state=open 

On Wed, Jun 6, 2012 at 5:28 PM, Dale Henrichs <[hidden email]> wrote:

Now we're getting somewhere. Philippe's original question was "If you
embrace Monticello then why bother with git at all?" Your response
was, essentially, that Monticello is not capable of solving the
problem at hand, so we embrace git for the superior versioning
functionality that it offers. But when it comes down to it, the real
reason for embracing git is what you wrote above. Basically:

1. Smalltalk is a small community, with limited resources. If we use
git, we don't have to spend energy duplicating its functionality.
2. Git is the defacto standard for the rest of the computing world,
and if we embrace it we can be part of larger ecosystems.

To me, those are excellent reasons for exploring git integration, and
the real value of this project. If we drop "Monticello is inadequate"
and adopt "We want to take advantage of the git ecosystem" as our
basic premise, how does that change things?

> Colin, I apologize if I hurt your feelings with the RCS statement. It was
> one of many analogies I have used along the way ... and if it bothered you,
> then it was an analogy in poor taste.

It's not about my feelings. I'll be the first to admit that Monticello
is getting long in the tooth and had rough edges, implementation
issues and downright design flaws from the very beginning. It solved
immediate problem of how to collaborate on projects in Squeak, but
it's hardly the final word on the subject. I've put an enormous amount
of effort into Monticello 2 precisely to solve the problems with
Monticello 1, and so far, completely failed to produce anything
useful. I'm glad you're making more progress.

> I hope that you now understand that my primary motivation is to IMPROVE
> the support for collaborative, multi-package Smalltalk projects and it
> really looks to me that git/github is a tough combination to beat ...

Yup. I get it. You're trying to make Smalltalk less of a ghetto, for
the benefit of everyone. Bravo! It may not be obvious, but by
nitpicking and challenging your assumptions, I'm trying to help you do
so more effectively. Monticello was born when Avi and I tried, and
failed, to version Smalltalk code using CVS. We ran into exactly the
set of issues that Philippe brings up. Git is way better than CVS, and
we've all learned a lot since then, so maybe these problems can be
solved this time around. But to do that, we have to be clear about
what the goal is and why we're pursuing it.

Colin

Colin,

Understood ... and appreciated ... deep dialog is important ... waving hands and "arguing" is part of the process to for getting to the same page ... and I appreciate your patience and perseverance:)

Metacello is getting "long in tooth" as well and the git/github connection has really taken some of the burden off of Metacello ... for example I don't have to answer the question:

  "how do you merge two metacello versions?"

As git provides a very good option...

If you haven't been following along too closely, with a git a Metacello configuration collapses down to a single baseline version method, encapsulated in a BaselineOf class ... as the repository contents changes with each commit it isn't necessary to "create a new baseline version", you just edit the single baseline method in the BaselineOf class and commit it along with the added/removed packages/dependencies/projects.....

ConfigurationOf doesn't go completely away with git...

Of course existing Metacello configurations have to keep working ... but it makes things easier knowing there is a migration path for folks who need the enhanced capabilities that git/github brings to the table ...

The other item on the agenda is cross-dialect code sharing ... Monticello hasn't been adopted by other Smalltalk dialects (as much as I had hoped early on) and it appears that Cypress (the Monticello package/snapshot model with the FileTree disk format and git/github for a shared SCM) has some traction in this area, so that's another plus for going with git/github as it has the potential to bring all of the Smalltalk dialects closer together ... again the small Smalltalk community cannot afford to spend all of its time ported code between dialects ...

Dale




----- Original Message -----
| From: "Colin Putney" <[hidden email]>
| To: [hidden email]
| Sent: Wednesday, June 6, 2012 6:49:27 PM
| Subject: Re: [Metacello] Re: project directory structure (git for smalltalk)
|
| On Wed, Jun 6, 2012 at 5:28 PM, Dale Henrichs <[hidden email]>
| wrote:
|
| > Colin ... I understand that there is lots of code that could be
| > written in
| > many different ways to solve the same problem ... The big value
| > that I see
| > is that the Smalltalk community can leverage some very good
| > technology:
| > git/github and use if OFF THE SHELF with no need for us to attempt
| > the
| > DUPLICATE it's functionality.
| >
| > I am putting code where my mouth is and between FileTree and the
| > modifications to Metacello (that are basically FUNCTIONAL right
| > now) I'm
| > building a bridge between the existing
| > Metacello/Monticello/mcz/SqueakSource
| > ecosystem and the Metacello/Monticello/FileTree/git/github
| > ecosystem.
|
| Now we're getting somewhere. Philippe's original question was "If you
| embrace Monticello then why bother with git at all?" Your response
| was, essentially, that Monticello is not capable of solving the
| problem at hand, so we embrace git for the superior versioning
| functionality that it offers. But when it comes down to it, the real
| reason for embracing git is what you wrote above. Basically:
|
| 1. Smalltalk is a small community, with limited resources. If we use
| git, we don't have to spend energy duplicating its functionality.
| 2. Git is the defacto standard for the rest of the computing world,
| and if we embrace it we can be part of larger ecosystems.
|
| To me, those are excellent reasons for exploring git integration, and
| the real value of this project. If we drop "Monticello is inadequate"
| and adopt "We want to take advantage of the git ecosystem" as our
| basic premise, how does that change things?
|
| > Colin, I apologize if I hurt your feelings with the RCS statement.
| > It was
| > one of many analogies I have used along the way ... and if it
| > bothered you,
| > then it was an analogy in poor taste.
|
| It's not about my feelings. I'll be the first to admit that
| Monticello
| is getting long in the tooth and had rough edges, implementation
| issues and downright design flaws from the very beginning. It solved
| immediate problem of how to collaborate on projects in Squeak, but
| it's hardly the final word on the subject. I've put an enormous
| amount
| of effort into Monticello 2 precisely to solve the problems with
| Monticello 1, and so far, completely failed to produce anything
| useful. I'm glad you're making more progress.
|
| > I hope that you now understand that my primary motivation is to
| > IMPROVE
| > the support for collaborative, multi-package Smalltalk projects and
| > it
| > really looks to me that git/github is a tough combination to beat
| > ...
|
| Yup. I get it. You're trying to make Smalltalk less of a ghetto, for
| the benefit of everyone. Bravo! It may not be obvious, but by
| nitpicking and challenging your assumptions, I'm trying to help you
| do
| so more effectively. Monticello was born when Avi and I tried, and
| failed, to version Smalltalk code using CVS. We ran into exactly the
| set of issues that Philippe brings up. Git is way better than CVS,
| and
| we've all learned a lot since then, so maybe these problems can be
| solved this time around. But to do that, we have to be clear about
| what the goal is and why we're pursuing it.
|
| Colin
|

Dale Henrichs wrote

deep dialog is important ... waving hands and "arguing" is part of the process to for getting to the same page

Man, we have a kick-ass community! Political correctness is a creativity killer. It's great that we give each other the leeway to battle it out, which is essential to discovering a great solution.

Dale Henrichs wrote

The other item on the agenda is cross-dialect code sharing... again the small Smalltalk community cannot afford to spend all of its time ported code between dialects ...

+1000. I know the universe is chaotic and evolution is non-linear, but we have a real tower of Babel going here ;-)