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

[Arthur Barrett]

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