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

Rick Macdonald rickmacd at shaw.ca
Fri Mar 14 14:45:11 PDT 2008

Gabor Maghera wrote:
> What you are proposing should work, Rick, given you're willing to 
> accept the cost, as it will be laborious.  As far as the changelist 
> grouping goes, I am not sure cvs2p4 will do that for you (based on 
> changelists having identical commit logs).  You may have to do that 
> yourself, perhaps through scripting.

After a bit more looking, I think this is easily done if it turns out 
the way to go. cvs2p4 creates a file called "changes" which appears to 
be exactly what I need. The SCCS does have identical commit comments, so 
you can see from the snippet below that cvs2p4 does do some amount of 
grouping such as in changelists 11 and 12. So, I'd just have to trudge 
through it all doing checkout/copy/submit for each changelist (using the 
details of the "working off line recipe", of course). I found the commit 
descriptions in a couple different p4 depot files (checkpoint and 
dbmeta), so I'd have to parse one of those at the same time to get the 
changelist description.

# 7
# 8
# 9
# 10
# 11
# 12

> As for the second option I proposed, here is a visual representation:
> trunk-A (trunk imported from SCCS)
> --------------------------------
>                                 \
>                                  -(branch spawned from trunk with no 
> changes on it - initially)
>                                ^
>                                .  (merge)
>                                .
>                                .
> --------------------------------
> trunk-B (branch imported from SCCS)

Ah, a thousand word picture! When I view it with a fixed font I see the 
branch from Trunk-A and the merge from trunk B are both from the head 
revisions. Wouldn't the branch from trunk-A be done somewhere in the 
middle, from the point at which the 2nd SCCS trunk was created by 
copying the first?

The first several years of history would be duplicated in trunks A and 
B. I'm not sure if that's a problem. I think RevML can omit that 
history, but I haven't started testing RevML yet.

I also don't have a grip on the second idea as far as integration 
history issues helping or hindering future merges. The first option, 
while being much slower, does give me something that I understand 
perfectly well, since the end result is as if all work was done in 
Perforce all along using one simple dev branch off the mainline.

> On Fri, Mar 14, 2008 at 8:09 AM, Rick Macdonald <rickmacd at shaw.ca 
> <mailto:rickmacd at shaw.ca>> wrote:
>     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
>     perfmerge).
>     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.
>     Thanks,
>     Rick
>     >
>     > Cheers,
>     > Gabor
>     >
>     > On Thu, Mar 13, 2008 at 4:00 PM, Rick Macdonald
>     <rickmacd at shaw.ca <mailto:rickmacd at shaw.ca>
>     > <mailto: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

More information about the perforce-user mailing list