Do you use version control other than for source code?

Question

I've found SVN to be extremely useful for documentation, personal files, among other non-source code uses. What other practical uses have you found to version control systems in general?

Answer 1

I edit a lot of documents in LaTeX, so I use SVN to store the tex files and images and so on. Handy for doing Diffs, and hopefully will save me if I have a disaster.

Answer 2

I have a folder in the path called bin with useful utilities like those from sysinternals and others. I use svn to keep these up to date on different machines. Also, things like powershell scripts, vimrc files, etc. are great to keep centralized.

Answer 3

I never even thought to use it for personal stuff, but on software projects, I check in pretty much everything that can't be regenerated at a later date (examples of this include executables and code-generated docs). Documentation always gets checked in. Presentations to customers gets checked in and tagged along with the code base used to demo, if there was a demo.

I'm thinking SVN and CVS aren't "friendly" enough to non-technical users, but I'm curious now as to the possibly uses for version control for non-engineering projects...

Answer 4

Generally anything that the build process needs I put in to source control. The only issue that comes up is if you have resoruces prepared by other departments e.g. Marketing, that go in your install for example.

Answer 5

Most documentation that will be viewed by more than one pair of human eyes. It is incredibly useful, for instance, during project planning phases when the analyst updates the requirements document and you'd like to see what changed since the last time you saw it. Wikis also have this functionality, natch. We use SharePoint for these purposes, but pick your vendor.

Answer 6

At one of my early jobs, we used CVS for DNS revision control. It was mainly a cheap and dirty way to back up the zone files.

I've also heard of people using a version control system for their home directories.

Answer 7

Hi Fernando,

I've seen version control being used for other non-source code purposes, like,

1. Schema files - a set of XML schema files that represent a real world schema
2. Content files - content represented in a specific format, this is tied to a designer in VStudio, using source control, allows history, rollbacks everything, with no database interaction

In both the cases we notice that it's basically verbose files, primary reasons to have these files in source control as opposed to "text records in database", is that

1. files that might need ability to compare versions
2. history (because multiple users work on them)
3. ability to rollback to an earlier version
4. labeling and releases by getting a specific label
5. if you use Team Foundation (TFS), the whole scrum templates with work items etc
6. no database involved, no extra development for all the above

Answer 8

During my final semester in school I took two classes that each had a large, time-consuming project due at the end of the semester. They both also required several long-ish papers throughout the semester. I made heavy use of SVN for both classes to track every change I made to every paper and project.

I'm more of a "write it all at once" kind of guy when it comes to writing, and tend to lose my train of thought if I try to spread the process over multiple sessions. Being able to diff the latest revisions of my papers made it much easier for me to get back on track.

Answer 9

I use revision control for just about all of my documents for any purpose.

I'm using Mercurial, so setting up a new repository in a given directory is a matter of a simple "hg init", which I found much less of a hassle than setting up a new Subversion repository.

I've also found that RCS is great in any situation where you need to sync files - I'm using that now instead of rsync for all of my syncing needs. It's also easier to make backups - cloning a repository to another location/machine/disk means I can just push the changes to that location, which is even easier with a default push repository. If you don't modify in the remote repo, then you don't even need to worry too much about setting that up other than the default.

One of the nicest things for me is that I can have syncing, backups or whatever on any system that I have SSH access to. (Well, if they'd install mercurial for me at Uni, then I could!)

Answer 10

Yes, I have a doc directory in git. I contains a todo list, a calendar and a few other documents.

Answer 11

I use SVN to check in changes to Asterisk VOIP Server config files. I have one repository with a folder corresponding to each of several servers. That folder contains the entire contents of /etc/asterisk.

Answer 12

I've used Subversion for everything from source control, build environments, installer scripts, and all that developmenty goodness. I've also set up a repository for non technical users for binary files, in this case old Excel and Word documents. It worked alright considering we lost any merge functionality. But it let all our users get a whole ton of information that was mostly edited by two or three people pretty easily. And with simple instructions on how to update before you do any editing (locking if necessary), and then dealing with conflicts (check what you updated and then delete your copy and perform an update) they were able to handle the repository thing pretty well, though I'm not sure they ever actually grew to like it. :)

Answer 13

I use version control a lot for common files, because I have one laptop, a desktop machine at work and a home desktop on which I do a lot of work too (I work from home two days a week).

A new session at any of them starts with a script called 'start' that updates a bunch of checkouts, and ends with a script called 'stop' that commits some things to VCS, or shows me at least the modifications.

I use it for:

• my one-file Getting Things Done task list (see yagtd, the tool I use)
• my password database (I should have sent in that suggestion to the StackOverflow podcast in reply to Joel's question)
• all of my random notes and files on projects
• a bunch of spreadsheets (including one that tracks some personal things day by day)
• some images (like the web avatars I use)

In addition, I've written something on top of Subversion to manage configuration files for both systems and my user accounts. I have so many accounts on so many machines, and I was tired of always relearning how to configure my shell/vim/... so I now store most of those things in version control too. That includes email signature files, a bunch of shell scripts in $HOME/bin, ...

Answer 14

In my company, the development group aims to use Subversion for pretty much every electronic document. This depends on being able to "lock" files that can't be merged, such as Excel documents. SVN provides the "requires-lock" feature, and the get-lock, modify, commit workflow is reasonably straight-forward.

The software engineers are on-board, but there is some resistance from mechanical engineers. They want to use the simultaneous collaborative editing features of Excel for example. They haven't adapted to the get-lock, modify, commit workflow.

TortoiseSVN lets you diff Word docs, which I find extremely useful. It also supports merging apparently, although I've been too chicken to try that feature...

I'd like to seriously consider a DVCS such as git or Mercurial. But unless it can lock binary file format (i.e. unmergable) files (thus becoming more like a centralised model for such files), and/or merge the binary file formats we use, it won't fit into my company's usage.

I just wish all software companies provided good diff and merge tools for their proprietary doc formats. That would increase the value of version control systems for proprietary doc formats.