Re: Discover the revision of a file that is not checked out?

[Todd Denniston]

Peter Loron wrote, On 11/02/2007 01:05 PM:
> We have our source files in CVS. We have a staging environment that is
> currently not managed via CVS. The files there are copied over, not
> checked out. Also the set of files that are there are not necessarily
> the head revision of each file.
>
> We want to switch over to managing the files there via CVS, but cannot
> simply do a 'cvs checkout' at the root module to get everything.

even having a (version controlled) script to do multiple 'cvs checkout's would 
be easier to trace from, so any start is probably better than what you got.

> Can somebody point me to a tool/script that can help us automatically
> discover what revision of what file is there? 
>
> We have notes on what revisions have been copied to the staging
> environment, 

In a text, excel file or something that will dump to those I hope. :)

> but it would be a seriously long project to go back through
> them to build up a revision catalog that could be used to check out the
> proper revisions.
>
> My current thought is to write a script to recurse through the tree, and
> then for each file, diffing the local one against each revision in CVS
> to find a match. Ick.

I suspect you will have to go with your current thought on the script, but you 
should be able to make a couple of optimizations.
You have two facts or conjectured facts that you probably know about each file:
1) The revision that is in the notes about the copies to the staging area.
2) The date on the file in the file-system where the staging area is.
This date has a few posibilities depending on OS and options used while 
copying the files:
        a) Microsoft, the new file will have the same
        date as the source file.
        b) Unix,
                i] the date will be of the system time
                when the file was copied.
                ii] the date will be the same on the new
                and source file.(cp -p)
We also know CVS sets the date on Checkouts to be the same as the last 
check-in, and CVS sets the date on updates to the system time when the update 
is done.
So the date in the staging area will be the same or later than the date of 
CVS's commit of that revision of the file.

I would start by testing the revision they have in the notes[1], and then look 
at the date on the file and work backward from there (might grab one revision 
newer first though). I would expect that unless you have an appropriately 
paranoid Configuration Manager you may find a few files which match no 
revisions _exactly_ considering the staging area was not already directly 
using CVS, i.e., there will probably be a subset files you will have to do a 
human visual diff of this subset(been there done that).

[1] And I hope for your Configuration Manager's sake that this finds a 99+% 
match of the set.

--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter
http://www.crane.navy.mil/custfeedback