Here are 2 methods for removing a version of an element. The first method is limited to rolling back the latest version, however, the second will allow a rollback to any version. It's not a good idea to delete a version in ClearCase because they can be problematic.
Method 1- Subtractive Merge:
cleartool merge -graphical -to {ELEMENT} -delete -version {VERSION}
e.g cleartool merge -graphical -to deploy-lib-init.xml -delete -version \main\37
If no manual merges were required on checkin ,then chances are this will be resolved automatically. All of the data for this can be obtained by right clicking on the element in ClearCase Explorer -> Properties of version. You should get a window like:
**NOTE** Because the window has a fixed size you cant see the whole string for "Name", I would advise copying the string into a text editor.
D:\CC\CASPA\willis7_CASPA_int\IPS_Source\System\build\deploy-lib-init.xml@@\main\37
The two highlighted parts are the ELEMENT and VERSION respectively.
Method 2- Hijack with older version:
cleartool get –to {ELEMENT} {ELEMENT}@@{VERSION}
e.g. cleartool get –to deploy-lib-init.xml deploy-lib-init.xml@@\main\5
A slightly easier approach. This involves hijacking your local version with a version specified by yourself (the example above would take version 5). This can then be checked out and back in to create a new version that replicates the specified version.
Showing posts with label ClearCase. Show all posts
Showing posts with label ClearCase. Show all posts
Something simple, but very effective!
I want you to do something for me; at the top of the browser you’re reading this on there should be a help button (unless you’re on a mobile device). Click it, then click the about option. You should be presented with something similar to this:
If the application you or your company is developing doesn’t have this feature then you need to give yourself a slap on the wrist and ask yourself, WHY? As a release engineer we’re often expected to know exactly what’s in every environment at all times. If you’re a small organisation with only a few projects and deliveries then this is sometimes possible, but even then what happens if you go on holiday and someone else covers for you??
If you’re using Ant I would advise writing a small task that will pull a few basic parameters from your build machine. Some useful properties to gather are the following:
Username
Build Machine
Date
Time
Build Number
Here’s the Ant target I use. It includes some ClearCase stuff (the source tool we use) but I thought I would leave it in for information.
Write some code to get this to display in your app then its job done!
I want you to do something for me; at the top of the browser you’re reading this on there should be a help button (unless you’re on a mobile device). Click it, then click the about option. You should be presented with something similar to this:
If the application you or your company is developing doesn’t have this feature then you need to give yourself a slap on the wrist and ask yourself, WHY? As a release engineer we’re often expected to know exactly what’s in every environment at all times. If you’re a small organisation with only a few projects and deliveries then this is sometimes possible, but even then what happens if you go on holiday and someone else covers for you??
If you’re using Ant I would advise writing a small task that will pull a few basic parameters from your build machine. Some useful properties to gather are the following:
Username
Build Machine
Date
Time
Build Number
Here’s the Ant target I use. It includes some ClearCase stuff (the source tool we use) but I thought I would leave it in for information.
<target name="buildinfo" description="Record build metadata">
<echo message="${line.separator}" file="${build.props.file}" append="true"/>
<echo message="buildby=${env.USERNAME}${line.separator}" file="${build.props.file}" append="true"/>
<echo message="host=${env.COMPUTERNAME}${line.separator}" file="${build.props.file}" append="true"/>
<echo message="builddate=${build.time}${line.separator}" file="${build.props.file}" append="true"/>
<echo message="buildview=${cc.view}${line.separator}" file="${build.props.file}" append="true"/>
<echo message="buildstream=${cc.stream}${line.separator}" file="${build.props.file}" append="true"/>
<echo message="buildproject=${cc.project}${line.separator}" file="${build.props.file}" append="true"/>
<echo message="foundationbaseline=${cc.found-baselines}${line.separator}" file="${build.props.file}" append="true"/>
<echo message="recommendedbaseline=${cc.rec-baseline}${line.separator}" file="${build.props.file}" append="true"/>
<echo message="Projrecommendedbaseline=${cc.rec-bline-stream}${line.separator}" file="${build.props.file}" append="true"/>
<echo message="currentbaselines=${cc.current-baselines}${line.separator}" file="${build.props.file}" append="true"/>
</target>
Write some code to get this to display in your app then its job done!
Posted by
Sion
at
09:32
In the company I work for Cruise Control has always been the primary continuous integration tool. When I was asked to add a few projects to Cruise Control I thought it would be a fairly straightforward task.... I was wrong. Cruise Control works by setting up your projects with a series of .xml files and running a batch file that pulls the configurations from these files and starts the continuous polling.
Thankfully, Jenkins(Hudson at the time) was in the pipeline and I was given the responsibility of migrating one of our latest projects to it. Jenkins is a very easy to use tool which hides much of the 'hard' configuration behind a GUI.
One thing to note here is that you will be downloading a .war file NOT a .zip . This caused a great deal of confusion when I downloaded this from a Windows PC and it decided to rename the file to a .zip - furthermore, Winzip will happily open the file as if it was a .zip . If this happens simply change the file extension to .war.
On the host machine you can now start running Jenkins. To get Jenkins running I created a small batch file (Linux script here):
@ECHO off
@rem *************************************************************************
@rem PROPERTIES - Set these here.
@rem
@rem *************************************************************************
SET HTTP_PORT="8080"
SET AJP_PORT="8000"
SET JAVA_HOME=D:\Tools\jdk\jdk160_14_R27.6.5-32
@rem JAVA properties
SET MAX_PERM_SIZE=128m
@rem *************************************************************************
@rem Make sure you have a Java JDK on your machine and that you have it added
@rem to the PATH environment variable
@rem *************************************************************************
SET PATH=%JAVA_HOME%\bin;%PATH%
@rem *************************************************************************
@rem Set the window title. Change project name to suit
@rem *************************************************************************
TITLE Jenkins Continuous Integration
@rem Start Jenkins
java -jar jenkins.war --httpPort=%HTTP_PORT% --ajp13Port=%AJP_PORT% -XX:MaxPermSize=%MAX_PERM_SIZE%
Thankfully, Jenkins(Hudson at the time) was in the pipeline and I was given the responsibility of migrating one of our latest projects to it. Jenkins is a very easy to use tool which hides much of the 'hard' configuration behind a GUI.
Installing Jenkins
To run Jenkins you must first download it from the Jenkins website and save it to a sensible location. The latest version can be found at the Jenkins Website.One thing to note here is that you will be downloading a .war file NOT a .zip . This caused a great deal of confusion when I downloaded this from a Windows PC and it decided to rename the file to a .zip - furthermore, Winzip will happily open the file as if it was a .zip . If this happens simply change the file extension to .war.
On the host machine you can now start running Jenkins. To get Jenkins running I created a small batch file (Linux script here):
@ECHO off
@rem *************************************************************************
@rem PROPERTIES - Set these here.
@rem
@rem *************************************************************************
SET HTTP_PORT="8080"
SET AJP_PORT="8000"
SET JAVA_HOME=D:\Tools\jdk\jdk160_14_R27.6.5-32
@rem JAVA properties
SET MAX_PERM_SIZE=128m
@rem *************************************************************************
@rem Make sure you have a Java JDK on your machine and that you have it added
@rem to the PATH environment variable
@rem *************************************************************************
SET PATH=%JAVA_HOME%\bin;%PATH%
@rem *************************************************************************
@rem Set the window title. Change project name to suit
@rem *************************************************************************
TITLE Jenkins Continuous Integration
@rem Start Jenkins
java -jar jenkins.war --httpPort=%HTTP_PORT% --ajp13Port=%AJP_PORT% -XX:MaxPermSize=%MAX_PERM_SIZE%
Subscribe to:
Posts (Atom)