IBM Rational Consulting, Training and Products by A Better Solution, Inc.

		A low-cost feature-rich alternative to ClearCase Multisite... Affordable, flexible ClearCase "Replication" and "Deployment" options...

ClearReplica Summary

ClearReplica allows remote developers to get local speed access without the high cost of Multisite. With ClearReplica you can "replicate" not only the whole VOB, but just a portion of it if you desire. Replicate to the same region if needed (or even the same VOB). Combine or split "replicated" VOBs at the destination or receiving location. With ClearReplica relaxed mastership, you can let developers from multiple locations work on the same branch at the same time.

Some of the features added in recent ClearReplica versions are:
*	Enhanced shipper-side replication control of selected labels, branches or attributes. ClearReplica shipper processes can be configured to send selected label or branch data. The shipper can be configure to Include or exclude select labels, branches or attributes that match a pattern.
*	Receiver-side control of replicated label, branch or attribute data. ClearReplica receiver processes can be configured to process received label, branch or attribute data from remote sites or ignore label, branch or attribute data completely.
*	Shipper-side control of replicated symbolic links. ClearReplica shipper processes can be configured send cleartool symbolic links creation to remote sites or ignore this symbolic link data completely.
*	Receiver-side control of replicated symbolic links. ClearReplica receiver processes can be configured accept or ignore cleartool symbolic links creation request from remote sites. The receiver processes can be configured to: ignore all remotely received symbolic link data or accept and process all received symbolic link data.
*	Enhanced shipper-side replication control of rmver and rmbranch commands. ClearReplica shipper processes can be configured to send selected rmbranch or rmver data. The shipper can be configure to Include or exclude rmver or rmbranch commands in the packets it sends.
*	Receiver-side control of rmver and rmbranch commands. ClearReplica receiver processes can be configured to process received rmver or rmbranch commands received from remote sites or ignore rmver or rmbranch commands completely.
*	Process Startup/Shutdown Triggers. The starting and stopping of ClearReplica Shipper or Receiver processes can cause user defined triggers to fire. ClearReplica administrators can send notification emails, update web pages or call any user written script or COTS software when Shipper or Receivers start or shutdown.
*	User defined Scheduled-Inactivity time. ClearReplica administrators can define a time that he ClearReplica receives should hold received packets for processing to avoid resource fighting with other known site-specific processes (e.g. "nightly backups" - scheduled "vob locking", etc.). ClearReplica administrators define a start time and end time as the period where the receiver will wait to process received packets.
*	Intelligent Locked VOB processing. ClearReplica receives will automatically hold packets for locked VOBs and process them once the associated VOB is unlocked.
*	Controlled Replication of cleartool lock/unlock (-lbtype, -brtype or -attype) commands. ClearReplica receiver directories can be configured accept or ignore cleartool lock/unlock (lbtype, brtype or attype) requests from remote sites. The receiver directories can be configured to: ignore all remote lock/unlock label, branch or atribute type requests or honor those requests.
*	Controlled Replication of cleartool rmelem commands. ClearReplica receiver directories can be configured accept or ignore cleartool rmelem request from remote sites. The receiver directories can be configured to: ignore all remote rmelem requests, accept only remote rmelem -file requests, accept only rmelem -directory requests or accept all remote rmelem requests.
*	Controlled Replication of cleartool rmtype (-lbtype, -brtype or -attype) commands. ClearReplica receiver directories can be configured accept or ignore cleartool rmtype -kind lbtype request from remote sites. The receiver directories can be configured to: ignore all remote remove label, branch or attribute type requests or honor those requests.
*	Controlled Replication of cleartool rmelem commands. ClearReplica receiver directories can be configured accept or ignore cleartool rmelem request from remote sites. The receiver directories can be configured to: ignore all remote rmelem requests, accept only remote rmelem -file request, accept only rmelem -directory request or accept all remote rmelem request.
*	Relocatable Logging Directories. By default all ClearReplica writes (other than to the VOB itself) are performed within directories underneath the m_bay directory that is located in the ClearTrigger depot directory. For organizations that wish to run ClearTrigger and ClearReplica from a read-only share, media or device, both ClearTrigger (12.5 and higher) and ClearReplica (9.2 and higher) allow for directory relocation. Directory relocation can also useful when managing disk space or improving performance. All directories written to by ClearReplica can be relocated to another directory for writing.
*	Additional "Peer-to-Peer" encryption to ClearReplica. All ClearReplica data has always been encrypted using an internal ClearReplica Data Encryption key so that only ClearReplica can decrypt ClearReplica data packets (perfect for closed or otherwise private networks), but ClearReplica now has additional encryption can be enabled that requires the sender and receiver to agree on a generated encryption key known only to the Sender and Receiver, thus allowing for the secure transportation of packets across open, public or 3rd party networks or even though the use of 3rd party courier services. Even those with ClearReplica cannot decrypt the packet without the "Peer-to-Peer" encryption key.

