IBM ClearCase to P4 Migration Guide

Preliminary Migration Preparation

Review Existing Branching Strategy

Early in your migration planning, determine whether your current branching strategy used in ClearCase is appropriate to use going forward. If not, adjust your strategy as needed.

Creating an initial branching strategy is a best practice when getting started in Perforce P4. Perforce Streams can model your branching strategy and indicate the intended flow of change.

Perforce Directory Standard (PDS)

With P4, the directory structure and branching strategy are related. A well-designed directory structure is critical because it:

It’s a best practice to create a Perforce Directory Standard (PDS) to establish the directory structure and corresponding branching strategy in P4.

Release Processes and the PDS

The directory structure in Perforce P4 can be thought of in “low” and “high” levels. Low levels represent your software products, and can vary for each software product. High levels of a Perforce directory structure convey branching structure, project management, and software lifecycle information. A well-designed, high-level directory structure is intuitive for developers and lends itself well to project management metrics, policy enforcement by branch type, and various kinds of automation.

Migrating to P4 typically involves defining a Perforce Directory Standard (PDS) for each product that is imported into P4. In some cases, it can be used across the entire organization. A PDS encourages consistency in release processes for various software products. It can be as flexible as needed to account for the different release processes and branching patterns for various software products in P4.

For example, one software product might be licensed, which might have a release process that defines how to maintain old releases and deliver patches. A web-based software product, in contrast, might not require maintenance of old releases, but must support rapid updates. Still another product could have a set of generic components that are delivered to customers then heavily customized, perhaps by your own organization.

Release processes for different software products may also vary due to the number of contributors and the structure of QA processes. Software products can follow the same release process, even though they might have very different release schedules.

Low levels of the directory structure are left untouched by the migration. This minimizes the difficulty of performing the migration and the impact of the migration to your environment (e.g. build scripts, release processes and tools, etc.)

Perforce Streams

Perforce Streams models branches at a higher level. A stream defines multiple things:

• What related files are included in a set.
• Where those files came from (the parent stream).
• How change flows to other streams.
• How parts of a stream are treated in the workspace.

Streams is an attractive framework for new projects in P4. The tools and workflow improvements simplify work for end users based on industry best practices. It also makes project and release management easier.

The detailed history import (DHI) tool used by P4 currently does not support ClearCase data being imported directly into Streams. However, ClearCase data can be imported into “classic” Perforce P4 branches and then migrated to Streams for future work. Alternatively, the baseline & branch import (BBI) method can be used to import ClearCase data directly into Streams.

Addressing Intellectual Property

Maintaining IP provenance (i.e., knowing where your source code came from and knowing what legal rights you have to it) can be made a priority during the migration. When looking at the migration process, your goal should be to ensure that IP provenance is not negatively impacted. Your migration processes should provide a clear audit trail so that all imported files can be traced back to the original ClearCase repository.

VCS systems inherently store valuable intellectual property. If sensitive information is being migrated, both the migration process and the resulting P4 environment should ensure that access is controlled to the same degree as it was in ClearCase.

Migrations also provide an opportunity to review access control policies. This process can help expose particularly weak access controls, and highlight where controls have gone too far. In some cases, ensuring strong IP protections requires extra effort. It is important to consider if strong access controls really benefit your organization.

The powerful and flexible access control capabilities available in P4 provide a straightforward means of guarding IP with relative ease.

Training

Training for Perforce P4 users and administrators is essential to help a migration go smoothly. We find it most effective to train the bulk of users a few days to a few weeks prior to the migration to P4.

Perforce provides a variety of training options including in-person and online instructor-led training. It is most effective to provide instructor-led training to a core set of administrators and key users (e.g., “train the trainers”).

Perforce P4 Transition Team

We recommend establishing a transition team during your migration process. This core group may include application administrators, system administrators, and other influential users. You might consider engaging Perforce Consulting to be a part of your transition team. The transition team defines how P4 will be used in your organization:

• How it will tie into your various processes and workflows?
• How should it will be integrated with other systems?

