* Steve Lamb <[EMAIL PROTECTED]> [070923 09:42]:
> I am looking for a tool to help me maintain a backup of a writing
> project. Being a programmer my first instinct is to use something
> along the lines of rcs/cvs. I was thinking of svn since I have a
> project on Google Code and have the tools installed on one of the
> machines on which I would do a part of the writing.
I have been using Subversion for this very application for several
years; it works well.
> However in attempting to answer this question for myself with Google
> searches I ran across a message in a mailing list which said that
> version controls designed for software might not be the best for
> documents.
Humbug! Read the Subversion manual; in the introduction, it addresses
the matter.
> What I want is the following:
>
> =>o backup my work
As simple as executing the command:
composition_machine: $ svn commit -m '<whatever commentary you
care to provide concerning this update to the SVN repository>'
from a terminal on the composition machine.
Because of the "diff" technique used by Subversion (see below), you
may commit a hundred times an hour, if you wish, the only penalty
being running up the revision counter (which is of no real
consequence). If no change has been made to the documents under the
control of Subversion, the commit command does nothing; this means
that you could, if you wished, use "cron" to periodically commit.
> on a machine separate from the machine(s) I'll be working on.
Simply create the repository on the other machine. This means that
the other machine must be running whenever you wish to commit a
revision.
But there is no need to have physical access to the repository
machine, other than to power it up; it is not necessary to log in at
the keyboard, at least if the repository machine is running GNU/Linux.
This is because Subversion is able to commit using ssh, which allows
remote login (and does so automatically, if you have ssh properly set
up with a passphrase). You also can shut down the repository machine
via ssh; so there really is no need for physical access, other than to
power up the machine.
And if you wish to backup to a medium such as a USB flash memory
stick, simply plug the USB flash stick into the repository machine and
then, from your composition machine, open a ssh channel over which you
can issue backup commands:
composition_machine: $ ssh repository_machine
repository_machine: $
Then, via ssh from the composition machine, backup the repository to
flash with the Subversion "hot-backup.py" script:
repository_machine: $ ./hot-backup.py /repository/ /media/flasha1
> =>o sync across multiple machines.
As simple as executing the command:
another_machine: $ svn update
from whichever machine you wish to bring up-to-date.
> =>o handle non-text data as well as some textual data. The main file
> that is going to change most often is an OOo document (odt). I'll
> also be storing any related files including Mindmap files (mm) and
> Writer's Cafe files.
Subversion doesn't care; it handles any file type, including binaries.
> =>o version might be nice in case I want to back out of large portions
> of the document or refer to previous verbage I had removed and want
> to reconsider.
Subversion maintains repository versions, rather than document
versions. A single commit to the repository increments the repository
version, whether the commit was for the revision of a single document
or for revisions made to dozens of documents. But Subversion uses a
"diff" technique, so the size of the repository grows very little from
one revision to the next, unless you are adding much new material.
And with Subversion, you always can go back to any previous version of
any document. You can return even to a previous version of a document
which you have removed from the repository; this is a consequence of
the Subversion approach of viewing a revision as a state of the
repository, rather than as a state of a document: removing a document
from the control of Subversion does not change the history of the
repository.
> =>o must be accessible on Windows and Linux (Debian/KUbuntu)
Subversion works on Window$.
> At first glance I am leaning for throwing Subversion on my main box
> so I can sync the other two machines off of it.
I suggest that you put the Subversion repository on a machine other
than the composition machine (but do use a reliable drive!). This
way, if your composition machine fails, you haven't lost the
repository. And this automatically gives you two copies of your work;
or even three copies, if you export the repository to a directory on
the repository machine, and update that "working copy" upon each
commit. If the working copy on the repository machine is on a drive
separate from the drive which holds the repository, then you have
three copies of your work, each on a separate drive, and with almost no
hassle.
But even if you should happen to lose the repository, it can be
restored from the backup on the USB flash device.
> Not sure if there is something better suited to the task or that svn
> would be particularly ill suited.
Subversion is well-suited and is simple to implement and use.
RLH
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
