RE: [Flightgear-devel] Rsync access to base package - again
Yes, CVS does send stuff up the line, and yes on a 56K modem this does happen at only 33.6K (best case). However, it only happens once. If you use cvs -z3 up -dP for the update, then it does compress the files. Use z9 for more compression. My solution was to run the base packages CVS for 10-20 minutes every day when I checked my email, and a couple of weeks later, it had settled down. Alternatively, go to an internet cafe, friend or somewhere else with a fatter pipe, and grab the CVS snapshot tarball (can't remember the link right now), put it on a CD or compact flash card, unpack it at home, and then just update it. Richard -Original Message- From: Matthias Heukäufer [mailto:[EMAIL PROTECTED] Sent: 13 July 2003 11:04 am To: [EMAIL PROTECTED] Subject: [Flightgear-devel] Rsync access to base package - again Hi! I'm afraid of getting expelled from this list someday for bringing this subject up so often, but I haven't received an answer yet. My problem is that updating the basepackage via a dialup-connection and CVS seems almost impossible to me. First, the cvs client is obviously _sending_ every one of the local files to the server before updating my local copy. See this (partial) result of cvs -t update -APd: cvs update: notice: main loop with CVSROOT=:pserver:[EMAIL PROTECTED]:/var/cvs/FlightGear-0.9 - rename(CVS/Entries.Backup,CVS/Entries) - unlink(CVS/Entries.Log) - Sending file `AtlasPalette' to server - Sending file `ChangeLog' to server - Sending file `Thanks' to server - Sending file `joysticks.xml' to server - Sending file `keyboard.xml' to server - Sending file `large.sky' to server - Sending file `materials.dtd' to server ... Sending default.apt.gz alone kept my modem busy for about 5 minutes. Is there something wrong with my cvs-client or is this the normal behavior? Second, this method of updating seems a waste of bandwidth to me, as the bigger part of all the files transmitted to and from the server are likely not to have changed since the last update. Curt, could you therefore enable rsync-access to the basepackage at flightgear.org? This would make it possible for people without fast internet connections like me to run the latest release of flightgear. Thanks, Matthias ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ __ This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk __ __ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Rsync access to base package - again
Hi! I'm afraid of getting expelled from this list someday for bringing this subject up so often, but I haven't received an answer yet. My problem is that updating the basepackage via a dialup-connection and CVS seems almost impossible to me. First, the cvs client is obviously _sending_ every one of the local files to the server before updating my local copy. See this (partial) result of cvs -t update -APd: cvs update: notice: main loop with CVSROOT=:pserver:[EMAIL PROTECTED]:/var/cvs/FlightGear-0.9 - rename(CVS/Entries.Backup,CVS/Entries) - unlink(CVS/Entries.Log) - Sending file `AtlasPalette' to server - Sending file `ChangeLog' to server - Sending file `Thanks' to server - Sending file `joysticks.xml' to server - Sending file `keyboard.xml' to server - Sending file `large.sky' to server - Sending file `materials.dtd' to server ... Sending default.apt.gz alone kept my modem busy for about 5 minutes. Is there something wrong with my cvs-client or is this the normal behavior? Second, this method of updating seems a waste of bandwidth to me, as the bigger part of all the files transmitted to and from the server are likely not to have changed since the last update. Curt, could you therefore enable rsync-access to the basepackage at flightgear.org? This would make it possible for people without fast internet connections like me to run the latest release of flightgear. Thanks, Matthias ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rsync access to base package - again
Matthias Heukäufer wrote: Hi! I'm afraid of getting expelled from this list someday for bringing this subject up so often, but I haven't received an answer yet. My problem is that updating the basepackage via a dialup-connection and CVS seems almost impossible to me. First, the cvs client is obviously _sending_ every one of the local files to the server before updating my local copy. See this (partial) result of cvs -t update -APd: Well, CVS hos to know the difference between the file on the server and the local file. One way is to receive *all* files and compare them locally, but you could call this approach ftp ... Another way is to sent the file to the server and let the server decide if they are different. Sending default.apt.gz alone kept my modem busy for about 5 minutes. Is there something wrong with my cvs-client or is this the normal behavior? Second, this method of updating seems a waste of bandwidth to me, as the bigger part of all the files transmitted to and from the server are likely not to have changed since the last update. Try using cvs with the -z5 option. This compresses the files quite a bit. Curt, could you therefore enable rsync-access to the basepackage at flightgear.org? This would make it possible for people without fast internet connections like me to run the latest release of flightgear. While rsync is a very good way to sync two files, it really has an advantage when a binary marked file has changed in CVS. So for the base package this could give a faster download *and* less bandwidth consumption for the university. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
