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 <broeker AT physik DOT rwth-aachen DOT de>
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:	<Pine.LNX.4.10.10104301441270.3437-100000@acp3bf>
MIME-Version:	1.0
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

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.

- Raw text -