From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <708075f8f47e3197600a9cbdf1dc3769@quanstro.net>
From: erik quanstrom <quanstro@quanstro.net>
Date: Thu, 29 Jan 2009 08:37:17 -0500
To: 9fans@9fans.net
In-Reply-To: <5d375e920901290412k3e48d87dy5261c9b1f1681127@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Sources Gone?
Topicbox-Message-UUID: 8d3d7aa6-ead4-11e9-9d60-3106f5b1d025

On Thu Jan 29 07:13:32 EST 2009, uriel99@gmail.com wrote:
> It includes, among other things, the performance of a drunken slug,

i don't know how slow a drunken slug is.  but before rushing
off to replace replica, it would be useful to see where the time
is going.  you may find that your proposed replacements suffer
from the same problems for the same reasons.  in fact, i suspect
that if things are slow, it is likely due to 9p latency from sources.
the same problem would apply to any tool using the high-latency
link.

i've had no problems with the performance of the replica tools.
when using replica to replicate fileservers, i have found that
the performance of replica was very good and seems to increase
fairly linearly with the speed of the source and target.

> and as you well point out, the skils of a schizophrenic monkey for
> managing local changes.

well then, please show me how hg/git or whatever would save
me from the situation outlined.  how would hg/git know that
i was really using some code which i had never locally modified
and was then removed on sources?

if you have any specific problems, i'm sure they could be quickly
fixed.

> 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 not convinced by this argument.  could you demonstrate how hg/git
would magicly apply correct deletions and not apply erroneous
ones and demonstrate how it's faster on the plan 9 codebase.

if you believe this is the way, then put your money where your
mouth is and do the work and show us how it's better.

otherwise, there's just no point in talking about it.

- erik