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, > 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. No not at all - you just handle it identically to how you do now. So you start with everything on 'server' but have the cnames a/b/c/d setup: :pserver:servera:/repo co project/a :pserver:serverb:/repo co project/b :pserver:serverc:/repo co project/c :pserver:serverd:/repo co project/d If you move project/d to a new server (fastbox) then you just move the cname. Eventually I'd like to use the 'publish/advertise' function in cvslock daemon (use 'cvs info -b' for a demo) to automatically find a repo, so the CVS/Root and CVS/Repository would just be ::myproject:: and CVSNT client would just listen for what server is advertising that project and get it from there (since advertising is a broadcast it isn't passed over sub-nets - therefore resulting in each sub-net automatically finding the fastest mirror for any project). The plan also calls for what we refer to as 'multiroot' where CVS/Root and CVS/Repository can have 'multiple roots' so if the ::project:: name cannot be found that the client can then use one of the previously found servers (eg: if you are at a hotel and using a VPN which blocks the multicast advertising). All the hard technical stuff is done - it's just the tedious process of hacking in the changes to CVS itself and the various gui elements. > You didn't give me any reason why I would want to switch my current setup > to a single repository. Mostly I'm trying to ensure I don't add features that encourage people to do the same as you (since it's a lot of work and not necessary). For you there would be a lot of effort in changing back now you've got existing systems running this way - which is one of the reasons I was keen to get the patch added (albeit as safely as possible). I suspect you are doing more work than is needed, and it'll make it harder to take advantage of new features in 2.5.04 such as the repository mirroring which would provide for much more 'ad-doc' capacity building. Splitting up repos prevents teams sharing any common code (though that may not currently be a requirement). > 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. ClearCase, Continuus/CM Synergy and PVCS Dimensions are the three top SCM systems according to Gartner and they all use this monolithic database backend. EVSCM is not for everyone - but the big end of town has consistently chosen SCM tools built this way. Generally I think EVSCM be implemented by companies trying to consolidate various disparate SCM tools already in use (SVN, CVS, CVSNT, MSTS, CC, Dimensions) to a single one that supports 'the best of all' and provides centralised management and auditing and a one-stop-shop for integrations (build etc). Despite not being for everyone - EVSCM is a logical extension to our family of SCM tools and hence why it's important for me to have a consistent message on things like 'many repos' vs. 'one repo'. At the end of the day I don't care how many repos a customer has or sets up (we have the 'multiple repo' function there so people can use it), however I need a clear answer at the ready when they ask me for 'best practice'. Regards, Arthur