Change 1407
=== 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.
- 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.