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

Rick Macdonald rickmacd at shaw.ca
Fri Mar 14 16:02:34 PDT 2008


Gabor Maghera wrote:
> 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).

Yes, I'm using the revmaps already to extract all the exact revisions to 
create P4 labels (and later branches for some of these labels) for 
several old historical release points.

> 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.  :-)

I pride myself in being lazy, so I figure this will be a series of 
scripts with little manual work in between (for the issues that I've 
confessed publicly, that is ;-). Between my last post and this one I 
wrote a little script (in case I go this way) to build a map of 
changelist numbers to descriptions. I'd just need a script to wade 
through the changes file and process one at a time.

The hard decision is yet to come: perfmerge or RevML?

Thank-you for your help and interest.

> Happy Friday,
> Gabor
>
> On Fri, Mar 14, 2008 at 2:45 PM, Rick Macdonald <rickmacd at shaw.ca 
> <mailto: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>
>     > <mailto: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>>
>     >     > <mailto: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>
>     >     >     <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