从一种源代码控制工具过渡到另一种源代码控制工具。 请给建议？
最近我被告知，我必须将我们的 Perforce 存储库迁移到 TrueChange (McCabe TrueChange)。 在那之前我还没有听说过 TrueChange。 到目前为止我已经使用过cvs、subversion、vss 和perforce。 我试图找到任何关于实现这一转变的智慧之言以及对 TrueChange 的期望。 我喜欢使用 Perforce，并且发现向它的过渡相当简单。
你能帮我吗？ 我正在使用 VS2005、RAD 和 CruiseControl。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我自 1999 年 9 月以来一直在使用 TRUEchange，我认为您很幸运，因为您被告知必须从 Perforce 迁移到 TRUEchange。
我曾使用过许多开源、本土和商业 CM 软件系统，到目前为止，TRUEchange 是我使用过的最好的产品。
TRUEchange 如此出色的四个因素（不止四个 - 这是四个关键因素）：
基于更改集而不是基于文件差异。 如果将 50 个文件作为一组检出、修改然后重新检入，则对这 50 个文件的更改将成为一个单元，称为更改集。 TRUEchange 比我用过的任何 CM 软件都能更好地处理并发并行基线。 Cset 可以迁移到编号较低的基线或迁移到编号较高的基线。 迁移/合并冲突很少见，客户端内置了三向合并工具，可以让用户极其轻松地处理冲突。 更改集可以从特定版本中删除（以任何顺序），也可以重新添加。如果在 5 个不同的更改集中对文件进行了 5 处更改，则可以删除第二个更改，同时保留更改 1、3、4和5个完好无损。 它还保留完整的元数据以支持将文件从一个目录移动到另一个目录、重命名文件或重命名目录。 可以删除文件，并且有一个更改集可以删除该文件。 由于删除文件的更改集保留了文件的文件 ID、文件名和父目录，因此可以随时恢复文件，而无需再次将其加载到系统中。 恢复文件时，更改历史记录也会恢复。
基于项目版本而不是基于文件版本。 当版本被设置检查点（类似于标记）时，整个项目中所有文件的内容将被记录为一个单元。 您不必跟踪 5000 个文件的各个版本号，而只需跟踪包含这些文件的项目的检查点。 维护为 QA 或部署构建的历史记录“非常简单”，因为不必跟踪文件版本。 TRUEchange 使用构建配置将相关项目分组在一起，并使用在构建过程中提取文件的文件路径 - 在 Unix/Linux、Windows 或 VMS 文件系统上。 我们使用三段版本号，例如 2.1.0。 版本的第一个构建（或迭代）将为 2.1.0.1。 第二个是 2.1.0.2，依此类推。 当我们运行构建并完成时，我们获取构建配置的详细信息并将数据插入到两个数据库表中。 一张表包含构建配置级别信息，例如构建配置名称、主要版本号、次要版本号、子版本号、迭代、描述性标题、构建类型（QA 或生产）以及完成的日期和时间。 另一个表包含指向第一个表中的构建配置级别行的外键，并包含项目名称、主版本号、次版本号、子版本号以及用于运行构建的检查点的迭代。 有了构建配置级别信息和项目级别信息，我们可以查询数据库并立即知道任何构建运行的确切内容。 目前，我们拥有自 2001 年 9 月以来的构建历史记录 - 近 33,500 个构建和超过 228,000 个子记录。 只需一两分钟，我就可以为过去 8 年中的任何构建运行重新创建源目录结构，并且知道它绝对准确且与最初的构建运行相同。 如果我必须使用基于文件版本的 CM 系统来执行此操作，则需要相当长的时间来重新创建任何给定的构建。
命令行命令、Windows GUI、Java GUI 客户端 (StreamCM)、可定制性和可靠性。 TRUEchange 具有大量命令行命令，可实现高度自动化。 使用 shell 脚本和 PHP，我们已经能够开发完全自动化的构建周期和定制的 Web 界面，以便开发人员与 CM 系统进行交互。 开发构建作为配置管理用户运行，并从网页运行 TRUEchange 检索文件。 这保证了工程师签入的代码在 CM 运行时能够构建。 StreamCM 可在多种平台上运行 - Unix（Solaris、AIX、HP-UX、Irix 等）、Linux（Red Hat、Fedora、Gentoo 等）、Windows（XP、Vista）和 MacOS（PPC 和 Intel） ）。 这种统一的接口允许开发人员使用多个平台，并且无论操作系统如何，客户端的行为都是相同的。 TRUEchange 可以使用其脚本语言进行高度定制。 我们定制了 TRUEchange 来与在 PostgreSQL 下运行的 CM 数据库进行交互，因此基于 Web 的应用程序可以从数据库中读取元数据，而不是查询 CM 系统。 我们还定制了 TRUEchange，通过与 Oracle 数据库的连接与 Mercury Interactive Test Director 中的问题跟踪系统进行交互。 它的可靠性很高。 近 10 年来，我们曾遇到过一次由于磁盘错误而需要返回备份的存储库故障。 由于 TRUEchange 维护针对每个存储库发布的事务，因此我们能够按照最初应用的确切顺序重放修改存储库的事务。 这是一个很少使用的存储库，但只需 10 分钟即可重放三天内的所有事务。 我们拥有超过 200 个用户许可证，并且从来没有超过两名 CM 工程师来支持用户群。 2008 年，我和另一位 CM 工程师执行了 6300 多个 QA 构建，并为生产部署创建了 1800 多个部署映像。 与我曾经使用过的任何其他 CM 系统相比，TRUEchange 需要的管理工作要少得多 - 大幅减少。 另一个优点是 McCabe 愿意根据客户的需求增强产品。 多年来，我们要求进行多次改进，他们几乎满足了每一项要求，并且超出了我们的预期。 TRUEchange 的另一个优点是它设计为在分布式环境中运行。 许可证管理器控制对系统的访问并跟踪存储库实际运行在哪些服务器上。 我们有一个许可证服务器和四个运行 97 个存储库的 Linux 服务器。 如果我们需要添加服务器来容纳额外的存储库，那么只需启动这些服务器，创建存储库（或将现有的存储库移动到新服务器），重新创建启动和停止脚本（通过自动化过程）并在新服务器上启动存储库。 无需客户干预。 我们管理着近 5200 万行源代码以及二进制文件（例如 gif 文件、jpeg 文件等）。
CruiseControl 插件。 通过最新版本的软件，McCabe 开发了一个 CruiseControl 插件，允许 TRUEchange 集成。 我们目前还没有使用 CruiseControl，因为我们的软件非常复杂，具有许多相互依赖性。 这不是 TRUEchange 的缺点，而是 CruiseControl 的缺点。 它似乎最适合不严重依赖其他系统的独立系统。
为了轻松地从另一个 CM 产品迁移到 TRUEchange itt 只需掌握面向项目与面向文件的概念，然后设置存储库以满足安全要求（谁可以访问什么以及在什么级别）和逻辑项目组织软件系统。 如果存储库和项目设置正确，只需将文件从旧的 CM 系统中拉出并将它们批量加载到 TRUEchange 项目中即可。
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.