The thing from the Apache point of view is that there are about 100
different java projects. And almost every single one of them uses
commons-logging for example. So that would be 100 copies of
commons-logging checked in to the subversion repository. When a new
release is made, and each project checks in the new version, there
goes
another 100 copies (since binary diffs are not very efficient). It
does
add up.
And when backups are made, all those bits need to be copied to the
backup medium. It's not just disk space, but time too.
This is illogical: the web site instructions at http://
incubator.apache.org/guides/sites.html say that
"Regardless of which tool you use, the web site should be maintained
in the svn repository, and include the site generation tool as a
binary file."
Wouldn't those also end up having the same tools in the repo dozens
and dozens of times over?
Frankly, I think this is a problem that should be solved at the
backend level - why does SVN not e.g. calculate a hash for the binary
files, figure out if it already has one, and then stores only just a
link to it instead of the actual file? An inefficient
implementation should not burden the individual developers.
SVN FAQ suggests that the SVN binary-store algorithm is already quite
efficient, though.
And when somebody wants to download the source to browse it, they
don't
need to wait for all the binary dependencies to download too. Probably
less important, but still nice for non-broadband users.
I think this is a non-issue. Nobody has in over six years ever
mentioned that this would be a problem.
<target name="getlibs">
<mkdir dir="lib"/>
<get dest="lib/junit-3.8.1.jar" src="${getlibs.base}/junit/jars/
junit-3.8.1.jar"/>
<get dest="lib/logkit-1.0.1.jar" src="${getlibs.base}/logkit/
jars/logkit-1.0.1.jar"/>
<get dest="lib/avalon-framework-4.1.3.jar" src="${getlibs.base}/
avalon-framework/jars/avalon-framework-4.1.3.jar"/>
<get dest="lib/log4j-1.2.12.jar" src="${getlibs.base}/log4j/
jars/log4j-1.2.12.jar"/>
<get dest="lib/servletapi-2.3.jar" src="${getlibs.base}/
servletapi/jars/servletapi-2.3.jar"/>
</target>
Unfortunately, this
a) requires you to run a separate build script after *every single
checkout or update*. This has the downside that some people might
simply forget, and end up running with obsolete library versions.
This might result in greater load to the developers, when bugs start
appearing.
b) encourages wrong kind of JAR versioning (minor issue, could be
subverted with clever use of scripts), which causes upgrade problems
(you need special cleanup scripts to make sure duplicate JARs don't
exist)
c) is inconvenient to IDE users, who will need to either drop to a
shell, or define a separate Ant task just to be able to compile
software.
I think the old progammer saying: "you code it once, but the user has
to use it a thousand times" is valid here: we can either work a bit
extra now, or we can have all the developers have to remember to
update their libraries all the time."
It all depends on whether we think our customers in this case is the
Apache infrastructure team, or the JSPWiki developer community.
Are you talking here about being able to build pre-apache versions of
jspwiki using the contents of the apache svn repository? I'm not sure
that is necessary - or even a good idea. Having the full history of
source files is good. But for reproducing old builds, the jspwiki cvs
server will still exist, won't it?
It exists, subject to, well sunspots. It is still essentially
essentially a "hobby" -computer, connected to the internet thanks to
some very nice people I happen to know. HW might fail, the
connection might go away, etc.
This is BTW also the reason why I would like to move jspwiki.org to
some better place, hosted by Apache, if possible.
/Janne
