[p4] Migrating SCCS to Perforce (again, still)

Rick Macdonald rickmacd at shaw.ca
Wed Mar 12 14:23:42 PDT 2008


Jeff A. Bowles wrote:

Hi Jeff! Nice to hear from you.

> Good luck with that beast. Where did you come across an SCCS archive?

A year++ we were bought out by a nearly equal-sized competitor. While 
both companies were large and international, we've had distributed 
development for ever (using Perforce for the last 10 years or more) 
whereas they have all their source in one office in France. Their 
procedures never grew beyond the script-wrapped SCCS system they set up 
long ago. The newly merged company has embraced distributed development 
as we have always had in our old company.

> First, I would point out that exact duplicates of filenames (the full 
> //depot/boring/path/name.c part) in two inputs to the 'merge 
> checkpoints' process will befuddle perfmerge. Don't know about RevML.

Because the SCCS import is from a completely separate software package, 
there is no chance of duplicates. The final depot will have //foo and 
//bar. In the future, code will likely get integrated from one to the 
other, but there is no overlap to start.

We haven't used Jobs in our Perforce database, so it's empty. No problem 
there. I do plan to use them in an important way in the future.

My remark about staying with 2005.2 is because of this comment in cvs2p4:

--- snip ---
==== PERFORCE METADATA DEPENDENCIES

Since cvs2p4 works by directly generating Perforce metadata in the
perforce checkpoint/journal format, it is dependent on "knowing" the
right definitions for certain tables within the Perforce database.

As of this writing, cvs2p4 writes metadata for the following Perforce
tables, at the version number shown for each table:

  table name    ver
  ------------  ---
  db.change     0
  db.desc       0
  db.rev        3
  db.revcx      0
  db.integed    0
  db.depot      0
  db.domain     2
  db.counters   0

The tests provided with this package are known to work correctly using
any Perforce server from version 2001.1 to 2005.2. It should work
correctly with any new p4d version that can still read (and upgrade
from) 2002.2 metadata.
--- snip ---

perfmerge needs the two depots to be at the same version.  RevML is 
tempting because (I think) it just plays back p4 command-line executions 
on a live server. Much slower, but seems a lot simpler and less risky, 
and it may not have any dependency on the depot versions.

> Second, I would run a couple of experiments in timings, before 
> deciding to do the merges while on Perforce release 2005.2.  The 
> db.archive overhead is fairly heavy, and if you're planning to upgrade 
> to the more recent releases anyhow, it might make sense to do this as 
> a parallel timeline:
>     1, "at the same time, upgrade versions on production machines and 
> begin testing-of-import processes on a backup machine.  Then, you'll 
> have a bit more speed *now* and a reason to make a fully-functional 
> backup machine that can be used for testing of new stuff."
>     2. "Test the import processes -- finding duplicates, dealing with 
> label issues, etc -- on the backup/testing machine 'til you're 
> satisfied with it. You can always restart the import/backup machine's 
> database so that you have near-unlimited number of attempts to get it 
> wrong, refining as you have time.  If you need to retitle one server's 
> set of jobs, or filenames, or whatever, make a call to Tech Support 
> before EVER attempting check-point surgery. (The law of unintended 
> consequences seeks out such situations with glee.)"
>     3.  "Then, one last anal-retentive time, do the upgrade on the 
> testing/backup server to record the times for 
> checkpoint/upgrade/checkpoint for your email announcement to your users."
>     4. "Then do it."
>
> (Please forgive the really fussy list, above!)
>
> Third, I agree that having the information to make labels or transfer 
> labels (or, at least, exhume / excavate them from the old records) is 
> a really good thing. But it'll take a lot of experimentation in your 
> 'testbed' system to make it reliable.
>
> Good luck with that beast. Where did you come across an SCCS archive?
>
>     -Jeff Bowles
>
>
> On Mar 12, 2008, at 10:08 AM, Rick Macdonald wrote:
>
>> I started looking at this last year but it got delayed until now.
>>
>> Currently, I'm looking at:
>>
>> - SCCS to RCS using Eric Raymond's sccs2rcs python version 1.5. It
>> seemed the newest I could find?
>>
>> - RCS to P4 using Richard Geiger's cvs2p4 from July 24, 2006. It seemed
>> the newest I could find?
>>
>> - There seems to be 2 options to merge the P4 depot above with our
>> existing server: RevML and perfmerge++ from Perforce. I haven't looked
>> at these much yet. Advice?
>>
>> - our existing server is still at version 2005.2. I'm thinking I'd do
>> this migration and depot merge at 2005.2 and then update the server to
>> 2007.x afterwards. Some of the scripts are old and there could be
>> issues, especially with cvs2p4. Is this a good plan?
>>
>> Release branches or labels: I've come up with the following. Have I
>> missed some better method?
>>
>> Ultimately, we need to label and/or branch several releases from the
>> SCCS files. Creating labels and then branching seems the way to go at
>> this point. cvs2p4 maintains the original SCCS revisions, as seen in the
>> journal and checkpoint:
>>
>> @pv@ 0 @db.archive@ @//depot/IMPORT/RCS/fanmo.F@ @4101.1@
>> @//Test/1/fanmo.F@ 14 32
>> @pv@ 0 @db.archive@ @//depot/IMPORT/RCS/fanmo.F@ @4100.1@
>> @//Test/1/fanmo.F@ 13 32
>> @pv@ 0 @db.archive@ @//depot/IMPORT/RCS/fanmo.F@ @3111.1@
>> @//Test/1/fanmo.F@ 12 32
>> @pv@ 0 @db.archive@ @//depot/IMPORT/RCS/fanmo.F@ @3100.1@
>> @//Test/1/fanmo.F@ 11 32
>>
>> The numbers "4101.1" are the SCCS revisions, and "14", "13" etc are the
>> corresponding P4 revisions. The SCCS revisions are not visible anywhere
>> that I can find in the P4 depot created, but cvs2p4 has a "revmap" that
>> produces this list:
>>
>> /home/rickm/GCTSCCS/RCS/fanmo.F/3100.1 //Test/1/fanmo.F#11
>> /home/rickm/GCTSCCS/RCS/fanmo.F/3111.1 //Test/1/fanmo.F#12
>> /home/rickm/GCTSCCS/RCS/fanmo.F/4100.1 //Test/1/fanmo.F#13
>> /home/rickm/GCTSCCS/RCS/fanmo.F/4101.1 //Test/1/fanmo.F#14
>>
>> I could write a trivial script to extract the depot file/revision names
>> at historical points that I need (eg 4100 would be file
>> /Test/1/fanmo.F#13) into filelist files and feed these into "p4 -x
>> filelist tag -l labelname".
>>
>> I would do this on the cvs2p4-created depot before merging with our
>> existing depot. I assume the labels will still be valid after the depot
>> merge? I think I could create branches from these labels before or after
>> the merge, so I'd probably do it after.
>>
>> Comments? Any red flags, things I haven't mentioned or asked that I
>> should have?
>>
>> Regards,
>> 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