(Illustration by Gaich Muramatsu)
Hi everybody, I've been using Coda over the last six month and would like to report on some of my experiences. I've been using Coda in quite a tiny setup to mirror my home directory. My server is a rather old machine, a pentium 133 with 64 MB RAM, later upgraded to 96 MB RAM and 1.6 GB swap (of which 1GB is used for Coda RVM). The server is also serving as a router with a squid cache/proxy. I have two clients connecting to the server, one of them is a laptop that is usually only suspended, the other one a plain computer running only occasionally. All systems are running Debian GNU/Linux. To start with the good things about Coda: when it works, it's really neat to have my files available on both clients without me having to worry about copying them over all the time and keeping track of versions. Unfortunately, things don't usually work out quite as well as I would wish. 1. Window managers and other X programs like to write their config and log files whenever they feel like it, so I usually ended up with conflicts pretty soon. Solution was to have local copies of the critical files and store only symlinks to the local copies on the coda volume. 2. .bash_history was another source of problems and went into conflict frequently. Well, I could deal with conflicts if they weren't show stoppers, especially if they occur in my home directory: when .bash_history is in conflict, I often ended up having a read-only backup/repair volume mounted in my home directory, preventing me from starting my window manager (KDE) because it insists on creating files in my home directory on startup. Often, I had to spend quite some time cleaning up things before I could really start work. The first few months it took me a lot of time to locate the files in conflict. /var/lib/coda/spool/<uid>/realm.cml wasn't always that helpful, and 'find -type l' often times out. It also took me a while to realise that their is usually (always) only one file visibly in conflict (i.e. shown as a link to @....), the next conflicting file shows up as a conflict only once I fix the first conflict. Quite often, venus would insist on crashing when encountering conflicts, so I learned to appreciate venus -init. After using coda for about six months, I have decided to try something else, maybe Unison. Coda generally works quite well now that I have made sure conflict-prone files are no longer in the coda file space, but every now and then I do run into problems right when I don't have the time to deal with them. I need something more fail-safe (btw, I never lost any important file due to coda's fault, usually only config files that were of no importance). Here's my list of things of 'requirements' that would make coda more useful for me: - don't let conflicts be show-stoppers. Currently, one conflict in a volume will stop all other files from being replicated. It would be easier to handle if coda would just stop replicating the files in conflict until those conflicts are resolved but keep working (read & write) for all other files. - better repair tool or more command line support for repairing. I frequently ended up with a conflict that repair refused to repair since it couldn't fine the global object. Even if that happens, let me just discard the local objects (currently I can do that using venus -init, but that will discard everything, not just the one object). - tools to tell me which objects exactly are in conflict. - keep venus from timing out (optionally). It took me hours today to copy my 700MB of data from the venus files space to a local partition because venus would time out. I ended up writing a script that waited a few seconds between every two files so venus would realise the server was still up before attempting to copy another file. - automatic token renewal or token-less (trusted) operation. What I remember from previous messages is that the tokens are essential for venus' operation. So token-less operation might not be possible, but maybe venus could acquire new tokens automatically just before an old one expires (old token could be used to authenticate with the scm). Well, keep up the good work, and maybe I'll revisit coda sometime in the future... JohannesReceived on 2004-09-04 17:43:29