Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Glen Starrett wrote: > Chuck Kirschman wrote: > >> Come on somebody - there has to be a way to give people cvs admin >> priveleges without giving them root access to the server or having to >> maintain an admin file per repository? The former is too dangerous, >> and the latter is a maintenance nightmare. I really want this to be >> handled in Active Directory rather than creating a bunch of files. Is >> there some way to specify an alternative group such as "cvsadmins" to >> do the same thing? > > > CVS is written around having few repositories, rather than many. While > it is possible to have many repositories it's not the norm except for > some circumstances. Why is it that you are using many repositories? > I agree that CVS is not designed for multiple-repository administration. It is fairly painful to administrate until you write your own system to manage it. We were hoping that Active Directory permissions would make it much simpler, and in many ways it has. But of course having to add another database (admin file) to each repository is exactly the pain we were hoping to avoid. We use multiple repositories for several reasons; some historical, others practical. If we were starting again today, we'd probably do things differently, but we'd still have a couple dozen repositories at least. - Access restrictions were on a per-repository basis in the 1.9 versions of CVS we started with. That is not as much of a problem in 2.0.58d, but it would be very painful to change everything now. We still think about access as per-repository rather than per-directory or per-branch. We still feel better about the Windows AD security than relying on cvs ACL's. - When we acquire a new company it is usually more convienent and efficient to just copy their repositories onto our servers. - Firewalls - it is more secure to have some machines behind a firewall and others outside it. For example, documentation is on the outside of a firewall, while source is behind it. - Scalability - we currently run 10 CVS servers, and you can only load-balance between them on a per-repository basis. One of the points I see again and again on this news group is that people deal with just a (relatively) small amount of source. I know there are other companies who have hundreds of thousands of files and hundreds of gigabytes of source used by hundreds of developers and nontechnical people around the world, but you don't see many posts from those people. Everyone seems to assume a small code base and a couple dozen developers at most. I constantly find issues that aren't handled well in cvsNT if your checkout/update takes more than a few minutes and you do anything else at the same time (write new code, etc). I would love to be able to specify an Active Domain group in the admin file per repository and be done with it. But since that isn't currently possible, I'll need to maintain a seperate database as to who can be an admin for which repository, and generate the files from there. It's the same pain as generating all the password, readers, and writers files for cvs 1.11 that made us move to cvsNT so we could use AD. Thanks for the advice chuck