RE: "cvs release" wishlist
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: 01 April 2000 01:03 > To: [EMAIL PROTECTED] > Subject: "cvs release" wishlist > > > Greetings! > > When our build tool recognizes that someone has removed a CVS > module from a > build area, I had planned to "cvs release -d $module" to > remove it from the > build area and then do a "make clean" everywhere to make sure > I had a clean > build area. > > I was bummed to find out that 'cvs release' doesn't take a > module definition, > but a DIRECTORY. I would think if I could checkout a module, > I would be able > to remove a module. Even better, a "-f" option to force the > removal even if > there are locally-modified files would make this whole thing > much more > automatable. > > Does this sound reasonable? Possible? Desirable? It sounds reasonable, but... What if I have checked out two versions of one module? Say: $ cvs co -d my_prog_v10 -r Version_1_0 myprog $ cvs co myprog There is no link as to what module you want when just saying release module myprog. Just my 2 cents. Guus
Base directory, in CVS directory
Hi All, Theory: ** Base directory, in CVS directory Base If watches are in use, then an edit command stores the original copy of the file in the Base directory. This allows the unedit command to operate even if it is unable to communicate with the server. ** That is a great feature, but the problem is that it is the copy with the exact same name as an original. Then, if I try to grep for the files recursively in some directory, I will get the files in the "Base" as well. More - that files seems to have read-only cleared, so in the end quite often I will edit it instead of the real file... Very annoying... :( I think that the file should have different extension (suffix) so it won't get into the search results AND / OR it should have a read only set, so even if I get to pick it up with the search it will not be so easy to modify it by mistake. Right now at least once a week I get myself to edit the wrong file (copy in the Base) and I am that close to drop the idea of using 'edit' on files and just flip readonly instead... So much for complainings, now what I want to know is: 1. Are there any other people with similiar opinion; 2. Are there any people with different opinion; 3. Is there any way to switch off that feature. Thanks in advance, BR, Jerzy The first thing they don't teach you at school: "Never say never". All the issues not related to the list please send to me in private, thanks. __ Get Your Private, Free Email at http://www.hotmail.com
setup problem from a WinCVS user
Hy, I have tryed to install WinCvsServer on WindowsNT and I can not connect to it.I have client 1.1b12.First I have downloaded the binary files from the web site and I had started the server.Then I had installed the client and I try to connect and nothing . How can I set SystemAuth=yes?Please help me. Thanke, Chira Valentin
Setting up CVS password on NT
Hi everybody, I need to set up CVS for accepting user-id and password on NT in the cvs.html its been written as follows: On the server side, the file `/etc/inetd.conf' needs to be edited so inetd knows to run the command cvs pserver when it receives a connection on the right port. By default, the port number is 2401; it would be different if your client were compiled with CVS_AUTH_PORT defined to something else, though. If your inetd allows raw port numbers in `/etc/inetd.conf', then the following (all on a single line in `inetd.conf') should be sufficient: 2401 stream tcp nowait root /usr/local/bin/cvs cvs --allow-root=/usr/cvsroot pserver You could also use the `-T' option to specify a temporary directory. The `--allow-root' option specifies the allowable CVSROOT directory. Clients which attempt to use a different CVSROOT directory will not be allowed to connect. If there is more than one CVSROOT directory which you want to allow, repeat the option. If your inetd wants a symbolic service name instead of a raw port number, then put this in `/etc/services': cvspserver 2401/tcp and put cvspserver instead of 2401 in `inetd.conf'. Once the above is taken care of, restart your inetd, or do whatever is necessary to force it to reread its initialization files. But what's the equivalent of it for NT. Thanx in advance regards narendra
Cannot commit as root
Hello cvs expoerts, If I want to use cvs from my workstation ( and here I am root ) how can I commit then changes to the server? If I am a normal user ... no problem, but if I'm root => error: cannot commit as root. -- Best regards, Marius mailto:[EMAIL PROTECTED]
cvs [commit aborted]: cannot commit files as 'root'
Hello ! I'm a beginner user of CVS and I don't know to resolve this error.I've setup a CVS server (I use SuSE Linux 6.3) and I am always logged as root. I've import a project but I can't commit the work. The error received is : cvs [commit aborted]: cannot commit files as 'root' What should I do ? Thanks ! Crosby
Re: Base directory, in CVS directory
"Win32 M$" schrieb: > Hi All, > > Theory: > ** > Base directory, in CVS directory > Base > > If watches are in use, then an edit command stores the original copy of the > file in the Base directory. This allows the unedit command to operate even > if it is unable to communicate with the server. > ** > > That is a great feature, but the problem is that it is the copy with the > exact same name as an original. Then, if I try to grep for the files > recursively in some directory, I will get the files in the "Base" as well. > More - that files seems to have read-only cleared, so in the end quite often > I will edit it instead of the real file... Very annoying... :( I agree completely: a great feature, but not optimally implemented. I also have had the problem you describe, and I think it will happen again and again if you are not very, very, very careful. The best procedure in the current state would be to exclude the Base directory from the recursive descent you describe, but I doubt if every tool offers this possibility, especially on non-Unix systems. > I think that the file should have different extension (suffix) so it won't > get into the search results AND / OR it should have a read only set, so even > if I get to pick it up with the search it will not be so easy to modify it > by mistake. I think both would be useful: the read only state to prevent accidental modifications and the additional suffix (maybe ",b" ?) to make it easier not to include them into recursive searches. Best regards, Martin
Re: Setting up CVS password on NT
Ñarendra Acharya wrote: > > Hi everybody, > > I need to set up CVS for accepting user-id and password on NT > > in the cvs.html its been written as follows: > On the server side, the file `/etc/inetd.conf' needs to be edited so inetd knows to >run the command cvs pserver when it receives a connection on the right port. By >default, the port number is 2401; it would be different if your client were compiled >with Do you (a) want a Unix server to authenticate from an NT domain controller? AFAIK this would require a PAM-enabled version of CVS, which hasn't been done yet. ..or (b) want to run the server on NT? Download the NT server from http://betty.magenta-logic.com/cvs, and install/run it (see readme.nt). Once it's installed and running as a service it's essentially the same operation as per the standard documentation. Tony -- [EMAIL PROTECTED]
Re: Setting up CVS password on NT
Hi Tony, This seems to be JUST what i wanted!! > > I need to set up CVS for accepting user-id and password on NT > ..or (b) want to run the server on NT? I want to RUN the server on NT!! > Download the NT server from http://betty.magenta-logic.com/cvs, and install/run it >(see readme.nt). Once it's > installed and running as a service it's essentially the same operation as per the >standard documentation. have started downloading the CVS 1.10.8NT patched tar.gz.. thanx a lot for your help regards narendra
Re: setup problem from a WinCVS user
You need to explain your setup a bit better before anyone can even *attempt* to help you. Where is your repository located? How are you attempting to talk to it? What version(s) of cvs are you running? What is the error message(s) that you are receiving? donald On Sun, Mar 05, 2000 at 11:24:39AM +0200, Chira Valentin wrote: > Hy, > > I have tryed to install WinCvsServer on WindowsNT and I can not connect to it.I >have client 1.1b12.First I have downloaded the binary files from the web site and I >had started the server.Then I had installed the client and I try to connect and >nothing . How can I set SystemAuth=yes?Please help me. > > Thanke, > > Chira Valentin
Re: cvs [commit aborted]: cannot commit files as 'root'
Don't run cvs as root. donald On Mon, Apr 03, 2000 at 04:42:47PM +0300, Crosby wrote: > Hello ! > I'm a beginner user of CVS and I don't know to resolve this error.I've > setup a CVS server (I use SuSE Linux 6.3) and I am always logged as root. I've > import a project but I can't commit the work. The error received is : > > cvs [commit aborted]: cannot commit files as 'root' > > What should I do ? > > Thanks ! > > Crosby > >
Re: cvs [commit aborted]: cannot commit files as 'root'
On Monday 3 April 2000, at 16 h 42, the keyboard of Crosby <[EMAIL PROTECTED]> wrote: > I'm a beginner user of CVS and I don't know to resolve this error.I've > setup a CVS server (I use SuSE Linux 6.3) and I am always logged as root. This is certainly one of the most awful errors an Unix user can make.
Re: cvs [commit aborted]: cannot commit files as 'root'
Yes , this is the easyest solution but on my work station I'm always logged as root. The CVS server is working on our local server . I use ssh to access the remote repository.It's possible to make a map On Mon, 03 Apr 2000, you wrote: > Don't run cvs as root. > > donald > On Mon, Apr 03, 2000 at 04:42:47PM +0300, Crosby wrote: > > Hello ! > > I'm a beginner user of CVS and I don't know to resolve this error.I've > > setup a CVS server (I use SuSE Linux 6.3) and I am always logged as root. I've > > import a project but I can't commit the work. The error received is : > > > > cvs [commit aborted]: cannot commit files as 'root' > > > > What should I do ? > > > > Thanks ! > > > > Crosby > > > >
Re: Cannot commit as root
On Tuesday 4 April 2000, at 13 h 50, the keyboard of Marius Oancea <[EMAIL PROTECTED]> wrote: [Why two identical requests from sec.sibnet.ro?] > If I want to use cvs from my workstation ( and here I am root ) You shouldn't.
Re: cvs [commit aborted]: cannot commit files as 'root'
Well to put it bluntly, it's at *best* idiotic to run as root for day to day usage of unix. Your asking for a world of hurt when you do a 'rm -rf /' accidently, or any number of other things that root can do that will *KILL* your system. Change the way you are working. There is a very good reason that cvs doesn't let you commit as root, which is the very same reason that you shouldn't run as root unless you have to. Running as root all the time is like holding a gun to your head, spinning the chambers and then pulling the trigger every time you input a command. You are going to burn yourself ( or at least put a very large hole in your head, metaphorically speaking of course ) donald On Mon, Apr 03, 2000 at 05:58:43PM +0300, Crosby wrote: > Yes , this is the easyest solution but on my work station I'm always > logged as root. The CVS server is working on our local server . I use ssh to > access the remote repository.It's possible to make a map > > On Mon, 03 Apr 2000, you wrote: > > Don't run cvs as root. > > > > donald > > On Mon, Apr 03, 2000 at 04:42:47PM +0300, Crosby wrote: > > > Hello ! > > > I'm a beginner user of CVS and I don't know to resolve this error.I've > > > setup a CVS server (I use SuSE Linux 6.3) and I am always logged as root. I've > > > import a project but I can't commit the work. The error received is : > > > > > > cvs [commit aborted]: cannot commit files as 'root' > > > > > > What should I do ? > > > > > > Thanks ! > > > > > > Crosby > > > > > >
Re: "cvs release" wishlist
I can't help you with the first part of the request, but I have been planning on working the second part. "cvs -Q release -d" will force the removal of everything except when there are files that have been "cvs edit"'ed and modified. Currently, there's no way around the interactiveness of "cvs unedit" (which "cvs release" eventually does). I've been planning on fixing this part of "cvs edit"/"cvs unedit". My proposal is to have "cvs edit" create a backup of the file (via the usual methods) and "cvs unedit" not to unmodify the file. This way, the sole responsibility of "cvs unedit" would be to notify watchers about the action. Of course, I haven't started on this patch yet, but I do expect it to be my next CVS TODO (I might have something within a couple of months). Noel [EMAIL PROTECTED] on 2000.03.31 18:03:06 To: [EMAIL PROTECTED] cc: (bcc: Noel L Yap) Subject: "cvs release" wishlist Greetings! When our build tool recognizes that someone has removed a CVS module from a build area, I had planned to "cvs release -d $module" to remove it from the build area and then do a "make clean" everywhere to make sure I had a clean build area. I was bummed to find out that 'cvs release' doesn't take a module definition, but a DIRECTORY. I would think if I could checkout a module, I would be able to remove a module. Even better, a "-f" option to force the removal even if there are locally-modified files would make this whole thing much more automatable. Does this sound reasonable? Possible? Desirable? :)hal mahaffey
Re: Reserved vs. non-reserved checkout
Concurrent development works great most of the time since: 1. The chances of multiple people modifying the same file at the same time is rare. 2. The chances of multiple people modifying the same place in the same file at the same time is rare. 3. Logical conflicts are handled via communication. "cvs edit", "cvs watch" and family afford a good means of communication. When setup properly, CVS will notify those already editing the file. Note that this notification may be too late for some. There exists a "cvs edit -c" patch that'll check for other editors before allowing the edit. The check can be overridden via "cvs edit -f". Note also that this patch may prevent "cvs edit" from working if the server connection is down (IMHO, "cvs edit -c" should fail if the server connection is down, but "cvs edit" and "cvs edit -f" should work). Noel Enc (See attached file: edit-c.diff) [EMAIL PROTECTED] on 2000.03.31 19:23:29 To: [EMAIL PROTECTED] cc: (bcc: Noel L Yap) Subject: Reserved vs. non-reserved checkout I'm sure that this topic has been covered here before, so if someone wants to point me to a transcript of this issue, feel free. Let me preface, first, with the following comments. I understand that the loosely coordinated, widely distributed development associated with open source projects has a variety of demands that differ from internal, "closed" development projects. My experience is primarily in the latter scenario. I further this (possibly religious) discussion because I want to be enlightened as to the value and advantage of the unreserved checkout scheme promoted by CVS. And to see if those advantages are really appropriate for the closed development projects. I have worked in closed environments for a long time using reserved checkout systems such as MKS, PVCS, and SourceSafe. In this environment, where many people may be working on the same set of files, and often same file; where there are common programming disciplines and guidelines, I have found the reserved checkout scheme more reliable than merging. Merging, in my experience, by developers of a variety of skill levels has allowed hard to find bugs to creep in when conflicts are manually resolved or not detected. We allow simultaneous modification of files, but this was the exception. And branching projects allowed us to maintain older versions of projects while new development continued along the main "trunk." Comments? Bill... I’m sure that this topic has been covered here before, so if someone wants to point me to a transcript of this issue, feel free. Let me preface, first, with the following comments. I understand that the loosely coordinated, widely distributed development associated with open source projects has a variety of demands that differ from internal, "closed" development projects. My experience is primarily in the latter scenario. I further this (possibly religious) discussion because I want to be enlightened as to the value and advantage of the unreserved checkout scheme promoted by CVS. And to see if those advantages are really appropriate for the closed development projects. I have worked in closed environments for a long time using reserved checkout systems such as MKS, PVCS, and SourceSafe. In this environment, where many people may be working on the same set of files, and often same file; where there are common programming disciplines and guidelines, I have found the reserved checkout scheme more reliable than merging. Merging, in my experience, by developers of a variety of skill levels has allowed hard to find bugs to creep in when conflicts are manually resolved or not detected. We allow simultaneous modification of files, but this was the exception. And branching projects allowed us to maintain older versions of projects while new development continued along the main "trunk." Comments? Bill… edit-c.diff
Re: diff does not seem to do -y
I suppose I should have mentioned that the diff was against cvs-1.10.8/src/diff.c
Sorry for any confusion.
reattached for context.
Todd Denniston wrote:
>
> Larry Jones wrote:
> >
> >
> > 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 C&H 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 format GTYPE input groups with GFMT.\n",
+"\t--line-format=LFMT Similar, but format all input lines with LFMT.\n",
+"\t--LTYPE-line-format=LFMT Similar, but format LTYPE input lines with LFMT.\n",
+"\t LTYPE is `old', `new', or `unchanged'. GTYPE is LTYPE or `changed'.\n",
+"\t GFMT may contain:\n",
+"\t%< lines from FILE1\n",
+"\t%> lines from FILE2\n",
+"\t%= lines common to FILE1 and FILE2\n",
+"\t%[-][WIDTH][.[PREC]]{doxX}LETTER printf-style spec for LETTER\n",
+"\t LETTERs are as follows for new group, lower case for old group:\n",
+"\tF first line number\n",
+"\tL last line number\n",
+"\tN number of lines = L-F+1\n",
+"\tE F-1\n",
+"\tM L+1\n",
+"\t LFMT may contain:\n",
+"\t%L contents of line\n",
+"\t%l contents of line, excluding any trailing newline\n",
+"\t%[-][WIDTH][.[PREC]]{doxX}n printf-style spec for input line number\n",
+"\t Either GFMT or LFMT may contain:\n",
+"\t%% %\n",
+"\t%c'C' the singl
RE: "cvs release" wishlist
This is way more than USD 0.02. Most CVS commands take directories and files as arguments (ie "cvs update"). The only exception I know are "cvs checkout" and "cvs export" since there can't be any directories assumed at that point. Noel [EMAIL PROTECTED] on 2000.04.03 02:53:14 To: [EMAIL PROTECTED] cc: (bcc: Noel L Yap) Subject: RE: "cvs release" wishlist > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: 01 April 2000 01:03 > To: [EMAIL PROTECTED] > Subject: "cvs release" wishlist > > > Greetings! > > When our build tool recognizes that someone has removed a CVS > module from a > build area, I had planned to "cvs release -d $module" to > remove it from the > build area and then do a "make clean" everywhere to make sure > I had a clean > build area. > > I was bummed to find out that 'cvs release' doesn't take a > module definition, > but a DIRECTORY. I would think if I could checkout a module, > I would be able > to remove a module. Even better, a "-f" option to force the > removal even if > there are locally-modified files would make this whole thing > much more > automatable. > > Does this sound reasonable? Possible? Desirable? It sounds reasonable, but... What if I have checked out two versions of one module? Say: $ cvs co -d my_prog_v10 -r Version_1_0 myprog $ cvs co myprog There is no link as to what module you want when just saying release module myprog. Just my 2 cents. Guus
Re: cvs [commit aborted]: cannot commit files as 'root'
Dear friends , I use my Linux from a long time and most of time like a root . If you (mr. Donald) give commands which are dangerous for your system is your problem. I know what I'm doing when press Enter after a command. For my question I don't receive a right answer. I don' t think it's a big mistake to make some changes to a project logged as root. I have thinking to a way to map the local user ( root ) to another user on server . Maybe this is possible but nobody give me a solution. Of course the easyest (to login as other user) was in my mind but I look after other solution. Anyway thanks for your (help) ! Crosby On Mon, 03 Apr 2000, you wrote: > Well to put it bluntly, it's at *best* idiotic to run as root for > day to day usage of unix. Your asking for a world of hurt when > you do a 'rm -rf /' accidently, or any number of other things that > root can do that will *KILL* your system. Change the way you are > working. There is a very good reason that cvs doesn't let you commit > as root, which is the very same reason that you shouldn't run as root > unless you have to. Running as root all the time is like holding a > gun to your head, spinning the chambers and then pulling the trigger > every time you input a command. You are going to burn yourself > ( or at least put a very large hole in your head, metaphorically speaking > of course ) > > donald > On Mon, Apr 03, 2000 at 05:58:43PM +0300, Crosby wrote: > > Yes , this is the easyest solution but on my work station I'm always > > logged as root. The CVS server is working on our local server . I use ssh to > > access the remote repository.It's possible to make a map > > > > On Mon, 03 Apr 2000, you wrote: > > > Don't run cvs as root. > > > > > > donald > > > On Mon, Apr 03, 2000 at 04:42:47PM +0300, Crosby wrote: > > > > Hello ! > > > > I'm a beginner user of CVS and I don't know to resolve this error.I've > > > > setup a CVS server (I use SuSE Linux 6.3) and I am always logged as root. I've > > > > import a project but I can't commit the work. The error received is : > > > > > > > > cvs [commit aborted]: cannot commit files as 'root' > > > > > > > > What should I do ? > > > > > > > > Thanks ! > > > > > > > > Crosby > > > > > > > >
Re: Base directory, in CVS directory
Short answer: Use "find ! -path '*/CVS/*'" (if you're using gnu find). Otherwise pipe the output of find through "grep -v '/CVS/' (you might have to backslash the '/'). Long answer: I've come to think that the Base subdirectory is a broken design. 1. The copy stored in Base isn't really the version that was originally checked out, it's the version existing at the time of "cvs edit". 2. "cvs unedit" is interactive due to it's modification check. I propose to: 1. Have "cvs edit" create a backup of the file via the usual means (thereby exposing the backup -- not hiding it within CVS/Base). 2. Have "cvs unedit" solely unedit the file(s) (and perform notifications). "cvs unedit" would no longer unmodify the file(s) -- it would be up to the user to unmodify the file since he/she now knows where the backup is. 3. Get rid of Base (as it'll be unnecessary due to the previous). Noel [EMAIL PROTECTED] on 2000.04.03 17:43:43 To: [EMAIL PROTECTED] cc: (bcc: Noel L Yap) Subject: Base directory, in CVS directory Hi All, Theory: ** Base directory, in CVS directory Base If watches are in use, then an edit command stores the original copy of the file in the Base directory. This allows the unedit command to operate even if it is unable to communicate with the server. ** That is a great feature, but the problem is that it is the copy with the exact same name as an original. Then, if I try to grep for the files recursively in some directory, I will get the files in the "Base" as well. More - that files seems to have read-only cleared, so in the end quite often I will edit it instead of the real file... Very annoying... :( I think that the file should have different extension (suffix) so it won't get into the search results AND / OR it should have a read only set, so even if I get to pick it up with the search it will not be so easy to modify it by mistake. Right now at least once a week I get myself to edit the wrong file (copy in the Base) and I am that close to drop the idea of using 'edit' on files and just flip readonly instead... So much for complainings, now what I want to know is: 1. Are there any other people with similiar opinion; 2. Are there any people with different opinion; 3. Is there any way to switch off that feature. Thanks in advance, BR, Jerzy The first thing they don't teach you at school: "Never say never". All the issues not related to the list please send to me in private, thanks. __ Get Your Private, Free Email at http://www.hotmail.com
Re: cvs [commit aborted]: cannot commit files as 'root'
On Mon, Apr 03, 2000 at 07:40:27PM +0300, Crosby wrote: > Dear friends , > I use my Linux from a long time and most of time like a root . If you > (mr. Donald) give commands which are dangerous for your system is your problem. > I know what I'm doing when press Enter after a command. Obviously you miss the point of *why* you shouldn't run as root on a day to day basis. But it's your computer ;) > For my question I don't receive a right answer. I don' t think it's a There is no right answer. cvs was designed to not allow the root user to do cvs commands. This has to do with the philosophy about why you shouldn't run as root unless you have to. It also goes into the level of trust that you are willing to let one 'root' user have on another machine. If you are so set on running as root go into the source and remove the check to see who you are running as, because obviously you know best In any event you will be running a unsupportable version of the cvs source base donald > big mistake to make some changes to a project logged as root. I have thinking > to a way to map the local user ( root ) to another user on server . Maybe this > is possible but nobody give me a solution. Of course the easyest (to login as > other user) was in my mind but I look after other solution. > Anyway thanks for your (help) ! > > Crosby > > > On Mon, 03 Apr 2000, you wrote: > > Well to put it bluntly, it's at *best* idiotic to run as root for > > day to day usage of unix. Your asking for a world of hurt when > > you do a 'rm -rf /' accidently, or any number of other things that > > root can do that will *KILL* your system. Change the way you are > > working. There is a very good reason that cvs doesn't let you commit > > as root, which is the very same reason that you shouldn't run as root > > unless you have to. Running as root all the time is like holding a > > gun to your head, spinning the chambers and then pulling the trigger > > every time you input a command. You are going to burn yourself > > ( or at least put a very large hole in your head, metaphorically speaking > > of course ) > > > > donald > > On Mon, Apr 03, 2000 at 05:58:43PM +0300, Crosby wrote: > > > Yes , this is the easyest solution but on my work station I'm always > > > logged as root. The CVS server is working on our local server . I use ssh to > > > access the remote repository.It's possible to make a map > > > > > > On Mon, 03 Apr 2000, you wrote: > > > > Don't run cvs as root. > > > > > > > > donald > > > > On Mon, Apr 03, 2000 at 04:42:47PM +0300, Crosby wrote: > > > > > Hello ! > > > > > I'm a beginner user of CVS and I don't know to resolve this error.I've > > > > > setup a CVS server (I use SuSE Linux 6.3) and I am always logged as root. >I've > > > > > import a project but I can't commit the work. The error received is : > > > > > > > > > > cvs [commit aborted]: cannot commit files as 'root' > > > > > > > > > > What should I do ? > > > > > > > > > > Thanks ! > > > > > > > > > > Crosby > > > > > > > > > >
problem
hello, I have a light problem, I get that error message, running pserver: cvs server: cannot open /root/.cvsignore: Permission denied cvs [server aborted]: can't chdir(/root): Permission denied is this a configuration problem? Is this that the cvs process would be running without knowing its CVSROOT? thank you very much, Stan.
Re: cvs [commit aborted]: cannot commit files as 'root'
Crosby writes: > > I use my Linux from a long time and most of time like a root . If you > (mr. Donald) give commands which are dangerous for your system is your problem. > I know what I'm doing when press Enter after a command. If you insist on being stupid (and it's your right to do so), you can edit src/options.h to remove the #define of CVS_BADROOT. -Larry Jones Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us. -- Calvin
RE: Reserved vs. non-reserved checkout
You are using an invalid email address: [EMAIL PROTECTED] which is resolving to someone who does not wish to get this mail. Please take this address out of your mailing lists. Regards, Ruth Ann Hill TI Central Help Desk , Team Lead Email: [EMAIL PROTECTED] 972-575-4071 or pgr 972-648-4548 You can reach the CHD at: 972-575-4357 or 1-800-527-4740 Please visit our website @ http://www1.itg.ti.com/help -Original Message-From: Noel L Yap [mailto:[EMAIL PROTECTED]]Sent: Monday, April 03, 2000 8:15 AMTo: [EMAIL PROTECTED]Cc: [EMAIL PROTECTED]Subject: Re: Reserved vs. non-reserved checkoutConcurrent development works great most of the time since:1. The chances of multiple people modifying the same file at the same time israre.2. The chances of multiple people modifying the same place in the same file atthe same time is rare.3. Logical conflicts are handled via communication."cvs edit", "cvs watch" and family afford a good means of communication. Whensetup properly, CVS will notify those already editing the file.Note that this notification may be too late for some. There exists a "cvs edit-c" patch that'll check for other editors before allowing the edit. The checkcan be overridden via "cvs edit -f". Note also that this patch may prevent "cvsedit" from working if the server connection is down (IMHO, "cvs edit -c" shouldfail if the server connection is down, but "cvs edit" and "cvs edit -f" shouldwork).NoelEnc(See attached file: edit-c.diff)[EMAIL PROTECTED] on 2000.03.31 19:23:29To: [EMAIL PROTECTED]cc: (bcc: Noel L Yap)Subject: Reserved vs. non-reserved checkoutI'm sure that this topic has been covered here before, so if someone wantsto point me to a transcript of this issue, feel free.Let me preface, first, with the following comments. I understand that theloosely coordinated, widely distributed development associated with opensource projects has a variety of demands that differ from internal, "closed"development projects. My experience is primarily in the latter scenario. Ifurther this (possibly religious) discussion because I want to beenlightened as to the value and advantage of the unreserved checkout schemepromoted by CVS. And to see if those advantages are really appropriate forthe closed development projects.I have worked in closed environments for a long time using reserved checkoutsystems such as MKS, PVCS, and SourceSafe. In this environment, where manypeople may be working on the same set of files, and often same file; wherethere are common programming disciplines and guidelines, I have found thereserved checkout scheme more reliable than merging. Merging, in myexperience, by developers of a variety of skill levels has allowed hard tofind bugs to creep in when conflicts are manually resolved or not detected.We allow simultaneous modification of files, but this was the exception. Andbranching projects allowed us to maintain older versions of projects whilenew development continued along the main "trunk."Comments?Bill...
RE: diff does not seem to do -y
You are using an invalid email address: [EMAIL PROTECTED] which is resolving to someone who does not wish to get this mail. Please take this address out of your mailing lists.Regards,Ruth Ann HillTI Central Help Desk , Team Lead Email: [EMAIL PROTECTED]972-575-4071 or pgr 972-648-4548You can reach the CHD at:972-575-4357 or 1-800-527-4740 Please visit our website @ http://www1.itg.ti.com/help-Original Message-From: Todd Denniston [mailto:[EMAIL PROTECTED]]Sent: Monday, April 03, 2000 8:33 AMTo: [EMAIL PROTECTED]Subject: Re: diff does not seem to do -yI suppose I should have mentioned that the diff was against cvs-1.10.8/src/diff.cSorry for any confusion.reattached for context.Todd Denniston wrote:>> Larry Jones wrote:> >> >> > 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 C&H 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)>--
RE: "cvs release" wishlist
You are using an invalid email address: [EMAIL PROTECTED] which is resolving to someone who does not wish to get this mail. Please take this address out of your mailing lists.Regards,Ruth Ann HillTI Central Help Desk , Team Lead Email: [EMAIL PROTECTED]972-575-4071 or pgr 972-648-4548You can reach the CHD at:972-575-4357 or 1-800-527-4740 Please visit our website @ http://www1.itg.ti.com/help-Original Message-From: Noel L Yap [mailto:[EMAIL PROTECTED]]Sent: Monday, April 03, 2000 8:42 AMTo: [EMAIL PROTECTED]Cc: [EMAIL PROTECTED]Subject: RE: "cvs release" wishlistThis is way more than USD 0.02. Most CVS commands take directories and files asarguments (ie "cvs update"). The only exception I know are "cvs checkout" and"cvs export" since there can't be any directories assumed at that point.Noel[EMAIL PROTECTED] on 2000.04.03 02:53:14To: [EMAIL PROTECTED]cc: (bcc: Noel L Yap)Subject: RE: "cvs release" wishlist> -Original Message-> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]> Sent: 01 April 2000 01:03> To: [EMAIL PROTECTED]> Subject: "cvs release" wishlist>>> Greetings!>> When our build tool recognizes that someone has removed a CVS> module from a> build area, I had planned to "cvs release -d $module" to> remove it from the> build area and then do a "make clean" everywhere to make sure> I had a clean> build area.>> I was bummed to find out that 'cvs release' doesn't take a> module definition,> but a DIRECTORY. I would think if I could checkout a module,> I would be able> to remove a module. Even better, a "-f" option to force the> removal even if> there are locally-modified files would make this whole thing> much more> automatable.>> Does this sound reasonable? Possible? Desirable?It sounds reasonable, but...What if I have checked out two versions of one module? Say:$ cvs co -d my_prog_v10 -r Version_1_0 myprog$ cvs co myprogThere is no link as to what module you want when just sayingrelease module myprog.Just my 2 cents.Guus
Re: cvs [commit aborted]: cannot commit files as 'root'
On Monday, April 3, Crosby wrote: > Dear friends , > I use my Linux from a long time and most of time like a root . If you >(mr. Donald) give commands which are dangerous for your system is your problem. >I know what I'm doing when press Enter after a command. > For my question I don't receive a right answer. I don' t think it's a >big mistake to make some changes to a project logged as root. I have thinking >to a way to map the local user ( root ) to another user on server . Maybe this >is possible but nobody give me a solution. Of course the easyest (to login as >other user) was in my mind but I look after other solution. > Anyway thanks for your (help) ! Ok, there is a way. However, I hesitate to show you that way, since you are "root", obviously a power-user, and can't find the method to do so by yourself... Anyhow, using the following method, I've been able to do what you wish: export CVS_RSH=ssh export [EMAIL PROTECTED]:/cvsroot PS: Do you know *WHY* cvs will not let you run things as root? --Toby.
Re: cvs [commit aborted]: cannot commit files as 'root'
On Monday, April 3, Donald Sharp wrote: > > There is no right answer. cvs was designed to not allow the root user > to do cvs commands. This has to do with the philosophy about why you > shouldn't run as root unless you have to. It also goes into the level > of trust that you are willing to let one 'root' user have on another > machine. If you are so set on running as root go into the source and > remove the check to see who you are running as, because obviously you > know best In any event you will be running a unsupportable version > of the cvs source base I may be wrong, but I believe there are other reasons that 'root' is not allowed to use cvs. I believe that they involve locking and such. --Toby.
Re: problem
On Monday, April 3, stanislas pinte wrote: > > I have a light problem, Ok, here. Have a match. :-) > I get that error message, running pserver: > > cvs server: cannot open /root/.cvsignore: Permission denied > cvs [server aborted]: can't chdir(/root): Permission denied > > is this a configuration problem? Is this that the cvs process would be > running without knowing its CVSROOT? > > thank you very much, I believe this is covered in the FAQ. --Toby.
Re: cvs [commit aborted]: cannot commit files as 'root'
on 4/3/00 12:40 PM, Crosby at [EMAIL PROTECTED] wrote: > I use my Linux from a long time and most of time like a root . If you > (mr. Donald) give commands which are dangerous for your system is your > problem. > I know what I'm doing when press Enter after a command. Generally accepted practices, such as not doing normal root as root, are generally accepted for a reason. No matter how smart you are. -- Tracy Snell Orlando Office 21st Century Telecom [EMAIL PROTECTED]
Re: problem
stanislas pinte writes: > > cvs server: cannot open /root/.cvsignore: Permission denied > cvs [server aborted]: can't chdir(/root): Permission denied > > is this a configuration problem? Is this that the cvs process would be > running without knowing its CVSROOT? You need to add a -f global option to the cvs command in inetd.conf. If that doesn't fix the problem, you're probably running Linux where, for some inexplicable reason, processes run by inetd have $HOME set. You'll need to unset $HOME, either by using env to run cvs with a pristene environment or by running a shell script that unsets $HOME and then runs cvs. -Larry Jones Mr. Subtlety drives home another point. -- Calvin
Re: Client-server interaction?
Applix747 writes: > > Is there a description somewhere of what actions CVS exeutes on the > server > and client for various commands? There is some documentation in doc/cvsclient.texi. Otherwise, use the source, Luke. > E.g., for the "update" command, how does CVS decide which client files > differ from server files? Does it require client-server traffic for > each file? The first step is to compare the file's current timestamp with the one stored in the CVS/Entries file. If they're the same, the file is presumed to be unchanged from the version that was checked out and the client simply tells the server that. Otherwise, the client sends the file contents to the server for further processing. > E.g., when updating a client file, what does CVS do? Does it resolve a > series > of "diffs" on a base file stored in the server? Is this slow if the > client > file is many revisions out of date? If the client file is unmodified from a repository revision, the server simply sends the diff between the current client revision and the desired revision. If the file may have been modified, the server does a diff3 of the revision that was checked out, the current client file, and the desired revision and then sends the client a diff (if the file was not, in fact, modified) or a new version. -Larry Jones Apparently I was misinformed. -- Calvin
unedit
Hello, I have some files that ware checked out by a user that is no longer on the system. How can i do cvs unedit to those checked out files ? Iv tried to add that user again to the system (solaris) and to cvs unedit again but with no luck. Any idea ? Thank you.
CVS+Kerberos=Core Dump
I am running cvs 1.10.6 on a Redhat 6.1 system. I installed from the latest RPM that came with Redhat 6.2 and (supposedly) contains Kerberos support. I have Kerberos5 version 1.1.1-9 installed on the same machine and have it set up as a Kerberos KDC. From my workstation (running the same versions of Redhat, CVS, and Kerberos) I can do a 'kinit' to get a kerberos ticket, and when I run "cvs checkout testproject", the kerberos server grants me a ticket for cvs/my.server.net just fine, but then I get the following error followed by a core dump: workstation:asmith:[1:05pm]:~/CVS> cvs checkout testproject cvs: client.c:4140: connect_to_gserver: Assertion `need <= sizeof buf' failed. Abort (core dumped) workstation:asmith:[1:05pm]:~/CVS> My CVSROOT environment variable is set with the :gserver: prefix. Anyone have any ideas on what might be causing this? If I switch my prefix to :pserver: and log in with plain text passwords, CVS works fine. -- Aaron Smith [EMAIL PROTECTED] IT Manager, Change Technology 616.381.9889 ext 17 EoExchange, Inc.http://www.eomonitor.com 3506 Lovers Lane, Second Floor Kalamazoo, MI 49001
Re: cvs [commit aborted]: cannot commit files as 'root'
on 4/3/00 11:44 AM, Tracy Snell at [EMAIL PROTECTED] wrote: > Generally accepted practices, such as not doing normal root as root, are > generally accepted for a reason. No matter how smart you are. s/root as root/tasks as root/ I need more sleep! -- Tracy Snell Orlando Office 21st Century Telecom [EMAIL PROTECTED]
Primate Foraging Units
PRIMATE FORAGING UNITS ... hours of foraging fun! An overwhelming dilemma exists among primates when it comes to providing mental stimuli. No matter how many toys or how much time is spent with a primate or even if the primate is in a natural social group in a large enclosure, natural daily lengthy activity foraging is missing unless the enclosure is large enough to provide daily required nutrition. When we analyze representatives of the order primates, we are dealing with large complex brains, with few exceptions digits and high energy levels. Because of these brilliant facts FAUNA-TEK foraging units offer a new dimension into mental and physical stimuli. Foraging units are complex feeders and in many cases are genus specific. Instead of offering partial or full diets to a primate in a non-challenging food dish, Fauna-Tek foraging units manipulate high volume of complex visual and hidden cavities therefore challenging the foraging behavior in a hygiene and lengthy way. A few weeks ago, the foraging unit 2022 "Lichen" was used with an adult and juvenile snow macaque and a video monitoring was done during early afternoon. That morning the macaques both received their daily monkey biscuits and were to be fed their daily fruit and vegetables later that afternoon. It took 2 minutes to scatter one half cup of unshelled sunflower seeds, 10 peanuts broken into smaller pieces and 100 raisins into the unit. The results were incredible. The two hour video tape revealed 65 minutes foraging and 20 minutes grooming. Of the 400 cavities, 12 of them had food left. It took less then 2 minutes to wash this unit. If the daily diet were to be used and the unit was offered to one primate only, now the foraging time would be extended even more. Fauna-Tek foraging units prolong and challenge this important daily activity, providing much needed stimuli in a natural way and reduces abnormal negative behavior especially when housed single. Since the enclosure which would be called "Territory" in the wild can not provide natural foraging, these foraging units can by bringing these ecosystems to the animals in a synthetic way regardless of the size of the enclosure. Go to http://www.our-pets.net/primateforaging.htm for more information and pictures. We also offer several primate foraging diets and other products in our primate store. Regards, Johan. Primate Store : http://www.our-pets.net/store_primates.htm http://www.our-pets.net/store_primates.htm">Primate Store You received this message because of your interest in primates. If you wish to be removed from this mailing list please REPLY on this message with REMOVE in the SUBJECT line.
Re: unedit
Go into the repository itself. Go to the directory(ies) that the user had edited the files on. There should be a CVS directory with a file called fileattr inside of it. For those files that the user has edited, remove his/her name. Remove everything after the _watched= part of the lines with filename theuser has edited. donald On Mon, Apr 03, 2000 at 06:39:22PM +0200, Moshe Levy wrote: > Hello, > I have some files that ware checked out by a user that is no longer on > the system. > How can i do cvs unedit to those checked out files ? > Iv tried to add that user again to the system (solaris) and to cvs > unedit again but with no luck. > > Any idea ? > > Thank you. >
Re: pserver login error on linux
Michael, I got a lot of feedback about this point. I think the password file should *not* be committed into the CVS repository. Someone recommended I upgrade my CVS version from the version that came with linux (1.10.6) to the latest version (1.10.8) and that solved the problem. Whew! Thanks for your help. -Dave. Michael Bletzinger wrote: > David Katz wrote: > > > > I'm having a devil of a time logging into cvs using pserver. I know > > cvs is working properly. I can use it from the command line to check > > things in and out (just not log in). I think the problem has to do > > with the passwd setup. On Mandrake Linux (a flavor similar to Red > > Hat), the /etc/passwd file using shadowing, so cvs can't read the > > passwords directly from there. > > > > Okay, so we create a CVSROOT/passwd file, right? Sure. I created the > > file and I know cvs is reading it because if I try to log in with a > > fake user name, it tells me: > > > > "no such user cvs in CVSROOT/passwd" > > > > We're making progress. But I've tried so many ways of encrypting a > > password combo and putting it into the passwd file (with salt, without > > salt, using cryptpw-which someone posted on this board, using htpasswd) > > and I always get the same error: > > > > "cvs [login aborted]: recv() from server db.totalcreativeinc.com: EOF" > > > > Aaaargh! > > > > If I try from WinCVS, I get this error: > > > > "cvs [login aborted]: authorization failed: server > > db.totalcreativeinc.com rejected access" > > > > I can't help but think that there's some secret way to populate that > > CVSROOT/passwd file that's going work. Please help! I've seen some > > commentary on whether to actually add the passwd file to CVSROOT using > > cvs, or to not because it could be a security risk. I'd appreciate any > > feedback on that issue as well. > > > > Here is my environment- > > > > $CVSROOT > > /usr/local/cvsroot > > > > $CVSROOT permissions > > user: cvs_root > > group: tci_sf > > > > /etc/inetd.conf > > cvspserver stream tcp nowait root/usr/bin/cvscvs > > --allow-root=/usr/local/cvsroot pserver > > > > /etc/services > > cvspserver 2401/tcp# CVS client/server > > operations > > # Keep only one version of cvspserver running (tcp version > > #cvspserver 2401/udp# CVS client/server > > operations > > > > telnet to db.totalcreativeinc.com:2401 > > Connected to db.totalcreativeinc.com. > > Escape character is '^]'. > > > > cvs [pserver aborted]: bad auth protocol start: > > > > Connection closed by foreign host. > > > > CVSROOT/config > > SystemAuth=no > > > > > CVSROOT/passwd > > Your passwd file is located in /usr/local/cvsroot/CVSROOT right? Note > that the passwd file is not a ",v" file. It is not committed. > > > cvs_root:$1$acZgejPN$G9TuTzvI49woVf9.zJ3YM0 (<-- currently with salt) > > > > login command > > cvs -d :pserver:[EMAIL PROTECTED]:/usr/local/cvsroot > > login > > > > login error > > (Logging in to [EMAIL PROTECTED]) > > CVS password: > > cvs [login aborted]: recv() from server db.totalcreativeinc.com: EOF > > > > Thanks in advance, > > > > David Katz > > [EMAIL PROTECTED] > > Chief Technical Officer > > Total Creative Inc. > > 415-421-9200 x.255 (v) > > 415-421-9222 (f) > > http://www.totalcreativeinc.com -- David Katz Chief Technical Officer Total Creative Inc. 415-421-9200 x.255 (v) 415-421-9222 (f) http://www.totalcreativeinc.com
Re: Cannot commit as root
On Tue, Apr 04, 2000 at 13:50 +0300, Marius Oancea wrote: > Hello cvs expoerts, > If I want to use cvs from my workstation ( and here I am root ) > how can I commit then changes to the server? If I am a normal > user ... no problem, but if I'm root => error: cannot commit as > root. There's something wrong in your enterprise. Go and read some basic doc about how to deal with priviledges! And don't tell your other team members to ask the same question, please :> virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED] -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.
Re: cvs [commit aborted]: cannot commit files as 'root'
On Mon, Apr 03, 2000 at 16:42 +0300, Crosby wrote: > > I'm a beginner user of CVS and I don't know to resolve this > error.I've setup a CVS server (I use SuSE Linux 6.3) and I am > always logged as root. The software is trying to tell you something (and the handbook did so, too -- if you would care to have a look there). DON'T work as root if you're not doing _any_ administrative task. Running X or reading mail or doc or doing development all has nothing to do with "priviledges needed". You shoot into your own foot -- don't do that! > What should I do ? Take the advise to work as a usual user, just like anyone else does. virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED] -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.
Re: CVS 1.10 or 1.10.8
On Fri, 31 Mar 2000, Yarry Gonzalez wrote: > I work for OpenAvenue, the new stewards of CVS. Hmmm, okay, perhaps you can explain what the situation with the stewardship of CVS is. It seems that Cyclic basically got tired of maintaining it, but didn't feel like passing the torch. Then they were bought by SourceGear, who maintains a (slow) web page for it and little else. How did OpenAvenue get passed the stewardship? Or is there no tie in - you're just stepping in to try to push forward your own branch of a project that is barely maintained by its current steward? I'd be interested to hear what plans you and your company have for the future of CVS. Do you plan to do most of the development yourself, taking patches that you like from the developer community? Or do you plan to simply be organizers, making releases and keeping buglists, but leaving most of the actual code-writing to independant developers? If you do plan on doing heavy development yourself, what features or changes do you plan to make to CVS? That is...fundamental design changes, or just optimizations and clean-ups? Adam
Re: Proposed new aliases, like HEAD
Exactly. You still wouldn't have automagic access to back out ANY merge, but you would if you limit yourself to one merge per branch and avoid merging to anything but a branch's parent branch. I guess if CVS remembered that you had just merged into your workspace and asked "Are you committing merge X (-j branchY.tail -j branchZ.head)?" or some such upon commit, the correct tagging could be accomplished almost automagically. Or, maybe, 'cvs ci -t' (t for tag, I don't have a better mnemonic at the moment), always saves the tag upon commit? Hmm, the more I think about this, the more I think I'd be tempted to make "automergetagging" the default behavior. The long way (but I think the way with the least side effects) to accomplish this would be to save the revision numbers of both endpoints of the merge for each affected (not changed, I think, though tagging only changed files should provide the basic functionality I am describing) file somewhere in the metadata upon merging and then tag the start and end points properly upon commit. The quick hack, I think, would be to tag the merge start with "tobranch_merge_N_start_prelim" and create an equivalent "end" tag (perhaps only if the appropriate revisions were untagged already) upon a merge and then patch 'cvs release' to delete the preliminary tags if they haven't been committed. Of course, even quicker would simply be to have CVS tag everything appropriate whenever it sees a '-j' and not even worry whether anything had been committed. Assuming that the majority of merges did get committed, this wouldn't be too messy, but you wouldn't be able to reconstruct for SURE (well, you know :) that such and such a change had been merged & committed. At least, not using the data trail. 'cvs history' could probably then be hacked to provide a list of merges, probably with a branchname filter. Anybody tempted to rip my designs to shreds yet? Always grateful for the input. :) Oh, and I'm not trying to contradict what a few of us have now said about the magic branch functions. These two features should be compatible. Derek R. Price CVS Solutions Architect 303.554.8291 [EMAIL PROTECTED] http://alumni.engin.umich.edu/~oberon/resume.html -- I thought I made a mistake once, but I was wrong. Stephen Rasku wrote: > Derek R. Price wrote: > > >Rather than a bunch of new magic tags, excepting perhaps '.trunk', > allow > >magic functions such as, '.parent', '.tail', and '.head' to be > appended to [snip] > I like this solution. I don't like the fact that you currently have > to tag a branch twice if you ever want to back it out. With this > mechanism, all you would have to do is: > > cvs update -j branch -j branch.tail > > -- > Stephen Rasku E-mail: [EMAIL PROTECTED] > Senior Software EngineerPhone: (604) 872-6676 > TGI TechnologiesWeb:http://www.tgivan.com/
Re: To branch or not?
Assuming *I* understood you correctly, my preferred method is simply to define two modules. I much prefer to reserve branches and tags for revision tracking. so I would define 3 directories inside projectdir: machine1 machine2 common and in the modules file (you may have to double-check my syntax): machine1mod projectdir machine1 common machine2mod projectdir machine2 common Then, assuming I got that syntax correct, when you check out machine1mod, you should get: projectdir/machine1 projectdir/common and for machine2mod: projectdir/machine2 projectdir/common If you play with the module definitions (aliai and ampersands and -d...), you can do some tricky stuff to either put the two modules under different directories to avoid checkout conflicts or (I think) set them up to purposely overlap the common directory if both modules are checked out, but that's more a matter of how you like to work. If you like having the machine 1 and machine 2 code checked out in the same disk space on different branches at the same time you might want to avoid the directory overlap or be aware that you'll have to rename the modules on checkout to make sure each module has the correct version of the common code. The ifdef stuff Michael Gersten mentioned may still be appropriate, but I personally wouldn't try and integrate that with CVS further than storing the information in the right place or maybe using a trigger to write the correct machine.h file on checkout of the module. I suppose Michael's method does have the advantage of condensing to a single step, but a trigger script which used 'uname' or 'ver' or whatever the Windows equivalent of 'umame' is would have the same effect and the user doesn't need to know how the machine they are compiling on relates to CVS. They only need to know their project name. Of course, this method precludes splitting the machine1 and machine2 code between the modules - it relies on a single module and the ifdefs in the code. Derek R. Price CVS Solutions Architect 303.554.8291 [EMAIL PROTECTED] http://alumni.engin.umich.edu/~oberon/resume.html -- This sentance contains threee errors. [EMAIL PROTECTED] wrote: > I need some help to decide whether to use a branch or whether some other method > is more appropriate. > > I'm a relative newcomer to CVS. I am using it to control a project that consists > of two Windows DLLs (I'm working with Microsoft Developer Studio and WinCVS, > with the repository on a UNIX box). Call them main.dll and site.dll. > > main.dll is core code common to all installations of the software. site.dll is > installation-specific. > > I want to know what is the best way to manage this project in CVS. My initial > thought was to create a branch for each different installation. So for the A > site, I would choose the A branch, edit the code for site.dll and rebuild the > project. > > I hit an immediate snag when CVS didn't appear to allow me to specify which > files were to be in the branch. Further reading made me think that perhaps this > is not what branches are intended for. A branch appears to be a way of creating > a copy of an entire project isolated from the main trunk, which at a later date > might merge back with the main trunk. I want to separate off a couple of files > from the project and make several different versions of these files, the > versions being related as brothers rather than as father, son, grandson, and > then choose which version I have checked out along with the common code so I can > build the appropriate version of site.dll. > > Everything is in one module at present. Would I be better off if I had put the > DLLs in separate modules? If so, what would I do with the source files that are > common to both DLLs? If I need to split this into two modules, can I do this > easily without losing the version histories? > > I would be very grateful for all suggestions that I receive. > > Ian Goldby > > ** > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please notify > the system manager. > > This footnote also confirms that this email message has been swept > for the presence of computer viruses. > > Power Technology Centre, Ratcliffe-on-Soar, > Nottingham, NG11 0EE, UK > Tel: +44 (0)115 936 2000 > http://www.powertech.co.uk > **
Re: "cvs release" wishlist
Hmm... doesn't that mean that: cvs edit myfile.h [change myfile.h] cvs unedit myfile.h cvs ci -mtest myfile.h Would cause changes to be checked in? Derek R. Price CVS Solutions Architect 303.554.8291 [EMAIL PROTECTED] http://alumni.engin.umich.edu/~oberon/resume.html -- You can lead a horticulture, but you can't make her think. -- Janis Joplin, when asked to use the word "horticulture" in a sentence Noel L Yap wrote: > I can't help you with the first part of the request, but I have been planning on > working the second part. > > "cvs -Q release -d" will force the removal of everything except when there are > files that have been "cvs edit"'ed and modified. Currently, there's no way > around the interactiveness of "cvs unedit" (which "cvs release" eventually > does). I've been planning on fixing this part of "cvs edit"/"cvs unedit". My > proposal is to have "cvs edit" create a backup of the file (via the usual > methods) and "cvs unedit" not to unmodify the file. This way, the sole > responsibility of "cvs unedit" would be to notify watchers about the action. > > Of course, I haven't started on this patch yet, but I do expect it to be my next > CVS TODO (I might have something within a couple of months). > > Noel > > [EMAIL PROTECTED] on 2000.03.31 18:03:06 > > To: [EMAIL PROTECTED] > cc: (bcc: Noel L Yap) > Subject: "cvs release" wishlist > > Greetings! > > When our build tool recognizes that someone has removed a CVS module from a > build area, I had planned to "cvs release -d $module" to remove it from the > build area and then do a "make clean" everywhere to make sure I had a clean > build area. > > I was bummed to find out that 'cvs release' doesn't take a module definition, > but a DIRECTORY. I would think if I could checkout a module, I would be able > to remove a module. Even better, a "-f" option to force the removal even if > there are locally-modified files would make this whole thing much more > automatable. > > Does this sound reasonable? Possible? Desirable? > > :)hal mahaffey
Re: CVS+Kerberos=Core Dump
Under remote repositories in the Cederqvist, Kerberos authentication mode is specified by kserver, not gserver. Derek R. Price CVS Solutions Architect 303.554.8291 [EMAIL PROTECTED] http://alumni.engin.umich.edu/~oberon/resume.html -- Bah, humbug. -- Ebeneezer Scrooge Aaron Smith wrote: > I am running cvs 1.10.6 on a Redhat 6.1 system. I installed from the > latest RPM that came with Redhat 6.2 and (supposedly) contains Kerberos > support. I have Kerberos5 version 1.1.1-9 installed on the same machine and > have it set up as a Kerberos KDC. From my workstation (running the same > versions of Redhat, CVS, and Kerberos) I can do a 'kinit' to get a kerberos > ticket, and when I run "cvs checkout testproject", the kerberos server > grants me a ticket for cvs/my.server.net just fine, but then I get the following > error followed by a core dump: > > workstation:asmith:[1:05pm]:~/CVS> cvs checkout testproject > cvs: client.c:4140: connect_to_gserver: Assertion `need <= sizeof buf' failed. > Abort (core dumped) > workstation:asmith:[1:05pm]:~/CVS> > > My CVSROOT environment variable is set with the :gserver: > prefix. Anyone have any ideas on what might be causing this? If > I switch my prefix to :pserver: and log in with plain text passwords, > CVS works fine. > > -- > > Aaron Smith [EMAIL PROTECTED] > IT Manager, Change Technology 616.381.9889 ext 17 > EoExchange, Inc.http://www.eomonitor.com > 3506 Lovers Lane, Second Floor Kalamazoo, MI 49001
Re: cvs [commit aborted]: cannot commit files as 'root'
I think it was the smart ones that came up with the general practices. Noel [EMAIL PROTECTED] on 2000.04.03 11:44:28 To: [EMAIL PROTECTED], [EMAIL PROTECTED] cc: [EMAIL PROTECTED] (bcc: Noel L Yap) Subject: Re: cvs [commit aborted]: cannot commit files as 'root' on 4/3/00 12:40 PM, Crosby at [EMAIL PROTECTED] wrote: > I use my Linux from a long time and most of time like a root . If you > (mr. Donald) give commands which are dangerous for your system is your > problem. > I know what I'm doing when press Enter after a command. Generally accepted practices, such as not doing normal root as root, are generally accepted for a reason. No matter how smart you are. -- Tracy Snell Orlando Office 21st Century Telecom [EMAIL PROTECTED]
unsubscribe
unsubscribe Shhh. Let me know if this works. The missing account should receive an acknowledgment message. Derek R. Price CVS Solutions Architect 303.554.8291 [EMAIL PROTECTED] http://alumni.engin.umich.edu/~oberon/resume.html
multiple edits per user per file (Was: CVS bug?)
Yes, IMO this is a bug. The original implementor didn't know how to get edits (or, more precisely unedits upon commit) to work properly when the same editor edits the same file within more than one working directory. I'm working on fixing this. I should have something posted by the end of the week (it would've been out last week, but I've been out sick the last few days). Noel PS For those interested, the difficulty was that, on client/server by commit time, there was no way to know what the location (ie hostname and working directory) of the file was. So, if edits were stored as "user@hostname:/working_dir", unedits would work fine, but uneditting upon commit wouldn't. [EMAIL PROTECTED] on 2000.04.03 13:53:39 To: [EMAIL PROTECTED] cc: [EMAIL PROTECTED] Subject: CVS bug? Noel, I noticed in the cvs newsgroups that you have responded to a number of the cvs issues relegated to the editors and watch features. I'm trying to figure out if I've stumbled across a bug or if my usage model is incorrect. > We're using CVS version 1.10.7 and we're using the editors and watch > features. So we've done a "cvs watch on" on all of the files and everytime > someone wants to edit a file, they do a "cvs edit " first. That > way the "cvs editors" command can be used to see who else might be editing > the same file. > > Right now, we're having troubles with CVS losing the editors information. > I've been able to duplicate the problem using WinCVS and the command line > version of CVS. The following scenario duplicates the problem: > > mkdir foo1 > cd foo1 > cvs checkout scripts > cd scripts > cvs edit foo.pl > cvs editors <-- indicates that foo.pl is currently being edited. mkdir > foo2 > > mkdir foo2 > cd foo2 > cvs checkout scripts > cd scripts > cvs editors <-- indicates that foo.pl is currently NOT being edited. > > I looked at the fileattr file in the repository before and after the > checkout was done in the foo2 area and it appears that the watch > information is being blown away from inside that file. > Does this sound like a bug? > Thanks. > > Rob >
Re: unedit
Short answer: 0. Read the specs for CVS/fileattr and keep it handy. 1. Go into the repository and edit the corresponding CVS/fileattr file. Long answer: 1. Install the "cvs unedit -e" patch which will allow you to specify the editor you wish to unedit. This patch also includes the "cvs edit -c" patch and some other minor ones: 1. "rm file; cvs up file" won't unedit the file. 2. Bug fix to have "cvs edit" save the correct working directory. Noel Enc (See attached file: unedit-e.diff) [EMAIL PROTECTED] on 2000.04.03 12:39:22 Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: (bcc: Noel L Yap) Subject: unedit Hello, I have some files that ware checked out by a user that is no longer on the system. How can i do cvs unedit to those checked out files ? Iv tried to add that user again to the system (solaris) and to cvs unedit again but with no luck. Any idea ? Thank you. unedit-e.diff
Re: unedit
Note that this procedure could wipe out others' edits (that's why I said to read the specs) so be careful. Noel [EMAIL PROTECTED] on 2000.04.03 14:44:42 To: [EMAIL PROTECTED] cc: [EMAIL PROTECTED] (bcc: Noel L Yap) Subject: Re: unedit Go into the repository itself. Go to the directory(ies) that the user had edited the files on. There should be a CVS directory with a file called fileattr inside of it. For those files that the user has edited, remove his/her name. Remove everything after the _watched= part of the lines with filename theuser has edited. donald On Mon, Apr 03, 2000 at 06:39:22PM +0200, Moshe Levy wrote: > Hello, > I have some files that ware checked out by a user that is no longer on > the system. > How can i do cvs unedit to those checked out files ? > Iv tried to add that user again to the system (solaris) and to cvs > unedit again but with no luck. > > Any idea ? > > Thank you. >
Re: "cvs release" wishlist
Oh yeah, another view (ie reply) to your question would be: "cvs edit" and family is meant to be part of a communication medium. "cvs edit" tells others you are modifying the file and you plan to commit those modification. "cvs unedit" tells others you've changed your mind and you'll no longer commit those modification (if any). Also, I do plan to make yet another patch, "cvs ci -c", that'll check whether the committer has valid edits on the files to be committed before going through with the commit. So, in your scenario, if the user did "cvs ci -c -mtest myfile.h", the commit would abort (of course, for optimal performance the user really should have "commit -c" in his/her .cvsrc file). Noel [EMAIL PROTECTED] on 2000.04.03 20:18:31 To: [EMAIL PROTECTED] cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: "cvs release" wishlist Hmm... doesn't that mean that: cvs edit myfile.h [change myfile.h] cvs unedit myfile.h cvs ci -mtest myfile.h Would cause changes to be checked in? Derek R. Price CVS Solutions Architect 303.554.8291 [EMAIL PROTECTED] http://alumni.engin.umich.edu/~oberon/resume.html -- You can lead a horticulture, but you can't make her think. -- Janis Joplin, when asked to use the word "horticulture" in a sentence Noel L Yap wrote: > I can't help you with the first part of the request, but I have been planning on > working the second part. > > "cvs -Q release -d" will force the removal of everything except when there are > files that have been "cvs edit"'ed and modified. Currently, there's no way > around the interactiveness of "cvs unedit" (which "cvs release" eventually > does). I've been planning on fixing this part of "cvs edit"/"cvs unedit". My > proposal is to have "cvs edit" create a backup of the file (via the usual > methods) and "cvs unedit" not to unmodify the file. This way, the sole > responsibility of "cvs unedit" would be to notify watchers about the action. > > Of course, I haven't started on this patch yet, but I do expect it to be my next > CVS TODO (I might have something within a couple of months). > > Noel > > [EMAIL PROTECTED] on 2000.03.31 18:03:06 > > To: [EMAIL PROTECTED] > cc: (bcc: Noel L Yap) > Subject: "cvs release" wishlist > > Greetings! > > When our build tool recognizes that someone has removed a CVS module from a > build area, I had planned to "cvs release -d $module" to remove it from the > build area and then do a "make clean" everywhere to make sure I had a clean > build area. > > I was bummed to find out that 'cvs release' doesn't take a module definition, > but a DIRECTORY. I would think if I could checkout a module, I would be able > to remove a module. Even better, a "-f" option to force the removal even if > there are locally-modified files would make this whole thing much more > automatable. > > Does this sound reasonable? Possible? Desirable? > > :)hal mahaffey
Re: "cvs release" wishlist
Yeah, what's wrong with that? With cvs-1.10.8, "cvs update -C" will give you a clean copy of the file provided you don't run into any of the merge bugs. If you do run into those bugs, you can always revert back to the standard "cvs up -r file >file" to get a clean copy. Yes, it'll now be two separate steps (one to clean the file, one to unedit the file). The alternative is to make "cvs unedit" interface more complicated by giving it three more options (one to check for modification, one to force the unedit without unmodifying, and one to unedit and unmodify the file). If you don't like the two step deal, you can always write a wrapper around cvs, but, as of now, there is absolutely no way (without manually going into the admin files or kludging a way (eg "cvs edit" the file again)) to unedit a file and keep all modifications. Noel [EMAIL PROTECTED] on 2000.04.03 20:18:31 To: [EMAIL PROTECTED] cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: "cvs release" wishlist Hmm... doesn't that mean that: cvs edit myfile.h [change myfile.h] cvs unedit myfile.h cvs ci -mtest myfile.h Would cause changes to be checked in? Derek R. Price CVS Solutions Architect 303.554.8291 [EMAIL PROTECTED] http://alumni.engin.umich.edu/~oberon/resume.html -- You can lead a horticulture, but you can't make her think. -- Janis Joplin, when asked to use the word "horticulture" in a sentence Noel L Yap wrote: > I can't help you with the first part of the request, but I have been planning on > working the second part. > > "cvs -Q release -d" will force the removal of everything except when there are > files that have been "cvs edit"'ed and modified. Currently, there's no way > around the interactiveness of "cvs unedit" (which "cvs release" eventually > does). I've been planning on fixing this part of "cvs edit"/"cvs unedit". My > proposal is to have "cvs edit" create a backup of the file (via the usual > methods) and "cvs unedit" not to unmodify the file. This way, the sole > responsibility of "cvs unedit" would be to notify watchers about the action. > > Of course, I haven't started on this patch yet, but I do expect it to be my next > CVS TODO (I might have something within a couple of months). > > Noel > > [EMAIL PROTECTED] on 2000.03.31 18:03:06 > > To: [EMAIL PROTECTED] > cc: (bcc: Noel L Yap) > Subject: "cvs release" wishlist > > Greetings! > > When our build tool recognizes that someone has removed a CVS module from a > build area, I had planned to "cvs release -d $module" to remove it from the > build area and then do a "make clean" everywhere to make sure I had a clean > build area. > > I was bummed to find out that 'cvs release' doesn't take a module definition, > but a DIRECTORY. I would think if I could checkout a module, I would be able > to remove a module. Even better, a "-f" option to force the removal even if > there are locally-modified files would make this whole thing much more > automatable. > > Does this sound reasonable? Possible? Desirable? > > :)hal mahaffey
RE: readers file not working
> > | Bug Report > | -- > | > | Reported By: Stephen Rasku > | Module: > | Version: CVS 1.10.7 (using pserver) > | OS:Solaris 7 (sparc) > | Description: > | > | The readers file isn't working for me. Here's the readers file: > >I test with Solaris 2.6 (sparc) as server >and FreeBSD 3.3 (i386) as client. >It seems CVSROOT/readers works. > >server% cat readers >koie >server% > >client% cvs ci -m "" FILE >cvs [server aborted]: "commit" requires write access to the repository >client% > >Does the file readers contain extra space chars at end of line? > I found out what the problem was. I was trying to commit from my repository so it was using my CVSROOT variable instead of tgx's. -- Stephen Rasku E-mail: [EMAIL PROTECTED] Senior Software EngineerPhone: (604) 872-6676 TGI TechnologiesWeb:http://www.tgivan.com/
RE: readers file not working
From: Stephen Rasku <[EMAIL PROTECTED]> Subject: readers file not working Date: Sat, 1 Apr 2000 06:31:00 +0900 (JST) | Bug Report | -- | | Reported By:Stephen Rasku | Module: | Version:CVS 1.10.7 (using pserver) | OS: Solaris 7 (sparc) | Description: | | The readers file isn't working for me. Here's the readers file: I test with Solaris 2.6 (sparc) as server and FreeBSD 3.3 (i386) as client. It seems CVSROOT/readers works. server% cat readers koie server% client% cvs ci -m "" FILE cvs [server aborted]: "commit" requires write access to the repository client% Does the file readers contain extra space chars at end of line? -- KOIE Hidetaka <[EMAIL PROTECTED]>
