Subject to the copyright assignment described below, your patches should be
sent in {\bf diff -u} format relative to the current contents of the Source
-Forge CVS, which is the easiest to understand and integrate.
+Forge SVN, which is the easiest to understand and integrate.
Please be sure to use the Bacula indenting standard (see below).
-If you have checked out the source with CVS, you can get a diff using:
+If you have checked out the source with SVN, you can get a diff using:
\begin{verbatim}
-cvs diff -u > change.patch
+svn diff > change.patch
\end{verbatim}
If you plan on doing significant development work over a period of time,
after having your first patch reviewed and approved, you will be eligible
-for having developer CVS access so that you can commit your changes
-directly to the CVS repository. To do so, you will need a userid on Source
+for having developer SVN access so that you can commit your changes
+directly to the SVN repository. To do so, you will need a userid on Source
Forge.
\subsubsection*{Copyrights}
\index{Copyrights}
\addcontentsline{toc}{subsubsection}{Copyrights}
-To avoid future problems concerning changing licensing or copyrights, all
-code contributions more than a hand full of lines must be in the Public
-Domain or have the copyright transferred to the Free Software Foundation
-Europe e.V. with a Fiduciary License Agreement (FLA).
-as in the current
-code. Note, prior to November 2004, the code was copyrighted by Kern
-Sibbald and John Walker. After November 2004, the code was copyrighted
-by Kern Sibbald, then on the 15th of November 2006, the copyright was
+To avoid future problems concerning changing licensing or
+copyrights, all code contributions more than a hand full of lines
+must be in the Public Domain or have the copyright transferred to
+the Free Software Foundation Europe e.V. with a Fiduciary License
+Agreement (FLA) as in the current code. Note, prior to
+November 2004, the code was copyrighted by Kern Sibbald and John
+Walker. After November 2004, the code was copyrighted by Kern
+Sibbald, then on the 15th of November 2006, the copyright was
transferred to the Free Software Foundation Europe e.V.
Your name should be clearly indicated as the author of the code, and you
must be extremely careful not to violate any copyrights or use other
people's code without acknowledging it. The purpose of this requirement is
-to avoid future copyright, patent, or intellectual property problems. To
-understand the possible source of future problems, please examine the
-difficulties Mozilla is (was?) having finding previous contributors at
-\elink{ http://www.mozilla.org/MPL/missing.html}
+to avoid future copyright, patent, or intellectual property problems.
+Please read the LICENSE agreement in the main source code
+directory. When you sign the Fiduciary License Agreement (FLA)
+and send it in, you are argeeing to the terms of that LICENSE
+file.
+
+To understand the possible source of future problems, please
+examine the difficulties Mozilla is (was?) having finding
+previous contributors at \elink{
+http://www.mozilla.org/MPL/missing.html}
{http://www.mozilla.org/MPL/missing.html}. The other important issue is to
avoid copyright, patent, or intellectual property violations as are currently
(May 2003) being claimed by SCO against IBM.
-Although the copyright will be held by the Free Software Foundation Europe
-e.V., each developer is expected to
-indicate that he wrote and/or modified a particular module (or file) and
-any other sources. The copyright assignment may seem a bit unusual, but in
-reality, it is not. Most large projects require this.
+Although the copyright will be held by the Free Software
+Foundation Europe e.V., each developer is expected to indicate
+that he wrote and/or modified a particular module (or file) and
+any other sources. The copyright assignment may seem a bit
+unusual, but in reality, it is not. Most large projects require
+this.
If you have any doubts about this, please don't hesitate to ask. The
objective is to assure the long term servival of the Bacula project.
was sufficient if the developer is independent, or an employee of a
not-for-profit organization or a university. However, in an effort to
ensure that the Bacula code is really clean, beginning in August 2006, all
-previous and future developers with CVS access will be asked to submit a
-copyright assignment (or Fiduciary License Agreement -- FLA).
+previous and future developers with SVN access will be asked to submit a
+copyright assignment (or Fiduciary License Agreement -- FLA),
+which means you agree to the LICENSE in the main source
+directory. It also means that you receive back the right to use
+the code that you have submitted.
Any developer who wants to contribute and is employed by a company should
-get a copyright assignment from his employer. This is because in many
-counties, all work that an employee does whether on company time or in the
+either list the employer as the owner of the code, or get
+explicit permission from him to sign the copyright assignment.
+This is because in many
+countries, all work that an employee does whether on company time or in the
employee's free time is considered to be Intellectual Property of the
-company. Obtaining a signed FLA from the company will avoid
+company. Obtaining official approval or an FLA from the company will avoid
misunderstandings between the employee, the company, and the Bacula
project. A good number of companies have already followed this procedure.
The Fiduciary License Agreement is posted on the Bacula web site at:
\elink{http://www.bacula.org/FLA-bacula.en.pdf}{http://www.bacula.org/FLA-bacula.en.pdf}
+The instructions for filling out this agreement are also at:
+\elink{http://www.bacula.org/?page=fsfe}{http://www.bacula.org/?page=fsfe}
+
It should be filled out, then sent to:
\begin{verbatim}
complete document, please notify me: kern at sibbald dot com.
-\subsection*{Basic CVS Usage}
-\index{Basic CVS Usage}
-\index{CVS}
-\addcontentsline{toc}{subsection}{Basic CVS Usage}
-The Bacula CVS is kept at Source Forge. If you are not a developer,
-you only be able to access the public CVS, which runs about 6 hours behind
-the developer's CVS. If you are a developer, then you will have immediate
-access to "the" CVS and any changes ("commit") that you make will be
-immediately seen by other developers.
+\subsection*{The Development Cycle}
+\index{Developement Cycle}
+\index{Cycle!Developement}
+\addcontentsline{toc}{subsubsection}{Development Cycle}
+
+As I noted in the 1.38 ReleaseNotes, version 1.38 was different from prior
+versions because it had a lot more contributions. I expect that this trend
+will continue. As a consequence, I am going to modify how I normally do
+development, and instead of making a list of all the features that I will
+implement in the next version, I will personally sign up for one (maybe
+two) projects at a time, and when they are complete, I will release a new
+version.
+
+The difference is that I will have more time to review the new code that is
+being contributed, and will be able to devote more time to a smaller number
+of projects (1.38 had too many new features for me to handle correctly).
+
+I expect that future release schedules will be much the same, and the
+number of new features will also be much the same providing that the
+contributions continue to come -- and they show no signs of let up :-)
+
+\index{Feature Requests}
+{\bf Feature Requests:} \\
+In addition, I would like to "formalize" the feature requests a bit.
-For developer access to the CVS, go to the Bacula page on Source Forge
-and click on the CVS menu item. Then follow the instructions for
-installing your SSH public key. It may take a few hours until the
-key is actually installed, and then you will have access to the CVS.
+Instead of me maintaining an informal list of everything I run into
+(kernstodo), I would like to maintain a "formal" list of projects. This
+means that all new feature requests, including those recently discussed on
+the email lists, must be formally submitted and approved.
-The Bacula CVS is divided into the following CVS "projects" or "modules".
+Formal submission of feature requests will take two forms: \\
+1. non-mandatory, but highly recommended is to discuss proposed new features
+on the mailing list.\\
+2. Formal submission of an Feature Request in a special format.
+I'll give an example of this below, but you can also find it on the web
+site under "Support -\gt{} Feature Requests". Since it takes a bit of time to
+properly fill out a Feature Request form, you probably should check on the email list
+first.
+Once I receive the Feature Request, I will either accept it, send it back
+asking for clarification, send it to the email list asking for opinions, or
+reject it.
+
+If it is accepted, it will go in the "projects" file (a simple ASCII file)
+maintained in the main Bacula source directory.
+
+{\bf Implementation of Feature Requests:}\\
+Any qualified developer can sign up for a project. The project must have
+an entry in the projects file, and the developer's name will appear in the
+Status field.
+
+{\bf How Feature Requests are accepted:}\\
+Acceptance of Feature Requests depends on several things: \\
+1. feedback from users. If it is negative, the Feature Request will probably not be
+accepted. \\
+2. the difficulty of the project. A project that is so
+difficult that I cannot imagine finding someone to implement probably won't
+be accepted. \\
+ 3. whether or not the Feature Request fits within the
+current stategy of Bacula (for example an Feature Request that requests changing the
+tape to tar format would not be accepted, ...)
+
+{\bf How Feature Requests are prioritized:}\\
+Once an Feature Request is accepted, it needs to be implemented. If you
+can find a developer for it, or one signs up for implementing it, then the
+Feature Request becomes top priority (at least for that developer).
+
+Between releases of Bacula, I will generally solicit Feature Request input
+for the next version, and by way of this email, I suggest that you send
+discuss and send in your Feature Requests for the next release. Please
+verify that the Feature Request is not in the current list (attached to this email).
+
+Once users have had several weeks to submit Feature Requests, I will
+organize them, and request users to vote on them. This will allow fixing
+prioritizing the Feature Requests. Having a priority is one thing, but
+getting it implement is another thing -- I am hoping that the Bacula
+community will take more responsibility for assuring the implementation of
+accepted Feature Requests.
+
+Feature Request format:
\begin{verbatim}
+============= Empty Feature Request form ===========
+Item n: One line summary ...
+ Date: Date submitted
+ Origin: Name and email of originator.
+ Status:
+
+ What: More detailed explanation ...
+
+ Why: Why it is important ...
+
+ Notes: Additional notes or features (omit if not used)
+============== End Feature Request form ==============
+\end{verbatim}
+
+\begin{verbatim}
+============= Example Completed Feature Request form ===========
+Item 1: Implement a Migration job type that will move the job
+ data from one device to another.
+ Origin: Sponsored by Riege Sofware International GmbH. Contact:
+ Daniel Holtkamp <holtkamp at riege dot com>
+ Date: 28 October 2005
+ Status: Partially coded in 1.37 -- much more to do. Assigned to
+ Kern.
+
+ What: The ability to copy, move, or archive data that is on a
+ device to another device is very important.
+
+ Why: An ISP might want to backup to disk, but after 30 days
+ migrate the data to tape backup and delete it from
+ disk. Bacula should be able to handle this
+ automatically. It needs to know what was put where,
+ and when, and what to migrate -- it is a bit like
+ retention periods. Doing so would allow space to be
+ freed up for current backups while maintaining older
+ data on tape drives.
+
+ Notes: Migration could be triggered by:
+ Number of Jobs
+ Number of Volumes
+ Age of Jobs
+ Highwater size (keep total size)
+ Lowwater mark
+=================================================
+\end{verbatim}
+
+
+\subsubsection*{SVN Usage}
+\index{SVN Usage}
+\addcontentsline{toc}{subsubsection}{SVN Usage}
+
+Please note that if you are familar with CVS, SVN is very
+similar (and better), but there can be a few surprising
+differences.
+
+The *entire* Bacula SourceForge.net Subversion repository can be
+checked out through SVN with the following command:
+
+\begin{verbatim}
+svn checkout https://bacula.svn.sourceforge.net/svnroot/bacula bacula
+\end{verbatim}
+
+With the above command, you will get everything, which is a very large
+amount of data:
+
+\begin{verbatim}
+branches/
+ Branch-1.32a/
+ ...
+ Branch-2.0/
+ import/
+ vendor/
+tags/
+ Release-1.1/
+ ...
+ Release-2.0.2/
+trunk/
+ bacula/
+ docs/
+ gui/
+ regress/
+ rescue/
+\end{verbatim}
- bacula (Bacula source code)
- docs (Bacula documentation)
- gui (Some of the GUI programs that do not use
- the Bacula core code)
- rescue (Bacula CDROM rescue code)
- regress (Bacula regression scripts)
- ryol (Roll your own Linux -- incomplete project)
+If you only want the current source code, you could use:
+\begin{verbatim}
+svn checkout https://bacula.svn.sourceforge.net/svnroot/bacula/trunk/bacula bacula
\end{verbatim}
-Most of you will want either the Bacula source (bacula) and/or the
-documents (docs).
-To get the source for a project, you must check it out ("checkout"), which
-you do usually once.
+To view what is in the svn, point your browser at the following URL:
+http://bacula.svn.sourceforge.net/viewvc/bacula/
-\subsubsection*{Public CVS Access}
-\index{Public CVS Access}
-\addcontentsline{toc}{subsubsection}{Public CVS Access}
+Many of the Subversion (svn) commands are almost identical to those that
+you have used for cvs, but some (such as a checkout) can have surprising
+results, so you should take a careful look at the documentation.
-The first time you checkout the code for each project, you will need to
-tell the cvs program where the CVS repository is. The procedure for
-checking out code from the public CVS is:
+Robert has kindly provided the following documentation on the new
+svn repository and how to use it:
+Here is the list of branches:
\begin{verbatim}
-cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/bacula login
+ Branch-1.32a
+ Branch-1.32e
+ Branch-1.34.2
+ Branch-1.34.5
+ Branch-1.36
+ Branch-1.36.1
+ Branch-1.36.2
+ Branch-1.38
+ Branch-2.0
+ import
+ vendor
\end{verbatim}
-Then when it prompts for the password for {\bf anonymous}, simply
-press the Enter key. The above command is necessary only once
-the very first time you login. Then enter the following command:
+The list of tags is:
\begin{verbatim}
-cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/bacula co -P bacula
+ Release-1.1 Release-1.19 Release-1.19a Release-1.19b
+ Release-1.20 Release-1.21 Release-1.22 Release-1.23
+ Release-1.23a Release-1.24 Release-1.25 Release-1.25a
+ Release-1.26 Release-1.27 Release-1.27a Release-1.27b
+ Release-1.27c Release-1.28 Release-1.29 Release-1.30
+ Release-1.31 Release-1.31a Release-1.32 Release-1.32a
+ Release-1.32b Release-1.32c Release-1.32d Release-1.32e
+ Release-1.32f Release-1.32f-2 Release-1.32f-3 Release-1.32f-4
+ Release-1.32f-5 Release-1.34.0 Release-1.34.1 Release-1.34.3
+ Release-1.34.4 Release-1.34.5 Release-1.34.6 Release-1.35.1
+ Release-1.35.2 Release-1.35.3 Release-1.35.6 Release-1.35.7
+ Release-1.35.8 Release-1.36.0 Release-1.36.1 Release-1.36.2
+ Release-1.36.3 Release-1.38.0 Release-1.38.1 Release-1.38.10
+ Release-1.38.11 Release-1.38.2 Release-1.38.3 Release-1.38.4
+ Release-1.38.5 Release-1.38.6 Release-1.38.7 Release-1.38.8
+ Release-1.38.9 Release-1.8.1 Release-1.8.2 Release-1.8.3
+ Release-1.8.4 Release-1.8.5 Release-1.8.6 Release-2.0.0
+ Release-2.0.1 Release-2.0.2
\end{verbatim}
-The above will place the contents of the bacula module in a directory
-named {\bf bacula} in the current directory. This data will come
-from the public CVS, which typically runs 6 hours to a day behind the
-developer's CVS. Once you have created a copy of the CVS, you can use
-the commands listed below under the title CVS Usage.
+Here is a list of commands to get you started. The recommended book is
+"Version Control with Subversion", by Ben Collins-Sussmann,
+Brian W. Fitzpatrick, and Michael Pilato, O'Reilly. The book is
+Open Source, so it is also available on line at:
-\subsubsection*{Developer CVS Access}
-\index{Developer CVS Access}
-\addcontentsline{toc}{subsubsection}{Developer CVS Access}
+\begin{verbatim}
+ http://svnbook.red-bean.com
+\end{verbatim}
-If you are registered as a Bacula developer (contact Kern about this),
-you may access the developer's CVS using:
+Get a list of commands
\begin{verbatim}
-export CVS_RSH=ssh
-export CVSROOT=:ext:<nnnn>@cvs.bacula.sourceforge.net:/cvsroot/bacula
+ svn help
\end{verbatim}
-where you replace \lt{}nnnn\gt{} by your Source Forge user name.
+Get a help with a command
-Then do:
+\begin{verbatim}
+ svn help command
+\end{verbatim}
+
+Checkout the HEAD revision of all modules from the project into the
+directory bacula-new
\begin{verbatim}
-cvs -z3 checkout -d <directory> bacula
+ svn co https://bacula.svn.sourceforge.net/svnroot/bacula/trunk bacula.new
\end{verbatim}
-where you replace \lt{}directory\gt{} by the name of the directory you want
-to contain the Bacula source code. If you want the docs, replace the
-word "bacula" on the above line by "docs" and be sure to put it in
-a different directory. The -z3 just tells CVS to use compression during
-the transmission, which makes things go faster. There is no need to
-do the anonymous login as is the case for non-developers.
+Checkout the HEAD revision of the bacula module into the bacula subdirectory
-The above command should generate output that looks a bit like the
-following:
+\begin{verbatim}
+ svn checkout https://bacula.svn.sourceforge.net/svnroot/bacula/trunk/bacula
+\end{verbatim}
+
+See which files have changed in the working copy
\begin{verbatim}
-cvs checkout: Updating bacula
-U bacula/Makefile
-U bacula/bar.c
-U bacula/foo.c
-U bacula/main.c
-...
+ svn status
\end{verbatim}
-\subsubsection*{CVS Usage}
-\index{CVS Usage}
-\addcontentsline{toc}{subsubsection}{CVS Usage}
+See which files are out of date
-The commands that follow with the exception of the {\bf commit}
-work the same whether you are accessing the public CVS or
-the developer's CVS.
+\begin{verbatim}
+ svn status -u
+\end{verbatim}
-Let's assume you used the name "bacula" for the directory, so your
-command was:
+Add a new file file.c
\begin{verbatim}
-cvs -z3 checkout -d bacula bacula
+ svn add file.c
\end{verbatim}
-When the command is done, simply do:
+Create a new directory
\begin{verbatim}
-cd bacula
+ svn mkdir newdir
+\end{verbatim}
+
+Delete an obsolete file
+
+\begin{verbatim}
+ svn delete file.c
+\end{verbatim}
+
+Rename a file
+
+\begin{verbatim}
+ svn move file.c newfile.c
+\end{verbatim}
+
+Move a file to a new location
+
+\begin{verbatim}
+ svn move file.c ../newdir/file.c
\end{verbatim}
+Copy a file retaining the original history in the new file
+
+\begin{verbatim}
+ svn copy file.c newfile.c
+\end{verbatim}
+
+Update the working copy with the outstanding changes
+
+\begin{verbatim}
+ svn update
+\end{verbatim}
+
+Compare working copy with the repository
+
+\begin{verbatim}
+ svn diff file.c
+\end{verbatim}
+
+Commit the changes in the local working copy
+
+\begin{verbatim}
+ svn commit
+\end{verbatim}
+
+Specify which files are ignored in the current directory
+
+\begin{verbatim}
+ svn propedit svn:ignore .
+\end{verbatim}
+
+Mark a file to be executable
+
+\begin{verbatim}
+ svn propset svn:executable '*' prog.sh
+\end{verbatim}
+
+Unmark a file as executable
+
+\begin{verbatim}
+ svn propdel svn:executable prog.sh
+\end{verbatim}
+
+List a file's properties
+
+\begin{verbatim}
+ svn proplist file.c
+\end{verbatim}
+
+Create a branch for a new version
+
+\begin{verbatim}
+ svn copy https://bacula.svn.sourceforge.net/svnroot/bacula/trunk \
+ https://bacula.svn.sourceforge.net/svnroot/bacula/branches/Branch-2.1
+\end{verbatim}
+
+Tag a version for a new release
+
+\begin{verbatim}
+ svn copy https://bacula.svn.sourceforge.net/svnroot/bacula/branches/Branch-2.1 \
+ https://bacula.svn.sourceforge.net/svnroot/bacula/branches/Release-2.1
+\end{verbatim}
-and then build Bacula. You will notice a lot of extra CVS directories
-in the source code. Don't ever change or delete them, or you will mess up
-your copy of the project. Also, do not rename or delete any of the files
-in your copy of the repository or you may have problems. Any files that
-you change will remain only on your system until you do a "commit", which
-is explained later.
Let's say you are working in the directory scripts. You would then do:
\begin{verbatim}
cd bacula (to your top level directory)
-cvs diff -u >my-changes.patch
+svn diff my-changes.patch
\end{verbatim}
When the command is done, you can look in the file my-changes.patch
it reports before proceeding. If you modified files that you do
do not want to commit to the main repository, you can simply delete
them from your local directory, and they will be restored from the
-repository with the "cvs update" that is shown below. Normally, you
+repository with the "svn update" that is shown below. Normally, you
should not find changes to files that you do not want to commit, and
if you find yourself in that position a lot, you are probably doing
something wrong.
-Let's assume that now you want to commit your changes to the main CVS
-repository.
+Let's assume that now you want to commit your changes to the main
+SVN repository.
First do:
\begin{verbatim}
-cvs bacula
-cvs update
+cd bacula
+svn update
\end{verbatim}
When you do this, it will pull any changes made by other developers into
or look in the .rej files that it creates. If you have problems, just ask
on the developer's list.
-Note, doing the above "cvs update" is not absolutely necessary. There are
+Note, doing the above "svn update" is not absolutely necessary. There are
times when you may be working on code and you want to commit it, but you
explicitly do not want to move up to the latest version of the code in
-the CVS. If that is the case, you can simply skip the "cvs update" and
+the SVN. If that is the case, you can simply skip the "svn update" and
do the commit shown below. If the commit fails because of a conflict, it
will tell you, and you must resolve the conflict before it will permit
you to do the commit.
commit your changes:
\begin{verbatim}
-cvs commit -m "Some comment about what you changed"
+svn commit -m "Some comment about what you changed"
\end{verbatim}
or if you really only want to commit a single file, you can
do:
\begin{verbatim}
-cvs commit -m "comment" scripts/file-I-edited
+svn commit -m "comment" scripts/file-I-edited
\end{verbatim}
Note, if you have done a build in your directory, or you have added
are stored in the repository, so when you do a commit, those object
files will simply be ignored.
-If you want to add new files or remove files from the main CVS
-repository, and you are not experienced with CVS, please ask Kern
+If you want to add new files or remove files from the main SVN
+repository, and you are not experienced with SVN, please ask Kern
to do it. If you follow the simple steps above, it is unlikely that
you will do any damage to the repository, and if you do, it is always
possible for us to recover, but it can be painful.
long as you are careful only to change files that you want changed,
you have little to worry about.
-\subsection*{The Development Cycle}
-\index{Developement Cycle}
-\index{Cycle!Developement}
-\addcontentsline{toc}{subsubsection}{Development Cycle}
-
-As I noted in the 1.38 ReleaseNotes, version 1.38 was different from prior
-versions because it had a lot more contributions. I expect that this trend
-will continue. As a consequence, I am going to modify how I normally do
-development, and instead of making a list of all the features that I will
-implement in the next version, I will personally sign up for one (maybe
-two) projects at a time, and when they are complete, I will release a new
-version.
-
-The difference is that I will have more time to review the new code that is
-being contributed, and will be able to devote more time to a smaller number
-of projects (1.38 had too many new features for me to handle correctly).
-
-I expect that future release schedules will be much the same, and the
-number of new features will also be much the same providing that the
-contributions continue to come -- and they show no signs of let up :-)
+\subsection*{Subversion Resources}
+\link{Subversion (svn) Resources}
+\addcontentsline{toc}{subsection}{Subversion Resources}
-\index{Feature Requests}
-{\bf Feature Requests:} \\
-In addition, I would like to "formalize" the feature requests a bit.
-
-Instead of me maintaining an informal list of everything I run into
-(kernstodo), I would like to maintain a "formal" list of projects. This
-means that all new feature requests, including those recently discussed on
-the email lists, must be formally submitted and approved.
-
-Formal submission of feature requests will take two forms: \\
-1. non-mandatory, but highly recommended is to discuss proposed new features
-on the mailing list.\\
-2. Formal submission of an Feature Request in a special format.
-I'll give an example of this below, but you can also find it on the web
-site under "Support -\gt{} Feature Requests". Since it takes a bit of time to
-properly fill out a Feature Request form, you probably should check on the email list
-first.
-
-Once I receive the Feature Request, I will either accept it, send it back
-asking for clarification, send it to the email list asking for opinions, or
-reject it.
-
-If it is accepted, it will go in the "projects" file (a simple ASCII file)
-maintained in the main Bacula source directory.
-
-{\bf Implementation of Feature Requests:}\\
-Any qualified developer can sign up for a project. The project must have
-an entry in the projects file, and the developer's name will appear in the
-Status field.
-
-{\bf How Feature Requests are accepted:}\\
-Acceptance of Feature Requests depends on several things: \\
-1. feedback from users. If it is negative, the Feature Request will probably not be
-accepted. \\
-2. the difficulty of the project. A project that is so
-difficult that I cannot imagine finding someone to implement probably won't
-be accepted. \\
- 3. whether or not the Feature Request fits within the
-current stategy of Bacula (for example an Feature Request that requests changing the
-tape to tar format would not be accepted, ...)
-
-{\bf How Feature Requests are prioritized:}\\
-Once an Feature Request is accepted, it needs to be implemented. If you
-can find a developer for it, or one signs up for implementing it, then the
-Feature Request becomes top priority (at least for that developer).
-
-Between releases of Bacula, I will generally solicit Feature Request input
-for the next version, and by way of this email, I suggest that you send
-discuss and send in your Feature Requests for the next release. Please
-verify that the Feature Request is not in the current list (attached to this email).
+\begin{verbatim}
+cvs2svn Statistics:
+------------------
+Total CVS Files: 3286
+Total CVS Revisions: 28924
+Total Unique Tags: 63
+Total Unique Branches: 11
+CVS Repos Size in KB: 232421
+Total SVN Commits: 4116
+First Revision Date: Tue Apr 23 12:42:57 2002
+Last Revision Date: Tue Feb 6 06:37:57 2007
+\end{verbatim}
-Once users have had several weeks to submit Feature Requests, I will
-organize them, and request users to vote on them. This will allow fixing
-prioritizing the Feature Requests. Having a priority is one thing, but
-getting it implement is another thing -- I am hoping that the Bacula
-community will take more responsibility for assuring the implementation of
-accepted Feature Requests.
+The new Subversion repository size on Robert's machine:
-Feature Request format:
\begin{verbatim}
-============= Empty Feature Request form ===========
-Item n: One line summary ...
- Date: Date submitted
- Origin: Name and email of originator.
- Status:
+4.0K bacula-tst/dav
+12K bacula-tst/locks
+40K bacula-tst/hooks
+16K bacula-tst/conf
+190M bacula-tst/db/revs
+17M bacula-tst/db/revprops
+4.0K bacula-tst/db/transactions
+206M bacula-tst/db
+206M bacula-tst
+\end{verbatim}
- What: More detailed explanation ...
- Why: Why it is important ...
+Main Subversion Page
+\elink{http://subversion.tigris.org}{http://subversion.tigris.org}
- Notes: Additional notes or features (omit if not used)
-============== End Feature Request form ==============
-\end{verbatim}
+Subversion Book
+\elink{http://svnbook.red-bean.com}{http://svnbook.red-bean.com}
-\begin{verbatim}
-============= Example Completed Feature Request form ===========
-Item 1: Implement a Migration job type that will move the job
- data from one device to another.
- Origin: Sponsored by Riege Sofware International GmbH. Contact:
- Daniel Holtkamp <holtkamp at riege dot com>
- Date: 28 October 2005
- Status: Partially coded in 1.37 -- much more to do. Assigned to
- Kern.
+Subversion Clients
+\elink{http://subversion.tigris.org/project_packages.html}{http://subversion.tigris.org/project_packages.html}
- What: The ability to copy, move, or archive data that is on a
- device to another device is very important.
+ (For Windows users the TortoiseSVN package is awesome)
- Why: An ISP might want to backup to disk, but after 30 days
- migrate the data to tape backup and delete it from
- disk. Bacula should be able to handle this
- automatically. It needs to know what was put where,
- and when, and what to migrate -- it is a bit like
- retention periods. Doing so would allow space to be
- freed up for current backups while maintaining older
- data on tape drives.
+GUI UNIX client link
+\elink{http://rapidsvn.tigris.org/}{http://rapidsvn.tigris.org/}
- Notes: Migration could be triggered by:
- Number of Jobs
- Number of Volumes
- Age of Jobs
- Highwater size (keep total size)
- Lowwater mark
-=================================================
-\end{verbatim}
\subsection*{Developing Bacula}
<? require_once("inc/header.php"); ?>
<table>
<tr>
- <td class="contentTopic">
- What is Bacula?
- </td>
+ <td class="contentTopic">
+ What is Bacula?
+ </td>
</tr>
<tr>
- <td class="content">
+ <td class="content">
<b>Bacula</b> is a set of computer programs that permit you (or the
system administrator) to manage backup, recovery, and verification of
<h3>Bacula Components or Services</h3>
Bacula is made up of the following five major components or services:
<p style="text-align: center; font-size: small">
- <img src="images/manual/bacula-applications.png" alt="" width="576" height="734"><br>
- thanks to Aristedes Maniatis for this graphic and the one below
+
<img src="images/manual/bacula-applications.png" alt="" width="576" height="734"><br>
+ thanks to Aristedes Maniatis for this graphic and the one below
</p>
<p>
<ul>
files containing resources (or objects). The following presents an
overall picture of this:
<p style="text-align: center">
- <img src="images/manual/bacula-objects.png" alt="" width="576" height="734">
+
<img src="images/manual/bacula-objects.png" alt="" width="576" height="734">
</p>
<h3>Conventions Used in this Document</h3>
of the software, the above paragraph holds true. If you are reading
the online version of the manual, <a href="/dev-manual">
http://www.bacula.org/rel-manual</a>, please bear in mind that this version
-describes the current version in development (in the CVS) that may
+describes the current version in development (in the SVN) that may
contain features not in the released version. Just the same,
it generally lags behind the code a bit.
<h3>Quick Start</h3>
To facilitate communication about this project, we provide here
the definitions of the terminology that we use.
<dl>
- <dt>Administrator</dt>
- <dd>The person or persons responsible for administrating the Bacula system.</dd>
+ <dt>Administrator</dt>
+ <dd>The person or persons responsible for administrating the Bacula system.</dd>
- <dt>Backup</dt>
- <dd>We use the term <b>Backup</b> to refer to a Bacula Job that saves files. </dd>
+ <dt>Backup</dt>
+ <dd>We use the term <b>Backup</b> to refer to a Bacula Job that saves files. </dd>
- <dt>Bootstrap File</dt>
- <dd>The bootstrap file is an ASCII file
+ <dt>Bootstrap File</dt>
+ <dd>The bootstrap file is an ASCII file
containing a compact form of commands that allow Bacula or
the stand-alone file extraction utility (<b>bextract</b>) to
restore the contents of one or more Volumes, for example, the
create a bootstrap file from a Catalog to extract any file or
files you wish.</dd>
- <dt>Catalog</dt>
- <dd>The Catalog is used to store summary information
+ <dt>Catalog</dt>
+ <dd>The Catalog is used to store summary information
about the Jobs, Clients, and Files that were backed up and on
what Volume or Volumes. The information saved in the Catalog
permits the administrator or user to determine what jobs were
it from simple backup and archive programs such as <b>dump</b>
and <b>tar</b>.
</dd>
-
- <dt>Client</dt>
- <dd>In Bacula's terminology, the word Client
+
+ <dt>Client</dt>
+ <dd>In Bacula's terminology, the word Client
refers to the machine being backed up, and it is synonymous
with the File services or File daemon, and quite often, we
refer to it as the FD. A Client is defined in a configuration
file resource. </dd>
-
- <dt>Console</dt>
- <dd>The program that interfaces to the Director allowing
+
+ <dt>Console</dt>
+ <dd>The program that interfaces to the Director allowing
the user or system administrator to control Bacula.</dd>
-
- <dt>Daemon</dt>
- <dd>Unix terminology for a program that is always present in
+
+ <dt>Daemon</dt>
+ <dd>Unix terminology for a program that is always present in
the background to carry out a designated task. On Windows systems, as
well as some Linux systems, daemons are called <b>Services</b>.</dd>
-
- <dt>Directive</dt>
- <dd>The term directive is used to refer to a statement
+
+ <dt>Directive</dt>
+ <dd>The term directive is used to refer to a statement
or a record within a Resource in a configuration file that
defines one specific thing. For example, the <b>Name</b> directive
defines the name of the Resource.</dd>
-
- <dt>Director</dt>
- <dd>The main Bacula server daemon that schedules and directs all
+
+ <dt>Director</dt>
+ <dd>The main Bacula server daemon that schedules and directs all
Bacula operations. Occassionally, we refer to the Director as DIR.</dd>
-
- <dt>Differential</dt>
- <dd>A backup that includes all files changed since the last
+
+ <dt>Differential</dt>
+ <dd>A backup that includes all files changed since the last
Full save started. Note, other backup programs may define this differently.</dd>
- <dt>File Attributes</dt>
- <dd>The File Attributes are all the information
+ <dt>File Attributes</dt>
+ <dd>The File Attributes are all the information
necessary about a file to identify it and all its properties such as
size, creation date, modification date, permissions, etc. Normally, the
attributes are handled entirely by Bacula so that the user never
needs to be concerned about them. The attributes do not include the
file's data.
- <dt>File Daemon</dt>
- <dd>The daemon running on the client
+ <dt>File Daemon</dt>
+ <dd>The daemon running on the client
computer to be backed up. This is also referred to as the File
services, and sometimes as the Client services or the FD.
-
- <dt><a name="FileSetDef"></a> FileSet</dt>
- <dd>A FileSet is a Resource contained in a configuration
+
+
<dt><a name="FileSetDef"></a> FileSet</dt>
+ <dd>A FileSet is a Resource contained in a configuration
file that defines the files to be backed up. It consists
of a list of included files or directories, a list of excluded files, and
how the file is to be stored (compression, encryption, signatures).
For more details, see the
- <a href="rel-manual/director.html#FileSetResource">FileSet Resource definition</a>
+
<a href="rel-manual/director.html#FileSetResource">FileSet Resource definition</a>
in the Director chapter of this document.</dd>
- <dt>Incremental</dt>
- <dd>A backup that includes all files changed since the
+ <dt>Incremental</dt>
+ <dd>A backup that includes all files changed since the
last Full, Differential, or Incremental backup started. It is normally
specified on the <b>Level</b> directive within the Job resource
definition, or in a Schedule resourc. </dd>
-
- <dt><a name="JobDef"></a>Job</dt>
- <dd>A Bacula Job is a configuration resource that defines
+
+
<dt><a name="JobDef"></a>Job</dt>
+ <dd>A Bacula Job is a configuration resource that defines
the work that Bacula must perform to backup or restore a particular
Client. It consists of the <b>Type</b> (backup, restore, verify,
etc), the <b>Level</b> (full, incremental,...), the <b>FileSet</b>,
and <b>Storage</b> the files are to be backed up (Storage device,
Media Pool). For more details, see the
- <a href="rel-manual/director.html#JobResource">Job Resource definition</a>
- in the Director chapter of this document. </dd>
+
<a href="rel-manual/director.html#JobResource">Job Resource definition</a>
+ in the Director chapter of this document. </dd>
- <dt>Monitor</dt>
- <dd>The program that interfaces to the all the daemons
+ <dt>Monitor</dt>
+ <dd>The program that interfaces to the all the daemons
allowing the user or system administrator to monitor Bacula status.</dd>
-
- <dt>Resource</dt>
- <dd>A resource is a part of a configuration file that
+
+ <dt>Resource</dt>
+ <dd>A resource is a part of a configuration file that
defines a specific unit of information that is available to Bacula.
For example, the <b>Job</b> resource defines all the properties of
a specific Job: name, schedule, Volume pool, backup type, backup
level, ...</dd>
-
- <dt>Restore</dt>
- <dd>A restore is a configuration resource that
+
+ <dt>Restore</dt>
+ <dd>A restore is a configuration resource that
describes the operation of recovering a file (lost or damaged) from
backup media. It is the inverse of a save, except that in most
cases, a restore will normally have a small set of files to restore,
while normally a Save backs up all the files on the system. Of
course, after a disk crash, Bacula can be called upon to do
a full Restore of all files that were on the system. </dd>
-
- <dt>Schedule</dt>
- <dd>A Schedule is a configuration resource that
+
+ <dt>Schedule</dt>
+ <dd>A Schedule is a configuration resource that
defines when the Bacula Job will be scheduled for
execution. To use the Schedule, the Job resource will refer to
the name of the Schedule. For more details, see the <a
href="rel-manual/director.html#ScheduleResource">Schedule Resource
definition</a> in the Director chapter of this document. </dd>
-
- <dt>Service</dt>
- <dd>This is Windows terminology for a <b>daemon</b> -- see
+
+ <dt>Service</dt>
+ <dd>This is Windows terminology for a <b>daemon</b> -- see
above. It is now frequently used in Unix environments as well.</dd>
-
- <dt>Storage Coordinates</dt>
- <dd>The information returned from the
+
+ <dt>Storage Coordinates</dt>
+ <dd>The information returned from the
Storage Services that uniquely locates a file on a backup medium. It
consists of two parts: one part pertains to each file saved, and the
other part pertains to the whole Job. Normally, this information is
of the Storage Coordinates. The Storage Coordinates include the
File Attributes (see above) plus the unique location of the information on
the backup Volume. </dd>
-
- <dt>Storage Daemon</dt>
- <dd>The Storage daemon, sometimes referred to as
+
+ <dt>Storage Daemon</dt>
+ <dd>The Storage daemon, sometimes referred to as
the SD, is the code that writes the attributes and data to a storage
Volume (usually a tape or disk).</dd>
-
- <dt>Session</dt>
- <dd>Normally refers to the internal conversation between
+
+ <dt>Session</dt>
+ <dd>Normally refers to the internal conversation between
the File daemon and the Storage daemon. The File daemon opens a
<b>session</b> with the Storage daemon to save a FileSet, or to restore
it. A session has a one to one correspondence to a Bacula Job (see
above). </dd>
-
- <dt>Verify</dt>
- <dd>A verify is a job that compares the current file
+
+ <dt>Verify</dt>
+ <dd>A verify is a job that compares the current file
attributes to the attributes that have previously been stored in the
Bacula Catalog. This feature can be used for detecting changes to
critical system files similar to what <b>Tripwire</b> does. One
data written to a Volume agrees with what is stored in the Catalog
(i.e. it compares the file attributes), *or it can check the
Volume contents against the original files on disk. </dd>
-
- <dt>*Archive</dt>
- <dd>An Archive operation is done after a Save, and it
+
+ <dt>*Archive</dt>
+ <dd>An Archive operation is done after a Save, and it
consists of removing the Volumes on which data is saved from active
use. These Volumes are marked as Archived, and many no longer be
used to save files. All the files contained on an Archived Volume
are removed from the Catalog. NOT YET IMPLEMENTED. </dd>
-
- <dt>*Update</dt>
- <dd>An Update operation causes the files on the remote
+
+ <dt>*Update</dt>
+ <dd>An Update operation causes the files on the remote
system to be updated to be the same as the host system. This is
equivalent to an <b>rdist</b> capability. NOT YET IMPLEMENTED.
</dd>
- <dt>Retention Period</dt>
- <dd>There are various kinds of retention
+ <dt>Retention Period</dt>
+ <dd>There are various kinds of retention
periods that Bacula recognizes. The most important are the
<b>File</b> Retention Period, <b>Job</b> Retention Period, and the
<b>Volume</b> Retention Period. Each of these retention periods
mechanisms for the catalog to be automatically pruned according to
the retention periods defined. </dd>
- <dt>Scan</dt>
- <dd>A Scan operation causes the contents of a Volume or a
+ <dt>Scan</dt>
+ <dd>A Scan operation causes the contents of a Volume or a
series of Volumes to be scanned. These Volumes with the information
on which files they contain are restored to the Bacula Catalog.
Once the information is restored to the Catalog, the files contained
bscan section</a> of the Bacula Utilities Chapter of this manual
for more details.</dd>
- <dt>Volume</dt>
- <dd>A Volume is an archive unit, normally a tape or
+ <dt>Volume</dt>
+ <dd>A Volume is an archive unit, normally a tape or
a named disk file where Bacula stores the data from one or more
backup jobs. All Bacula Volumes have a software label written to
the Volume by Bacula so that it identify what Volume it is really
In general, the Director oversees the flow of information. It also
maintains the Catalog.
<p style="text-align: center">
- <img src="images/manual/flow.jpeg" border="0" alt="Interactions between Bacula Services" width="480" height="370">
+
<img src="images/manual/flow.jpeg" border="0" alt="Interactions between Bacula Services" width="480" height="370">
</p>
- </td>
+ </td>
</tr>
</table>
projects / bacula / docs / commitdiff