Hello Eric,

unfortunately I can hardly guess what is wrong in your situation,
may be more detailed description of your setup and how you get the conflict
might help.

(CML is "cache modification log", a recording of what
has been done to an object, like "create", "rename", "remove", "store")

Going a bit offtopic:

I notice details which are preferably avoidable in Coda administration.

You mount Coda at a non-standard place instead of the standard /coda.

Normally Coda gives the same view of the files on any computer in the world.
You are making your given Coda client incompatible with the rest
of the Coda world (e.g. symbolic links do not work on your client the same
way as for all others).

Another more subtle thing is administrating Coda as Unix root user,
it is a bit dangerous.
On one side there are usually many processes running
as root on a particular host and you do not always want all of them
get rights over distributed files (used on other hosts as well).

On the other side, the numeric value of a Unix uid is totally irrelevant
for Coda.

To see it from another point, root should be clog-ed to Coda only in cases
when you want the corresponding host's system processes to have certain rights,
like running cron jobs and updating files on Coda. Still, it would be
safer to run those jobs under a separate local uid and make that uid
instead of root to clog to Coda.

Things a human does interactively is his/her activity, not the host's.
It is best done under a separate uid.

You may know that AFS has been trying to attach distributed rights
to something else than uid, and went for PAGs, creating ground for a long term
confusion (they are still struggling with definition of the exact available
and desired semantics of a PAG).
Coda has a much simpler and cleaner approach, attaching the rights
to an uid, which is _the_ identity on Unix-like systems.

Sorry for not being able to help,
try to give more details, or may be somebody else on the list can suggest
a solution.

Regards, Rune