@subsection Goals

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

@subsection Description

The @file{branches/} directory structure is an intermediate space
between @file{trunk/} directory structure and @file{tags/} directory
structure.

@subsection 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 @file{branches/} directory structure, in
this case we can go straight from @file{trunk/} to @file{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 @file{trunk/} directory structure. That is, we take a
functional instance of @file{trunk/} directory structure and store it
under @file{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 @file{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 @file{trunk/} directory structure
are connected among themselves. This way, we create branches for the
whole @file{trunk/} directory structure and never to individual
components inside it. On the other hand, creating branches for the
whole @file{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 @file{trunk/Identity/} directory structure, but the
@file{trunk/Manual}, @file{trunk/Scripts} and @file{trunk/Locales}
directory structures only. This way, we create documentation,
automation scripts and locale information for specific revisions of
@file{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 @command{centos-art}
command-line, if the directory structure the @command{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 @file{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 @file{trunk/}
directory structure as reference. Each major development line is
updated regulary in order to create frozen lines under @file{tags/}
directory structure every 6 months.

@image{trunk/Identity/Models/Img/Scripts/Bash/Functions/Path/figure-1,400pt}

The updates commited up to individual major development lines need to
be merged into the @file{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 @file{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.

@subsection See also

@menu
* Filesystem trunk::
* Filesystem tags::
@end menu