List of assumptions about using git for managing Smalltalk source

assumptions.md

1. I assume that by moving to a disk-based structure, we are expecting folks to edit and modify directory structure on disk using the shell and standard editors. This means that all information is going to be stored in plain test files. No binary files. Binary files may be stored in the project structure for use by developers, but the mechanisms for loading code into an image from disk must not involve binary files.

2. I assume that we will preserve package structure on disk. This means that at a minimum we must be able to preserve the collection of class and method definitions that make up a Monticello package. This includes traits and any other standard definitions that are currently present in a Monticello package. In practice "preserving the package structure" means that one can load a package from disk and then save the package to disk in another location and the directory structure is "identical". The package loader must be respectful of files and directories that are not part of the official package structure, but there is no requirement that the "extra" files and directories embedded in the package structure be preserved.

3. I assume that we will include the basic project structure information currently present in the Metacello baseline specification that is still applicable for disk-based projects. This boils down to required external projects and package to package dependencies.

4. I assume that we will explicitly preserve Monticello package structure on disk. Doing so will make the transition to (and from) the disk-based projects easier and not require the development of new tools.

5. I assume that the basic structures and tools will be agnostic as to the underlying version control system that is used, whether it be svn, git, mercurial or something else.

6. I assume that we will provide explicit support for the use of github. We have become dependent upon distributed repositories (Squeaksource) and github is a more than adequate replacement for SqueakSource.

7. I assume that we will provide explicit support for git. Over time, we will develop image-based tools to interface directly with git.

Assumption 1: Although we have a great IDE, some people may prefer working in emacs or something like that. This means a constant to and fro between the image and the file system. I don't see this as a major important assumption. Also, because I think that changing the directory structure on disk is a bit unnecessary. Yes, no binary files.

Assumption 2, 3, 4: agree

Assumption 5: the tools must know about git or hg or whatever because it makes interoperability easier. The file structure can be without meta information and very simple, which makes it independent of the version control system. But then the tools must know how to talk to it, which could be specific to git, for example.

Assumption 6: I don't think that github should be the only repository and I also don't understand what github specific support you need to provide. I'd stick to the basic git tools that supports any distributed repository system.

Assumption 7: agree

No binaries, okay.
Supporting git, okay (not doing it would transform the project into something else, diverge release, etc)
Evading to get coupled with github, okay (github is coupled to git, so we don't really need to further complicate our dependencies)
Preserve Monticello package structure on disk, okay
Being agnostic of git would be a plus but only if the cost makes sense (in terms of getting this done this semester).

Otto, Re Assumption 1:

I guess I should have said that "if the files are on disk, folks will edit the files and manipulate the directory structure with the shell" ... the intention was not that it was the not the primary means, but that in reality folks will use an editor and monkey with things on disk, so being friendly makes sense.

The types of things that are currently not disk-based friendly is the package file ... the name of the directory should be used as the name of the package, but the name inside the package file is used to actually name the package internally ... this duplication of information makes renaming a package on disk more complicated than it should be ...

It's not a top priority, but I think that as long as we have text files on disk ... folks will try to do things from the editor and shell ...

Otto, Re Assumption 5:

Very good point ... the lowest common denominator is the directory structure, so the tools must support that as a minimum ... Agreed that we will want to have in-image support for the various SCMs...

Otto, Re Assumption 6:

Another good point ... If you know of a better open source and free web site for managing git repositories, I'd be interested in hearing about it ..

Regarding support for the various schemes, there will be a certain amount of built-in Metacello support for disk/git/github and I am hoping that folks who want to add svn/trac support or something else, will just fork the metacello project (on github) and add the necessary support...

Sebastian,

Agreed...my motivation for disk/git/github is that I want to be able to start collaborating with a small group of developers and do development based on disk/git/github so that we can iron out any kinks in the system and discover some "best practices" to recommend before opening it up for general use...

Sebasian,

Oh and I'm thinking that we'll reach that point "real soon now"