For larger and more complex migrations, training for this team should occur early in the planning process. This allows best practices established by the team to evolve, be documented, and be communicated to the larger user community.

Import Strategies

There are three supported approaches for importing files:

The following is an overview of the strengths and limitations of each import strategy.

Starting Over Strategy - Tips

Starting over really isn’t really a conversion strategy. This approach uses the “tips” — the / main/LATEST file versions from ClearCase – and simply adds them to P4 without any history.

Based on your organization’s Perforce Directory Standard, a high-level directory is identified in which the files will be stored. For example:

//Janus/main/src

In this example, Janus is a product name. Main indicates files in the main stream of development. Src is the root of the low-level directory tree. The low-level directory tree is copied verbatim into P4.

The “Tips approach” is sometimes appropriate for specific parts of a project. For example:

• Documentation VOBs
• VOBs for shelved but not terminated projects.

This approach is usually not appropriate for source code, except for prototype and demo code.

Even in simple Tips migrations, care must be taken to ensure that file types are mapped correctly. Text, binary, and Unicode files should be reviewed. Also file type modifiers should be applied when migrating, such as ‘+x’ for executables and ‘+F’ for compressed binary formats like *.gz or *.mpg, etc.

Starting over offers some benefits. First, it can be easy. You define target directories in P4 and then add the files. Because there is less to migrate, it is also faster.

But for organizations that need to remain in compliance, this approach does not move historical information into P4. If multiple branches are imported, P4 won’t be able to simplify first-time merges between them. In order to easily perform these merges, P4 needs to understand the historical relationship between the branches.

Detailed History Import (DHI)

Detailed history import (DHI) is the logical extreme migration case. The goal with this approach is to capture as much detailed branch/merge information and migrate it into P4. This ensures that comprehensive historical research can be done in the new system, without the benefit of the old.

Perforce has a sophisticated tool and process that enables conversion of very detailed historical data from ClearCase to Perforce P4. The tool has been successfully used for performing detailed history conversions from fairly large ClearCase data sets (about 100 GB) to P4. Due to licensing restrictions and operational complexity, the DHI conversion tool is only available through Perforce Consulting services.

Detailed history migrations from ClearCase can be selective. You can select only a subset of VOBs to be imported. Within each imported VOB, a subset of all available files and labels are typically targeted for import.

Conversion includes file contents for each revision. Details include the metadata associated with each check-in, file renames, and detailed branching and merging history. ClearCase’s representation of branching activity is translated into P4 as “integration records.”

The import process groups ClearCase “check-ins” into P4 “changelists.” For example, if a given user checked in a set of files at the same time (+/- a few minutes) with the same check-in comment, those would be grouped together as a single P4 changelist. UCM metadata, if available, also factors into changelist grouping.

Our migration process starts by scanning repositories for various issues that need to be resolved in ClearCase prior to migration. Examples include:

• “Evil twin” files and directories.
• File types such as “block special devices” that are supported only in ClearCase.
• File types (such as hard links) that can be imported, but require special emulation in P4.
• Architectural and conceptual differences between ClearCase and P4. For example, mapping ClearCase labels into P4 proves rather difficult, because typical usage of labels varies between the systems.
• Certain rare “circular merge” activities that are not easily translated into P4.
• ClearCase repositories that have mild data corruption that might not be visible to normal users but would be exposed when a detailed conversion history tool runs specific commands.

DHI has a more involved undertaking with ClearCase than with other VCS systems. Concepts from UCM and RUP that depend on ClearCase attributes and triggers are not handled by import tools. They require manual importing.

Depending on the amount of data being migrated and the speed of ClearCase in your environment, a complex migration strategy using imports running in parallel may be required. Extracting all information from ClearCase – with years of history – might take a full week to perform the mechanical extraction/import.

ClearCase DHI Preparation

If you plan to engage Perforce to help you plan a detailed history migration from ClearCase, there are a few things to be aware of early in your planning process.

