[cvsnt-dev] patches for script_trigger.cpp and server.h

[Chuck Kirschman]

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
> 
> 
> 
>