Goals
-----

This directory implements the Subversion's branches concept in a trunk, branches, tags repository structure.

Description
-----------

The branches/ directory structure is an intermediate space between trunk/ directory structure and tags/ directory structure.

Usage
-----

If changes committed up to the main develpment line are all predictable (e.g., there is just one person committing changes), there is no a big need of using branches/ directory structure, in this case we can go straight from trunk/ to tags/. However, when there is no way to predict changes in the main development line (e.g., there are many people working at it at the same time) it is needed to find out a different place for changes to occur in more predictable ways.

At this point, several options may arise to create branches. In the CentOS Artwork Repository we prefer to use the idea of separating the main development line into different major development lines whose receive frequent update in a fixed period of time. In this configuration, a major development line is a directory structure branched from trunk/ directory structure. That is, we take a functional instance of trunk/ directory structure and store it under branches/ directory structure using a branch identifier and the same hierarchy the main development line uses.

When we create separete development lines, this way, we are creating a major development line that will receive minor updates to current functionalities but won't introduce new functionalities nor remove old ones. This is very importat if you need to have a predictable behaviour for that branch content through a period of time. When that period of time is gone, a new major development line is created to introduce new functionalities from trunk/ directory structure and so repeating the whole production cycle.

In order to create branches inside the CentOS Artwork Repository the whole repository structure must be considered. This is because all directory structures stored under trunk/ directory structure are connected among themselves. This way, we create branches for the whole trunk/ directory structure and never to individual components inside it. On the other hand, creating branches for the whole trunk/ directory structure duplicates lots of files and demands a considerable amount of storage space which is not convenient. As an intermediate solution, we do not create branches for the trunk/Identity/ directory structure, but the trunk/Manual, trunk/Scripts and trunk/Locales directory structures only. This way, we create documentation, automation scripts and locale information for specific revisions of turnk/Identity directory structure.

A good reason to create a major development line could be documentation.  Consider how hard it could be build a documentation manual if the target of it is changing unpredictably; what are we documenting? Something similar happens with centos-art command-line, if the directory structure the centos-art was design to work with changes unexpectedly it is very hard to implement a path-based functionality in that environment; where are we retriving files from or saving them to?

Assuming there is no way to predict changes in main development line, the creation of new branches inside the CentOS Artwork Repository uses The CentOS Project Release Schema.  This is, a new major development line is created every 2 years using trunk/ directory structure as reference. Each major development line is updated regulary in order to create frozen lines under tags/ directory structure every 6 months.

The updates commited up to individual major development lines need to be merged into the trunk/ directory structure in order for further major development lines to benefit from previous major development lines improvements.  The appropriate moment to commit from major development lines to trunk/ directory structure is when the frozen line of a major development line is been created.  This way, the main development line is the central place for changes, a place to concentrate changes from different major development lines that may be or not being developed at the same time.

As general convenction, when a new major development line is created, functionalities from previous major development lines are included into the new development line. However, improvements for components included from previous major development lines are not handled inside the new major development line which imported them. Such improvements are handled by the previous development line and merged up to main development line to improve the main development line, in the same way the new major development line merges the improvements of the new functionalities it was created for. As final resault, both changes merged from new and previous major development lines will be included into the next major development line.

See also
--------