You’ll first need to establish a replica of your ClearCase environment, including all VOBs targeted for import. This instance should be provisioned on hardware separate from your production environment. This allows dry runs to be completed without taxing a production server.

The migration will also require a powerful, dedicated migration server. This can be the new P4 server, but it does not have to be. It must be a Linux server, even if the production and replica servers are Windows. A fast network connection between the ClearCase replica machine, the migration server, and the P4 server (which can be the same machine) is essential.

Migration is a very resource-intensive process and can potentially be very demanding in terms of disk space and RAM resources. It is more demanding than actual P4 server operations, as the equivalent of years of work done in ClearCase is compressed into hours or days to get it into P4.

Detailed migration often involves custom scripting due to differences in ClearCase usage, oddities in a particular data set, and custom requirements. This is why it is important to review all your requirements prior to migration.

Detailed History Import - Pros

Using a DHI strategy gives you the ability to view file history using powerful visualization tools from P4, such as Time Lapse View. This can shed new light on the evolution of your source code and give you a better understanding of changes over time.

There is also an increased benefit for systems integrated with version control. For example, the meaning of the linkage between a set of files originally modified in ClearCase, and an issue from your issue tracking system, can be maintained. Plus with code review tools like P4 Code Review, you can continue to provide greater context to future changes.

Unlike P4, ClearCase does not have a way to validate the integrity of versioned file contents using checksums. Corruption of file contents – e.g. due to disk failures – can go undetected1. Once historical data is in P4, it will benefit from checksum verification, which will improve IP provenance. This allows your teams to access a file’s history that before might have been impossible.

After the migration, comprehensive historical research and “merge forensics” can be done in P4 without the need for going back into ClearCase. Although, if possible, it is recommended you keep ClearCase as a backup with one user license for a few years.

Detailed History Import - Cons

Detailed import tools have a variety of technical limitations. Some of these limitations are due to differences in the way ClearCase and P4 work. Others are due to the potential complexity of ClearCase environments, including unusual patterns (or even corruption) in the data. So-called “evil twin” elements and certain circular branching patterns created by misconfigured config specs can be difficult to follow.

Existing detailed history import tools may require development to work on your data prior to migrating. The likelihood of this scenario depends on your data. It is typically necessary if a full-context migration is attempted. Added complexity translates into potential schedule and budget risks for your migration project.

Baseline & Branch Import

The baseline & branch import (BBI) strategy provides a lightweight migration alternative. It is more sophisticated than the simple Tips approach, yet without the technical complexity involved in detailed history import (DHI).

The BBI process is generic and can be done from any other version control system to P4. Customers have used it to migrate from a variety of systems – IBM ClearCase®, Borland StarTeam®, Merant PVCS®, Subversion, Mercurial, CVS, Microsoft Visual Source Safe, and AccuRev. It has even been used to migrate from a set of network drives with directories named to indicate releases.

With the BBI approach, only certain points in your history are imported. The branch diagram shows the baselines – snapshots of a directory structure at a point in time – and major branching operations.

Sample Baseline & Branch Diagram

The baselines (blue dots) indicate what “interesting versions” are to be imported. The arrows indicate major branching operations that affect an entire branch. In this scenario, a 2.0-Rel branch has been created along with four patches on that branch. When migrating to P4, we can see only two of those four patches have been merged back to MAIN. The BBI process:

• Imports all the baselines.
• Records the fact that two merges were completed with updates added to MAIN
• Tracks the two unmerged patches remaining on the release branch.

Once all this information is available in P4, it can be used to complete new merges. Importing the branching operations allows P4 to select common ancestors for merge work. After the migration, your teams can pick up right where they left off with branching activities.

The BBI process imports branching operations at a high level, capturing the sum of merge operations. For example, in Figure 1, the arrow representing the merge of p2 back to MAIN would likely have occurred as a series of merges carried out by several developers. The individual file merges are not tracked, but the sum of the results of the merge – file adds, edits, and deletes – are tracked. The imported baseline represents a point in time when the merge of p2 is considered complete.

The goal with BBI is to bring over just enough branching history to answer key questions. For example:

