Lo, on Friday, February 22, Paul E Condon did write: > I saved a cvs repository of personal programs in RedHat some time ago, > before I discovered Debian. Now I'm trying install it and access the > files in it. I used tar to save the whole repository as cvs.tgz. When > I untar it, I discover that the permissions are wrong and the group > assignment of the files is different from the Debian convention. So I > set about to make them right for Debian, but I can't get it to work.
To which Debian convention are you referring? The numeric GIDs should have shifted, but other than that, I'm not aware of any Debian convention for ownership of files in a CVS repository. In fact, due to the way CVS repositories work, such a convention would most likely be counterproductive. > First question: Debian uses "src" as the conventional group name for > cvs internal files. Granted, I've customized my repository pretty heavily, but I don't see this: [ankh-morpork:/var/cvs]$ /bin/ls -ld /var/cvs drwxr-xr-x 4 root root 4096 Feb 10 2001 /var/cvs [ankh-morpork:/var/cvs]$ /bin/ls -l /var/cvs total 8 drwxrwxr-x 3 root cvsadmin 4096 Feb 13 2001 CVSROOT drwxr-xr-x 10 cobbe cobbe 4096 Feb 6 21:08 cobbe IIRC, I created the cvsadmin group, but the permissions on /var/cvs seem to indicate that the group permissions just default to whatever's appropriate for the user who created the repository. Which version of CVS are you using? The above results are from 1.10.7-7, the version in potato. > Second question: What permissions do I need to set? I've done > chmod g+w * > everywhere that there is a directory, but I still get these error > messages when I try to checkout a sample program directory, e.g.: While Debian and RedHat may have default groups that they use for CVS repositories, this isn't reallly all that relevant. As long as all of the CVS users have write access to the appropriate directories, everything should work out. Typically, one does this by manipulating the group ownerships and permissions of the files in the repository. I'm assuming that you want all-or-none access: each user can access either the entire repository or none of the repository. (More finely-grained access controls are possible, but they complicate the process somewhat.) I'm also assuming a `local' or `ext' access method, as opposed to `pserver'. I'll use two metavariables to make the explanation easier: $CVS_GROUP is to the name of the group controlling CVS access, and $REPOSITORY is the name of the directory which contains the repository files (e.g., where you untarred your archived repository). - addgroup $CVS_GROUP - Use adduser to ensure that all of the appropriate users are in $CVS_GROUP. - chgrp $CVS_GROUP $REPOSITORY - chmod g+ws $REPOSITORY ## The setgid bit is crucial. - find $REPOSITORY -print | xargs chgrp $CVS_GROUP ## Make everything owned by the CVS group. - find $REPOSITORY -type d -print | xargs chmod g+ws ## Make all directories group-writable and setgid. Make sure that you're running in $CVS_GROUP (you may need to log out and log back in), and you should be good to go. (If you don't understand what all of the above does or why you're doing it, please ask. That understanding will help you deal with other repository problems later on.) > [EMAIL PROTECTED]:~/co$ cvs co hello > cvs checkout: warning: cannot write to history file > /var/lib/cvs/CVSROOT/history: Permission denied > cvs checkout: Updating hello > cvs checkout: failed to create lock directory for `/var/lib/cvs/hello' > (/var/lib/cvs/hello/#cvs.lock): Permission denied > cvs checkout: failed to obtain dir lock in repository > `/var/lib/cvs/hello' > cvs [checkout aborted]: read lock failed - giving up > [EMAIL PROTECTED]:~/co$ Yeah. User pecondon doesn't have write access to the repository directory. The above process should fix this. HTH, Richard