Login | Register
My pages Projects Community openCollabNet

Discussions > commits > svn commit: r34 - in trunk: . www

fsvs
Discussion topic

Hide all messages in topic

All messages in topic

svn commit: r34 - in trunk: . www

Author pmarek
Full name P.Marek
Date 2005-11-19 04:48:02 PST
Message Author: pmarek
Date: Sat Nov 19 04:48:02 2005
New Revision: 34

Added:
   trunk/www/purpose.html (contents, props changed)
Modified:
   trunk/ (props changed)
   trunk/www/index.html
Log:
website update


Modified: trunk/www/index.html
Url: http://fsvs.tigris.o​rg/source/browse/fsv​s/trunk/www/index.ht​ml?view=diff&rev​=34&p1=trunk/www​/index.html&r1=3​3&p2=trunk/www/i​ndex.html&r2=34
====================​====================​====================​==================
--- trunk/www/index.html (original)
+++ trunk/www/index.html Sat Nov 19 04:48:02 2005
@@ -15,6 +15,7 @@
 System VerSioning” or “Full System VerSioning”. It
 aims to become a complete backup/restore tool for linux machines,
 with a subversion repository as the backend.</P>
+<P>Read more about <A HREF="purpose.html">how it should work</a>.</P>
 <H2>What is does currently</H2>
 <P>FSVS is still in development.<BR>Currently it does (in subversion
 speak)</P>
@@ -27,6 +28,8 @@
     filesystems like /proc, /sys, /dev (if devfs), and so on.
     PCRE-expressions and recursive ignore patterns are possible, too.
 </UL>
+<P>You can browse through some (text-only) documentation <A HREF="../fsvs/doc/"​>here</A> -
+this is the same as available in the source packages.</P>
 <H2>What it needs to run</H2>
 <UL>
     <LI>subversion-1.2 libraries

Added: trunk/www/purpose.html
Url: http://fsvs.tigris.o​rg/source/browse/fsv​s/trunk/www/purpose.​html?view=auto&r​ev=34
====================​====================​====================​==================
--- (empty file)
+++ trunk/www/purpose.html Sat Nov 19 04:48:02 2005
@@ -0,0 +1,102 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=iso-8859-1">
+ <TITLE>FSVS purpose</TITLE>
+ <SCRIPT SRC="http://www.tigris.or​g/branding/scripts/t​igris.js"></SCRIPT>
+</HEAD>
+<BODY LANG="en-US" DIR="LTR">
+
+<H1>Purpose of FSVS</H1>
+
+<HR>
+<H2>Overview</H2>
+FSVS should do two things:<UL>
+<LI>Make reliable, compressed, non-intrusive, versioned backups with meta-data support.
+<li>Help in system deployment.</ul>
+
+
+<HR>
+<H2>Backups</H2>
+ As long as you regularly commit your machine's files, you're safe.<BR>
+ If your harddisk dies, you just update to the last version;
+ if you destroy or remove a file per accident, you can choose a version
+ from your repository.
+ <P>Most of that can be done by <a Href="http://subversion.tigris.org">subversion</a>
+ today; what FSVS does more:<UL>
+ <LI>meta-data support (although patches for subversion
+ <A href="http://svn.collab.ne​t/viewcvs/svn/branch​es/meta-data-version​ing/">exist</a>;
+ but they don't have much chance to be ever included, in spite of
+ <A href="http://subversion.ti​gris.org/issues/show​_bug.cgi?id=1256">issue 1256</a>
+ and many wishes on the mailings lists);
+ <li>non-intrusive means that there are no <TT>.svn</TT> subdirectories in every directory.
+ (like <a href="http://svk.elixus.org/">svk</a>, but that's IMO slow and needs a local repository).
+ </UL>
+ The advantage over using <A href="http://rsync.samba.org/">rsync</a> is the availability of many version per file,
+ and storing these compressed; scripts exist to have a few versions backuped with rsync,
+ but they're all full-text. (At least the changed files use their full size).
+
+
+<HR>
+<h2>System deployment</h2>
+
+<div style="float:right; border:1px solid black; padding:5px;">Example tree:<PRE>
+base/
+ trunk/
+ tags/
+ version-1/
+ version-2/
+ version-3/
+ released/
+user/
+ anthony/
+ bertram/
+ charlie/
+machine/
+ workstation-1/
+ workstation-2/
+ workstation-3/
+software/
+ package-1/
+ package-2/
+</PRE></div>
+
+Imagine having 10 similar machines with the same base-installation. <BR>
+Then you install one machine, check that into the repository as <tt>base/trunk​</tt>,
+and make a copy as <tt>base/relea​sed</tt>.<P​>
+The other machines get <tt>base/relea​sed</tt> as checkout source, and another (overlayed) from
+eg. <tt>machine/A​</tt>.<BR​>
+Per-machine changes are always committed into the <tt>machine/*​</tt>-parts of the repository; this
+would be eg. hostname, ip address, and similar things.<P>
+
+On the development machine all changes are stored into <tt>base/trunk​</tt>; if you're satisfied
+with your changes you merge into <tt>base/relea​sed</tt>, whereupon all other machines can update
+to this latest version.
+
+<P>So by looking at <tt>machine/X</tt> you can always see what makes this machine different
+from the others; and in <tt>base/relea​sed</tt> you can check out every old version to verify
+problems and bugs.<P>
+
+It would be reasonable to have another tree in the repository for the user-data, eg <tt>user/X<​/tt>.<BR>
+On user installation this directory would be checked out onto the machine, and the user has the same data
+area everywhere, and backuped as often as the administrator tells cron to do commits.
+
+<P>
+Optional software packages could be stored in another subtree. They should be of lower priority than the
+base tree, because if conflicts arise<A HREF="#1"><sup​>1</sup>​</a>,
+the base should always be prefered, to make sure that the machine
+is at least accessible (it's better that a software doesn't work than that the machine stops working).
+
+</UL>
+
+
+<HR>
+<font size=-1>
+<A NAME="1">Note 1</a>: Conflicts should not be "auto-merged". If two or more trees bring the same file,
+the file from the "highest" tree wins.
+
+</font>
+
+
+</BODY>
+</HTML>
Messages per page: