Re: affect of large numbers of tags on performance

[Paul Sander]

In addition to tagging, we also built a manifest of the source files,
checked it in, and applied the same tag as was applied to the rest of the
build.  The manifest was stored separately from the source code so that
developers wouldn't muck with its tags.  Our rebuild procedure used that
file to populate a workspace rather than relying on the tagged sources,
in case the developers fudged the tags for any reason after the build
completed.  (We also had a changeset mechanism, and having the manifest
in advance made the integration and reversion computations easier.)

Our manifest included the path of the source file relative to the root
of the workspace, plus the version number.  This worked because we didn't
use the modules database and instead used directory names from the repository
directly.  All of our source code lived in a single repository, also.

To do this today, you'd want to include the contents of the Repository file,
the path (relative to the top of the repository) to the RCS file, the version
number, and the path to the source file (relative to the top of the workspace).

--- Forwarded mail from address@hidden

If you are worried about not being able to get a older build using a tag,
when you delete the tag, stick the file revision, name, folder name, EXACT
date/time of commit etc in a database along with the tag you are deleting in
SQL database. You can get these info from the rlog/log files. In future if
someone says give me "build_xxx" .. Simply do a lookup in the SQL database
for this date, get the EXACT date/time of the commit and just use that as a
'tag'. CVS allows passing the date/time to get a revision. Like CVS co
"2003-10-10 14:00" will give me all the commits I did that are near or
exactly matching October 10th, 2003 2:00 PM ...

--- End of forwarded message from address@hidden