|
|
6ba043 |
@subsection Goals
|
|
|
6ba043 |
|
|
|
09d4f2 |
This section exists to organize files related to @code{path}
|
|
|
09d4f2 |
functiontionality of @file{centos-art.sh} script. The @code{path}
|
|
|
09d4f2 |
functionality of @file{centos-art.sh} script standardizes movement,
|
|
|
09d4f2 |
syncronization, branching, tagging, and general file maintainance
|
|
|
09d4f2 |
inside the repository.
|
|
|
6ba043 |
|
|
|
6ba043 |
@subsection Description
|
|
|
6ba043 |
|
|
|
09d4f2 |
@emph{''CentOS like trees, has roots, trunk, branches, leaves and
|
|
|
09d4f2 |
flowers. Day by day they work together in freedom, ruled by the laws
|
|
|
09d4f2 |
of nature and open standards, to show the beauty of its
|
|
|
09d4f2 |
existence.''}
|
|
|
6ba043 |
|
|
|
09d4f2 |
@subsubsection Repository layout
|
|
|
09d4f2 |
|
|
|
09d4f2 |
The repository layout describes organization of files and directories
|
|
|
09d4f2 |
inside the repository. The repository layout provides the standard
|
|
|
09d4f2 |
backend required for automation scripts to work correctly. If such
|
|
|
09d4f2 |
layout changes unexpectedly, automation scripts may confuse themselves
|
|
|
09d4f2 |
and stop doing what we expect from them to do.
|
|
|
09d4f2 |
|
|
|
09d4f2 |
As convenction, inside CentOS Artwork Repository, we organize files
|
|
|
09d4f2 |
and directories, related to CentOS corporate visual identity, under
|
|
|
09d4f2 |
three top level directories named @file{trunk/}, @file{branches/}, and
|
|
|
09d4f2 |
@file{tags/}.
|
|
|
09d4f2 |
|
|
|
09d4f2 |
@float Figure, trunk/Identity/Models/Img/Scripts/Bash/Functions/Paths/figure-6
|
|
|
09d4f2 |
@image{trunk/Identity/Models/Img/Scripts/Bash/Functions/Path/figure-6}
|
|
|
09d4f2 |
@caption{The CentOS Artwork Repository layout.}
|
|
|
09d4f2 |
@end float
|
|
|
09d4f2 |
|
|
|
09d4f2 |
The @file{trunk/} directory (@pxref{trunk}) organizes the main
|
|
|
09d4f2 |
development line of CentOS corporate visual identity. Inside
|
|
|
09d4f2 |
@file{trunk/} directory structure, the CentOS corporate visual
|
|
|
09d4f2 |
identity concepts are implemented using directories. There is one
|
|
|
09d4f2 |
directory level for each relevant concept inside the repository. The
|
|
|
09d4f2 |
@file{trunk/} directory structure is mainly used to develop CentOS
|
|
|
09d4f2 |
corporate visual identity.
|
|
|
09d4f2 |
|
|
|
09d4f2 |
The @file{branches/} directory (@pxref{branches}) oranizes parallel
|
|
|
09d4f2 |
development lines to @file{trunk/} directory. The @file{branches/}
|
|
|
09d4f2 |
directory is used to set points in time where develpment lines are
|
|
|
09d4f2 |
devided one from another taking separte and idependent lives that
|
|
|
09d4f2 |
share a common past from the point they were devided on. The
|
|
|
09d4f2 |
@file{branches/} directory is mainly used to perform quality assurance
|
|
|
09d4f2 |
on CentOS corporate visual identity.
|
|
|
09d4f2 |
|
|
|
09d4f2 |
The @file{tags/} directory (@pxref{tags}) organizes parallel frozen
|
|
|
09d4f2 |
lines to @file{branches/} directory. The parallel frozen lines are
|
|
|
09d4f2 |
immutable, nothing change inside them once they has been created. The
|
|
|
09d4f2 |
@file{tags/} directory is mainly used to publish final releases of
|
|
|
09d4f2 |
CentOS corporate visual identity.
|
|
|
09d4f2 |
|
|
|
09d4f2 |
The CentOS Artwork Repository layout is firmly grounded on a
|
|
|
09d4f2 |
Subversion base. Subversion (@url{http://subversion.tigris.org}) is a
|
|
|
09d4f2 |
version control system, which allows you to keep old versions of files
|
|
|
09d4f2 |
and directories (usually source code), keep a log of who, when, and
|
|
|
09d4f2 |
why changes occurred, etc., like CVS, RCS or SCCS. Subversion keeps a
|
|
|
09d4f2 |
single copy of the master sources. This copy is called the source
|
|
|
09d4f2 |
``repository''; it contains all the information to permit extracting
|
|
|
09d4f2 |
previous versions of those files at any time.
|
|
|
09d4f2 |
|
|
|
09d4f2 |
@subsubsection Repository name convenctions
|
|
|
09d4f2 |
|
|
|
09d4f2 |
Repository name convenctions help us to maintain consistency of names
|
|
|
09d4f2 |
inside the repository.
|
|
|
09d4f2 |
|
|
|
09d4f2 |
Repository name convenctions are applied to files and directories
|
|
|
09d4f2 |
inside the repository layout. As convenction, inside the repository
|
|
|
09d4f2 |
layout, file names are all written in lowercase
|
|
|
09d4f2 |
(@samp{01-welcome.png}, @samp{splash.png}, @samp{anaconda_header.png},
|
|
|
09d4f2 |
etc.) and directory names are all written capitalized (e.g.,
|
|
|
09d4f2 |
@samp{Identity}, @samp{Themes}, @samp{Motifs}, @samp{TreeFlower},
|
|
|
09d4f2 |
etc.).
|
|
|
09d4f2 |
|
|
|
09d4f2 |
Repository name convenctions are implemented inside the
|
|
|
09d4f2 |
@code{cli_getRepoName} function of @file{centos-art.sh} script. With
|
|
|
09d4f2 |
@code{cli_getRepoName} function we reduce the amount of commands and
|
|
|
09d4f2 |
convenctions you need to remember concentrating them in just one
|
|
|
09d4f2 |
single place you can look for fixes and improvements.
|
|
|
09d4f2 |
|
|
|
09d4f2 |
@subsubsection Repository work flow
|
|
|
09d4f2 |
|
|
|
09d4f2 |
Repository work flow describes the steps and time intervals used to
|
|
|
09d4f2 |
produce CentOS corporate visual identity inside CentOS Artwork
|
|
|
09d4f2 |
Repository.
|
|
|
09d4f2 |
|
|
|
09d4f2 |
To illustrate repository work flow let's consider themes' development
|
|
|
09d4f2 |
cycle.
|
|
|
09d4f2 |
|
|
|
09d4f2 |
Initially, we start working themes on their trunk development line
|
|
|
09d4f2 |
(e.g., @file{trunk/Identity/Themes/Motifs/TreeFlower/}), here we
|
|
|
09d4f2 |
design background images and propagate them to different visual
|
|
|
09d4f2 |
manifestations using one theme's model as reference.
|
|
|
09d4f2 |
|
|
|
09d4f2 |
Later, when the theme is considered ``ready'' for implementation (i.e.
|
|
|
09d4f2 |
all visual manifestations have been already set), we create a branch
|
|
|
09d4f2 |
for it (e.g., @file{branches/Identity/Themes/Motifs/TreeFlower/1/}).
|
|
|
09d4f2 |
Once the branch has been created, we forget that branch and continue
|
|
|
09d4f2 |
working the trunk development line while others (e.g., an artwork
|
|
|
09d4f2 |
quality assurance team) test the new branch for tunning it up.
|
|
|
09d4f2 |
|
|
|
09d4f2 |
Once the branch has been tunned up, and considered ``ready'' for
|
|
|
09d4f2 |
release, it is freezed under @file{tags/} directory (e.g.,
|
|
|
09d4f2 |
@file{tags/Identity/Themes/Motifs/TreeFower/1.0/}) for packagers,
|
|
|
09d4f2 |
webmasters, promoters, and anyone who needs images from that CentOS
|
|
|
09d4f2 |
theme the tag was created for.
|
|
|
09d4f2 |
|
|
|
09d4f2 |
Both branches and tags, inside CentOS Artwork Repository, use
|
|
|
09d4f2 |
numerical values to identify themselves under the same location.
|
|
|
09d4f2 |
Branches start at one (i.e., @samp{1}) and increment one unit for each
|
|
|
09d4f2 |
branch created from the same trunk development line. Tags start at
|
|
|
09d4f2 |
zero (i.e., @samp{0}) and increment one unit for each tag created from
|
|
|
09d4f2 |
the same branch development line.
|
|
|
09d4f2 |
|
|
|
09d4f2 |
@float Figure, trunk/Identity/Models/Img/Scripts/Bash/Functions/Paths/figure-1
|
|
|
09d4f2 |
@image{trunk/Identity/Models/Img/Scripts/Bash/Functions/Path/figure-1}
|
|
|
09d4f2 |
@caption{Name convention for tags and branches creation.}
|
|
|
09d4f2 |
@end float
|
|
|
09d4f2 |
|
|
|
09d4f2 |
As proposition, it would be convenient not to freeze trunk development
|
|
|
09d4f2 |
lines using tags or anything else. If you think you need to freeze a
|
|
|
09d4f2 |
trunk development line, create a branch for it and then freeze that
|
|
|
09d4f2 |
branch instead.
|
|
|
09d4f2 |
|
|
|
09d4f2 |
The trunk development line may introduce problems we cannot see
|
|
|
09d4f2 |
immediatly. Certainly, the high changable nature of trunk development
|
|
|
09d4f2 |
line complicates finding and fixing such problems. On the other hand,
|
|
|
09d4f2 |
the branched development lines provides a less changable area where
|
|
|
09d4f2 |
only small fixes/corrections are commited up to repository.
|
|
|
09d4f2 |
|
|
|
09d4f2 |
If others find and fix bugs inside the branched development line, we
|
|
|
09d4f2 |
could merge such changes/experiences back to trunk development line
|
|
|
09d4f2 |
(not visversa) in order for future branches, created from trunk, to
|
|
|
09d4f2 |
benefit.
|
|
|
09d4f2 |
|
|
|
09d4f2 |
Time intervals used to create branches and tags may vary, just as
|
|
|
09d4f2 |
different needs may arrive. For example, consider the release schema
|
|
|
09d4f2 |
of CentOS distribution: one major release every 2 years, security
|
|
|
09d4f2 |
updates every 6 months, support for 7 years long. Each time a CentOS
|
|
|
09d4f2 |
distribution is released, specially if it is a major release, there is
|
|
|
09d4f2 |
a theme need in order to cover CentOS distribution artwork
|
|
|
09d4f2 |
requirements. At this point, is where CentOS Artwork Repository comes
|
|
|
09d4f2 |
up to scene.
|
|
|
09d4f2 |
|
|
|
09d4f2 |
Before releasing a new major release of CentOS distribution you can
|
|
|
09d4f2 |
create a branch for one of several theme development lines available
|
|
|
09d4f2 |
inside the CentOS Artwork Repository, perform quality assurance on it,
|
|
|
09d4f2 |
and later, freeze that branch using tags. Once a the theme branch has
|
|
|
09d4f2 |
been frozen (under @file{tags/} directory), CentOS Packagers (the
|
|
|
09d4f2 |
persons who build CentOS distribution) can use that frozen branch as
|
|
|
09d4f2 |
source location to fulfill CentOS distribution artwork needs.
|
|
|
09d4f2 |
|
|
|
09d4f2 |
@subsubsection Parallel directories
|
|
|
6ba043 |
|
|
|
09d4f2 |
Inside CentOS Artwork Repository, parallel directories are simple
|
|
|
09d4f2 |
directory entries built from a common parent directory and placed in a
|
|
|
09d4f2 |
location different to that, the common parent directory is placed on.
|
|
|
09d4f2 |
Parallel directories are useful to create branches, tags,
|
|
|
09d4f2 |
translations, documentation, pre-rendering configuration script, and
|
|
|
09d4f2 |
similar directory structures.
|
|
|
09d4f2 |
|
|
|
af53cb |
Parallel directories take their structure from one unique parent
|
|
|
af53cb |
directory. Inside CentOS Artwork Repository, this unique parent
|
|
|
af53cb |
directory is under @file{trunk/Identity} location. The
|
|
|
af53cb |
@file{trunk/Identity} location must be considered the reference for
|
|
|
af53cb |
whatever information you plan to create inside the repository.
|
|
|
09d4f2 |
|
|
|
09d4f2 |
In some circumstances, parallel directories may be created removing
|
|
|
09d4f2 |
uncommon information from their paths. Uncommon path information
|
|
|
09d4f2 |
refers to those directory levels in the path which are not common for
|
|
|
09d4f2 |
other parallel directories. For example, when rendering
|
|
|
09d4f2 |
@file{trunk/Identity/Themes/Motifs/TreeFlower/Distro} directory
|
|
|
09d4f2 |
structure, the @file{centos-art.sh} script removes the
|
|
|
09d4f2 |
@file{Motifs/TreeFlower/} directory levels from path, in order to
|
|
|
09d4f2 |
build the parallel directory used to retrived translations, and
|
|
|
09d4f2 |
pre-rendering configuration scripts required by @code{render}
|
|
|
09d4f2 |
functionality.
|
|
|
09d4f2 |
|
|
|
af53cb |
Another example where parallel directory removes the uncommon path
|
|
|
af53cb |
information is when we use the @code{help} functionality. This time,
|
|
|
af53cb |
@file{centos-art.sh} script uses parallel directory information
|
|
|
af53cb |
(without uncommon directory levels) to build the documentation entry
|
|
|
af53cb |
required by Texinfo to store documentation entries inside the
|
|
|
af53cb |
repository.
|
|
|
09d4f2 |
|
|
|
09d4f2 |
@float Figure, trunk/Identity/Models/Img/Scripts/Bash/Functions/Paths/figure-3
|
|
|
09d4f2 |
@image{trunk/Identity/Models/Img/Scripts/Bash/Functions/Path/figure-3}
|
|
|
09d4f2 |
@caption{Parallel directories removing uncommon information.}
|
|
|
09d4f2 |
@end float
|
|
|
09d4f2 |
|
|
|
09d4f2 |
Othertimes, parallel directories may add uncommon information to their
|
|
|
af53cb |
paths. This is the case we use to create branches and tags. When we
|
|
|
af53cb |
create branches and tags, a numerical identifier is added to parallel
|
|
|
09d4f2 |
directory structure path. The place where the numerical identifier is
|
|
|
09d4f2 |
set on is relevant to corporate visual identity structure and should
|
|
|
09d4f2 |
be carefully considered where it will be.
|
|
|
09d4f2 |
|
|
|
09d4f2 |
@float Figure, trunk/Identity/Models/Img/Scripts/Bash/Functions/Paths/figure-4
|
|
|
09d4f2 |
@image{trunk/Identity/Models/Img/Scripts/Bash/Functions/Path/figure-4}
|
|
|
09d4f2 |
@caption{Parallel directories adding uncommon information.}
|
|
|
09d4f2 |
@end float
|
|
|
09d4f2 |
|
|
|
09d4f2 |
When one parent directory changes, all their related parallel
|
|
|
09d4f2 |
directories need to be changed too. This is required in order for
|
|
|
09d4f2 |
parallel directories to match the new parent directory structure. In
|
|
|
09d4f2 |
the other hand, parallel directories should never be modified by no
|
|
|
09d4f2 |
reason but to satisfy their parent directory structure. Liberal change
|
|
|
09d4f2 |
of parallel directories may suppress the conceptual idea they were
|
|
|
09d4f2 |
initially created for.
|
|
|
09d4f2 |
|
|
|
09d4f2 |
@float Figure, trunk/Identity/Models/Img/Scripts/Bash/Functions/Paths/figure-5
|
|
|
09d4f2 |
@image{trunk/Identity/Models/Img/Scripts/Bash/Functions/Path/figure-5}
|
|
|
09d4f2 |
@caption{Wrong construction of parallel directories.}
|
|
|
09d4f2 |
@end float
|
|
|
09d4f2 |
|
|
|
09d4f2 |
@subsubsection Syncronizing path information
|
|
|
09d4f2 |
|
|
|
09d4f2 |
Creating parallel directories is very useful to keep repository
|
|
|
af53cb |
organized. But, what would happen to functionalities like @code{help}
|
|
|
e68a7a |
(@strong{WARNING:} @emph{The @samp{trunk Scripts Bash Functions Help} documentation entry no longer exists.}) that rely on parent
|
|
|
09d4f2 |
directory structures to create documentation entries (using parallel
|
|
|
09d4f2 |
directory structures) if one of those parent directory structures
|
|
|
af53cb |
suddenly changes after the documentation entry has been already
|
|
|
af53cb |
created for it?
|
|
|
09d4f2 |
|
|
|
09d4f2 |
Well, at this point, functionalities like @code{help} may confuse
|
|
|
af53cb |
themselves if path information is not updated. Such functionalities
|
|
|
af53cb |
work with parent directory structure as reference; if a parent
|
|
|
af53cb |
directory changes, the functionalities dont't even note it because
|
|
|
af53cb |
they work with the last parent directory structure available in the
|
|
|
af53cb |
repository, no matter what it is.
|
|
|
09d4f2 |
|
|
|
09d4f2 |
In the specific case of documentation (the @code{help} functionality),
|
|
|
09d4f2 |
the problem mentioned above provokes that older parent directories,
|
|
|
09d4f2 |
already documented, remain inside documentation directory structures
|
|
|
af53cb |
as long as you get your hands into the documentation directory
|
|
|
af53cb |
structure (@file{trunk/Manuals}) and remove what must be removed to
|
|
|
af53cb |
match the new parent directory structure.
|
|
|
09d4f2 |
|
|
|
09d4f2 |
There is no way for @code{help}, and similar functionalities that use
|
|
|
09d4f2 |
parent directories as reference, to know when and how directory
|
|
|
09d4f2 |
movements take place inside the repository. Such information is
|
|
|
09d4f2 |
available only when movement actions, like thoses achived by
|
|
|
09d4f2 |
@command{rm} or @command{mv} commands, take place inside the
|
|
|
09d4f2 |
repository. So, is there, at the moment of moving files, when we need
|
|
|
09d4f2 |
to syncronize parallel directories with their unique parent directory
|
|
|
09d4f2 |
structure.
|
|
|
09d4f2 |
|
|
|
09d4f2 |
Syncronizing parallel directories with their respecitive parent
|
|
|
09d4f2 |
directory implies moving files inside the repository, i.e. we need to,
|
|
|
09d4f2 |
firstly, rebuild the path information for each parallel directory
|
|
|
09d4f2 |
inside the repository, using the current path of its parent directory
|
|
|
09d4f2 |
as reference, and later, use the new path information to move each old
|
|
|
09d4f2 |
parallel directory from its old location to its new location based on
|
|
|
09d4f2 |
an updated path information.
|
|
|
09d4f2 |
|
|
|
09d4f2 |
As CentOS Artwork Repository is built over a version control system,
|
|
|
09d4f2 |
file movements inside the repository are considered repository
|
|
|
09d4f2 |
changes. In order for these repository changes to be versioned, we
|
|
|
09d4f2 |
need to, firstly, add changes related files into version control
|
|
|
09d4f2 |
system, and later, use commands from the version control system to
|
|
|
09d4f2 |
move those files already versioned. This configuration makes possible
|
|
|
09d4f2 |
for everyone to know about changes details inside the repository; and
|
|
|
09d4f2 |
if needed, revert or update them back to a previous revision.
|
|
|
09d4f2 |
|
|
|
09d4f2 |
Finally, once all file corrections have been already made, the
|
|
|
09d4f2 |
syncronization action takes care of updating path references inside
|
|
|
09d4f2 |
related files. Updating path references inside related files is
|
|
|
09d4f2 |
specially important for documentation files where documentation nodes
|
|
|
09d4f2 |
are built using repository path information as reference.
|
|
|
09d4f2 |
|
|
|
09d4f2 |
@subsubsection What is the right location to store it?
|
|
|
09d4f2 |
|
|
|
09d4f2 |
Occasionly, you may find that new corporate visual identity components
|
|
|
09d4f2 |
need to be added to the repository. If that is your case, the first
|
|
|
09d4f2 |
question you need to ask yourself, before start to create directories
|
|
|
09d4f2 |
blindly all over, is: What is the right location to store it?
|
|
|
09d4f2 |
|
|
|
09d4f2 |
The CentOS Community (@url{http://wiki.centos.org/GettingHelp}) is the
|
|
|
09d4f2 |
best place to find answers to your question, but going there with
|
|
|
09d4f2 |
hands empty is not good idea. It may give the impression you don't
|
|
|
09d4f2 |
really care about. Instead, consider the following suggestions to find
|
|
|
09d4f2 |
your own comprehension and so, make your propositions based on it.
|
|
|
09d4f2 |
|
|
|
09d4f2 |
When looking the correct place to store new files, to bear in mind the
|
|
|
09d4f2 |
corporate visual identity structure used inside the CentOS Artwork
|
|
|
09d4f2 |
Repository (@pxref{trunk Identity}) would be probaly the best advice
|
|
|
af53cb |
we could offer to you, the rest is just matter of choosing appropriate
|
|
|
09d4f2 |
names. To illustrate this desition process let's consider the
|
|
|
09d4f2 |
@file{trunk/Identity/Themes/Motifs/TreeFlower/Distro/} directory as
|
|
|
09d4f2 |
example. It is the main development line of CentOS distribution visual
|
|
|
09d4f2 |
manifestation, using TreeFlower's artistic motif, inside themes of
|
|
|
af53cb |
CentOS corporate visual identity.
|
|
|
09d4f2 |
|
|
|
09d4f2 |
When building parent directory structures, you may find that reaching
|
|
|
09d4f2 |
an acceptable location may take some time, and as it happens most of
|
|
|
af53cb |
time, when you find it, that may be not a definite solution. There are
|
|
|
af53cb |
many concepts that you need to play with, in order to find a result
|
|
|
af53cb |
that match the conceptual idea you try to implement in the new
|
|
|
af53cb |
directory location. To know which these concepts are, split the
|
|
|
af53cb |
location in words and read its documentation entry from less specific
|
|
|
af53cb |
to more specific.
|
|
|
09d4f2 |
|
|
|
09d4f2 |
For example, the
|
|
|
09d4f2 |
@file{trunk/Identity/Themes/Motifs/TreeFlower/Distro/} location
|
|
|
09d4f2 |
evolved through several months of contant work and there is no certain
|
|
|
09d4f2 |
it won't change in the future, even it fixes quite well the concept we
|
|
|
09d4f2 |
are trying to implement. The concepts used in
|
|
|
09d4f2 |
@file{trunk/Identity/Themes/Distro/Motifs/TreeFlower/Distro/} location
|
|
|
09d4f2 |
are described in the following commands, respectively:
|
|
|
09d4f2 |
|
|
|
09d4f2 |
@verbatim
|
|
|
09d4f2 |
centos-art help --read=turnk/
|
|
|
09d4f2 |
centos-art help --read=turnk/Identity/
|
|
|
09d4f2 |
centos-art help --read=turnk/Identity/Themes/
|
|
|
09d4f2 |
centos-art help --read=turnk/Identity/Themes/Motifs/
|
|
|
09d4f2 |
centos-art help --read=turnk/Identity/Themes/Motifs/TreeFlower/
|
|
|
09d4f2 |
centos-art help --read=turnk/Identity/Themes/Motifs/TreeFlower/Distro/
|
|
|
09d4f2 |
@end verbatim
|
|
|
09d4f2 |
|
|
|
09d4f2 |
Other location concepts can be found similary as we did above, just
|
|
|
09d4f2 |
change the location we used above by the one you are trying to know
|
|
|
09d4f2 |
concepts for.
|
|
|
09d4f2 |
|
|
|
09d4f2 |
@subsection Usage
|
|
|
54264c |
|
|
|
09d4f2 |
@table @command
|
|
|
97552b |
@item centos-art path --copy=SRC --to=DST
|
|
|
af53cb |
Use this command to duplicate @file{SRC} in working copy,
|
|
|
af53cb |
remembering history. In this command, @file{SRC} and
|
|
|
af53cb |
@file{DST} can each be either a working copy (WC) path or
|
|
|
af53cb |
URL:
|
|
|
af53cb |
|
|
|
af53cb |
@table @samp
|
|
|
af53cb |
@item WC -> WC
|
|
|
af53cb |
Copy and schedule for addition (with history).
|
|
|
af53cb |
|
|
|
af53cb |
@item WC -> URL
|
|
|
af53cb |
Immediately commit a copy of WC to URL.
|
|
|
af53cb |
|
|
|
af53cb |
@item URL -> WC
|
|
|
af53cb |
Check out URL into WC, schedule for addition.
|
|
|
af53cb |
|
|
|
af53cb |
@item URL -> URL
|
|
|
af53cb |
Complete server-side copy; used to branch and tag.
|
|
|
af53cb |
@end table
|
|
|
af53cb |
|
|
|
af53cb |
This command is an interface for Subversion's @command{copy} command.
|
|
|
af53cb |
Options related to Subversion's @command{copy} command can be passed
|
|
|
af53cb |
from third argument on. For example to specify a log message use the
|
|
|
af53cb |
@option{--message} option as follow:
|
|
|
af53cb |
|
|
|
af53cb |
@verbatim
|
|
|
97552b |
centos-art path --copy=URL/SRC --to=URL/DST --message 'Copy url/src to url/dst'
|
|
|
af53cb |
@end verbatim
|
|
|
af53cb |
|
|
|
af53cb |
For more information on Subversion's @command{copy} functionality,
|
|
|
af53cb |
run the command: @command{svn help copy | less}.
|
|
|
af53cb |
|
|
|
97552b |
@item centos-art path --move=SRC --to=DST
|
|
|
af53cb |
Move and/or rename something in working copy or repository. In this
|
|
|
af53cb |
command, SRC and DST can both be working copy (WC) paths or URLs:
|
|
|
af53cb |
|
|
|
af53cb |
@table @samp
|
|
|
af53cb |
@item WC -> WC
|
|
|
af53cb |
Move and schedule for addition (with history).
|
|
|
af53cb |
@item URL -> URL
|
|
|
af53cb |
Complete server-side rename.
|
|
|
af53cb |
@end table
|
|
|
af53cb |
|
|
|
af53cb |
This command is an interface for Subversion's @command{move} command.
|
|
|
af53cb |
Options related to Subversion's @command{move} command can be passed
|
|
|
af53cb |
from third argument on. For example to specify a log message use the
|
|
|
af53cb |
@option{--message} option as follow:
|
|
|
af53cb |
|
|
|
af53cb |
@verbatim
|
|
|
97552b |
centos-art path --move=URL/SRC --to=URL/DST --message 'Move url/src to url/dst'
|
|
|
af53cb |
@end verbatim
|
|
|
af53cb |
|
|
|
af53cb |
For more information on Subversion's @command{move} functionality,
|
|
|
af53cb |
run the command: @command{svn help move | less}.
|
|
|
af53cb |
|
|
|
af53cb |
@item centos-art path --delete='SRC'
|
|
|
af53cb |
Use this command to remove files and directories from version control.
|
|
|
af53cb |
In this command, @file{SRC} can be a working copy (WC) path or URL.
|
|
|
af53cb |
|
|
|
af53cb |
@table @samp
|
|
|
af53cb |
@item WC
|
|
|
af53cb |
Each item specified by a PATH is scheduled for deletion upon the next
|
|
|
af53cb |
commit. Files, and directories that have not been committed, are
|
|
|
af53cb |
immediately removed from the working copy. PATHs that are, or
|
|
|
af53cb |
contain, unversioned or modified items will not be removed unless the
|
|
|
af53cb |
@option{--force} option is given.
|
|
|
af53cb |
|
|
|
af53cb |
@item URL
|
|
|
af53cb |
Each item specified by a URL is deleted from the repository via an
|
|
|
af53cb |
immediate commit.
|
|
|
af53cb |
@end table
|
|
|
af53cb |
|
|
|
af53cb |
This command is an interface for Subversion's @command{delete}
|
|
|
af53cb |
command. Options related to Subversion's @command{delete} can be
|
|
|
af53cb |
passed from third argument on. For example to specify a log message
|
|
|
af53cb |
use the @option{--message} as follow:
|
|
|
af53cb |
|
|
|
af53cb |
@verbatim
|
|
|
af53cb |
centos-art path --delete='URL' --message 'Delete url.'
|
|
|
af53cb |
@end verbatim
|
|
|
af53cb |
|
|
|
af53cb |
For more information on Subversion's @command{delete} functionality,
|
|
|
af53cb |
run the command: @command{svn help delete | less}.
|
|
|
af53cb |
|
|
|
af53cb |
@item centos-art path --sync='SRC'
|
|
|
af53cb |
Use this command to syncronize path information inside working copy.
|
|
|
af53cb |
This command is automatically used after moving or renaming parent
|
|
|
af53cb |
directories. In this command, @file{SRC} is a working copy path
|
|
|
af53cb |
inside @file{trunk/Identity/} location, considered the parent
|
|
|
af53cb |
directory you want to syncronize path information for.
|
|
|
54264c |
@end table
|
|
|
6ba043 |
|
|
|
6ba043 |
@subsection See also
|
|
|
6ba043 |
|
|
|
6ba043 |
@menu
|
|
|
af53cb |
* trunk Scripts Bash::
|
|
|
41f1ec |
* trunk Scripts Bash Functions::
|
|
|
6ba043 |
@end menu
|