SVN Structure Conventions

Majoron (www.majoron.com)

Revision History
Revision 1.02007.11.12

The first revision

Abstract

This book declare structure conventions for SVN folder organization.


Table of Contents

Definitions
Repository Organization
Overview
Promoting
Releasing
Workspace
Repository Structure
Overview
Up Level
Projects
Solution
Realising
Workspace
A. Example1
B. Questions

Definitions

Components is a single logically indivisible unit. For example executable program or shared module is a component. Web site may be considered as a component too.

Product is a local software system to resolve some tasks. Product may consists from a several components. For example notepad is a product.

Service is a remote rather than local software system to resolve some tasks. Product may consists from a several components. For example gmail.com is the service.

Website is a software system for presentation and promoting one or group products at Internet.

Projects is a any kind of a sensible software activity to archive a fixed goal. For example service or product which resolve some tasks is a project. Also web site for promoting some products is a project too.

Solution is a project for one or group customers. For example implementation private protocol for customer is the solution.

Repository Organization

Overview

This section cover some basic principals for repository structure organization.

Promoting

There is a few strategies for product promoting. What kind of strategy use for the product is a separate subject to discuss.

One product a one site devoting to product
One product a few sites devoting to different areas of product
One product a one site, which contains promoting different products.

If will be used first strategy for product promoting then SVN structure contains one project with name of the products. This project contains website and product, which consists from a set of the components. If will be used other strategy for product promoting then SVN structure will be contain different project for product itself and website. This separation allows to disconnect product promoting and SVN structure to avoid SNV structure reorganization.

There is a one strategies for service promoting.

One service a one web presentation devoting to serivce

Releasing

Projects and solutions are objects for realising. TODO: place here about 0.5

Workspace

TODO: place here infromation about project file organizaiton: msvc + eclipse and etc..

Repository Structure

Overview

This section cover a repository structure for special types of the projects.

Up Level

First level of the SVN repository consists from

3rdparty. This is folder contains3rdparty library.
Distribs This is folder contains 3rdparty library distributives.
Documents This is folder contains documents for while work organization. This kind of documents applicable for all projecs.
Projects This is folder contains projects.
Solutions This is folder contains solutions

Projects

This folder contains all projects (websites, services and products) by name. For each project SVN structure looks like below.

Websites if project contatins a websites.
Services if project contatins a services.
Components. This folder contains all components for product or service.

Solution

This folder contains all solutions by name. SVN structure is similar with project SVN structure.

Realising

For realising projects and solution

Workspace

To think about it.

A. Example1

This is example SVN structure for OLS project. This is project consists from website and components.

  • OLS

    • Website

      • ols

        • 0.5

        • 1.0

      • dms

        • 0.5

        • 1.0

    • Components

      • 0.5

        • Documnets

        • OSLCore

        • Codecs

        • Workspace

          • msvc

          • eclipse

          • automake

      • 1.0

        • Documnets

        • OSLCore

        • Codecs

        • Workspace

          • msvc

          • eclipse

          • automake

B. Questions

Should we have different folder for Services, Project and Websites?
Should documentation be for each release (0.5 and etc) or common for while project or both?