RE: The recursive behavior of CVS

Actually, there are TWO -d options, one to the left and one to the right of your checkout command. The one on the left sets the CVS root. The one on the right points out to CVS where the work area is. It seems, from a little experimentation, that CVS needs to find A root, and will take it from

Re: User variable problem

There's a shell setting that makes it complain when you use an undefined value. (But I don't recall what it is). If you are using ksh, you can use ${parameter:-word} to substitute word in place of parameter if parameter isn't defined. DEFAULT /serv/CVSROOT/commitcheck ${COMMITCODE:-JUNK} Then,

Re: restricting concurrent editing

can any body tell me how to restrict users editing the same file at a time That's against the philosophy behind CVS. CVS was designed to explicitly _allow_ people from editing a file at the same time. In case of no Not quite. CVS is designed to make concurrent editing feasable. That doesn't

fetching multiple tags

I found this question interesting, since I'm about to address it in a CVS wrapper I'm writing... Marc Tessier wrote: I am wandering if there is any options to extract the most recent version of a list of TAG? I have tag A, B, C and the I want to get the most recent files of all three in one

Re: Multiple tags

But as Larry said to the original poster: No. You're expected to tag all the files in a module, not just some of them. Indeed. In CVS, tags are meant to label the state of the module No. That is untrue. Otherwise you wouldn't be able to place a tag on a single file or checkout a single

cvs checkout -N -d xxx

This works flawlessly: $ mkdir WorkArea1 $ cd WorkArea1 $ cvs checkout file1 file2 mod1/file3 As does this (note the missing -N at the beginning): $ cvs checkout -d WorkArea2 file1 $ cvs checkout -d WorkArea2 -N file2 $ cvs checkout -d WorkArea2 -N mod1/file3 But, the first and third commands of

cvs checkout -d -N (more)

Also, this sequence works too... $ cvs checkout -d WorkArea4 -N mod1/file3 $ cvs checkout -d WorkArea4 -N file1 $ cvs checkout -d WorkArea4 file2 Work Area State: File: Module/file: new -d-d (-N) old -d (-N) -d -N Here are each of the cases laid out

starting with an empty repository

Maybe it's me and not cvs 1.11.2 ... I think the following command sequence should work... $ mkdir workarea $ cd workarea $ cvs checkout -l . $ touch file0 $ mkdir module $ touch module/file2 $ cvs add module/file2 ... I am looking for a command sequence to get file2 into CVS without first

starting with an empty repository (more)

I made some progress... $ cvs checkout -l . $ touch file0 $ mkdir module $ cvs add module $ touch module/file2 $ cvs add module/file2 The module itself needs to be added to then get the file in. Further, if I don't want ALL of the files in the repository root, (caused by the initial check out),

Re: Security, audits and pserver

um, I'm a newbie at CVS, so I've read more of the documentation than anything else, but the answers I've seen so far for the security question seem to have missed one vital point. People have write access to spots in the repository, therefore they, just like CVS, can write as they please to the

checkout -r dst -j src fyle

I'm writing a script to merge files from one branch (src) to another (dst). If a file has never been merged between the two, then the command checkout -r dst -j src fyle should checkout the file on the dst branch and then merge the changes from the tip of the src branch into it. If this merge

repeated merges from a branch

I have reached the point where I need to merge from a branch to main a second time with the same file. The documentation I have found dedicates just enough words to say use cvs checkout -j once -j twice file and it's the human's responsibility to guess the right value for once. This strikes me

anomoly merging from one branch to another

I presume that the following commit message is a benign case of version 1.1.1.1 being renamed on output to the user. But I'm a bit more worried about the message from checkout. What I did was to create a new file on a branch (so there is no 1.1 yet), and then I used the branch copy, v1.1.2.1,

update -l -r brnch dir doesn't seem to do anything

I've used CVS for a bit over 24 hours, having used ClearCase for the past 16 years, and I am trying to get a handle on how NOT to get a whole directory dumped into my work area. We have a directory with approximately 1,500 source files in it. (No unfortunat ely, I can't make a smaller

to release or not to release

If I am reading the documentation correctly, I can forgo the release command if I change history logging in config to ignore checkout/release events. All I need to do after that seems to be to use rm -rf * in the work directory. to get the same impact as release. -CTH