This page should serve as a summary of my experience with these two version control systems and a comparison of their possible workflows. There are four main areas where I shall compare them:

• Basics
• Development in a team
• Code reuse
• Integration with task-tracking

I have a lot of experience with MKS in all areas but, as I’ve been working with git on my private hobby projects so far, I’m very much limited to Basics and Code reuse here. Actually my goal with this page is to help me remember those awkward git commands.

1 Basics

1.1 Central vs Distributed Repositories

MKS is a client-server program. There is a central server that stores the repositories of each Project. People work with Sandboxes, private copies of a Project, that allow status tracking and all sorts of operations on the Project as well. A Sandbox is represented by a foo.pj file and the Working Files.
The server is usually under the control of a very busy and important admin, so don’t even ask me how to create a project. Just write him an email and in a matter of days you’ll have your new project. Another few hours/days will be needed to sort out access rights. To create a Sandbox, select the Sandbox/Create… menu item in the GUI. Or use the command line:

~$ mkdir foo
~$ si createsandbox --project=foo.pj foo # sandbox file foo/foo.pj is created

In git, you always have your own repository, represented  by the .git directory in the root of your project. To create a repo and a copy of the Working Tree, simply type

~$ mkdir foo && cd foo
~/foo$ git init

Or you can copy an existing repo anywhere (any URL is possible), similar to a Sandbox (but it’s more than that):

~$ git clone //bar/Projects/foo
~$ cd foo

The client-server concept of MKS seems superior at first sight, but I’m not sure. If the server’s backup strategy is not just-so, disaster is threatening, while in git every developer has a full copy of the entire repo. With MKS there is absolutely no way to track your work offline. Nor can you do so if you’ve received Read-only access only. Client server architectures are also very slow, as most operations go through the network. So on second thoughts, I’m absolutely sure: distributed is far superior.

1.2 Simple Workflow

I’ll cover adding and updating a file to the project. In both cases it starts with creating the file.

In MKS you can use the GUI: Member/Add, Member/Lock, Member/Edit Working File, Member/Check in, Project/Checkpoint. Or using the command line:

~/foo$ echo '#!bin/sh' > foo
~/foo$ si add foo
~/foo$ si lock foo
~/foo$ echo 'echo foo' >> foo
~/foo$ si ci --update foo
~/foo$ si checkpoint --sandbox=foo.pj

In git it’s far simpler:

~/foo$ echo '#!bin/sh' > foo
~/foo$ git add foo
~/foo$ echo 'echo foo' >> foo
~/foo$ git commit -a

1.3 Files vs Content

The reason for git’s simplicity is that it’s tracking content, not files separately. A “commit -a” will check in everything you’ve changed in your Working Tree as one atomic operation. Hence the lack of the checkpoint operation as well. An explicit “add” is only necessary for new files.

Note: If you use commit without -a, you need “git add” for each changed file as well before commit.

2 Development in a Team

MKS handles co-operation with a repo on the central server, private sandboxes and file Locks. A Lock means that only the locking developer is allowed to Check In the locked file. It’s very controlled, but may result in deadlocks if multiple people want to edit the same file. The second wannabe locker has to wait for the other’s checkin, merge the new revision into his Working File, lock and check in. The problem can be mitigated with good software-design based on nicely separated modules where people seldom queue up for a single file.

Git, on the other hand takes all this in its stride, considering multiple people working on the same file at the same time as a fact of life. The key is easy branching and merging. I’m not practiced but is seems the key operations are:

~/foo$ git pull # update you cloned repo with newest commits
~/foo$ git checkout -b newfoonction # create branch for development
~/foo$ echo 'echo newfoonction' >> foo
~/foo$ git commit -a
~/foo$ git push # publish your branch to original repo

Then it’s up to the maintainer of the main repo to merge the new branch to master. More of that later when I get some practice.

3 Code Reuse

MKS enables code reuse with the Shared Subproject concept. Project “foo.pj” that resides on the central server can be inserted into Project “bar.pj” into an arbitrary subfolder under an arbitrary name. You can also specify to reuse a certain Checkpoint of Project “foo.pj” (Build), or develop on it’s mainstream (Normal) or DevelopmentPath (Variant). In the latter two cases you’re able to Lock, Check In files and Checkpoint your Shared Subproject foo.pj from within the reusing bar.pj. You can also change between a fixed checkpoint (Build), mainstream (Normal) or DevPath (Variant) development, using the Configure Subproject menu item.

Git does this with submodules. Development from within a main project is easier, as remote clones of your main repo always see a specific commit of your submodule, never the index (like a Normal or Variant Subproject in MKS). But simple operations like updating your submodule to different versions or pulling from a repo containing submodules is tricky.

Below, I’ll list a few MKS Subproject related operations and give the closest git equivalent of them.

3.1 Add Shared Subproject

This MKS operation inserts another Project into a reusing Project’s folder structure.

~/bar$ git submodule add ~/foo foo
~/bar$ git submodule update --init

3.2 Resync Sandbox Recursively

Let’s assume bar is a cloned repo, containing submodules.

~/bar$ git pull
~/bar$ git submodule update

3.3 Configure Subproject to latest Build

~/bar$ cd foo
~/bar/foo$ git checkout HEAD
~/bar/foo$ cd ..
~/bar$ git commit -a

3.4 Configure Subproject to ANY Build

~/bar$ cd foo
~/bar/foo$ git checkout HEAD^^ # 2 versions before newest
~/bar/foo$ cd ..
~/bar$ git commit -a

3.5 Develop Subproject from within Main Project

Coming soon…

3.6 Drop Subproject

Coming soon…

4 Integration with Task-Tracking

MKS contains a full bug/task tracking tool called Integrity Manager, fully integrated with its version control called Source Integrity. The task/bug unit is called “issue” and its linked with version control operations via “Change Packages”.

As far as git is concerned, task-tracking is not built in, but you can find stunning web based solutions in free software projects. Midnight Commander’s Trac-git combo springs to the lips.

I always wanted to try out something like that. My bro mentioned they use Redmine at the office. I gave it a try, and it integrates with git so easily and beautifully, that I did not want to believe my own eyes. It’s become a semi-official tool at our place as well.

One needs sort of a central git-repo on the server where the Redmine web-app runs. This repo should be the one where everyone pushes. Redmine offers issue-tracking, which is slightly better than that of MKS, and to connect a git-commit to an issue, one has to mention the issue number in the first line of the commit message. Yes, it’s that simple:

1cd87ac Fix foo to avoid a bar-baz interference #42

The above line is from a oneline git-log, showing part of the SHA1 id of the commit and the commit-message. When such a commit is pushed to the central repo, it automatically connects it to issue 42, which in turn lists all related commits. No hassle with check-ins and Change Packages. Just commit and push.

Not to mention Redmine’s excellent web-based repository browsing.