[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problems using CVS transparently

From: Sonam Chauhan
Subject: Re: Problems using CVS transparently
Date: Thu, 04 Apr 2002 15:45:51 +1000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120

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.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]