Replica and cvs/git/mercurial/darcs/whatever solve similar but different problems.
Onr fundamental difference is that the latter set is intended to keep trees exactly in sync, whereas the design of replica expects you to want some files to contain local changes that persist and are not synced back in the other direction. This is anathema to the version control systems I've used. (Mercurial, for instance, used to support it okay, but slowly the "-f" flags have been dropping off commands, making it harder and harder.) I am acutely aware of this problem because I use cvs and mercurial (git was far too much trouble a few years ago; maybe it is better now) as a clumsy synchronization mechanism for plan9port, and the way I use these tools is the way I used replica, not the way they are intended to be used. Replica also attempts to reuse the functionality of having a network mounted file system (sources) rather than invent its own protocols, and so on. Basically it tries to fit into Plan 9 well. This is probably one of the reasons for the lack of speed, but it's not insurmountable. The addition of fcp made it quite a bit faster, if I recall, and I'm sure there is still more that could be done. The replica tools are not SHA1-based because they cannot depend on the user having a venti to manage the blocks, and managing a separate copy of the data (like the dvcs's do) seemed out of character with fitting well into the surrounding system. I can easily believe that the replica tools might accidentally delete your whole file system (but only the files that you hadn't changed) if sources all of a sudden claims that the files are gone, like it did a few days ago. It's trying to stay in sync with sources, after all. This was a case that I would never have imagined, and it probably needs some sanity checking. If I were working on replica today, I would probably change it to only perform actions listed in the log, and not take the log merely as a set of hints about what actions to perform. Right now, if the log says "there's a new copy of devmnt.8" and replica looks and sources and doesn't see it, it assumes that there is another change to devmnt.8 coming up, namely its deletion. It probably shouldn't do that, as failure modes like sources forgetting its files demonstrate. I wrote replica and some fraction of fossil in my spare time, because I was using Plan 9 and wanted to make it a more hospitable environment. I'm not using Plan 9 anymore, hence not maintaining those tools. If you, as a user of Plan 9, want the tools to be better, that's what open source is all about. You have the source: fix the things that matter to you and contribute the changes back. Russ P. S. Erik is right. Understand the problem before you throw away the software. http://www.jwz.org/doc/cadt.html
