Friday, December 15, 2006

Continue Review of "All About CVS"

Concurrent Versioning System (CVS) - the cominant open-source network-transparent version control system.

I need to design, install and maintain a CVS Suite configuration management solutions on a Windows based system.

Theory behind configuration management and in particular source code control.

Secure Shell protocol (SSH)

CVSNT helps computer users keep track of changes to files.

Configuration Management (CM) - a discipline to ensure that the configuration of a item and its components is known, documented and that changes are controlled and tracked.

Purpose - to ensure the integrity of a product and to make its evolution more manageable.

For CM to be effective, it must ensure the integrity of all managed items in each development stage, and make their evolution more manageable, and their interrelationship clear.

Version identifiers or version numbers of individual files do not relate specifically to the version number of an entire application. Since our applications are made up of more than a single file, the collection of files that make a product version is numbered separetely to the version numbers of the individual files.

It is important to distinguish between the version numbers used internally by CVSNT and external numbering schemes used by us. These external numbering schemes are recorded in CVSNT ad tables or labels.

concurrent development - massively parallel development.

Client software - manages the files on your computers.

Server software - manages the repository of files from all computers and users on the network.

A single server can host multiple repositories.

A single repository can host multiple projects.

Each repository and each project can have different users with varying permissions to objects, branches and meta data such as tags.

Ant is a tool similar to Make designed for use in Java projects.

For configuration management t obe effective it must be implemented in such a way that is consistent with our corporate or 'project' culture and is designed to deliver results according to our managment objectives.

Choices for a CM solution are guided overall by management objectives and then by company culture. Do I understand these?

I should avoid using personal preference as a guide.

The most important thing is delivery.

Reserved/Unreserved - is a file reserved for editing by a single user, or can multiple users all edit the same version of the same file at once.

Centralized/De-Centralized - Is a central reference copy of the source code always available, or do users work more autonomously on their own personal copy?

This give 4 possible models:

  • Reserved Centralized
  • Reserved Distributed
  • Unreserved Centralized
  • Unreserved Distributed
Right now I would lean to 'Unreserved Distributed'

Object code can always be re-generated a long as the source code is available.

Branches are used whenever the evolution of changes to the code is not sequential. Branching supports to streams of development.

Magic branches are used when the code exists as several variations, however as individual documents the majority is identical.

CVS stores three things for each document it is managing:

  • The latest version
  • The history as differences to the latest version
  • meta data about each version d
When a person creates a branch there are two "latest versions" stored by CVS in the repository. This allows differences to be kept for both.

Development models assume that the majority of changes will be performed on the Trunk, and then migrated as necessary to other branches.

Branching intensive development model. Most flexible, least control.

Promotion intensive development model. Least flexible, most control.

Mixed model 1:

  • develop version 1 on the trunk
  • when version 1 is feature complete branch version 1 maintenance
  • begin work on version 2 on the trunk
  • finalize version 1 on the branch
  • promote version 1 branch to test
  • fix version 1 bugs on the version 1 branch and promote to test again
Mixed model 2:

  • develop version 1 on the trunk
  • when version 1 is feature complete promote to integration
  • development for version 2 is placed on a branch to be integrated in later
  • when version 1 is integrated promote to testing
  • when version 1 is promoted to production
I am not sure this model makes sense.

ELSYS has been following a promotional model in development.

The client side of CVS works with the files in a sandbox locally.

The server side of CVS works with the files in the repository.

What model is SUSTAIN using?

What backup do we need to do for the repositories?

The CVS repository stores CVS configuration information plus all the versions of each of the documents and also meta data about each of these versions.

The repository should not be named CVS or CVSROOT since these names have specific meaning to CVS.

Don't version control a directory or file name CVS, AUX, LPT, CON, or other "Microsoft DOS" reserved word.

Should be using Server 2000 or 2003.

It is best to have 10 times the size of the files being checked in available in memory. Three times is the absolute minimum.

  • 100 meg file means 1000 meg (1 gig) of memory (best)
  • 100 meg file means 300 meg of memory (minimal)
Faster disks are generally more valuable than more processors or faster processor in a CVSNT server system.

For maimum security let the operating system handle the security (SSPI - Windows, SSH Unix).

Pserver should be disabled.

Refactoring of the repository (name changes)

Project and module refer to the same thing.

Each top-level directory is a module.

Directories below the top-level are module aliases.

Email sending is disabled by default.

No comments: