[Top][All Lists]

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

Re: Multisite CVS

From: david
Subject: Re: Multisite CVS
Date: Fri, 8 Nov 2002 10:08:59 -0600 (CST)

> Can CVSup so something useful if a person at both sites commits to the
> trunk between updates?  How is that type of conflict resolved?
I looked at CVSup fairly closely at one point, and AFAICT that type
of conflict is resolved by throwing away the changes at the
"slave" respository.  If you're going to have people committing
at the "slave" repository, you *must* have these commits have
revision numbers that are not the same as those on the master.
This can be done by forcing revision numbers to be used, or by
branching at the master repository and making absolutely sure
nobody there commits to those branches.
> What if people at both sites apply the same tag?
I don't know, but I fear the worst.  What likely happens is that
the slave repository is overwritten.

CVSup is *not* *designed* for multisite use.  It is useful for read-
only remote repositories.
> --- Forwarded mail from address@hidden
> Couldn't you use something like CVSup and automatically trigger its
> execution after every check in?

You could, I suppose, but there's race conditions to deal with.

> Is there more to a multisite repository than meets the eye?

What strikes me is that there is no way to know if any given repository
is in a consistent state, and that it is quite possible for two
people to check in stuff with the same revision number at different
respositories, as long as they do so before any sort of synchronization
can be applied.

> (I assume the poster is aware that cvs works just fine half way around the
> world from the repository.)
I hope so; that is, after all, the proper way to use CVS for
distributed development.

Now building a CVS reference site at

reply via email to

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