On 12 Dec 2002, Justin Erenkrantz <firstname.lastname@example.org> wrote:
> <email@example.com> wrote:
> >As I'm sure you realize, there probably has to be some way for a
> >slave to catch up when it's been separated from the master for one
> >or more revision.
> Yup, that is where I'd like to receive input from the community.
> Currently, it's a push model, but I'd *really* like for it to become
> a pull model where the slave updates from the master as necessary.
I live in Australia but regularly work on CVS and ClearCase
repositories in the US, so I'm fairly keen on caching. :-)
It might be nice if there was a way to get the client to cache all
possible history, so that one could do diffs against arbitrary past
revisions or look at logs while disconnected from the network. Since
the history is immutable this ought to be at least conceptually
straightforward. I don't know at what level this would best fit in.
Personally I would lean towards replicas pulling updates when they
need it, rather than vice versa, though I'm pretty ignorant about
whether that would be harder to implement.
- From a security point of view, it doesn't require the additional
privilege of allowing the server to initiate operations on the
replica. (Suppose there's a one-way firewall between them.)
- Replicas which only update rarely don't impose a cost on the
- Replicas which "drop out" don't cause a problem to the server.
With a push model, you need to either handle failure every time or
have a heuristic for detecting dead replicas.
- The replica doesn't need the information until a client asks for
it; at that point it can check for anything more recent.
- The master is probably "more central" on the network than the
replica, which might be e.g. on an intermittently connected or less
reliable network. Therefore the client's more likely to know when
its connection will be up, and when it ought to start replication.
If replication fails, the replica's adminstrator may be in a
better position to fix it.
The main advantage compared to a svn-aware caching proxy seems to be
that the changes are available as soon as the client requests them,
without needing to wait for them to come down from the parent.
However, I'm not sure that's a big advantage. To be sure it is up to
date, the replica has to check for updates anyhow.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Dec 13 07:56:06 2002