ClearReplica Details

ClearReplica is a custom add-on to the IBM Rational Software ClearCase product. It provides geographically disjoint development as a less expensive alternative to ClearCase Multisite. ClearReplica provides many of the replication features of ClearCase Multisite as well as additional features. With ClearReplica you can replicate whole VOBs, "portions" of VOBs, a single or select files, a single or select directories or even select branches. Use ClearReplica to replicate multiple VOBs in to single VOBs, single VOBs to multiple VOBs and replicate VOBs to other VOBs within the same ClearCase region. These options allow more flexibility to create on-line backup VOBs and staging or distribution VOBs.

ClearReplica is licensed differently than ClearCase Multisite in that ClearReplica License pricing is not a factor of how many VOBs are replicated or the number of users of those VOBs. ClearReplica is licensed per location, therefore the cost is the same to replicate one VOB with one user from Atlanta to India as it does to replicate 100 VOBs with 300 users from Atlanta to India. Sites can in many instances replace hundreds of Multisite licenses with one or two ClearReplica Licenses. You simply need one license at each site if development is performed at both sites, or a single license at one site if the off-site location is just for backups or disaster recovery. This relaxed licensing results in huge upfront cost savings over traditional Multisite.

ClearReplica requires that ClearTrigger 10.3 or higher is installed at the sending and receiving site; again an unlicensed version of ClearReplica will suffice at the receiving site if no development is performed on the receiving VOB there.

Some restrictions that exist in ClearCase Multisite are relaxed in ClearReplica. For instance, developers can work on the "same" branch at both locations for there is no Multisite mastership restriction. Geographically disjoint development teams can still work on separate branches and this is still the recommended method.

Use ClearReplica for geographically distributed development teams or use it to provide a hot backup to recover lost versions in a fraction of the time. Use ClearReplica to automatically distribute code or binaries located in a directory in a VOB without having to use the bandwidth of replicating the whole VOB. Replicate portions of the VOB to teams all over the world or across the hall. Simply install and configure ClearReplica on top of a ClearTrigger installation and get started!

ClearReplica advantages over traditional Multisite:

+
Lower License Cost and Cost of Entry

+
Parallel and distributed shippers and receivers

+
Extended Transport Mechanisms

+
Extended "Deployment" capabilities to ClearCase

+
Automatic Error Notification

+
Nearly free "disaster recovery", "backup sites" or "distribution hubs"

+
Enhanced Replication Flexibility

+
Confirmation of packet delivery (automatic packet recovery)

+
Relaxed Mastership

+
Relaxed Replica Management

+
Automatic data encryption

+
Additional "peer-to-peer" data encryption

+
Enhanced "Replication Triggers" allow further automation and notification to your "replication" or "deployment" process

+
Enhanced "Replication" and "Deployment" capabilities to disconnected machines or those without a static IP address

