# | Change | User | Description | Committed | |
---|---|---|---|---|---|
#3 | 28901 | marc_tooley | "" | ||
#2 | 5757 | marc |
Pulling in latest changes from Mr. Geiger's cvs2p4 Primary |
||
#1 | 5694 | marc_tooley |
Branching for minor little mods to cvs2p4. It turns out the Public Depot is probably a convenient delivery mechanism.. |
||
//guest/richard_geiger/utils/cvs2p4/test/p4_filesat.good | |||||
#10 | 5654 | Richard Geiger | Take care of David Birkhead's first two problem children :-) | ||
#9 | 5597 | Richard Geiger |
Add news USE_IMPORT_DEPOT switch, to allow you to have cvs-import'ed revisions (the "vendor branch") end up in a different depot than locally-authored revisions. This should pretty much complete feature work in 3.0; |
||
#8 | 5531 | Richard Geiger |
A significant checkpoint commit, with new improved handling of import vendor branches, and revisions present in main by virtue of multiple vendor drops to a file with no local mods. test/runtest works, with new refernece results pretty well scrutinized. |
||
#7 | 5467 | Richard Geiger |
checkpoint. Need to update the docs prior to release! |
||
#6 | 5143 | Richard Geiger | prep for 2.5.5 | ||
#5 | 2376 | Richard Geiger | First show at fixing RCS/"import" confusion... | ||
#4 | 1944 | Richard Geiger | Update expected text output files. | ||
#3 | 1781 | Richard Geiger |
This change reintegrates cvs2p4 2.0 developement work (through 2.0b6) back into my mainline development. |
||
#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!) |