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.
Arthur Barrett wrote: > Chuck, > >>>> 2. Allow a centralized script location defined in the "script.name" >>>> file. With many repositories on a single box, making a change to a >>>> script that must live in every CVSROOT is an administration nightmare. >>> What are everyone else's thoughts on this one? >>> >> Furthermore, all the other scripting situations such as loginfo run things >> in other places on the box if you choose. > > A jail enforces the rule that only things within the jail can be ran (again > it's a unix/linux thing, not replicatable on windows) > Fair enough; my servers are currently all Windows. > As far as I know CVSNT shouldn't run scripts outside of CVSROOT anyway, but > it's a very long time since I looked at all the why's and wherefore's in > that area. It certainly is true that if a user has write access to CVSROOT > directory in the repo then they may as well be considered root users on the > box. > That's a bit extreme. They don't need write access to the CVSROOT directory to run a script. In my case, the scripts often send information to a bug tracking software. No write access on the box is required to do that. And access control is through Active Directory groups, so I can control who gets to do what. > If I was giving our CM Design and CVSNT Administration course and someone > proposed what you've done with the 'single script location for all repos on > a server' I'd ask 'what rule governs when to create a new repository?'. > Generally our 'best practice' recommendation is to create a new repo on a > server when you need different scripts/rules for the new repo. > > Security considerations aside - if all these repo's are using the same > rules - why not just have one repo (aside from historical reasons)? Each > directory can have different ACLs so that can't be the reason - user FRED > can be only valid for the module 'project/a' and user MARY can be valid only > for the module 'project/b'. > Of course this was all set up over ten years ago, and originally it was indeed for access control. The problem I saw with ACL's is who gets to decide the access rights. There is no set of administrators for a subdirectory. We have a nice web-based access control mechanism based on AD where two or three users can control who has access to their repository. Think about a company with 200 products. You may be the guy who knows about product 117, and you get to grant read and write access to that repository. I may know about product 45 (but nothing about 117), so I can hand out access to my repository. We really don't want to have a single person or group responsible for handing out access. It's just grunt work, and pointless effort. They'd always have to check with the repository owner before granting the access, and they don't add any value to the process. Furthermore, we need to impersonate the user in order to talk to one of our defect trackers. So we need to run as the committing user. In this circumstance Active Directory permissions are the safest way to go. Another reason to have multiple repositories is load balancing. With your monolithic repository, you are constrained to a single server, and it had better be huge. We have hundreds of Gb's of source in over 140 repositories, spread out over several servers and accessed by over 700 developers. If one repository becomes too big, we can move it to a different server. If several extremely active repositories are on one box and saturate the CPU or network or disk, we can move some of them to different boxes. When products become obsolete, we can pack that repository off and put it on that dusty server in the corner, but still feel confident that the build scripts will work if we need to build it again. We can use cheaper and easier to maintain hardware rather than getting huge iron that is expensive to upgrade or replace. We can even use VM's effectively. So if your company is small or works on just one or two products, the monolithic repository works ok. One of our previous cvs guys is now at another company where that is their approach. He finds that they are pretty much on the verge of needing to move to a "big boy" approach like ours. Access control is poorly managed, the server often bogs down, and backups are an issue. For him, the fact that they use a single repository for their product, web site, and internal database development seems like a bad plan. The only thing these items have in common is that they need to be revision-controlled. We typically take the approach that all servers are set up identically, and that when we need to upgrade a script we would rather do it once per server. Yes, we could programatically inject it into every CVSROOT if we had to, but there doesn't seem to any value in that approach. Now for my opinion. CVS in general seems to be geared at smaller groups. Not as small as VSS, but certainly not large enterprise operations. So your single repository approach, which is aimed at these smaller companies, probably makes sense. Especially if your best practices include turning on auditing. I do not expect any changes or support. I understand what Open Source means. We will continue to submit patches when appropriate that you may accept or reject. > The reason why I ask is just that I need to explain to (new) users when they > ask me: "when do I use this option 'use same script for all repos'?" versus > "when do I create a new repo?". > I'm not sure I understand that question. It's like asking "do I want electric windows" versus "do I want tilt steering?" The answer may be yes or no to either piece independently. You use the same script for all repositories when you want them all to behave the same. If you don't have multiple repositories, then by default you are using the same script for all one of them. In some cases my repository will run the common script and a custom script based on that repository. You create a new repository based on independent sets of source code and/or other considerations, like scripts being different (if you are unable to parse on the module). If your company is small, go with a single repository if you like. If you have multiple products that are reasonably large, then you'll probably want multiple repositories. If you're considering multiple servers, you probably want multiple repositories. Cheers chuck > Regards, > > > Arthur > > > >