version/revision control software for things mostly not source

Chad Perrin perrin at
Sat Apr 17 17:32:38 UTC 2010

On Sat, Apr 17, 2010 at 06:08:49PM +0300, Dan Naumov wrote:
> I think I am reaching the point where I want to have some kind of sane
> and easy to use version/revision control software for my various
> personal files and small projects. We are talking about varied kind of
> data, ranging from binary format game data (I have been doing FPS
> level design as a hobby for over a decade) to .doc office documents to
> ASCI text formatted game data. Most of the data is not plaintext. So
> far I have been using a hacked together mix of things, mostly a
> combination of essentially storing each revision of any given file a
> separate file001, file002, file003, etc which while easy to use and
> understand, seems rather space-inefficient and a little bit of ZFS
> snapshotting, however I want something better.
> What would be examples of good version control software for me? The
> major things I want are: a simple and easy to use Windows GUI client
> for my workstation, so I can quickly browse through different
> projects, go back to any given point in time and view/checkout the
> data of that point to a Windows machine. Space efficiency, while not
> critical (the server has 2 x 2TB drives in RAID1 and can easily be
> expanded down the line should the need eventually arise) is obviously
> an important thing to have, surely even with binary data some space
> can be saved if you have 20 versions of the same file with minor
> changes.
> Sadly, FreeBSD's ZFS doesn't have dedup or this functionality would've
> been easy to implement with my current hacked together methods.
> Performance does't matter all that much (unless we are talking
> something silly like a really crazy IO bottleneck), since the only
> expected user is just me and perhaps a few friends.

If you're looking for local revision management, I think something like
Mercurial is an excellent choice.  If, however, you're looking more for a
system for backing up to a remote computer with revision management
included in the package, Subversion may be a better choice.  This is
because the basic assumption for distributed version control systems like
Mercurial (which I love) is that you'll be working on stuff locally and
want the ability to move forward and backward through changes, run
parallel development branches locally to try out things and compare your
results and so on, with occasional reintegration with others' efforts.
By contrast, a centralized VCS like Subversion operates on the basic
assumption that all your work is intended to be stored on some
centralized system, and when you want to commit a particular revision you
also want it at that moment to be backed up to that central location.

I think this is why Subversion was fairly popular as a simple, manual
backup system for a lot of people, while DVCSes like Mercurial tend to be
popular more specifically with software developers -- particularly in
open source projects.

So . . . depending on your particular needs and workflow, I'd say that a
centralized VCS and a DVCS are both candidates for "best option" in your

Note: I use Subversion and Mercurial as my examples because those are the
two I generally use and like the most.

Chad Perrin [ original content licensed OWL: ]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url :

More information about the freebsd-questions mailing list