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

[Arthur Barrett]

Chuck,

Thanks again for your time to explain.

> They don't need write access to the CVSROOT

Yes that is understood.

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

It's already possible to delegate the 'control' permission to a user or 
group of users for any sub-directory, and whilst we do not provide a web 
interface the CVS Suite Studio does include a nice graphical way of 
controlling permissions (in 2.5.04 an evaluation copy/cut down 'cost free' 
edition of this is included primarily for this purpose).

> Another reason to have multiple repositories is load balancing.

It's really no harder to move a module than a repository (especially if the 
administrative scripts are all at the machine level).

Your patch is machine specific so it doesn't really help when moving 
machines - tthough if all machines are organised the same way then in theory 
the scripts are already on the new machine.

Finally 2.5.04 addresses scalability by allowing the admin to set up proxy 
servers (assuming that the spike loads are mostly read's).

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

The advantage would be in isolation (in the event a hacker compromised the 
security fewer projects/users would be affected).

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

Are you suggesting that repository auditing is only an issue for small 
companies?  This feature is generally only required by 100+ user 
installations.

> We will continue to submit patches when appropriate that you may accept or 
> reject.

One of my roles as product manager is to encourage all users to contribute - 
either by paying for support or by doing what you are doing now - submitting 
comprehensive bug reports and testing and patches.  I personally don't care 
how people contribute (by cash or in kind) however I do care that people 
contribute.

The only reason why we'll reject a patch is if it is superfluous (eg: if it 
implements tic-tac-toe, or duplicates existing functionality) or if it 
represents a security risk.

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

What you are saying about multiple servers and multiple repositories has 
some merit (especially if the CVSROOTs do contain a lot of differences - 
though that does NOT seem to apply to your org), and the whole reason why 
CVSNT supports adding multiple repositories is that we did envisage that a 
user may want multiple repositories (some banking customers require 'chinese 
walls' where one user not simply denied access to another project but their 
username is not valid on that project which can only be implemented with 
multiple repositories).

However large org/multiple projects == multiple repositories I think is 
something that is best actively discouraged - it's not required for any 
technical reason and steers users to 'native' ACLs or trying to implement 
security in administrative scripts rather than using the cvsnt native acls.

I realize that if we design an idiot proof product only idiots will want to 
use it, but we still need to give some thought to whether implementing some 
feature sends the wrong message eg: when we implemented parsable lists of 
protocol properties some people thought that we wanted CVSROOT to adopt a 
new syntax and started building CVSROOTs like 
:protocol:hostname=host;password=passwd:/repo which was never our intention 
(quite the opposite in fact), but we do some accept responsibility for the 
misunderstanding since we did implment that feature and did not clearly 
specify what it was for.

Finally whilst your question is about CVSNT we often think in terms of EVSCM 
(was previously CVSNT 3.x), which does not have RCS files at all but an 
database on the back end (eg: MS SQL or Oracle).  Now whislt it's a bit OT 
and academic - please humour me: in this new system do your reasons for 
separate repositories hold up?  I do not think so - moving rows in a 
database is much much more difficult than moving the RCS files around.  I 
suppose you could ask for a separate database for each repo - but since each 
database has considerable overhead of its own that may not have the desired 
effect.

I'll be very interested in your feedback - particularly about the 
performance problems that lead to moving a repository to a separate 
machine - I suspect that the new repository proxies will resolve that.  If 
they do not then I guess you are implying that the load is a write/tag one - 
and that would be a more serious problem to overcome (particularly in an 
EVSCM context).

Regards,


Arthur