Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
On Mon, 29 Nov 2004 18:44:27 +0200, "mada" <no.spam at no.spam.org> wrote: >mostly binary files (ranging from .pdf and .ps to .bmp and .mp3, I am not > ..snip... >Suppose there is no network connection available, or that the data to be >exchanged between the cvs server at work and a client at home is too much to >exchange over the phone (I live in Greece, decent internet is an unknown >term here). So I was thinking about setting up a second cvs server at home, >always connect locally to each server either at work or at home, at have the >two servers exchange only the "differences" between their repositories, >only. Is something like that possible? Unfortunately, no, this is not possible with CVS. What is possible is to have one CVS server running in read-only mode as a mirror. This mirror then will get a snapshot of the repository files regularly in some non-CVS backup way. But it does not solve your problem.... > >As a worst-case solution, I would be satisfied if I was able to copy all the >checked-out modules from work to home, have them permanently checked-out >there, and only perform updates and commits online, which, as far as I >understand, do not require large data exchange. Is this possible? Yes, it is possible to have several working file sets (aka sandboxes) on different computers (or even on the same computer). This is what CVS was built for, really... This would in theory reduce the network traffic, but in practice, since there are no way to send binary file updates as deltas, you will still be stuck with transferring the whole file in an update or commit if it is binary (which affects all of the fie types you listed). If the files had been ordinary text source files then updates and commits would only send small amounts of data over the network. But CVS cannot handle non-text files this way. > >Do you see any better solution for such a scenario? > Not really... :-( /Bo (Bo Berglund, developer in Sweden)