• What did release 2.0 look like?
• Where was this file branched from?
• What files do I need in my workspace to start maintenance work on release 2.3?

Because the BBI approach preserves file contents at key points, the cutover to P4 can happen at any point in the release cycle.

After conversion, P4 would show history of your software product in its Revision Graph tool. This view will look like the product was developed in P4 from the beginning. Although detailed data is lost, you will know what the state of your product looked like at each release. But the hundreds of check-ins between those baselines are discarded, as are user-ids, dates, times, and check-in comments.

Accurate diagrams are essential for planning a BBI migration. Ideally, release engineers should draw a branch history picture for each software product to be imported. This information can also be manually found in ClearCase. Once the diagram is drawn and vetted, it is translated into a set of Perforce commands that recreate the baselines in P4.

The first baseline will appear as an initial addition of the entire product directory tree. Subsequent baselines result in Perforce changelists that show only certain changes like files added, deleted, or modified. Branching operations are translated into P4 equivalents. Merges done in ClearCase are recorded in P4 as the results of the merges.

If your organization will still need access to detailed historical research, ClearCase can be kept running with a single license. It is a good idea to keep this ClearCase license around at least for a year or two after a BBI migration.

Baseline & Branch Import - Pros

When implementing a BBI strategy, ideally you would want the flexibility to do a multisystem migration for different teams. Each team could potentially migrate into P4 on their own schedule and without impacting others. Because the BBI approach works against a live, running P4 server (rather than generating separate server instances like some detailed history import tools) the project planning for each team does not require coordination.

Once your “interesting history” is available in P4, you can use powerful file and directory diff tools – Revision Graph and Time Lapse View – to view your old files in a new light. Unlike the detailed imports, you won’t be able to tell exactly who changed what, when, and why. But you can tell how the software product evolved from baseline to baseline.

The BBI process is fairly straightforward, and has little risk of technical snags. Compared to detailed options, this approach makes migration particularly easy. All the historical information can be loaded into P4 prior to migrating teams. Then, on the day of cutover, only the baselines representing the latest state of development on active branches needs to be brought in.

BBI also runs very quickly. Because of this, dry runs can easily be done to test changes that may need to be part of the migration, such as updates to build scripts or make files. And the amount of metadata resulting from BBI is negligible and does not unduly impact performance or initial capacity planning.

Migrating to a new VCS tool gives you the opportunity to normalize past history into a new PDS. This allows you to create consistency across activities, such as the creation of branches. In cases where branching strategies evolved over time with ClearCase, you can simplify historical research of the imported baselines. With the BBI approach, common concepts such as “software product X went to production” can be indicated the same way for each of the imported software products.

Baseline & Branch Import - Cons

In cases where files were renamed or directory structures were reorganized between releases, the historical connection between files’ names can be difficult to capture. For example, file hello.c in v1.0 of your software product was renamed greetings.c in v1.1. The fact that greetings.c used to be hello.c requires analysis of your data to detect.

Both ClearCase and P4 track renames, but each in their own way. But in BBI migrations, that historical linkage of the renaming is sometimes forgone. Renaming can be easily captured – as opposed to showing a delete of one file and the adding another – without the connection that the two are related.

ClearCase allows versioning of some uncommon, low-level file types on some platforms. These block special devices and character special devices are not supported in P4. Such files will not be imported with BBI or any migration strategy. Symbolic links can be imported, however.

Warnings with BBI Strategy

If version control best practices were not followed with ClearCase, reproducing the baselines may be difficult2. For example, if branches were made from /main/LATEST rather than from a label on MAIN, getting a config spec to epresent the baseline from which a branch was created may involve some guesswork. You may need to use / main/LATEST with a ‘–time’ clause and select a “best guess time" to represent the point on MAIN at which a branch was created.

Terminology and Concepts

In this section, we will review the P4 equivalents of basic ClearCase concepts. Consider these when planning your migration.

VOBS and Depots

