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, > > 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). > If I move a module to another repository, all the get scripts will now need to check it out from this different repository. Everyone has to reroot or reget their source. If I move a repository including the cname, my users never know it. > 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. > Exactly. > 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). > >> 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), cvswrappers files are one of the places where repositories vary substantially. One team's binary is another team's text extension. > 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). > Again, most of our setup predates cvsNT and ACLs. Maybe we would do it differently if starting today, maybe not. It would just be speculation. You didn't give me any reason why I would want to switch my current setup to a single repository. Unless I would see substantial benefits I would not want to incur the cost. And without trying it I can't say that performance would or would not be adequate. So I'll abstain on that question. As for EVSCM, I really can't say. Until you work with something you don't know where its sharp edges are. Big databases worry me because I can't recover a file from backups without losing all other changes that came after it. I'm not sure what level of hardware would be necessary for a multi-terabyte monolithic repository. On the other hand, it may be incredibly efficient working with a single DB. I just don't know. I really don't feel qualified to comment on a product I've never used. But as you say, it's academic because we're not interested in this route. > Regards, > > > Arthur > > > >