My approach is very slightly different, and it is due to similar catastrophe
concerns, but since these are all from a single author (me!), I don't really
need to have check-in and check-out from a VSS or SVN repository.
In gory detail, what I do:
1. Manual creation of a new sub-folder every time I do a "release" to
customers and internal users.
The new sub-folder name is the version number of the book.
This creates a complete copy of a given document files and
keeps this released version (including a PDF of the book) entirely separate
from the new work.
1. Automatic local backup of all changed files every hour to an
external drive, using "ShadowProtect".
This is an outstanding program, by the way, from
www.storagecraft.com and I am sure that there are others like it.
What I particularly like is the simple ability to "mount' the
compressed images and versions as it were an add-on drive on my system, for
easy file recovery if needed.
This also allows me to recover a previous version of a file if
I decide that I do not like the changes I have made to any given .fm file.
Since it copies every hour, I can go back in time pretty
easily. Sorta like Apple's Time Machine.
2. Automatic weekly FULL drive backup to the same external drive, using
ShadowProtect.
This is for the situation if my laptop disk drive were to die
and I needed to rebuild on a new computer.
Continous three weeks of laptop drive copies available on that
drive (if I were to start using a 2TB external drive (costs less than $150
now!), I could have more than 3 months of backups on it).
3. Manual weekly copy of my entire working directory tree to two drives
at home, using "Beyond Compare".
This is an excellent folder comparison utility from
www.scootersoftware.com, and it also allows easy drive/folder synchronization.
Since this is just a synchronization, it keeps only one
"version", if you will, of all my files.
In summary, I have:
1. Version control - in separate folders on primary laptop disk.
2. Primary disk catastrophe prevention - in a separate external drive
on my desk.
3. Some geographic redundancy - in two separate drives at home.
What I _don't_ have is full geographic redundancy. In case San Jose decides to
slide into the Pacific in the Big One!
I am, however, exploring using on-line Internet storage for this. For example,
I am very impressed with how incredibly easy Dropbox (www.dropbox.com) is to
use - I am using their free 2GB version now and once they release the non-beta
of the system, I will probably sign up for additional capacity. The remote
Dropbox directory simply looks like another drive/folder on my system. Copying
files to it sends it to the web site storage and also makes it easy to access
from any of my computers that have the app running.
I have in the past, tried Mozy (www.mozy.com) after it was recommended by my
brother-in-law, but was not happy with the major bug I found trying to replace
a computer where the "backup" was being done. Their info got out of synch, and
they could not fix this bug - so lost my files. Fortunately, I was still in the
early days of using it, so had not yet abandoned my disk backups - I got a
refund from Mozy.
Hope this helps,
Z
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Alison Craig
Sent: Friday, August 06, 2010 10:28 AM
To: Andy Kass; [email protected]
Subject: RE: FrameMaker and Version Control Software
Andy:
Thanks for all the information (FYI - I use unstructured FM9).
I use version control as version control as I do find myself having to go back
to previous versions periodically (in the old MS Word days - pre June 2009 - I
also needed to be able to rescue myself from a severe crash!).
However, backups are equally as important and until a couple of days ago, my
VSS database was *never* getting backed up. If the place caught fire or we had
a flood (and we're located in a major river delta flood plain), documentation
would be screwed - and given that medical devices cannot legally ship without
documentation, that means the whole company could be screwed.
I know FM and Word files (yes, I still have to maintain certain types of
smaller documents in Word) take a lot more space than programming files, but
until IT initiates a space discussion, I'll continue doing daily check outs and
check ins. IMHO, not using this functionality negates the point of version
control.
I had a conversation with my R&D contact yesterday and he told me that unlike
VSS, SVN keeps all files (in a project?) at the same revision level at all
times. That might be great for the programmer's but as the lone writer I can't
see the benefit for me - at least not at the present time. It seems to me that
this would only serve to bloat the db size.
I guess I need to play around with the various SVN options to see what I think
is necessary without taking up more than my share of network/backup space.
Thanks again for the input.
Alison
Alison Craig, Technical Writer
Ultrasonix Medical Corporation
Tel: (604) 279-8550, ext 127
E-mail: [email protected]
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Andy Kass
Sent: Thursday, August 05, 2010 5:43 PM
To: [email protected]
Subject: RE: FrameMaker and Version Control Software
Hi,
I'm on digest, so a bit late to this discussion.
I wanted to clarify that version control and backups serve 2 different
purposes. And although version control inherently does backup, it does it
inefficiently (uses more space) in the case of unstructured FM's binary files.
For binary files, version control stores the whole file every time. So if you
change a comma, update your book, and commit your change, every file in the
entire book will be archived to the repository (about 5 MB in our case).
For structured FM, whose text files are like code, version control is actually
a very useful tool for backup because it provides all the benefits of version
control (no locking necessary, concurrent changes, merging, rollback), and can
be used as an efficient backup if you commit the files every day (or more
often). IMHO, this functionality and simplicity is a huge benefit of structured
FM (and SGML-based writing tools in general).
We use unstructured FM 8 with SVN for version control, and here's our process:
We only do checkins (commits) at major milestones (writer handoffs or releases)
to reduce the impact of binary FM files on SVN. Then we check out from SVN to
our PC drives (not backed up) and copy the files back and forth to a working
directory on a backed up network drive. This keeps the very large SVN
repository from taking up too much space on the networked drive and it keeps FM
(and myself) from polluting my SVN directory with lock files, backup files, and
other temporary working files.
Because I don't work directly on my repository files, I only need a few SVN
commands that I can do from the command line--so I don't use tortoise (but
others in my team do).
For locking, the SVN mechanism isn't very easy to use, so we just have a wiki
pages that we update to indicate a lock--and we only lock entire books at a
time. However, if I'm only fixing a bug or modifying one chapter, I'll only
commit the one file. This leaves the checked in book in an unpublishable state,
but we have to do a full production before the next release anyway.
Regards,
Andy
_______________________________________________
You are currently subscribed to framers as [email protected].
Send list messages to [email protected].
To unsubscribe send a blank email to
[email protected]
or visit
http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com
Send administrative questions to [email protected]. Visit
http://www.frameusers.com/ for more resources and info.
