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

Gabor Maghera gmaghera at gmail.com
Fri Mar 14 15:18:50 PDT 2008


It's good to know that cvs2p4 does the grouping for you.  Thanks for sharing
that information.

As to where to branch from Trunk-A, you're correct - doing from somewhere in
the middle would get you closer to what you had in SCCS.  If you can
identify the branch point in SCCS, that should be a breeze.  You can use
cvs2p4's ancillary script to create a map of RCS revision to p4 changes, to
aid you in doing so (see section 3 in the README).

Using the second proposed option, if you were to look at the revision
history of a file on your new branch, information will be a bit obscured.
The changes which took place on your SCCS branch will show as having been
done on Trunk-B in Perforce, then integrated in one swoop into the branch.
I think you're better off doing it the way you propose, by integrating your
SCCS changelist groupings one at a time (employing the first option).  I do
admire your willingness to do that work.  :-)

Happy Friday,
Gabor

On Fri, Mar 14, 2008 at 2:45 PM, Rick Macdonald <rickmacd at shaw.ca> wrote:

> 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
> /home/rickm/GCTSCCS/RCS/src/modules/vespa/xp/vespa.F/711.4 956071067
> cggsourc Exp trunk  - 711.3 -
> # 8
> /home/rickm/GCTSCCS/RCS/src/modules/vespa/xp/vespa.F/711.5 957536375
> cggsourc Exp trunk  - 711.4 -
> # 9
> /home/rickm/GCTSCCS/RCS/src/modules/seginpm1/xp/seginpm1.F/711.5 957536787
> cggsourc Exp trunk  - 710.1 -
> # 10
> /home/rickm/GCTSCCS/RCS/src/modules/wunetpm1/xp/wunetpm1.F/711.5 960547942
> cggsourc Exp trunk  - 710.1 -
> # 11
> /home/rickm/GCTSCCS/RCS/src/modules/fanmo/xp/fanmo.F/711.7 962373191
> cggsourc Exp trunk  - 710.1 -
> /home/rickm/GCTSCCS/RCS/src/modules/fbcor/xp/fbcor.F/711.7 962373194
> cggsourc Exp trunk  - 711.4 -
> /home/rickm/GCTSCCS/RCS/src/modules/runet/xp/runet.F/711.7 962373912
> cggsourc Exp trunk  - 710.1 -
> /home/rickm/GCTSCCS/RCS/src/modules/vespa/xp/vespa.F/711.7 962374103
> cggsourc Exp trunk  - 711.5 -
> # 12
> /home/rickm/GCTSCCS/RCS/src/modules/runetpm1/xp/runetpm1.F/711.7 962377452
> cggsourc Exp trunk  - 710.1 -
> /home/rickm/GCTSCCS/RCS/src/modules/seginpm1/xp/seginpm1.F/711.7 962377491
> cggsourc Exp trunk  - 711.5 -
> /home/rickm/GCTSCCS/RCS/src/modules/wunetpm1/xp/wunetpm1.F/711.7 962377769
> cggsourc Exp trunk  - 711.5 -
>
> >
> > 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
> >     1.2.1.4 <http://1.2.1.4>
> >     >     <http://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
> >
>



More information about the perforce-user mailing list