PVCS -> Vault Migration Compatible?

[rbuehler]

I have been given the task of migrating Gigs of repositories from PVCS to SourceGear Vault. Looking around this wonderful forum of information I found THIS post in which Jeff Clausis outlined my possible solutions.

From what I can tell, you have a couple of different options:
1) Store the latest version of the files in Vault, and keep PVCS / Merant archived somewhere in case it is needed for historical purposes. - Easiest

2) Perhaps someone has done a port of their own, and would kindly assist you with the knowledge / tools they gained during their port. - Moderately Easy to Moderately Hard (based on the good will of the other party)

3) If there is an interface ( command line or otherwise ), you could write your own port - Moderately Hard and above.

Option number 3 is my decision (or at least my goal).

Unfortunately, I don't think the two SCMs are compatible for a migration without some major design decisions and possible loss of information.

Problems:
PVCS branches-in-place
All version information is stored file-by-file
No linking of files by changeset

Let me explain what I mean by branch in place. When exploring the file/folder structure of the repository no branching evidence is visible. Branches are visible only in the revision viewer. Getting a branch is the same as getting any non-tip revision, simply supply the revision number of the branch version. To support this branch style PVCS enforces a unique revision incrementation style. It versions the trunk as 1.0, 1.1, 1.2, 1.3 ... 1.N (I haven't found how to jump to 2.0 yet.) Now I branch at Revision 1.3 and I get a new version available for checkout called 1.3.1.0 with subsequent version of 1.3.1.1, 1.3.1.2 ... 1.3.1.N and if I branch 1.3 again I get 1.3.2.0, 1.3.2.1, 1.3.2.2 ... 1.3.2.N Using recursive logic I can branch the first branch at its second revision and get 1.3.1.2.1.0

The lack of linking files in the same changeset poses the issue that PVCS doesn't know which file branches go together as a single new branch. I can only guess based on checkin times and comments. Each files revision increments at its own pace and so revisions can't be used to match changesets.

I've read how Eric describes a reposity as 3-D <folder,file,revision> well, I think I would use that same language to describe a PVCS repository as 4-D <folder,file,branch,revision>. The version history is a tree rather than a list.




Can Vault accurately represent this without too much trouble?
OR
Do you have any suggestions for how I project this 4-D space into 3-D?
OR
Did I make myself perfectly unclear?

[rbuehler]

By PVCS I mean Serena ChangeMan Version Manager.
Sorry for any confusion.

[dan]

Being unfamiliar with PVCS, we probably can't help much on how to extract the information you need from it.

However, on the Vault side, imports of branches will work if you are able to catch the right version in Vault that it should be branched from. For instance, if a 1.3 branch in PVCS corresponds to a particular version in Vault, you can branch Vault at that version, (and even call in 1.3.1), and then continue adding transactions to the branch that happen after that.

Not sure how much help this is, but I guess I just want to point out Vault's support for Branch, and that if you import items in the right order, using branch could be viable.

[rbuehler]

I was really hoping you would say that Vault can branch without adding files or folders to the view of the repository. Without that feature it is impossible to exactly represent PVCS in a Vault repository.

To illustrate, here is an example of all the information that PVCS can give me about revisions and branches:

Code: Select all

===============
/p1/src/main.cpp
 1.0
 1.1
 1.2
   1.2.1.0
   1.2.1.1
 1.3

===============
/p1/src/main.h
 1.0
 1.1
   1.1.1.0
 1.2

As is my understanding, Vault cannot branch in place. Thus I need to come up with a location to place the branch and a way to translate the logs from pvcs. The above information could be translated multiple ways.
The trunk is always
$/p1/src/main.cpp with versions 1.0, 1.1, 1.2, 1.3
$/p1/src/main/h with versions 1.0, 1.1, 1.2
But the branches could be
/src was branched and both main.cpp and main.h were revised in that branch
$/p1/branches/1/src/main.cpp with versions 1.0, 1.2, 1.2.1.0, 1.2.1.1
$/p1/branches/1/src/main.h with versions 1.0, 1.1, 1.1.1.0
OR
/src was branched and main.cpp was revised followed by another branch off of /src and this time only main.h was revised
$/p1/branches/1/src/main.cpp with versions 1.0, 1.2, 1.2.1.0, 1.2.1.1
$/p1/branches/1/src/main.h with versions 1.0, 1.1, 1.2
$/p1/branches/2/src/main.cpp with versions 1.0, 1.2, 1.3
$/p1/branches/2/src/main.h with versions 1.0, 1.1, 1.1.1.0
OR
/src was branched and main.cpp was revised. Then /branches/1/src was branched and main.h was revised
$/p1/branches/1/src/main.cpp with versions 1.0, 1.2, 1.2.1.0, 1.2.1.1
$/p1/branches/1/src/main.h with versions 1.0, 1.1, 1.2
$/p1/branches/2/src/main.cpp with versions 1.0, 1.2, 1.2.1.0, 1.2.1.1
$/p1/branches/2/src/main.h with versions 1.0, 1.1, 1.1.1.0
OR
other combinations

Make sense? It took me quite a while to figure it all out.

So, there are no real questions in this post, but if I made any mistakes please let me know.

One last note, please do not confuse this with a feature request. I would not like to see this implemented in any SCM. The branch to a new location mechanism provides much greater control, organization, and view.

Thanks for fast response. This forum is the most impressive support I have ever seen from a software company.

Sincerely,
-Bob

[dan]

I guess I am at a loss as to how to interpret the PCVS branching

If you want all the branches to be visible, you might just create explicit folders for each branch that was created in PVCS, and import the history completely. That would be safe, but might also cause the tree to be cominbinatorially large if you have lots and lots of branches.

Sorry I can't be of more help...

[wvendrig]

Hi
I was wondering if the transition from merant to sourcegear in the end was successful?
We are investigating the possibility as well
tnx
Wilco