Recently I was told, I have to migrate our Perforce repository to TrueChange (McCabe TrueChange). I had not heard of TrueChange up until that point. I have used cvs, subversion, vss and perforce so far. I am trying to find any words of wisdom in making that transition and what to expect from TrueChange. I loved working with Perforce and I found the transition to it fairly simple.
Can you help me out? I am using VS2005, RAD and CruiseControl.
I have been using TRUEchange since September 1999 and I think you are fortunate that you have been told you have to migrate from Perforce to TRUEchange.
I have worked with a number of open source, home-grown and commercial CM software systems and by far and away, TRUEchange is the best product I have ever used.
Four things that make TRUEchange so good (there are more than four - these are four key ones):
Change set based instead of file diff based. If 50 files are checked out as a group, modified and then checked back in, changes to those 50 files are a single unit called a change set. TRUEchange handles concurrent parallel baselines better than any CM software I have ever used. Csets can be migrated to a lower numbered baseline or migrated to a higher numbered baseline. Migration/merge conflicts are rare and there is a built-in 3-way merge tool in the clients that allows the user to deal with conflicts with extreme ease. Change sets can be removed from a particular version (in any order) and could be added back in. If there have been 5 changes to a file in 5 different change sets, the 2nd change can be removed while leaving changes 1, 3, 4 and 5 intact. It also keeps full meta-data to support moving of files from one directory to another, rename of files or rename of directories. Files can be removed and there is a change set that removes the file. Since the change set that removes the file maintains what the file's file id, file name and parent directory were, files can be restored at any time without having to load them into the system again. The change history is restored when the file is restored.
Project version based instead of file version based. When a version is checkpointed (similar to tagging) the contents of all files in the entire project are recorded as a unit. Instead of having to keep track of the individual version numbers for 5000 files you would only have to keep track of the checkpoints for the projects that contain those files. Maintaining history of what has been built for QA or deployment is "dead simple" since file versions don't have to be tracked. TRUEchange uses build configurations to group related projects together and the file paths where the files were extracted to for the build process - on Unix/Linux, Windows or VMS file systems. We use a three segment version number such as 2.1.0. The first build (or iteration) for a version would be 2.1.0.1. The second would be 2.1.0.2 and so on. When we run a build and it completes, we take the details of the build configuration and insert the data into two database tables. One table contains the build configuration level information such as build configuration name, major version number, minor version number, sub version number, iteration, descriptive title, build type (either QA or Production) and date and time completed. The other table contains a foreign key pointing to the build configuration level row in the first table and contains the project name, major version number, minor version number, sub version number and iteration from the checkpoint used to run the build. With the build configuration level information and the project level information, we can query the database and immediately know the exact content of any build run. We currently have history for builds since September 2001 - almost 33,500 builds and over 228,000 child records. In a matter of a minute or two I could recreate the source directory structure for any build run in the last 8 years and know it to be absolutely accurate and identical to the build run originally. If I had to do that with a file version based CM system it would take quite a long time to recreate any given build.
Command line commands, Windows GUI, Java GUI client (StreamCM), customizability and reliability. TRUEchange has a multitude of command line commands allowing a high level of automation. Using shell scripts and PHP we have been able to develop fully automated build cycles and customized web interfaces for developers to interact with the CM system. Development builds run as the configuration management user with retrieval of files from TRUEchange are run from a web page. This guarantees that code checked in by the engineers will build when it is run by CM. StreamCM runs on a variety of platforms - Unix (Solaris, AIX, HP-UX, Irix, etc.), Linux (Red Hat, Fedora, Gentoo, etc.), Windows (XP, Vista) and on MacOS (PPC and Intel). This unified interface allows developers to use multiple platforms and have the client act the same regardless of OS. TRUEchange can be highly customized using their scripting language. We have customized TRUEchange to interact with our CM database running under PostgreSQL so web based applications can read meta data out of a database rather than querying the CM system. We have also customized TRUEchange to interact with our problem tracking system in Mercury Interactive Test Director via a connection to the Oracle database. It is highly reliable. In almost 10 years, we have had one failure of a repository that required going back to a backup - due to a disk error. And since TRUEchange maintains the transactions that are posted against each repository, we were able to replay the transactions that modified the repository in the exact order they were originally applied. It was a lightly used repository but it took only 10 minutes to replay all of the transactions from a period of three days. We have over 200 user licenses and we have never had more than two CM engineers to support the user base. In 2008, the other CM engineer and I performed over 6300 QA builds and created over 1800 deployment images for production deployment. Compared to any other CM system I have ever used, TRUEchange requires a lot less administration - by a huge margin. The other plus is McCabe's willingness to enhance the product based on their customer's needs. We have asked for numerous enhancements over the years and they have delivered on just about every request and exceeded our expectations. The other great thing about TRUEchange is it is designed to run in a distributed environment. A license manager controls access to the system and tracks which servers the repositories are actually running on. We have a license server and four Linux servers that run 97 repositories. If we needed to add servers to house additional repositories, it would merely be a matter of bring those servers up, creating the repositories (or moving existing ones to the new server), recreating the start and stop scripts (through an automated process) and starting the repositories on the new server. No client intervention is required. And we manage almost 52 million lines of source code plus binary files (such as gif files, jpeg files, etc.).
CruiseControl Plugin. With the latest release of software, McCabe developed a CruiseControl plugin that allows TRUEchange integration. We have not used CruiseControl at this point because our software is extremely complex with many interdependencies. This is not a shortcoming of TRUEchange but rather a shortcoming in CruiseControl. It seems to be best suited to standalone systems that don't heavily depend on other systems.
In order to easily migrate from another CM product to TRUEchange itt is merely grasping the concept of project oriented versus file oriented and then setting up the repositories to meet the security requirements (who can access what and at what level) and logical projects organization of the software systems. If the repositories and projects are setup correctly, it is merely a matter of pulling the files out of the old CM system and bulk loading them into the TRUEchange projects.