must take all or nothing.
For developers, the most important thing to remember about Git and
-the Source Forge repository is not to "force" a {\bf push} to the
+the bacula.org repository is not to "force" a {\bf push} to the
repository. Doing so, can possibly rewrite
the Git repository history and cause a lot of problems for the
project.
-You can get a full copy of the Source Forge Bacula Git repository with the
+You can get a full copy of the Bacula Git repository with the
following command:
\begin{verbatim}
-git clone http://git.bacula.org/bacula trunk
+git clone http://git.bacula.org/bacula.git bacula
\end{verbatim}
-This will put a read-only copy into the directory {\bf trunk}
-in your current directory, and {\bf trunk} will contain
+This will put a read-only copy into the directory {\bf bacula}
+in your current directory, and {\bf bacula} will contain
the subdirectories: {\bf bacula}, {\bf gui}, and {\bf regress}.
-Obviously you can use any name an not just {\bf trunk}. In fact,
-once you have the repository in say {\bf trunk}, you can copy the
+Obviously you can use any name an not just {\bf bacula}. In fact,
+once you have the repository in say {\bf bacula}, you can copy the
whole directory to another place and have a fully functional
git repository.
The above command needs to be done only once. Thereafter, you can:
\begin{verbatim}
-cd trunk
+cd bacula
git pull # refresh my repo with the latest code
\end{verbatim}
-As of August 2009, the size of the repository ({\bf trunk} in the above
+As of August 2009, the size of the repository ({\bf bacula} in the above
example) will be approximately 55 Megabytes. However, if you build
from source in this directory and do a lot of updates and regression
testing, the directory could become several hundred megabytes.
and must commit. In fact, we suggest you commit frequently.
\item When you commit, the commit goes into your local Git
database. You must use another command to write it to the
- master Source Forge repository (see below).
+ master bacula.org repository (see below).
\item The local Git database is kept in the directory {\bf .git} at the
top level of the directory.
\item All the important Git configuration information is kept in the
file {\bf .git/config} in ASCII format that is easy to manually edit.
\item When you do a {\bf commit} the changes are put in {\bf .git}
- rather but not in the main Source Forge repository.
+ rather but not in the main bacula.org repository.
\item You can push your changes to the external repository using
the command {\bf git push} providing you have write permission
on the repository.
\item Download the Source code:\\
\begin{verbatim}
-git clone http://git.bacula.org/bacula trunk
+git clone http://git.bacula.org/bacula.git bacula
\end{verbatim}
\item Configure and Build Bacula:\\
\item Create a branch to work on:
\begin{verbatim}
-cd trunk/bacula
+cd bacula/bacula
git checkout -b bugfix master
\end{verbatim}
Normally, you will work by creating a branch of the master branch of your
repository, make your modifications, then make sure it is up to date, and finally
-create format-patch patches or push it to the Source Forge repo. Assuming
-you call the Bacula repository {\bf trunk}, you might use the following
+create format-patch patches or push it to the bacula.org. Assuming
+you call the Bacula repository {\bf bacula}, you might use the following
commands:
\begin{verbatim}
-cd trunk
-git checkout master
+cd bacula
+git checkout bacula
git pull
-git checkout -b newbranch master
+git checkout -b newbranch bacula
(edit, ...)
git add <file-edited>
git commit -m "<comment about commit>"
When you have completed working on your branch, you will do:
\begin{verbatim}
-cd trunk
+cd bacula
git checkout newbranch # ensure I am on my branch
git pull # get latest source code
git rebase master # merge my code
\section{Specifying the Configuration File}
\index[general]{Specifying the Configuration File}
-Starting with version 1.27, each of the following programs requires a valid
+Each of the following programs requires a valid
Storage daemon configuration file (actually, the only part of the
configuration file that these programs need is the {\bf Device} resource
definitions). This permits the programs to find the configuration parameters
\index[general]{Catalog!Using bscan to Compare a Volume to an existing}
\index[general]{Using bscan to Compare a Volume to an existing Catalog}
-If you wish to compare the contents of a Volume to an existing catalog without
-changing the catalog, you can safely do so if and only if you do {\bf not}
-specify either the {\bf -m} or the {\bf -s} options. However, at this time
-(Bacula version 1.26), the comparison routines are not as good or as thorough
-as they should be, so we don't particularly recommend this mode other than for
-testing.
+If you wish to compare the contents of a Volume to an existing catalog
+without changing the catalog, you can safely do so if and only if you do
+{\bf not} specify either the {\bf -m} or the {\bf -s} options in order to
+avoid modifying the catalog. However, not every record that is stored in
+the catalog is stored on the volumes, so we don't particularly
+recommend using {\bf bscan} other than for testing. Probably the best
+way to compare what is on a Volume to what is in the Catalog is to use
+one of the Verify Job options.
\subsection{Using bscan to Recreate a Catalog from a Volume}
\index[general]{Volume!Using bscan to Recreate a Catalog from a Volume}
projects / bacula / docs / commitdiff