From a0d91de48419329bf6d7a1a80782920ade123062 Mon Sep 17 00:00:00 2001 From: Kern Sibbald Date: Wed, 7 Feb 2007 16:07:49 +0000 Subject: [PATCH] Update web to refer to SVN --- docs/developers/generaldevel.tex | 635 ++++++++++++++++++----------- docs/home-page/inc/header.php | 2 +- docs/home-page/pages/home.php | 2 +- docs/home-page/pages/maillists.php | 2 +- docs/home-page/pages/what.php | 178 ++++---- 5 files changed, 492 insertions(+), 327 deletions(-) diff --git a/docs/developers/generaldevel.tex b/docs/developers/generaldevel.tex index d63c496e..824dde78 100644 --- a/docs/developers/generaldevel.tex +++ b/docs/developers/generaldevel.tex @@ -37,50 +37,57 @@ requirements for such code. 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. @@ -100,20 +107,28 @@ explicitly acknowledging that they do so in their first submission. This 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} @@ -129,134 +144,363 @@ registered office mentioned in the document. When you send in such a 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 + 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:@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 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: @@ -269,7 +513,7 @@ when you are happy with your changes, you can do the following: \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 @@ -278,19 +522,19 @@ repository. Make sure that you understand all the changes that 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 @@ -301,10 +545,10 @@ you can examine the files it claims have conflicts and look for \lt{}\lt{}\lt{}\ 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. @@ -313,14 +557,14 @@ Once your local copy of the repository has been updated, you can now 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 @@ -329,8 +573,8 @@ actually in the repository. For example, none of the object files 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. @@ -345,131 +589,52 @@ doing your commits, your commit will effect only that directory. As 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 - 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} diff --git a/docs/home-page/inc/header.php b/docs/home-page/inc/header.php index 8e690395..a4934ef5 100644 --- a/docs/home-page/inc/header.php +++ b/docs/home-page/inc/header.php @@ -138,7 +138,7 @@ diff --git a/docs/home-page/pages/home.php b/docs/home-page/pages/home.php index 4b9e40c4..0bbb7ed0 100644 --- a/docs/home-page/pages/home.php +++ b/docs/home-page/pages/home.php @@ -30,7 +30,7 @@ can access all the available Bacula documentation (HTML, PDF, and TGZ) both for the officially released version and for the current code under development in the Source - Forge CVS. The development version of the manual typically has + Forge SVN. The development version of the manual typically has more documentation, but may also document new features that are not in the released version. The Developer's Guide presents important information for users who want to diff --git a/docs/home-page/pages/maillists.php b/docs/home-page/pages/maillists.php index 719c2378..129b9811 100644 --- a/docs/home-page/pages/maillists.php +++ b/docs/home-page/pages/maillists.php @@ -89,7 +89,7 @@ http://lists.sourceforge.net/lists/listinfo/bacula-beta.

bacula-commits

The bacula-commits list is a read only list for those users who wish to be receive a diff of each -commit to the CVS. Please do not email directly to this list. +commit to the SVN. Please do not email directly to this list. You may subscribe by following the instructions at: diff --git a/docs/home-page/pages/what.php b/docs/home-page/pages/what.php index 24e10f3f..2924cab8 100644 --- a/docs/home-page/pages/what.php +++ b/docs/home-page/pages/what.php @@ -1,12 +1,12 @@ - + - +
- What is Bacula? - + What is Bacula? +
+ Bacula is a set of computer programs that permit you (or the system administrator) to manage backup, recovery, and verification of @@ -39,8 +39,8 @@ software available under the GNU Version 2 software license.

Bacula Components or Services

Bacula is made up of the following five major components or services:

