Woshiadai Dev Notebook

I just read some recent articles and literatures about the idea of “building software at a higher level (than raw source code)” such as MDA, software workbench, software factories, etc. It seems like people are starting or have started (e.g. tools like OptimalJ from Compuware) using models as an efficient way of building software and leave the complexity issues to automation (as much as possible). Also, it appears to me that domain specific languages might appear as the major programming languages for specific domains. Actually, lots of XML documents have been serving as configuration files, preferences and options for quite some time, those in some sense are DSLs too.

Here are some interesting projects and articles from Eclipse and VS.NET 2005:

1) EMF+GEF+GMF: those are the modeling frameworks in Eclipse. EMF is quite similar in spirit to MDA proposed by OMG, GEF provides the framework to write graphical editors for editing EMF models. GMF (http://www.eclipse.org/gmf/) is a newly proposed project that aims to add automatic generation of GEF editors for EMF models, which bridges the gap between EMF and GEF.

2) Other MDA-related projects at Eclipse: GMT (http://www.eclipse.org/gmt/) is a set of research tools for generative model transformation. This one seems quite interesting because we are thinking about model transformation as well for our wizard-based design tools.MDDi (http://www.eclipse.org/proposals/eclipse-mddi/index.html) seems quite intersting as well, but it is also in its infancy.

3) MS has been pushing about software modeling in VS.NET 2005 and there are ideas and tools about “software factotires” (http://lab.msdn.microsoft.com/teamsystem/workshop/sf/default.aspx). They have a series of articles about software factories by Jack Greenfield. He also wrote a book (http://www.wiley.com/WileyCDA/WileyTitle/productCd-0471202843.html).

Perforce is one of the popular SCM system used by many IT companies. It uses RCS ,v file format for history archive file. The network communication model is client/server over TCP/IP. I am not sure about the detailed protocol Perforce uses.

Some quick points after reading Perforce user guide and administration guide:

• 1) Configuration and setup is a bit complicated. The document is not very straightforward about the setup process, meaning of basic concepts and usage of the environment variables. After reading the whole user guide, you finally get the basic ideas about various elements of Perforce and how they should be used, but not at the very beginning.
• 2) Too many commands and options. There are just too many commands and options to get a job done. And the worst part is that some commands have different names from CVS’s or Subversion’s commands, which are well-known to SCM users. Perforce also uses their own terms for well-understood concepts, e.g. integrate v.s. merge.
• 3) Perforce provides support for a wide range of platforms and offers multi-language API for 3rd-party developers. The Web client interface is really cool and it should save a lot of time for beginners.
• 4) Perforce reuses RCS history archive file format and maybe this is why it does not support directory versioning.
• 5) Internally, Perforce keeps a mapping between file extension and file type to distinguish binary and text files. Binary files are stored in whole while text files are stored in deltas.
• 6) Transaction is well supported in Perforce. Either all changed files get submitted in a changelist or none of them.
• 7) Branching is basically copy operation, and Perforce can keep track of the branching internally so that the history information is preserved.
• 8) In Perforce, a job records what needs to be done and a changelist stores the actual changes. They can be linked to represent the scenario of a bug report and how the bug is fixed.

Concepts in Perforce:

Depot: repository on Perforce server, it is a directory called “depot” in the perforce root directory on the server.

Workspace: isolated place where users get their job done. Users define a mapping between depot directory structure and workspace directory structure.

View: a mapping between files in depot and files in workspace.

Changelist: similar in spirit to the changeset concept. It records changes made as a transaction. There is a default changelist and users can define individual chagnelist called “numbered changelist” as well.

Job: a description of problems that should be solved, e.g. a bug report. Jobs are linked to changelists that actually make changes happen and fix the problems.

Label: similar to label in RCS, CVS and Subversion. Use label to make logic group of file, e.g. alpha release, bug fix, etc.

Branch: copy of files at a different directory. There are two approaches for branching: based on file specifications (from-files to-files) or branch specifications (name the branch mapping).

Perforce User Guide (2005.1)Perforce User Guide (2005.1)
Perforce Admin GuidePerforce Admin Guide