p4_filesat.good #2

  • //
  • guest/
  • richard_geiger/
  • utils/
  • cvs2p4_meta/
  • test/
  • p4_filesat.good
  • View
  • Commits
  • Open Download .zip Download (270 B)
//depot/Test/larry/file#1 - branch change 3 (ktext)
//depot/Test/main/dollar$file#2 - edit change 26 (ktext)
//depot/Test/main/file#2 - edit change 2 (ktext)
//depot/Test/main/space file#2 - edit change 26 (ktext)
//depot/Test/import/datefile#2 - edit change 30 (ktext)
# Change User Description Committed
#2 1744 Richard Geiger Changes for 2.0b6:

- handle Attic files correctly - this required a change from the old
  version (and required touching genmetadata), since we now use the
  old RCS archive tree in place (or a copy thereof).

- dolabels now closes the labels journal file explicitly. Previously,
  the subsequent "p4d -jr" could see premature eof to due buffered
  data, and the last bunch of labels in the dblbls file would not
  be converted.

- fix a bug that broke conversion of files that had been deleted and
  then re-added in CVS; upon re-adding the file, it would be given
  revision #1 agian, instead of the next unused revision number.

- added a couple of test cases for these.

Many thanks to Fan Zhang of Numeritech for helping to wring out
these problems!
#1 1636 Richard Geiger Branch for working on a direct-metadata generation verison of cvs2p4
//guest/richard_geiger/utils/cvs2p4/test/p4_filesat.good
#2 1407 Richard Geiger === Release 1.3.2

- Reduce the memory footprint of bin/genmetadata. Previously, it was
  holding and sorting a complete copy of the metadata file "in-core"
  (as well as a copy of all of the RCS revision tags data!). This adds
  up quick, and some users saw genmetadata gobbling memory voraciously
  (and in some cases being running out, causing thrashing and/or process
  termination by the OS).

  genmetadata now keeps the metadata in a temp file, (sorting it in
  primary-key-sized chunks), and the revision tag information in a
  db-backed hash.

- Fix the label handling so that _all_ perforce revisions based on the
  labeled cvs revision are included in the generated
  labels. Previously, one of the N "correct" Perforce revisions were
  being tagged (effectively, at random). This stems from the fact that
  lazy copying and branching are explicit in Perforce, but implicit in
  CVS. I.e., the "#1" revision in a new Perforce branch _appears_ to
  be a separate entity (identical to the revision from which it was
  branched. This means that to use the converted labels, it will be up
  to _you_ to remember what labels go with what branches: but that's
  the way it is in CVS, too.

- A minor change in revmap to have a meaningful usage message, and
  properly handle the new rrevmap format.

- dochanges correctly deletes revmap database files for either
  *.db or *.pag/*.dat style databases.
#1 1185 Richard Geiger Changes for 1.3
(Labels!)