> > I must be honest, I find it quite hard to believe that people
> > can defend a system where there is a 100% decrease in
> > efficiency, that in many cases will NEVER be used (refer back to
> > my original post about build machines). That's what the current
> > text-base penalty is ... it is a *100 percent* increase in
> > resource load.
> >
>
> I question the 100% penalty, although I see some increase. How much
> of these sizes is due to the sources (for which there is a 100%
> penalty) and how much of these sizes is due to binaries
> (which presumably
> wouldn't be checked in? Or are the binaries checked in for
> some reason?
98% sources, a few binaries that are checked into the tree as
binhex'ed "text files" because SCCS cant handle binary files.
Nut the vast majority of my build is source, which means it is
pretty darn close to a 100% space increase for a build that never
uses the VCS for anything other than an extraction tool. Even in
the case where there are actual humans editing stuff, since the
tree is so large, and each developer only works in a fraction
of that tree (but needs the full tree present for builds), the
penalty is more noticable.
Bear in mind I am working with a FULL UNIX implementation here,
not just a kernel. Sometimes, for some tasks, I actually need
two full sets of UNIX source code, plus the whole of Java, gcc,
apache and a plethora of open source libraries. It is a LOT of
source. Not as big as some projects, granted, but not trivial
either.
Kean
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 17 09:50:30 2002