Solutions
VM: How to copy or move a Version Manager Project Database (PDB) to another location
| ID: | S121539 | |
| Published: | ||
| Updated: | 21 June 2022 |
Operating System(s)
- All Unix
- All Windows
Product(s)
- PVCS Version Manager
Description
Somtimes, an existing project database has to be moved to a different location from where it was originally created. This could include moving the data to a different server.
Resolution
There are different ways of doing this, all with their own advantages and disadvantages.
For project databases accessed through the VM File Server available as of VM 8.0.x
Any of the options listed below for project databases accessed through the file system can be used, but may not be necessary if the repository is accessed through a PVCS VM File Server and the goal is to move the data to another machine.
The VM File Server is designed to make project databases more portable for the administrator. The "Client Name" in a Path Map definition that is specified through the File Server Admin utility resolves to the physical location, or "Project DB Path", using a string substitution. Because of this, the entire project database metadata and revision library can be copied/moved to another location without modifications (using file system copy), and the result is transparent to the end users.
The only requirements are for the "Client Name" entries to remain identical, and for the corresponding "Project DB Path" and "Revision Path" directories to be updated so they point to the new locations, if those locations were changed. If the "Project DB Path" and "Revision Path" directories will not change (e.g. the data is local to the server and was copied to the same directories, or data is on a network drive and the UNC path does not change), use the section Preserving File Server Settings from KB doc S138232 to copy all Path Maps entries to the new machine.
There are virtually no downsides to using the PVCS VM File Server data migration method. Only if Client Name happens contains the name of the old server might users be confused as the Client Name cannot be changed, so the old server name would continue to show up in project databases (archive paths, CFG file paths, etc.) even though the named machine may no longer exist. Version Manager itself has no problems with these virtualized names, but if it causes too much confusion for your users, you could perform a one-time copy to a Path Map Client Name that does not contain any server reference, like \\vmfs or \\pvcs, using methods 2, 3, or 4 documented below.
Detailed information on using the PVCS VM File Server can be found in KB doc S126695.
The only requirements are for the "Client Name" entries to remain identical, and for the corresponding "Project DB Path" and "Revision Path" directories to be updated so they point to the new locations, if those locations were changed. If the "Project DB Path" and "Revision Path" directories will not change (e.g. the data is local to the server and was copied to the same directories, or data is on a network drive and the UNC path does not change), use the section Preserving File Server Settings from KB doc S138232 to copy all Path Maps entries to the new machine.
There are virtually no downsides to using the PVCS VM File Server data migration method. Only if Client Name happens contains the name of the old server might users be confused as the Client Name cannot be changed, so the old server name would continue to show up in project databases (archive paths, CFG file paths, etc.) even though the named machine may no longer exist. Version Manager itself has no problems with these virtualized names, but if it causes too much confusion for your users, you could perform a one-time copy to a Path Map Client Name that does not contain any server reference, like \\vmfs or \\pvcs, using methods 2, 3, or 4 documented below.
Detailed information on using the PVCS VM File Server can be found in KB doc S126695.
For project databases accessed through the file system and not using the VM File Server:
-
Restoring from a full backup
This method works specifically if the project database is going to be in the exact same location on the new server that it was on the old server.
NOTE: If the original path includes the server name, the new server should be renamed to match the original server. If this is not possible, see options 2 and 3 for making changes to the path. -
Using the VM GUI Edit | Copy feature
If you choose to copy a project database into a new location, you can use Edit| Copy. VM will create a new project database in the specified location.
Note: As of VM 8.1.2, the Copy feature is significantly improved and included copying shared file relationships as well as Workspaces. Using VM 8.1.2 or later, the Copy feature is a viable and much easier to use alternative to the ExportPDB / ImportPDB route listed below, providing you can access both the source and destination location.
-
Using PCLI ExportPDB / ImportPDB commands
A very useful feature in PCLI (Project Command-Line Interface - see PCLI User's Guide and Reference) is the possibility to export a project database and import it into a new location.
-
Importing the archive directory structure
This method is only valid if your project database's archive structure exactly reflects the project database view you have in the GUI.
The methods above are described in full detail in the attached WORD document. It is suggested that you study them all and then decide on whichever suits you the most.
Migration ID
KB39987
