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