[cvsnt] CVSNT implementation reliable?
David Somers
dsomers at omz13.com
Sat Aug 5 15:02:29 BST 2006
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
More information about the cvsnt
mailing list