On 06/29/2012 04:37 PM, Makarius wrote:
I did not know this "build artifacts" business yet, but after some web
browsing I now understand for what SVN used to be abused in the past.
Here is a comparison matrix for the 3 main players in the field (from
the Maven perspective):
http://docs.codehaus.org/display/MAVENUSER/Maven+Repository+Manager+Feature+Matrix
Artifactory appears to win in most respects; this is consistent with
what I've seen on Stackoverflow discussions etc. about the same question
"foo vs. bar vs. baz" in artifact management.
But almost none of the categories discussed are even remotely relevant
for us.
BTW Mercurial classifies largefiles (and subrepositories) as "Features
of Last Resort" http://mercurial.selenic.com/wiki/FeaturesOfLastResort
[...]
What we have is a monotonic store
of "artifacts", where certain Isabelle versions take a projection
according to Admin/components or similar. This allows to use the
Isabelle history in the expected way, e.g. bisect over a certain range
with the
right components being used automatically. No restriction to "latest
this, latest that", with implicit meaning of "latest".
Agreed. I abandoned the largefiles idea already myself by now.
Artifactory seems to be the "solves all your problems solution",> but it
is also quite large. See also http://www.jfrog.com/products.php
Here is a live demo
http://repo.jfrog.org/artifactory/webapp/browserepo.html?11
This means all this infrastructure offers a plain hierarchic web
download in the end -- no need to use Maven. A modest wget script can
still download components as plain URLs. On the server side it is a bit
more than just a modest python script, though ...
It is complete overkill, IMHO. And these Java-based servers based on web
containers (Jetty et al.) do not always play nicely in a Unix
environment, e.g., shutting them down does not always work reliably,
etc. I think we should build something with standard Unix tools, instead
of relying on another server from a different universe.
So here is my latest low-tech proposal:
* /home/isabelle/components is the components repository, where all
components are stored. They are stored as tarballs.
* The existing php script can be used to serve this directory via HTTP.
* Non-free components are marked as such simply via file permissions,
i.e., by having the world-readable flag unset. Since Apache runs under
group "isabelle", we might have to set the group to something else
(e.g., an imagined "isabelle-admin").
* Integrity of this directory is ensured by a cron job which compares
the output of "sha1sum /home/isabelle/components/*" with a file
in the Admin section of the Isabelle repository. So we can easily detect
accidents (and revert them, possibly with the help of the standard
backups). Such a script is easy to write, and I already have
some fragments lying around here.
* /home/isabelle/contrib is maintained automatically by unpacking the
contents of the tarballs (and setting permissions properly).
* A similar script in Admin/ can download components via HTTP and link
them into a clone of the Isabelle repository.
I would say that 30 lines of bash will do. And additional 30 lines of a
README, which goes into the same directory.
Alex
_______________________________________________
isabelle-dev mailing list
[email protected]
https://mailmanbroy.informatik.tu-muenchen.de/mailman/listinfo/isabelle-dev
