diff does not seem to do -y
I am guessing that the reason for the change is in the "Diff librarification" that was done but I want to know why I can not do a "cvs diff -y" now. with (CVS) 1.9 (client/server) ---as shipped with slackware 3.2 "cvs diff -ybw" would give me the familiar side by side diff I want but with (CVS) 1.10.8 (client/server) --- compiled by me on slack 7.0 with ./configure;make;make install "cvs diff -ybw" only gives diff: invalid option -- y Usage: cvs diff. looking at cvs-1.10.8/diff/diff.c it looks as though the y should be processed if the option ever made it there, but by putting a printf in the y case I know it never does. Is there a way I can make cvs call the external diff, or is there an option I need to through at config time to remind cvs it now has gnu diff hidden in its belly, or maybe if I can find time to do it where to start on a fix, BIG maybe? TIA -- ___ Todd Denniston, Code 6067, NSWC Crane E-Mail: mailto:[EMAIL PROTECTED] The opinions expressed here are not sanctioned by and do not necessarily represent those of my employer.
Re: diff does not seem to do -y
Larry Jones wrote:
Todd Denniston writes:
with (CVS) 1.9 (client/server) ---as shipped with slackware 3.2
"cvs diff -ybw" would give me the familiar side by side diff I want but with
(CVS) 1.10.8 (client/server) --- compiled by me on slack 7.0 with
./configure;make;make install
"cvs diff -ybw" only gives
diff: invalid option -- y
Usage: cvs diff.
looking at cvs-1.10.8/diff/diff.c it looks as though the y should be processed if
the option ever made it there, but by putting a printf in the y case I know it
never does.
The following comment in src/diff.c tells the story:
/* CVS 1.9 and similar versions seemed to have pretty weird handling
of -y and -T. In the cases where it called rcsdiff,
SNIP
mostly to ignore -q. Maybe this should be fixed, but I think it's
a larger issue than the changes included here. */
or maybe if I can find time to do it where to start on a fix, BIG maybe?
I'd start by comparing the options lists in src/diff.c, diff/diff.c, and
the rcsdiff man page. And if you do decide to do it, please change the
diff_usage message (in src/diff.c) to document all of the options rather
than deferring to "rcsdiff-options". (And, although I haven't looked, I
suspect a similar change ought to be made to the Cederqvist manual.)
-Larry Jones
Pitiful. Just pitiful. -- Calvin
Thanks for the pointers, and I love those CH comments especially when they hit the
context :).
- I have not looked at changing Cederqvist, I hate doing documentation but love to
have it. :)
- I have updated the diff_usage message.
note: I looked through and tried to remove any option that did not show up in the
getopt_long call or in longopts[], but I could have missed one.
- from what I remember I think people on the list have suggested changing the
following line
"(The most popular is -c for context diffs but there are many more).\n"
to indicate that to generate patches the -u option was there i.e.
"(The most popular is -c for context diffs and -u for patches).\n"
but as I could not find you or Greg indicating as such I did not change it.
-I have done some local testing of various options and could not find that I had
broken anything so this
should be good.(crosses fingers and grabs the asbestos)
--- diff.c 2000/04/01 00:27:55 1.1
+++ diff.c 2000/04/01 00:39:24
@@ -64,6 +64,7 @@
/* FIXME: should be documenting all the options here. They don't
perfectly match rcsdiff options (for example, we always support
--ifdef and --context, but rcsdiff only does if diff does). */
+/*should this FIXME comment go away now? -- Todd*/
static const char *const diff_usage[] =
{
"Usage: %s %s [-lNR] [rcsdiff-options]\n",
@@ -76,8 +77,67 @@
"\t-r rev1\tDiff revision for rev1 against working file.\n",
"\t-r rev2\tDiff rev1/date1 against rev2.\n",
"\t--ifdef=arg\tOutput diffs in ifdef format.\n",
-"(consult the documentation for your diff program for rcsdiff-options.\n",
-"The most popular is -c for context diffs but there are many more).\n",
+" rcsdiff-options are as follows:\n",
+
+"\t-i --ignore-case Consider upper- and lower-case to be the same.\n",
+"\t-w --ignore-all-space Ignore all white space.\n",
+"\t-b --ignore-space-change Ignore changes in the amount of white space.\n",
+"\t-B --ignore-blank-lines Ignore changes whose lines are all blank.\n",
+"\t-I RE --ignore-matching-lines=RE Ignore changes whose lines all match RE.\n",
+"\t--binary Read and write data in binary mode.\n",/*it is in the longopts
+ i do not know if it
+ works*/
+"\t-a --text Treat all files as text.\n\n",
+"\t-c -C NUM --context[=NUM] Output NUM (default 2) lines of copied context.\n",
+"\t-u -U NUM --unified[=NUM] Output NUM (default 2) lines of unified context.\n",
+"\t -NUM Use NUM context lines.\n",
+"\t -L LABEL --label LABEL Use LABEL instead of file name.\n",
+"\t -p --show-c-function Show which C function each change is in.\n",
+"\t -F RE --show-function-line=RE Show the most recent line matching RE.\n",
+"\t-e --ed Output an ed script.\n",
+"\t-n --rcs Output an RCS format diff.\n",
+"\t-y --side-by-side Output in two columns.\n",
+"\t --width=NUM Output at most NUM (default 130) characters per line.\n",
+"\t --left-column Output only the left column of common lines.\n",
+"\t --suppress-common-lines Do not output common lines.\n",
+"\t-DNAME --ifdef=NAME Output merged file to show `#ifdef NAME' diffs.\n",
+"\t--GTYPE-group-format=GFMT Similar, but fo
Re: [Info-cvs] CVS 1.11 is now available
Also note this did not start happening until some one got the SARCASMbright idea/SARCASM to auto add the unnecessary [Info-cvs] to the subject of each of the messages, so you might look for that system and see what needs put back the way it was. BTW 11:14 two from Steve Cameron and 13:16 three from Greg A. Woods, so it is still broken. Yarry Gonzalez wrote: Hello all, I'm not sure why this was sent three times. I swear I only sent it once... ;-) One item of interest is that I did post that message from the eGroups archive site. I am sending this one directly to the list, so if you get it only once, I think we've found the problem. I will try and contact eGroups if this turns out to be the case. Sorry bout the spam, certainly wasn't intentional. Take care, Yarry Gonzalez OpenAvenue Community Relations -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Ernest Schwaegerl Sent: Wednesday, September 20, 2000 11:16 AM To: Yarry Gonzalez; [EMAIL PROTECTED] Subject: RE: [Info-cvs] CVS 1.11 is now available This is the 3rd copy of this message that I have received. They were: 1. 11:08 AM 2. 11:09 AM and this one 3. 11:10 AM. Lots of replies are coming through numerous times. What's up with this list? Ernest J Schwaegerl ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Verifymsg on branches?
Alex Harper wrote:
Uwe,
I've just finished my first cut at doing per-branch bug number requirements in
our CVS repository. Bear in mind I haven't finished testing it yet, so I could
be way off base here. It also presumes you are using cvs client/server.
My solution was to parse the server-side Entries and/or Entries.Log in the cvs
temp directory during msgverify. Any sticky tag (including branches) for the
files committed seems to appear there so you can check the sticky tag against a
list of known branches (in my case supplied by Bonsai).
I'm fairly certain this will not work for the commit -r case Laird mentioned,
but since 99% of my users are using GUI CVS clients which do not have a commit
-r interface anyway I decided this was a hole I could live with (given no other
choice).
Loginfo supplies a lot more information than any of the other CVS hooks, the
problem for me was that by the time the loginfo runs you can't stop the commit.
Its already happened. So while you can warn the user that they didn't include a
bug number you can't actually _make_ them do anything at that point.
If someone with more CVS hook experience than I knows of a hole in the above
suggestion please let me know...
SNIP
If you want something that is simple, and I mean simple no checking for branches,
which makes sure bug ID's are applied, try the verifymsg and rcsinfo combo.
for my setup I use something close the following (please no laughing, it works
well enough) and a reasonable amount of growling when people go around the thing.
It is applied on the server and is executed on the server.
Though it does not check for branches, it does make sure Bug numbers are used
before checking the change into the revision tree, with the exception of "mvc",
"none" and "version_rev" which is where the growling comes in.
CVSROOT/verifymsg
#cut here
PROJ /CM_scripts/verify_checkin.sh
#cut here
CVSROOT/rcsinfo
#cut here
PROJ /CM_scripts/rcsinfo_template.txt
#cut here
/CM_scripts/rcsinfo_template.txt
#cut here
PCR#:
Reviewed(y/n):
Comments:
#cut here
/CM_scripts/verify_checkin.sh
#cut here
#! /bin/bash
# this script is for use by CVS for the verifymsg settings.
#
if head -2 $1 | tail -1 | grep "PCR#:" /dev/null; then
#note mvc = my version control...useful for personal revisions
#none = no pcr just check it in. (If you don't want to see me, don't use.)
head -2 $1 | tail -1 | awk -F: '{ print $2 }'
if head -2 $1 | tail -1 | awk -F: '{print $2}' | grep -e "[[:digit:]]" -e
"[[:digit:]][[:digit:]]" -e "[[:digit:]][[:digit:]][[:digit:]]" -e "mvc" -e "none"
-e "version_rev" /dev/null; then
if head -3 $1 | tail -1 | awk -F: '{print $2}' | grep -e y -e Y -e n -e N
/dev/null; then
#it has a number and it has a review mark
exit 0
else
echo " "
echo "either it has be reviewed or not, either way let me know which."
echo " "
exit 1
fi
else
echo " "
echo "I need a PCR number, or a mcv or none marker."
echo " BTW we get to see each other if I see a none used with out permission"
exit 1
fi
else
echo " "
echo "Not using the form I see."
echo " "
exit 1
fi
#cut here
stddisclamer.h
Re: Obtaining a list of all projects in CVS
"Derek R. Price" wrote:
Antony Stace wrote:
Is there a command which will list information about all the projects in
the CVS repository? Ie, what projects exist, what files are being
worked on in each project, etc. Or do I need to write a script to get
this type of info?
There isn't one. 'cvs co -c' and 'cvs co -s' will work if the modules
admin file is up to date but you shouldn't set up a modules file for this
reason.
The easiest way is to use 'ls' in the toplevel of the repo if you have
access.
You can try the following to get a complete file list, and you might be
able to deduce the project list from that:
cvs -nq rdiff -s -D"Jan 1, 1970" . |awk '{print $2}'
There's also a wrapper script floating aroud that I'm told does what you
ask. Search the mail archives.
Derek
along the same lines to get the modules alone
cvs -n checkout -p CVSROOT/modules
seems to work even though I do not have direct (not a mounted file system) access
to the cvs repo.
i.e. if you do
cvs -d :pserver:[EMAIL PROTECTED]:/home2/cvsroot login
get password from http://www.cvshome.org/dev/index.html#anon
cvs -d :pserver:[EMAIL PROTECTED]:/home2/cvsroot -n checkout -p
CVSROOT/modules
you get to see the cvs modules file
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: notify file
Tomás Velek wrote: I thank everyone who have send me the answers, but I still don't know, how to get to know, what I want to know. Is there a simple way, how to inform the other users about my commit. I'd like the other users to get email, that contain names of the commit files and who who were they commited. To achieve this this I'd prefer 'notify' file, that will run extern mailing program (in my case 'postie.exe', that I found on internet). I'd like use the 'notify' file for every user to choose whether to receive email notification or not (with help Watch add command). If it is possible, please give me advice. Minutely, if you can. I'd be very obliged to you. P.S. I supposed, that I only write one line to 'notify' file to right working on NT server. For examle: ALL postie -to:%s -msg:"Parameters, which I ask you" Is possible it? Tomas If you have a cm account (or even a dummy account that can be controlled by cm if cm does checkins) have that account do a cvs watch add -a commit at the head of your tree and then change your 'notify' file to ALL postie -to:ALL_MY_PROJECT -msg:"Parameters, which I ask you" where ALL_MY_PROJECT is an alias on your mail host to everyone in your group, this will force it out to everyone. My preference though has always been to leave the -to: as -to:%s and request that everyone on the project run cvs watch add -a commit in the directories they may be changing, that way if it is a big project they are not getting hundreds of emails a day for directories that may/do not affect them. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: SV: Different kind of access methods
Larry Jones wrote: [EMAIL PROTECTED] writes: On the same time.. ( Just to be sure :-) ) ?? Yes. -Larry Jones Larry, Don't you have to be careful if someone is doing :local: access but on an nfs/smb/samba mounted CVS repo? (I mention this because I have seen it mentioned many times as a bad thing) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS with cvsroot on a samba mount
"Derek R. Price" wrote: Sorry. No new solution. Like I said the first time through, the easy answer is in switching to pserver mode and the second best probably lies in figuring out which flags need to be changed on the SAMBA server to allow CVS to operate properly across the share. You might be better off with pserver anyhow. Other problems may decide to rear their heads later, due to, say, EOL conversions or whatever, and may turn out to be more subtle and harder to fix. you might want to look back in the archives (if the archives are working) for a thread running from 13 Dec 2000 through 14 Dec 2000 with the subject of "SV: Different kind of access methods" for some of those more subtle problems. Of course if you want to do the testing debugging, we'll read all the advice you can send. :) Derek snip stddisclamer.h
Re: Force CVS to using root to commit files (one way or another)
Matthew J Fletcher wrote: Hi,. I am trying to setup a cvs system for development but have come across a number of problems, which i would hope some of you have seen before. - Due to the requirements of our work we need to be operating as root, (this is set in stone, honist), however it is very anoying to logout or su to another user to commit files, how can i force cvs to accept root commits ? I have worked on UNIX for about 5 years doing things from user-space programs down through hardware drivers, the only time you NEED to be root is to "make install; insmod driver" the hardware driver, assuming you know how to use file permissions. The only possible exception I have seen is a program that is ONLY used for machine maintenance by root. - If it is not possible to force cvs to accept root commits, i would like to have a quick script to load my cvs gui from another user, but i have failed to get this to work, i know its not strictly a cvs issue, but its either ask here or we have to go back to Microsoft SourceSafe and co, (i thought a bit of emmotional blackmail might help) find cvs_source -type f |xargs grep CVS_BADROOT eg,. #!/bin/bash su matt tkcvs -dir /usr/src/cvssources exit but it dont work,.. any ideas ? Try this: #!/bin/bash su - matt -c "tkcvs -dir /usr/src/cvssources" exit -- regards --- Matthew J Fletcher NPD Firmware When did ignorance become a point of view ? --- OSR -- __ We apologize for the inconvenience, but we'd still like yout to test out this kernel. -- Linus Torvalds, announcing another kernel patch ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: using NFS from homogeneous (almost) systems
Frederic Brehm wrote: I know that one should use client/server CVS when the repository and sandbox are on heterogeneous systems. (SGI and Sun, for example). What are the pros and cons of using NFS to access the CVS repository between systems that are similar? What if the OS version isn't exactly the same? I'll let others answer this one. We have been using CVS like this for a while. I would like to know if it is worth setting up a cvs server on our file server. The sysadmin has to do this and be comfortable with it because he is the only one who can login to the file servers. Thanks, Fred An easier method, to implement and thus more worth setting up, might be rsh to one central box that has access to the repo dir. If you already use rsh/ssh between machines in the office it is fairly easy to just change everybody's $CVSROOT to point to ":ext:open_machine_name:/path_to/repo" also you may need to set $CVS_SERVER if for some reason the server's cvs binary is not found on the path provided to the shell. That is the method we use here with a mix linux, sun, and HP-UX hosts and clients, so far without repo locking problems. This will have all of the file locking happening on just one machine, and thus no NFS race/heterogeneous problems. Another nice thing is, if the repo is the only thing on the NFS drive people were accessing you could restrict access to only the open machine and thus be able to keep a slightly better eye on when someone interacts directly with the ,v files. -- __ Todd Denniston, Code 6067, NSWC Crane mailto:[EMAIL PROTECTED] I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power The opinions expressed here are not sanctioned by and do not necessarily represent those of my employer.
Re: val-tags issue (was: CVS 1.11.1 Released)
Ingolf Steinbach wrote: Hi, could someone with write permissions please make sure that cvs1-11-1 is in CVSROOT/val-tags? Thanks. % cvs up -r cvs1-11-1 cvs [server aborted]: cannot write /home2/cvsroot/CVSROOT/val-tags: Permission denied % cat CVS/Root :pserver:[EMAIL PROTECTED]:/home2/cvsroot Regards Ingolf I agree, something seems a bit off. thor:~/cvs/repo/ccvs$ cvs -z2 update cvs [server aborted]: update requires write access to the repository thor:~/cvs/repo/ccvs$ cat CVS/Root :pserver:[EMAIL PROTECTED]:/home2/cvsroot thor:~/cvs/repo/ccvs$ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: The hated $Log$ keyword
Greg A. Woods wrote: [ On Wednesday, May 2, 2001 at 10:39:47 (-0700), Richard Wesley wrote: ] Subject: The hated $Log$ keyword BTW, I appreciate the arguments against using $Log$ (redundancy, merging, admin -m, etc.), but these guys really like the Header Teach them to use cvs log (and even cvs rlog now). Either that or teach them to use GNU-style ChangeLog files (which is really trivial with some tools) SNIP I have found that cvs2cl.pl also does a really nice job of generating the logs I need (and I used to like $Log$ when we used rcs), it even tries to generate the 'GNU-style ChangeLog files' Greg is talking about. When you run it against the whole of the repository it lets you see more easily how changes relate to the different files, or if you want the history of just one or a few files you can specify them on the command line. take a look at it here: http://www.red-bean.com/cvs2cl/ -- __ Todd Denniston, Code 6067, NSWC Crane mailto:[EMAIL PROTECTED] I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Automatically increment build number
Weber, Mathias-Henry 1254 PPW-P1 wrote: SNIP Again - you're absolutely correct. This is what I do for real releases (linking features to a tag). I just wanted to have some kind of a compact handle that help me to gauge the behaviour of the various intermediate test releases that come up during the same day and sometimes reside simultaneously on the same dedicated test machine with names like Appl.exe Appl.exe.old Appl.exe.bak Appl.exe.debug etc. The process is that a developer builds an intermediate executable on his personal machine including some fresh features that he wants to test. Then he takes this executable to the dedicated test machine (there is special hardware needed to test). Here he finds the above depicted situation and he needs to copy the new executable to the test machine with the name Appl.exe. So - he moves the existing Appl.exe to something like Appl.exe.dontknowhowtoname and copies his file in place. After having tested he leaves the test machine and checks in his modifications. We build official test releases about once a week, and there is a tag and a release notes file coming with each of them. But we daily build several personal releases and it does not pay off to document each of these releases mainly bound to trash can. Here a build number that is incremented automatically would be handy. Since this topic is in no way crucial I consider this thread closed. Nevertheless it helped me a lot to discuss it here to get a clearer view of it. Thanks Mathias Sorry to reopen but I could not help but to believe the restated problem (tracking where something is in one day / builder) as a little easier to solve. 1. have your official test release tag script apply appropriate strings for an official release. 2. have another tag script set the development baseline up with a line like the following: fprintf(stderr, \n \t compiled %s %s\n, __DATE__ , __TIME__ ); It should also be possible to some how pass in the username (on unix anyway) as a -D option to the compiler and add that to the line. -- __ Todd Denniston, Code 6067, NSWC Crane mailto:[EMAIL PROTECTED] I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Automatically increment build number
Weber, Mathias-Henry 1254 PPW-P1 wrote: SNIP Just having __TIME__ in a file is not sufficient. This file must be rebuild every once the resulting executable is linked. So you need an additional rule for this file. Cheers Mathias simple, i.e. bad, kludge all: build stuff to completion touch file_with_print_statement.cpp Ok, you are correct, my solution does have a whole in it. -- __ Todd Denniston, Code 6067, NSWC Crane mailto:[EMAIL PROTECTED] I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: handling of MsWord-Documents in CVS ?
Patrick Lynch wrote: Good morning, I've been reading the traffic in regard to placing Word documents under WinCvs and CVS and I'm getting concerned. SNIP Bottom line: with this 'scenario', will WinCvs support Microsoft Word documents stored as 'binaries'? Thank you, Pat I don't use WinCvs at all, but CVS has not had any problems for us with controlling the word files we keep in it as binaries (which is what they are). http://cvshome.org/docs/manual/cvs_9.html#SEC80 I don't think even branching has much to do with it, other than when it comes time to merge two branches with changes you have to do doc file merges with word by hand instead of using CVS to do it automatically. as long as you only have one person doing a write operations on a particular document you should not end up with problems. http://cvshome.org/docs/manual/cvs_10.html#SEC83 I would suggest doing a 'cvs watch on word.doc' for each doc so that they come out read only and the 'cvs edit ' and 'cvs editors' works. http://cvshome.org/docs/manual/cvs_10.html#SEC89 If I have any GCEs above please correct them to the list, we don't actually use the 'watch on' because there is only one person who ever edits the word docs (lucky us). -- __ Todd Denniston, Code 6067, NSWC Crane mailto:[EMAIL PROTECTED] I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Release notes out of CVS
Anette Van Aswegen wrote: Hi I would like to know whether there a facility exists within CVS from where I can retrieve a release note after we have released a new version. `cvs log` and `cvs history` try http://www.red-bean.com/cvs2cl/ to get the notes down to a manageable list. How would CVS know which version was released to a client? CVS does not by itself, however you can use branches and/or tags against the whole baseline to make it appear so to the human operator. http://cvshome.org/docs/manual/cvs_4.html#SEC48 http://cvshome.org/docs/manual/cvs.html http://cvshome.org/docs/manual/cvs_14.html#SEC111 Thank you Anette van Aswegen -- __ I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power The opinions expressed here are not sanctioned by and do not necessarily represent those of my employer.
Re: CVS and assesment
Larry Jones wrote: Thomas Tuft Muller writes: I imagine a scenario where each programmer is forced to check in once a week (preferrably with a specific tag indicating that the files are possibly untested/uncompilable). Proper scripts could analyze the code regarding inter alia number of lines/words/bytes, commenting, commenting rules, coding-rules, class cohesion, method-length, class-length, parameter names, variable names, etc, etc. In addition the scripts should also take into account the state of the archive last time the scripts were run, and analyze/provide statistics about the change. Combined with a weekly/monthly submitted timeplan from the programmers, this could be a valuable tool for managers to see the overall as well as individual progress/quality. Does such analying scripts exist for the CVS archive format? I sincerely hope not. -Larry Jones Hmph. -- Calvin Sorry to spoil your day Larry, but such scripts do exist (some managers still do not understand that Source Lines Of Code [SLOC] is only useful with Xlib and raw C, but not Motif or GTK and C++ or java). I will however only give you the first line of such an abomination that I have been forced to live under: cvs checkout -r HEAD -p $MODULE_NAME 2/dev/null $TMP_FILE2 It's up to you to determine what kind of tyrannical analysis of $TMP_FILE2 you want to do with a FORTRAN program or perl script. -- __ Todd Denniston, Code 6067, NSWC Crane mailto:[EMAIL PROTECTED] I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power The opinions expressed here are not sanctioned by and do not necessarily represent those of my employer.
Re: Download documentation
[EMAIL PROTECTED] wrote: Hi, I would like to download the CVS online manual to be able to use it locally. I mean the one you get on http://cvshome.org/docs/manual/cvs.html I did not find it anywhere, even not in the complete CVS distribution. Where can I get it? Kind regards Anke Koelzer cd cvs-1.11p1/doc makeinfo --html cvs.texinfo --force or if you want better output you might try using texi2html (like Derek did to create the pages). http://www.mathematik.uni-kl.de/~obachman/Texi2html/ Derek, when you made the pages did you have to do any fudging about to get it to work? I did not expect to have to use the --force with makeinfo. -- __ Todd Denniston, Code 6067, NSWC Crane mailto:[EMAIL PROTECTED] I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power The opinions expressed here are not sanctioned by and do not necessarily represent those of my employer.
Spaces in directory or file names
What have been peoples experience with keeping code under CVS where either the file and/or the directory names have spaces in them? Will it work, or do I find my LART and apply it (or both)? What are the 'gotyas'? Yes the code I am about to import comes from a windows developer, I am trying to figure out how big the bullet is I need to bite or put in his mouth. I have already done a search of the email list and a google of cvshome.org so please answer with a direct link or text explaining your experience. -- __ Todd Denniston, Code 6067, NSWC Crane mailto:[EMAIL PROTECTED] I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Spaces in directory or file names
Donald Sharp wrote:
It seems to work for me when I just tried it..
Create a test repository and create a filename with a space in it
try different things with it. See if it works.
donald
well one thing it seems I can not do is use the directory as a module
i.e. in the modules file
proj_source proj_rootdir/proj Source
proj_source proj_rootdir/proj\ Source
proj_source proj_rootdir/proj Source
none of the above will work.
I get the following for the above
cvs [server aborted]: there is no repository /CVSROOT/proj_rootdir/proj
cvs [server aborted]: there is no repository /CVSROOT/proj_rootdir/proj\
cvs [server aborted]: there is no repository /CVSROOT/proj_rootdir/proj
server 1.10.7
client 1.10.8
looks like I am going to at least have to get rid of spaces in the dir names,
unfortunately the above dir is not the only one with spaces... time to pull out
bash, and sed :{
On Thu, Jun 07, 2001 at 08:28:19AM -0500, Todd Denniston wrote:
What have been peoples experience with keeping code under CVS where either the
file and/or the directory names have spaces in them?
Will it work, or do I find my LART and apply it (or both)?
What are the 'gotyas'?
Yes the code I am about to import comes from a windows developer, I am trying
to figure out how big the bullet is I need to bite or put in his mouth.
I have already done a search of the email list and a google of cvshome.org so
please answer with a direct link or text explaining your experience.
--
__
Todd Denniston, Code 6067, NSWC Crane mailto:[EMAIL PROTECTED]
Phone : (voice)(812)854-3993 (fax): (812)854-3437
I'd crawl over an acre of 'Visual This++' and 'Integrated Development
That' to get to gcc, Emacs, and gdb. Thank you.
-- Vance Petree, Virginia Power
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Spaces in directory or file names
Derek R. Price wrote:
Todd Denniston wrote:
Donald Sharp wrote:
It seems to work for me when I just tried it..
Create a test repository and create a filename with a space in it
try different things with it. See if it works.
donald
well one thing it seems I can not do is use the directory as a module
i.e. in the modules file
proj_source proj_rootdir/proj Source
proj_source proj_rootdir/proj\ Source
proj_source proj_rootdir/proj Source
none of the above will work.
I get the following for the above
cvs [server aborted]: there is no repository /CVSROOT/proj_rootdir/proj
cvs [server aborted]: there is no repository /CVSROOT/proj_rootdir/proj\
cvs [server aborted]: there is no repository /CVSROOT/proj_rootdir/proj
server 1.10.7
client 1.10.8
looks like I am going to at least have to get rid of spaces in the dir names,
unfortunately the above dir is not the only one with spaces... time to pull out
bash, and sed :{
Or abandon your use of the modules file.
Derek
Actually I found I could sneak around this problem with the creative use of
simlinks.
create a bottom level directory called links and put simlinks to the
directories I want as modules, fortunately I only have one for now.
--
__
Todd Denniston, Code 6067, NSWC Crane mailto:[EMAIL PROTECTED]
I'd crawl over an acre of 'Visual This++' and 'Integrated Development
That' to get to gcc, Emacs, and gdb. Thank you.
-- Vance Petree, Virginia Power
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Advantages and Disadvantages of CVSNT
Mathias Meyer wrote: on Donnerstag, 14. Juni 2001 00:59 you wrote: What about the capabilities of commitinfo, loginfo, taginfo. I would imagine those must be limited on an NT server, since it won't have all the same commands available. (I'm just guessing though, as I've never run it on NT. It's something you should investigate though). SNIP Yeah, those are very good points. I thought about loginfo etc. too, but I don't think that those could be convincing arguments for my admin, but anyway thanks for the hints. Maybe I'll convince him. Thanks a lot and best regards from germany. -- Hey, *info is not a point for your admin. it's a point for your boss wink. Sorry boss I can't provide that *info because the admin decided I MUST us NT. :) -- __ I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Archiving a project
Furmaniuk, Michael wrote: We currently have our repository set up with all of our projects as high level directories, in this sort of idea: --- project 1 --- code / system -- project 2 \ --- project 3 ...etc We are now not going to use some of them (say project 1 or 2), they are for customer specific projects which are now cancelled, and the code is duplicated in other projects so we won't lose development. I am wondering what is the best way to lock the repositories and keep anyone from checking code into them. I was thinking of using watches, or perhaps setting up scripts to watch for specific directories and not display them if anyone tries a checkout or a CVS log. Is there a good scenario to use in this case? I've been looking in the archives, the Docs, and even in Karl Fogel's book and really don't see where someone has wanted to lock people out of a project, and unlock it later on if the project suddenly comes back. We do use scripts to do checkouts from CVS and set up the code in development and build areas, one idea I toyed with was changing directory names at the project level to have a keyword and modify the scripts to ignore any projects with that keyword. But if I change directory names I don't want to screw up CVS. Is there a good way to handle this? Thanks, Michael perhaps you could do a cvs watch on, set the permissions on all the directories (that you want protected) so no one had write access (chmod oug-w dirs), and then setup a lock dir (I think you may need to do this ?Larry?) so people can still check it out for read only. pro: -no moving the repo -later checkouts of the files are marked ro in sand boxes (watch on) -no one (even the cm person) can mod the repo with out shell access to the repo (to change perms on the directories) -you can still do checkouts to look at the code con: -you have to have shell access to the repo to set it up. -you (may) have to modify the lock dir setup. -you can still do checkouts to look at the code. -- __ I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS and AFS
Michael Sperber [Mr. Preprocessor] wrote: Gerhard == Gerhard Sittig [EMAIL PROTECTED] writes: Gerhard On Thu, Jun 14, 2001 at 22:50 -0400, Charles Karney wrote: We use CVS in a mixed Windows and Linux environment. Recently we switched from accessing the CVS repository vis ssh to a Linux machine on which CVSROOT was a local disk to having the \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ CVS repository in AFS and having all clients access this as a local file system. ^^^ Gerhard You did read the few thousand horror stories of what's going to Gerhard happen when accessing repos via networked filesystems in the Gerhard list, didn't you? ... because by far most of them don't apply to AFS. If you'd read the report you'd seen that most of the few thousand horror stories have no relation to what Charles was asking about. although they do not sound like AFS because they usually say NFS or SMB, they are exactly the case described by Charles! Telling CVS on each machine that it accessing the repository on a physical (local) drive so that all lock files are being cached in the local machines File System cache. However the case is that the lock files are being cached locally, network latency added, and finally being put in the actually distributing computer's cache to be checked by other cvs clients. This allows a race condition to exist where one client may not know another has a lock and so it can (insert bad thing) which corrupts or causes other problems with the repository. Basic summary: If the repository is being accessed as a local File system, then the repository should be on a physical disk of the computer, otherwise you have different clients in a race condition. Real use: If the repository is an network file system (NFS/SMB/AFS) mount then it can be used as a local file system IF and ONLY IF you are using a remote protocol (RSH/SSH/pserver) to connect to the single computer which accesses the repo as a local file system, there by making all locks in only one computer's cache. (Some even indicate this could be bad, but I have YET to experience a problem with it. YMMV) -- __ I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS and AFS
Michael Sperber [Mr. Preprocessor] wrote: Todd == Todd Denniston [EMAIL PROTECTED] writes: SNIP Todd Telling CVS on each machine that it accessing the repository on Todd a physical (local) drive so that all lock files are being cached Todd in the local machines File System cache. However the case is Todd that the lock files are being cached locally, network latency Todd added, and finally being put in the actually distributing Todd computer's cache to be checked by other cvs clients. This Todd allows a race condition to exist where one client may not know Todd another has a lock and so it can (insert bad thing) which Todd corrupts or causes other problems with the repository. Not on AFS. Check your facts. I am not able to parse enough of how CVS makes and uses it locks at a code level quickly enough to answer this, so . CVS maintainers, Knowing the following about AFS, would AFS keep the locking sane or do we still have the race condition? (my understanding says yes we race because it is cacheing in two machines, but I would kind of like to be SURE for future reference.) from http://www.angelfire.com/hi/plutonic/afs-faq.html#sub1.11 Save on close: [ Programmer ] AFS Cache Manager does not send file modifications to a file server until the close() or fsync() system call. write() system calls only update the local cache copy on the client. Note the difference in semantic of writing a file: local unix file: writes update the file immediately AFS file:local cached copy updated immediately but the server copy is only updated when the file is closed or fsync'ed. It is important to understand that most applications (eg: vi, emacs, frame, interleaf, wingz, dogz, etc) issue the close() system call when the user chooses/issues the save command in the application. Users are not required to exit the application to save their changes back to the server. SNIP whole file locking: [ Programmer ] AFS does support advisory locking an entire file with flock(). Processes on the same client workstation that attempt to lock a file obey the proper locking semantics. Processes on different AFS clients requesting a lock on the same file would get EWOULDBLOCK returned. -- __ Todd Denniston, Code 6067, NSWC Crane mailto:[EMAIL PROTECTED] I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: strange release -d error
Michael P. Soulier wrote: On Wed, 03 Oct 2001 09:56:12 -0400, Matt Riechers [EMAIL PROTECTED] wrote: Does it work w/o the trailing slash? Nope. [msoulier@pmerd071 projects]$ cvs release -d CVSROOT You have [0] altered files in this repository. Are you sure you want to release (and delete) directory `CVSROOT': y cvs release: deletion of directory CVSROOT failed: Unknown error 523 Mike I have been getting the same error since I upgraded my client from 1.10.8 to 1.11, IFF my working directory is on an NFS file system. Kind of weird so I just do the `rm -r tree` after cvs tells me it is ok. You have [0] altered files in this repository. Are you sure you want to release (and delete) directory `tree\': y cvs release: deletion of directory tree/ failed: Unknown error 523 client$ cvs --version Concurrent Versions System (CVS) 1.11 (client/server) -- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Tags question
Mark Lancisi wrote: Is there a cvs command or utility that you can run on a given project/module that will give you a list of all the tags present therein? thanks in advance! markl http://www.red-bean.com/cvs2cl/ cvs2cl.pl -r -t ; grep -A1 utags: ChangeLog I am not sure if it gets them all, but it gets a good chunk. cvs status -v filename will show all attached to a particular file. the utags trick gets me all the ones applied by import and I have a file (in the repo) in which my tag scripts track all the tags I have hand applied, so I don't have to do these searches. (I think I posted the scripts earlier so if you want them try searching an archive first) -- __ Todd Denniston, Code 6067, NSWC Crane mailto:[EMAIL PROTECTED] I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Tag Comments
Colm Murphy wrote: Hi folks, It would be very useful for our development to be able to add a comment when placing a tag. This would contain more information than is possible to place in the tag name itself. Has anyone ever put a system in place to do this ? I have a script which I use to apply my tags which gives an effect similar to what you want I think. when it applies a tag it does the following: 1) checks out the project in tmp (security issues are ignored) 2) edits a file at the head of the tree by appending to the file my comments and other information I want trapped like the tag name and its relation to the release schedule (for me the file is called version.lst) 3) commits the change to version.lst using the comment I input. 4) applies the tag to the checked out baseline. when I use cvs2cl.pl this lets me see where each of my tags has been applied in relation to the baseline changes. -- __ I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs: two log questions
Neil Zanella wrote: Is it possible to do the following two things in CVS: 1. have the equivalent of a .signature file when committing so that a line or two of text are always appended at the bottom of the message log when committing If you want it for everyone try rcsinfo http://www.cvshome.org/docs/manual/cvs_18.html#SEC172 If you want it for just one person, you may be able to do something with the editor cvs brings up for you to enter comments with(but this is just a guess). 2. specify a command that in one or few lines lets me know the date of the last commit done by a specific user cd head of checked out baseline cvs2cl.pl grep user name ChangeLog| head -1 http://www.red-bean.com/cvs2cl/ http://www.red-bean.com/cvs2cl/cvs2cl.pl -- __ I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: english text only?
Greg A. Woods wrote: SNIP If _EVERYONE_ who was concerned about this issue would contact the list administrators directly instead of just posting a meta disussion to the list itself then maybe something would happen. So far as I know there have only been a very tiny percentage of us contacting the list admins directly. (The list admins DO NOT read this list itself!) do you mean: mailto:[EMAIL PROTECTED] found at the bottom of http://mail.gnu.org/mailman/listinfo/info-cvs this is the only thing I could find that I thought referred to the admins, and yes I HAVE (just a few minutes ago) sent this address an email asking for some changes. -- __ I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: english text only?
Eric Siegerman wrote: On Thu, Mar 21, 2002 at 05:44:27PM -0500, Greg A. Woods wrote: Surely you know about [EMAIL PROTECTED] too -- it's in the SMTP envelope of, and multiple times in all the headers of, every message from this list. Also [EMAIL PROTECTED], to which their web site says comments should be directed: http://www.gnu.org/prep/mailinglists.html#Spam and of course [EMAIL PROTECTED] http://www.gnu.org/prep/mailinglists.html#General Information about info-* lists makes me wonder if we could get the list turned into a moderated where the moderator is a program that: 1) requires subscription to the list before it will pass the message, and /dev/null's the non-subscriber's email. 2) replies to html messages indicating this is a mailing list, not a web page, and /dev/null's the original incoming mail. 3) replies to unicode messages that this is an email list, which uses ascii, and /dev/null's the original incoming mail. 4) passes any messages which are from subscribers but not html or unicode on to the list. -- __ I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: PROPOSAL: Addressing the list's spam issue: was: [GB2312] ±ÜÃâåeÎóµÄÍâÙQÐÐäN·½Ê
Robert J. Clark wrote: On Mon, 8 Apr 2002 18:00:47 -0400 (EDT) R P Herrold [EMAIL PROTECTED] wrote: I have copied RMS (who seems able to get attention grin) on poll results: 6 in favor, 0 opposed, 5 new pieces of spam at the moment. Definitely +1 - Rob +1 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Questions . . .
Spencer Thomas wrote: I have just set up a CVS server here in our shop (which was amazingly simple and CVS rocks the house), but I have two questions : 1. Is there a way to make CVS process a file before it is actually updated (committed) back into the repository/module and only on specific files? One of my programmers is looking to run one of his code formatters on all of our Java source code as it goes back into the repository (so that everyone sees the same formatting). http://www.cvshome.org/docs/manual/cvs_18.html#SEC165 Others can explain better why, although it can be done, doing this can be a real headache. (something to do with making cvs checkout the now updated version back into the guy's sandbox, and change markers where there are no real content changes i.e. conflicts out the wazoo) http://mail.gnu.org/pipermail/info-cvs/2002-March/026478.html http://mail.gnu.org/pipermail/info-cvs/2002-March/026400.html http://mail.gnu.org/pipermail/info-cvs/2002-March/026406.html http://mail.gnu.org/pipermail/info-cvs/2002-March/026439.html http://mail.gnu.org/pipermail/info-cvs/2002-March/026491.html just keep hitting the 'next message' links, this is a very long thread. 2. Is there a way to make CVS force comments on commits? Right now it asks for a comment, but if you leave it blank it seems to be ok. I want CVS to refuse the commit until a comment is entered. see http://mail.gnu.org/pipermail/info-cvs/2000-November/011106.html -- __ I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Retrieving timestamp of cvs rtags
Larry Jones wrote: William Brower writes: Is there any way to retrieve the timestamp of when a cvs rtag or tag command was issued? That is I'm less concerned (today) with *what files* belong to a given tag as I am *when* the tag was applied. Doing this via a cvs command would be great but even if I have to grope around in the repository, it would be OK. rtag is recorded in the history file (presuming you have one and the user doing the rtag didn't disable it), but not tag. CVS doesn't keep track of when a tag was applied to a file. And note please that tags belong to files, not the other way around. -Larry Jones although tag is not recorded in the history file, its application time can be approximated. If you run cvs2cl.pl http://www.red-bean.com/cvs2cl/ and search from the top of the Changelog generated for the tag, the first entry you find the tag in will indicate the time after which the tag was applied (and if the file was modified after that time you now have a window of time the tag was applied in). I personally use a script to apply my tags, and when it applies a tag it updates a file from the repo with information about the tag. This file is thus updated at the time of a tag and has the tag applied to it so I know within a few seconds of when each tag was applied. -- __ I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power The opinions expressed here are not sanctioned by and do not necessarily represent those of my employer.
Re: Checking a repository for corruption.
Charlie Farbstein wrote: Somewhere out there is a perl script (check_cvs.pl) that can be used to check a repository for corruption. Will someone tell me from where it can be obtained. Charles L. Farbstein Titan Systems Corporation Tactical Services Division [EMAIL PROTECTED] (619) 553-5664 -- Spawar http://mail.gnu.org/pipermail/info-cvs/2001-June/015932.html and there did not seem to be a reply to: http://mail.gnu.org/pipermail/info-cvs/2001-June/015973.html -- __ I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs update (cvs status shows CVS/Entries cached date/time)
Jayashree wrote: Hi, $cvs status a.c File: a.cStatus: Locally Modified Working revision:1.40Mon Sep 2 20:46:00 2002 Repository revision: 1.40/home/cvs/a.c,v What does the time stamp Mon Sep 2 20:46:00 2002 mean? Is that the checkout/update time or checkin time of the file? Regards Jayashree cvs status a.c ls -l a.c #note timezone to GMT effect sleep 60;touch a.c cvs status a.c ls -l a.c #note no change from above cp a.c a.c.bak sleep 60;cp a.c.bak a.c;date grep a\.c CVS/Entries cvs status a.c;date grep a\.c CVS/Entries cvs status a.c;date ls -l a.c #note timezone to GMT effect #A1: last time the local file was noted by cvs to have been written. #A2: last time the local file was written. #where written can be by cvs [checkout|update], save from your editor, cp. cvs version Concurrent Versions System (CVS) 1.11 (client/server) CVS Gurus Is this supposed to report the cached value, instead of the filesystem value which it caches during the command (kind of surprised me) Unfortunately http://www.cvshome.org/docs/manual/cvs_17.html#SEC155 and http://www.cvshome.org/docs/manual/cvs_10.html#SEC84 have the only detailed Cederqvist info I could find on cvs status and neither documents the time field for the Working revision. So do we have an annoyance level buglet? -- __ I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [annotate aborted]: invalid change text in filename,v
Larry Jones wrote: Mike Ayers writes: I have had problems on a few occasions recently with files getting corrupted in my archive (oddest thing, really - I am only operating in local mode on local drives, but I *am* running Windows...), which have, fortunately, occured on rarely checked in files (the majority citizen of most archives). I fixed them by pulling an old archive, verifying that the file was the same version as the corrupted file, then verifying that they were different. When I replaced the current repository file with the archived one, all was once again hunky-dory. Corruption almost always occurs while updating the file, so it's exceedingly rare to have a correct, up-to-date backup for a corrupted file. You've been exceedingly lucky (or unlucky, depending on your perspective). -Larry Jones Mike, I am kind of curious here, have you (back up first) ran scan disk lately? Ran low on drive space? Or have your drives just had their out of warranty anniversary? Not that I WANT to work in the windows environment, but if CVS/RCS as a repository is unstable in a local mode there, I would like to know if it is something CVS is doing or could protect against (besides refusing to work there :). -- I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Newbie question : common/shared objects
Jay Yarbrough wrote: I'm quite new to using CVS. Our applications rely on common source, and built products alike. Some of these are 3rd party (dlls, jars, source, etc.) and some are internally developed. For instance, to build release 1.2 of product X, I need release 3.4 of product A, release 5.4 of product B, and release 1.1 of product C. To build release 2.1 of Product Y, I will use release 3.4 of product A, release 5.3 of product B, and release 2.0 of product D. How is this typically handled within CVS? TIA, Jay Two ways I see. 1. for the crowd who believe 0 binary files should be stored in CVS a) put everything you have source for under cvs, probably good to have a separate module for each of the 3rd party sources. b) store all binaries in an accessible directory (use naming to indicate binary version). c) build either a file describing which binaries go with the version, or build a makefile (or your build tool of choice) which will get the binaries needed for the version. d) check the makefile/binary description file into the repository. e) use cvs tag or cvs rtag to apply the same tag to the whole set of cvs modules for the version, including the makefile/binary description file. to retrieve a version a) cvs checkout -r $TAGNAME all_modules b) use makefile/binary description file to recover needed binary files. c) build 2. for the crowd that tolerates binary files in CVS, and understands that the ',v' files will get big quick. a) put everything you have source for under cvs, probably good to have a separate module for each of the 3rd party sources. b) put binaries you do not have source for under cvs (don't forget `-kb') http://www.cvshome.org/docs/manual/cvs_9.html#SEC80 c) use cvs tag or cvs rtag to apply the same tag to the whole set of cvs modules for the version. Remember to omit ones not needed. to retrieve a version a) cvs checkout -r $TAGNAME all_modules b) build -- I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
tag vs rtag question, was Re: Merging from vendor-branch to branch
Nick Patavalis wrote: SNIP You merge the local changes cvs co -j VENDOR_R1 -j VENDOR_R2 module You resolve the confilicts, test the new sources, and generaly make sure that everything is stable. Then commit your changes. Several commits may be necesairy since the conflict resolution may take some time. No problem though since the rest of the developers are safely isolated in the VENDOR_R2_MERGE branch). When you have finished with the conflict resolution and tests you tag the trunk accordingly cvs rtag VENDOR_R2_MERGED SNIP I have not worked with normal branches or rtag before, I have always used tag and import, so I am asking this from a 'please correct my head perspective'. If at the point the rtag is ran above the last commit of a file happened on the branch would rtag place the tag on the HEAD version of the file (what we want here, I think) or on the branch version of the file? http://www.cvshome.org/docs/manual/cvs_4.html#SEC44 http://www.cvshome.org/docs/manual/cvs_17.html#SEC153 The above pages from the manual are not real clear (to me) on what rtag tags if you do not give a -rsomthing as it is working on some (possibly unknown) state of the repository. Even -D seems a little scary unless you have spent enough time looking in the repository to verify that, at the time specified, the baseline is consistent. I would think that with the situation above, doing a cvs tag VENDOR_R2_MERGED in the working directory where conflict resolution was finished would be the safest method, to be sure you tagged the resolved files and not something else. Thanks for any clue sticks. -- I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Info about tags
Nick Patavalis wrote: On Thu, Oct 24, 2002 at 08:15:30AM -0400, James Hughes wrote: Nick Patavalis wrote: What tags exist, listed in chronological order? What are the names of the tags corresponding to vendor-branch imports, in chronological order? What tags exist in a specific branch? cvs status -v will provide much (all?) of the above. No it won't! I have to know to *which* file to run cvs status in order to get the info I want. And depending on the tag I'm interested in, it might not be sufficient to do cvs status on one file alone! Take for instance this very real example (my source-tree is a linux-kernel): cvs status -v Makefile === File: Makefile Status: Up-to-date Working revision:1.1.1.2 Wed Oct 23 16:20:33 2002 Repository revision: 1.1.1.2 /home/npat/new_kernel/cvsroot/arm-linux/Makefile,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) Existing Tags: T10 (revision: 1.1.1.2) T9 (revision: 1.1.1.2) T8 (revision: 1.1.1.2) T7 (revision: 1.1.1.2) T6 (revision: 1.1.1.2) T5 (revision: 1.1.1.2) T4 (revision: 1.1.1.2) T3 (revision: 1.1.1.2) T2 (revision: 1.1.1.2) T2 (revision: 1.1.1.1) T1 (branch: 1.1.1) and try to answer: which tag represents the most recent vendor-branch import? easy follow the magic vendor branch 1.1.1.x, T10 is probably the tag that represents the most recent vendor-branch import. now the 'T2 (revision: 1.1.1.2)' and 'T2 (revision: 1.1.1.1)' looks funny, did not think you could apply the same tag to two revisions, but the last import in which the file _changed_ was T2 (revision: 1.1.1.2). A file with a richer import change history would have made this exercise more fun. OK, wait a second...I see why you chose this file...I can not be SURE that the tag was applied during an import, I only assumed it was because it followed the form of the ones used for import, and I believe than any sane (or one who wanted to stay that way) person would use a different form of tag for their own work than they did for imports. I would need at least one more set of history to figure it out for sure. You got me. there are however tools that can help. broken record, Yep that's right I am about to mention cvs2cl.pl again. (can't help it, I like it :) http://www.red-bean.com/cvs2cl/ and FLUFFY has began to do maintenance and is keeping it on cpan (so far looks like he has added an ignore_tags mod) http://search.cpan.org/author/FLUFFY/CVSUtils-1.00/ If you run 'cvs2cl.pl -r -t -b' in your sandbox and look for the tags, found with above cvs status, you will find to which files (and when iff at least one file changed) a tag was applied. and if all the files tagged at that time have the import 'magic' revision scheme, the tag is most likely an import one. Now I know why I have a file that gets updated and tagged by the script I hand apply tags with, it keeps me sanER, I know which are mine and which are vendor/other people. branch stuff seems a little tougher and as I don't have other than the vendor branch to check I can't test to give you any pointers (other than figure out what the ''magic'' revision stamp looks like). It might be posible to use the XML output to have a machine parse it out. -- I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS checkout, excluding some files??
mmala wrote: Hi Is there anyway to checkout the repository such that I can exclude some files?These files are needed for an older release but in the current version they are not needed.I know we can make a branch, but is there any other method to exclude just some files from checkout?They are in different directories. Thanks, Jeeva Sarma If the tag for the older release (you did tag the release, didn't you?) is only on the files you need, cvs checkout -rreleasetag will only get those files (as they were at the time of the release). I have used this method to get sets of files from a general test script baseline, where I just need a subset of those files for a formal test, i.e. I only tag the ones I know will be used during the formal test, then do a cvs checkout -rformal_test_tagN module If you need the files as they currently are I suppose you could do some kind of find in the checked out directory and pipe that to a cvs update -A fnames, as someone earlier noted an update would probably get all the other files too. -- I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: problem commiting file to CVSROOT
Daniels, Dave F [PCS] wrote: I have several files I'm trying to commit to a subdirectory of CVSROOT, but only the ,v file is being created. I'm concerened about this because some users may make changes without realizing the files aren't being updated correctly on the server. To work around this problem temporarily, I've manually created the necessary files on the server, but I'd like to understand why this isn't being done by cvs. if you are talking about files in $CVSROOT/CVSROOT/ (admin files) http://www.cvshome.org/docs/manual/cvs_2.html#SEC20 then you are probably looking for: http://www.cvshome.org/docs/manual/cvs_18.html#SEC176 In this case I have to ask, Why are USERS changing any thing in this directory? The users question is why I am confused as to what you are asking. if you are new to cvs, I am concerned you are talking about normal files (source code)? here I would suggest reading most of the manual http://www.cvshome.org/docs/manual/ but in particular http://www.cvshome.org/docs/manual/cvs_2.html#SEC9 and http://www.cvshome.org/docs/manual/cvs_2.html#SEC11 -- I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: first change on a branch causes no change to show up in -rTAGA::TAGB
Matthew Herrmann wrote: Hi All, I'm using cvs2cl to generate version differences on branches, but I'm having trouble with picking up changes where no change was previously there. I think the problem is one in cvs log, though, not cvs2cl. Here's the command I use cvs2cl -w -f ChangeLog_%1_To_%2.txt -r%1::%2 the scenario that breaks it is: working on branch BRANCH1 at TAG1, on BRANCH1 : file is on 1.23 at TAG2, on BRANCH1 file is on 1.23.1.4 after changes the problem is that even when looking at 2 tags on the same branch, it is only after the first change to the file that it becomes _really_ on the branch, before that, the tag is still officially on the trunk. What would fix this for me is for 1.23 = 1.23.x.y to be considered on the same line. At the moment the line is only being start just after 1.23 which means I'm losing a significant number of changes out of these history logs. are there any patches available for this problem? some others must have had this problem with log -r. cheers, matt I assume you are speaking of either http://search.cpan.org/author/FLUFFY/CVSUtils-1.00/ or http://www.red-bean.com/cvs2cl/ the '-r' option to cvs2cl is for: [-r, --revisions Show revision numbers in output] what I think you want is to pass options to cvs log so you should use -l options: [-l OPTS, --log-opts OPTS Invoke like this cvs ... log OPTS] if you want to pass revisions to cvs log I believe it should be something like cvs2cl -l -r%1::%2 -w -f ChangeLog_%1_To_%2.txt I use the global compress option as cvs2cl.pl -g -z9 -r -t -f cl.txt so I think the line I gave you above will work, if cvs log will accept whatever -r%1::%2 evaluates to. -- I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How can i make sensable release notes off of the history log?
Paul Sander wrote: Take a look at the rinfo and lmerge programs at http://www.wakawaka.com/source.html They're not a complete solution to your problem, but they get you a lot closer to it. --- Forwarded mail from [EMAIL PROTECTED] Has anyone been tasked to make release notes out of the history log file? I was wondering if there is a perl script or anything out there that will make the history file more organized. Right now the history log file is 10mb and has many duplicate commit comments --- End of forwarded message from [EMAIL PROTECTED] along the same lines as rinfo, cvs2cl will make a change log from the history and checkin comments. Note that cvs2cl attempts to make one entry for each commit, so if you checkin 100 files with one cvs commit, cvs2cl will give you 1 entry in the log. http://search.cpan.org/author/FLUFFY/CVSUtils-1.00/ or http://www.red-bean.com/cvs2cl/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Using cvsup mirror for a fast checkout
Chris Sharpe wrote: I've got several remote sites that have slow links and large checkouts are too slow (for their satisfaction). Here's my plan: 1) Use cvsup to create a read-only mirror that is local to them. Update this at least once a day. Prevent checkins here. 2) Create a wrapper around 'cvs checkout' which will take their $CVSROOT from the environment or from a -d argument, change the hostname from the master server to their local mirror, and then pass that along as the new -d arg to 'cvs checkout'. So :method:[EMAIL PROTECTED]:/archive becomes method:[EMAIL PROTECTED]:/archive. After getting a checkout from the cvsup local mirror, it then traverses the tree and changes all of the CVS/Root files back to using the master server. 3) Now all future cvs operations (update, log, commit, etc.) will operate directly with the master, but the amount of data going back and forth over the net is far lower. Any holes in this? It seems that since cvsup is creating an exact duplicate from the master, all of the CVS/Entries data should be in sync as well. And the first update will pull over changes made since the mirror was last updated. If you are going to do step 2 so 3 happens why not just make a tar.bz2 at your local site and copy that to the remote site on the period that you would have done the cvsup, and wrapper cvs checkout to untar the file and change :method:[EMAIL PROTECTED]:/archive to :method:[EMAIL PROTECTED]:/archive then do a cvs -z9 update Assuming a cvsup period of at least longer than once every 2 or 3 days? if they were still doing updates, logs and diffs against a cvsup server, then making the change to the master at commit time (which they would be reminded to do as you are not allowing writes to the files in the cvsup server), I would see cvsup as the better solution. -- __ Todd Denniston, Code 6067, NSWC Crane mailto:[EMAIL PROTECTED] I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Bug tracking.
J wrote: Well, I think you haven't tested what you are saying. Indeed, there is I've explain it poorly prehaps. So you can gladly go without tags: you just need to have in place an alternate method to know that bugfix X is composed by foo.c at revision 1.2, bar.h at rev. 1.27 and whee.dat at rev. 1.1.1.1 Yes, but what I would like is a uniqe commit number, whatever it may be, 578 for instance applied to all the files involved in that single commit. I commit my changes and cvs says: Commited change #578 ... Then I could say in my bug log: Fixed memory leak, in commit #587 Then, it would be nice if you could go cvs diff -r #587 -r #586 and it would say: changed files: main.c ...diff fish.c ...diff other.c ...diff Still I guess I could just say: Fixed memory leak, in version main.c 1.2, fish.c bar.h 1.27 other.c 1.1.1.1 But it would be difficult to get the right versions out. With a commit number you could go: cvs update -r#586 The answer it to use labels I guess, but I don't really want to label all the files just for a minor bug fix. I just thought it would be a useful feature to be able to go back to state just after a specified commit. You could see exactly what's been done at any point, without having to label everything first. (this numbering thing is ofcourse is an implicit labeling system at commit time) Actually CVS does 'sort of' apply an implicit label at commit time. It time stamps the checkin, use '-D' to get it back. One caveat, this might get mangled if someone else was doing a checkin at the same time or same second. And I have found just putting a BUG_ID field in the commit comments (you can enforce this with a rcsinfo script) to be adequate to track when changes went in and what they changed, though I use http://search.cpan.org/author/FLUFFY/CVSUtils-1.00/ or http://www.red-bean.com/cvs2cl/ to generate my bug fix log. And why is it you don't want to apply tags, like just after doing the commit to fix 586 to just issue `cvs tag fix_586` either in the same directory or at the base of your sand box? It has been a while since we discussed on the list as to whether many tags slowed things down, but IIRC it seemed that it was not a problem until you had several hundreds of files with several thousands of tags. -- I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: List files of a Tag
Brusset, Mathieu wrote:
Hi folks,
I'm currently a CVS administrator.
Configuration: Win NT server + WinCVS1.2 + CVSNT 1.1.11.3
I'm looking for different admin stuff :
1. How to get the list of files from a TAG ?
on unix try:
cvs -n checkout -rTAG -p module 21 1/dev/null|grep Checking out |awk
'{print $3}'
BTW order matters with the '21 1', and I have done the above with tags I
know are only applied to portions of my baseline and yes it only returns file
names that have the tag.
on NT first suggestion:
install cygwin and do unix method.
on NT second suggestion:*
reboot to unix do unix method.
on NT third suggestion:
you might be able to use MS find instead of grep but good luck on redirecting
stderr and stdout.
2. How to get a list of tag from a project ?
on unix:
a) if all tags have been used in some kind of command after cvs tag:
more $CVSROOT/CVSROOT/val-tags
b) if you are not sure (a) is true:
cvs log -t |grep -v -e ^[[:alnum:]] -e \
|awk -F: '{print $1}'|sort |uniq
On NT:
a) hope all tags have been used after they were applied and:
more $CVSROOT/CVSROOT/val-tags
b) install cygwin/unix and:*
cvs log -t |grep -v -e ^[[:alnum:]] -e \
|awk -F: '{print $1}'|sort |uniq
Kind Regards,
Mathieu
*someone being less annoying than me MAY know of a way to do similar things
with the NT and windows clients, or other unix toolkits for MS.
--
I'd crawl over an acre of 'Visual This++' and 'Integrated Development
That' to get to gcc, Emacs, and gdb. Thank you.
-- Vance Petree, Virginia Power
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Security options :-(
Phil R Lawrence wrote: Satya Prasad DV wrote: At 02:32 PM12/17/2002, Mike Ayers wrote: Here's a bit of a challenge for the list. We need to set up a CVS repository on a Linux server such that the users can't modify the files, except through proper CVS operations. The catch? They are currently permitted to log into the server. The cvs user id and group id need to be different from all other login users. And set permissions for repository such that the cvs user and group only are given write permissions. This should suffice And then what? Use pserver to map the existing user ids to the cvs id? I have been trying to figure out a secure way to set this thing up, but each way seems to have big drawbacks. Method 1 description: - users SSH into existing accounts. - repository has group permissions that allow users to check in and out, etc. drawback: - users can modify the history files, because they are located in the same dir as source files. Audit function is thus compromised. If I have understood Greg correctly this drawback can be nullified, by telling SSH to only let you execute one command 'cvs'. man sshd, search for 'command='. And combine that with filesystem permissions (and ACLs?) on each of the modules/directories/CVSROOTs to get finer granularity of your access control. -- I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Solaris install help?
Bob Imperial wrote: please skip the HTML on a mailing list, mail is for raw text, and many of the people who can answer your question do not use HTML mail readers. Anybody out there have experience with installing CVS on Solaris? I've inherited the task on getting source control on our development server and I am a newbie with installing anything on Solaris. TIA! http://www.cvshome.org/dev/codes.html tar -xvzf cvs-1.11.2.tar.gz cd cvs-1.11.2 more INSTALL #search for 'Building from source code under Unix:' #and most times you can start at step 2 #follow it. #then either a) cd doc lpr cvs.ps #begin reading #or b) point your browser at http://www.cvshome.org/docs/manual/ and begin reading, after that look at http://www.cvshome.org/docs/ -- __ Todd Denniston, Code 6067, NSWC Crane mailto:[EMAIL PROTECTED] I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: GUI client that checks out 1 file?
Phil R Lawrence wrote: SNIP Command Line GUI. My department wants a GUI that allows graphical browsing of the repository tree and the ability to check out individual files. The ability to shell out and type commands by hand will underwhelm those whom I'm trying to convert to CVS. Any other ideas? Phil Phil, Why do they want to check out individual files? (this might help us come up with a better answer for you) If you are looking for the users to know they are the only ones editing the file try the cvs watch command, or for something closer to locks see Noel Yap's RCVS patches. The standard mode of operation, what cvs and its clients, expect is that the developer will checkout either a directory structure or part of a directory structure, each of which can be defined as a modules in the CVSROOT/modules file. Even when you checkout a single file with CVS it makes the directory structure up to the file. I suppose that you could either put each file in it's own directory or setup the modules file to point to a single file for each module, but to me and probably others the question is WHY, CVS was meant to let multiple developers work on multiple files at one time. http://www.cvshome.org/docs/manual/cvs_10.html#SEC83 -- I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: error with checkout
Schwenk, Jeanie wrote: Why do I get this error when attempting to checkout from a node where the repository DOES NOT reside. When I perform the same checkout from the node where the repository resides, everything is fine. cvs server: existing repository /export/cvsroot does not match /export/cvsroot/env/locke -Original Message- From: Schwenk, Jeanie Sent: Friday, January 17, 2003 12:45 PM To: CVSpost (E-mail) Subject: error with checkout I am getting one result from the node where the cvs repo resides and another when using the pserver to access the repo. Here's what I am doing on the node where the repo resides: cvs co -d . PILOT_ENV When I do the same thing from any other node, for example: cvs co -d . HOMER_ENV I get the following error: cvs server: existing repository /export/cvsroot does not match /export/cvsroot/env/homer cvs server: ignoring module HOMER_ENV Here's what is in the modules file: HOMER_ENV-d /home/sc env/homer PILOT_ENV-d /home/sc env/pilot assuming that with your shell `echo HOMER_ENV` gives -d /home/sc env/homer as opposed to HOMER_ENV. wouldn't this mean what you are passing cvs looks like cvs co -d . -d /home/sc env/homer cvs co -d . -d /home/sc env/pilot which means you are passing two -d options and you are attempting to check out two different modules, does env/homer exist in $CVSROOT ? suggestion, run the commands and paste the exact command and error messages to your email, the above information looks suspiciously like you typed something like the command you are using. And what does your $CVSROOT look like? (be sure to X out any passwords). you are using the same pserver $CVSROOT from both shells aren't you? Did I specify something incorrectly? How does using pserver make it different? What's wrong? Jeanie __ This is Linux country. On a quiet night, you can hear NT re-boot. -- I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS 1.11.5 Released strong(Security Update)/strong
Derek Robert Price wrote: CVS 1.11.5 has been released. This release fixes a major security vulnerability in CVS. The Common Vulnerabilities and Exposures project (cve.mitre.org http://cve.mitre.org) has assigned the name CAN-2003-0015 to this issue. See the text of CAN-2003-0015 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0015 for more information. I assume this report is why I get cvs -z9 update -P /home2/cvsroot: no such repository cvs update: authorization failed: server cvs.cvshome.org rejected access Any ETA on geting cvshome updated? -- I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: error with checkout
Schwenk, Jeanie wrote: You are correct, it is passing cvs co -d . -d /home/sc env/homer Perhaps what I want to do can't be done, I was sure it could though. I've got files that I don't want in a directory when they are checked out from CVS (e.g. .cshrc). I want them dumped in the $HOME directory not in a directory $HOME/HOMER_ENV. I've tried many different configurations because I thought the only way to get the file without having it placed in a directory was to use the -d flag. I've read the modules section in the cederqvist and I'm out of ideas. Any suggestions? Jeanie if cvs co -d . -d /home/sc/test env/pilot works on one machine then on that same machine try cvs co -d . -d /home/sc/test2 env/homer, if it works then you probably have a pserver config problem, if it does not then you probably have some kind of access problem with the homer (does not exist or no read/write perms), or it could be that you are attempting to check out two modules in the same physical directory which I am pretty sure CVS does not like (probably what the existing repository message was about). -Original Message- From: Todd Denniston [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 21, 2003 7:05 AM To: Schwenk, Jeanie Cc: 'CVSpost (E-mail)' Subject: Re: error with checkout Schwenk, Jeanie wrote: SNIP -Original Message- From: Schwenk, Jeanie Sent: Friday, January 17, 2003 12:45 PM To: CVSpost (E-mail) Subject: error with checkout I am getting one result from the node where the cvs repo resides and another when using the pserver to access the repo. Here's what I am doing on the node where the repo resides: cvs co -d . PILOT_ENV When I do the same thing from any other node, for example: cvs co -d . HOMER_ENV I get the following error: cvs server: existing repository /export/cvsroot does not match /export/cvsroot/env/homer cvs server: ignoring module HOMER_ENV Here's what is in the modules file: HOMER_ENV-d /home/sc env/homer PILOT_ENV-d /home/sc env/pilot assuming that with your shell `echo HOMER_ENV` gives -d /home/sc env/homer as opposed to HOMER_ENV. wouldn't this mean what you are passing cvs looks like cvs co -d . -d /home/sc env/homer cvs co -d . -d /home/sc env/pilot SNIP -- I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Help Required
Amit Sharma wrote: Hi All, I have one query related to CVS Linux access permissions and wanted to discuss with you all. whenever user log on CVS It parses the password file and treat the user as system user as mentioned after his encrypted password and the folder access are drwxrwx---6 cvsadmin per1 4096 Oct 1 09:27 per1 drwxrwx---6 cvsadmin per2 4096 Oct 1 09:27 per2 drwxrwx---6 cvsadmin per3 4096 Oct 1 09:27 per3 Now my query is how would it be possible for one user of per1 to have read-only access to access on per2 and other per1 users don't have the access to per2. Because as if i modify the permissions for per1 to 774 all users of per1 per3 would also have the access to per1 code(Read only) Is there any other ways for access restriction in CVS so that I can set the folder permissions as we are doing it for Visual Source Safe. Thanks, Amit. perhaps the following pages from the manual would help http://www.cvshome.org/docs/manual/cvs_2.html#SEC36 http://www.cvshome.org/docs/manual/cvs_18.html#SEC179 I think I have heard on this list (archived at http://mail.gnu.org/pipermail/info-cvs ) that a LockDir writeable by everyone who needed read access would allow read only access for everyone it was configured writeable for, and setting the actual repository to only be writeable by the smaller write permitted group would provide nice control. -- __ I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Checkout problem on cvs host
Craig Dickson wrote: When I run the following command on a client computer it works as expected: cvs -d :pserver:[EMAIL PROTECTED]:/usr/local/cvsroot checkout -d . test Running CVS as root is nuts. Doing it using pserver doubly so. Its just a test system, so get over it. still bad, because you do not get used to getting your directory permissions and group file configured correctly. working on getting over it. :) However, when I run it on the box that is actually hosting the cvs pserver, I get this: cvs server: existing repository /usr/local/cvsroot does not match /usr/local/cvsroot/test cvs server: ignoring module test checkout really wants to create the directory. The usual advice is to run the command from one level higher in the tree with a real directory name rather than .. that doesn't explain the error message, since the operation works on a client. the question is, what is different when running on the actual host server that might cause this message? it might help if you posted the pwd of the directory you were running your cvs command from and the actual cvs line used on the server. Kind of looks like you may be attempting to checkout a sandbox inside of the repository, I believe cvs no longer likes that at all. -- __ I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Checkout problem on cvs host
Craig Dickson wrote: After further investigation, I actually am now seeing it on the client box as well. Perhaps I was all along ... Here is the terminal output: C:\dev\test\MAINcvs checkout -d . test cvs server: existing repository /usr/local/cvsroot does not match /usr/local/cvsroot/test cvs server: ignoring module test WAG, softlink somewhere in the path. WAG 2, have you done a `cvs init` on the server? WAG 3, MS CR-LF translation bites (are you using cygwin/wincvs/both)? http://www.acronymfinder.com/af-query.asp?String=exactAcronym=WAG -- __ I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: XML Schema and DTD for CVS Info in XML files?
Herr Christian Wolfgang Hujer wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello dear CVS users, I'd like to know wether there already exists an XML Schema and a DTD to include CVS information in XML files. SNIP I am not sure it is exactly what you want but on the cvs2cl page there is a dtd and schema for cvs2cl's output, which might at least give you some ideas. http://www.red-bean.com/cvs2cl/ http://www.red-bean.com/cvs2cl/changelog.dtd http://www.red-bean.com/cvs2cl/changelog-xml-schema.xdr new home for cvs2cl http://search.cpan.org/author/FLUFFY/CVSUtils-1.00/ -- __ Todd Denniston, Code 6067, NSWC Crane mailto:[EMAIL PROTECTED] I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: new feature.
Shankar Unni wrote:
SNIP
(b) Interesting idea, but why do you want to avoid tagging everything?
The general recommended CVS usage model is that the repository be
considered a whole entity. Thus, you tag the entire repository the way
it should be for a particular release, whether it be a full release, or
a partial delta.
Extra tags on files cost almost nothing, and by properly maintaining
your tags, you can re-generate your deltas trivially using cvs diff
-rtag1 -rtag2, which will generate no output for files that have not
changed between tag1 and tag2.
Is this something you're already doing with another revision control
system? I can't think of any commonly used revision control system that
does the sort of thing you're asking - at least, not ClearCase or
Perforce, which are the other two I've used extensively.
SNIP
while I agree with Shankar, that for most situations having the whole
repository tagged is the best method and for your situation I think it is
correct, I have found a use for tagging just some files.
When working with a mess of scripts used for testing a product, I found that I
had several 'engineers debug' scripts which needed controlled and could
eventually be used for THE test, but for each formal test it was decided that
only the scripts called out formally in the test description were to be
available to the testers (this removes the management worry that they are
running the just make it work backdoor scripts).
I found that if I had a file with a list of the filenames (one per line) used
in the formal test I could do a variation on the following (in bash):
BASE_SCRIPTS_DIR=path_to_checked_out_baseline
TAGNAME=My_Formal_tag
tagsome()
{
read INPUTLINE
while [[ $INPUTLINE != EOF ]]
do
#the following should tag each file individually so we only tag those we
#want to.
(cd $BASE_SCRIPTS_DIR/scripts;cvs tag -l $TAGNAME $INPUTLINE)
read INPUTLINE
done
}
tagsome list_of_the_filenames.txt
#the following would retrieve only the files that had the
#tag applied to them.
#I do not know if this is a 'known feature' of cvs, so it
#may change in the future.:)
cvs checkout -r$TAGNAME scripts
Note: how you get list_of_the_filenames.txt is your problem, I had to do
several contortions of `strings ?.doc|grep patterns|awk|perl_script` (Yes you
can program when you are just the CM person :)
-Original Message-
From: Marc Tessier [mailto:[EMAIL PROTECTED]
Sent: Monday, March 24, 2003 3:13 PM
To: Shankar Unni
Subject: RE: new feature.
SNIP
Some people work with CVS by tagging all the files but in my
case I just want to work with delta. I do not need to resend
to my people all files just need to send them delta so my
packages are small all the time.
SNIP
--
__
Todd Denniston, Code 6067, NSWC Crane mailto:[EMAIL PROTECTED]
I'd crawl over an acre of 'Visual This++' and 'Integrated Development
That' to get to gcc, Emacs, and gdb. Thank you.
-- Vance Petree, Virginia Power
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: new feature.
Todd Denniston wrote:
SNIP
BASE_SCRIPTS_DIR=path_to_checked_out_baseline
TAGNAME=My_Formal_tag
tagsome()
{
read INPUTLINE
while [[ $INPUTLINE != EOF ]]
do
#the following should tag each file individually so we only tag those we
#want to.
(cd $BASE_SCRIPTS_DIR/scripts;cvs tag -l $TAGNAME $INPUTLINE)
read INPUTLINE
done
}
Forgot one thing, kind of a got-ya when it hits :)
echo EOF list_of_the_filenames.txt
That is unless you like long running loops :)
tagsome list_of_the_filenames.txt
SNIP
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs issue reporting
Mark Cooper wrote: Last week, I posted a message to this group for help with a particular problem, namely that when merging between two branches (as opposed to merging between branch and trunk) under certain circumstances removed files can be re-added. Having investigated this according to the single useful response I got (thanks to Matthew Herrmann), I am 99.9% sure that there is an issue (as a developer myself I hesitate to use the word 'bug') which needs addressing. SNIP So. My question is 'How do I report an issue or bug to the cvs development team?'. Mark Cooper Like Larry said: Seriously, you asked a hard question that will require some serious investigation and thought. Mark, have you considered generating a set of commands to generate your error? With a repeatable procedure to generate the problem, the problem is half solved... most of the time. (it is possible you have done this and I have not seen it because I am not subscribed to the bug list) from your first email: Mark Cooper wrote: We have recently noticed a difference in the way that a merge works between two branches and between a branch and the main trunk. Consider the following: branch taken from trunk work proceeds some files removed from trunk (head) new branch taken from trunk working copy updated to new branch first branch merged into new branch I generated the following script, which unfortunately I do not see your problem with. cd mkdir testcvs mkdir testcvs/testrepo export CVSROOT=~/testcvs/testrepo/ cd testcvs/ cvs init mkdir testrepo/baseline cvs checkout baseline cd baseline/ touch testfile.txt cvs add testfile.txt cvs commit -m need file cvs tag tag1 cvs tag -b -r tag1 tag1b cd .. cvs checkout -r tag1b -d branch baseline cd branch/ pwd testfile.txt cvs commit -m message cd ../baseline/ cvs remove -f testfile.txt cvs commit -m removeal touch nefile cvs add nefile cvs commit -m add nefile cvs tag tag2 cvs tag -b -r tag2 tag2b cd .. cvs checkout -r tag2b -d working baseline cd working/ cvs update -j tag1b -j tag2b ls exit cvs --version Concurrent Versions System (CVS) 1.10.8 (client/server) Yes I know that machine needs updated! Bad Todd, will make better use of /opt and simlinks in the future. :) btw when I try it with a newer version I get the same answer. cvs --version Concurrent Versions System (CVS) 1.11.5 (client/server) -- __ I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Ignore local changes?
Wade Williams wrote: Yes there is: Do not ever modify the CVS controlled file! Always, and only ever, modify a copy of any file if you don't want CVS to see your changes to it! I.e. this is a build system problem, not a CVS problem. No, it's not a CVS problem. However, CVS could make life easier with this as an option. I can't imagine I'm the only developer that makes local changes to try something out, but wants to be sure those changes do not end up in the repository. The problem with it's a build system problem is that the files in question are not a part of any build system. They're application configuration files. So, that requires me to modify the original file, and then make sure the original is back in place before committing so my changes are not put into the repository. But, it sounds as if I'd be beating my head against the wall by arguing this one further. Wade Actually, it may be a build system problem. If as a part of normal development you need a config file that is different from the production config file, you probably can and probably should setup a script/Makefile/Magic_Incantation which can generate the appropriate config file for development or production, and then version control that (instead of the config file). If on the other hand you are only varying the config file because you want to try something out, well I have known plenty of engineers who do that, and because it is something non-standard and probably only vaguely needed (i.e. no one else is going to need the config that way) they deal with the fact that they must do things by hand to keep their 'interesting config' from ending up in version control. if on the third hand (hey, where'd that come from?) each engineer needs their own config that does not change often and it for some reason can not be tweaked to the specific setup by a build script probably_bad_suggestionyou could each branch your version of the config file and not worry about the fact that it is under version control/probably_bad_suggestion. -- __ I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Input files
Hamid Ghassemi wrote: Can CVS use an input file in place of options for each individual file. We have a list of files that makes up a recipe of what source code is needed to make a product. suggestion read http://www.cvshome.org/docs/manual/cvs-1.11.6/cvs_4.html#SEC48 it tells you that cvs can internalize the recipe so you do not have to even have a separate file with the information in it. I would like to use this file as a input to a CVS command to do checkouts, tag, commit, etc. There is no interface in cvs to do it directly, however you could build a script (language of your choice) to make an interface. I would have it do something like the following. $recipe_version=v_1_1 /*maps to v1.1 ?*/ while $more_files_in_input.txt do $line = read line from input.txt $filename=$line.$1 $rcsversion=$line.$2 /* humans should ignore cvs use of rcs version numbers, and use tags */ cvs tag -r $rcsversion $recipe_version $filename done echo to get the input.txt version back for rebuild $recipe_version type \`cvs checkout -r$recipe_version module\` in an appropriate directory. echo in the mean time club the CM person until they understand echo how to use cvs tag or cvs rtag on the whole baseline echo and just keep input.txt as an artifact of the past. :) echo http://www.cvshome.org/docs/manual/cvs-1.11.6/cvs_4.html#SEC48 see the following for a bash script that does someething like you want http://mail.gnu.org/archive/html/info-cvs/2003-03/msg00251.html http://mail.gnu.org/archive/html/info-cvs/2003-03/msg00252.html Here is an example Input file input.rxt: /foo/foo.c 1.1 /foo/abc.h 1.4 Command line Cvs co @input.txt Or CVS co input.txt Thanks in advance Hamid ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Literature on SCM
Minich, Matthias wrote: hello, i'm looking for some good information about version-management, software-change-management or configuration-management. so maybe someone can suggest some books or online-resources (books preferrably german, but english also does the job) about introducing such a system in existing projects and workflows. thanks, Matthias Minich Brad Appleton and others Branching Patterns for Parallel Software Development has helped me a lot. He also has a lot of SCM links on the page. (Note: the page has moved...to) http://www.cmcrossroads.com/bradapp/acme/ there are some books listed off of: http://www.cvshome.org/docs/ http://ccvs.cvshome.org/fom//cache/80.html David Thornley has some practical help for cvs users. http://www.thornleyware.com/ try following the thread in: http://mail.gnu.org/archive/html/info-cvs/2001-08/msg00771.html there is some advice and links to resources there. Also searching for books or resources or branching and scm may turn up something in the archives. http://mail.gnu.org/archive/cgi-bin/namazu.cgi?query=book+scmsubmit=Searchidxname=info-cvs http://mail.gnu.org/archive/cgi-bin/namazu.cgi?query=bookidxname=info-cvs http://mail.gnu.org/archive/cgi-bin/namazu.cgi?query=resourcessubmit=Searchidxname=info-cvs When I look back at a lot of the mailing list hits, I am begining to think we probably need an entry in the CVS Home FAQ-O-Matic http://ccvs.cvshome.org/fom//cache/1.html for this question. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: from Arun - lock in CVS
arun wrote: Hi All, SNIP Its is working fine, but after checkout of files, they are not locked for a single user. How do i lock the files From anybody else editing it. SNIP 1) you might look in the archives for this discussion which has been had many times before. http://mail.gnu.org/pipermail/info-cvs http://mail.gnu.org/archive/html/info-cvs/2002-02/msg00575.html especially follow: http://mail.gnu.org/archive/html/info-cvs/2001-10/threads.html#00350 http://mail.gnu.org/archive/html/info-cvs/2001-10/msg01024.html 2) understand that locking is not the model used by CVS: http://www.cvshome.org/docs/manual/cvs-1.11.7/cvs_10.html#SEC83 3) for a fuller understanding of CVS start here: http://www.cvshome.org/docs/manual/cvs-1.11.7/cvs.html http://www.cvshome.org/docs/manual/cvs-1.11.7/cvs_1.html#SEC1 4) look at some of the troubles you will have and the way others have solved them: http://mail.gnu.org/pipermail/info-cvs http://ccvs.cvshome.org/fom//cache/126.html http://ccvs.cvshome.org/fom//cache/120.html (I think the answer here might not be quite right though, I think the commands done only change the sandbox) -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: help on pserver connection
One other fun thing to check on after you have modified
/etc/xinetd.d/cvspserver
( http://www.cvshome.org/docs/manual/cvs-1.11.7/cvs_2.html#SEC30 ), and
restarted xinetd, and found it is still now working on leprechaun, is to see if
the same
`cvs -d :pserver:[EMAIL PROTECTED]:2401/repo login` works on genesis. If it does
work there have someone familair with linux firewalling look to see if the
kernel is bitbucketing all your packets from off machine, 2401 should be out of
that range...but it might not be. I have had this problem with a recent RH and
another service (RSH), don't you just love admining a machine some one else
setup.
kent emia wrote:
[EMAIL PROTECTED] kent]$ cvs login
Logging in to :pserver:[EMAIL PROTECTED]:2401/repo
CVS password:
cvs [login aborted]: reading from server: Connection reset by peer
[EMAIL PROTECTED] kent]$
from the Online-Manual
:pserver:
Errors along the lines of connection refused typically
indicate that inetd isn't even listening for connections on port
2401 whereas errors like connection reset by peer, received
broken pipe signal, recv() from server: EOF, or end of file
from server typically indicate that inetd is listening for
connections but is unable to start CVS (this is frequently
caused by having an incorrect path in `inetd.conf' or by
firewall software rejecting the connection).
snip
maybe they are referring to '/etc/xinetd.d/cvspserver' isn't it?
my settings in /etc/xinetd.d/cvspserver
# default on
#
# service cvspserver
service cvspserver
{
disable = no
id = cvspserver
env = HOME =/home/cvs
socket_type = stream
protocol= tcp
port= 2401
wait= no
user= root
passenv = PATH
server = /usr/bin/cvs
server_args = -f --allow-root=/repo pserver
}
SNIP
--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: revision/version numbers
Jim.Hyslop wrote: Katherine King [mailto:[EMAIL PROTECTED] wrote: SNIP Now, having said all that, if they want to see if something's changed, they can use the diff command: cvs diff -rPREVIOUS_TAG -rCURRENT_TAG filename If diff says nothing, then the file has not changed. To get exactly what you have asked for (which is really not that useful, given what the goal of your testers seems to be) you can issue these commands: echo ^RCS file:filerev echo ^revision filerev cvs log -rCURRENT_TAG | grep -f filerev The output will look something like this: cvs server: Logging . SNIP cvs log -rCURRENT_TAG 21|grep -e ^revision -e ^RCS file: I think the above may give you some false positives, the files in the Attic (dead don't have the tag) lists all revs in the file. cvs log -t |grep -e CURRENT_TAG -e ^RCS file: shows all files and whether they have the tag. cvs log -t |grep -e CURRENT_TAG -e ^RCS file:|grep -B1 CURRENT_TAG shows just the files that have the tag. (I think) Of course with any of the methods you may have to do some awk/perl/'text editor' to reduce the data for non programmers so the _repository directory_ and ',v' are gone. BTW What Paul Sander indicated Labels are not immutable; they can be moved around. is true, though hopefully if it is an important tag the person who did it will be beaten with an _appropriate_ clue bat, then you can recover with the information recorded from one of the methods above. I guess I have been lucky and no one other than me (CM person) has messed about with tags, I may have to start keeping a file for the above on releases in the future. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Using cvs to manage system configuration files
Wayne Johnson wrote: I have several systems I manage. I'm always making changes to things like /etc/hosts, /etc/sysconfig, /etc/httpd/conf, etc. I was thinking. Would it work to create a master configuration directory with sym links to all the common config files, then import this to cvs. Then when something stops working, you can do a diff to see what it was. If a system update (i.e. rpm) provides a new mail.cf file, you can see what customizations you've had, and merge them in. Anyone done this? Any problems? Security? Probably don't want a public cvs server to do this, right? Any problems using symlinks for CVS files? TIA, SNIP If all the systems are going to be that similar why not use NIS[+] and maintain the changes on just one system (and have those files under rcs on that system or in a cvs off-system for backups)? Oh, and when using NIS it's probably a good idea to put a firewall at the point where you want to stop the distribution of the NIS information, like just before the internet connection or the connection to the rest of the company. And I would think if you keep any of the information in CVS/RCS (whether you use NIS or not) you would want to make directory read (and definitely write) access to all of the repo off-limits for anyone not in the administration group (not the same as root). -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: how can I see what changes a cvs update would merge
Robert P. J. Day wrote:
-Original Message-
From: Jim.Hyslop [EMAIL PROTECTED]
Sent: Nov 28, 2003 9:50 AM
To: [EMAIL PROTECTED]
Subject: RE: how can I see what changes a cvs update would merge
Robert P. J. Day [mailto:[EMAIL PROTECTED] wrote:
???. my cvs reference doesn't explain the -wb or -i
options to cvs diff. care to elaborate?
Have you tried cvs --help diff?
-
whoops, point taken. i was just glancing at the 2-page CVS reference card
i got from www.refcards.com, and it made no mention of those diff options.
i guess there really is more than one way to do things.
google on { Quick Command Line Reference cvs }
and you'll come up with a way to generate an `up to date` refcard for
your version of CVS.
if you want a pdf version I suggest you pipe its output through mpage
and ps2pdf :)
for the really impatient:
http://www.faqchest.com/prgm/cvs-l/cvs-99/cvs-9911/cvs-991102/cvs99110510_16799.html
or
http://www.geocrawler.com/archives/3/382/1999/4/50/2094674/
and the incredibly impatient:
http://www.enetis.net/~mitch/make-cvs-quickref
--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: exclusive checkout
[EMAIL PROTECTED] wrote: Hi everyone, Is there a way of enforcing exclusive checkout in CVS? http://www.cvshome.org/docs/manual/cvs-1.11.7/cvs_16.html#SEC119 cvs admin -l CONTROLEDFILE will lock the file but, you will have to 'enforce' it with people skills, and likely hate your self later for even considering working this way. http://www.cvshome.org/docs/manual/cvs-1.11.7/cvs_10.html#SEC95 read the following message if you want more insight as to why, and if you are not afraid of patching your tools, there patches for you. http://www.mail-archive.com/[EMAIL PROTECTED]/msg04330.html I know about the advantages of CVS's unreserved checkout model, which is great for coders, but our graphics artists will be getting problems with it. They develop pictures and thus like code developers should know and understand the limitations of any tool they use. how multiple _developers_ can work work together, and sometimes the tools they use will _help_ them. http://www.cvshome.org/docs/manual/cvs-1.11.7/cvs_10.html#SEC83 The tools can only help if the developers follow company/task policy. In the case of cvs, the help is that cvs can watch a file and let you know if it is being edited by someone else. The policy will have to include no use of chmod on the files being watched. http://www.cvshome.org/docs/manual/cvs-1.11.7/cvs_10.html#SEC89 cvs watch add -a all CONTROLEDFILE cheers, Uwe -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Any hangin lock issues, pserver, 1.11.10 1.11.11?
Mark wrote: I have attempted to upgrade from 1.11.1p1 on solaris 2.8 to 1.11.11. We use a non-root pserver. It seems that with 1.11.11(10), the 2 I have tryed, there quite often is lock files left, allong with the corresponding cvs-servid directory. The server process exits, it is no longer running. This lock files left are in pairs. What I mean is the #cvs.lock directory is left with the correspondind #cvs.wfl* file. Any ideas... thought it was 1.11.11 so I when to 1.11.10 when it still happened, I put the 1.11.1p1 binary back... everything is fine now. I built the 1.11.1p1 with solaris make (ccs) and sun workshop 6.1, same with 1.11.11(10) built them on the machine that they run on. Thanks, Mark Mark, I am not sure if Sun got mmap correct in 2.8 (unpatched), but your problem seems to have a boundary similar with a problem I had in solaris 2.6 recently. http://mail.gnu.org/archive/html/bug-cvs/2003-11/msg00152.html after you configure (but before compile) of cvs Version 1.11.1p1 make the following change in config.h: diff config.h.normal config.h 199c199 #define HAVE_MMAP 1 --- /*#define HAVE_MMAP 1*/ compile and try your hand tests with this version. If this fixes your problem then it looks like you have a couple of options: 1) live with this no mmap version, and remember that you have to mod the config.h file when putting new versions on because there is no --disable-mmap option to configure. 2) patch the sun box up and see if that fixes it, with possible reversion to option 1. bonus option) slack off less than Todd and make a patch+doc_update to the source adding a --disable-mmap config option and get Larry or Derek to apply it. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs commit/up's change file ownership in working dir.
Patton, Matthew E., CTR, OSD-PAE wrote: Classification: UNCLASSIFIED From: Kaz Kylheku [mailto:[EMAIL PROTECTED] Read up on the setgid bit on directories. I have extensive use of setgid on my REPOSITORY. setgid is not a solution when managing things like /etc/*. I think we need to move beyond simply creating in the working directory a file owned by whatever fopen(2) comes up with. No we don't. The POSIX operating system interface is designed such that programs can use the fopen() function without worrying about it. It does the right thing based on the process security context, umask, and permissions of the directory. ... Versioning permissions is a bogus idea. When you check out files, they should be created such that they are accessible to you. Then my patch to eradicate the chmod'ing of checked out files based on the respository's file perms is all the more necessary - who came up with that one anyway? SNIP My little example describes just one of a few problems wherein CURRENT implementation of PRESERVE_PERMISSIONS would end up overwriting the perms/mode of a file with whatever person was last mucking with it. Again, I repeat that I simply want to store a perm+mode attribute in the RCS file so that when it's checked out it gets those perms unless of course the euid of the process (eg. non-root) can not actually do the chown/chmod in the working directory. I don't care about these latter failures. SNIP As Larry indicated the PRESERVE_PERMISSIONS_SUPPORT was found to not work as it was expected, and thus (from my perspective) it was marked in a way to allow it to atrophy. Why it has not been completely removed yet is unknown to me, perhaps it is something to look forward to with the final 1.12.X release. I suspect from your first email you have read some of the list archives that I have below[1-5]. I believe the wall you are hitting with your patch is due to three things: 1) As Larry mentioned in Re: cvs ci, cvs upd: Hard linkage problem [2] you need to include test cases in sanity.sh to verify that the functionality works and continues to work in the future and better to have those same ones crash/break/fail under the current code. Which is also mentioned in the HACKING file under Writing patches (tactics) 2) Everyone else using CVS has found that it is much easier/saner to manage file permissions and ownership using a build tool of some sort, and even specifically for /etc [3,4,5]. Some even give, what I see as, good reasons to keep permissions out of CVS, see Kaz Kylheku's responses [5]. 3) Because PRESERVE_PERMISSIONS_SUPPORT code as a whole is notoriously buggy and contains at least one known problem that can cause unrecoverable data loss[6] and has been for quite some time, (my opinion only) no one wants to even accept a patch to it that does not fix it all and accept maintainer ship for the long haul. The original (cleaned up) vision for Preserve Permissions can probably be seen in the references from Jim Kingdon's email[1]. [1] Subject: Re: CVS and PreservePermissions http://mail.gnu.org/archive/html/info-cvs/2000-12/msg00378.html [2] Subject: Re: cvs ci, cvs upd: Hard linkage problem http://www.faqchest.com/prgm/cvs-l/cvs-00/cvs-0005/cvs-000505/cvs00051019_22271.html (I wish mail.gnu.org/archive had most of the pre mid 2000 posts. From time to time I find many good answers in my personal archive back through Dec. 99, and can not reference them online.) (solutions) [3]Subject: Re: CVS management of /etc - permissions problem http://mail.gnu.org/archive/html/info-cvs/2001-09/msg00353.html [4] Subject: Re: using cvs to contol system files http://mail.gnu.org/archive/html/info-cvs/2002-10/msg00352.html http://mail.gnu.org/archive/html/info-cvs/2002-10/msg00351.html [5] Subject: Re: CVS management of /etc - permissions problem http://mail.gnu.org/archive/html/info-cvs/2001-09/msg00348.html http://mail.gnu.org/archive/html/info-cvs/2001-09/msg00373.html [6] from Larry Jones. I am pretty sure Larry got tired of typing this and has it in a permanent cut and paste buffer somewhere as it is the same (or almost so) each time preserve permissions comes up. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: A way to see who has checked out a module?
Could it be Phil that you have posed the question because the users that want this have come from a version control system that either supports locking, like rcs|sccs, or from a version control system that does locking by having a human cm dole out files to the people who request to work on them? If the above is where they come from and are looking for something vaguely similar in CVS you might try `cvs watch on filename`[1]. If it is mostly to further communication when someone finds out the file they have been modifying is changed when they do a cvs update, try `cvs watch add -a commit` so they might be notified a little quicker. BTW from your first email ... I do not want to give them shell access to the box. I have not used ViewCVS, but I have a question, if people are modifying the files how is it they don't have 'shell access to the box'? note: I have begun taking a perspective near Greg Woods' on pserver, ... pserver is almost as good as a shell access with none of the accountability. Or are the users in question read only? [1] http://www.cvshome.org/docs/manual/cvs-1.11.10/cvs_10.html#SEC89 Steve deRosier wrote: Again... this isn't going to tell you much. It basically gives you a log of certain activity with the system. I can run the same command and I get the following results: * I have 21 modules checked out. Of those 21, I only have directories in my sandbox for 15 of those (where did those others go? probably rm -r them at some point when I didn't need to work on them anymore) Of the 15, I haven't touched 6 of them in close to a year, and in the last two months I've only even looked at 3. * Someone who left the company almost 6 months ago has 8 modules checked out. * One person only has 1 module checked out -- From March last year. * No releases are ever done by anybody. So, what info does cvs history -ao give you? Basically that someone checked out a module for some reason at some point. Does that give you the info you're looking for? Maybe. If so, I'd just setup a simple cron command: 'cvs history -ao /var/www/html/cvscheckouts.txt' But it doesn't tell me anything useful. - Steve Phil Labonte wrote: But you can see who has checked out files and when via the command line so all I was looking for is something to add to apache... I guess I will have to write my own perl script for cgi cvs -history -a -o shows all users and all checked out modules... Greg A. Woods wrote: [ On Tuesday, January 13, 2004 at 09:25:52 (-0500), Phil Labonte wrote: ] Subject: Re: A way to see who has checked out a module? I use ViewCVS as well but there is no option to see a log of checked out files is there? If there is can you let me know where? Fundamentally there's really no such concept of checked out files in CVS. There is no file locking in CVS, so checked out does not mean what I think you think it means. Any number of people can have any number of working directories checked out on any number of clients. None of it really makes any difference to how anyone would know who's really working on what. CVS is not a replacement for good project management. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Help and info on line endings
Frederic Brehm wrote: At 12:49 PM 1/28/2004, Scott Reed wrote: Why don't you check them out on a Windows client? The server which the users (who do not have CVS clients) access the files is running Linux. The files are automatically, periodically checked out and zipped up for download from the server. SNIP As an alternative, you can have your Linux script check the status of each file. If the Sticky Options: does not include -kb, then do the unix2dos on it. On a checkin, run dos2unix on the same files. WARNING: I don't know if the test for -kb is sufficient. If and Only If there are no -kb's, then there is one other easy option with the zip included with most Linux Distro's these days: -l convert LF to CR LF (-ll CR LF to LF) use `xzip -l [other options]` to create the zips for the windows people and `-ll` to receive zips from them. If you have binaries you could build a script that does the `-l zipfile.zip TextFileList` on known text files and then `-u zipfile.zip BinaryFileList` (I think) to add the binaries to the zip file. SNIP -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Repository file owner/group problem
Andrew E. Clark wrote: Hi there, CVS users! As this is my first post, I'll explain my problem briefly -- but please forgive me if this issue has already cropped up in previous postings... The CVS repository (on a Red Hat Linux 9.0 machine) I'm administering has the following problem: whenever a non-cvs-administrative user commits a file, that file shows up in the repository as owned by that person, rather than cvs. This behaviour effectively prevents anyone else from checking out or committing projects to the repository, since (to my thinking) ONLY cvs (my cvs sysadmin user) should be writing to it. Although I've set up a 'cvsuser' group in /etc/group and added all active users to the list (NB: we have no remote users at this time), this owner/group problem still persists. Granted, I only know _some_ things about Linux system administration... please make sure you have read and understand this: http://www.cvshome.org/docs/manual/cvs-1.11.10/cvs_2.html#SEC13 And see if it helps you. What are the permissions on your repository _directory_? from the above info it should be something like: ls -ld /cm/REPOSITORY/ drwxrwsr-x7 cmadmn cvsuser 512 Aug 18 13:19 /cm/REPOSITORY/ SNIP -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Querying log messages and more
Jeeva Sarma wrote: Hi I want to do the following. Query the log messages of all the files in the repository, get the file names and revision numbers associated with the log messages that contain a certain number(task number) cd CurrentCheckedOutSandbox cvs2cl.pl -r -t -C -R task number I have a script that does the above, including making a temporary checkout in /tmp/ for the search. http://www.red-bean.com/cvs2cl/ ok not sure, for a while the current version was as CVSUtils on cpan http://search.cpan.org/~fluffy/ but looks like it may be back to red-bean...?.. and then checkout those revisions into a directory. Should have applied a tag so you could: cvs checkout -r tag module however you might be able to use the output from cvs2cl to back create a tag, I have done it before, its kind of a pain. in the future if you need to be able to checkout specific points in the baseline tag the baseline...the whole baseline...unless you want to ONLY check out the files WITH the tag (everything else gets unchecked out). using `cvs checkout -D DateFoundIn_cvs2clOutput module` might give what you want. Is there anyway to do this other than writing a complex script? use an already complex script to get the information first and then have it's output parsed (cvs2cl will put out in xml if you want) by a slightly complex script. Any command I can use? ( other than the cvs log command) If anyone has done something similar, can you pls give me a few ideas? I would appreciate any help on this. Thanks, Jeeva -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Checkout a file revision to stdout?
[EMAIL PROTECTED] wrote: Is there any way to checkout a specific revision of a file to standard output, rather than creating a file? The real reason for wanting to do this is to find which revision of a file a particular piece of text first appeared. I wrote a script called rcsgrep a long time ago that checked out files on the main trunk only directly from the ,v file in the archive, and grepped through each one in turn. So I could use that. I just wondered if there was a better way. if it is a line that was put in and never modified, then `cvs annotate filename` might be useful. I have found that command to be a lot of fun. I usually do something like: #say I have 15 revs in the file on the trunk BOTTOM_BOUND=1 TOP_BOUND=15 SEARCH_STRING=old address, from for i in `seq $BOTTOM_BOUND $TOP_BOUND`;do \ echo $i; \ cvs diff -u -r1.$BOTTOM_BOUND -r1.$i filename|grep $SEARCH_STRING \ ;done If you want it to bail after the first found rev then do an `if cvs diff|grep... then exit 0 fi` instead of just the cvs diff line. luke -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs as a heartbeat client (questions)
I am setting up a new cvs server, and this one happens to be on a set of machines using DRBD for disk mirroring and heartbeat for cluster management. The two machines will share the same service DNS name (and IP), and which ever of them is the current master will be the one with access to the file systems on the DRBD devices. Our CVS repositories will be on one of the DRBD devices using ext3 file systems. BTW only the current master will be answering to the IP. My questions: 1) does anyone in this group already have some scripts for nicely letting cvs know it is about to lose it's lower level file systems, ready for calling in the haresources file? (hey, had to ask :) 2) on linux will a `killall cvs` cause cvs (as server for :ext: /or :pserver:)to cleanup and exit nicely or is there a particular signal I should pass to killall? What I want is to be able to essentially tell cvs is I know the file system is leaving, sync self and bail. 3) if a `killall cvs` is done on the the server processes what is the likely output on a cvs client on a remote system? Will the client automatically try again in a few seconds? Will it cause data corruption in the users sandbox? 4) worst case, if a user is committing and cvs is not stopped before the lower level device goes away (probably from a power fail), a partial or even full ',filename' new file could exist. a) correct??? b) does anything need to be done in one of these worst cases, (re)move file? 5) is there a more efficient way of locking the repository than creating all the `#cvs.rfl' in all the sub directories of all the repositories? That is, is there a single file I can create that blocks access to each repo for the whole repo, instead of what is suggested for backup? http://www.cvshome.org/docs/manual/cvs-1.11.14/cvs_2.html#SEC24 Or should I temporarily change a soflink where the cvs bin is expected (this could be problematic if someone has the bright idea of setting CVS_SERVER to something else)? I suppose unmounting the file system will also have a locking effect, but there is a possible race between the killall and umount I think. 6) am I just over killing the effect removal of the disk from cvs will have on the server processes? -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs as a heartbeat client (questions)
Larry Jones wrote: Todd Denniston writes: 2) on linux will a `killall cvs` cause cvs (as server for :ext: /or :pserver:)to cleanup and exit nicely or is there a particular signal I should pass to killall? What I want is to be able to essentially tell cvs is I know the file system is leaving, sync self and bail. I'm not sure what signal killall sends by default on Linux, but on systems that I'm familiar with it sends SIGKILL which is kill with extreme prejudice -- the signal cannot be caught or ignored so it would give CVS no chance to cleanup and exit nicely. SIGTERM is the canonical please go away signal; CVS should honor it. The man page on my slackware 8.1 system indicates the linux killall sends SIGTERM, but it is probably a good idea for portability to do SIGTERM explicitly then. SNIP 4) worst case, if a user is committing and cvs is not stopped before the lower level device goes away (probably from a power fail), a partial or even full ',filename' new file could exist. a) correct??? Yes. b) does anything need to be done in one of these worst cases, (re)move file? It's possible that permission problems could keep another user from comitting changes to that file, but the original user should be able to commit it without any problems. (And you probably don't want anyone else to commit changes before the interrupted commit is completed anyway.) Cool. In a quick test I did earlier today, if ',filename,' existed the (now) second checkin from the user would fail, but the ',filename,' was removed and the third checkin would work. From your comment it seems like a good idea just to leave those files until they cause an error, so the users know _something_ is up. SNIP 6) am I just over killing the effect removal of the disk from cvs will have on the server processes? I don't think so, losing access to the disk is a very serious problem and one that has almost certainly not been heavily tested. However, CVS was designed to be as bullet-proof as possible. I think you guy's have done a very good job of bullet-proofing it, I had to think hard on what could cause trouble and 4 above was the only thing that really popped out. If I can do 2 during root requested fall overs it should reduce the chance the systems will run in to trouble. -Larry Jones Thanks for the informative response. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs as a heartbeat client (questions)
Jim.Hyslop wrote: [EMAIL PROTECTED] wrote: Todd Denniston writes: 5) is there a more efficient way of locking the repository than creating all the `#cvs.rfl' in all the sub directories of all the repositories? That is, is there a single file I can create that blocks access to each repo for the whole repo, instead of what is suggested for backup? No. CVS locking is per-directory. Todd, would an empty CVSROOT/writers file work for you? It won't completely block access to the repository, but it will prevent anyone checking anything in while the file exists. That unfortunately only works for :pserver:, which fortunately only three[1] of the repositories uses. Note: 19 repositories exist on the version control partition, and a couple of others temporarily exist in home directories (:ext: method). [1]and soon to be one...silly windows users. :) And as soon as I get the windows users on one of the rsh/ssh solutions there will be none. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Finding out which tags exist
Derek Robert Price wrote:
Geoff Beier wrote:
Derek Robert Price wrote:
If you have a binary GNU info installed but your local CVS manual isn't
installed correctly, and you have a copy of the CVS source handy, you
can access the info manual like so:
info --directory=cvs-1.11.14/src --file=cvs.info
With my build you have to do:
info --directory=cvs-1.11.14/doc --file=cvs.info
Er, yeah. What you said. That's what you should have to do with most
builds. Sorry about that. :)
if INFOPATH is set correctly (and the $INFOPATH/dir file has been built
fully[1])
`info cvs` will work.
[1] I learned when using stow[2], that I had to move the individual dir files
to dir.package and then in the stowed info directory do something like:
FCOUNT=`ls dir.*|wc -l |awk '{print $1}'`
COUNT=`expr $FCOUNT - 1`
cat `ls dir.*|head -1` dir
for i in `ls dir.* |tail -$COUNT`; do /tmp/infodirbuild $i dir;done
begin /tmp/infodirbuild:
BEGIN_LINE=`grep -n Menu: $1|awk -F : '{print $1 }'`
END_LINE=`wc -l $1|awk '{print $1}'`
NUM_LINES=`expr $END_LINE - $BEGIN_LINE`
tail -$NUM_LINES $1
end /tmp/infodirbuild.
[2]http://www.gnu.org/software/stow/
--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Commit script
Derek Robert Price wrote: Fouts Christopher (6452) wrote: How can I achive the yet another alternative where only one log message is prompted even on a LOCAL connection? Hack your client (Jim Hyslop already pointed out the correct location - at the `if (current_parsed_root-isremote)' line)? Use `cvs commit -m message'? Wrap your CVS executable with a script that prompts for the log message then passes it to `cvs commit' as the argument to `-m'? Derek would not :fork: or :local: do it, with out having to make fun code mods? -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Submitting a contrib script?
Derek Robert Price wrote: Peter Connolly wrote: Message What is the normal way to submit a 'contrib' script to the CVS project? Either submit it to the [EMAIL PROTECTED] mailing list, or, to insure there is a tracked record, open an issue on cvshome.org http://ccvs.cvshome.org/servlets/ProjectIssues. Either way, please be aware that submitting your script to either location implies consent to release the script under the GPL and share copyright with the FSF. Of course, we prefer an explicit notice in your submission of the applicability of the GPL. Thanks for your support, Derek As I am also getting ready to send a script for contrib, I have two further questions: 1) does it have to be GPL or is LGPL also acceptable to the project? 2) would the Copyright line be ok with (C) 2004 US Department of Defense, Navy. or does it need some explicit FSF section? # License: GNU Lesser General Public License (LGPL) # # Copyright:(C) 2004 US Department of Defense, Navy. Man the fun with releasing things that you create on your employer's time is getting what they require and what the project require to line up. Then there is the actual permission and proof of. :) -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Commit script
Fouts Christopher (6452) wrote: The BEST solution yet - simple and effective! I tried this and it worked! Now for another question - where is the default commit template? Note I don't have the source files so I can't check yet. I'll download them later so I can browse them. I want to eventually create my own template and scripts to validate user, bug number etc... -chris SNIP there is no 'default commit template` with cvs, but you can make and use your own following the directions: http://www.cvshome.org/docs/manual/cvs-1.11.14/cvs_18.html#SEC156 specifically the template is pointed to by rcsinfo http://www.cvshome.org/docs/manual/cvs-1.11.14/cvs_18.html#SEC174 verifymsg points to the script/program you want to use to check they filled out the template. http://www.cvshome.org/docs/manual/cvs-1.11.14/cvs_18.html#SEC168 one basic example set sent to the list a while back is at: http://mail.gnu.org/archive/html/info-cvs/2000-11/msg00330.html you might look for others in the archive http://mail.gnu.org/pipermail/info-cvs for this and other related things: http://mail.gnu.org/archive/html/info-cvs/2001-02/msg00447.html -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: folder level access in cvs
Sandhya wrote: Hi all, Joining new to the team of mails... Have started to be the admin of cvs for for the past 1 month. Just wanted to know how to give read- write access on a folder level in cvs. I have tried readers and writers. but that works only for repository level and not for modules or directory level. If anyone can help me out how this can be achieved, it wud be of great help to me. Assumption 1: your repository is on a *nix system. Assumption 2: you are not using pserver with only one REAL user account. create unix groups (/etc/group) of users and set group write capability of directories to the correct group. Also make sure the directories are not world (other) writeable. see: http://www.cvshome.org/docs/manual/cvs-1.11.14/cvs_2.html#SEC13 and as you are a new admin make sure you read at least http://www.cvshome.org/docs/manual/cvs-1.11.14/cvs_10.html#SEC83 and probably best to just start at the beginning and read most of http://www.cvshome.org/docs/manual/cvs-1.11.14/cvs.html I like to have a local copy for fast access. http://www.cvshome.org/docs/manual/ http://ftp.cvshome.org/release/stable/cvs-1.11.14/cederqvist-1.11.14.html.tar.bz2 also search: http://mail.gnu.org/pipermail/info-cvs I believe some people may have been able to use ACLs in some types of file systems and others I believe have mentioned getting finer grained control using commitinfo scripts. Have you found your big stick yet? Good luck. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs tag: some slightly counterintuitive behaviour
Andy Jones wrote: I've found some behaviour of cvs tag that breaks the principal of least astonishment - at least, for me. In short: cvs tag doesn't tag the files in the working directory, it tags the files it thinks are there. I'm preparing a release. Some of the code is questionable - I don't know if it is dead or not but it certainly does not want to be part of the release. So I've been deleting these files from the working directory. SNIP 1) `rm -f filename` or 2) `cvs remove -f filename;cvs commit` ... 1) tells the file-system to make it go away. 2) tells cvs to tell the file-system to make it go away mark a new revision on this branch as dead. in case 1) as far as cvs is concerned it IS still there (go on, do a `cvs update`, cvs will remind the file-system). in case 2) for this branch cvs knows it is DEAD. If you only want to tag SOME of the files then you need to list each one explicitly on the tag command line. I have done this in the cases where to perform qualification testing we wanted some of the testing scripts not all, because some of the scripts were the kind that in software told the box to reset itself and get out of error conditions without power cycle or simply were not expected to be used during test so don't provide them. check the archive I might have dropped some scripts when I posted about only tagging some files before. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs tag: some slightly counterintuitive behaviour
Andy Jones wrote:
Why can't you just choose the files you want to tag and run the TAG
command only on those. This way only those files get tagged and not the
complete module, which is not want you as it is want to happen.
Because I have 12,766 files, and I want to tag all but about 30 of them. Working
out which 30 is a long and laborious process of checking by hand. It would have
been nice if I could have just worried about getting the sandbox to a given state
and then tagging that state.
What I'll end up doing is compiling a list of the 30 as I go along, tagging
everything and then doing something like:
cat badlist.txt | xargs cvs tag -d tag
As I said, it's not really a big deal, just a small surprise.
how about taking that badlist.txt and using it thus:
cd sandbox
export BASE_SCRIPTS_DIR=`pwd`
find . -type f ../wholelist.txt
grep -v CVS\/ ../wholelist.txt ../NoCVSlist.txt
grep -v -f /whereever/badlist.txt ../NoCVSlist.txt ../TagThese.txt
echo EOF ../TagThese.txt
apply_tag()
{
read INPUTLINE
while [[ $INPUTLINE != EOF ]]
do
#the following should tag each file individualy so we only tag those we
#want to.
(cd $BASE_SCRIPTS_DIR/;cvs tag -l $TAGNAME $INPUTLINE)
read INPUTLINE
done
(cd $BASE_SCRIPTS_DIR; echo y |cvs release -d scripts)
}
apply_tag TagThese.txt
takes a bit more scripting but you never delete anything out of cvs that way.
you might be able to tag more at a time, but I always worry about going beyond
the shell command limits with big lists.
I had a set of scripts that generated the 'badlist.txt' for me.
--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: folder level access in cvs
Sandhya wrote: Hi Todd and Lawrence, SNIP Now my concerns are whether I have a previlage to lock the tags that are created. As I have worked more with perforce, I have a doubt whether I can do the same with cvs. When a user creates a tag, is there any means by which other users cannot update the tag. Thanx in advance :) Sandhya.. As I indicated, the list archive has many treasures related to controlling access. Please attempt some searches there, more focused questions will probably yield better answers. http://mail.gnu.org/archive/cgi-bin/namazu.cgi?query=branch+lock+commitinfoidxname=info-cvsmax=20result=normalsort=score Sandhya wrote: SNIP also search: http://mail.gnu.org/pipermail/info-cvs I believe some people may have been able to use ACLs in some types of file systems and others I believe have mentioned getting finer grained control using commitinfo scripts. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs as a heartbeat client (questions)
Larry Jones wrote: Todd Denniston writes: 2) on linux will a `killall cvs` cause cvs (as server for :ext: /or :pserver:)to cleanup and exit nicely or is there a particular signal I should pass to killall? What I want is to be able to essentially tell cvs is I know the file system is leaving, sync self and bail. I'm not sure what signal killall sends by default on Linux, but on systems that I'm familiar with it sends SIGKILL which is kill with extreme prejudice -- the signal cannot be caught or ignored so it would give CVS no chance to cleanup and exit nicely. SIGTERM is the canonical please go away signal; CVS should honor it. It does not seem to be honoring SIGTERM (as well as I would like anyway). I issue `killall -SIGTERM cvs` twice prior to removing the disk and cvs is still running after the disks are removed. I also just tried sending `killall -SIGTERM cvs` twenty times from the command line and had no effect on the server for an :ext: checkout, not even when it switched sub directories. while doing an update, :ext: method, it takes 2 or 3 calls to `killall -SIGTERM cvs` before the server process is stopped. If the update is caught before it starts processing files, i.e., before the client prints 'cvs server: Updating .', it terminates quickly. If I am somewhat more patient, after ~30 seconds from the kill command, cvs [any command] will terminate. It looks like the client processes another 30-50 files after the server is given the SIGTERM, which seems like a lot of files to me. I am going to change my plan a little and issue the SIGTERM a couple of times, sleep 30 seconds and then issue `killall -9 cvs`, so if there is some kind of emergency we are able to go down in under a minute. 3) if a `killall cvs` is done on the the server processes what is the likely output on a cvs client on a remote system? Will the client automatically try again in a few seconds? Will it cause data corruption in the users sandbox? The client will report an error from the server and quit. The user must run it again to finish whatever operation was interrupted. There should not be any corruption in the sandbox (or the repository!), but the repository may well be in an inconsistent state sine the user might have been in the middle of a commit and thus the repository would have new versions of some files but not of others. SNIP -SIGTERM gives: cvs [server aborted]: received termination signal cvs [checkout aborted]: end of file from server (consult above messages if any) -9 gives: cvs [checkout aborted]: end of file from server (consult above messages if any) -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Question on repository file permissions
Fouts Christopher (6452) wrote: I have a sample project with r-s permissions for g and o. I have dir1/file1 directory/file in the project, which user cvsadmin in the cvs group, created. so now file1 has r--r--r-- permissions. I have a separate lock direcotry, called /cvsroot/lockDir with rwxrwsrwx permissions. Now user1 in group user checks out sample and modifies file1. When user1 checks in file1, it gets Could not open file /cvsroot/sample/dir1/file1, permission denied. I fixed it by chmod -R o+w /cvsroot/sample. I thought the idea behind the LockDir was for me (cvs admin) NOT to have to do this? - Chris T Fouts checkin requires the user to write to the repository, for this user1 needs write privileges to the REPOSITORY. i.e. ls -ld /cvsroot/sample/dir1/ #should yield something like: drwxrwsr-x # cmuser projgrp512 Jan 26 10:51 /cvsroot/sample/dir1/ #and ypcat group /tmp/look; cat /etc/group /tmp/look| grep user1 #should yield something like projgrp::530:user1,me,restofgroup LockDir lets you allow more people to read than to write, i.e. you can set it up so marketing and the PHB can read the repository but never commit. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Windows with Dir/ and dir/
Spiro Trikaliotis wrote: Hello Todd, thanks for your suggestions. * On Mon, Apr 19, 2004 at 03:51:44PM -0500 Todd Denniston wrote: SNIP I assume you either wrote over the original bin/cvs you had or are in some other way making sure you are executing the new version? Yes, I executed path-to-cvs/cvs directly (and did a cvs --version to be sure). Anyway, I found out this not to be optimal, as CVS seems to try to run exactly path-to-cvs/cvs on the server, which cannot be found or, even worse, might be something different (as in my case). At least, my crash has gone after I put the new path into the PATH environment variable. You might want to undo that and set CVS_SERVER=path-to-cvs/cvs on the client, ssh and rsh methods will use that to execute the correct server version... makes it nice and easy to try new versions out. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Fw: need to force username of cvs 'action' when using sharedSSHaccount
Tim Grotenhuis wrote: Is there a reason why you can't use the old-fashioned strategem of one account per developer ? My ISP won't give me additional accounts. Have you checked your ISP's TOS (Terms Of Service)? They may also have a problem with you allowing other people than yourself to log into ONE account, or at least YOU will be the one to blame for anything ANY of the other people who you have given access to do with that account. The ISP I have (home one) will allow you to get more email boxes (which correlates to a full user name and password in their setup) for just $2 more each month, perhaps something like this is available for you, but they would also have to manage a unix group for you if you want some security. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs diff: Include contents of added files?
Toralf wrote: When I run 'cvs diff' on a directory where a new file has been added, but not commited, the output will contain a line saying cvs server: tst.c is a new entry, no comparison available (if the name of the file is tst.c) Is it possible to have the compelete contents of the file listed as added lines instead? Differently put, can I get cvs to include the output of diff options /dev/null tst.c instead of printing the above mentioned message? I want this because I'd like to create a patch file containing *all* changes made on the working directory - including files scheduled for addition. cvs diff --new-file more_options tst.c -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Commit ID Enhancement
Derek Robert Price wrote: It occurred to me that a Commit ID implemented as a tag might make a useful addition to the CVS feature-set. From my perspective, only a minor improvement, as it only builds into cvs something that I can do as frequently or seldom as I (as the cm person on several projects) chose. If a unique commit id tag were applied to each revision as it is committed (unique across the repository and the same for each file in a commit), this might be a useful step towards the merge/change set tracking some people have proposed. Such a special tag could be accessed to back out a single commit, implying something like `up -j cid -j cid -1' when used alone to back out a single, complete, change. I would think that either a new namespace and new options // to or syntax involving -r -j would be in order or a namespace outside the current tag namespace, perhaps using names that start with a character currently prohibited in tags. I definately prefer the latter but I have not examined all the implications of that change. How about instead of reserving a namespace _from_ all users of CVS, allow them to specify in a file (in $CVSROOT/CVSROOT/) the pattern that they want used. their header and global number: boneheadedCommitNumber%n or if they want it based on each user (this might be a really stupid thing) but global number: %uTrashedUsAt%n or if they don't want it happening automatically at all: if they just want what ever you come up with: DEFAULT_PATTERN and of course I would prefer that the file default to most times. also with the current implementation of tags the tag would need applied across the whole repository, because if they wanted to checkout against the tag they only get those tags that were tagged with that tag... not a problem with diffs though. BTW I am not suggesting changing the current implementation of checkout against tags, I use that effect when I want only a particular set of files checked out for tests but want all available for development. Just an idea in case anybody has any spare time on their hands. Not enough spare time to do anything other than grump. :} Cheers, Derek Oh, and no spaces allowed in the pattern 8P -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: when cvs repository
Mark D. Baushke wrote: Fabian Braennstroem [EMAIL PROTECTED] writes: right now I am using cvs just for my programming part and I am curious for what else I could need it on my linux. Do you have any suggestions? I read that some even put there whole '/etc'-directory under cvs. Can you recommend this? No, I am not able to recommend using cvs to control /etc directly. The files in /etc would be better handled by a Configuration Management system rather than a source control system. That is, something that understands what process signals or other changes in the running state of the machine are needed to be implemented when one or more files in /etc are changed in some manner. -- Mark A more full answer would be, to control /etc you ether need a Configuration Management system that understands what the things in /etc mean, or you need a build system ([like makefiles] that you may keep in cvs with the source files for building etc) that understands /etc _well enough_ to take source configuration files and build your /etc. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: branch removal question
Don Butts wrote: Content-Type: multipart/mixed; boundary1243246784== Please do not send MIME and/or HTML encrypted messages to the list. Plain text only, PLEASE! We are using cvs in somewhat of a non-standard way. We have a production cut of our compiled source that we deploy via cvs using a production branch. The application does not mind the fact the CVS control files co-exist within the source and the application runs fine. When we want to patch production we first patch the same branch in a different checkout area and then commit it. Confused, one or 2 CVSROOTs? do you mean `patch patchfile` or `cvs update -jsomething -jsomethingelse` (generally called a merge) When it comes time to upgrade the production area we bring down the application during a maintenance window and perform a cvs update in the production area. This has worked great for more than a year so I am very happy with this process. We were basically mimicking this process in a pre-production area for QA purposes and while this has worked OK we are having a bit of trouble keeping these two branches in sync. So, I know that I can remove a branch via the cvs admin -n command and I am wondering if a better process would be to remove the preprod branch every time Why remove it? You loose history when you remove things (actually delete information from repo files), which is pretty much against having a version control system in the first place. why not create preprod`date +%Y_%b_%d` branches when you want to go into QA, so you have all the information that lead up to each release. (next question is a more personal process, not general practice) and why are the production releases not just (normal) tags on the QA branch(es), where the QA people have said this set of files is correct for release.? Of course you _might_ want to branch at that normal tag too if you need to do several fixes to the released version and then merge back to that QA branch when the fixes are ready to be QAed. I move a new patch to production and when it comes time to test the next patch just recreate the preprod branch off of the current prod branch. I have performed some tests using this method and all seems to work fine but I thought that I would ask the opinion of those who have been using CVS a lot longer than I. Thank you for your time, Don Butts -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: How to keep developers separate from committers?
Mark D. Baushke wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jean-Christian Imbeault [EMAIL PROTECTED] writes: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of For an example of one of the threads, follow this link: http://mail.gnu.org/archive/html/info-cvs/2002-05/msg00149.html http://mail.gnu.org/archive/html/info-cvs/2004-01/msg00024.html This looks exactly like the kind of thing that would accomplish what we want to do! Unfortunately the links in these threads for the patches point to a web site that no longer exists :( Well, Claus Henriksen probably still reads this list and might post new patches for you... Of course, the point I was trying to make in that thread was that it is POSSIBLE to do the same thing without any of the patches to cvs being necessary. Mark, would cvs_acls[1] in the source tarball, or cvs_acls2[2] be more direct pointers to what he wants, with out having to patch CVS? [1] cvs-1.11.16/contrib/cvs_acls.in [2][sorry only had the tarball from 1.11.16 available so I don't know if cvs_acls2 has been merged later.] http://lists.gnu.org/archive/html/info-cvs/2004-03/msg00401.html http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=cvs_acls2idxname=info-cvsmax=20result=normalsort=score -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: using commitinfo and verifymsg
[EMAIL PROTECTED] wrote: If a developer checks in multiple files in a single commit, is there anyway of finding out what all the files are using either bash or perl scripts on the cvs server? I've tried using the 'cvs status' command in a bash script tied into the commitinfo file, but that only works on a directory by directory basis. It may help if I give an overview of what I'm aiming to do: We have a project which consists of a number of software components, the source for which is kept in separate subdirectories. Each separate component has associated with it a history file, so each of the subdirectories has a history.txt file in it (sometimes at the top level, sometimes in a further subdirectory). I want to use cvs to ensure that when a developer checks in a bunch of files, that he/she is also checking in an updated history file which gives an overview of his changes. SNIP If you do not have policies that are carved in stone, you may be able to let the programmers work smarter not harder. Instead of attempting to make sure there is a history file in the directory, why not make sure that there is history kept with each file that is changed? Sounds like I am suggesting more work for the programer, but cvs makes this less work than keeping the history file for the directory, IFF you can get the programmer to make comments that are as good as s/he would have put in the history.txt file. use rcsinfo verifymsg[1] to force the inclusion of bugfix numbers (if needed) and a comment of the history.txt quality[2]. Then when the history.txt files are needed, grab cvs2cl[3] and go to the head of a checked out tree and issue `cvs2cl -d -f history.txt`. I prefer to have it in one big file most times and with revision tag information, so I use `cvs2cl -r -t -b -f ChangeLog.txt`. You might want to try `cvs2cl -d -f differentTypeOfhistory.txt` on your baseline now and see if it could be close to what you need. I have discussed[4][5] with others on the list ways these can be used to track history, perhaps those discussions might be helpful to you as well. [1]Re: Verifymsg on branches?Date: Wed, 22 Nov 2000 15:29:54 example rcsinfo verifymsg http://lists.gnu.org/archive/html/info-cvs/2000-11/msg00330.html [2] you will probably need to write some bash/perl/C code that implements your idea of how to mechanicaly guess if the programmer has entered a quality comment, and then update it when they start figuring out how to trick your rules (arms race), or beat them with a manger who will ask if they really want to go back to making history.txt files. [3] http://www.red-bean.com/cvs2cl/ [4]Re: 2 how to in CVS questionsDate: Fri, 16 Feb 2001 16:02:16 http://lists.gnu.org/archive/html/info-cvs/2001-02/msg00428.html [5]Re: Tags usage -- comments pleaseDate: Mon, 14 Jun 2004 11:49:28 http://lists.gnu.org/archive/html/info-cvs/2004-06/msg00217.html -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the WarfighterThe opinions expressed here are not sanctioned by and do not necessarily represent those of my employer. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs on Win2x cluster
Jim.Hyslop wrote: [EMAIL PROTECTED] wrote: Has anyone experience with running a cvs server on a Win2x cluster? We plan to install a version management system on a active-passiv failover cluster running under Windows 2003. Therefore I am interested in the ability of cvs to handle Windows messages to stop the process on one machine and start it on the other machine. I haven't tried the configuration you're suggesting, but CVS has no notion of Windows messages. It is strictly command-line based. HTH! I have been working with cvs in a linux 'heartbeat'[1] cluster. For me, the solution was to create a script to stop and start cvs on the correct node, it is working well for me, I just have not had time to get release of the script approved. Perhaps you could create a script or program that can receive the Windows messages and appropriately un/configure cvs to run on the node and stop/start the (x)inet like process(es). [1] http://www.linux-ha.org/ -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS and CMM workflow
Jorge Godoy wrote: Hello, Do any of you here work in a CMM certified company? I'm working with a company that is going to be certified and I am curious about some procedures to, at first, gather all evidences needed, specially authorization to start the work in some modules and the authorization to commit the changes (commiting is not hard, since there are logs, but the start is more problematic, specially with a very dynamic team). SNIP Short answer: CMM specifies what policies you should have for the work you do, not how to do that work, so we probably can't help much from here. You'll need the policies and procedures, that deal with this, from the actual company you are working with. Long answer: My understanding of the CMM is that it indicates 'if you do a type of thing, you will have procedures and policies for how it will be done'. It does not specify how to do something, that is what the procedures and policies are for, and the procedures and policies will be specific to the way the organization wants to do business. Basically you need to ask the company you are going to be working with for a copy of the appropriate procedures and policies, and read them. Seeing as you indicate you will be working 'with' and not 'for' the company a second set of policies may come into play, those policies are for subcontractors. The policies for subcontractors allows them to let you be off in your own set of policies and procedures, and tells you how they want to deal with the code you give them and what policies you have to have in place. If you are doing 'code for hire' on site, directly with their cm system, though you will probably be using their internal policies and procedures, we're back to ask them for the documents. Hope this is helpful. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: multiple password entries
mikegw wrote: Hello all, A quick question, I am using cvs over a network using rsh. When I release a project I get asked for my password for each file in the project. Is there a way to make cvs only ask once for each 'release'? on your local (client) box: echo $HOSTNAME $LOGNAME rhost.start copy rhost.start to the cvs server on the server: cat rhost.start ~/.rhosts for understanding read: http://csrc.nist.gov/publications/nistpubs/800-7/node126.html http://www.mkssoftware.com/docs/man1/rsh.1.asp -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
