April 2012


Using Git and GitHub to host and manage Cuis code

Cuis 4 includes new tools and new suggested procedures for managing Smalltalk code. Central to this is the management of Packages and Package Files (.pck). But Cuis doesn't do version control. Instead, we suggest using external VCS tools.  In particular, we're using GitHub, and the first project we're hosting there is StyledTextEditor.

The guiding principle is do not duplicate concepts and behavior. As we're using an external tool (Git) for version control, then use it as it meant to be used. Most people use Git for version control and a file based IDE such as Eclipse for development. Such IDEs don't do version control themselves. It is done by Git. Do the same: do not include package version control in Cuis. This is a departure from the Monticello /Git integration (smallsource and MonticelloFileTree) by Otto Behrens, Dale Henrichs, etc.

We use GitHub to host, version, diff and merge external packages (.pck files), i.e. code that is maintained independently and outside Cuis.

Package files need to be simple text files. Cuis encoding for latin alphabet (ISO 8859-15) is handled without problems by GitHub. Cuis uses the LF (ascii code 10) newline convention, as preferred in GitHub. This allows Git/GitHub to diff versions, and merge branches.

Each GitHub repository has one set of users and permissions. Each GitHub repository has one state (Git commits repositories, not individual files). Branch and merges are done on the whole repository and not on individual files. Therefore, we need a separate GitHub repository for each project, i.e., for each package or set of closely related packages that are always loaded and maintained together as a whole.

Development process for External Packages

This is the suggested procedure for developing external packages. Usually do this every day.

  1. Start with a standard (i.e. fresh) Cuis image. Never save the image.

  2. Set up Git repositories for external packages (if not already done)

  3. Install packages from Git repositories.

  4. Develop. Modify and/or create packages.

  5. Save own packages (to Git repositories).

  6. Git add / commit / push as appropriate.

  7. Fileout changes that are not part of any package. These are automatically captured in numbered changesets, separated from changes to packages.

  8. Exit the image. Usually without saving.


  
 
  © 2012 Juan M. Vuletich