Re: Problems using CVS transparently

[Sonam Chauhan]

Thanks Rob:

Rob Helmer wrote:

On Thu, Apr 04, 2002 at 02:21:23AM +1000, Sonam Chauhan wrote:

Hi there - I need to make CVS work transparently with a proprietary development 
environment lacking source control. I've hit the problems below.
Can you help?

==-----==
PROBLEM #1: CVS usage must be transparent. This means no 'CVS' meta-directories 
are allowed in the development(working-set) file hierarchy since the proprietary 
development environment modifies this hierarchy directly. How can I do this?


Why do you need to do this? I'm sure you can find a workaround of some
form, but it will be that much more difficult to support, being so different
from the "official" CVS distribution.


The proprietary IDE (something called 'webMethods B2B'), though lacking version 
control, has a inbuilt release mechanism. It zips up release directories in the 
working set. These ZIP files are then distributed to other servers. Hence we end 
up with CVS directories in 'live' servers. This takes us far far away from 
'support land' and also may cause complications with the software's  internal 
functioning.

You're right though about the workaround being complicated. I've already hit 
problems using 'cvs add'...
-----------------------------------------
address@hidden Package]$ cvs add code
? code/classes
? code/jars
? code/source
cvs server: cannot mkdir /opt/cvsroot.../code: No such file or directory
-----------------------------------------



==-----==
PROBLEM #2: How to add large numbers of files and directories to an existing cvs 
module.


I would use the find and xargs commands :

find ./ -type f | grep -v '/CVS/' | xargs cvs add



I did try this but hit the bug(?) described above.

Some CVS doco I came across states "hard links are only supported within a 
directory". So things look bleak.


If you don't have CVS meta-data dirs like you described, then
you could drop the "| grep -v '/CVS/'" part I suppose, although I still
think running with no meta-data dirs is a bad idea [:)]

Unfortunately, I have to [:)]

Basically I need CVS only for versioning capabilities. Before a major release, 
I'd like to do something like this (params are wrong - I have no idea)
  "cvs -tag -recurse -tag_name "Release Number 9" <souce-controlled-dir>

I could then use CVS to restore the directory or even specific file to previous 
release checkpoints.



==-----==
PROBLEM #3: How can I detect and commit changes to the development codebase when 
making a release? As described in problem #2, new directories may be added or 
deleted arbitrarily by the development environment.


I think you would have to write a script to handle this, if you did
a "cvs -n update" then you would see all files not in CVS listed
as "?" and "M" for any locally modified.
You could use this output to make a simple script to add any new files
and commit all changes. Removing files might be a little tricker, but
I think the "cvs -n update" output would help you there too. Just make
sure you update first.


This script would have to cvs add directories, sub-directory by sub-directory I 
guess.



Maybe you should explain more about what exactly it is you are doing;
it seems as though you may want to seperate this file generation process
from the revision control process some more.


I think this is just proving too hard -- especially with the hard linking issue 
 and CVS' lack of support for linking.

I think I'll try another approach - manually snapshotting a release's zip files 
built by the IDE's release process.(I know where these files are on disk) That 
is more manegeable (manually 'cvs add'-ing 3-5 zip files instead of hundreds of 
smaller files)  and gives me versioning where none existed before  (the IDE has 
no idea that multiple ZIP files are part of the same release).

Maybe there is a better way:

The installation of a release involves only the unzipping of the ZIP files on 
the remote servers. Maybe a release script could also unzip these ZIPs in a CVS 
controlled directory. What do you think?

Of course, with this approach there no versioning (and hence no checkpointing) 
between point releases, but its better than nothing.

Regards,
Sonam
--
Electronic Commerce
Corporate Express Australia Ltd.
Phone: +61-2-9335-0725, Fax: +61-2-9335-0753