%% "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