Tips for Using CVS or Subversion as a Backup Frame for Office Documents

I have been using subversion for a long time (and before that CVS) to store not only the source files, but later LaTeX files for my research and, ultimately, some text files and other materials.

I like the fact that I can work with several computers and synchronize the latest things with each, while maintaining some hierarchy of my backups and projects.

I am sure that I cannot be the only one who does this.

Now I'm thinking of using CVS or subversion as the primary backup mechanism for a family computer, which includes many frequently changing office documents. Is this a good / bad idea? The main problem that I can think of is that the files are considered binary, so the server is a little bloated.

However, I would like to hear about other things that I should know about or take care of.

Also, where can I find good examples of scripts that can automate sessions?

+3
svn backup cvs
Feb 11 '09 at 20:11
source share
8 answers

In fact, I really do not recommend doing this before taking this path. First of all, I think it goes without saying that if you use the SCM repository for such a task, use SVN instead of CVS! This doubles for a situation where it is almost guaranteed that you will store binary data, which is a huge pain with CVS.

In any case, I used to store a large amount of non-programming material in SVN repositories, but now I only use a time machine to back up files that concern me, and a small website repo for my point files and such , I think the key thing that gets in the way is that you actually don't have the same attitude to normal data files as you did with the source code. In most cases, it is very unlikely that you are interested in sharing the two versions of the report that you wrote, or by returning your version of the working copy to some project that you wrote two weeks ago. With such documents, you usually only care about the latest version, and the tools and security that SCM provides are usually more annoying than useful in this regard, especially when it comes to commentary on recordings, merging, etc.

In addition, I highly recommend (is that a word ?;)), with the result that non-programmers use SCM. The required number of explanations is too large for the tool to be useful to them, especially in relation to a task not originally intended for this tool. I did this in several environments where we thought it would not be a problem, as these people were not stupid and they were dealing with software related artifacts. But inevitably, the confluence of conflicts and other SCM "gotchas" led to confusion and, ultimately, to phone calls to me in the evening.

I would say that you should study document sharing portals such as Sharepoint for collaborative office documents, etc. They are better designed to work with these types of things without causing a lot of headache for non-technical people and can gracefully work with version history, binary data, etc. This may be redundant for your family, but creating a small portal to store important data should not be a big problem - you just need to look around a bit and find something that suits your needs.

+7
Feb 11 '09 at 20:20
source share

You should explore the subversion auto version option. This allows you, for example, to configure a network resource that any computer can see and record, but which automatically performs the necessary commit actions whenever data is written. If someone accidentally deletes their document, they can be restored using subversion commands.

+3
Feb 11 '09 at 20:26
source share

This is actually a good idea. Subversion uses xdelta to store differences even in binary documents, so the server is not so overloaded with different versions.

As for scripts, just update svn when you enter the machine and don't forget to make svn commit when you leave. I have been doing this for my own data for several years and without problems.

+2
Feb 11 '09 at 20:14
source share

I use Mercurial to save office documents. He does everything I need -

  • Stay tuned for older versions.
  • Protect from disasters. Since Mercurial is a distributed version control system (DVCS), I have a repository on my work computer, laptop, other laptop and home machine.
  • Allow committing offline because it is DVCS.
  • Simple web interface for displaying changes

... and much more. Most of what she does is useful to me as a programmer, but she also makes things simple enough to manage documents.

Oh, and one major advantage - on the Mac, many “documents” are folders that contain a bunch of files. With SVN, you would quickly clutter up these folders with files that the application deleted, but SVN wants to save them. With Mercurial, when you delete a file, it gets “deleted” for this version, but if you look at the previous revision, it will come back! The perfect solution for Mac apps!

+2
Feb 11 '09 at 20:48
source share

http://wiki.documentfoundation.org/Libreoffice_and_subversion

This key seems to use the .fodt format, not the .odt format. Without compression, the traditional diff system, the fix works well without processing all your documents like binary files!

+2
Nov 25 2018-11-11T00:
source share

Yes and no.

Assuming that you are using version control (CVS or any other system) correctly, this is a good way to keep track of old versions of files, and you are more likely to find this version of your file exactly before or after you made any specific change if you have it.

However, version control does not protect you from natural disasters, such as the actual loss of your data (power surge on your computer with all its disks). Therefore, you need to back up your repository regularly on some secure media. Depending on how important this is, simply burning it to a CD / DVD and another mobile disc stored somewhere else may be enough.

In addition, problems may arise with your version control repository. Due to bugs in version control software, crashes, collisions, etc. Part of it may become damaged. Worse, you may not notice it until you find out that some versions cannot be restored. So you have a procedure for checking the integrity of your repository before backing up. And do not cancel all backups at once.

+1
Feb 11 '09 at 20:23
source share

Why not just use the backup tool for your documents? If you do not need changes and you only need the latter, it is best to use a backup tool / scheduled backup.

If you want fixes, go to your plan. The only thing that I could offer in this case is a scheduled task that performs fixing in the root of all your files. The commit comment may be "auto commit [date / time]", and I would have a different username for tasks.

0
Feb 11 '09 at 20:18
source share

I tried using TortoiseSVN on the internal NAS, but it didn’t work - I think because the drive was FAT32. I use SyncBack to support multiple copies of my files at home, as I am not worried about saving the change history.

0
Feb 11 '09 at 20:21
source share



All Articles