[cvsnt] CVSNT implementation reliable?

David Somers dsomers at omz13.com
Sat Aug 5 15:02:29 BST 2006


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


More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook