-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
I assume that we will provide explicit support for git. Over time, we will develop image-based tools to interface directly with git.
Created
February 23, 2012 17:36
-
-
Save dalehenrich/1893955 to your computer and use it in GitHub Desktop.
List of assumptions about using git for managing Smalltalk source
Sebasian,
Oh and I'm thinking that we'll reach that point "real soon now"
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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...