A PVCS Version Manager migration must preserve the meaning of file revisions, labels and release selections as well as the files themselves. Start with an inventory and a verified recoverable copy, then prove a small export against the source before converting an entire repository.
The MERANT name places many installations in a long product history. Current product information is available through the OpenText PVCS community. Exact commands and archive behavior depend on the installed Version Manager release. This guide provides an assessment method and a repository migration record, not a universal export command.
Establish what the installation contains
Record the product version, server/client components, archive locations, project hierarchy and tools used for normal access. Inventory users, permissions, locks, branches, promotion groups, version labels and build scripts that select revisions. Include binaries and files stored outside the main project when a release depends on them.
Consult documentation for that installed version. For example, the Version Manager 8.1.4 user guide describes version labels and revision selection in that release. Treat it as version-specific historical documentation, and reconcile it with your installation before automating anything.
Have the repository administrator create a recoverable copy using the installation's supported backup procedure. Verify a restore in an isolated environment and demonstrate reading selected revisions there. Record the source snapshot time and any writes allowed afterward. A migration trial needs a stable reference to make comparisons meaningful.
Map a release at the file level
A release label can select different revision numbers in different files. A Git commit, by comparison, represents a repository snapshot. Make the mapping explicit before deciding how to construct destination history.
Consider this fictional release selection:
| Source path | PVCS revision selected by RELEASE-1 |
Destination evidence |
|---|---|---|
src/main.c |
1.7 |
Exported bytes and checksum |
src/config.c |
1.3 |
Exported bytes and checksum |
assets/logo.bin |
1.2 |
Binary size and checksum |
These revision numbers belong to individual files. They do not imply three repository-wide releases. Record which label rules apply, what happens when a file lacks that label, and how deleted or renamed paths are represented. Reproduce the actual build selection rather than guessing from the newest revision of every file.
Choose the history you need to retain
Three common project choices are a selected release snapshot, selected release milestones, or a fuller historical conversion. Evaluate them against the work people need to do afterward: rebuild a shipped version, trace a defect, inspect authorship or understand a branch.
For each choice, list what becomes available in the destination and what remains in a preserved source system. Agree on retention, access and ownership. If the destination is Git, decide how authors, timestamps, branches and labels map into Git objects. Multiple file revisions may need grouping rules to form a meaningful commit; mark inferred groupings as inferred in the conversion record.
The official Git fast-import documentation describes an input stream for creating Git history. A separate conversion frontend must obtain and translate source data. Choosing fast-import leaves the PVCS extraction and semantic mapping work to that frontend.
Prove a small export
Use the installed version's supported read/export tools against the restored test copy. Start with a representative subset: text, binary, multiple revisions, a label, a branch and a renamed or deleted path if those occur in the real repository. Record exact tool versions and commands privately with their outputs.
Decide byte policies before comparing checksums. Keyword expansion and line-ending conversion can intentionally change exported text. Record raw archive content, normal checkout content and any normalized destination content as distinct representations where applicable. Compare like with like. For binaries, require exact byte equality unless an explicitly approved transformation is part of the plan.
An acceptance record should connect each source selection to its exported path, size, checksum, metadata and destination revision. Rebuild one known release from the destination and compare its behavior or agreed artifacts. A successful import process is one piece of evidence; a reproducible release exercises the mapping that developers actually need.
Cut over with reconciliation
Schedule a controlled final source snapshot or a documented incremental procedure. Reconcile any changes since the trial and rerun the selection checks. Give developers the new location, access instructions and a short exercise to retrieve and build an accepted release.
Keep the source recoverable under the agreed retention policy. Record how to return to the prior workflow if acceptance fails and who makes that decision. Remove dependence on old build paths only after the destination workflow has been demonstrated.
The downloaded record is intended to travel with the migration: it captures scope, backup verification, mapping decisions and acceptance evidence. No PVCS repository was converted for this guide. For the broader ownership and handover questions around a software system, use the custom software project brief.