info-cvs
[Top][All Lists]
Advanced

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

RE: Opinion: open source-"supported" CVS backup capabilities are very we


From: Arthur Barrett
Subject: RE: Opinion: open source-"supported" CVS backup capabilities are very weak
Date: Tue, 8 Jan 2008 00:13:57 +1100

(this was posted to the CVSNT newsgroup as well - I'm reproducing my
response and some of Tony Hoyle's response here, slightly edited, since
Philip posted here as well and these comments are probably pertinent)

Philip,

> The simple CVS repository backup solution using RSYNC works fine on
> LANs or low cost WANs.  However, a CVS TAG operation that affects a
> large group of files will cause retransmission of entire RCS archive
> files.

RSYNC only transmits those parts of a file that have changed.  For a tag

operation this is very small, so whilst it will affect many files the 
amount of data sent is not going to be large at all.

We regularly sync between repositories using both rsync and unison, and 
the bandwidth requirements of such syncing aren't particularly high. 
What kind of size of repository are we talking about?

As far as your other points go, nobody has turned their back on 
anything.  There are at least 4 cvs based projects that I know of (on 
the server side.. dozens on the client side).  As someone who's worked 
with the protocol for many years I have a lot of respect for it.. it's 
stood the test of time and works well (and, most importantly, reliably).

Also look at Unison as an alternative to RSYNC since it works on Windows
and Unixes.

If you are using CVSNT then TAGs are often not needed anymore if you use
changesets (cvs commit -B nnn) or commit ids.

> The only widely-supported, multi-platform, open source, viable
> solution for low-bandwidth repository backup is Subversion.

Are you talking about 'svnsync'?  It's an odd idea - relaying successful
commits to a second repo, but could be easily added to CVSNT 2.5.04.  In
2.5.04 there is a 'sync' protocol that (currently) has two modes -
either all requests are passed through from the 'local' CVSNT server to
a remote one, or the 'local' CVSNT server processes all 'read' requests
(eg: diff, rlog etc) and the 'write' requests such as 'commit' or 'tag'
are passed to the remote server (and then unison or rsync is used to
mirror the change back again).  Adding a 3rd mode where the local server
processes the 'write' and also passes it to a 'remote' server would be
straightforward - please contact cvsnt-dev if you need pointers on
getting started in the coding.

>From memory CVS 1.12 has something similar (but different) with the
'cvsproxy' that may also be able to be developed into something like
this.

Regards,


Arthur
  





reply via email to

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