Re: [9fans] Sources Gone?

["Roman V. Shaposhnik" <rvs@sun.com>]

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.