[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