Any ex ClearCase or VSS users out there?

[Voelker, Bernhard]

Neil Martinsen-Burrell wrote:

> Based on these comments and Bernhard's command examples previously, I've 
> made a start on a Survival Guide for ClearCase users.  Take a look at it 
> http://bazaar.launchpad.net/~nmb/bzr-migration-docs/clearcase-
> start/annotate/head%3A/en/survival/bzr-for-cleartool-users.txt and to make 
> changes, just check out  lp:bzr-migration-docs and edit en/survival/bzr-for-
> cleartool-users.txt

This is a really great start from the user's point.
I'd like to add some aspects about the light-weight way to use Bzr.
It's basically an "infrastructure" issue (maybe because of the many
basic network protocols bzr supports (sftp, ssh, http, ...). In ClearCase,
a lot of preparation and planning has to be done by a ClearCase admin.

=============

In ClearCase, beside the basic software installation on the central server as
well as on the clients, you have to setup a group on OS level for all persons
to work on the projects plus the "ClearCase user", i.e. VOB admin.
Several projects, i.e. independant repositories, can be grouped into a "region".
A client host can only be member of one region (pls. correct me if I'm wrong).
A "VOB" database (repository) is then created (and added to the current region's
registry database) by a command like this:

  cleartool mkvob <options> /vobs/my-project

After that, every client belonging to that ClearCase region can work with
that VOB repository by mounting it:

  cleartool mount /vobs/my-project

The user creates one or more "views" in that region:
[Note: i'll explain "dynamic views" first]

  cleartool mkview -tag my_view <path-to-view-repository>

A tag is a name for the view; the view repository is needed to
hold local copies of checkedout files and non-versioned files
- so-called "view-private" - files. The view server manages that
view repository and the user usually doesn't have to care about
that.

A view is somewhat like a filter on the whole repositories' element versions,
i.e. a ruleset called config_spec defines which versions of which elements
should be seen by this view. The default ruleset is to select the own checkouts
(i.e. the locally changed version of an element) or the LATEST version on the
/main branch:

  element * CKECHEDOUT
  element * /main/LATEST

A view server provides the element versions picked up by that rules as a
directory hierarchy in the "MVFS" (multi-versioned) file system.
On windows clients, a separate driver letter is used for MVFS which shows
all active views, e.g.

  M:\my_view1\my_project

On UNIXoide clients, usially the mount point /view is used being used for that:

  /view/my_view1/my_project

Any program can now work on the elements in that path via common OS level operations
like ls, cat, cp etc. on UNIX or dir, notepad, etc. on Windows.
The magic about this is that the view provides an always-up-to-date look
into the repository, i.e. when user A checks in a new version of a file
and the config_spec of user B's view selects the LATEST version on that branch,
that the next action (after ~1-3 seconds) on this element automatically works
with the new version: there's no need for a manual pull to get the change!

This is why this type of view is called "dynamic view": you always have the
latest and greatest stuff with the drawback that you have to be online.
Only checkedout elements and non-versioned - so-called "view-private" files -
are physically stored on the machine where the view server is running.
All other files are overlaid by the versions on the VOB server.

The second possible view type is called "static view" which is more like 
in other VCSs: all element versions selected by the view are physically
copied from the VOB server to the view server according to the config_spec.
The user has to pull newer versions manually but can work with the files offline.

=============

I guess this is enough right now for a discussion ... the concept of 
dynamic views is radically different from the way other VCSs and static views
work.

I don't want to blame the heavy way of ClearCase administration, it can be
totally hidden from the user and and the desired development and testing workflow
can be integrated in a powerful and intuitive IDE.

Have a nice day,
Berny