//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 | |
|---|---|---|---|---|---|
| #1 | 1769 | Doug Quist | Grab a copy of the wip in-case I want/need to tweak something during testing | ||
| //guest/richard_geiger/utils/cvs2p4_meta/test/p4_filesat.good | |||||
| #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!) |
||