>
>
>
> We got similar benefits at my former employer when we stored JAR files in
> SVN (archival of old revisions); especially small patches and hotfixes with
> only a few changed class files were transferred and stored efficiently.
>
> You could also transparently transform the zip into an uncompressed zip
> file before uploading it, thus getting more benefits from differential
> storage - at the possible loss of bit-for-bit identity if you try to
> recompress the zip again on download, as different implementations of the
> algorithms tend to give slightly different results, even for the same
> compression level. On the other hand, this could even improve storage on
> the server when configured with a high compression level, as the server
> side compression can then exploit inter-file redundancies in the zip file
> (if present), while zip itself compresses all files independently.
Not related to Svn, but elsewhere I was working towards Maven Jars in Git,
too ......
*"Github releases as a Maven repo" *
So I have 27 releases of XStream unzipped and pushed to https://github
.com/paul-hammant/mc-xs-classes In terms of size 8.4M of Jars is now 2.4M
of bare .git repo. I wrote about 0.01% of XStream back in the day in case
you were interested.
All the jars are still available - here - https://github.com/paul-hamm
ant/mc-xs-classes/releases (the signatures don't match those from Maven
Central, but that is not important right now). Those jars are mere tags in
Git. GitHub via their 'releases' feature has done the rest. I have a
Python3 script that can spider a Maven group/artifact and push all the
releases to GH quite quickly.
Note: the size of the .git/ folder doesn't change regardless of the order
of unzipping jars and piushing their contents to the repo. Git doesn't
store deltas, and uses a DEFLATE algorithm for storage. Diffs are
meaningless on binary files, of course.
And yes, the idea is a that teams can quickly host their own binary deps on
GitHub and not bother with Maven Central at all. This might suit
experimental things, more than mainstream. It also might suit Snapshot
releases. I've a blog entry on the general idea of git as a MavenCentral
alternate - https://paulhammant.com/2017/05/13/maven-central-as-
multiple-git-repos/ and other postings in various Maven mail lists that
share code, if you're interested.
-ph
Received on 2017-08-04 13:24:02 CEST