On Thu, 2009-01-29 at 13:12 +0100, Uriel wrote: > The issues with replica go beyond its tendency to wipe out complete > file systems. > > It includes, among other things, the performance of a drunken slug, > and as you well point out, the skils of a schizophrenic monkey for > managing local changes.
Full disclosure: I don't use replica. But... > All this has been solved by git and hg; and git and hg would *never* > wipe out your local files simply because the backing store for the > repository you are pulling from happens to break, the pull simply > would fail and leave your local repo intact, and when the remote repo > is brought back, all would work just fine. ...I'm really somewhat of a Git buff. So I'm obviously interested in this discussion. As was pointed out in a different thread Git architecture is, in fact, quite close to venti/fossil. Venti is the immutable hash addressed history and fossil is the index. Thus the way Git transfers history between the repositories is conceptually very similar to transferring venti blocks that can be reached from a designated set of VtRoots. This has a number of useful properties in Git: the state of the history repository has nothing to do with the state of your local write buffer (index). You may fetch quite a few additional blocks of history, but that doesn't force you to "reformat" your write buffer. In fact, it is usually a good idea to: fetch, inspect and only then do a "merge". replica, on the other hand, tries to not rely on anything but its own functionality, effectively making it possible to manage changes backed by something other than fossil/venti. Replica is trying to be more like rsync, than Git. I've come to realize that this might be, in fact, the key problem. Git itself is not afraid to admit that it *is* a filesystem. Linus said it explicitly on quite a few occasions. We already have a filesystem. Do we need another one? > Oh, and they are both *excellent* at helping one keep track of local > changes without messing everything up. > > Of course they also help with things like merges, changelog > generation, etc. but I suspect those things are not really wanted. And that is a complementary problem to all of the above: your history is as good (and as helpful in doing merges, etc.) as is the effort put into creating it in the first place. A conversation on this list a month or so ago completely convinced me that those who make changes to Plan9 sources see very little value in maintaining history that way. Thanks, Roman.
