Re-structuring CVS repositories and retaining history

Currently, we have the following in our CVS Repository :

Module1
  |
  |
  +-----A
  |
  +-----B

We want o restructure this module such that the sub directories A and B appears as high level modules. What I could do is to check Module1 out and then pull A and B out and then do a fresh cvs add for A and B individually, thus making them new cvs modules. But I am sure if I do this, I am going to lose the history as well as I would have to remove all internal CVS folders under A and B.

Q1: So is there a way to restructure this and retain the history?

What I essentially am trying to do is to filter out access between A and B. So -

Q2: Is there a way to set up security so that certain users can check out Mod开发者_运维问答ule1/A only and not Module1/B ? and vice-versa?

Q1: So is there a way to restructure this and retain the history?

Like you wrote in your comment, if you have sys privs you can mv modules around the repository and keep the history of all the files below A and B but in doing so, you lose the history that /A used to be Module1/A and /B used to be in Module1/B (not to mention build scripts probably break now). Subversion resolves this for you by offering the move (or rename) command which remembers the move/rename history of a module.

Q2: Is there a way to set up security so that certain users can check out Module1/A only and not Module1/B ? and vice-versa?

There sure is, used group permissions. From this page, http://www.linux.ie/articles/tutorials/managingaccesswithcvs.php Here's the snip I'm referring to in case that page ever goes away

To every module its group

We have seen earlier how creating a cvsusers group helped with the coordination of the work of several developers. We can extend this approach to permit directory level check-in restrictions.

In our example, let's say that the module "cujo" is to be r/w for jack and john, and the module "carrie" is r/w for john and jill. We will create two groups, g_cujo and g_carrie, and add the appropriate users to each - in /etc/group we add

g_cujo:x:3200:john,jack
g_carrie:x:3201:john,jill> 

Now in the repository (as root), run

find $CVSROOT/cujo -exec chgrp g_cujo {} \;
find $CVSROOT/carrie -exec chgrp g_carrie {} \;

ensuring, as before, that all directories have the gid bit set.

Now if we have a look in the repository...

   john@bolsh:~/cvs$ ls -l 
   total 16
   drwxrwsr-x    3 john     cvsadmin     4096 Dec 28 19:42 CVSROOT
   drwxrwsr-x    2 john     g_carrie     4096 Dec 28 19:35 carrie
   drwxrwsr-x    2 john     g_cujo       4096 Dec 28 19:40 cujo

and if Jack tries to commit a change to carrie...

   jack@bolsh:~/carrie$ cvs update
   cvs server: Updating .
   M test
   jack@bolsh:~/carrie$ cvs commit -m "test"
   cvs commit: Examining .
   Checking in test;
   /home/john/cvs/carrie/test,v  <--  test
   new revision: 1.2; previous revision: 1.1
   cvs [server aborted]: could not open lock file
   `/home/john/cvs/carrie/,test,': Permission denied
   jack@bolsh:~/carrie$ 

But in cujo, there is no problem.

   jack@bolsh:~/cujo$ cvs update
   cvs server: Updating .
   M test
   jack@bolsh:~/cujo$ cvs commit -m "Updating test"
   cvs commit: Examining .
   Checking in test;
   /home/john/cvs/cujo/test,v  <--  test
   new revision: 1.2; previous revision: 1.1
   done
   jack@bolsh:~/cujo$ 

The procedure for adding a user is now a little more complicated that it might be. To create a new CVS user, we have to create a system user, add them to the groups corresponding to the modules they may write to, and (if you're using a pserver method) generate a password for them, and add an entry to CVSROOT/passwd.

To add a project, we need to create a group, import the sources, change the groups on all the files in the repository and make sure the set gid on execution bit is set on all directories inside the module, and add the relevant users to the group.

There is undoubtedly more administration needed to do all this than when we jab people with a pointy stick. In that method, we never have to add a system user or a group or change the groups on directories - all that is taken care of once we set up the repository. This means that an unpriveleged user can be the CVS admin without ever having root priveleges on the machine.