Re: diff has NUL instead of /dev/null
Hi Paul, The file window-NT/config.h defines DEVNULL as "nul" which is the expected Windows NT localtion for a file with no bytes. The UNIX systems $ grep -r DEVNULL cvs-1.11.9 | grep .h: cvs-1.11.9/emx/config.h:#define DEVNULL "nul" cvs-1.11.9/os2/config.h:#define DEVNULL "nul" cvs-1.11.9/src/cvs.h:#define DEVNULL "NLA0:" cvs-1.11.9/src/cvs.h:#ifndef DEVNULL cvs-1.11.9/src/cvs.h:#defineDEVNULL "/dev/null" cvs-1.11.9/windows-NT/config.h:#define DEVNULL "nul" cvs-1.11.9/windows-NT/stamp-ch:#define DEVNULL "nul" $ So, I think you may take that there is nothing wrong with your output as provided. Note CVS 1.11.9 is very old (came out in 2003). You may wish to upgrade to at least CVS 1.11.23 which was released on May 7, 2008. You may find it useful to consider CVS 1.12.13 as the most recent release of CVS provided to the net. If you want a more recent and supported version of CVS, then I suggest a visit to https://cvsnt.org/ which provides a C++ version of CVS that is available for both Windows and Linux and for which you may purchase support from March Hare (march-hare.com). Be safe, stay healthy, -- Mark
Re: importing files: CVS
Hi KM, KM writes: > I haven't created a repository from scratch in a long time. I created > the repository and the CVSROOT files are done. I imported a directory > and it creates a branch from the vendor branch field I passed. the > version numbers are 1.1.1.1. I don't remember this happening in the > past, but as I've said it's been a long time. > > when I do a checkout i expected the trunk/HEAD and to see 1.1 > versioning. I am doing this correctly? Do i need to switch to the HEAD > or checkout the HEAD to see them as 1.1. > > Hope it all makes sense. Thanks > KM > Everything is working as designed. The first time you make a change to one of the 1.1.1.1 version files and commit it, the new version will be version 1.2. Another import will create 1.1.1.2 which will NOT be on the HEAD until you merge it. This is just how vendor branches work. Be safe, stay healthy, -- Mark
Re: How can I get early version of cvs!
Hi Thamer, Alsulaiman, Thamer writes: > I am Thamer Alsulaiman, a junior faculty at UIOWA. I will be teaching > Object oriented design next Fall. Okay. > I am currently thinking of giving the students project on version > control. I downloaded the CVS files from 2005. But I wish to get much > earlier releases, which I expect to be simpler and have basic > functionality. I need it as a basis to understand the basic building > blocks of version control software, and design an OO project around > it. Okay. > Kindly, any pointers will be appreciated. You could checkout the sources from the cvs repository See URL: https://savannah.nongnu.org/cvs/?group=cvs ) cvs -z3 -d:pserver:anonym...@cvs.savannah.nongnu.org:/sources/cvs login : cvs -z3 -d:pserver:anonym...@cvs.savannah.nongnu.org:/sources/cvs co ccvs If you do a 'cvs log' you should see all of the old tags to check out older versions that have been tagged. For example, you should be able to get cvs1-5 in this way. > Thanks. CVS 1.1 and 1.2 were a set of shell scripts written around RCS - The Revision Control System. The sources for versions prior to 1.3 were mostly shared on USENET in comp.sources.unix and the like and cvs-1.4Alpha was shared as a set of patches over email... which I do not believe I have any longer. However, if you provide me space to upload, I could give you a number of revisions from my personal archive. 412 -rw-r--r--. 1 mdb user 421731 Dec 16 1993 cvs-1.3.tar.gz 1228 -rw-r--r--. 1 mdb user 1256940 Jan 2 1996 cvs-1.6.tar.gz 1320 -rw-r--r--. 1 mdb user 1348725 Feb 19 1996 cvs-1.7.tar.gz 1376 -rw-r--r--. 1 mdb user 1406364 May 6 1996 cvs-1.8.tar.gz 1652 -rw-r--r--. 1 mdb user 1687669 Jun 23 1997 cvs-1.9.tar.gz 2460 -rw-r--r--. 1 mdb user 2518438 Aug 13 1998 cvs-1.9.28.tar.gz 2456 -rw-r--r--. 1 mdb user 2514232 Aug 13 1998 cvs-1.9.27.tar.gz 2492 -rw-r--r--. 1 mdb user 2549964 Aug 15 2000 cvs-1.10.tar.gz 2316 -rw-r--r--. 1 mdb user 2371144 Sep 18 1998 cvs-1.10.2.tar.gz 2280 -rw-r--r--. 1 mdb user 2334373 Feb 18 1999 cvs-1.10.5.tar.gz 2264 -rw-r--r--. 1 mdb user 2317260 May 16 1999 cvs-1.10.6.tar.gz 2260 -rw-r--r--. 1 mdb user 2312181 Jul 28 1999 cvs-1.10.7.tar.gz 2268 -rw-r--r--. 1 mdb user 2322238 Jan 17 2000 cvs-1.10.8.tar.gz 2636 -rw-r--r--. 1 mdb user 2695311 Apr 18 2002 cvs-1.11.2.tar.gz 3116 -rw-r--r--. 1 mdb user 3189772 May 19 2004 cvs-1.12.8.tar.gz 2880 -rw-r--r--. 1 mdb user 2947477 Jun 9 2004 cvs-1.11.17.tar.gz 4 -rw-r--r--. 1 mdb user 65 Jun 9 2004 cvs-1.11.17.tar.gz.sig 2900 -rw-r--r--. 1 mdb user 2969415 Nov 11 2004 cvs-1.11.18.tar.gz 4 -rw-r--r--. 1 mdb user 65 Nov 11 2004 cvs-1.11.18.tar.gz.sig 2924 -rw-r--r--. 1 mdb user 2992973 Feb 3 2005 cvs-1.11.19.tar.gz 4 -rw-r--r--. 1 mdb user 65 Feb 3 2005 cvs-1.11.19.tar.gz.sig 2944 -rw-r--r--. 1 mdb user 3013502 Apr 18 2005 cvs-1.11.20.tar.gz 4 -rw-r--r--. 1 mdb user 65 Apr 18 2005 cvs-1.11.20.tar.gz.sig 3372 -rw-r--r--. 1 mdb user 3451335 Sep 28 2005 cvs-1.11.21.tar.gz 4 -rw-r--r--. 1 mdb user 65 Sep 28 2005 cvs-1.11.21.tar.gz.sig 2864 -rw-r--r--. 1 mdb user 2929933 Sep 28 2005 cvs-1.11.21.tar.bz2 4 -rw-r--r--. 1 mdb user 65 Sep 28 2005 cvs-1.11.21.tar.bz2.sig 2872 -rw-r--r--. 1 mdb user 2939294 Jun 9 2006 cvs-1.11.22.tar.bz2 4 -rw-r--r--. 1 mdb user 65 Jun 9 2006 cvs-1.11.22.tar.bz2.sig 3384 -rw-r--r--. 1 mdb user 3463528 Jun 9 2006 cvs-1.11.22.tar.gz 4 -rw-r--r--. 1 mdb user 65 Jun 9 2006 cvs-1.11.22.tar.gz.sig 2876 -rw-r--r--. 1 mdb user 2942652 May 8 2008 cvs-1.11.23.tar.bz2 4 -rw-r--r--. 1 mdb user 65 May 8 2008 cvs-1.11.23.tar.bz2.sig 3432 -rw-r--r--. 1 mdb user 3512175 May 8 2008 cvs-1.11.23.tar.gz 4 -rw-r--r--. 1 mdb user 65 May 8 2008 cvs-1.11.23.tar.gz.sig 3308 -rw-r--r--. 1 mdb user 3385448 Jun 9 2004 cvs-1.12.9.tar.gz 4 -rw-r--r--. 1 mdb user 65 Jun 9 2004 cvs-1.12.9.tar.gz.sig 4 -rw-r--r--. 1 mdb user 65 Dec 13 2004 cvs-1.12.11.tar.gz.sig 3584 -rw-r--r--. 1 mdb user 3667923 Dec 13 2004 cvs-1.12.11.tar.gz 4 -rw-r--r--. 1 mdb user 189 Jan 26 2005 cvs-1.12.11.tar.gz.asc 3964 -rw-r--r--. 1 mdb user 4058504 Apr 18 2005 cvs-1.12.12.tar.gz 4 -rw-r--r--. 1 mdb user 65 Apr 18 2005 cvs-1.12.12.tar.gz.sig 4628 -rw-r--r--. 1 mdb user 4737137 Oct 3 2005 cvs-1.12.13.tar.gz 4 -rw-r--r--. 1 mdb user 65 Oct 3 2005 cvs-1.12.13.tar.gz.sig You may also find that the cvsnt sources which are a rewrite in C++ may be of interest. -- Mark
Re: Need the ECCN number for CVS
An Export Control Classification Number (ECCN) is not needed for the Concurrant Version System (CVS) Open Source Software package. It is NOT a commercial product. It does not contain any export controlled technology. -- Mark D. Baushke m...@gnu.org
Re: [Non-DoD Source] Re: CVS lock issue
In order to write a tag or a new revision of a file to particular 'foo.cc' in the repository, CVS must update the 'foo.cc,v' file in the repository. After it locks the directory, it opens a new file ',foo.cc,' which is where it starts copying the foo.cc,v along with the added line containing the tag. When the update and copy is finished, it renames ',foo.cc,' to 'foo.c,v' and removes the write locks. If there is a problem during the write, there are cases where the ',foo.cc,' file is left so that no information from 'foo.cc,v' is lost (other than the update being made). This should have resulted in an error message. For read operations, the existence of ,foo.cc, will not be a problem. However, for write operations, that file must not exist. A repository maintainer must go in and see if they can salvage anything that we left around and also possibly see if they can understand what problem arose. In my experience, the most common case of a ',foo.cc,' file being left around was if the repository was on an NFS filesystem and it lost some of the file it was trying to write. Good luck, -- Mark
Re: Forwarding of patches to upstream CVS
Amit Uttamchandani amit.ut...@gmail.com writes: I am currently helping out the Debian CVS maintainer. I would like to forward some bugs that we have into your bug tracking. Is that OK? Yes. Including suggested fixes is also encouraged. -- Mark pgpmZl7DoBlAw.pgp Description: PGP signature
Re: cannot read from /cvs/CVSROOT/Emptydir/##CVSDUMMY/##CVSDUMMY
th_wm th...@gmx.de writes: after trying to call cvs update on a directory myDir, which is not the current directory, I've got the error message cvs -d :mycvs-root/cvs up -d ../../myDir cvs server: User 'myuser' cannot read from /cvs/CVSROOT/Emptydir/##CVSDUMMY/##CVSDUMMY instead of updating that directory. Remark: :mycvs-root/cvs, myuser myDir are ok; I only anonymized it here. The command works, if I call cvs up without the 2nd -d option, when the working directory is to be updated. What was wrong or missing, what may be the reason for this error message? It would seem that the relative directories are giving CVS problems. How can the problem be resolved? Try doing the update directly while in the ../../myDir directory: cd ../../myDir cvs update -d If that does not work, then more information will be needed about the contents of your checked out tree. -- Mark pgpcoe7lUrZUf.pgp Description: PGP signature
Re: About CVS
Many people, companies, and open source projects still use CVS to manage their source code base. CVS was built originally on top of RCS and later extended to use a client/server model rather than just a local model. There is good integration between the Eclipse IDE and CVS (it has been argued that the integration between Eclipse and CVS is better than the Eclipse and SVN integration), but that is not the only method of using CVS. It is also not the only source control system integrated with Eclipse (e.g., ClearCase, Perforce, and Subversion). A number of the original CVS developers determined to write a replacement for CVS to avoid some of the problems that folks had identified over time. My recollection is that CollabNet sponsered the original work back in 2000 which is how svn was born. The key idea is to choose the correct source control system for the project. There are a number of possible alternatives available. If you want a client/server system which is open source software, then you will probably end up using either CVS, CVSNT (a fork of CVS), or Subversion. There are commercial alternatives available as well if an organization feels it needs support. There are a number of distributed revision control software packages as well (e.g., git, mercurial (aka hg), svk). -- Mark pgp3uvL4pQa2M.pgp Description: PGP signature
Re: Convert already downloaded code from one user to another
Jai Kumaran V.G. jaiga...@gmail.com writes: i have downloaded a codebase with user1 credentials, i want to just to migrate this existing download code base to user2 with out downloading the codebase again. If your CVS/Root files mention user1, then you will need to modify your CVS/Root files using something like the 'newcvsroot.sh' script which comes with your CVS source distribution. If there are any files being watched and you have done a 'cvs edit' then you will likely need to revert those locks as user1 before proceeduing to adding advisory locks as user2. is find and replace best solution or is there any optimal solution for this ? or is there any tools to do this? You may use a command-line 'cvs -d $CVSROOT' to over-ride the CVS/Root entries, or you may choose to use the contrib/newcvsroot.sh which comes with the CVS source distribution to change the CVS/Root as appropriate for user2. You may need to change the underlying file permissions and ownerships to allow the approprate user2 to have full access to the repository. -- Mark pgp3lpoIwcIRw.pgp Description: PGP signature
Re: missing files after cvs checkout
Hi David, Actually, you can determine where it is in the repository using the CVS command: cvs log filename The 'RCS File' will include the '/Attic/' component if the filename is indeed in the Attic. Then looking to see the 'state: ' of the 'head:' revision should tell you if it is right or not. For exaqmple, if 'head: 1.33' is found and the data looks something like this: RCS file: /path/to/file/Attic/name.c ... head: 1.33 ... revision 1.33 date: -mm-dd hh:mm:ss +; author: xx; state: dead; lines +0 -0; ... then there is nothing wrong. However, if the state is something else like 'state: Exp;' then you have run into the older 'cvs' bug. Good luck, -- Mark pgpiqtaD5Rd3c.pgp Description: PGP signature
Re: down revision
Santosh santosh...@gmail.com writes: Hello, I unknowingly bumped a revision of file from 7.46 to 8.00. I use cvs special characters to get the revision no. in C source code. I need to down the revision to 7.47, how can I do it? Why should it matter? The internal CVS revision is not really intended to be used outside of CVS for any real purpose... Are you running into some kind of a bug with CVS using 8.00 ? If not a regular user, can cvs administrator do it? Yes, it is possible, but it will be a manual operation of the administrator on the ,v file itself. -- Mark pgpUuQRy9evVB.pgp Description: PGP signature
Re: Unremoving a file?
Jake Colman col...@ppllc.com writes: I 'cvs removed' a file from a branch. I now realize that it should not have been removed. How do I get it back? If you have not yet done a 'cvs commit', then 'cvs add filename' will undo the 'cvs remove filename' operation. If you have done a 'cvs commit', then using something like the command: cvs log filename to find the correct revisions for the branch should see a 'dead' revision. For example, if you see that your branch has a 1.1.2.10 as the 'dead' revision, then cvs update -j1.1.2.10 -j1.1.2.9 filename will apply the reverse patch to revert the change which cause the file to be removed from the branch. Doing a 'cvs commit' will re-add the file under the 1.1.2.11 revision to the branch such that 1.1.2.9 and 1.1.2.11 should compare as the same file modulo the differences in any RCS keyword values. -- Mark pgpldhxTO41Sn.pgp Description: PGP signature
Re: Get all CVS comments since last tagged version
I wonder if it is possible to collect all CVS committ-comments of the current HEAD that were added since the last tagged CVS version. That means, I only want to get all the comments of files that were edited since the last CVS tagged version, NOT the comments of all files. Assumpton: The last tag was 'FROM_TAG' .. If the command: cvs log -rFROM_TAG:: is not doing what you expect, then you may have to write something to do what you want. You may find it useful to look at cvs2cl.pl http://www.red-bean.com/cvs2cl/ The '--delta FROM_TAG:TO_TAG' option might be a starting point. Good luck, -- Mark pgp7XXSweVCSz.pgp Description: PGP signature
Re: ssh fine w/pubkey only, nonstandard port and passphrase for local keypair but cvs isn't
Mike Klein forumsmkl...@gmail.com writes:
I have no problems using ssh or scp with an sshd configured for pubkey
only and my local keypair requiring a passphrase before authn. I have my
sshd running on a nonstandard port (to cut down on scans).
Yet I can't seem to configure CVSROOT to allow cvs from cmdline (cygwin)
or my IDE (NetBeans) to allow a commit.
I always get the message that pubkey failed.
I am unsure even after googling whether CVSROOT permits non-standard
ports or local passphrase for pubkey authnis all of this possible?
Typically you would need to have the Port entry for your CVSROOT host.
For example, the host anoncvs.usa.openbsd.org uses port 2022 for its sshd.
In your $HOME/.ssh/config file:
%--%--%--%--%--%--
Host anoncvs.usa.openbsd.org
ForwardX11 no
ForwardAgent no
Port 2022
%--%--%--%--%--%--
Your CVSROOT might contain this:
:extssh:anon...@anoncvs.usa.openbsd.org:/cvs
or (depending on the release of CVS you are using)
:ext:anon...@anoncvs.usa.openbsd.org:/cvs
and you might checkout the modules file using the command:
cvs co -p CVSROOT/modules
The other method to deal with this is using CVS_RSH
CVS_RSH=$HOME/my-ssh-script; export CVS_RSH
CVSROOT=:ext:myu...@cvs.somehost.domain.com:/cvs/path; export CVSROOT
Then using a $HOME/my-ssh-script something like this:
#!/bin/sh
exec ssh -p 2022 -x -a ${1+$@}
which lets you hardcode the port number option.
-- Mark
pgpCCLsfPBO6t.pgp
Description: PGP signature
Re: listing all files from a cvs repository
smp mvonb...@gmail.com writes: is there any command to list all files from a repository? For cvs 1.12.x, use 'cvs -n rls -lR .' For cvs 1.11.x, use 'cvs -n rlog -R .' Note: CVSNT also supports the 'rls' command. I want to send this command from PHP and show there a files. rlog, checkout etc works fine. If the repository is large, you will find that this will be very painfully slow and may cause timeouts as the entire directory is traversed. Generally, I find that dumping all of the pathnames into a MySQL database that gets updated a few times a day with the pathnames is easier on the repository server and a web UI... Enjoy! -- Mark pgpv9lWqjzJek.pgp Description: PGP signature
Re: CVS list files in repository which are currently in checked out status
Rupa Bholanath Lahiri rupab_lah...@infosys.com writes: Is there a command in CVS to get all working copies? No. -- Mark pgpSuM2C9pWJ0.pgp Description: PGP signature
Re: CVS list files in repository which are currently in checked out status
Hi Rupa, Rupa Bholanath Lahiri rupab_lah...@infosys.com writes: Please correct me if I am wrong, does this command list out the files which are locked (file locking or reserved checkouts) to allow only one person to edit the file at a time. A 'cvs release' command will automagically unlock files on which you have performed a 'cvs edit filename' operation. It will not print out such files unless they have been modified in your working copy. A 'cvs release' command will print out a list of modified files in your along with a number: $ cvs release -d mod M foo.txt You have [1] altered files in this repository. Are you sure you want to release (and delete) directory `mod': If you say 'no', then you will get a message like ** `release' aborted by user choice. and the module will not be released. If you say 'yes', then the module will be released. The -d option will remove the local copy of the files for you in addition to possibly updating the history file and sending any notifications of edits you have released to any watchers of the files you have edited. -- Mark pgpn9CqKLJGD3.pgp Description: PGP signature
Re: Stuck with commitinfo while setting up CVSspam
Todd wrote: I would suggest /bin/true and /bin/false. One should consume all of the input or you will get odd broken pipe error messages. Other than that, I agree with the rest of your message. -- Mark pgpfYHN3AW5vw.pgp Description: PGP signature
Re: How I can download all cvs repository?
Alexandr Vladykin alexa...@vladykin.pp.ru writes: I have an access to a CVS repository - login and password. I can checkout info, commit, update etc. I can do it only from one computer at office. But I want to have a copy of all of the repository at home. This really should not be needed. So I'll can have all info about changes in CVS, checkout any tagged version etc at home, not at work. Some places of work might call what you want to do 'theft' of intellectual property, so be sure it okay with your employer first. How I can do it? I can not ask admin to copy me files of CVS repository. Why not? If it legit to do what you want, they should have no problem helping you. Now I think to write a script for checkout all file revisions and by once commit it into my local CVS repository. But if I'll do so, I'll lose any info about date, when this file revision was commited and who was commited it. This has already been done. If you have debian, you can just install the cvssuck package. Otherwise, look for CVSsuck on cvs.m17n.org/~akr/cvssuck/ or check your favorite search engine. May be you have any idea? Ask your IT folks if they can give you CVSup access to the repository. -- Mark pgpoJkX711Myh.pgp Description: PGP signature
Re: cvs log - related
Hi Satheesh, Satheesh sat...@ltp.soft.net writes: I have added a new java file to the repository. And there are no revisions to it so far. When I view the cvs log, the log report is fetching the file but says date: 2008/12/31 06:00:51; author: amit; state: Exp; lines: +0 -0 But I have added with 130 lines. Why the log is not showing +130 -0 in its report. Am I missing any options in the cvs log command. I used cvs log -d date1=date2 logfile.log Please suggest on this issue. You don't really give much information here. However, if you did a CVS import of your first revision of the file, then revision 1.1 will have a date without any 'lines:' information. It is considered the baseline revision. However, the imported revision 1.1.1.1 will have a 'lines: +0 -0' indicating that there are no differences between it and the revision 1.1 of the file. You have not provided sufficient information for anyone to tell you what you do or do not have in your repository, but that is my best guess for what you are doing to yourself. In future, you may wish to consider providing the output of 'cvs version' information as well as both the 'revision 1.*' and 'date:' line output. Good luck, -- Mark pgp4Pu0kUbf9i.pgp Description: PGP signature
Re: Need CVS Help
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings Muhammad Shafi, Muhammad Shafi [EMAIL PROTECTED] writes: How to setup a new user in CVS and how to reset a user password in CVS. If you use :extssh: or :ext: methods, then follow the instructions for adding ew users to the operating system. If you use :pserver:, be advised that I believe this is a bad idea and I personally refuse to run a :pserver: cvs server myself. If the following document is not useful to you: http://tldp.org/HOWTO/Secure-CVS-Pserver/setuptools.html http://www.taylorit.com/articles/2005-06-17/how.to.set.up.a.cvs.server/ http://www.taursys.com/howto/cvs/ you may find others by doing a google search, or someone here may be better suited gto your reuireenebts.. -- Mark NB: I personally do not believe that CVS has had an extensive enough security audit to justify such a weak protocol. (Although, I can understand the attraction of using :pserver: for anonymous read access to a mirror of a CVS repository.) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJCnDuCg7APGsDnFERAjJdAJ9Bd8/PMcrwBfKO8W5ivFPLq8clGwCg2Qnc kOy1PlSireWZuC4FU6JaLHI= =/+QG -END PGP SIGNATURE-
Re: To get some information regarding CVS
Arthur Barrett [EMAIL PROTECTED] writes: True, it is open-source, so anybody could in principle analyze the source code to figure out the format. Yes indeed - and if anyone wants a concise list all they need to do is ask. A grep for findnode.*other_delta in the source will find all the nodes we add, at a quick look myself they are: - filename - commitid For what it is worth, if rcs-5.8 is ever released, the same patch I provided to debian [Bug #352527] (which was released as a part of rcs 5.7-18 in the debian etch release) provides a way for RCS to read and understand the commitd extension used by CVS and CVSNT. I had no problems working with Romain Francoise of debian or Paul Eggert of the GNU project to adopt a final revision of the patch. (They did choose not to accept my patch to WRITE new commitid entires using RCS, but that is not really needed if you want something to be able to parse existing ,v files for CVS and CVSNT.) - mergepoint1 - bugid - permissions And I'm in the process of adding 'username' (for where the username is different to the author - don't ask why - it's a corner case that needs to be covered). You might want to discuss the best way to do the encoding for such things with the [EMAIL PROTECTED] and/or [EMAIL PROTECTED] folks before you lock it into your code base. As the Product Managger CVSTN at March Hare Software I think I can answer on behalf of 'the commercial supporters'. We are spending out effort on the areas that people who use the product are most often requesting that the effort be spent. You are the first person ever to have requsted the list of RCS tags, Hmmm... I suspect that technically RCS calls them phrases in their grammar. The RCS tags are also sometimes known/understood to be symbolic names for revision numbers. I personally think it is good to standardize on the RCS format extensions within the RCS source base. This is why I made the effort to ensure that the CVS extension of the commitid RCS phrase was compatible with CVSNT (even though it was not very necessariy well defined by the CVSNT folks effectively it is a base62 string [0-9a-zA-Z][0-9a-zA-Z]*) and then I ported it to be understandable as an RCS phrase extension by RCS so that the RCS application would not silently strip the ,v file of that extension if it was ever used on a CVS ,v file. If there are good grammar definitions for mergepoint1, bugid, permissions and username, then it would be great if they could be shared. Any extensions to values in the other phrases (like kopt) might also be desirable. -- Mark pgp61zTiht9Kf.pgp Description: PGP signature
Re: To get some information regarding CVS
Arthur Barrett [EMAIL PROTECTED] writes:
If there are good grammar definitions for mergepoint1, bugid,
permissions and username, then it would be great if they could be
shared.
Do you have an example of how these are usually expressed?
Use the command 'man rcsfile'
For commitid, I used
{ commitid id; }
and the id itself used in CVS is a base62 encoded text. It would have
been more efficient to use a base64 encoded value for the id and put it
into a string like @id@, but CVSNT was already using it as a simple id,
so that is what we had to to in CVS to be interoperable.
I have appended the rcsfile man page for you after my .signature as an
example. This is based on the final patch submitted in February 2006
(the first patch I had submitted was in September 2005).
The CVS executable generates a slightly longer commitid than 16 bytes
used by CVSNT. CVS uses the current binary time concatenated with some
random bytes to get around simultaneous commits on the same cluser
happening at the time time... on a heavily loaded system it is possible
for the smaller commitid to be a duplicate. By using a timestamp plus a
source of random bits, this is much less likely for CVS. Although, I
will grant that it makes it harder to use the commitid as a label that
users type.
Details:
This is the code in src/main.c we use to genreate the global session ID
used for the commitid in RCS transactions for this session:
/* ... */
enum {RANDOM_BYTES = 8};
enum {COMMITID_RAW_SIZE = (sizeof(time_t) + RANDOM_BYTES)};
static char const alphabet[62] =
0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ;
/* Divide BUF by D, returning the remainder. Replace BUF by the
quotient. BUF[0] is the most significant part of BUF.
D must not exceed UINT_MAX CHAR_BIT. */
static unsigned int
divide_by (unsigned char buf[COMMITID_RAW_SIZE], unsigned int d)
{
unsigned int carry = 0;
int i;
for (i = 0; i COMMITID_RAW_SIZE; i++)
{
unsigned int byte = buf[i];
unsigned int dividend = (carry CHAR_BIT) + byte;
buf[i] = dividend / d;
carry = dividend % d;
}
return carry;
}
static void
convert (char const input[COMMITID_RAW_SIZE], char *output)
{
static char const zero[COMMITID_RAW_SIZE] = { 0, };
unsigned char buf[COMMITID_RAW_SIZE];
size_t o = 0;
memcpy (buf, input, COMMITID_RAW_SIZE);
while (memcmp (buf, zero, COMMITID_RAW_SIZE) != 0)
output[o++] = alphabet[divide_by (buf, sizeof alphabet)];
if (! o)
output[o++] = '0';
output[o] = '\0';
}
/* ... */
/* Calculate the cvs global session ID */
{
char buf[COMMITID_RAW_SIZE] = { 0, };
char out[COMMITID_RAW_SIZE * 2];
ssize_t len = 0;
time_t rightnow = time (NULL);
char *startrand = buf + sizeof (time_t);
unsigned char *p = (unsigned char *) startrand;
size_t randbytes = RANDOM_BYTES;
int flags = O_RDONLY;
int fd;
#ifdef O_NOCTTY
flags |= O_NOCTTY;
#endif
if (rightnow != (time_t)-1)
while (rightnow 0) {
*--p = rightnow % (UCHAR_MAX + 1);
rightnow /= UCHAR_MAX + 1;
}
else {
/* try to use more random data */
randbytes = COMMITID_RAW_SIZE;
startrand = buf;
}
fd = open (/dev/urandom, flags);
if (fd = 0) {
len = read (fd, startrand, randbytes);
close (fd);
}
if (len = 0) {
/* no random data was available so use pid */
long int pid = (long int)getpid ();
p = (unsigned char *) (startrand + sizeof (pid));
while (pid 0) {
*--p = pid % (UCHAR_MAX + 1);
pid /= UCHAR_MAX + 1;
}
}
convert(buf, out);
global_session_id = xstrdup (out);
}
/* ... */
The CHAR_BIT macro is presumed to be set by limits.h and is often 8.
The UCHAR_MAX macro is presumed to be set by limits.h and is often 255.
Enjoy!
-- Mark
$ man rcsfile | ul -tdumb
RCSFILE(5) RCSFILE(5)
NAME
rcsfile - format of RCS file
DESCRIPTION
An RCS file's contents are described by the grammar below.
The text is free format: space, backspace, tab, newline, vertical tab,
form feed, and carriage return (collectively, white space) have no sig-
nificance except in strings. However, white space cannot appear within
an id, num, or sym, and an RCS file must end with a newline.
Strings are enclosed by @. If a string contains a @, it must be dou-
bled; otherwise, strings can contain arbitrary binary data.
The meta syntax uses the following conventions: `|' (bar) separates
alternatives; `{' and `}' enclose optional phrases; `{' and `}*'
enclose phrases that
Re: Obtaining the files modified/created after a failed/successful build of CVS repository
Spiro Trikaliotis [EMAIL PROTECTED] writes: For example, in my case, I use Windows as an additional server. That is, my main server is on a unixoid machine. However, when I am on travel with my laptop (without network access), I take an rsync'ed copy of the repository with me. This way, I can work offline (read-only!) with CVS as if I would have network access. Of course, I could use the :local: access method for this. However, I like to use CVS the same way as I use it with the real server, this, I am always using the :ext: access method. Additionally, if I go to another machine (and my laptop is around), I use that repository, too. So, in this case, I have to use :ext:. Using :fork: is probably a better solution to your particular need. It acts as client/server without needed to use rsh or ssh transport as :ext: needs. ... - but, as we all know, some developers do not consider :pserver: to be a good idea at the first place, so, this might not be such a big restriction. Yup. I still advocate that :pserver: should be removed or at least never compiled by default... (The authentication business should be left to the operating system and NOT poorly managed by a user-level program like CVS.) -- Mark pgpTrMbh2pVwG.pgp Description: PGP signature
Re: Repository synchronization between two cvs server
If you are using :ext: with 'ssh' as the transport, you may configure compression over the transport by modifications to your $HOME/.ssh/config file. However, by default it does do compression. If you are using :ext: with 'rsh' as the transport, you may wish to consider using the '-z 9' option to heavily compress the data being trasmitted over the wire. As Arthur suggests, if you want good answers to your questions, provide good information about what you are trying to solve and how things are configured. -- Mark pgpbSsTJV40Jz.pgp Description: PGP signature
Re: List of directories under a top-level module
chaitu [EMAIL PROTECTED] writes: I'll go with the new-tarball-every-week idea. What you said makes perfect sense, Todd. Also, do you know if there are any ways to sync up the CVS repository across geographical locations? It would be ideal if I could create a readonly (as in, only checkouts allowed) mirror of the remote repository in my office, and keep this mirror in sync with the remote repository, so that in the worst case, checkouts are really fast... CVSup is good at this. See http://www.cvsup.org/ for details. Examples of CVSup users are the various *BSD distributions. -- Mark pgpHYo2zCU1rv.pgp Description: PGP signature
Re: List of directories under a top-level module
CVS 1.12.9 or newer releases support 'cvs rls' and 'cvs ls' commands. CVS 1.11.x does not support 'cvs rls' or 'cvs ls' at this time. However, a poor man's 'cvs rls' command may be performed using: cvs -nq rlog -R module-name which will list out all of the files under the 'module-name' hierarchy although not in as useful a form. -- Mark pgphKaE36TFix.pgp Description: PGP signature
Re: cvs update error
$CVSROOT/CVSROOT/Emptydir should not have any files or directories present in it at all. -- Mark pgpRlVASo6qv2.pgp Description: PGP signature
Re: cvs 1.11.23 executable available for Windows?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Arthur, Arthur Barrett [EMAIL PROTECTED] writes: Thank you for your comments. ... Also windows users are rather fond of active directory integration which CVSNT provides with the SSPI protocol (though that does require CVSNT server as well though not necessarily on windows). My point of view is that CVS should never be in the business of doing authentication operations. When I use the :extssh: transport, the client connects with the server and does a user login with the server using the appropriate credentials for that server. I even have some operating systems which use LDAP for authentication (OpenLDAP rather than ActiveDirectory in this csae). However, letting CVS (or CVSNT) run as a privileged user is never safe in my opinion (we need to agree to disagree on this topic I guess). I have advocated avoiding :pserver: support for years primarily because I think it is wrong for CVS to do authentication and authorization operations. In the same manner, I am not a fan of any of the other methods which bypass the operating system doing the authentication and authorization of user permissions to do a client/server operation. Indeed. And it is good to direct CVSNT questions to that group. This question was explicitly about CVS and not CVSNT. I still see a not-insignificant percentage of Q's per month specifically about CVSNT on this newsgroup. I think people just assume CVSNT is the windows port of CVS and that the CVS newsgroup is the correct place to go and ask Questions. Yes, and I really do appreciate you lurking here and answering those questions and/or directing folks to the appropriate place. By the way, there are a few things in the CVS 1.12.x 'FEATURE' branch (the main trunk) which include dealing with OpenPGP signatures (GnuPG or PGP) on revisions which you may wish to consider adding to CVSNT going forward. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFIVTxDCg7APGsDnFERAjLHAJ9gvXy8f0c62bxKC6o7cts0Y9zXIACgxSfl GHeHuC02ZWwu72ljKTXIWow= =5eTH -END PGP SIGNATURE-
Re: Latest CVS for Linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Juay Tan [EMAIL PROTECTED] writes: Where can I get the latest version is closer to Unix version like 1.12.23 ? There is no 1.12.23 release, but there is a 1.11.23. The following might work on a GNU/Linux system which uses rpmbuild and rpm: wget ftp://ftp.gnu.org/non-gnu/cvs/source/stable/1.11.23/cvs-1.11.23.tar.bz2 rpmbuild -ta cvs-1.11.23.tar.bz2 Otherwise, you might try looking at one of the rpmfind.net distributions. For example, Fedora Core distributions might find this distribution to be useful: ftp://rpmfind.net/linux/fedora/development/source/SRPMS/cvs-1.11.23-1.fc10.src.rpm Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFIVHOkCg7APGsDnFERAq0aAJ4xMO+n1NOKBRIWwddkU4NhB6QDpwCfexuw cJ8IO9mb0G7hTGbRwIpc1iI= =7qpz -END PGP SIGNATURE-
Re: cvs 1.11.23 executable available for Windows?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nelson Bolyard [EMAIL PROTECTED] writes: I decided it was time to replace my own build of cvs 1.11.22 + my patches with a real released build of cvs 1.11.23 for Windows. So I went googling for it and couldn't find it anywhere. I don't recall exactly where I downloaded my 1.11.22 cvs.exe from (long ago) but I suspect it was from cvshome.org, which is no more. It was partially archived on ximbiot.com but that archive doesn't appear to include the executable downloads. This leads to several questions: 1) Are there any official Windows builds of cvs 1.11.23, (built using MSVC, and not with cygwin), and if so, where? I am not aware that anyone has contributed an offical build. If you wish to contribute the offical build, we can publish it on here: ftp://ftp.gnu.org/non-gnu/cvs/binary/stable/cvs-1.11.23/x86-woe/cvs-1-11-23.zip ftp://ftp.gnu.org/non-gnu/cvs/binary/stable/cvs-1.11.23/x86-woe/cvs-1-11-23.zip.sig after all, you did do most of the work to make 1.11.23 useful to Windows users. 2) What sites would be the best candidates to offer a contributed build of cvs.exe, if someone were to contribute it? In other words, if I was to make a build to be a contributed build somewhere, where would be the best places to contribute it? Feel free to send [EMAIL PROTECTED] a pointer to the cvs-1-11-23.zip and I'll work with Derek to get it published on the ftp.gnu.org site. /Nelson P.S. I want thank Mark D. Baushke for the extra work to clean up the config.h files to further improve the use of system headers on windows. You are welcome. Thank you for your contributions to testing that it works properly on windows. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFIVHU2Cg7APGsDnFERAuPmAJ42rIm+a1DaShf4LMX5ccvQjP/eHACeOyfs xOSi0SVUc7SWC9k1+aJsSsA= =rbsH -END PGP SIGNATURE-
Re: cvs 1.11.23 executable available for Windows?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Arthur Barrett [EMAIL PROTECTED] writes: 1) Are there any official Windows builds of cvs 1.11.23, (built using MSVC, and not with cygwin), and if so, where? Whether using the client or the server I believe most windows users of CVS use CVSNT. Hmmm... having worked with Nelson to get the CVS 1.11.23 sources building and doing the right thing under Windows, I rather think he knows the difference and would have asked the cvsnt group for help if that had been his question. It is certainly true that running a server on Windows, the only choice is either to use CVSNT or to use CVS built under CYGWIN. However, it is not clear to me that CVSNT owns the entire market of CVS clients. I do not have any substantive surveys to prove it one way or the other and I am unwilling to make the claim either way. I would not be surprised to learn that a site which has a mixture of operating systems with a UNIX CVS installation might be using CVS rather than CVSNT as clients under Windows. Note: there is a separate newsgroup for CVSNT. Indeed. And it is good to direct CVSNT questions to that group. This question was explicitly about CVS and not CVSNT. If you must use CVS 1.11 then you are probably best off continuing to build it yourself. To be honest, I believe in building ALL of my applications from source and NEVER using pre-built binaries... this is largely a matter of making sure that I have the possibility of fixing bugs I find in the tools I use with some hope of being able to replace the existing version with my patched version. I will grant you this is not necessarily a common approach. So, if it is typical for Windows users to blindly install binaries on their machines which they did not build, then by all means we should try to give them an 'official' copy of the tool. Enjoy! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFIVHevCg7APGsDnFERArK4AJ91OX24PMaEOb7cYvEge6kozjkLHgCgw6Bo VYhmYdkpKYTzpbCRVxMK27o= =HUwR -END PGP SIGNATURE-
Re: cvs recursive commit pops up an editor between each file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Russ, If you want to have client/server kinds of interactions, then use the :fork: method rather than the :local: method for checking out your files. For example, if you have 'cvs -d /my/cvs/repository checkout foo' right now this is equivalent to using the :local: method as in the command 'cvs -d :local:/my/cvs/repository checkout foo' ... So, if you use 'cvs -d :fork:/my/cvs/repository checkout foo' it will checkout your files using client/server methodologies and you will not be prompted for a log message for each directory of your commit. You could also just use a '-F logmessage' to use a prepared log message file or '-m log message to use a prepared quick log mesasge for your commits as an alternative. Enjoy! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFISmqyCg7APGsDnFERAqrZAKCX6+Z8+qxuWGs63j+yiivKCUbyLACguj76 cl9ycRX26hAqyvLLR3imLWw= =MxLj -END PGP SIGNATURE-
Re: How does a new checked in folder affect other branches/tags?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings Ola Theander, Doing a 'cvs add foldername' will immediately create the a new 'foldername' directory in the repository regardless of the branch in which you were operating. Users on the main trunk will see these new directories if they checkout a new tree or if they do a 'cvs update -d' unless they specify the -P option to prune empty directories. New files added to a branch are only visible on the branch on which they were added. Enjoy! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFISmnkCg7APGsDnFERAhf/AKCq1mjIIb3ROZYtkyQbhWaBo6QD2QCdHMms 8knSTq4SkvFN20GQDvl3Fd0= =OZAf -END PGP SIGNATURE-
Re: Building out of multiple tags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 gounder27 [EMAIL PROTECTED] writes: I am new to CVS (have used clearcase quite a bit). Can we checkout files from multiple tags. Like for example, if I have 1 files tagged may_release and out of those 1 files, I have 100 files which also have tag called patch1. Okay. Can I tell CVS to checkout files with tag patch1 and if patch1 is not present, checkout files with tag may_release? No. I don't want to label all the 1 files as patch1 because for patch1, we only modified those 100 files. In clearcase, this is very easily done through an appropriate config file. I hope it is possible in CVS also. No, it is not possible with CVS. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFIPO8TCg7APGsDnFERAnTbAKCS0vooaJOVxnbWzYqnKrEo48x5SwCfY20r jkDsOKlcZif12r07fyAY5Nw= =EI7C -END PGP SIGNATURE-
Re: Need Basic Help..
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Varun, Varun Dubey [EMAIL PROTECTED] writes: Can you please assist me to know how CVS stores the information about Labels , Branches, Revision History, Checkins information, Metadata used to store all information about the project, user etc..., Basically I want to know how the versions and other important information in CVS Server are managed. Read: http://cvs.savannah.gnu.org/viewvc/ccvs/doc/RCSFILES?root=cvsview=markup and read http://en.wikipedia.org/wiki/Concurrent_Versions_System More information on CVS is available from http://savannah.nongnu.org/projects/cvs There are also a few books on CVS available from various publishers. Good luck, -- Mark rant-on This email message and its attachments may contain CONFIDENTIAL AND PRIVILEGED INFORMATION intended for the sole use of the addressee(s). Email sent to [EMAIL PROTECTED] or info-cvs@nongnu.org will be available to a wide variety of people forever. It is in no way confidential or privileged. If you have received it in error, please contact the sender by return email, notify your system manager and destroy the original message and any copies thereof. Your desires are not binding on me or any other organization that listens to this email address or the associated newsgroup. Any review, use, disclosure or distribution is unlawful. Better contact a lawyer to sue your current legal advisor. They are totally mistaken. Please check this email and any attachments for the presence of viruses. Good advise. The Company accepts no liability for any damage caused by any virus transmitted by this email. This is an interesting legal theory. Who believes it other than your lawyer? The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The Company reserves the right to monitor, review and store the content of all messages sent to or from this e-mail address. www.aztecsoft.com The confidentiality tag to your email is idiocy when sent to a public email list. It only makes both you and aztecsoft.com look foolish. If you are going to post and expect answers to public lists in the future, you might as well get a private email address at one of the sites like yahoo! or gmail. They are cheap and don't have the idiocy of mangling your outgoing email with such drivel. That said, this is the only message from aztecsoft.com I intend to respond to until your 'disclaimer' of confidentiality is removed. Others on the list might respond. /rant-on -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFIODxtCg7APGsDnFERAh5BAJ9PbSqdE+/M5bnlfGvSK/bvESq6yACeK9qq Z9SL/ObUK8ztPooOJXcZyxw= =d7An -END PGP SIGNATURE-
Re: What's the meaning of examining and committing in the response message of the update command?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tony (Wei-Cheng) Tang [EMAIL PROTECTED] writes: I see the example below in the section 7.2. But I don't know what the different between the stage of the examining and committing. Could you kindly explain that? The sources are available, so you could look and see. The first message is when the client-side traversal is happening to determine the files to send to the server and the second is when the server-side traversal is happening to commit the changes to the repository. If you don't want to see those messages, use the command: cvs -q ci -m Removed unneeded files and neither message will be printed. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFILFHQCg7APGsDnFERAvlwAJ4oA0qDAza2Jh18weXWtLLJgVAHFwCfUrtH dze7sNztcXLDkOpOuzI8EEM= =0SBQ -END PGP SIGNATURE-
Re: cvs commit failure for binary file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Pranab, The bug you are reporting has long since been fixed. Here is the src/ChangeLog entry for the fix: 2005-12-06 Mark D. Baushke [EMAIL PROTECTED] * buffer.c (stdio_buffer_shutdown): No longer assert() the fstat(). Use error (0, ...) instead of error (1, ...) to avoid infinite loops. (patch #4678) Patch adapted from Allan L. Bazinet [EMAIL PROTECTED] You may wish to upgrade to cvs 1.11.22 as a LOT of bug fixes have happened over the 17 releases of CVS since your version. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFIGPeRCg7APGsDnFERAkzgAJ9iuiepeFVy9YjhrgM5qrkKXEOPsACdGrcG Gr9EcKd8GwvnIQkaj0iLEEs= =GlHq -END PGP SIGNATURE-
Re: Import source code from a CVS to another CVS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 mosfet [EMAIL PROTECTED] writes: I would like to know if it's dangerous/recommended or not to download source code from one CVS and to import into another. I am a bit afraid because when you checkout source code you a have some .cvs in every folder and I would like to know if it won't interfere with the new CVS where I want to import. If you do a 'cvs import' in a tree which has a CVS directory, the CVS directory and all of its contents is ignored completely. There is no difficulty for CVS to live in a workflow which does a source code import - From one repository to another one. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFH7JQ6Cg7APGsDnFERApklAJ9DmmryqODL38KRgR11+3jwUbOUIACfeF/D 574AJ6Zid2NojjQghErUCHU= =oR4i -END PGP SIGNATURE-
Re: Import source code from a CVS to another CVS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Spiro Trikaliotis [EMAIL PROTECTED] writes: * On Thu, Mar 27, 2008 at 11:46:18PM -0700 Mark D. Baushke wrote: If you do a 'cvs import' in a tree which has a CVS directory, the CVS directory and all of its contents is ignored completely. Is this true even if you perform a cvs import -I!? Yes. CVS will always ignore the CVS directory as a CVS directory inside of the repository is used for cvs edit and cvs watch related control files. This should work fine with cvs 1.11.22 and cvs 1.12.13. There may have been more ancient releases of CVS which did not do the same thing, but I do not recall which ones those would have been. I would never use import without that -I! switch... I understand. I tend to use 'cvs import -I ! -ko -d -X' myself, so that files are only on the vendor branch with the original datestamp and without normal cvs keyword expansion. In some cases, I would then go in with cvs admin and change the -ko to a -kb for the small binary files (e.g., .jpg and .png and *.pdf) that might have come along for the ride and need to be binary to work properly for non-UNIX checkouts. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFH7RgbCg7APGsDnFERArKGAJ9asz5adEJ4D4ScLSFygLnqxREn3wCeNyEo HQUEHjPi0OZBoneRKsCtLoA= =PKTv -END PGP SIGNATURE-
Re: another question on locking...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 EP1 [EMAIL PROTECTED] writes: Using the (now pretty much deprecated) cvs admin, how does a group lock a file? One has never properly used 'cvs admin' to lock a file. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFH6t/yCg7APGsDnFERAvonAKDRxdJBnnSmnH4SEG8TT2c0X3RVPwCfWOI8 JUdTZtQx4dRbiiepPp5M5wQ= =th9w -END PGP SIGNATURE-
Re: locking a module
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 EP1 [EMAIL PROTECTED] writes: Is it possible (i.e., is there a CVS utility to take care of something like this)? In CVS, you may use the commitinfo hook in conjunction with the contrb/cvs_acls* script to perform administrivate lockouts for commits for certain users, module/file, branch tuples. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFH6uB9Cg7APGsDnFERAjysAKDquutbVlZHf6qdIGyGkHEiMM9caQCeJnWa hSFAe2bHyN0Hi7Bj3jJMm+c= =vbao -END PGP SIGNATURE-
Re: Since DST started, cvs update uploads entire sandbox, every time
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Nelson, Thank you very much for your work on this problem. We will look forward to your suggested fix. Note that you may wish to go to the https://savannah.nongnu.org/ https://savannah.nongnu.org/projects/cvs/ and add a new bug report submission: https://savannah.nongnu.org/bugs/?func=additemgroup=cvs and attach your bug fix to that report. This will let other folks who might want to patch their 1.11.22 sources able to have the chance to do it without waiting for cvs 1.11.23 to be released. Thanks, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFH3uj9Cg7APGsDnFERApgpAJ49NcAjD1B7O9Opbm70G+tkWT5tzwCeOSba B6iFCLz8QHsLYP73UGyiQYc= =/VdV -END PGP SIGNATURE-
Re: Since DST started, cvs update uploads entire sandbox, every time
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Arthur, Yup. The problem was around a long time and was fixed in cvs 1.11.19. The fixed code was provided from Chris Bohn with help from J.C. Hamlin and Jonathan Gilligan into the cvs-1.11.19 release in 2004. The following are the related ChangeLog entries in the windows-NT/ChangeLog file: 2004-11-17 Derek Price [EMAIL PROTECTED] * Makefile.am (EXTRA_DIST): Add JmgStat.c JmgStat.h. (Thanks to a report from Chris Bohn [EMAIL PROTECTED].) 2004-09-07 Derek Price [EMAIL PROTECTED] * JmgStat.c, JmgStat.h: New files. * filesubr.c (check_statbuf): Use new Windows mod time routine. (Thanks to a report from Chris Bohn [EMAIL PROTECTED], help from J. C. Hamlin [EMAIL PROTECTED], and a published patch from Jonathan Gilligan.) That said, it is entirely possible that the latest changes in US laws about when the Daylight Savings Time is changed may require that the file be updated. I have no way to test any of the windows API functionality myself and no strong desire to ever develop directly on the windows operating system again. That said, the CVS team stands willing to update the CVS sources to fix this problem if someone who is a Windows developer is willing to provide such a fix and test it. In particular, a fine-grained look at how SystemTimeToTzSpecifiedLocalTime() works will potentially be needed. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFH3UwcCg7APGsDnFERAhtIAJkB/Za8s808ejly2FDULotZl9Yw5ACgvpyM q1BeBbzVAud82wK9iCubVZQ= =9hYu -END PGP SIGNATURE-
Re: Since DST started, cvs update uploads entire sandbox, every time
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Arthur Barrett [EMAIL PROTECTED] writes: That said, it is entirely possible that the latest changes in US laws about when the Daylight Savings Time is changed may require that the file be updated. If that were the case then I would have expected to see more discussion about it on the TortoiseCVS, WinCVS and CVSNT newsgroups - which I haven't. This would be true if CVSNT and CVS happened to use exactly the same code to solve the problem. I honestly do not know if that is true or not. The changes to the DST laws simply altered 'when' the change occurs (which changes every year in Australia and many other countries so has been tested every year since 2004 outside the US). I would have thought that CVS was also being tested, but that is by no means certain as we still receive bug reports from folks running ancient versions of CVS. I really can't see this as being an explanation - unless the CVS 1.11 changes were never complete - I do suppose most windows users use CVSNT. I was under the impression that the cvs 1.11.19+ and cvs-1.12.11+ releases were fine with regard to the red file problem. Of course, I have no direct experience with it myself. (I stopped using Windows in 2000 and have used various UNIX based operating systems exclusively since that time, so I am probably not the right person to give authoritative testimony on what was and was not visible on Windows systems since that time :-) .) If Nelson can test using CVSNT and if the result is that CVSNT doesn't have the problem and CVS 1.11 does - then it's a concrete place for someone to begin looking ;) Sure. Of course the explanation could be non-DST related. I've seen this 'every file stamp wrong' problem when CVS is used with some anti-virus software, also if the client and server clocks are sufficiently non-synchronised it'll occur too. Okay. I have never personally seen this problem at all, so I was not sure what could be driving it given that cvs 1.11.22 did not have any previously reported problems of this kind. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFH3XwOCg7APGsDnFERAvxXAJ0UNHeiohLGDpL4h41nIe+TdEucbwCfWNYN 7czIBx1qum9cvr83VPev2Bg= =1cTc -END PGP SIGNATURE-
Re: Merging while ignoring revision numbers.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frank Petrillo [EMAIL PROTECTED] writes: Is it possible to merge files and ignore the revision numbers/ancestor? One typically does this by doing the merge with -kk rather -kkv on the cvs update line. This causes things like $Id: ... $ to be kept as $Id$ during and after the merge. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFH2pqZCg7APGsDnFERAoPcAKCW5tdDFe+AnIh25RqGBkY9EN0RYQCfQUnR c2OM6gjdY+Enuhe1DTu7+q8= =wV3n -END PGP SIGNATURE-
Re: build a repository out of a set of checkout files?
Hi Ginger, Your plan is not a good fit for the sematics used by CVS. Perhaps you should consider using distributed source control system such as mercurial or git? -- Mark
Re: cvs log ordered by commit
ciol [EMAIL PROTECTED] writes: I would like to know what the official CVS developers think about this. Why cvs2cl is not official? It seems pretty offical to me. It is just not shipped with any CVS releases. The tool would appear to be useful for both the CVS and CVSNT projects and there is active development here: www.red-bean.com/cvs2cl/ (lastest release 2.62 on 2007-04-23) for you to use. Why CVS has not integrated such a possibility? What further integration do you desire? It is a very nice third-party application and works well. What more do you need? What is the correct way the official developers had in their mind? I suppose I do not understand your question. CVS allows its user community to use a concurrent versioning system for sources. It is by no means attempting to force a particular workflow, methodology, or project maintenance mechanism on its user community. If you like the metadata to all be organized into a ChangeLog file, then tools like cvs2cl may prove useful to you. Or, you may wish to use the Emacs 'M-x add-change-log-entry RET' mechanism. Or, you may wish to use a vim macro for this purpose, or you may choose to hack the log_accum script to do something whacky for your commits... Whatever makes you happy... -- Mark Todd Denniston wrote: ciol wrote, On 02/26/2008 01:39 PM: Thanks. I think it's weird it's not integrated to cvs. However, I found that the GNU project maintains also a ChangeLog file: http://www.gnu.org/software/guile/changelogs/guile-changelogs_4.html page summary: Change logs are more useful to the outside than CVS log is, and Change Log must be maintained separately from the CVS log. What is your position on this? I agree with 'change logs are more useful to the outside than CVS log is'. I disagree with 'Change Log must be maintained separately from the CVS log'. I put good comments in CVS log (commit comments) and cvs2cl turns that into a good ChangeLog. Now where someone could easily disagree with me is when a non-technical person is looking at that change log, and in that case I say they are not looking for a change log, but a change SUMMARY. I generate change Summaries by reading the cvs2cl generated change log and trimming it down, i.e., the change Summary should not contain an entry for every commit. Of course the above is my opinion only. :) Todd Denniston wrote: ciol wrote, On 02/25/2008 08:56 AM: Hi, how can I see cvs logs ordered by commits (and time), not by files? Please CC me as I am not subscribed. Thank you. Do you mean like: Yes. http://www.red-bean.com/cvs2cl/ChangeLog-basic.txt or this: http://www.red-bean.com/cvs2cl/ChangeLog-tags-revs.txt or this: http://www.red-bean.com/cvs2cl/ChangeLog-the-works.txt Then try cvs2cl (cvs to change log). http://www.red-bean.com/cvs2cl/ BTW, if you are on windows instead of Unix, you may need to use cvs2cl.py that comes with CVSNT instead.
Re: Need one shot post-commit hook in cvs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Arthur Barrett [EMAIL PROTECTED] writes: If you use loginfo in the admin directory to setup a script to be called post commit, it can be called multiple times. I need a way to have a single commit event only call the post commit hook script just once even if multiple files are being checked in. Which version of CVS are you using? I know CVSNT has had postcommand and postcommit for some time, and I think CVS 1.12 now has one or both of those as well. Sadly, neither the 1.11.x (STABLE) nor the 1.12.x (FEATURE) branches of CVS support the postcommit trigger. Currently supported triggers are: Supported in both STABLE and FEATURE: commitinfo loginfo notify taginfo verifymsg Supported in FEATURE: postadmin postproxy posttag postwatch preproxy If a 'cvs add directory-name' or a 'cvs import' is being performed, then the loginfo script is run once, but you can tell from the arguments '- New directory' and '- Imported sources' respectfully, that this is what is happening. The typical method to use to get what you want is to have your commitinfo trigger remember the list of directories being traversed (especially the last directory) and then when the loginfo script is run and gets to that directory, do the task you need to be done only once. For examples of how to do this, the CVS distribution has examples in cvs-1.11.22/contrib/commit_prep.in cvs-1.11.22/contrib/log_accum.in or cvs-1.12.13/contrib/commit_prep.in cvs-1.12.13/contrib/log_accum.in which get built as contrib/commit_prep and contrib/log_accum -- Mark PS: It is anti-social to ask questions of the [EMAIL PROTECTED] mailing list without a valid email address. The original user's use of From: Mark [EMAIL PROTECTED] is such that I would not have replied to him at all had not Arthur asked the question of CVS to the list. 'Free' email addresses are still easy to obtain. I suggest you may wish to get one if you wish to ask future questions of this list, so that private exchanges of clarifying questions may be taken off-list if that is appropriate. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFHu9EaCg7APGsDnFERAqjbAKCBty1MCcugl+gcaFvg1DnnkVhEjQCfVfAc rP0mVMkfqt5cgm9mCWHfnt8= =IsK3 -END PGP SIGNATURE-
Re: how to get list of projects in cvs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 harcrelc [EMAIL PROTECTED] writes: What's a command to get a list of all projects in my current cvs repo? If you have a new version of cvs on the server, then 'cvs rls .' is a fine idea. Otherwise, a hack might be to do this: mkdir dummy cd dummy cvs co -l -d top . cvs -n up -d : you should now get a 'cvs update: New directory name -- ignored' : kind of output. The list of name directories is your top-level : modules. I use cvs across the network, so.. I would like to be able to get a list of the dirs in cvs root in another machine.. really. A way to get a list of all modules with ,v files in the repositiory would be to use the command: cvs rlog -R . which should list out all of the ,v files in the repository. The directories will be on lines whichbegin with 'cvs rlog: Logging ' Enjoy! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFHPIdaCg7APGsDnFERAvzcAJwKxUcD2NYHSkROoKaahTCe7rGrmACgnkK5 jYBzc2toRQKSGyIJEfxoqUk= =pNDV -END PGP SIGNATURE-
Re: Lock question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Simon Renshaw [EMAIL PROTECTED] writes: The lock file look like #cvs.rfl.castor-srvr4.benchmarkcanada.com.19844 and is owned by simon. That's my username. If process 19844 is still running on your CVS server, then you might want to kill it and remove the lockfile. If the process is not running, you may just remove the lock file. The lockfile is created when you are doing a checkout or other read-only operation (e.g., cvs update). Each dev use his own username and since I'm not a dev I don't usually commit stuff. Sure, but write locks are of the form #cvs.wfl.host.dom.ain.123456 But, there is a Windows machine running Cruisecontrol with CVSNT 2.5.03 that uses my name to check CVS for changes. Could it be the cause of the lock? Yup. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFHM8eXCg7APGsDnFERAgSGAJ9yVK7iVaBFQSIEqGVOjGWeoBQnLgCaA4I6 ES3CQIJhFBkWUZnXNo0BB/k= =YscY -END PGP SIGNATURE-
Re: How to diff branch sandbox against tip of trunk?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Larry Jones [EMAIL PROTECTED] writes: Someone (whose name escapes me at the moment and I'm too lazy to go look it up) was working on a patch to add magic tags for things like the trunk and branch roots, but it never quite got finished. I'm not sure what the current status is. You are probably thinking of the patches that Frank Hemmer [EMAIL PROTECTED] submitted. See also https://savannah.nongnu.org/patch/?4443 https://savannah.nongnu.org/patch/?4809 I don't recall how far away that code was from being able to be used, but it was a newtags2 branch in the CVS repository. Modifiers to tag names included: .base .head .root .origin .prev .next .commitid WIth some discussion of a .trunk to also be added. So, -r.trunk.head would give you the head of the main trunk. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFHM8OPCg7APGsDnFERAnqBAJ9ERrmS/5ppa2plj9AZRYOq1KO40ACg03i+ 3wacxRDlxIIo+g1GGWHrQj4= =Ti9c -END PGP SIGNATURE-
Re: Lock question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Todd Denniston [EMAIL PROTECTED] writes: 2) everybody is using extssh. Ok, that sounds like a CVSNTism, unless unless CVS-1.12.X has picked it up. The :extssh: method was added to CVS in cvs 1.12.13. The NEWS file says this: | * Thanks to a suggestion from Joseph P. Skudlarek [EMAIL PROTECTED], an |:extssh: has been added as a synonym of the :ext: access method, as a |kindness to users of old version of Eclipse. Basically, it just assumes :ext: and CVS_RSH=ssh exist for the connection. That said, I believe the eclipse cvs client is written in Java. I do not believe it is a very well written client as it tends to stop working when anything slightly out of what it expects shows up in the transactions on the wire. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFHKOgXCg7APGsDnFERAl8yAJ9xUZrTRo5noOmkO8sMJQrGhrK56wCgjrpI 4AZ3IK2O8iULOmSooYHzR7Y= =QD7S -END PGP SIGNATURE-
Re: how do I notify of certain branch got commit ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 shagdelic [EMAIL PROTECTED] writes: Instead of get notification of commit to certain directory, how do I get notification of commit to certain branch ? I searched a little bit and looks like most topic is about the 1st scenario, i.e., certain directory. Thanks a lot, Just hack your log_accum script to pay attention to the branch and only send email if it is the certain branch. A 'cvs -Qn status' command on the files being committed should give you the branch being used. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFHIrO8Cg7APGsDnFERAtokAKCdd8DxK6WOrpaSgyZpfD8EZr8LWQCg2CQB jQYmxRvvl1wKi2ZZrYru8zQ= =sVyk -END PGP SIGNATURE-
Re: CVS Commands
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Todd Denniston [EMAIL PROTECTED] writes: `cvs ls` and `cvs rls` I suspect are CVSNT commands, so if you are having trouble with those you will get better help in the CVSNT list. fwiw: The 'cvs ls' and 'cvs rls' commands are also available in cvs-1.12.8 and newer versions of the FEATURE branch and should interoperate properly between CVS and CVSNT clients and servers. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFHGprlCg7APGsDnFERAvL7AKCf4lCU5brhtfT6RoEMeWBzOo/ULgCfVh1o Z4MxdIsdDeRlAj0e4rtbr9g= =RGas -END PGP SIGNATURE-
Re: restrict commits of single file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Standard CVS has two triggers which are run before the commit happens and one that runs after it. These are called commitinfo, verifymsg and loginfo. The contrib directory in a cvs release contains a perl script called cvs_acls.pl the documentation is cvs_acls.html in that directory... See the URL: http://cvs.savannah.nongnu.org/viewvc/ccvs/contrib/?root=cvs The cvs_acls script will stop at the first match, so you want to use the logic of deny for everything and then adding allow for everything except the file you want to allow. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFHDFjvCg7APGsDnFERAtPNAKCm3qkqAlY0CVjOBQbml2F0jIkQ9QCgheUE XkNPrGyFWn/8dNMowvsBuGs= =JITV -END PGP SIGNATURE-
Re: CVS Branch Permissions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jyothish Vidyadharan [EMAIL PROTECTED] writes: I want to set up things so that a user has write permissions to just one branch and read-only permissions for the other branches. How do I set this up?? For cvs-1.11.x or cvs-11.12.x, read this URL: http://cvs.savannah.nongnu.org/viewvc/*checkout*/ccvs/contrib/cvs_acls.html?root=cvscontent-type=text%2Fhtml If it does what you want, then download and configure (fix @PERL@ references to use your /usr/bin/perl path) and install it in your $CVSROOT/CVSROOT along with a CVSROOT/avail file and then add it to your CVSROOT/commitinfo trigger. http://cvs.savannah.nongnu.org/viewvc/*checkout*/ccvs/contrib/cvs_acls.pl?root=cvscontent-type=text%2Fplain Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFG/RUICg7APGsDnFERAlXJAKCtkKcIwKM1vhCwJuKLux4XtLPIEQCg1i+4 f/Mp/WA98Ht8JfQ7Zn49raU= =SnQd -END PGP SIGNATURE-
Re: Trying to use pam.d with CVS 1.12.13
Hi Guido,
Your problem could b related to bug#14721 (setting PAM_RHOST to the
remote ip of the connected client). If so, the patch you want follows my
.signature.
-- Mark
cvs diff -up -r1.450 -r1.451 server.c
Index: server.c
===
RCS file: /cvsroot/cvs/ccvs/src/server.c,v
retrieving revision 1.450
retrieving revision 1.451
diff -u -p -r1.450 -r1.451
--- server.c3 Oct 2005 19:33:45 - 1.450
+++ server.c16 Oct 2005 18:17:07 - 1.451
@@ -109,6 +109,7 @@ static char *Pserver_Repos = NULL;
# endif /* AUTH_SERVER_SUPPORT */
# ifdef HAVE_PAM
+# include netdb.h /* getnameinfo */
# if defined(HAVE_SECURITY_PAM_APPL_H)
# include security/pam_appl.h
# elif defined(HAVE_PAM_PAM_APPL_H)
@@ -6891,6 +6892,27 @@ check_pam_password (char **username, cha
int retval, err;
struct pam_conv conv = { cvs_pam_conv, 0 };
char *pam_stage = start;
+struct sockaddr peer;
+int len;
+char host[NI_MAXHOST];
+
+/* get the client's ip address */
+len = sizeof (peer);
+if (getpeername (STDIN_FILENO, peer, len) 0)
+{
+ printf (E Fatal error, aborting.\n\
+error %s getpeername failed\n, strerror (errno));
+ exit (EXIT_FAILURE);
+}
+
+/* convert the ip address to text */
+if (getnameinfo(peer, len, host, NI_MAXHOST,
+ NULL, 0, NI_NUMERICHOST) 0)
+{
+ printf (E Fatal error, aborting.\n\
+error %s getnameinfo failed\n, strerror (errno));
+ exit (EXIT_FAILURE);
+}
pam_username = *username;
pam_password = password;
@@ -6906,6 +6928,12 @@ check_pam_password (char **username, cha
if (retval == PAM_SUCCESS)
{
+pam_stage = set remote host ip;
+retval = pam_set_item (pamh, PAM_RHOST, host);
+}
+
+if (retval == PAM_SUCCESS)
+{
pam_stage = authenticate;
retval = pam_authenticate (pamh, 0);
}
Re: can the CVS directory be moved/renamed ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gal Vardi [EMAIL PROTECTED] writes: Is there a way to eliminate, hide or keep the ./CVS directory away from the current directory ? Nope. Either hide it with a dot, under .CVS or keep it at some other place like ~user/CVSdirs/some_relative_path ? Nope, CVS does not allow that particular customization. That said, the sources are open and you may pervert them in any way you desire. Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFG6BITCg7APGsDnFERAo3vAKDvlY9eH15Ivu7ffTyd0ZDVSa7D5gCffpus Dw7ZC+uj4jA5wLF7ZrajyV8= =C9Wy -END PGP SIGNATURE-
Re: Reading log info of the last revision on a given branch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 nandan cn [EMAIL PROTECTED] writes: Was looking for a cvs command line, where Given a file name and branch name, want the *log message* of the latest revision on that branch. Tried some of the cvs log commands , but couldn't get what i was looking for Given: CVSROOT :ext:host.dom.main:/path/to/repository filename module/subdir1/subdir2/file1.c branch mybranch cvs -d :ext:host.dom.main:/path/to/repository \ rlog -rmybranch. -N module/subdir1/subdir2/file1.c will give you the log message LAST revision for the 'mybranch' branch. The '.' at the end asks CVS for just the last revision. The -N supresses all of the other tags. The module/subdir1/subdir2/file1.c is the pathname you might use to checkout just the file1.c sources in your local tree. If you are already in a checked out tree, then going to the module/subdir1/subdir2 directory you should be able to use: cvs log -rmybranch. -N file1.c to get the same information. Enjoy! -- Mark $ cvs -H log Usage: cvs log [-lRhtNb] [-r[revisions]] [-d dates] [-s states] [-w[logins]] [files...] -l Local directory only, no recursion. -R Only print name of RCS file. -h Only print header. -t Only print header and descriptive text. -N Do not list tags. -S Do not print name/header if no revisions selected. -b Only list revisions on the default branch. -r[revisions] A comma-separated list of revisions to print: rev1:rev2 Between rev1 and rev2, including rev1 and rev2. rev1::rev2 Between rev1 and rev2, excluding rev1. rev:rev and following revisions on the same branch. rev:: After rev on the same branch. :revrev and previous revisions on the same branch. ::rev rev and previous revisions on the same branch. rev Just rev. branch All revisions on the branch. branch. The last revision on the branch. -d datesA semicolon-separated list of dates (D1D2 for range, D for latest before). -s states Only list revisions with specified states. -w[logins] Only list revisions checked in by specified logins. (Specify the --help global option for a list of other help options) $ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFG3uqfCg7APGsDnFERAuzMAJwL5Sy9gxr/rsEuA9T+hoVROqHhFwCfUOFr HKHhK3cQbno9BezrC3ibn4A= =CNPT -END PGP SIGNATURE-
Re: Up-to-date check failed for binary file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Velevitch [EMAIL PROTECTED] writes: On Aug 5, 10:14 pm, Chris Velevitch [EMAIL PROTECTED] wrote: As I understand it, the error 'Up-to-date check failed' indicates that the repository version is newer than the workspace version. Yes. A 'cvs update' will checkout try to update the file revision in your local checked out tree. However, this file is a binary file and I know it's the current version. In my way of thinking, the repository is wrong for this file. How do I fix it? What does a 'cvs status' say? Is there really a newer revision in the repository? If so, what does a 'cvs log' say about that revision number? I suggest you checkout that file in a separate tree and examine it to see for sure. If you think you understand what is happening, you are probably wrong, but you could do something as simple as mv file file.save cvs update file mv file.save file to destroy the evidence and really screw up whoever had committed the revision you didn't like. This is a bad solution most of the time. Also, the file is 3.5Mb in size. Is there any size issues for binary files? For some operating systems there can be problems with files in excess of 2GB. This could be either the ,v file on the server or the individual revision on the client. Those systems need large file support to get files bigger than 2GB in size. A 3.5MB file should not be a problem. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGtsrFCg7APGsDnFERAlLTAKDCPZSTUlqLXFN6urtg36oNhUM89gCfWiBA vlh2xRsiBkyn2Y+nAU/ayRM= =R7lh -END PGP SIGNATURE-
Re: Determine Branching Date
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Connolly [EMAIL PROTECTED] writes: On 7/29/07, ehchn1 [EMAIL PROTECTED] wrote: I would like to find out whether it's possible for us to determine the exact date for a branching done in CVS. CVS does not normally keep this information for you. If you use a history configuration to track rtag commands, then the 'cvs history' command will be able to give you some information. You may also write a taginfo trigger to keep track of when a tag operaton is performed. The basic problem is that you may do anything to your tree with regard to mixing explicit date stamps and branches to checkout something that you wish to tag. Also, tags may be added to files or deleted from files long after the rest of the files have been tagged. If you know that you did a single branch tag of a tree that was nominally up-to-date, then using a tool that analyzes the 'date' of all of the revisions in your repository would give you a window of time during which your tag was created. The time will be no earlier than the most recent commit to the parent branch of the tag which your new branch can see and no later than the first revision committed to the new branch. Tools such as cvs2cl (see www.red-bean.com/cvs2cl/) have options to help you find this kind of information. Reason is that I didn't keep track of the branching date, so hopefully CVS would have such information. I've not been able to figure this out either. As a result, I include the date as part of the tag or branch name. Generally, I put down a revision tag on the sources in a tree that is known to build and be what I want and then use an rtag to branch from that revision tag. The addition of 'LogHistory=TMAR' ensures that my 'cvs history' command will locate the dates where a 'cvs rtag' operation was run (the 'T' records rtag operations). The typical naming convention I use is given a 'branch-name' the tag I use is 'branch-name_BP' where the _BP is for the branch point. Enjoy! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGtJ9rCg7APGsDnFERAmepAKCQqJM2Lj4AEmJJs3SfWnMTx9+j2ACg16Fg HinIeQb58uY00amZaZ4S9eU= =HGSV -END PGP SIGNATURE-
Re: Branching Practices
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I favor doing development on the main trunk. Branches are use ONLY for bug fixes and stabilization. A branch is made from the main trunk to throttle the flow of changes to increase the stability of the code in the branch. At some point, it is time to take another branch to be a release candidate. These release candidate branches will probably never have more than a handful of patch made to them as the result of a final QA testing effort. The throttle branch will be used for new minor releases over time and each minor release will be handled by committing the minimum amount of change needed to fix a problem. As it gets closer to time to freeze a release for more serious testing, it becomes time to create the throttle branch. Now, every bug found on the throttle branch gets committed first to the main trunk to find a long term solution. If the fix seems to work properly, then it is applied to the throttle branch. If there is already a release candidate, then the patch is applied to the release candidate branch if it seems to do no harm on the throttle branch. By doing successive commits to the other branch, the quality of the patch may become better and therefore reduce the churn of the final patch that gets applied to something that is closer to being released to a customer. Generally, only bug fixes found by unit and system testing get fixed in the branch and only bugs that directly impact quality go into the release candidate branch. That is, if you do not have a test for it, you don't fix it in the branch and if you don't have a bug that will directly impact funcationality for the customer, it does not go into the release candidate. So, if a bug is found that is judged not to be acceptible risk to put into the branch after it has been tested in the wilds of the main trunk, it is only fixed in the main trunk and it will have to be some other patch which is less risky or no patch at all which gets applied to the throttle branch. In a similar manner, the quality bar should be higher to get into a release candidate. Any new feature gets put into the main trunk. If there is a strong need to port it to a minor release, then it gets ported to the throttle branch first before it is ever even thought about being merged into an existing release candiate. The time between when a release candidate branch is pulled and the time when the release is made should be as quickly as possible with as few changes as possible. The idea here is to have a very tight window between when the first release candidate is made and when the final product is shipped. Although, it is possible that multiple release candidates may be needed. The above mechanism assumes that the main trunk is always the next major release and the throttle branches off of it will be major releases. The branches off of the throttle branches will be minor releases and if necessary there may be multiple patch releases off of a minor release (that is, you could refine things by creation of yet another level of branches). So for example, I might have a top-of-tree main trunk that I consider release 7.x, the branch tag RELENG_6 might be for the 6.x major release, the RELENG_6_2 might be the second branch off RELENG_6 and hold the sources for the 6.2 release. Enjoy! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGsDPbCg7APGsDnFERAl5LAJ9Glaksb+Bw7Bv//PMKy4h3kThVZwCfST7V 4Eohisj0coWIRAMZVjaRT5s= =jwfJ -END PGP SIGNATURE-
Re: Mismatching versions in Entries file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Franke [EMAIL PROTECTED] writes: L.S., I have a copied website tree on a server which was copied from an old server, all the files where checked out from CVS. The CVS root from which these files where checked out is gone and the files have been reimported into a new CVS tree but now the versions in the Entries file in the CVS directories are higher than the versions in the new CVS tree. Unless all of the intermediate revisions were put into the 'new CVS repository', you have nothing that will help you. Is there a way to resynchronize the Entries files so that cvs up will work again? I've already thought about rechecking out the tree but this isn't an option for the developer. If you know that the checked out website files were the latest revision of files in the repository, then you could checkout a separate tree with whatever is at the top-of-tree for the new repository and then replace those files with a copy of the website files and 'cvs commit' them to the new repository and work forward from there. If they were not the latest, then you might wish to create a branch to put the website files into the repository. Either a new vendor branch or just a branch of the top-of-tree and then replace all of the files from the checked out tree with the website files. In any case, there is no way to easily map the files into a separate repository which is what you really have on your hands now. Actually, I suppose it might be possible to take SHA1 hashes of the website files an compare them with the SHA1 hashes of every revision in the repository until you find a match for which revision in the repository matches one of the website files. Then you could tag the revision you found and generate diffs and merges later based on it. Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGpifdCg7APGsDnFERApGAAJ9+A/q+za5O9Qv+/pBLekZtoq9JcgCgv7jQ kxgILZ/wll8kzPREfX5sj6k= =Fvnu -END PGP SIGNATURE-
Re: difference between commit and checkin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Mario, [Please note that use of invalid Email addresses in posing questions to the info-cvs group is considered bad manners. It is easy enough to get free email addresses when you want to ask questions. Please do so in future as I suspect that [EMAIL PROTECTED] may not be a valid email address...] _mario.lat [EMAIL PROTECTED] writes: what is the difference between commit and checkin? There is no difference. cvs commit # the name of the cvs command cvs ci # a name familiar to RCS users (the RCS 'ci' command) cvs com # a unique substring of commit all cause the same action which is the equivalnt of the RCS 'ci' (also known as the RCS 'checkin' command) command be run for each of the files that have changed. In a similar manner, the names of the commands to perform a 'cvs checkout' are also known by the following names: cvs checkout # the name of the cvs command cvs co # a name familiar to RCS users (the RCS 'co' command) cvs get # a name familiar to SCCS users(the 'SCCS get' command) I hope you find answer this useful. Enjoy! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGdBaSCg7APGsDnFERAnvKAKCspb+gXuG1OkPVHCTsn9P0qAlZxACgzqPj 2qzBXRxJKfynSPkg0dqAL5E= =yrg7 -END PGP SIGNATURE-
Re: Memory error while committing...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 James Depaul [EMAIL PROTECTED] writes: I've asked the Unix Admin to bump up the security limits file for us as follows: data = 524288 rss = 131072 stack = 131072 I've tried it again after re-logging and the same error persists - giving up. Is there another way: could I delete the file OUTSIDE of cvs and do some cleanup afterwards?! I really think the unusually large size of the file is the culprit here. Advice will be welcome - Moving the ,v file out of the repository would stop the problem. You could try using the RCS 'co' command to checkout particular versions of the file. It might have a slightly smaller memory footprint than cvs. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGYmO/Cg7APGsDnFERAn7rAKDPCAB2q8jphYOnf8Eg3MjOF4TsbACeP9Ao 4yqOBwKtej9KzLr2CZNGDLQ= =Ub2S -END PGP SIGNATURE-
Re: gssapi problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yves Dorfsman [EMAIL PROTECTED] writes: In our environment, a lot of the clients are on MS Windows, and gserver works fine. But when they do not logout of MS Windows for a few days, they get the following error message when they try to update or commit: GSSAPI authentication failed: No credentials are available in the security package I would expect this kind of error at such time as the ticket-granting-ticket (TGT) expires or if the cache has been deleted by some other process for some reason. If they log out and back in from MS Windows, then it works fine with gserver again. It doe not happen with any other software, only with CVS. I have never used an MS Windows Kerberos environment. Are you certain that the other software is really using GSSAPI? It is entirely possible that the other software has a cache of the user's password and/or is not reauthenticating on every connection as is done by CVS. For example, just mounting a file share may never be reauthenticating itself with the server. Anybody has seen a behaviour similar to this ? For only CVS? No. I have not seen this occur with only CVS executables. I have seen the kind of error you mention when the current credentials could not be renewed on the KDC or when the KDC policy had a hard time limit on authenticated credentials which had expired and not been renewed. If the ticket-granting-ticket (TGT) expires, then you should be able to renew it with a command like 'kinit' (At least, I suspect there is also a 'kinit' command your MS Windows users could use for this purpose.) If you have a 'klist' command which works, you will see output something like this: $ TZ=UTC; export TZ $ date Sun Jun 3 14:43:45 UTC 2007 $ klist -5 Ticket cache: FILE:/tmp/krb5cc_29543_PzbBs19284 Default principal: [EMAIL PROTECTED] Valid starting ExpiresService principal 06/03/07 10:34:46 06/04/07 00:34:46 krbtgt/[EMAIL PROTECTED] 06/03/07 10:34:48 06/04/07 00:34:46 afs/[EMAIL PROTECTED] 06/03/07 10:34:50 06/04/07 00:34:46 daemon/[EMAIL PROTECTED] $ w mdb 2:44pm up 114 day(s), 7:36, 15 users, load average: 0.04, 0.04, 0.04 User tty login@ idle JCPU PCPU what mdb pts/222:34pm1 w mdb $ In the above case, the login time was 2:34pm UTC and the expire time occurs six hours after the time of the login. If I am not able to renew my krbtgt after the six hours, then I would expect the kind of error you are seeing. I would then need to run the 'kinit' command to either renew or regenerate my TGT. Normally, a renew should just work fine and should have been transparent as long as the KDC is configured to allow it. If you want to try to reproduce the problem, then using a 'kdestroy' command to destroy your credentials followed by running the CVS command should give you the same kind of error. This problem is really outside of the scope of CVS as such as I would expect the same kind of problem to arise for any kerberos application which needs access to a new or renewed TGT. Hmmm... A quick google of the error finds a similar problem replicated here: http://rcmail.vintela.com/pipermail/putty/2005-August/29.html wherein there seems to be an issue with Microsoft's SSPI. The GSSAPI layer of SSPI apparently will only provide applications with the original ticket, even after the client has renewed their ticket. Apparently Windows XP SP2 needs WindowsXP-KB885887-x86-ENU.exe installed. Check Microsoft Knowledge Base article KB885887 for possible links to the .exe If that fails, I urge you to contact the folks that run your KDC to see if they can help you better. Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGYtm9Cg7APGsDnFERAojWAKDeuKOkR5ZB8gSwmaYj9w5nB7EeNgCfRh0S T7bkMnJ2IRo0YWSxTy2S3+A= =+RAr -END PGP SIGNATURE-
Re: Memory error while committing...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 James Depaul [EMAIL PROTECTED] writes: We are using CVS 1.11.17 (client/server) on AIX 5.3 I spoke with the server admin and he tells me that the OS is in good shape in case of heap size - see below. Do we need to specify some CVS admin parameters to increase the heap size that CVS is using on the system? Could someone comment please - we are still getting the same error while commiting: cvs [commit aborted]: out of memory; can not reallocate 33894405 bytes Here is the memory status on the box itself: ...elided... Suggestions would be welcome. ...elided... Hi James, It is my recollection that under AIX, there are per-user limits as to how much memory a single process may consume. It may be that the user(s) running. You may wish to have your system admin look at /etc/security/limits but my recollection was that 256MB was the maximum possible for data and stack to grow. I don't have easy access to an AIX 5.x box right now, but a FreeBSD 4.11 box I have around here has an /etc/login.conf file wherein there are attributes for various classes of users as to the cputime, datasize, stacksize, memoryuse, openfiles, vmemoryuse and other similar knobs. So, I would need to ask you if the problem is that your user is running into a problem with allocating an additional 32MB because that user is running close the the per-user limits imposed by the defaults set by your administrator. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGXFbBCg7APGsDnFERAniBAJ9hXraVM8A5JMClpkoh/lCptP9vEgCfRSxw NAGVT4Mse3koT4qhaxNZUIY= =vrhn -END PGP SIGNATURE-
Re: Memory error while committing...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 James Depaul [EMAIL PROTECTED] writes: We have a sizable Word Document in a directory that we're try to remove - each time I delete the file and try to commit it I get the following error: commit -m Deleting file permanently for R meeting/minutes/Automated eSD Deployment Toolkit (ADT) Detail Design - Web App Component v1.1.doc Removing meeting/minutes/Automated eSD Deployment Toolkit (ADT) Detail Design - Web App Component v1.1.doc; cvs [commit aborted]: out of memory; can not reallocate 33894405 bytes How do we get around this memory allocation error? Add more virtual memory (aka swap space) to your server. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGV+1BCg7APGsDnFERAidtAKDSOEbbRU7dU/Bm2v4u/RT4KzQ2gwCfdn9+ 7usJ6l1/CP9SJsNl3qiwoDA= =pxlk -END PGP SIGNATURE-
Re: Deleted tags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wells, Timothy L. [EMAIL PROTECTED] writes: I was wondering if there is any way to find out when and who deleted tags from a file? Is there any type of log file for tags kept in CVS? If you are using a 'CVSROOT/taginfo' file with logging for tag operations, then you are in luck. Otherwise, if they removed the tag via a 'cvs rtag' command, you may have information in your history file depending on the CVSROOT/config you have for the LogHistory attribute. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGV+3GCg7APGsDnFERAloOAJ9CY1uN+CeqlkCXUH8I4TzrqqixwwCg4159 jNJZZkKomcyzP8d/qwNkoQk= =foBx -END PGP SIGNATURE-
Re: Working copy from CVS Respository Dump
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 MossAndLichens [EMAIL PROTECTED] writes: I have a CVS Repository Dump with many files and subfolders. I need to a get a working copy of this CVS Dump. I have a TortoiseCVS Client. Should I have a local CVS Server to host the dump so that I may get a working copy? I do not understand what you mean by a 'CVS Repository Dump' as that is not something that CVS uses or creates. If you mean that you have a clone of a cvs repository or a backup copy of a cvs repository you are trying to use, then that might be more useful to know. Are you using cvsnt? If so, then asking on http://www.cvsnt.org/ may be more useful than asking here. This forum is primarily for discussion of the command-line versions of CVS rather than CVSNT or the various GUI programs which may be used with either CVS or CVSNT repositories. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGV+60Cg7APGsDnFERAtQBAKDKDiDwn7qtiDuOMNlNPLaCCxYXowCfXS5u B8KEjhdLDjTWXs5HmeWkx5k= =G1Ti -END PGP SIGNATURE-
Re: Wincvs error: GSSAPI authentication failed: The specified target is unknown or unreachable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nick Wales [EMAIL PROTECTED] writes: I have a fully working linux kerberized CVS implementation. So I can checkout, update etc using the gserver implementation. I've started to try out some windows clients now, but with little success. I have the MIT kerberos network identity manager running, with a valid ticket. Now when I'm running the same command I run successfully from the linux machines, i.e. cvs -d :gserver:hostname:/var/cvs checkout test I get this message GSSAPI authentication failed: The specified target is unknown or unreachable Can anyone shed any light on why this might be happening? That error will arise if hostname does not result in a valid credential. In this case, the gsp_display_status() function is returning 'The specified target is unknown or unreachable' as the error description returned by the gss_init_sec_context(). It seems possible that the kerberized windows client is falling prey to the differences between GSSAPI implementation on Windows and non-Windows machines. I am not up-to-date with the variations of GSSAPI that exist out there, so you may need to find someone who understands those differences on an application level outside of the CVS application itself. Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGV/F6Cg7APGsDnFERAjXRAJ0Xjnw725Dfr5b2JCGqpQQf4NuzYwCgtStx rbIq44HSYAELjIs/HNOW8II= =Y5+v -END PGP SIGNATURE-
Re: Permission denied when checking out from kerberos client
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Nick, If you are trying to specify a local username of nick.wales, then you may need to patch your cvs sources to properly handle this. There is a patch here: http://savannah.nongnu.org/bugs/?17083 for both cvs 1.11.x and cvs 1.12.x which may be able to help you upgrade your client and server versions of CVS to do what you want. At present, the nick.wales part is not being used at all and so you are stuck with just a cvs/cvs2 as the name it is trying to validate. In addition, the lack of being able to find a KDC for the realm suggests that there may be a problem on cvs2 with locating the KDC realm. You may need to use a fully qualified domain name for cvs2. It appears to be using the loopback address and unless you are using a host which is running its own KDC, that will not lead to good things. Good luck, -- Mark Nick Wales [EMAIL PROTECTED] writes: Still having issues with this... Now trying to run the gserver command from the local machine and getting a more obvious error. This is from the client end the KDC is definitely available, as I have just got a kerberos ticket using kinit. klist shows that the ticket is valid. [EMAIL PROTECTED] gservertest]$ cvs -d :gserver:[EMAIL PROTECTED]:/var/cvs checkout test cvs checkout: GSSAPI authentication failed: Unspecified GSS failure. Minor code may provide more information cvs [checkout aborted]: GSSAPI authentication failed: Cannot find KDC for requested realm The syslog shows this error. May 16 17:06:22 cvs xinetd[3251]: START: cvspserver pid=4051 from=127.0.0.1 May 16 17:06:22 cvs xinetd[3251]: EXIT: cvspserver signal=13 pid=4051 duration=0(sec) Any ideas? Nick -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGWG7ZCg7APGsDnFERAkrVAJ9hZtSPtKMpRQL4+RzUDIsEysVWDQCeJ/mM M5Url6vSlJHV6CRANRNG+WU= =XG/A -END PGP SIGNATURE-
Re: Two different locations using same CVS server, takes longtime to check-in some stuff, any other idea?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 GS [EMAIL PROTECTED] writes: We are using CVS to keep repositories, we are working at Two different locations (using one CVS server), taking lot of time even if we want to add couple of new files, this is scienario: I believe you have a terminology problem. A repository is typically specified as a (connection method, hostname, pathname) tuple to a hierarchy of files stored in RCS ',v' format. A CVS server is typically the ability to run one or more processes on the hostname using the particular connection method which is used to provide access to the repository pathname. We have one CVS server located at primary location called, location1, we have another location called location2 in different timezone, we have software development groups at both locations on same project, the team at location2 connect to location1 using VPN (once VPN up, they can access all servers), then check-out code onto one of the Linux machine at location1, then transfer this code into location2, compile it and make some changes and then tar the whole directory and upload onto one of the Linux machiene at location1, then check-in to CVS, this is taking lot of time, any other solutions can some expert suggest. The most common method to do this is to use the SSHv2 protocol with the :ext: or :extssh: connection method to connect to the CVS server hostname and checkout the files from the repository to the client. If you are not able to directly use an SSH client (GNU/Linux distributions typically use OpenSSH to implement the 'ssh' client/server protocol), then you may be able to use a proxy server we don't have VPN client to install on Linux machine at location2 (we are using VPN client on windows laptop, that is how we access location1 machines). if we have VPN client for Linux, that will be little easier. A lot of folks use ssh as a way to provide a secure connection between sites without without VPNs running. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD4DBQFGUPr0Cg7APGsDnFERAsG+AJ442mFNGXFWV3xEpUzGrbhHSIDc4QCXQjNQ XQkJbspVChzMX8Zsly9jog== =rk0R -END PGP SIGNATURE-
Re: Simple GUI for command line cvs.exe?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Szlucha [EMAIL PROTECTED] writes: I'm using cvs.exe (1.11.22) on Windows and I'm in need of a simple GUI that will work with this version, and not a server based version. I've looked at WinCVS, but it requires that the CVSNT server be running on my PC, and that is not an option for me. Thanks! So, you are not using a client/server implementation of CVS? If you do have a client/server implementation of CVS, then the last time I looked, WinCVS provided a CVSNT client to be used to connect to either a CVS or CVSNT server. Of course, cvs.exe 1.11.22 may not be configured as a server under windows unless you have built your own copy with cygwin. Fwiw: CVSNT clients work just fine with CVS servers. (The converse is also true, we do try to keep CVS and CVSNT interoperable to the extent possible). You would need to use one of these methods: :ext: (:ext: using a RSH transport) :extssh: (:ext: using an SSH transport) :pserver: :kserver: (kerberos) :gserver: (GssApi) as the methods to connect to your CVS server, but that seems likely in any case. There are a number of GUIs that run on windows which interoperate with CVS servers. See http://ximbiot.com/cvs/cvshome/dev/addons.html for a reasonable list. The two most popular GUIs for windows appear to be www.tortoisecvs.org and www.wincvs.org as they are usually no cost. There is also SmartCVS if you wish to purchase something. If you are already using an IDE like CodeWarrior, eclipse.org, or NetBeans, then there are add-ons for those as well. I believe that all of the GUI solutions assume that the CVS repository lives on a machine other than the current client or at least is operating as a client/server implementation. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFF/DPNCg7APGsDnFERAguQAJ0cPndHF1gvk4o2tYiyRK9w/ulA5wCgw0Qv KvYhwipI2wbkyuyEbg6m5vg= =FiV0 -END PGP SIGNATURE- ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
Re: Read Only Repository, Sort of
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Huber, Robert [EMAIL PROTECTED] writes: I have the requirement to make a read only repository for a legacy system and another to make a repository for a current system where individual developers can check out code but only the administrator can check the code back in. Are either of these a practical option and if so how does one set up the permissions or do I have to develop a set of wrapper scripts to provide for this capability? The CVSROOT/config file will want to use a directory other than the repository and then you can make the read-only repository use a userid and groupid for which no user of the repository has write access. For the second case, you will need to make use of the commitinfo and taginfo triggers to disallow users other than your administrator from doing the modifications. This will not stop 'mkdir foo cvs add foo' operations, but as directories are not really revision controlled it should not matter that much. the contrib/cvs_acl* script in the CVS source distribution should be a good starting place for the commitinfo scripts. The taginfo script will probably have to be one you write yourself. -- Mark PS: Tell your system administrator that appending their disclaimer to outgoing email to large mailing lists that are archived automagically in many place makes the company look like they have cluseless/silly individuals running their company. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFF+wBaCg7APGsDnFERApUbAJ9QdWqsFW/nwE2cHag1PcBCQecRCACgw6tF hGDEwx2O41WnlmUHFR7PCZo= =lrEC -END PGP SIGNATURE- ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
Re: CVS and NFS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Steve, There are many cases where NFS clients have opened a file on an NFS server and written to it and the text written to disk is not the same as the text the client was attempting to write. Part of this is because the NFS protocols will not always be truthful about the state of the write to the actual filesystem which may not be 100% complete at the time that the server tells the client that all is well. NFS typically uses UDP which does not necessarily have checksums enabled and even if they are enabled they are fairly weak cksum32 which could easily have multiple bits corrupted without detection. For cases when NFS over TCP is being used, there have often been interoperability problems between heterogeneous implementations of the client server protocol and again, you only have a cksum32 checksum going for you. The ,v files in a CVS repository do not carry any individual or block checksums, so it is entirely possible that the data written over the network via NFS could be corrupted in many places along the path to being written to disk and you may not find out for a long time that an old revision is just not available to you any longer due to corruption of part of the ,v file. The CVS client/server interaction imposes additional checksums between the CVS client machine and the CVS server machine, but those are lost if there is a network layer between what the server considers a local disk write and what the network considers an NFS write. The concerns of the NFS protocol also exist for the Samba protocol. While it may be that your particular installation has a good network with no noise or back switches to corrupt packets along the way and a completely homogeneous NFS implementation between your client and server, it is still the case that the vast number of repository corruptions reported appear to be strongly correlated to using NFS or Samba for writes to the ,v file store. Using local disk or local raid disk arrays or SAN attached filesystems for the file store of the repository just do not have the same levels of risk associated as using NFS or Samba. As far as using NFS (or Samba) for your checked out trees, this is less of a problem because a corruption there is much more likely to be noticed as the revisions in your tree are all 'active' and it is fairly easy to move a corrupt file aside and do a 'cvs update' to fix the problem. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFF8uTFCg7APGsDnFERApTOAJ9EZEhd3VBECDOQsz214xQOBJHTMACgtHEX IpoA5R2PLLnvNnzJBRDwzy8= =Lp4v -END PGP SIGNATURE- ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
Re: (no subject)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Read about cvs_acls here: http://cvs.savannah.nongnu.org/viewcvs/*checkout*/ccvs/contrib/cvs_acls.html?root=cvs Fetch the documentation and script here: http://cvs.savannah.nongnu.org/viewcvs/ccvs/contrib/cvs_acls.html?rev=HEADroot=cvsview=log http://cvs.savannah.nongnu.org/viewcvs/ccvs/contrib/cvs_acls.pl?rev=HEADroot=cvsview=log -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFF8uXgCg7APGsDnFERAtZMAKCzfdjVHyKchPl5e0xPzfumJwVsKgCg9gpN ZCj5d+gOd5VP6NwtTJYPCvE= =KAWq -END PGP SIGNATURE- ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
Re: Branch Locking
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 sumit manchanda [EMAIL PROTECTED] writes: How can I lock a branch in cvs ? The short answer is to use a commitinfo trigger script to do the work. An example would be to look at the contrib/cvs_acls.* files in a CVS source distribution... or browse the top-of-tree version of it from the savannah.nongnu.org project for CVS. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFF7oThCg7APGsDnFERApcGAKDM5YLvkVc6kst78YbChZOgs5IhqwCgyFVu nEV1WVkHw3HLSdg2xE0scD0= =diem -END PGP SIGNATURE- ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
Re: Removing old revisions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] writes: I am wondering about removing old revisions from our files in cvs. One of our managers thinks that be retaining all of the old revisions we are incurring overhead in our cvs interactions. We have rather large repositories and quite a few of the members have many revisions. The revisions are kept in backward deltas, so that on the mainline the revision that is most accessible is the top-of-tree. It seems to me that I recall reading someplace in the past that removing old revisions is not a very wise thing to do. Does anybody have any thoughts or advice on this subject? Do not do it. Is it a common practice or not? No. Is it dangerous? It means that you lose revision history and thus the ability to go back to the revisions deleted or to branch from them. It could also be a problem if you have lots of branches as deleteing the branch point revision makes it impossible to use that branch ever again. This is because branches are forward deltas from the branch point revision. To get to the top-of-branch, CVS (like RCS) traverses back to the greatest common ancestor using reverse deltas and then traverses forward along the revisions that lead to the top-of-branch. Is there any performance degradation by not removing old revisions? Hmmm there was a bug (#17560) where the merge algorithm for checking out very old revisions was O(n*n), but that has been reduced to O(n) in what will become CVS 1.11.23. You may checkout a copy of this version of CVS from the savannah.nongnu.org if you wish. (Or, you could get a copy of the patches that Michael J Smith posted to the list.) If you do not need to get back to ancient revisions very often, then I suppose there could be some degredation if the size of the files are too big, say in excess of a gigabyte or two. Such that adding a new revision is actually taking lots of time for the filesystem to rewrite. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFF6btyCg7APGsDnFERAtPpAJ9Eyimic915Cdff1N2GG3XhHTkgkQCcCvbY bXu+VaFhXUdj9YKXjEMd95o= =DCQA -END PGP SIGNATURE- ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
Re: Removing old revisions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Larry Jones [EMAIL PROTECTED] writes: Mark D. Baushke writes: It could also be a problem if you have lots of branches as deleteing the branch point revision makes it impossible to use that branch ever again. CVS won't let you remove a branch point revision. Hmmm... while that may be true, it does not render my point invalid. The following illustrates my point: cvs -d /tmp/cvs-test init cvs -d /tmp/cvs-test co -d top . cd top mkdir jj cvs add jj cd jj echo a foo cvs add foo cvs ci -m1 foo echo b foo cvs ci -m2 foo cvs tag -b bar echo c foo cvs ci -m3 foo cvs log foo cvs admin -o1.2 foo cvs -q log foo Yeilds the following error message: cvs [update aborted]: could not find desired version 1.2 in /tmp/mdb-repos/jj/foo,v In my opinion, this renders branch bar impossible to use again. The difficulty is knowning if one of the branches (or tags) being deleted will ever be needed again. If you only have one or two branches, then it should be easy to spot the use. If you have many, it may be possible to overlook the use. Or, if you assumed that CVS would not let you remove a revision being used by any kind of tag, that would also be a possible problem. In the user's case, I understood that many files may be visited to delete 'old' revisions, so due care in dealing with branches would need to be taken. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFF6gJVCg7APGsDnFERAmcnAKDZsaqfjsImQ/F43vhlBz9LQMFxhACePmJk ZKBR8LhjREIhrGlJiPfDiSw= =xYzQ -END PGP SIGNATURE- ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
Re: major version number
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 fpefpe [EMAIL PROTECTED] writes: Greetings -- What is the procedure when commiting updates to the respository to such that the major version of the source module is not 1.xx but 2.1 (2.0)? Avoid doing it. The cvs revision numbers are for internal cvs use only. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFF547yCg7APGsDnFERAuiUAJ45p+C0qp7LOQfbzr8gshCNTj33UgCfT8mu j6GjLsm3J0YuVDB8FpYm5G0= =t8P3 -END PGP SIGNATURE- ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
Re: [Cvs-cvs] Restricting privileges
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The cvs-cvs address is for reporting commits to the repository, not questions. I have directed the reply to the info-cvs@nongnu.org list. Jean-Claude Gervais [EMAIL PROTECTED] writes: What is the best way (read that as 'simplest/easiest way') to restrict access in CVS? For write access, use of the CVS triggers is a good way. There is a script in the contrib directory called cvs_acls you can use. For read access, the use of UNIX groups is reasonable. For example, if you want to allow only certain users to manipulate tags/branches. You might want some users to create tags, but not be able to move them, also you might want to prevent people from inadvertantly deleting branches. The taginfo CVS trigger may be used to prohibit the modification of tags by individuals. Is there a friendly way (for example using access rights in CVS/NT) or must you absolutely write taginfo scripts and such? This list is for CVS, not CVSNT. If you wish to ask about CVSNT, you will find better answers from the http://www.cvsnt.org/ web site. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFF5S7NCg7APGsDnFERAjRUAKD5rpE99KKOqpV2eYF/Jf9ZOTDvVQCfa3rI 5Elci3OS3WAzs/vPZskl/UE= =D215 -END PGP SIGNATURE- ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
Re: Which CVS version is best for Windows?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Grumbler(ng) [EMAIL PROTECTED] writes: I'm using cvs (cvs.exe) in version 1.12.7 since years. I'd like to update to the latest version. But detected some problems: A. Version 1.12.13a could not checkout from the existing repostitory, e.g. cvs -d :local:u:/avrdepot checkout robi (the path could not be found, but cvs update in the same repository works fine) B. Version 1.11.22 lists many file, that requires a commit, because CVS detected changes. But this is not true. Furthermore after the commit (and successfully new revision created) the $CVSHeader$ is set to the first revision (1.1) instead of 1.4 as it is now. I checked the NEWS files and Cederqvist files for both versions and did not find anything usefull for this topic. It seems 1.11.22 is newer than 1.12.13a (exe and NEWS-file). Thanks in advance. CVS 1.11.22 is the latest STABLE branch release of CVS. CVS 1.12.13a is the latest FEATURE branch release of CVS. It is possible that 1.12.13a may still have bugs in some of the newer features that you may not want to use, although many people are now using cvs 1.12.x releases in production environments. The 1.12.7 release was pretty good and the 1.12.9 release was very stable. There were a few bugs including a possible security vulnerability in zip that is not patched until the 1.12.13a release. As provided, the cvs.exe binary file is a client only and does not support any server operations. You could rebuild from sources in a Cygwin environment if you need client/server and local CVS operations to work. If you need to use Windows for your server and are not able to use Cygwin for some reason, then you may find CVSN (http://www.cvsnt.org/) an interesting choice. CVSNT is a fork of CVS which is also open source and is more tightly integrated with Windows as well as still having working ports to most UNIX and GNU/Linux operating systems. The CVSNT folks and the CVS folks chat enough that our client/server protocols still interoperate when using the :ext:, :extssh: and :pserver: protocols. Other protocols are available for CVSNT which might be of interest to a windows shop. Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFF3C2gCg7APGsDnFERAldoAJ9rvW5FEGJi4fsWtjhYml1wzEjhAgCffLvd /CMGBFkJEPD1+LC4giW0wMs= =HG3Q -END PGP SIGNATURE- ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
Re: updating files very slow on cvs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 om [EMAIL PROTECTED] writes: I am facing one problem while updating workspace as follows. The speed of checking out, checking in or updating files is very slow as compared to other people performing the same action from their desktops. I tried to perform the same action from different workstations, but still the result is the same. I am not able to find out whether it is a network issue or something else which is reducing the speed.This Happens only for my Account, Even on Other machines server on redhat linux cvs version 1.11.17 client : TortoiseCVS and WinCVS Any help would be appriciate. Are you using :ext: or :extssh: ? If so, you may wish to check your home directory on the redhat GNU/Linux server to see if the shell startup file for your interactive shell (e.g., ~/.cshrc for /bin/tcsh or ~/.profile or ~/.bashrc for /bin/bash) is running commands it should not be when you are not doing an interactive login. For C Shell (/bin/csh and /bin/tcsh), you may wish to use if ($?prompt) then # only run your interactive command shell # initializations here endif For Bourne Shell (/bin/bash /bin/zsh /bin/ksh), you may wish to use if [ z$PS1 != z ]; then # only run your interactive command shell # initializations here fi If you are using :pserver: as the connection method, then I have no idea what your problem might be. Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFy3JJCg7APGsDnFERAu6HAJ9p69vEaIVh7Soa1ZRkrOCQ7zhEygCdGuh1 VzTkgqr7bQOIucHrf3OHzJs= =muPf -END PGP SIGNATURE- ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
Re: controlling/checking comments in commits
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sinan Kalkan [EMAIL PROTECTED] writes: i'd like to ask whether it is possible: 1- to disallow empty comments in commits and/or Yes, you could write a verifymsg script which denied a commit for which the log message was empty. You would probably also want to disallow just typing whitespace or '.' as long as you are at it. 2- to force getting separate comments for each file that become committed. Well, if you are avoiding client/server commits, then you could get per-directory log messages. If there is more than one file per directory being changed, then there would be no way to enforce a per-file commit log message. I am not sure I think it is wise to have a different log message for every commit in any case. as far as i've learned, it is possible to 'install' scripts of our own before or after commit but i've not figured out a way to get information about the comments nor how to force separate comments for each file. Read: http://ximbiot.com/cvs/manual/cvs-1.11.22/cvs_18.html#SEC172 Enjoy! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFtxRpCg7APGsDnFERAiOSAJwJXuCLV5/iNJclrt8rqe2y52p4jgCgvKaC 2c6mlqFBisrUfabhidbkBdE= =eAM9 -END PGP SIGNATURE- ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
Re: Adding directory and files when parent directory has stick tag.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeff Pream [EMAIL PROTECTED] writes: Somebody just called on me to clean up a situation involving a branch from a trunk that didn't exist. The scenario was that he had checked out a tagged version of a project, he then proceeded to add/commit a new directory and several files. It looks like CVS created a branch but put it in the Attic, presumably because there was no main trunk to branch from. Yup, this is the way it is supposed to work. With cvs 1.12.x you can also get a similar result by doing a vendor-only branch import using 'cvs import -X' as the import command. There is a 1.1 revision and a 1.1.1.1 revision just like a normal import of a new file, but there is also a dead 1.2 revision and the ,v file is in the Attic. (This is done for NetBSD development all the time.) This is a very useful feature to allow independent development to be carried out in a branch and only to merge to the trunk when your checked out tree is working as you want it to work. To clean this up I went to the repo and blew away the new directory and its files. Then I manually removed the Entries line pertaining to the new directory. This is just a bad idea. Doing it lost a lot of work. Generally, checked out trees that have CVS/Entries with an entry for a directory that has gone missing just gives CVS clients a very hard time. If you really must do something like this in future, you are better off leaving the directories in place and only removing the ,v files. At that, I would probably have moved them out of the way if there was some reason you felt you had to have an active revsion 1.1 for some unknown reason. CVS still didn't do what I wanted, but after some messing around with updates and manual hacks (yes things had gotten out of control at this point), I managed to get it where I wanted it. If you say so, it must be true. I bet it was a lot of work. My question: What is the PROPER way to clean up the above mess, First, it was not a 'mess' that needed to be cleaned up at all. It was just a way of doing concurrent development that you had not used previously. resulting in the new directory and files being on the trunk instead of this mystery branch in the Attic and version 1.1 being in the users sandbox next to the rest of the project which still retains the original tag? I am sorry you were confused, but had you done a cvs checkout -rbranch modulename other users would have had access to the same files that your user had committed in their own checked out tree. This is how things are supposed to work. That said, if you have someone who developed sources on a branch that had no revisions on the main trunk, someone would typically merge those files to the main trunk using this basic approach... Assumption: branchtag1 is the tag used, myproj is the top-level module under which new directories were created... Something like these steps were probably taken to get the tree in the state you saw cvs rtag -b branchtag1 myproj cvs checkout -rbranchtag1 myproj cd myproj mkdir foodir cvs add foodir cd foodir echo hello hello.txt cvs add hello.txt cvs commit -m'new file on branch only' hello.txt ... add other files as desired ... Now, if they have completed their development and are happy with the results, all that remains is to merge the branch sources back into the main trunk... : now it is time to merge the branchtag1 files into the main trunk cvs checkout myproj cd myproj ... make sure that you do NOT have a -P switch in your ~/.cvsrc file cvs update -d -j branchtag1 ... make sure everything looks good ... cvs commit -m'merge branchtag1 back into the main trunk' At this point, there will still be a dead 1.1 revision, and a living 1.1.0.2 magic branch with 1.1.2.x revisions on it AND revsion 1.2 should look a lot like revision 1.1.2.x found on mybranch1 for the hello.txt file. I hope this answers your questions. Enjoy! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFsEV4Cg7APGsDnFERAi+VAJ9wlp28WQ9R5tHoO9iEQkitrmZsXgCgxtHm /MdYj0jboNrXlhtUYMi+EOk= =/x5n -END PGP SIGNATURE- ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
Re: commit restrict to one file in CVS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 om [EMAIL PROTECTED] writes: The problem I am facing is suppose the file name has a space as shown in the above statement; then the newcommit.sh reads it as two different arguments instead of one. Yup. This problem is fixed in CVS 1.12.x which has a new way to deal with formating the names of files if you enable the UseNewInfoFmtStrings=yes in the CVSROOT/config file. The latest release of the FEATURE branch is CVS 1.12.13. Enjoy! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFp0j9Cg7APGsDnFERArtPAJ4o28rK1+lPYFxKZvcBwaE5u3YCMACgnPiS RaZiWg6hWpVr2WwsJjrOtTc= =TyX5 -END PGP SIGNATURE- ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
Re: CVS upgrade to 1.11.21
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aggarwal, Vineet [EMAIL PROTECTED] writes: We are planning to upgrade cvs client-server, running on AIX, from version 1.11.1p1 to 1.11.21. Are there any known issues with 1.11.21 that are not in 1.11.1p1? Many bugs have been fixed. That said, you may wish to move to 1.11.22 which is the latest release and does fix some more bugs. Some of which were introduced between 1.11.1p1 and 1.11.21. Look at the cvs-1.11.22/NEWS file for more information on patches between 1.11.11 and 1.11.22. Will it modify the format or contents of RCS files in repository in any way? No. Are there any known issues with rollback? No. If someone has done this before, we would appreciate if you could share the experience. Be sure to use 'cvs init' after the update to make sure you have all of the needed CVSROOT/* files. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFp/LqCg7APGsDnFERApWhAKCfEcHZgxqvIRASNIJuNm70PiF2bACfaFyx bz4Cn1sGcLz6zRLWP8xGPa4= =CMrV -END PGP SIGNATURE- ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
Re: GPG needed for CVS trunk?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Toft [EMAIL PROTECTED] writes: Peter Toft [EMAIL PROTECTED] writes: I just wanted to verify my latest CVS error http://savannah.nongnu.org/bugs/?18743 with the trunk CVS version, so I checked out CVS from ... CVS, and compiled it. A very adventurous thing to do. Be advised that the trunk CVS does not Yep - If you can give me at resonable tag I can easily try... work on all hosts yet. Feel free to submit patches to get it working under additional hosts. on my Linux box it compiles fine at least. Yeah, the only GNU/Linux box with problems is an older 2.2 or 2.4 kernel running on a non-intel hardware... I forget which one. When using the trunk CVS and running cvs init I then got errors about needing gpg secret key. I cannot find documentation about this or know how to disable this binding to GPG. Can anyone comment and help me there? Well, the point of the new OpenPGP (initially only looking for GnuPG support) is to ensure that all commits are signed. So, you probably want to generate a GnuPG key-pair and start using them for your commits. That said, you could tell your client not to bother about such things as signing by doing this: cvs --no-sign init but you are probably going to be unhappy about most cvs operations that modify or verify things if you do not have a GnuPG key-pair. Exactly - I hope that I can disable this in one of the CVSROOT files per module of per repository. Not at present, but I am not sure if Derek is entirely finished with the feature or not. I understand the idea, but want at least to be able to select when to use this feature. I believe it is pretty much hard-coded for now. You could hack the configure to avoid GnuPG totally... ./configure GPG=/bin/false This means that it will behave as if your system does not have a GnuPG that is functional. So, the client and server generated will not try to sign anything at all. You will probably also find it highly desirable to look at the gpg-agent program which is a part of the GnuPG 2.x series of GnuPG programs. Documentation is present in the ccvs/doc/cvs.texinfo file under the 'OpenPGP Signatures' section. Thanx - excellent mail Mark! Peter Toft, Ph.D. [EMAIL PROTECTED] http://petertoft.dk Følg min Linux-blog på http://www.version2.dk/blogs/petertoft -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFqB9CCg7APGsDnFERAkh6AKDQBDdO0f6/Ir6ngYT6zOxA+uzBNACglG35 7NZwPzv6GWoXZRf0qSgED2E= =g9Wa -END PGP SIGNATURE- ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
Re: GPG needed for CVS trunk?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Toft [EMAIL PROTECTED] writes: I just wanted to verify my latest CVS error http://savannah.nongnu.org/bugs/?18743 with the trunk CVS version, so I checked out CVS from ... CVS, and compiled it. A very adventurous thing to do. Be advised that the trunk CVS does not work on all hosts yet. Feel free to submit patches to get it working under additional hosts. When using the trunk CVS and running cvs init I then got errors about needing gpg secret key. I cannot find documentation about this or know how to disable this binding to GPG. Can anyone comment and help me there? Well, the point of the new OpenPGP (initially only looking for GnuPG support) is to ensure that all commits are signed. So, you probably want to generate a GnuPG key-pair and start using them for your commits. That said, you could tell your client not to bother about such things as signing by doing this: cvs --no-sign init but you are probably going to be unhappy about most cvs operations that modify or verify things if you do not have a GnuPG key-pair. You will probably also find it highly desirable to look at the gpg-agent program which is a part of the GnuPG 2.x series of GnuPG programs. Documentation is present in the ccvs/doc/cvs.texinfo file under the 'OpenPGP Signatures' section. Enjoy! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFpwKbCg7APGsDnFERAsLAAJ4j795TbdntqMmVxMQ9d+osfe8CcQCgmr96 7Vgl5cUFS4DS4ip/W4zVoxk= =fz2i -END PGP SIGNATURE- ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
Re: List of Checkedin files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 siva prasanth [EMAIL PROTECTED] writes: I have brach that is checked in to the HEAD. You did some kind of merge operation and then a cvs commit? If so, all cvs knows about is the commit you made. Now i want to know list of files that have been checked in to that HEAD from that branch. I do not know that this is directly possible. I suppose you could run some kind of heuristic comparing versions on the branch with versions on the head... Is there a command by which i can how the list of files that are checked in to head from a branch. No. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFozE7Cg7APGsDnFERAlapAKCTfakChvFx12i9Nmhs/dNN+iSFegCgjRP5 4u5kuzBvFM4NR9i5fV31KI4= =dF98 -END PGP SIGNATURE- ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
Re: commit requires write access to the repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Dave, This problem is not with CVS. You should ask for help from the sf.net folks You probably need to use the :ext: method rather than :pserver: to do commits: cvs -z3 \ -d:ext:[EMAIL PROTECTED]:/cvsroot/chessdb \ checkout cheesdb This will use your ssh keys and should allow you to do both checkouts and commits. Good luck, -- Mark Dave (from the UK) [EMAIL PROTECTED] writes: I'm the project admin for a project on Souceforge: http://sourceforge.net/projects/chessdb/ I'm the only admin and there are no developers yet I've written to the CVS several times, but had a mis-hap and deleted the source files locally. No problem I thought - just check them out, and I'll have copies. So I did: cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/chessdb co -P chessdb That was fine - all files came down okay. But if I change one locally, I'm unable to commit it back: $ cvs commit cvs [server aborted]: commit requires write access to the repository I tried this: cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/chessdb commit but the same problem. CVS % cat Root :pserver:[EMAIL PROTECTED]:/cvsroot/c $ cat Reposittory chessdb teal /export/home/drkirkby/chessdb/CVS % cat Entries /.cvsignore/1.2/Sat Dec 30 16:36:17 2006// /CONTRIBUTORS/1.1.1.1/Tue Dec 26 19:37:27 2006// /COPYING/1.2/Sat Dec 30 04:46:14 2006// /ChangeLog/1.6/Tue Jan 2 06:50:51 2007// /ChessDB-with-crafty.iss/1.3/Sat Dec 30 16:35:14 2006// /Makefile.conf/1.5/Mon Jan 1 20:07:45 2007// /Makefile.cygwin/1.1.1.1/Tue Dec 26 19:34:58 2006// /Makefile.mingw/1.1.1.1/Tue Dec 26 19:34:58 2006// /Makefile.vc/1.1.1.1/Tue Dec 26 19:34:58 2006// (and so on) I have ssh keys set up, so can log in without a password -- Dave (from the UK) Please note my email address changes periodically to avoid spam. It is always of the form: [EMAIL PROTECTED] Hitting reply will work for a few months only - later set it manually. http://witm.sourceforge.net/ (Web based Mathematica front end) ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFmozHCg7APGsDnFERAtBlAJ41ZRU2nTzibCT6BF9lZDi8df63CwCfYNMj cLfqRB9xtSPnhDsxA2/87jQ= =/UuN -END PGP SIGNATURE- ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
Re: cvs access error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Danish, Generally, the user 'root' is prohibited from doing CVS operations. The CVS application is not really safe for 'root' users not to assume that their privilege is being exploited, so by default the user 'root' is not allowed to be a real user for the system. Under :pserver: it will switch to the correct user to be used, but your $CVSROOT entry makes that harder to handle. In addition to this problem, it is possible you will have problems with port 2401 being firewalled and/or not properly setup on the GNU/Linux server. You should see if you can access the repository locally from the GNU/Linux box still going over your :pserver: method first to ensure that evertyhing has been properly setup. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFmo3WCg7APGsDnFERAqwKAKC33zcmJNrO3RiNa0f92ZX3FyG8cwCffmUv LUayqGiScj19ISRhHGBg+Uw= =Rvy9 -END PGP SIGNATURE- ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
Re: RCS: Preserving group ownership
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] writes:
Mark D. Baushke wrote:
[EMAIL PROTECTED] writes:
I want to be able to use RCS with files such that when I check out the
file, the group ownership is preserved.
That is, I want owner = root, group owner = www. But whenever I co,
group owner reverts to root. That's even if I chgrp www on the *,v
file.
In many filesystems, the default group of a new file may be defaulted to
the current directory group by setting the set-gid bit on the directory.
You do not specify which operating system or filesystem you are using
for your repository, so further advice is not really possible.
Linux (SuSE 10.1), ext3.
Yes, the set-gid should do what you wish.
chown -R root:www /path/to/cvs/root/directory
find /path/to/cvs/root/directory -type d -exec chmod g+s {} \;
This means that new temporary ,foo, files created in those directories
will be of group www and when they are renamed to foo,v the group will
be as you expect.
-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (FreeBSD)
iD8DBQFFhDQWCg7APGsDnFERAqybAJ9jJNE/txUTyRcui6xSEvm0GilY7QCdE8er
EvvTkFXrNlzFNpUYyDP3nd4=
=/b4s
-END PGP SIGNATURE-
___
info-cvs mailing list
info-cvs@nongnu.org
http://lists.nongnu.org/mailman/listinfo/info-cvs
Re: RCS: Preserving group ownership
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] writes: I want to be able to use RCS with files such that when I check out the file, the group ownership is preserved. That is, I want owner = root, group owner = www. But whenever I co, group owner reverts to root. That's even if I chgrp www on the *,v file. In many filesystems, the default group of a new file may be defaulted to the current directory group by setting the set-gid bit on the directory. You do not specify which operating system or filesystem you are using for your repository, so further advice is not really possible. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFgZs9Cg7APGsDnFERAsJkAKDOrXi5SRfWwsKIVd0p+T/Tl14CQwCg4HXK xlqvdYXbw3m7n1T2J+abbsw= =P/AX -END PGP SIGNATURE- ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
Re: cvs update doesn't use modules?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark E. Hamilton [EMAIL PROTECTED] writes: I don't know why I've never noticed this before, but I've just discovered that 'cvs update' won't update modules. We have a module that specifically excludes certain sub-directories, and a user wanted to use 'cvs update -d -P module' to ensure that he got any new directories in the sub-directories the module did check out. This didn't work, and of course updating the directory checks out the excluded stuff. The CVSROOT/modules file is really just a way to specify aliases to files and directories you want collected. If you look at the CVS directory contents, it does not have any indication of the original 'module' that may have been used to checkout the directories. Why doesn't update use modules? Because CVS has no idea which module or modules may have been used for the initial checkout. Is this something that will be fixed in 1.12? It is not currently fixed and I know of no plans to do anything in this area. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFgksPCg7APGsDnFERAmeaAKCIQhQe+i1XRFbvo9m2cCxf37DrAgCgvk7H BD0po+4zSW/n5sEywX8QMNc= =64Vp -END PGP SIGNATURE- ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
Re: Partial checkout access restrictions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Manuel Lemos [EMAIL PROTECTED] writes: I have been digging the documentation but I could not find a way to restrict checkout access to of some repository directories to some users. I see there is commitinfo control file, but that is for commit access. It does not restrict checkout access. I see you can restrict access based on file system permissions, but that is not a good solution for my problem because all repository files and directories have the same owner user and group. This is your problem. Anybody knows of another way to restrict checkout access? Typical methods include using group membership to deal with such restrictions. If that mechanism will not work for you because you are (ab)using a single 'cvs' :pserver: user, then you don't really have any other solution. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFFfRewCg7APGsDnFERAnkPAJ4yW2tXt32kuQtSXymVRy4Q3URaBgCdFspJ Y/me6tswtbOZwH1McVTMUQE= =Lgt/ -END PGP SIGNATURE- ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
Re: Moving Repositories
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark J [EMAIL PROTECTED] writes: Due to merges and acquisitions, my company has three different CVS installations. I've roughed out a Pretty Good plan of attack, but for one issue. I can't for the life of me find any information on changes between 1.11.2 and 1.11.21. All three versions are a little different, with two of them being nigh identical (1.11.21 and 1.11.21-wd [WANdisco build]) that should work fine. But I'm concerned about problems with adding a 1.11.2 repo into a 1.11.21 environment. Such an update between vanilla versions of CVS 1.11.2 and 1.11.21 should be no problem at all. I do not know anything about 1.11.21-wd, so I can not advise you there. All the admin files look the same, and I'll be changing them so that all three CVSROOTs are pretty much the same, except for LockDir. I don't see any differences in the ,v files, so it looks good to go. The format of the ,v files is identical for all cvs 1.11.x revisions. If you do a 'cvs init' on your repository, any 'missing' administrative files will be added to your repository's CVSROOT directory. I'd appreciate it if anyone sees a problem, if you'd reply so I can make this as smooth as possible. You should not have any problems. Enjoy! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFFekn4Cg7APGsDnFERAr2cAJ4tMC1R0gqjWU2PonxphwPvoO48FQCfdiD4 YlrTcbVNZ/jcnljD7c77hOA= =52TC -END PGP SIGNATURE- ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
Re: listing files in CVS server, without rls?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Armel Asselin [EMAIL PROTECTED] writes: Hello, i'm trying to list the files located inside a server (without getting them at that time). I found rls in CVS 1.12 (and it works fine for me where available) but in 1.11 which seems to be still very wide spread (since it is the stable), rls does not exist. I tried checkout -n and export -n but it does not want to _just_ list the files :-( and as such these command just print an error message and leave. The closest you can get with cvs 1.11.x is do to do this: cvs -n rlog -R . which will give you the full path to the ,v file on your server. You would then need to trim the prefix to remove the common pathname root. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFFdHXjCg7APGsDnFERAmg6AJ9j3Gknxyw+wqMwZBp6amiEXsWb4wCgjo8o kPtNTY+hI6BzKPX6XpCo/X8= =Dq9v -END PGP SIGNATURE- ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