A P4 depot is roughly equivalent to a ClearCase VOB (Versioned Object Base). VOBs and depots both display as top-level directories to users, and store a set of files. At least one VOB or depot must exist before any file can be versioned.

A VOB is a container for versioned file contents and metadata related to those versioned files. A P4 depot contains only the contents of versioned files. All metadata is stored in a central database on the P4 server.

When mapping VOBs to depots, consider the following:

• Unlike files in ClearCase VOBs, files can be branched across depots in P4. Depots are more transparent (barring any special access controls).
• In P4, you can manage all digital assets – including binary files. Most customers do not manage binaries in ClearCase due to performance considerations. When mapping, you can create a depot for source code and other various components of software products. For example, a depot might be assigned fore each, e.g. //gizmo, // gizmo-build, and //gizmo-release.
• Depots can be created in seconds, but can last a lifetime. Choose their names wisely. Names should be kept short to allow them to be referenced easier. For example: //Engineering is OK, but //Eng is better.
• Path names are primary keys in many P4 databases. Character limits are platform dependent and no less than 1024 characters.

ClearCase Regions

In ClearCase, network registry regions can be employed to segregate VOBs. These regions restrict a user to see only a subset of all VOBs. To achieve similar segregation in P4, the P4 Protections Table can be used. Users who were in different regions in ClearCase would be assigned to different user groups in P4. Access to different depots would then be managed at the group level.

VOB Servers vs. P4 Server

In ClearCase environments, there may be multiple VOB server processes potentially distributed across multiple VOB server machines. With P4, a single server may be adequate for any given installation3. The process easily runs on a single machine and is frugal with system resources when compared to ClearCase. One P4 server can scale to support extremely large environments (e.g. 10,000+ users) using enterprise-grade server machines.

One of the first steps in any migration is to setup P4 hardware in a data center. See the General Performance Recommendations for information useful in capacity planning for your primary server.

It is also common to allocate two or three identical server machines to P4 to achieve High Availability and Disaster Recovery (HA/DR) goals. A typical configuration has two servers (a primary and a hot spare) in a primary data center, and a third server (warm spare) in another data center located far from the primary data center.

Operating System Selection

Just as with ClearCase, the primary factor in selecting an operating platform for P4 is the platform that IT is most comfortable supporting.

In mixed Windows/Linux environments, Linux platforms are almost invariably selected for ClearCase. This is primarily due to case sensitivity reasons and ClearCase’s reliance on a monodirectional filesystem. VOB data is then accessible to clients on both Linux and Windows.

With P4, only a Transmission Control Protocol (TCP) connection is needed between clients and servers. Further, the case sensitivity behavior of P4 can be configured independently of the platform. Thus, with P4, the server can be configured on Windows or Linux in multi-platform environments.

Registry and License Servers

P4 does not require license or registry server processes or additional hardware. A simple 0.5 KB license file on the P4 server machine drives the license mechanism.

Release Servers and Installation

With ClearCase, it is important to carefully manage server and client versions. Ensuring users run client software that is compatible with the current version of the server is important to ClearCase. To ensure consistency, some ClearCase installations deploy a separate release server. This defined network resource allows users to download correct versions of client software.

With P4, all server and client components install in minutes over the web. More importantly, P4 clients and the server have a very loose forward and backward compatibility relationship. Users can generally run client versions that are older or newer than the server. Client programs simply hide or disable those features that require newer versions of the server, and new server versions rarely require client upgrades.

P4 supports a centrally configured, automatically deployed client for large Windows sites. Such sites can be used to ensure that users download consistent, trusted versions of software that are supported by IT and/or release engineers. The ease of installation and enhanced compatibility makes maintaining clients less of an administrative priority than in ClearCase environments.

View Servers, Protecting Unversioned and Checked Out Files

P4 stores all metadata in databases located on the central server4. There is no equivalent of a ClearCase view server process. Because of this, there is no need for administrators to allocate and configure view server machines in P4. Users also do not need to start or stop view server processes.

