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...

	Johannes