Question

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 Module1/A only and not Module1/B ? and vice-versa?

Answer 1

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.