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.
patrick goovaerts wrote: > Currently i'm investigating the use of CVSNT for our IT/dept. Our IT/Dept > includes 5 developers which are integrated in a seperate company, acting > as > a 'Back-Office' for the 7 companies in our Group. The develpers have no > specific role (java-programmer, web-developer, graphical designer,...). > They have there own projects to work with and these projects can be > RPGIV-Java-Web-...based. (no version control needed!) Why do some projects need no version control? > When a developer is > not at the office, other developers must have access to his projects to > make > some changes when needed. Finally, they all will work with IBM > RAD-developer suite (WDSCi 6.x) > > 1) Workspaces (Eclipse) > - Local Access > Each user will have it's own workspace on his Dev-PC. When developers > work on their local workspace only, this creates the problem of > project-availability for other developers. > > - NetworkFolders > Therefore I tried to store projects on a network-drive and let the > developer > point to this network-workspace. This works for some projects but not for > all (web-projects and webfaced projects are too big to work properly). Working across network folders will thrash your network, will be slow, and isn't a good idea. > - Local Access with NetworkFolders > Another option is to ask the developer to copy the workspace from the > network-folder to his own dev-pc first. Work on the project and restore > to the networkfolder. The modern version of sneakernet. > ==> Because the network-drive is in our Backup-process, we don't have to > worry much for loss of projects. The full workspaces are backed-up and > can > be restored 'as-is'. But, this also means that every project needs to be > stored as a full workspace (loss of default workspace preferences). This > overload on workspaces will become 'unreadable' over time (to give an > idea, we have about 500 applications running for the moment) That's more of a problem with your development environment than anything else. > 2) CVS > It looks like CVS can help us here. Because all projects are stored on a > reserved server, they can be retrieved easily when needed be each > developer > at any time. After working on a project, he can choose to create a new > version or not, however this is not a key-issue. You need to differentiate between working on and modifying a project. > 3) Backup/Restore issues > CVS-Backup is covered by our TSM-backup-procedures, so we don't have to > worry about that either. However, i noticed that the sources are changed > by > CVS and have a changed name (source.java,v). You really shouldn't care how cvs[nt] stores the files and data in its repository... just realize that its in there along with all the revisions and a bunch of metadata, and needs to be part of your data management process. > In fact, the source is saved > in it's original state and changes are written at the end of the file... More-or-less true. > So, what happens in case of server-failure? Then you discover whether your disaster recovery process works or not :-) Treat the cvsnt server as you would any other critical server (with things like a on/off site hot/cold standby, data backup, OS/application backup, etc.) > Or when we need to upgrade > the > CVSNT-version? You just upgrade the cvsnt software. > Are all the sources available again after rebuilding the > server and restoring the data-folders (which contains the CVS-folders)? Yes. Greetings from Luxembourg, David Somers typographer/programmer/whatever