%% "Colin S. Miller" <[EMAIL PROTECTED]> writes:
csm> In the 'dynamic' view, any changes committed by one engineer are
csm> automatically propergated to others, unless they have also
csm> modified that file (I forget how conflict resolving happens).
This is too simple.
The context for your view (the config spec) has rules to decide which
versions should be visible in that view (workspace). One possible rule
is the "LATEST" rule, which means "show me the latest version (on a
given branch)". If you use this rule then yes, when someone checks in a
new version then EVERY view (with a context like that) will "magically"
see that new version immediately, without the owner of the view doing
anything. This can be problematic, of course, although it can also be
very useful!
However, there are many, many alternatives to this that exhibit more
control and every ClearCase house I'm aware of uses one or more of those
alternatives almost all the time. You can select versions based on
labels (so as long as the labels don't move--and they can be locked--you
will see the same version always). You can even select based on
timestamp ("show me all versions as of 8am this morning"--and that will
automatically change every morning--or "show me all versions as of 8am
on 25 April 2005"), or on user ("show changes made by me or Joe, and not
by Alan") or combinations of those, etc. You can apply attributes to
versions and select versions based on that (TestStatus=="passed" or
whatever).
It can be quite powerful although most teams, as a practical matter,
typically choose a basic set (often label-based) and leave it at that.
csm> Also, the build directory can also be shared, so that when you
csm> build, it can copy the object files from any machine that has a
csm> copy.
Again, this not quite correct. You are talking about "winkin" of
derived objects. To use this, first, you have to be using clearmake to
build your derived objects instead of normal make or whatever: normal
tools behave just as they would anywhere else.
If you use clearmake, it can "winkin" derived objects built by others IF
it knows that the result of the build command would be the same. In
that case it creates what could be considered a "hard link" in your
view, pointing to a single shared version of the object. So, there is
no copy going on here: only one physical copy of the object actually
exists anywhere: this saves the compile time, of course, and it also
saves disk space.
As with anything, there are definite tradeoffs to be made (mainly in
terms of speed and complexity).
csm> This is fine if your machines are homogeneous. However,
csm> it can cause subtle build errors if you are mixing the
csm> tool chains between machines.
Only if you're careless with your makefiles. Clearmake uses a very
rigorous comparison to make sure the object is winkin-able. Besides the
obvious (the same version of all the elements used to build the object)
it also stores the command line used to build it, and if a string
comparison of the command line differs in any way (options that come in
a different order, or even extra whitespace) then winkin doesn't happen.
So, all you have to do to make sure that you don't get these errors is
ensure that your command line contains text related to the target you
want to build. This can be done through the compiler name (ppc-gcc), or
some argument (-DPPC), or the name of the directory where object files
are put (-o ppc/foo.o), or any other difference.
The rules for this just make good sense anyway, for any multi-targeted
build environment, so it's not a hardship.
ClearCase is a very rich, very complex environment. It's got some very
cool parts, and it's also got some very big issues.
Anyway, I don't think this list is the right place to discuss it, as
ClearCase is most definitely not free software.
--
-------------------------------------------------------------------------------
Paul D. Smith <[EMAIL PROTECTED]> HASMAT: HA Software Mthds & Tools
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions---Nortel Networks takes no responsibility for them.
_______________________________________________
help-gnu-utils mailing list
help-gnu-utils@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnu-utils
