Re: Do we have an alternative to tag, to record status of cvs repo

[Paul Sander]

>--- Forwarded mail from 
>monnier+gmane.comp.version-control.cvs.general/news/@rum.cs.yale.edu

>> I was wondering whether we have a whatfile kind of tool which was used in
>> RCS(version no. of each file stored in a whatfile, which is used to check
>> out the entire code base later). I tried to create a similar kind of tool
>> using the CVS commands. I am able to create the info file by traversing
>> through the Entries files in my local copy. But a check out using this file
>> is taking around 4 hours, as I am issuing a check out command for each
>> file separately.

>How about using the Entries file directly and blindly ?
>Something like:

>    cp CVS/Entries .../whatfile

>you can then retrieve the corresponding code by doing something like:

>    mkdir -p foo/CVS
>    cd foo
>    echo $CVSROOT >CVS/Root
>    echo $PROJECTNAME >CVS/Repository
>    cp .../whatfile CVS/Entries
>    cvs update

>Ah, no that won't work because update will try and get new things on
>the branch. How about you take an existing workspace and do

>    cp .../whatfiles CVS/Entries
>    cvs update -C -r BASE

>which should even save you from downloading files which haven't changed.
>But CVS handles very poorly the "-r BASE" kind of tricks, so it won't
>do quite what you want.

I was able to accomplish this successfully by reading the Entries and
Repository files to build a manifest file that mapped RCS files to
working files.  A separate tool read the manifest, invoked RCS directly
to copy out the files, and built the CVS meta-data directly.  Once
done, the new workspace was identical to the original, and CVS operated
on it normally.

I then checked in and tagged the manifest for reproducibility.  The
overhead of the method was much less than using CVS exclusively; the
checkout portion ran about 3 times faster, and building the manifest was
an order of magnitude faster than tagging.  The difference in speed
increased with the age of the project, and it was more immune to problems
when people accidentally (or perhaps not accidentally) moved or removed
tags from specific versions.

Checking in and tagging the manifest was done with CVS, but my checkout
used RCS directly.  Bypassing the CVS directory-level locking protocol
is safe under these conditions, because the versions are known in advance
and are immutable.  The RCS file update algorithm and the filesystem
together avoid problems with lost data in the event that my checkout runs
concurrently with a commit.

>--- End of forwarded message from 
>monnier+gmane.comp.version-control.cvs.general/news/@rum.cs.yale.edu