[cvsnt] Betr.: Re: sync-protocol questions
arthur.barrett at march-hare.com
Tue Sep 30 13:04:50 BST 2008
> The reason I got interested in replication is the availability of an
> up-to-date backup at any time.
> If the primary server were to crash, for example due to a
> disk crash, the
> existence of a mirror repository allows to be up in a matter
> of seconds.
> Simply change the hostname of the backup server and some
> CVSNT settings
> and the backup can replace the original server.
> Indeed, you don't really need sync for this (using unison or
> rsync alone
> would offer the same live backup), but when I started out
> reading up on
> the replication I didn't know that and believed the sync
> protocol would
> take care of all the replication.
Yes - and indeed our commercial users have had that option for a few
years already - there is a unison server hidden in the CVSNT lock server
that can be enabled with the right hocus pocus, and the standby server
can be left in 'read only' mode (again an option that's been on CVSNT
servers for years).
Certainly the sync provides another level of this - and that is a
genuinely valid reason to use it. The other really good reason to use
it is when the link to the main server may be failure prone. Whilst the
link being does will cause commits to fail - a lot of work can continue.
Ditto goes for if you want to work 'offline' on a laptop - the sync
protocol essentially enables a 'distributed cvs'.
An even better solution is what we originally planned to introduce in
2.5.04 a thing called MULTIROOT - a CVSROOT with multiple servers, eg:
:sspi:host1,host2,host3:/repo, but we ran out of time. The idea being
that the servers are tried in a certain order (either hardcoded or based
on ping time).
More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter CVSNT on Facebook