I have a perculier problem about how to maintain a clearcase project.
This project is a xml schema repository where each schema has a version. This repository is common and is used by all the apps in the enterprise. From clearcase prespective the project has a single component.
Now the apps can be using different versions of the schema(s). So we are trying to figureout a way to setup the project in such way that a project can have a baseline of what versions of these files are included in a build.
The only way we know of how to do this is to create a component for each schema or group of schemas and create a stream for each app to include the components they use. But that would result in too many components.
Has anyone dealth with something like this before? We are prepared to restructre the whole project if necessary, so we are open to any idea. Thans for the help.
The idea behind a UCM component is to reference a coherent group of file, i.e all files within a UCM component are labeled (baselined) even if only one of them if modified.
The life-cycle of those files is common, and they are used as a whole.
In your case:
each file (xml schema) can evolve on its own
the granularity is at file level (and not group of files)
You can group those files in one component, but each of your project will then need to extract its own version of the relevant file, through extended path names.
That means:
your project reference the latest baseline of the "XML schema repo" UCM component
it extract from that component the relevant version of the various xlm files it needs
and copy those version in a private (non-versioned) directory
Related
In VS 2017, or more accurately, the old project format used in VS 2017, each project had a 'Properties' folder with an AssemblyInfo.cs file which held things like project version, copyright, etc.
If you wanted to share some of that information between several projects, say all those in a particular solution, you created a AssemblyInfo_Shared.cs file, moved the shared properties into it, removing them from the original AssemblyInfo.cs file, then you would 'link' the shared version into each separate project.
Now when you build, information that is in AssemblyInfo_Shared.cs will be shared between all projects where as project-specific values would remain in the original AssemblyInfo.cs file.
However, in the new project format, these values are all embedded into the project's file, which now is a simple XML file. How can you share settings between projects now?
Properties (and even items) in the project file are processed by MSBuild, and can easily be refactored into .props and .targets files that are shared among your projects.
With the new project file format, MSBuild will automatically import files named Directory.Build.props at the beginning of your project, and Directory.Build.targets at the end - this includes searching up the folder tree until one of these is found. With this, it is very easy to share properties across all projects in your solution: simply create a Directory.Build.props file in the solution folder with your version properties, and every project will share those properties.
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.
I want to ask what is exactly the derived object in ClearCase and how is work.
Additional i want to ask if there is an other program with the same function, because in Git, MKS or in IBM® Rational Team Concert™ i cannot find something similar, is it obsolete ?
This is quite linked to dynamic views, which are very specific to ClearCase and not found in other more recent VCS.
See "ClearCase Build Concepts"
Developers perform builds, along with all other work related to ClearCase, in views. Typically, developers work in separate, private views. Sometimes, a team shares a single view (for example, during a software integration period).
As described in Developing Software, each view provides a complete environment for building software that includes a particular configuration of source versions and a private work area in which you can modify source files, and use build tools to create object modules, executables, and so on.
As a build environment, each view is partially isolated from other views. Building software in one view never disturbs the work in another view, even another build of the same program at the same time. However, when working in a dynamic view, you can examine and benefit from work done previously in another dynamic view. A new build shares files created by previous builds, when appropriate. This sharing saves the time and disk space involved in building new objects that duplicate existing ones.
You can (but need not) determine what other builds have taken place in a directory, across all dynamic views. ClearCase includes tools for listing and comparing past builds.
The key to this scheme is that the project team's VOBs constitute a globally accessible repository for files created by builds, in the same way that they provide a repository for the source files that go into builds.
A file produced by a software build is a derived object (DO). Associated with each derived object is a configuration record (CR), which clearmake or omake uses during subsequent builds to determine whether the DO can be reused or shared.
A derived object (DO) is a file created in a VOB during a build or build audit with clearmake or omake.
Each DO has an associated configuration record (CR), which is the bill of materials for the DO. The CR documents aspects of the build environment, the assembly procedure for a DO, and all the files involved in the creation of the DO.
The build tool attempts to avoid rebuilding derived objects.
If an appropriate derived object exists in the view, clearmake or omake reuses that DO.
If there is no appropriate DO in the view, clearmake or omake looks for an existing DO built in another view that can be winked in to the current view.
The search process is called shopping.
This is relevant for very large C or C++ makefile-based projects.
I think the TL;DR version of this is:
Derived objects contain information that describes
What was accessed to build the object, including dependencies that may bot be in your build files.
Other files created during the build process ("Sibling Derived Objects")
The commands used to build the object (The "build script") assuming that clearmake, omake, or the ANT listener were used to run the build.
In the case of clearmake and omake, this information is used to avoid rebuilds, potentially speeding builds. The lookup is referred to DO "shopping" and the build avoidance is "winkin."
If you have regulatory or security compliance or needs where this level of auditing is critical, there really isn't anything else that does this.
I'm wondering if it is possible to create project-specific files in Clearcase. What I want to do is create files in one project, use Clearcase to source control the files, but I don't want those files to leave that porject because they don't have applicability in any other project.
For example:
I want to manage database changes in Clearcase. I plan on having 3 folders in each project (projects are created for each release of the software). The folders are "install", "update", and "backout". The install folder contains the scripts needed to build a database from scratch for the stream that I'm working in, let's say the stream is in project "13.03". The "update" and "backout" folders contain scripts needed to update and backout the changes to bring the database from 13.02 to 13.03, and vice versa.
In the 13.04 project, I'll have the same folder structure, but I don't want the contents of the "update" and "backout" folders in my 13.04 because I'll have other files that will bring the database from 13.03 to 13.04.
So what I'm looking to do is essentially create "project-specific" files/folders in Clearcase.
I'd gladly take any other recommendation for managing database changes in Clearcase. Keep in mind that the 13.03 and 13.04 (for example) baselines could be being developed at the same time.
It seems you are referring to the same project, with different versions (13.02, 13.03, ...).
If that is the case:
simply update your 3 folder according to the current version
put a baseline (if we are talking about ClearCase UCM) on the component representing your project
if evolutions needs to be done on any file of a specific version, make a child Stream called, for instance, "13.03", and update your "13.03" folders there. They will evolve in complete isolation in their own dedicated "13.03" branch.
If you have to create a new directory for each project version (which means you don't need a source control system at all, just a simple backup system), then you have no choice but to recreate each of those folders with their appropriate files in them, making new "add to source control".
Is it possible?
Exporting sources from ClearCase?
The surest way is a snapshot view on a dedicated workstation: since a snapshot view has its storage (the equivalent of the .svn directories) outside the said view, that means the resulting directory is clean.
Then you can take this tree, compress it and transfer it whenever you want, (like a workstation without any VCS)
Use a snapshot view. Update the config spec in such a way that it selects the latest version of all elements from the main branch.
Copy the folder recursively to another folder say c:\svntemp
Import the contents in c:\svntemp\ in to SVN.
For each branch that you have you need to follow this procedure