>>>- Dynamic views
ClearCase implements a Virtual file system providing a vie winto
multiple versions (a.k.a. MVFS - the multi-version file system).
What that means ... well, if anyone was ever a user of Sun's Network
Software Environment (NSE) which implemented the "Translucent
File-System" it was somewhat similar.
Each workspace (copy) is essentially a "mount point" for an instance of
the file system. A Clearcase "view" identifies a storage area/directory
(to hold locally created/generated files and files checked-out for
editing) and a set of version-selection rules (that decide which
version(s) of which files will be visible in the workspace). The
version-selection rules are called a "configuration specification" or
"config-spec" (abbreviated as "cspec")
If you use "dynamic" version selection rules such as /main/LATEST (or
anything that selects "LATEST" of any branch) then anytime someone else
does a checkin of that branch, your view is automagically and virtually
instantaneously updated with the new version of that file (unless you
already had it checked-out for editing).
That makes the "update" command obsolete in CVS/SVN. You dont need to
initially "populate" the workspace because readonly copies of everything
automatically appear when you create the workspace. And you dont need to
do an "update" to sync with the latest state of the branch because it
happens automatically (this can be a really good idea, or a really bad idea)
Furthermore, ClearCase's MVFS "extends" the filepath namespace with
version-extended path names. A normal file-path looks like it would on
the Unix command-line. So if I say "/top/src/hdrs/foobar.h" I will see
the version of foo.h that is selected by my config-spec
But if I use the version-extended namespace, I can say
/top/src/hdrs/foorbar.h@@/main/10 and it will refer to version 10 on
branch "/main" of the file. I can use any valiud "version selection
rule" after the "@@", such as a label (foobar.h@@/RELEASE-12) or an
attribute tag (foobar.h@@{PROMOTION_LEVEL="Baselined"} or if I just use
"@@" at the end (foobar.h@@) then the result is a directory containing
all versisn of that file visible in the version of that directory
>>>- Good branch/merge support (a lot better than e.g. Subversion)
Clearcase uses SCCS-style interleaved deltas (a.k.a. "inline deltas")
and upto 32-way diff/merge (e.g. comparing one base version against 31
different contributor versions). It tracks merges in the version-tree
and knows which versions contribuetd to which other versions and which
chunks of code from which deltas were already merged.
It can also support some algebraic merge operations such as a
subtractive merge (subtracting only one delta from a set of deltas that
were since merged into the file), or an additive sum (specifying exact
the set of deltas to include/exclude for a given file)
As far as branching, ClearCase is almost too powerful/flexible. There
are branch-types (basically the name of the branch) and there are
branch-instances (an instance of creating the named branch for a given
file). So I can easily use just the branch type (branch name) to
represent all the files and versions that were checked-out/in onto that
branch. Or I can refer to just one instance of the branch for a
particular file.
This means that, if I chose to do so, I could have different branching
topolgoies (structures) for different files and the same branch type. I
might have file1@@/main/foo/bar/3 and file2@@/main/bar/foo/2 and
file3@@/main/bar/4). Granted, most people dont do this, they attempt to
use more or less the same branching structure across all files! HOWEVER,
in ClearCase I only need to create versions for a branch if and only iff
I change the file on that branch. If I dont have to checkout the file
for editing in my view, there is no need to create an instance of my
branch for that file. So branches ocntain ONLY the files that needed to
change - not the whole repo)
>>>- ClearMake
Since ClearCase uses an MVFS, it can intercept all read/write calls to
access file versions during a build. This allows Clearcase to audit the
build, and detect every version of every file that was used to
build/generate another file or make-target. PLUS it knowns more than
just the file and version, it knows the command-line that was used to
create it.
This means for starters that if youre using ClearMake, you dont have to
maintain source file dependencies, CC will "learn" those when it does
its first build in your workspace. It also means that its smart enough
to know the impact of changing a build/compile command-line flag and
which targets are dependent upon it and need to be rebuilt.
Plus it automatically captures a configuration-record (config-rec) for
each built-target (a.k.a. "derived object") during the build. The
config-rec captures the "recipe" (command-line invocation(s)) used to
generated that target, and the full version-extended pathname of each
contributing source-file.
ClearCase also tracks a "cache" of built objects (with parameters that
can be fine-tuned) so that, if I need to build a target, it can look in
the cache to see a built-copy of it already exists with the exact same
contributing source versions and build-options and create a virtual
file-system link to the already built file instead of actually having to
build it (this is called "wink in")
The price for all of this (besides the big price-tag of Clearcase) is
that the multi-version file-system implemented by Clearcase is very
network resource intensive. It takes a lot more time and effort and
people to administer and configure.
And if you dont know what you are doing or dont plan it very well, some
of those things that would otherwise improve performance (such as
wink-in, and never having to "get/checkout" readonly copies of files)
can sometimes cost more network i/o cycles and bandwidth than theuy
would otherwise save.
--
Brad Appleton <brad@bradapp.net> www.bradapp.net
Software CM Patterns (www.scmpatterns.com)
Effective Teamwork, Practical Integration
"And miles to go before I sleep" --Robert Frost
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jul 6 08:00:56 2005