When dynamic views are used, view server machines contain the contents of checked-out and unversioned private files. Some organizations back up view storage areas regularly to protect against loss. If protecting checked-out and unversioned files is a priority, you will need to address this when migrating to P4. In P4, unversioned and checked-out files are not available to the server, and are not backed up.

Some organizations devise infrastructure to help protect unversioned and checked-out workspace files in P4. They might require users to store workspaces on network drives that are backed up. More often, you can addresses these processes and users during training, and encourage them to avoid keeping files checked out for too long.

ClearCase Multisite vs. Perforce Federated Architecture

If your ClearCase environment relies on Multisite, Perforce Federated Architecture provides flexible and superior support for remote development.

P4 proxy servers are both simple and effective. P4 proxies cache the contents of versioned files at remote sites, greatly reducing the dependency on WAN networks. Proxies do not cache any metadata. This ensures one single source truth and eliminates the need for specialized and administration-intensive concepts like branch mastership, scheduling batch replication, etc. Once hardware is available, P4 proxy servers can be setup in minutes and require virtually no maintenance.

P4 replicas are more capable than proxy servers and have a small administrative footprint. One popular replica configuration could provide read-only access to all data (file content and metadata). This improves performance for remote teams and automated processes like CI/CD. Build performance is enhanced because all read-only data is serviced locally. Data consistency is still maintained because there is still one canonical representation of important data on the central server.

Replicated VOB servers generally run on server machines equivalent to the primary server. It requires the support from a similar tiered data center. Due to the significant investment in licenses, hardware, and administrative overhead, Multisite installations are used only in cases where major development centers exist. There are rarely implemented where many small teams are spread out.

By contrast, P4 proxy servers are lightweight programs that can run on desktop-grade hardware, even in enterprise environments. Proxy servers are so lightweight in terms of hardware resource demands that they can be deployed anywhere that even a few developers gather. In some cases, individual users deploy a P4 proxy instance in small office without IT support. P4 replicas require more powerful hardware than a proxy server, but have a small administrative footprint. They can be useful for small or medium sized teams, as well as larger sites. There is no additional cost or license issues to deal with when deploying a P4 proxy or replica servers.

Replacing ClearCase Views with Perforce Workspaces

The term workspace is familiar to both ClearCase and P4 users. In both systems, it refers to what developers use to manage files under version control on their local machines.

With ClearCase, it is typical for a developer to maintain several workspaces, or views. Developers working on multiple branches typically use a different view for each activity. They work in one view at a time. For example, a developer might maintain a liz_user_main_dev view with a config spec selecting /main/LATEST versions, and a separate liz_user_rel_2.3 view selecting /main/REL2.3/LATEST5 versions.

A Perforce client spec – a form controlling the definition of a workspace – determines the subset of P4 files visible in a workspace. To users, branches in P4 display as fully populated directory trees. There will typically be a directory on the server named MAIN, and another directory named for a specific release. For example, REL2.3. A developer might have a liz_user_dev workspace, which could include both MAIN and REL2.3 directories. Liz could easily work in both activities at the same time.

In P4, only user files are stored on the local disk. All metadata – including information about the name and contents of a user’s workspace – is maintained on the P4 server. If your teams are using Perforce Streams, they have the capability to specify which modules are actively in use in a branch and import dependencies from other projects.

Rethink Label Strategies

Both ClearCase and P4 provide labels, which can be used to identify the versions of files that constitute a baseline. For many ClearCase users, the use of labels is mandatory. But applying labels can be time-consuming. This task could account for 30% or more of the time associated with official builds.

In P4, labels are just one way of reproducing baselines. Labels certainly do the job of identifying a baseline, but other approaches are available. You can accomplish the same thing without the taxing build process. Alternatives to labeling take advantage of Perforce change-lists. Each Perforce check-in generates a unique changelist number that reflects the state of the entire repository at a point in time. Any given changelist, even though it affects only a small subset of the files, can be used to describe the state of every file in the depot.

Branches in P4 are represented as directories, making it easy to use a combination of branches and changelist numbers to represent a baseline. Alternately, labels can reference changelist numbers limited to an identified scope in P4, where the scope is typically the directory representing a particular branch.

