[Top][All Lists]

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

Re: Problems using CVS transparently

From: Rob Helmer
Subject: Re: Problems using CVS transparently
Date: Wed, 3 Apr 2002 15:56:37 -0800
User-agent: Mutt/1.2.5i

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.

> ==-----==
> 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

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 :)

> ==-----==
> 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.

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.

Rob Helmer

reply via email to

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