Re: External diff program in WinCVS - how does it work?
Hi Mark, when starting the diff you get the "diff settings" window. You have to check the checkbox "use the external diff". Then it will work. Michael -- Dipl.-Math. Michael Lukaschek, Software Development Interzart AG 3D Commerce / Dimension 3D-Systems GmbH Phone: +49-511 390884-0 Fax: +49-511 390884-10 mailto:[EMAIL PROTECTED] http://www.dimension-3d.com Mark O'Brien schrieb: Hi all, I have a external graphical diff program (tkdiff.tcl) that I have set up WinCVS to work with (via preferences). I can run tkdiff.tcl by it self and it runs fine, however WinCVS does seem to recognize I have added it to the preferences. How does the external diff program work (or not work) in WinCVS? Running WinCVS 1.0.6 on Win 2K, repository on Solaris. Thanks all, Mark ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs Kryptographische Unterschrift mit S/MIME
Permision needed with CVS
Hi, I am using the command line client of CVS on my windows NT4.0 computer with directory. Every thing work fine if I don't have any conflict, but when I try ro update a file that is also localy modified, I systematicly have the following error : retrieving revision 1.2 retrieving revision 1.2.4.1 Merging differences between 1.2 and 1.2.4.1 into general.conf cvs update: could not open output file: Permission denied cvs update: subsidiary diff failed Unfortunatly, the error message doesn't specify in which directory the output file is created. Anybody would know? Thanks P.S. Please respond by email, I am not a member of the mailing list. -- Guillaume Cot [EMAIL PROTECTED] phone : +33.1.41.09.99.70 fax : +33.1.55.95.00.11 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Tag not logged.
Hi ppl ! I'v stumbled upon some weird thing. When I tag some file with 'tag -b' it doesn't get logged into history file, is it the way things should be ? Btw, rtag is logged into history. I use CVS 1.10.7 on Solaris 7. Maybe I missed smth in configuration or options ? Thanks in advance. Grigoriy Kuznetsov Compass Plus, RTS Department. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Problem with checkout
Hi I am relatively new to using cvs and setting it up. I followed the docs on the cvshome.org website and have the cvs setup and working. THe only thing is that when I checkout a tree from the cvs repository all the files permissions are read only and yet I have read/write access to the files. If I manually change the permissions then I can edit the files and commit them back. The questions is could this be a config option I left out or maybe something to do with the permissions on the cvsroot directory. At the moment the directory is owned by cvs.cvs and the permissions 770 Is this ok? I set myself as a member of this group thus being able to access the files. Thanks any help would be greatly appreciated Cheer Sean ~~~ Sean Preston [EMAIL PROTECTED] GNU/Linux, the OS of choice ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Reimporting vendor projects where items have been deleted
Nathan Herring wrote: Larry writes: How is import supposed to know to do that, though? Import knows the name and branch version of the vendor branch, has a list of files to import, and has a list of files already in the repository. This is all it needs to know. Now use the following heuristic: Yeah. Basically, import would have to look up the tip of the vendor branch before execution to obtain the list of files present during the last import. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- Re: Graphics A picture is worth 10k words, but only if the words describe the picture. Very few arbitrary sets of 10k words can be adequately replaced with a picture. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: feature question
Sasa Brcerevic wrote: Why did not 'edit -c' make it to the cvs 1.11 and yet it is on the windows version of cvs 1.10.8? Most likely you were using a patched version of 1.10.8. The answer to the more general question of why 'edit -c' isn't in cvs 1.11 has to do with the lack of some of the supporting cruft, including documentation and test suite cases. Noel Yap has, in fact, been looking for volunteers to produce those. If you're interested in assisting, you should search the info-cvs list for the recent thread or just tell Noel. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- I will never win an emmy. I will never win an emmy. I will never win an emmy... - Bart Simpson on chalkboard, _The Simpsons_ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
different access control to different users!
Have any idea about how t o apply the patch for gicving access to various users with different permisssions? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Permision needed with CVS
Guillaume Cot wrote: I am using the command line client of CVS on my windows NT4.0 computer with directory. Every thing work fine if I don't have any conflict, but when I try ro update a file that is also localy modified, I systematicly have the following error : retrieving revision 1.2 retrieving revision 1.2.4.1 Merging differences between 1.2 and 1.2.4.1 into general.conf cvs update: could not open output file: Permission denied cvs update: subsidiary diff failed Unfortunatly, the error message doesn't specify in which directory the output file is created. Anybody would know? What version of the client and server are you using (send me the output of 'cvs version')? I can't find the error message you mention in the current source. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- I will not spank others. I will not spank others. I will not spank others... - Bart Simpson on chalkboard, _The Simpsons_ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: feature question
Are you sure you're not using a Windows version that's been patched? Noel [EMAIL PROTECTED] on 2001.03.23 01:39:59 To: [EMAIL PROTECTED] cc: (bcc: Noel L Yap) Subject: feature question Clear DayWhy did not 'edit -c' make it to the cvs 1.11 and yet it is on the windows version of cvs 1.10.8? have a day, Sasa == Sasa Brcerevic Technology Partners Group Phone: +61 1800 155 577 Direct: +61 (02) 4925 1535 Mobile: +61 (0416) 297 442 Email: [EMAIL PROTECTED] WWW: www.technologypartnersgroup.com == Title: Clear Day Why did not 'edit -c' make it to the cvs 1.11 and yet it is on the windows version of cvs 1.10.8? have a day, Sasa ==Sasa Brcerevic Technology Partners Group Phone: +61 1800 155 577Direct: +61 (02) 4925 1535Mobile: +61 (0416) 297 442Email: [EMAIL PROTECTED]WWW: www.technologypartnersgroup.com==
'newbie' here, having a problem with check-out
Good morning, 'newbie' here, so be kind. This is what I've done so far: 1. installed CVS on my local machine and went thru the import, checkout, commit drill...everything works well... 2. again, running CVS from the command line, I was able to connect my local machine to my file-server using pserver...again everything worked well... 3. installed WinCvs on my local machine and everything, yet once again, ran aok... 4. used WinCvs on my local machine and connected to my file-server using pserver...this is where I ran into a problem...it was: 4.1 imported from my local machine a directory c:/docs with 2 sub-directories each of which contained two binary (Word and Excel) files, 4.2 deleted c:/docs... 4.3 checked out docs from the repository... 4.4 committed the c:/docs directory... 4.5 at this point, everything is working fine... 4.6 tried to check out docs from the repository and got the msg: "...*PANIC* adminstration files missing...", 4.7 this, according to the manual, indicates a bad CVS file... 4.8 I deleted the CVS files from the c:/docs directories and tried to check out again -- no luck, get the same error msg. 4.9 However, I can check out each of the files individually. I'd appreciate any help. Thanks, Pat ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: different access control to different users patch problem.
I've never used this patch before, so take the following advice with a grain of salt: [EMAIL PROTECTED] wrote: 1)I have down loaded the cvs1.11 in to Unix. Is this the version the patch was originally created from? If not you can expect to do a bit of porting. 3) Now we tried to apply the patch( using 'patch -i patchname ) to 'src' durectory inder cvs-1.11 and it gives some error saying that linking files are missing ( which are there in doc directory. 4) so we went to 'doc' directory and tried to apply the patch again using the same command. it gives error by saying 'missing some files' which we found in src directory. 5) So we merged both the directories 'doc' and 'src'. And now tried to compile using make. Merging directories shouldn't be necessary. Most likely you are running patch from the wrong location or stripping the wrong number of path elements. Read the patch file itself (the man page for patch shouldn't hurt either) and look at the file names it is looking for. If there are path elements you can't duplicate (e.g. ccvs-orig ccvs-final), they should be 'stripped' using the -pN option to patch. Use the remainder of the paths to figure out where you should be running patch from. i.e. make sure that after any elements are stripped, the relative paths remaining point to files. You should have something left like src/foo.c, src/bar.c, doc/cvs.texinfo and this would mean patch should be run from the parent directory of src doc. 6) Almost all files are successfully compiled butat the end it faild with the following error? Undefined first referenced symbol in file change_permsadd.o verify_read checkout.o passwd main.o change_owneradd.o local_security add.o deluser main.o verify_adminadmin.o chacl main.o verify_writecommit.o adduser main.o lsacl main.o verify_create add.o ld: fatal: Symbol referencing errors. No output written to cvs collect2: ld returned 1 exit status Versions of CVS prior to the current dev version created patches that always put newly added files in '.' rather than where they should be. It's possible that this happend and there is a new file containing these functions in '.' (rather than 'src' or the like) that never got compiled, but if your patch made the correct changes to src/Makefile then I don't know why you didn't run into a missing file error earlier. Of course, the new file may have been compiled and just not added to the linking line. Try grepping all *.c files for the missing functions or search the patch file for the segment(s) which should have added these functions. Hope this helped. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- I will not conduct my own fire drills. I will not conduct my own fire drills. I will not conduct my own fire drills... - Bart Simpson on chalkboard, _The Simpsons_ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs commit error
Hello folks, So I'm getting this error when I try to checkin/commit any of the files in a particular tree. Anyone have a clue what this is about? cvs [ commit aborted] could not open lock file '.../Server.java,' Permission Denied. Now, I have the right permission, I know that. Thanks, Saima ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Problem with checkout
Sean Preston wrote: thing is that when I checkout a tree from the cvs repository all the files permissions are read only and yet I have read/write access to the files. If I manually change the permissions then I can edit the files and commit them back. Are the files being watched (look up the 'watch' command in the CVS manual if you don't understand this)? Is your CVSREAD variable set? Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- G: "If we do happen to step on a mine, Sir, what do we do?" EB: "Normal procedure, Lieutenant, is to jump 200 feet in the air and scatter oneself over a wide area." -- Somewhere in No Man's Land, BA4 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs edit/unedit
Hi, I have been trying the cvs watch/edit/unedit commands and related feature, and I came accros the following problem: I can't see how I could notify a user on a watchers list of the type of the command that another user has executed, if the 1st user has chosen "cvs watch add -a all file"? I mean, normally this is done through CVSROOT/notify on a line like ALL echo %s some_file but %s contains only the list of the "watching" users. Is there any solution, apart that the user specifically says "cvs watch add -a cmd" to know that the cmd has been executed... Also, is there a possibility to get the name of the file which have been modified, without explicitely listing all the files in CVSROOT/notify? I mean, by using only the "ALL ..." line above. Thanks for any suggestions, Irina. I forgot: I am using CVS 1.11 on unix. -- === Irina STURM Functional Verification Center of Competence - CMG STMicroelectronics, 9 chem de la Dhuy, 38240 MEYLAN, FRANCE Phone: (+33) (0)4 76 58 68 90, Fax: (+33) (0)4 76 58 40 11 E-MAIL: [EMAIL PROTECTED] === ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs commit error
Saima Iqbal wrote: So I'm getting this error when I try to checkin/commit any of the files in a particular tree. Anyone have a clue what this is about? cvs [ commit aborted] could not open lock file '.../Server.java,' Permission Denied. Now, I have the right permission, I know that. I'm going with most likely, you don't. If the actual name reported for the lock file above was something like ',Server.java,' then this may mean you simply don't have the needed write permissions to the directory even though you have write permissions for the lock directory, which allowed you to check out. Sometimes this can happen if a new directory was created by someone else whose default group isn't one you're a member of and the setgid bit hasn't been set on the directory. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- Thousands of years ago, cats were worshipped as gods. Cats have never forgotten this. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
update -p on removed files.
Hello. I'm writing the javacvs module in netbeans IDE. I encountered the following problem. When performing a visual diff for 2 old revisions of a file. eg. diff -r 1.1 -r 1.2 Client.java (checked out in version 1.5) to obtain the right revision I perform cvs update -p -r 1.1 to get one of the revisions being compared. This works just fine, except the case when the file was locally removed. Then the server returns this line: E cvs server: conflict: removed javacvs/libsrc/org/netbeans/lib/cvsclient/Client.java was modified by second party I can't understand that, because the update -r 1.1 file command (without the -p switch) works. The only way to get the older revision is the checkout command with the same switches.. however that has one major disadvantage.. you need to know the whole repository path to the file, which is a non-trivial task to perform. Is this intended behaviour or a bug? Thank you very much.. Milos Kleint PS: (using the NT cvs server) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
When trying to merge a file
I have cvs 1.11. When trying to merge a file from a branch to the main trunk, being on the main trun working directory and typing cvs up -j VCR_BRANCH pnt.h I get this: cvs server: file pnt.h exists, but has been added in revision VCR_BRANCH. Does that mean that the file was merged, or what? Thanks for help -- Horia Ioanid Niksun, Inc. http://www.niksun.com 111 North Center Drive, North Brunswick, NJ 08902-4909, USA (732)821-5000/227 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Permision needed with CVS
Guillaume Cot wrote: What version of the client and server are you using (send me the output of 'cvs version')? I can't find the error message you mention in the current source. There it is : Concurrent Versions System (CVS) 1.10.5 (client) Copyright (c) 1989-1998 Brian Berliner, david d `zoo' zuhn, Jeff Polk, and other authors CVS may be copied only under the terms of the GNU General Public License, a copy of which can be found with the CVS distribution kit. Specify the --help option for further information about CVS I actually did want the output of 'cvs version' and not 'cvs --version' as the former reports the server version too, but maybe that didn't work until 1.11? A quick glance at the logs seems to imply this is the case. Sorry. Maybe the message doesn't came directly from cvs, but from a external program cvs use to merge files. If it's that case, send me the name of the programs and the parameter it's using. It's also possible that the message has simply been changed. Many bugs have been fixed since 1.10.5. If you can't figure out what is wrong you might try upgrading your client and maybe your server. 1.11 Binaries for NT and other OSes are available on CVSHome.org. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- Elsa, I'm no good at being noble but it doesn't take much to see that the problems of three little people doesn't amount to a hill of beans in this crazy world. Someday you'll understand that. - Humphrey Bogart as Rick, _Casablanca_ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Unable to Checkout Module
Title: Unable to Checkout Module Hello Everyone, I am unable to check out a module from my cvs server.. I am getting the error: cvs [server aborted]: can't chdir(): No such file or directory I am using these commands: cvs -qd :pserver:[EMAIL PROTECTED]:/home/sourcecontrol/TASS co -lp timesheet cvs -d :pserver:[EMAIL PROTECTED]:/home/sourcecontrol/TASS -z3 co -d untitled1 timesheet Can anyone explain why this is occurring and how to fix it? Thanks, Peter
Re: Unable to Checkout Module
Peter Salama writes:
I am unable to check out a module from my cvs server.. I am
getting the error:
cvs [server aborted]: can't chdir(""): No such
file or directory
Most likely your server has $HOME set to "". It should not be set at
all.
-Larry Jones
Hey! What's the matter? Can't you take a joke?! It was a JOKE! -- Calvin
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Unable to Checkout Module
Title: RE: Unable to Checkout Module Larry, Thanks for getting back to me.. When I run set HOME is set to my login path so I went ahead and unset it and then ran the command with still the same error... Any other suggestions or comments? I may be doing it wrong and if so please advise.. Thanks, Peter Salama -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, March 23, 2001 9:25 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Unable to Checkout Module Peter Salama writes: I am unable to check out a module from my cvs server.. I am getting the error: cvs [server aborted]: can't chdir(): No such file or directory Most likely your server has $HOME set to . It should not be set at all. -Larry Jones Hey! What's the matter? Can't you take a joke?! It was a JOKE! -- Calvin
HELP! I can't access pserver
I have a project on the CVS server that has been running fine. I wanted to add another separate project and added another --allow-root statement into the inetd.conf file now when I try to access the server I get: cvs [login aborted]: unrecognized auth response from cvsrepo: Usage: cvs [cv s-options] command [command-options-and-arguments] What is the proper syntax for allowing access to more than one repository via the pserver? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: HELP! I can't access pserver
"Largent, Jim" wrote: I have a project on the CVS server that has been running fine. I wanted to add another separate project and added another --allow-root statement into the inetd.conf file now when I try to access the server I get: cvs [login aborted]: unrecognized auth response from cvsrepo: Usage: cvs [cv s-options] command [command-options-and-arguments] That means the line in inetd is wrong. You probably left off the "pserver" command. Another possibility is that you tried to break the command in inetd.conf into two lines? Test the command on a command line until you can get it to reply with the "bad auth" stuff when you hit return. Then copy it back into inetd.conf. What is the proper syntax for allowing access to more than one repository via the pserver? Add the --allow-root= argument twice. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- 116. (A)bort, (R)etry, (P)retend this never happened... ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: HELP! I can't access pserver
Thanks, but all I did was insert an additional --allow-root= stmt. When I removed it, I could access the repository again. With 2 --allow-root stmts, the line naturally wraps, but I didn't insert a return. The server is CVS 1.10 running on Solaris 5.6, any other thoughts? -Original Message- From: Derek R. Price [mailto:[EMAIL PROTECTED]] Sent: Friday, March 23, 2001 2:05 PM To: Largent, Jim Cc: '[EMAIL PROTECTED]' Subject: Re: HELP! I can't access pserver "Largent, Jim" wrote: I have a project on the CVS server that has been running fine. I wanted to add another separate project and added another --allow-root statement into the inetd.conf file now when I try to access the server I get: cvs [login aborted]: unrecognized auth response from cvsrepo: Usage: cvs [cv s-options] command [command-options-and-arguments] That means the line in inetd is wrong. You probably left off the "pserver" command. Another possibility is that you tried to break the command in inetd.conf into two lines? Test the command on a command line until you can get it to reply with the "bad auth" stuff when you hit return. Then copy it back into inetd.conf. What is the proper syntax for allowing access to more than one repository via the pserver? Add the --allow-root= argument twice. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- 116. (A)bort, (R)etry, (P)retend this never happened... ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: HELP! I can't access pserver
"Largent, Jim" wrote: Thanks, but all I did was insert an additional --allow-root= stmt. When I removed it, I could access the repository again. With 2 --allow-root stmts, the line naturally wraps, but I didn't insert a return. The server is CVS 1.10 running on Solaris 5.6, any other thoughts? -Original Message- From: Derek R. Price [mailto:[EMAIL PROTECTED]] inetd.conf into two lines? Test the command on a command line until you can get it to reply with the "bad auth" stuff when you hit return. Then copy it back into inetd.conf. Other than the above, it should work, so maybe upgrade to 1.11? Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- Photons have mass? I didn't know they were catholic! ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: HELP! I can't access pserver
Largent, Jim writes: Thanks, but all I did was insert an additional --allow-root= stmt. When I removed it, I could access the repository again. With 2 --allow-root stmts, the line naturally wraps, but I didn't insert a return. The server is CVS 1.10 running on Solaris 5.6, any other thoughts? What editor are you using? It might be inserting a return automatically. The other possibility is that you've exceeded the maximum number of arguments your inetd allows. In that case, have inetd run a shell script that exec's cvs with the correct arguments. -Larry Jones I'll be a hulking, surly teen-ager before you know it!! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Reimporting vendor projects where items have been deleted
On Thu, Mar 22, 2001 at 10:30:19PM -0800, Nathan Herring wrote: Larry writes: How is import supposed to know to do that, though? IF import file does not exist, AND repository file does exist, AND repository file has a branch with the same name as the vendor-tag argument AND that branch has the same version as the branch version specified on import AND the most recent revision on the vendor-tag branch is not marked dead, THEN create a new version on the vendor-tag branch marked as dead END IF What he said! Note that if all of these conditions are met except the last one, ie. the ,v file has an appropriate vendor branch, but the latest revision on that branch is marked "dead", then of course the new release tag should be added to that dead revision -- as happens now for an unchanged "live" file. P.S. Here's a second example: $ mkdir vendor1 $ cd vendor1 $ echo 1vendor1_file1 $ echo 2vendor1_file2 $ cvs import -m first tst vendor1 vendor1_v1 N tst/vendor1_file1 N tst/vendor1_file2 No conflicts created by this import $ mkdir ../vendor2 $ cd ../vendor2 $ echo 1vendor2_file1 $ cvs import -m second tst vendor2 vendor2_v1 N tst/vendor2_file1 $ cd ../vendor1 $ rm vendor1_file1 $ cvs import -D -m third tst vendor1 vendor1_v2 R tst/vendor1_file1 U tst/vendor1_file2 No conflicts created by this import NOTE: It didn't remove vendor2_file1 [NB: this actually said "vendor2_file2"; I've corrected what I assume was a typo -ES ], because, depsite the fact that the import file did not exist, the repository file did not have the original vendor1 tag, and so CVS assumes it wasn't part of this vendor's import and leaves it alone. This is the only part I question -- and I do mean "question"; I'm not asserting that it's wrong, but wondering whether it might be, and asking people to think about it. Should this be based on the import branch number, rather than name? That is: if, in the above example, branch-tags "vendor1" and "vendor2" both referred to branch 1.1.1, then they'd be considered identical for this purpose; vendor2_file1 *would* be deleted during the "third" import. But if "vendor1" and "vendor2" referred to different branches, eg. the vendor2 import had been: $ cvs import -m second -b 1.1.3 tst vendor2 vendor2_v1 then, as Nathan says, vendor2_file1 would *not* be deleted during the "third" import -- indeed, in this specific case, it wouldn't have to be deleted, since it wouldn't be on branch 1.1.1 in the first place. But perhaps that's what Nathan meant by: AND that branch has the same version as the branch version specified on import in which case, all I'm questioning is whether the following condition should go away: AND repository file has a branch with the same name as the vendor-tag argument -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Reimporting vendor projects where items have been deleted
On Fri, Mar 23, 2001 at 09:19:32AM -0500, Derek R. Price wrote: Nathan Herring wrote: Import knows the name and branch version of the vendor branch, has a list of files to import, and has a list of files already in the repository. This is all it needs to know. Now use the following heuristic: Basically, import would have to look up the tip of the vendor branch before execution to obtain the list of files present during the last import. Not "before execution". Instead, "import" turns into a classic merge(*) -- which I guess "update" already is. So one has to add a scan of the repository directory, and the reading of any repository files that aren't in the directory being imported, but it's still only one-pass. * I mean "merge" here in the traditional "sort/merge" sense, not CVS's "merging revisions" sense -- don't you love overloaded jargon? -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Reimporting vendor projects where items have been deleted
Eric Siegerman wrote: On Fri, Mar 23, 2001 at 09:19:32AM -0500, Derek R. Price wrote: Basically, import would have to look up the tip of the vendor branch before execution to obtain the list of files present during the last import. Not "before execution". Instead, "import" turns into a classic I have no idea what you are talking about, but I think my method is the easiest. Anything else would be overkill, I'm pretty sure, and I think the checkout of the branch tip before import is unavoidable when implementing this feature (barring currently unimplemented caches metadata...). Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- 170. If you try to fail, and succeed, which have you done? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Reimporting vendor projects where items have been deleted
Eric Siegerman wrote: Note that if all of these conditions are met except the last one, ie. the ,v file has an appropriate vendor branch, but the latest revision on that branch is marked "dead", then of course the new release tag should be added to that dead revision -- as happens now for an unchanged "live" file. No it shouldn't. The only time I can see _any_ reason to do this is for the tag used in the import during which the file was actually remove and then only to mark the import which deleted the file. This information should more likely be in the log message. The dead revision really only needs to be attached to the branch. Should this be based on the import branch number, rather than name? That is: if, in the above example, branch-tags "vendor1" and "vendor2" both referred to branch 1.1.1, then they'd be considered identical for this purpose; vendor2_file1 *would* be deleted during the "third" import. But if "vendor1" and "vendor2" referred to different branches, eg. the vendor2 import had been: $ cvs import -m second -b 1.1.3 tst vendor2 vendor2_v1 then, as Nathan says, vendor2_file1 would *not* be deleted during the "third" import -- indeed, in this specific case, it wouldn't have to be deleted, since it wouldn't be on branch 1.1.1 in the first place. Absolutely not. If the same vendor branch name was used in both cases then it should already be an error if they point at different branches. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- The Gothic idea that we were to look backwards instead of forwards for the improvement of the human mind, and to recur to the annals of our ancestors for what is most perfect in government, in religion and in learning, is worthy of those bigots in religion and government by whom it has been recommended, and whose purposes it would answer. But it is not an idea which this country will endure. - Thomas Jefferson to Joseph Priestley, 1800 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Reimporting vendor projects where items have been deleted
Eric wrote: Note that if all of these conditions are met except the last one, ie. the ,v file has an appropriate vendor branch, but the latest revision on that branch is marked "dead", then of course the new release tag should be added to that dead revision -- as happens now for an unchanged "live" file. I'm not sure I necessarily agree with this. For most purposes, a file missing a static tag is equivalent to a file containing a static tag to a dead revision. Mostly, it would just take up room on the server. If you can think of a real reason to have this, let me know. But perhaps that's what Nathan meant by: AND that branch has the same version as the branch version specified on import in which case, all I'm questioning is whether the following condition should go away: AND repository file has a branch with the same name as the vendor-tag argument I ended up sending the e-mail in a half revised state accidentally, so I didn't end up explaining why we need this. First, thanks for pointing out my errors! Here are two cases we wish to get right: CASE 1: Vendors using different vendor branches (not just names). $ echo 1vendor1 $ cvs import -m vendor1_version1 tst vendor1 vendor1_version1 N tst/vendor1 No conflicts created by this import $ rm vendor1 $ echo 2vendor2 $ cvs import -m vendor2_version1 -b 1.1.3 tst vendor2 vendor2_version1 N tst/vendor2 No conflicts created by this import $ rm vendor2 $ cvs import -D -m vendor1_version2 tst vendor1 vendor1_version2 R tst/vendor1 No conflicts created by this import This deletes file vendor1 because a file exists on the vendor branch we're importing to (1.1.1), and doesn't exist in the import list. This doesn't delete file vendor2 because it doesn't contain the branch 1.1.1. CASE 2: Vendors using different names, but same vendor branches. $ echo 1vendor1 $ cvs import -m vendor1_version1 tst vendor1 vendor1_version1 N tst/vendor1 No conflicts created by this import $ rm vendor1 $ echo 2vendor2 $ cvs import -m vendor2_version1 tst vendor2 vendor2_version1 N tst/vendor2 No conflicts created by this import NOTE: at this point vendor1 == vendor2 == 1.1.1 $ rm vendor2 $ cvs import -D -m vendor1_version2 tst vendor1 vendor1_version2 R tst/vendor1 No conflicts created by this import With the heuristic I described, this would also do the "right" thing, since it checks the name of the vendor branch as well as the branch version number. You don't want to delete the vendor2 files, and the only way to make sure it's not a vendor1 file is to make sure it doesn't have the vendor1 branch tag. This is somewhat important, as most people don't generally realise that if they specify a different vendor name, they won't get a different vendor branch, but rather they'll be on the same vendor branch with the new tag assigned. You can end up royally screwed if you have different vendors with the same file that you import into the same location, failing to specify different branch versions, and then use the delete feature on a subsequent import where the file doesn't exist. However, this is certainly an extreme case, and not the normal. nh ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: 'newbie' here, having a problem with check-out
On Fri, Mar 23, 2001 at 10:12:49AM -0500, Patrick Lynch wrote: [earlier steps consist basically of importing, then checking out into c:/docs with WinCVS] 4.4 committed the c:/docs directory... 4.5 at this point, everything is working fine... 4.6 tried to check out docs from the repository and got the msg: "...*PANIC* adminstration files missing...", You shouldn't need to check out again at this point, merely update. After all, you already have a working directory. Now, if this script isn't quite correct, and what you actually did was: 4.61 delete c:/docs 4.62 try to do a "cvs update" that would give you the result you saw, I think. This certainly would: # import cd c:/docs # compressing 2 dos commands into 1 :-) cvs import ... # make a CVS sandbox, but keep the old c:/docs as a backup cd c:/ cvs co -d docs-cvs ... cd c:/docs-cvs edit commit # forgetting that you should be working in docs-cvs now :-( cd c:/docs edit commit # kaboom! admin files are missing of course. 4.7 this, according to the manual, indicates a bad CVS file... 4.8 I deleted the CVS files from the c:/docs directories and tried to check out again -- no luck, get the same error msg. Yes. Now you've explicitly created the problem it was seeing before; what I'm wondering in the preceding paragraphs is how *else* the same situation (missing c:/docs/CVS subdirectory) could have arisen. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Unable to Checkout Module
Peter Salama writes: Thanks for getting back to me.. When I run set HOME is set to my login "path" so I went ahead and unset it and then ran the command with still the same error... Any other suggestions or comments? I may be doing it wrong and if so please advise.. You're looking at $HOME on the *client* -- it's the *server* that likely has it set wrong. Most likely it's set wrong for inetd and CVS is inheriting it. If you can't figure out how to fix inetd, then you can have inetd run a shell script instead of running CVS directly; the shell script can unset $HOME and then exec CVS. -Larry Jones I just can't identify with that kind of work ethic. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: When trying to merge a file
Horia Ioanid writes: cvs server: file pnt.h exists, but has been added in revision VCR_BRANCH. That means that the file was created (as opposed to just being modified) on the branch. When you merge the branch to the trunk, CVS expects to create the file on the trunk, but the file already exists on the trunk. Either you had previously merged changes from the branch and now you're trying to merge them again, or someone independently created that file on the trunk. In either case, the files are completely unrelated as far as CVS is concerned, so it hasn't a clue how to go about merging them -- you have to do it by hand. -Larry Jones Just when I thought this junk was beginning to make sense. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Why the split for rcvs?
[EMAIL PROTECTED] on 2001.03.23 14:25:36 Since I didn't found RCVS, I'm strictly speaking from what I saw. At the time RCVS was created, maintenance on CVS was questionable. The product had been handed over from one company to another. I think the founder wanted some place that developers can post patches. What do you think about things now? Do you think that main tree of CVS is now being supported ok? Yes. However, my patches are lacking some of the things the HACKING file asks for in patch submissions (test cases and documentation) so it's been made clear to me that unless these things are supplied, the patches won't make it into the standard release. I've been trying to find time and volunteers to help me create more usable patches than the ones I've submitted for RCVS. If you want to volunteer some time (specially for some of the patches you may already be interested in), I (and many, many others) really appreciate it. I will volunteer time. I have done a fair amount of UNIX C and Shell scripting in the past but I'm rusty at this point. I'm intersted in the locking code. What I don't understand about your code is how well has it already been grafted into the main CVS tree. Is your code based exculcively off of the rcvs tree (I also have no idea how much the current version of cvs and rcvs differ)? None of my patches are in the main CVS tree. My RCVS patches were based off of cvs-1.10.8. They are incremental (which means you'll need to install each and every patch up to and including the last one you need) -- I'm working on fixing this. Give me a good idea of where to start on your locking code and how the merge into the main cvs tree should be approched. (I saw Derek's posts about your reserved lock code and I think I understand what is being asked for but I'm not sure). Let me know how I can help Awesome. I'm enclosing the patches dealing with locking and multiple edits -- there're three of them 'cos one of them is a merge of the other two with conflicts resolved. You may also want to take a look at some of the bug fixes. If you have questions, feel free to ask. Note that these patches are against cvs-1.11 and I have very minimal testing on them. Thanks much, Noel Enc (See attached file: fix-backup_over_readonly.diff)(See attached file: enh-multiple_edits+reservations.diff)(See attached file: enh-reservations.diff) (See attached file: enh-multiple_edits.diff)(See attached file: fix-default_fileattrs.diff)(See attached file: fix-edit_fields_with_plus.diff) fix-backup_over_readonly.diff enh-multiple_edits+reservations.diff enh-reservations.diff enh-multiple_edits.diff fix-default_fileattrs.diff fix-edit_fields_with_plus.diff
RH 7.0, cvs pserver not working
hello -
I'm running Red Hat 7.0 and CVS 1.11. CVS works fine locally but I cannot
get pserver to work. The error message from a Windows 2000 client is:
$ cvs -d :pserver:[EMAIL PROTECTED]:/cvs login
(Logging in to [EMAIL PROTECTED])
CVS password:
cvs [login aborted]: connect to 192.168.1.134:2401 failed: Connection
refused
Both of these postings refer to a similar problem:
http://mail.gnu.org/pipermail/info-cvs/2000-December/011394.html
http://mail.gnu.org/pipermail/info-cvs/2001-March/013146.html
I have the line:
cvspserver 2401/tcp
in my /etc/services file.
I have created the file /etc/xinetd.d/cvspserver with content:
service cvspserver
{
flags = REUSE
instances = 25
disable = no
protocol= tcp
socket_type = stream
wait= no
user= root
group = cvsusers
env = HOME=/cvs
passenv =
server = /usr/bin/cvs
server_args = -f --allow-root=/cvs pserver
log_on_success += DURATION USERID
log_on_failure += USERID
}
and I have rebooted the machine to re-initialize the cvspserver service.
Thank you for any help!!
Ginger
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
strange error message
I'm running cvs-1.10.8 on solaris2.8 (with binary built for solaris2.7) and getting the error message below. What does it mean? cvs checkout: Updating mep/src/Shape cvs checkout: cannot open directory /volume14/postfix/repo.cvs/postfix/mep/src/Shape: Value too large for defined data type cvs checkout: skipping directory mep/src/Shape TIA, - Ted ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Why the split for rcvs?
Noel L Yap wrote: Note that these patches are against cvs-1.11 and I have very minimal testing on them. You'll get the best results if any _submitted_ patches are against the dev version. The less work that has to be done to get the thing properly into the tree as usably and maintainably as possible, the more likely it is that someone with access will do it... Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- Old heads as well as young may sometimes be charged with ignorance and presumption. The natural course of the human mind is certainly from credulity to skepticism. - Thomas Jefferson to Caspar Wistar, 1807 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
can't login via pserver and therefore can't save ~/.cvspass file
Hello, We're running CVS 1.10.6 as our CVS server and I'm running CVS 1.10.8 on RedHat 7.0 as a client and have the following environment vars set in my client shell: CVSROOT=:ext:[EMAIL PROTECTED]:/usr1/cvs CVS_RSH=ssh When I try to create a ~/.cvspass on the client with the following command it hangs after I type in my CVS password. Unix prompt-cvs -d :pserver:[EMAIL PROTECTED]:/usr1/cvs login (Logging in to [EMAIL PROTECTED]) CVS password: Besides being able to login via pserver, CVS seems to function properly for me. I'm able to import, checkout, etc. fine with the above environment settings. HOWEVER, there is an error message that appears when I do them: Unix prompt-cvs checkout mymodulename [EMAIL PROTECTED]'s password: stty: standard input: Invalid argument -- ERROR MESSAGE cvs server: Updating mymodulename I've also installed the latest version of WinCvs and have set the Authentication as "passwd file on the cvs server" and everything seems to work fine with it. Anyone have any ideas why things might be behaving this way? The reason I want to be able to save a ~/.cvspass file is because I want to call cvs commands from with scripts and that seemed to be the best way to do it. If there is a better or more common way to be able to execute cvs commands from within scripts could someone pass that info along, please? Many thanks, Joe ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Reimporting vendor projects where items have been deleted
On Fri, Mar 23, 2001 at 03:41:12PM -0500, Derek R. Price wrote: Eric Siegerman wrote: [if] the ,v file has an appropriate vendor branch, but the latest revision on that branch is marked "dead", then of course the new release tag should be added to that dead revision No it shouldn't. I defer to your (much) greater knowledge of CVS internals. I suggested this *because* it's what happens with unchanged live files, and it seems cleaner to me to treat unchanged files (whether live or dead) in the same way, unless there are reasons to do otherwise -- "make sure special cases really are special" and all that. I'll take your word for it that there are indeed reasons to treat these cases differently. Should this be based on the import branch number, rather than name? Absolutely not. If the same vendor branch name was used in both cases then it should already be an error if they point at different branches. Do you mean where someone does this? cvs import foo vendor1 release1 cvs import -b 1.1.3 foo vendor1 release2 ^ [sic] I wasn't trying to address this case, which is clearly an error, but rather Nathan's Case 2 below. I guess I was unclear. Sorry. On Fri, Mar 23, 2001 at 12:53:25PM -0800, Nathan Herring wrote: CASE 1: Vendors using different vendor branches (not just names). [importing on vendor branch A does *not* check "dead" revisions into vendor branch B] No argument here! CASE 2: Vendors using different names, but same vendor branches. To summarize: cvs import foo vendor1 release1 cvs import foo vendor2 release2 with no -b option either time. After looking into this more closely, it seems each of us is right some of the time :-) Under Nathan's assumption -- that this happened because a user was trying to create a second vendor branch but forgot the -b -- he's right; his proposed behaviour works better. But there's another way this situation can arise (which is the one I was thinking of when I proposed my change): if the user was trying to import a new release into an existing vendor branch, but mistyped the tag name. I'll call this "case 3", even though it's isomorphic to case 2. In case 3, my proposed behaviour works better -- if a file is in release1 but not in release2, the user does *not* want it to appear on what they intended to be the *only* vendor branch. Thus, it shouldn't appear on either actual branch, and my way, it doesn't. But note: - Cases 2 and 3 are both due to user error - Both of them have other problems, which keep them from doing what the user wanted (as opposed to what they mistakenly asked for :-) Thus, it doesn't seem to matter much which way this particular decision goes; it comes down to arguing over which error users are more likely to make. Unless, of course, there are more *non-error* cases; if there are, what's right for those should win over both cases 2 and 3. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Rename atomicity
On Fri, Mar 23, 2001 at 11:24:19PM +0100, Assar Westerlund wrote: What the patch below does is introduce an option (`-R') for running without creating any lock-files. This would let any user subvert CVS locking in the interest of "saving time" (famous last words) and potentially corrupt the repository. -R would be safe if: - it could be used *only* on operations that don't change the repository (eg. checkout), and - it arranged that the user not be allowed to commit from the resulting sandbox Failing that, it should be an optional feature chosen at configure time -- and should be disabled by default! -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: strange error message
On Fri, Mar 23, 2001 at 04:50:43PM -0700, Ted Irons wrote: cvs checkout: cannot open directory /volume14/postfix/repo.cvs/postfix/mep/src/Shape: Value too large for defined data type cvs checkout: skipping directory mep/src/Shape I'm running cvs-1.10.8 on solaris2.8 (with binary built for solaris2.7) At a guess, this is your problem. More specifically, it looks as though the binary was compiled on/for a system that only supports small "something"'s (probably 32-bit inode numbers), and the repo is on a filesystem with larger whatever-they-are's (eg. 64-bit inode numbers). Try getting the 1.11 source and compiling it on the server machine. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Rename atomicity
I can say from experience that assembling a sandbox from an unlocked repository is no more or less safe than any out-of-date sandbox, provided the CVS metadata are correct with respect to the contents of the working files. In either case, a "cvs update" is required (with the accompanying conflicts resolved) before a commit can be completed. This can be tricky if the read operation is done concurrently with a commit or tag operation. The first point, that the operation be read-only is absolutely correct. To resolve issues surrounding concurrent reads and writes, my method required that all revisions retrieved from the repository be identified in advance. --- Forwarded mail from [EMAIL PROTECTED] On Fri, Mar 23, 2001 at 11:24:19PM +0100, Assar Westerlund wrote: What the patch below does is introduce an option (`-R') for running without creating any lock-files. This would let any user subvert CVS locking in the interest of "saving time" (famous last words) and potentially corrupt the repository. -R would be safe if: - it could be used *only* on operations that don't change the repository (eg. checkout), and - it arranged that the user not be allowed to commit from the resulting sandbox Failing that, it should be an optional feature chosen at configure time -- and should be disabled by default! --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
