[p4] Baseless merging - the answer to a migration to Perforce question?

[Rick Macdonald]

This question is about creating a branch relationship during or after an 
SCCS to P4 migration.

We've had Perforce for at least 10 years, and we'll be adding a pile of 
SCCS code to it due to a company merger.

The code in SCCS is simply one long trunk (only 2-digit revision 
numbers; little or no 4 digit branch revisions such as 1.2.1.4), but a 
couple of years ago they made a copy (not an SCCS branch) of all the 
SCCS files. Each of these codelines has since evolved with their own 
development. Some changes have been done manually to both codelines. 
SCCS itself knows nothing about the copy branch, but the SCCS history 
and revision numbers of everything up to the copy point would be 
identical. The SCCS revision numbers in the two copies are clearly 
separate. The copy had its revision numbers all bumped up to 4500.1, 
whereas the original trunk is not higher than 4200.x.

My question is, how to get the branch relationship into Perforce? If I 
call the original SCCS trunk "main" and the copy "dev", we need it to 
end up like this:

main _______________________________________
                                                      \________________  dev

Going forward, we'd want to be able to integrate back and forth between 
main and dev, eventually retiring dev with one last integration to main.

I'm wondering if there is some trick to be done to the SCCS files, or 
the rcs/cvs conversion of them. Or, perhaps something can be done during 
cvs2p4. I'm thinking not, but I don't know rcs/cvs.

In my subject, I made a guess of letting baseless merging handle it 
after the two codelines are simply migrated independently to Perforce. 
In 10 years, I've never dealt with baseless merging, so I can't quite 
get my head around it. We don't need Perforce to  duplicate the exact 
integration history between the two codelines over the last two years. I 
think we can get by with using Jobs to annotate certain changelists 
where bugs were fixed or new development added to either codeline. But 
as I mentioned, going forward, we'd like Perforce to be helpful with 
integrating between main and dev (probably in both directions) just like 
one would expect with a normal parent-child relationship created in 
Perforce by branching.

Actually, integrating between the two codelines in Perforce implies 
cherry-picking new changes to come (because we aren't ready to resolve 
all the changes yet). I can't imagine what the first integration between 
the two would look like. It would be a cherry-picked changelist from the 
head of one codeline to the other, but what would resolve make of that?

Otherwise, what other ideas should I be looking at?

Rick