Unified Change Management (UCM)

UCM adds a layer of process to base ClearCase. We strongly recommend reviewing our Streams Adoption Guide.

Perforce Streams provides a flexible workflow and guidance for release management. When used in conjunction with other ALM tools, like Perforce ALM, it can replace ClearCase UCM.

Migration Technical Details

Perforce is not ClearCase. ClearCase and P4 think very differently. They have very different internal representations and modeling of parallel development, branching, and merging. The net result to the user is that both provide good model of what you need to do to achieve parallel development – but one should be aware of the differences.

Evil Twins

An “evil twin” is a scenario where two elements with the same name appear in different branches. For example, say you have a MAIN, DEV_A and DEV_B branches, with each of the DEV branches parented directly from MAIN. In DEV_A branch, a developer runs ct mkelem to create a new file element, foo.c. Independently in DEV_B branch, a developer runs the same command to create a new file element, foo.c. Then another developer runs ct findmerge to make files that originated on DEV_A appear on MAIN. Later, someone does another ct find-merge intending to merge changes from MAIN to DEV_B, including the new foo.c merged to MAIN earlier from DEV_A.

Which is the real “foo.c” in DEV_B? The one that originated in DEV_A, or the one that originated in DEV_B? To ClearCase, it is unclear. One is identified as the correct file, and the other is dubbed the evil twin. Although one would expect them to be branch-relations of the same element, in ClearCase they are not related. They are identified as completely independent elements, referenced in its database by different OID (object identifiers).

If the findmerge command completes successfully, you would have two foo.cs in the MAIN branch. But only one foo.c would display in the directory. It is not obvious to users which file is being referenced. ClearCase doesn’t provide any sort of warning. Situations are even worse when there turn out to be “evil twin” directory elements.

“Evil twin” directory elements are one of the more insidious complexities of ClearCase. ClearCase admins that are aware of this potentially confusing scenario sometimes put in “evil twin detection” and “evil twin prevention” triggers.

From the perspective of migrating data from ClearCase, this “evil twin” history is murky and not something to bring forward into P4. The process for dealing with evil twins in P4 is to detect instances of them, manually select the “correct” element from the pair, and use ct rmelem to eliminate the evil twin.

In P4, it is possible for a similar scenario to occur. A file with the same name could be created independently in two branches. However, unlike in ClearCase, P4 detects and encourages you to resolve the situation the first time they are merged together. The histories of the two files can be combined in P4, and their revision histories united. You are not required to kill off an evil twin. Therefore you do not lose any history. Instead you can simply unite the trees.

Symlinks on Windows

Using Multi-Version File System (MVFS) with ClearCase enables support for symlinks on Windows in dynamic views. P4 has no equivalent of a custom filesystem, and does not support symlinks on non-supported platforms. Symlinks are supported on Windows Vista, Windows 7, and Windows Server 2008, but not on earlier versions of Windows. If there is a reliance on using symlinks on earlier versions of Windows, this must be accounted for during migration planning.

P4 does allow symlinks to be versioned. When a file of type ‘symlink’ is brought into a P4 workspace on a Windows machine without symlink support, it displays as a text file. The contents are the target path of the symlink. For example, say in a Linux workspace you did ‘ln–s hello.hpp hello.h’. The file hello.h would be a symlink pointing to hellol.hpp.

In P4, if you sync the hello.h symlink to a Windows workspace without symlink support, you get a file with the contents being “hello.hpp”, the path to the target of the symlink. You would not get the content of the pointed-to file, as would occur in a ClearCase snapshot view.

File Type Mappings and Limitations

When migrating from ClearCase to Perforce P4, the ‘typemap’, which defines file types based on P4 pathname heuristics, will help ensure that files are added with the correct file type mapping. This is especially important for Unicode files.

ClearCase allows versioning of some file special filesystem objects, such as block special devices, character special devices and hard links. These have no equivalent in P4. If such objects are versioned in ClearCase, you will need to account for that in your migration planning.

Conclusion