Dropbox is a fantastic concept, but it has some major flaws — namely that the software is proprietary, and that users must entrust their files to a third party. Unfortunately, Linux users have few alternatives to Dropbox — and even fewer that are free software and mature enough for daily use. While not quite mature, DVCS-Autosync is looking like an interesting alternative for file synchronization between Linux systems.
One other option is SparkleShare, an attempt to provide a multi-platform, git-based replacement for Dropbox. However, SparkleShare is still in early development, and is somewhat ambitious — it attempts to replicate not only Dropbox's main feature (synchronizing files seamlessly) but also to provide collaboration tools and an easy to use GUI frontend for viewing file revisions. SparkleShare also puts off some potential users because of the project's technology choices — namely that SparkleShare is written in Mono and uses git rather than another Distributed Version Control System (DVCS).
Many users simply want a tool that will synchronize files, and have no need for collaboration features, multiplatform support, or a GUI to manage all of it. For those users who don't find SparkleShare appealing, DVCS-Autosync is a Python-based alternative that is not as full-featured — but it does get the job done.
René Mayrhofer announced DVCS-Autosync on March 10th of this year, though the tool has actually been around for quite a while before that. Mayrhofer says that the script started life before SparkleShare was announced, as part of managing his home directory using SVN and then git. Mayrhofer says he lacks time to try to contribute to SparkleShare, but was "pleased to see others go into the same direction" and that he wanted to publish what he had so far.
So what is DVCS-Autosync? It's a Python script to keep DVCS repositories in sync when files are added, changed, or removed by automatically committing and pushing or pulling the files to the server and clients. It does this by watching one directory for changes, using inotify and communicating between clients using XMPP (Jabber). Thus, when changes are made clients receive a message over XMPP to notify them of the change and to initiate a pull from the git repository.
DVCS-Autosync has been based around (and tested with) git, but it's been written to allow use with other distributed version control systems — so if a user has a strong loyalty to Mercurial, they would be able to configure DVCS-Autosync to use Mercurial or another DVCS instead by editing the commands used for various DVCS-Autosync operations. For example, users could replace the default pull and push commands ("git pull" and "git push," respectively) with the appropriate pull and push commands for another DVCS.
Right now, DVCS-Autosync is not yet packaged for most distributions, excepting Arch. Packages for Debian/Ubuntu are on the way but for now if you want to use DVCS-Autosync it requires grabbing the source off of Gitorious and installing the necessary dependencies. Users will need Python 2.6 or later (2.7 seems to work just fine), Pyinotify, and xmpppy (packaged as python-jabberbot on Ubuntu). Of course git or your favorite DVCS is also required. Because the utility uses Jabber/XMPP to communicate between clients, you'll also need a Jabber account that you can use for its notifications.
The installation instructions on the DVCS-Autosync page seem to be a bit
outdated. There's no "autosync.py" included with the source, the
dvcs-autosync script is now what you're looking for. Also you can install
DVCS-Autosync using "
python setup.py install" rather than
copying the scripts manually.
The next step is to initialize a git repository on a central server, and to then clone that repository on each client that will be using DVCS-Autosync. Each client also requires a config file (included as .autosync-example in the source, under the main directory) that needs to be customized to add Jabber account information. After that, run dvcs-autosync and, if all is configured properly, it should just go. As long as dvcs-autosync is running, it will automatically commit files after they're added to the directory or changed, and synchronize files to the other clients after they've been checked in. Users do not need (or have the ability to) manually make commits with dvcs-autosync.
Note that it will not operate quietly, however. The application is set up to display desktop notifications for each change. This is similar to Dropbox's default behavior — but seems utterly unnecessary past the first few hours when one might wish to ensure that the script is actually working. Mayrhofer says that the devel branch now allows users to configure notifications to go to the desktop, XMPP, both, or turn them off entirely.
Users can recover older versions of files, or view commit logs, using the standard git utilities — but dvcs-autosync doesn't have any special tools for that, either. In short, it is currently a single-purpose utility that syncs files between machines.
DVCS-Autosync is an interesting alternative to Dropbox and SparkleShare, but it still has some room for improvement and a few missing features that may be problematic for some users.
First and foremost, DVCS-Autosync is missing encryption. While Dropbox's encryption is significantly compromised by the fact that the company can decrypt its users files without the users' permission or knowledge, it does at least offer the feature. DVCS-Autosync, on the other hand, makes no provision for encryption at all. Mayrhofer says that he "definitely" plans to implement encryption at some point — but for now it's assumed that the repository is trusted. Mayrhofer is undecided how to implement encryption but may look at using git-annex, which has gained support for encrypted backends recently.
Using git-annex might help with another weakness in the current implementation: if you're using DVCS-Autosync for syncing large files that change often, you may be looking at a fairly large repository after a while because it will store the entire file for each change. However, this is a known problem and DVCS-Autosync contributor Dieter Plaetinck has suggested using git-annex to handle large files as a way around the current problem.
Moving directories gracefully, and providing a single commit entry for multiple file events (such as moving a directory, or uncompressing a tarball within the synced directory) are also on the list of bugs to handle soon. Longer term, Mayrhofer has indicated that he'd like to add context to commit messages (such as which applications are open at the time), and a way to specify commit messages via a traybar icon or popup rather than the general commit messages that are generated by DVCS-Autosync currently.
In its current state, DVCS-Autosync has a few kinks to be worked out before it can reliably replace Dropbox for most users. However, there seems to be some strong interest in the application already, and it could quickly become reliable enough to become a staple for Linux users who just want a simple file synchronization tool that requires little attention.
Newsletters and articles
the beginning of a three-part series on undefined behavior in C. "Undefined behavior exists in C-based languages because the designers of C wanted it to be an extremely efficient low-level programming language. In contrast, languages like Java have eschewed undefined behavior because they want safe and reproducible behavior across implementations, and willing to sacrifice performance to get it. While neither is 'the right goal to aim for,' if you're a C programmer you really should understand what undefined behavior is." second installment in the series on undefined behavior in C has been posted to the LLVM blog. "The end result of this is that we have lots of tools in the toolbox to find some bugs, but no good way to prove that an application is free of undefined behavior. Given that there are lots of bugs in real world applications and that C is used for a broad range of critical applications, this is pretty scary." a new series of systemd articles; this set is aimed at developers. "As you can see this code is actually much shorter then the original. This of course comes at the price that our little service with this change will no longer work in a non-socket-activation environment. With minimal changes we can adapt our example to work nicely both with and without socket activation..."
Page editor: Jonathan Corbet
Next page: Announcements>>
Copyright © 2011, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds