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

Rick Macdonald rickmacd at shaw.ca
Fri Mar 14 08:09:50 PDT 2008

Gabor Maghera wrote:
> There may be a way to do it without having to rely on baseless merging 
> for going forward once migration to p4 is completed.  Import the trunk 
> only via cvs2p4.  Once you get it into Perforce, spawn a branch from 
> it.  Check the entire branch out for edit, delete all of its files 
> from your workspace (to handle deletes performed on the branch).  
> Perform a p4 add on any files which were added to the SCCS branch.  
> Submit.  This will give you the ancestral relationship between the 
> branch and its donor at the cost of losing SCCS revision history on 
> your branch.

It occurs to me that we could do the above, but instead of one 
checkout/submit, we could repeat it for every revision of every file. I 
think I could extract the changelist grouping from a dry run of cvs2p4 
and do this with the same sets of files. The results would be exactly 
what we want, but the dates would be wrong. Brutal and slow, but an idea 
to consider. I think we could do this on the output of cvs2p4, and then 
merge the entire result with our production server (using RevML of 

This should work, right?

> You could probably get similar results without revision history loss 
> but it gets a bit more complicated.  Import the trunk only via cvs2p4, 
> and branch right away.  Import the branch with cvs2p4 but not as a 
> branch, rather a trunk for a new module (you can do this with 
> cvs2p4).  Now, perform a baseless merge from this place into the 
> branch you created after the first import.  The revision history on 
> the p4 branch will include full revision history, but the branch point 
> will be off, and the revision history from SCCS will show as having 
> taken place on the trunk of the module which resulted from the second 
> cvs2p4 import.
> If you were to go with the latter option, you'll probably have to use 
> perfmerge++ to merge the results of the two runs of cvs2p4.  I don't 
> think it's possible to do the import in one step, because of the 
> desired change from branch to trunk and massaging it into a new 
> module, when converting the SCCS branch.

I don't understand this one yet. Have to think about it some more.


> Cheers,
> Gabor
> On Thu, Mar 13, 2008 at 4:00 PM, Rick Macdonald <rickmacd at shaw.ca 
> <mailto:rickmacd at shaw.ca>> wrote:
>     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
>     <>), 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
>     _______________________________________________
>     perforce-user mailing list  -  perforce-user at perforce.com
>     <mailto:perforce-user at perforce.com>
>     http://maillist.perforce.com/mailman/listinfo/perforce-user

More information about the perforce-user mailing list