Code Repository Introductory Tour

In this short tour of this section we will help the new user to get to know the LAMPAS code repository system, how it works and how to use the tools provided.

The code repository controls basically 4 task groups:

• Version Control
• Module Management
• Application Management
• Wizards

From the Code Repository Home Page, we link out to the various task groups like such:

Version Control
Version control takes a slightly different approach to other version control management systems. First of all, the only object in this system that you can control is the "branch". Version numbers in a branch is controlled dynamiccaly as modules are checked out and in again.

Under LAMPAS, the branch represents a "stream". In other words, if you have an application called "MyCMS", then typically you could have two "branches":

• The "development" branch
• The "production" branch

Application administrators will define a "release" within a branch. That involves the following:

• Define a new release
• Define a module with a version inside a branch as the "Main" module
• Define dependencies between other modules and the "Main" module

Coming back to our sample application, "MyCMS", you will have under your two branches various modules, each with several versions as developers work on the modules. At some point, an Application administrator will start a new release and define which modules in each branch hang together. That is taken live in that stream.

The developer as access to the "branch" management portion of the version control system, and can do the folloing:

• Pick an "active" branch
• Define a new branch
• View the various branches
• Edit an existing branch
• Delete a branch

From the Code Repository point of view, your options look graphically like the following:

Technically, branches are not deleted, but rather marked "inactive". There will later be an option to completely remove the branche together with it's associated modules.

When defining a news branch, the developer will be given the option to duplicate an existing branch (only the newest version of each module) from where to start. Given our example, if a group of developers want to experiment with a new concept, they will be able to create a "concept" branch and use the latest version of each module in the current "production" branch as the base.

Module Management
Module management relates to the actual source code. Conceptually you can think of a module as a Perl "sub". An application therefor, is a couple of modules or conceptually a couple of "sub's" in a regular Perl program.

The module management web interface can be descibed as follows:

Defining a new module is conceptually the same as:

sub YourSubName {

	# source code starts below...

	return 1;

}

• A unique ID (automatically generated)
• A name ("YourSubName" as an example)
• A description
• A type
• Module Docuemtation (linked to each version)

The rest of the module properties relates to the module source code and version information. Defining a new module, as well as editing an existing module, therefor deals with the setting or updating of the above module elements.

To Do

In this to do section I will document the things I still need to do for updating this document:

• Add the "Application management" section
• Add the "Wizards" section
• Spell Check document
• Upload the document

Change Log

In this section I add notes on what was updated since the last version. This will be an ever growing list, as I do not intend to keep a version number on this document.

• Updated several of the images
• Added the basic text

Last Updated : 2005-10-02