X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs Date: Mon, 30 Apr 2001 14:49:27 +0200 (MET DST) From: Hans-Bernhard Broeker X-Sender: broeker AT acp3bf To: djgpp-workers AT delorie DOT com Subject: Re: sbrk() storing the size of memory blocks In-Reply-To: <3.0.1.32.20010430165712.006cffa0@wingate> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Mon, 30 Apr 2001, Nimrod A. Abing wrote: > >http://www.delorie.com/bin/cvsweb.cgi/djgpp/ > interface like myself, it is very inconvenient to click on each file and > get a diff/revision history at that -- and not the file itself. That's a limitation in the version of CVSWeb used by DJ. The version at SourceForge, e.g., presents a much more detailed directory listing. Among other things, there's a direct link to the file itself, by clicking on the version number instead of the filename. OTOH, I suspect DJ may have done this on purpose, to keep the bandwidth requirements reasonably low. The same problem can happen easily once you start to provide regular development snapshots as a tarball: people will start to run cron jobs to always download the latest tarball to their own machines, no matter whether they actually need to have the latest and most potentially instable stuff there is or not. This could cause bandwidth exhaustion on DJ's server. (Even Sourceforge doesn't provide automated snapshot tarballs, by default. You have to do that yourself, as a project admin, if you want it). -- Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.