Yes, which is basically a pass through to RCS level commands.
My understanding is that CVS ("Concurrent Versions" System) wasn't designed
in the model of "checkout the sourceand lock it" ( like SCCS does).
CVS has a model of usingthe "edit" command which indicates to other developers that you
You need to create a workspace where you check out CVSROOT,
there you can edit the administration file and check it back in.
mkdir work; cd work
cvs co CVSROOT
When you check it in, cvs will rebuild it's administration database to
activate you change on the server.
Teala
-Original
find /path/to/repository -type f | grep -i fooglitz.c
:-)
-teala
-Original Message-
From: [EMAIL PROTECTED] [mailto:blained;mindspring.com]
Sent: Thursday, October 31, 2002 9:12 AM
To: [EMAIL PROTECTED]
Subject: Can I check out a file without specifying the module it's in?
Actually,
Have you done a cvs add of the file first?
Looks like you are trying to commit a new file without running the add
first.
Cheers,
Teala
-Original Message-
From: Sven Sandberg [mailto:[EMAIL PROTECTED]]
Sent: Saturday, May 18, 2002 4:41 PM
To: [EMAIL PROTECTED]
Subject: cvs commit:
As long as you cvs add commit the new file from within a work tree
pulled
from the branch, (i.e. cvs co -r BRANCHNAME or cvs up -r BRANCHAME),
then
CVS will know to add that new file specifically to the branch.
The new file will get placed into the Attic and only exist on the branch
-
Are you sure your CVSROOT variable was pointing to the test
repository when you checked out CVSROOT commited the taginfo file?
If taginfo did not change in your test repository, then it sure sounds
like it got commited to some other repository...
Cheers,
Teala
-Original Message-
Personally I don't use the import command to bring new source into
our repository. I have a simple recursive shell script that walks down
a directory structure adding directories and then checking to see
if files are non-text and then either adds them with -kb or not, and
commits them. Works
Susan,
If you did an import to bring the files into the repository initially,
it will
create a 1.1.1.1 version
I don't think it is a bug.
There are graphical tools: tkcvs will display graphical renditions of
file versioning,
see: http://www.twobarleycorns.net/tkcvs/tkcvs-log.gif
Cheers,
Do the Entries file in the CVS subdirectories look correct?
(for any directories in the sandbox with affected files)
ie. could the Entries files have been corrupted somehow?
If the Entries files are missing entries for the files in question
then that is why WinCVS is displaying ?. If this is
Thanks for your reply David,
- we are using pserver access
- the checkout proceeded through about 1/3 of the files in the module,
the hang happened after pulling over (successfully) a 15Mb file, and
(presumably) during pulling over the next file in that directory (6Mb).
- The checkout was
Thanks for your help Lee,
The CVS_CLIENT_LOG looks good - I'll have to get it set up for when we
are having the network problems and see the hangs again.
What I realized from your inquiry about specifying the port number in
the CVSROOT variable is that it doesn't work for versions 1.10.x
I use rtag command on a nightly basis to tag the top of our tree,
and then pull from that tag to do our nightly builds.
I've never seen any instance where all files in the module were not
tagged
(i.e. this would result in a build failure for us if it did...), and
the rtag command used in this
Oh, that sounds nasty - is it a case issue with using WinCVS?
I can't imagine you would get case issues on a Unix client
We get directory issues with lower case getting converted to
all caps frequently while using WinCVS back to a Linux server.
I sure hope all the log fixes syntax changes
Recently we had a cvs co command 'hang' and we are trying to debug what
happened. The server side (RH 6.2 running CVS 10.7) show no processes
running, but the solaris side (Solaris 8, running CVS 1.11) still shows
the cvs co in process.So somehow the server side closed the connect,
but the
You can definitely use rtag to tag a branch:
cvs rtag -r $BRANCH $TAG $MODULE
Cheers,
Teala
-Original Message-
From: Dan Walter [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 04, 2002 4:23 PM
To: [EMAIL PROTECTED]
Subject: can rtag on an existing branch?
I created a branch with rtag
Terry,
You seem to have some fundamentals about cvs a little blurred.
What you are trying to do is fairly complex - your email is an
interesting jigsaw puzzle.
I don't know about your issue with cvs co -d, but fundamentally what you
are trying to do by making a 'directory' in the source tree
What about the parent directories above cvsroot/CVSROOT ?
you don't show the ls listing for those as Larry mentioned.
If they likewise are owned by cvs:techops and aren't 777, you still
won't be able to write your history file into CVSROOT as user
idw:idwgroup
Also, I have found that creating
you need to explictly checkout the CVSROOT directory either locally on
the server or on a client system by doing:
cvs co /yourpathtorepository/CVSROOT
cd /yourpathtorepository/CVSROOT
vi modules
add your new modules with
-Original Message-
From: Teala Spitzbarth
Sent: Thursday, January 10, 2002 11:32 AM
To: 'Whitlock, Ginger'; [EMAIL PROTECTED]
Subject: RE: Why does 'cvs admin -lbranchname'
complain that my branch is absent?
Oh, yuck.
I know from other email that Larry has sent me that
the way CVS
There was a similar thread about Build Processes (Release Engineering)
in CVS back in August, started by Bil Joga. My reply outlines our
tagging and branching model:
http://mail.gnu.org/pipermail/info-cvs/2001-August/018972.html
If you look around that date you will see a few other replies.
This topic is a frequently discussed one on the alias.
There have been examples of commitinfo scripts posted on the alias
which enable you to restrict access to branches. The one I use
is based on lock-branch.sh posted by Shubhabrata Sengupta, see:
-Original Message-
From: Teala Spitzbarth
Sent: Thursday, January 10, 2002 11:32 AM
To: 'Whitlock, Ginger'; [EMAIL PROTECTED]
Subject: RE: Why does 'cvs admin -lbranchname' complain that my branch
is absent?
Oh, yuck.
I know from other email that Larry has sent me that the way
Oh, yuck.
I know from other email that Larry has sent me that the way CVS handles
branches can be problematic in some commands - i.e. CVS doesn't actually
create a branched version of each file when the branch is created (that
is why you
see the magic zero in that fake branch revision
The most straightforward way is to use the rdiff command
cvs rdiff -s -r green -r rel-1-1 MODULENAME
This gives you a listing of all files that changed between the two tags,
and the beginning and ending revisions for those files.
If you want log information (i.e. commit comments for
Jeanie,
You said in your email yesterday that *you* created the
Release_Aug21_2001 tag.
The only way *you* can have a working copy of the tree
listing sticky tags of Release_Aug21_2001 is if *you*
either 1) did a fresh cvs co -r Release_Aug21_2001 module-name
to create your tree or 2) did an
Yes, the sticky tags just mean that the tree you were working in
was pulled (or the one you used to create) the Release_Aug21_2001 tag,
they
haven't been put on every file in any different way than
when you tagged the tree before you left. Developers that have been
working in sandboxes pulled
Robert,
I don't have any answers, but I can
say that I have seen similar behavior.
For awhile I was using an aliased module
that excluded certain directories -
but found that our developers (using pserver
connections), would land up getting the
excluded directories when they attempted
to
I think the critical question is
what kind of IS support you get on that solaris
system at the university, and how will your laptop/home
system access the university systems?
I.e. are you going to get permission to set up
a pserver port for cvs on the solaris system (requires
root access)?
you're not in a 'working copy'
cvs has no knowledge of the directory structure
or where to import it into the repository.
-teala
-Original Message-
From: Marius Flage [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 10, 2001 9:13 AM
To: [EMAIL PROTECTED]
Subject: Newbie indeed
Hi
and very
good platform availability for both server and client pieces. If you
need more than CVS offers right now, I would be sure to evaluate
Perforce along with ClearCase.
Good Luck,
Teala Spitzbarth
___
Info-cvs mailing list
[EMAIL PROTECTED]
http
of the form x.x.0.x next to a Branch
tag
in the log output makes it seem at first glance that more files were
modified
on the branch than really were
Thanks much
Teala Spitzbarth
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman
So I take it no one out there has ever tried to emulate SCCS 'floor'
model
within CVS?
Thanks
Teala
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Teala Spitzbarth
Sent: Wednesday, February 14, 2001 12:42 PM
To: [EMAIL PROTECTED]
Subject: Issues
to enforce the raised revision on new files to
write a script to be run by commitinfo ?
Thanks much,
Teala Spitzbarth
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Saima!
Tried to reply direct but don't think it went through...
I've done alot of straight edits (mv's and rm's) on our cvs repository and
haven't had any problems - but this is what I know will happen.
1) Don't do it if you have tags!! (you'll loose the ability to replicate old
builds)
2)
Hi Folks,
Is there anyway to disable the automatic merge on checkin under CVS?
I.e. to force that if a developer tries to checkin a file from a working
copy that is outdated - they get an error message?
I can see that if you admin files with the -m option, it will be disabled,
but this requires
look here, and you'll see an online link to
it...
CVS Manual: Version Management with CVS, by Per Cederqvist et al
http://www.cvshome.org/docs/index.html
-teala
-Original Message-
From: Matthew Berney [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 11, 2000 4:25 PM
To: 'CVS
36 matches
Mail list logo