Select a feature on the left to see a more detailed description...

ClearReplica Defect Status List

The status of any reported ClearReplica defects will be reported here.

All current ClearReplica binaries are at version and were last updated on .

      - clearreplica_shipper
      - clearreplica_receiver
      - clearreplica_proxy
      - clearreplica_shipout
      - clearreplica_shiptest
      - clearreplica_hostentry
      - clearreplica_crypt_key_gen

Only defects of the current and previous major releases are listed; no defect is listed that is earlier than the last mandatory patch. All defects from previous releases were rolled into the current major release and are no longer listed.

Releases 11.0.3 and higher are supported..

Patch Number

Defect Number and Description

Release Found

Release Fixed

cr11_0.3
(Mandatory)

CR_11.0.2.1
(Problem)

If a ClearReplica receiver receive a packet in a receiver directory that was set to "honor lock/unlock remote label type request" and the receiving VOB had ClearTrigger Policy that prevents users from manually locking/unlocking label types, ClearReplica would fail to keep the label type lock state in sync.

(Fix)

Changed ClearReplica receivers to properly override ClearTrigger in this case where remote label locks/unlock are to be honored.

CR_11.0.2.2
(Problem)

If a -queued_stop request was received by a cleareplica_receiver or cleareplica_shipper process that process would not stop until the current series of packets was processed when it should stop at the next packet in the current series.

(Fix)

Changed ClearReplica "shipper" and "receiver" processes to honor a -queued_stop request before starting to process the very next packet.

CR_11.0.2.3
(Enhancement)

clearreplica_receiver: One can now control whether or not labels are applied to element directory versions during replication.

Within receiver.conf files one can configure receiver directories to modify this behavior. Each directory can have an additional optional parameter (label_dir_personality) defined that determines how or if element directory versions are labeled. The valid values and what they do are below:

"label_dir"

The default if not provided - labels all directories and their imported parents with the versions union of all labels applied during import to contained in those directories. To defeat this behavior, use the no_label_dir option.

"no_label_dir"

Ensures that directory versions are not labeled during the receiving process.

11.0.2

11.0.3

cr11_0.2
(Mandatory)

CR_11.0.1.1		If a ClearReplica receiver that was expecting packets with "standard encryption" received a packet with "peer-to-peer encryption" it would properly toss and destroy the packet, but would not report having done so to the log files. In some cases it would properly toss and destroy the packet, but then stop the receiver unexpectedly.

(Fix)		Changed ClearReplica receivers to properly report this case in the receiver logs. Additional changes were made to log entries to state which encryption is used and expected for both shipper and receiver logs.

CR_11.0.1.2		If the shipper.conf file had in invalid value for transport_program, ClearReplica would continue with the default of ftp and report no error.

(Fix)		Changed ClearReplica Shipper process only allow valid values for transport_program if provided. All non-valid values will cause the shipper to report the value as illegal at startup before shutting down. The default of "ftp" is only used when no value is provided in the shipper.conf file.

CR_11.0.1.3		For UNIX only: In some rare cases if the ClearReplica Shipper was started with the -start and -wait flags together the shipper would end unexpectedly when it processed its first packet.

(Fix)		Changed ClearReplica Shipper so that it would properly run in these cases.

11.0.1

11.0.2

Can ClearReplica be used as the "deployment" mechanism for your DevOps infrastructure?

ClearReplica can be your DevOPs deployment engine Yes. Not only can you use ClearReplica to perform automated deployments, but it is cost effective, because you only need a ClearReplica license at the distribution point. From the single distribution point you can deploy to any number of machines all over the world.

Replication Triggers allow you to customize the destination location's automated process. So you can use ClearReplica to distribute you application to hundreds of machines and then automate the installation of those distributed applications at those destination hosts. You can even deploy to laptops with "dynamic IP addresses" without having to update deployment scripts.

You can view the to hear more about ClearReplica.