[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