[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Can cvs support distributed development usage.

From: Kaz Kylheku
Subject: Re: Can cvs support distributed development usage.
Date: Tue, 18 Sep 2001 04:09:43 GMT
User-agent: slrn/ (Linux)

In article <address@hidden>, Yi Zhou (RD-CN) wrote:
>As u say , CVSup is not good enough to implment sync function, can u
>recommend me another strong tool?
>Can rsync or rdist can do the same thing?

You don't seem to get it. Suppose you have two repositories A and B which
start out being identical. Then users do some work and commit it to A.
Users of B do some work and commit as well. The problem is, they both
did it to corresponding files. Now what do you do? If you keep only
the A version of the files, you lose the work done on B and vice versa.
No simple-minded sync tool can solve this problem; you need some
real distributed algorithm to keep the updates coherent across the
distributed servers.

The simplest thing you can do with the available tools is have only one
repository be writable, and the others be read-only cached replicas that
are periodically updated.

For real distribution, you would need some protocol which would keep
track of which repository has the latest version of a file, keeping
all the commits coherent across the system. It almost doesn't make
sense; arguably the client/server distribution is already good enough.

>Provided that the code most likely to be worked on by any given
>developer is stored in their local repository they'll get decent
>performance from localised commit/update/etc operations.

That won't necessarily be the case, because their local CVS repository
will have to synchronize with the remote ones. If your local repository
doesn't have the latest version of a given file and you want to update,
then it has to fetch that file from the remote repository.  Moreover,
your commits have to be broadcast to the other servers.  (Or at least
invalidation notices have to be sent out). The algorithms needed
to scale CVS's concistency model to a distributed system could introduce
poor performance.

As far as local replication goes, *you already have that*. It's called
your working copy. Once you have a working copy, files that do not
change are not downloaded when you do a cvs update, only ones that need
updating. So having one additional level of caching in the form of a
local repository won't really help, other than perhaps make your initial
checkout much faster.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]