[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.
Regards,
Sonam
--
Electronic Commerce
Corporate Express Australia Ltd.
Phone: +61-2-9335-0725, Fax: +61-2-9335-0753
- Problems using CVS transparently, Sonam Chauhan, 2002/04/03
- Re: Problems using CVS transparently, Pierre Asselin, 2002/04/03
- Re: Problems using CVS transparently,
Sonam Chauhan <=
- RE: Problems using CVS transparently, Yuval Rotem, 2002/04/04
- Re: Problems using CVS transparently, Eric Siegerman, 2002/04/04
- Re: Re: Problems using CVS transparently, Kaz Kylheku, 2002/04/04
- Re: Problems using CVS transparently, Sonam Chauhan, 2002/04/04
- Re: Re: Problems using CVS transparently, Joi Ellis, 2002/04/05
- Re: Re: Re: Problems using CVS transparently, Kaz Kylheku, 2002/04/05
- Re: Re: Re: Problems using CVS transparently, Eric Siegerman, 2002/04/05
Re: Problems using CVS transparently, Pierre Asselin, 2002/04/04