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

Gabor Maghera gmaghera at gmail.com
Thu Mar 13 20:43:55 PDT 2008


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.

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.

Cheers,
Gabor

On Thu, Mar 13, 2008 at 4:00 PM, Rick Macdonald <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), 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
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>



More information about the perforce-user mailing list