Does anyone know the rules for winking in derived objects (DO) when using clearmake?
I got into a situation where a clean compilation resulted in .o and .d files being 5 days old. After investigation I found that a sibling view had the same baseline as me, but hadn't been recompiled since the rebase and these DO's were being winked in to my view.
Will DO's in the team view get winked in to child streams or does it only work with siblings? Further will winking in happen across all views in any hierarchy?
Many thanks
EDIT : More specifically I want to know where the DO's are winked in from? Sibling views only? Any view with the same baseline?
Thanks again
It seems you are dealing with shareable DOs
In order to avoid winkin between views, you can use clearmake -V, which disables any winkin.
They shouldn't winked between views, unless the command winkin is called explicitly and/or your are dealing with sharable DOs.
The child stream could get the same DO's if its foundation baseline is the same than the prarent stream, referencing the same versions.
Related
I am working with ClearCase UCM. We have a project that has been created as a 'single stream' Project Type.
We now wish this to have multiple child streams.
Is there a way to change this after creation? If so, how? Or does this need to be recreated?
I have looked into commands that change the project, but other than policies, I can't see if something may be related - and I can't see any related policy names - but this is fairly new to me, I just happen to have the most experience in my area.
The simple/multi-stream nature of an UCM project is determined at its creation with cleartool mkproj -model.
The "model" (simple or default) is not something you can change by policy or with cleartool chproj.
That is why the IBM help page on "Single-stream projects" says:
You may want to use a single-stream project during the initial stage of development when several developers want to share code quickly.
When the development effort expands and you need a parallel development environment, you can create a multiple-stream project based on the final baselines in the single-stream project.
We are trying set up a complex project and we are trying to limit the number of views and branches.
We are working in UCM ClearCase where different groups work independently then merge into a merge branch once everything clears testing.
Is it at all possible to point the config spec of our new views to several different branches?
If so is there anything that we need to think about?
Maybe someone could post an example that they have created?
An UCM view is always related to one Stream, so using one branch (if said Stream contains modifiable components)
A base ClearCase view could be configured to monitor several branches, but only one rule (the last one which can be applied for a given file version) will prevail, ie only one branch will be selected.
So it isn't possible.
We have a table in our our database that stores XSL's and XSD's that are applied to XML documents created in our application. This table is versioned in the sense that each time a change is made, a new row is created.
I'm trying to propose that we store the XSL's and XSD's as files in our Source control system instead of relying on the database to track the history. Each time a file is updated, we would deploy the new version to the database.
I don't seem to be getting much agreement on the issue. can anyone help me out with pros and cons of this approach? Perhaps I'm missing something.
XSL and XSD files are part of the application and so ought to be kept under source control. That's just obvious. Even if somebody wanted to catgorise them as data they would be reference data and so - in my book at least - would need to be kept under source control. This is because reference data is part of the application and so part of its configuration. For instance, applications which use the database to store values for drop downs or to implement business rules need to be certain that it holds the right version of the data.
The only argument for keeping multiple versions of the files in the dtabase would be if you might need to process older versions of the XML files. This depends on the nature of your application. Certainly I have worked on systems where XML files / messages came from external (third party) systems, where we really had no control over the format of the messages sent. So for a variety of reasons we needed to be able to handle incoming XML regardless of whether its structure was current or historical. But is is in addition to storing the files in a source control repository, not instead of.
I'm currently working on a project that has several 'Visual Studio Solutions'. One is for the main application and the others are component-based projects which will be reused in other applications.
The problem is that all three solutions need to access data from the same database. Each component has its own set of views, functions and sprocs but the schema differs in places (one component may require a field that another component doesn't).
Basically, I don't want to have one solution break because of a change that I've made in another one.
The way I see it I have two options:
Create a new project that is referenced in all solutions that purely contains database scripts
Manage the Schema in the main application solution and the views, functions and sprocs in the other solutions (as appropriate) and be very, very careful when I do a build
Any suggestions would be greatly appreciated.
Thanks in advance,
Jason
Just thought I'd post my solution here just in case anyone else comes across the same problem...
I went with option one in the end. I created a new Database Project which is referenced in all 3 solutions. Not the prettiest solution in the world, but it works.
Thanks again to pranay for responding.
One of the shops I'm working at relies on dynamic views in ClearCase. The established norm has been to create a new view for each project effort. Over time I've found that I've only needed to have one or two views concurrently active. I've taken to "reusing" a view by changing the config spec (subsequent to check-in, label, release, etc.). So far, it has worked out. Is there any long-term problem with doing that? If not, is there anyway I can re-name the view (change the view tag) to better reflect what the purpose of the view is?
For base ClearCase dynamic views, the only side-effect you can have when recycling a config spec are private files:
Those are store within the dynamic view storage, and not always removed when the config spec is reset.
You also need to make sure no files were left checked-out: they also are stored in the view storage, and once the config spec has changed, they may not be visible/reachable any more (but you should still be able to unco them through the 'find co' GUI).
You cannot rename (change the tag) of a view (dynamic or snapshot)
And, just to be complete, you cannot recycle the config spec of an UCM dynamic view (which reference a stream).
You can try to change the foundation baselines of said stream, but again, that is not always possible.
I vote for scrapping old views and creating views afresh. Besides all teh great inputs from VonC, from the disk space point of view, old views tend to get bulky over time and you soon you wont be a favorite with your sysadmins :-)
From my experience there is no log term affect for using only 2 dynamic views instead of one for each "project". If you don't need the views active concurrently its a good method, thats the beauty if dynamic views they can be updated very fast and very frequently.
For the renaming part, why rename? make a similar new dynamic view (or two) and give it a new name (view tag).