There's one repo per thing that is versioned. All these are separate repos
g: com/thoughtworks/paranamer a: paranamer type: javadoc is one repo
g: com/thoughtworks/paranamer a: paranamer type: sources is one repo
g: com/thoughtworks/paranamer a: paranamer type: classes is one repo
g: com/thoughtworks/xstream a: xstream type: javadoc is one repo
g: com/thoughtworks/xstream a: xstream type: sources is one repo
g: com/thoughtworks/xstream a: xstream type: classes is one repo
Or you could do it in less repos, I'm sure, and Git will still make a
compression saving.
And despite what you said, Git manages to find some commonality in *binary
classes *to make a saving. XStream's regular JARs:
Total size for *27* original versions 8.4MB
The .git folder afterwards 2.4MB
Raw/bare storage space saving 71.4%
Your point about the git:// protocol being being more chatty that http://
is true. That's probably more CPU on the server side. It is definitely more
time. See here ...
Git takes 1s to do:
git clone https://github.com/paul-hammant/mc-xs-classes --depth 1 --branch
1.4.3 --bare
Wget takes 0.5s to do:
wget http://central.maven.org/maven2/com/thoughtworks/
xstream/xstream/1.4.3/xstream-1.4.3.jar
On pom files - they are within the base Git repos, yes. You can't get them
from the server to the client in one Git operation, without bringing at
least a whole tag. Maybe there could be a tag just for the POM file to make
it addressable remotely, and checkoutable locally. I'll test that later
today.
- Paul
On Mon, May 15, 2017 at 4:14 AM, Stian Soiland-Reyes <[email protected]>
wrote:
> Interesting idea! All for experimenting with git!
>
> You did not take into account the protocol differences, fetching a single
> 8MB jar from Maven Central is easy, while fetching 6 MB via multiple git
> HTTP resources (even assuming git packs there will be multiple http calls)
> is probably more expensive, particularly as a typical project may have 50
> dependencies.
>
> Would each version be a new git repo? The binary class files are not really
> suitable for "diffing" and would pretty sure be changed every release (even
> if the SRC is the exact same).
>
> It is possible in JAR to use jar200 packing, which can significantly reduce
> the compressed size. Perhsps that is relevant here. See
> http://docs.oracle.com/javase/7/docs/technotes/tools/share/pack200.html
>
> Are the pom files within these git repositories or can they be prefetched
> separately like today to speed up transitive dependency loading?
>
>
