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

[Gabor Maghera]

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.

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)

Hope this helps,
Gabor




On Fri, Mar 14, 2008 at 8:09 AM, Rick Macdonald <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>> 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>), 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
> >
> >
> >
> >     _______________________________________________
> >     perforce-user mailing list  -  perforce-user at perforce.com
> >     <mailto:perforce-user at perforce.com>
> >     http://maillist.perforce.com/mailman/listinfo/perforce-user
> >
> >
>
>