-
- thanks to Aristedes Maniatis for this graphic and the one below +
+ thanks to Aristedes Maniatis for this graphic and the one below

    @@ -146,7 +146,7 @@ want backed up, and how, you must create a number of configuration files containing resources (or objects). The following presents an overall picture of this:

    - +

    Conventions Used in this Document

    @@ -160,7 +160,7 @@ implemented. of the software, the above paragraph holds true. If you are reading the online version of the manual, http://www.bacula.org/rel-manual, 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.

    Quick Start

    @@ -179,14 +179,14 @@ Running Bacula. To facilitate communication about this project, we provide here the definitions of the terminology that we use.
    -
    Administrator
    -
    The person or persons responsible for administrating the Bacula system.
    +
    Administrator
    +
    The person or persons responsible for administrating the Bacula system.
    -
    Backup
    -
    We use the term Backup to refer to a Bacula Job that saves files.
    +
    Backup
    +
    We use the term Backup to refer to a Bacula Job that saves files.
    -
    Bootstrap File
    -
    The bootstrap file is an ASCII file +
    Bootstrap File
    +
    The bootstrap file is an ASCII file containing a compact form of commands that allow Bacula or the stand-alone file extraction utility (bextract) to restore the contents of one or more Volumes, for example, the @@ -195,8 +195,8 @@ the definitions of the terminology that we use. create a bootstrap file from a Catalog to extract any file or files you wish.
    -
    Catalog
    -
    The Catalog is used to store summary information +
    Catalog
    +
    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 @@ -210,109 +210,109 @@ the definitions of the terminology that we use. it from simple backup and archive programs such as dump and tar.
    - -
    Client
    -
    In Bacula's terminology, the word Client + +
    Client
    +
    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.
    - -
    Console
    -
    The program that interfaces to the Director allowing + +
    Console
    +
    The program that interfaces to the Director allowing the user or system administrator to control Bacula.
    - -
    Daemon
    -
    Unix terminology for a program that is always present in + +
    Daemon
    +
    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 Services.
    - -
    Directive
    -
    The term directive is used to refer to a statement + +
    Directive
    +
    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 Name directive defines the name of the Resource.
    - -
    Director
    -
    The main Bacula server daemon that schedules and directs all + +
    Director
    +
    The main Bacula server daemon that schedules and directs all Bacula operations. Occassionally, we refer to the Director as DIR.
    - -
    Differential
    -
    A backup that includes all files changed since the last + +
    Differential
    +
    A backup that includes all files changed since the last Full save started. Note, other backup programs may define this differently.
    -
    File Attributes
    -
    The File Attributes are all the information +
    File Attributes
    +
    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. -
    File Daemon
    -
    The daemon running on the client +
    File Daemon
    +
    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. - -
    FileSet
    -
    A FileSet is a Resource contained in a configuration + +
    FileSet
    +
    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 - FileSet Resource definition + FileSet Resource definition in the Director chapter of this document.
    -
    Incremental
    -
    A backup that includes all files changed since the +
    Incremental
    +
    A backup that includes all files changed since the last Full, Differential, or Incremental backup started. It is normally specified on the Level directive within the Job resource definition, or in a Schedule resourc.
    - -
    Job
    -
    A Bacula Job is a configuration resource that defines + +
    Job
    +
    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 Type (backup, restore, verify, etc), the Level (full, incremental,...), the FileSet, and Storage the files are to be backed up (Storage device, Media Pool). For more details, see the - Job Resource definition - in the Director chapter of this document.
    + Job Resource definition + in the Director chapter of this document. -
    Monitor
    -
    The program that interfaces to the all the daemons +
    Monitor
    +
    The program that interfaces to the all the daemons allowing the user or system administrator to monitor Bacula status.
    - -
    Resource
    -
    A resource is a part of a configuration file that + +
    Resource
    +
    A resource is a part of a configuration file that defines a specific unit of information that is available to Bacula. For example, the Job resource defines all the properties of a specific Job: name, schedule, Volume pool, backup type, backup level, ...
    - -
    Restore
    -
    A restore is a configuration resource that + +
    Restore
    +
    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.
    - -
    Schedule
    -
    A Schedule is a configuration resource that + +
    Schedule
    +
    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 Schedule Resource definition in the Director chapter of this document.
    - -
    Service
    -
    This is Windows terminology for a daemon -- see + +
    Service
    +
    This is Windows terminology for a daemon -- see above. It is now frequently used in Unix environments as well.
    - -
    Storage Coordinates
    -
    The information returned from the + +
    Storage Coordinates
    +
    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 @@ -320,21 +320,21 @@ the definitions of the terminology that we use. of the Storage Coordinates. The Storage Coordinates include the File Attributes (see above) plus the unique location of the information on the backup Volume.
    - -
    Storage Daemon
    -
    The Storage daemon, sometimes referred to as + +
    Storage Daemon
    +
    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).
    - -
    Session
    -
    Normally refers to the internal conversation between + +
    Session
    +
    Normally refers to the internal conversation between the File daemon and the Storage daemon. The File daemon opens a session 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).
    - -
    Verify
    -
    A verify is a job that compares the current file + +
    Verify
    +
    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 Tripwire does. One @@ -348,22 +348,22 @@ the definitions of the terminology that we use. 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.
    - -
    *Archive
    -
    An Archive operation is done after a Save, and it + +
    *Archive
    +
    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.
    - -
    *Update
    -
    An Update operation causes the files on the remote + +
    *Update
    +
    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 rdist capability. NOT YET IMPLEMENTED.
    -
    Retention Period
    -
    There are various kinds of retention +
    Retention Period
    +
    There are various kinds of retention periods that Bacula recognizes. The most important are the File Retention Period, Job Retention Period, and the Volume Retention Period. Each of these retention periods @@ -397,8 +397,8 @@ the definitions of the terminology that we use. mechanisms for the catalog to be automatically pruned according to the retention periods defined.
    -
    Scan
    -
    A Scan operation causes the contents of a Volume or a +
    Scan
    +
    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 @@ -410,8 +410,8 @@ the definitions of the terminology that we use. bscan section of the Bacula Utilities Chapter of this manual for more details.
    -
    Volume
    -
    A Volume is an archive unit, normally a tape or +
    Volume
    +
    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 @@ -444,9 +444,9 @@ represents in general a separate process (normally a daemon). In general, the Director oversees the flow of information. It also maintains the Catalog.

    - Interactions between Bacula Services + Interactions between Bacula Services

    -
-- 2.39.5