Still, once github gets an outage, our repositories are basically
'left-padded' (taken offline)

--
-- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal

On Wed, May 17, 2017 at 1:35 PM, Paul Hammant <p...@hammant.org> wrote:

> Aldrin - https://github.com/paul-hammant/mc-xs-all - no large files added
> to Git. Git makes 70% saving on bytes used ('bare' mode).
>
> On Wed, May 17, 2017 at 11:10 AM, Aldrin Leal <ald...@leal.eng.br> wrote:
>
> > Just a friendly reminder that git is not optimized for large files (for
> > this, they made git-lfs). Plus, when you do checkout a git repo, there's
> no
> > binary diffs - so if you've got plenty of releases, you'll be wasting a
> lot
> > of space/time in terms of transmission and storage.
> >
> > --
> > -- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal
> >
> > On Wed, May 17, 2017 at 9:37 AM, Paul Hammant <p...@hammant.org> wrote:
> >
> > > We can agree to differ on what I'm suggesting and what the impact of
> that
> > > would be :)
> > >
> > > On Wed, May 17, 2017 at 8:59 AM, Brian Fox <bri...@infinity.nu> wrote:
> > >
> > > > Even more than redefining what Central does, you're effectively
> > > describing
> > > > a new, unofficial java class packaging and distribution mechanism.
> This
> > > > seems like it will violate signatures etc and make tracking of what
> you
> > > > actually have a nightmare.
> > > >
> > > > On Tue, May 16, 2017 at 5:55 PM, Hervé BOUTEMY <
> herve.bout...@free.fr>
> > > > wrote:
> > > >
> > > > > this idea of putting everything in git is funny: not sure this will
> > go
> > > > very
> > > > > far from this poc, but let's imagine...
> > > > >
> > > > > on classes branch, splitting the jar into individual .class has
> IMHO
> > a
> > > > big
> > > > > drawback: we loose original jar and its signature
> > > > >
> > > > > On the other branches, the current poc shows commits for versions
> > that
> > > > are
> > > > > perfectly linear: if there are multiple branches that are released
> in
> > > > > parallel, the commit won't be so clean. I don't know if this will
> > have
> > > an
> > > > > impact on compression efficiency.
> > > > >
> > > > > Another issue with this idea: during development, with SNAPSHOTs,
> the
> > > git
> > > > > repo
> > > > > will be polluted: this idea IMHO could only be valid for releases
> > > > >
> > > > > not to speak about read concurrency when one requires to use
> multiple
> > > > > versions
> > > > > of a lib. And of course, write concurrency is even harder.
> > > > >
> > > > >
> > > > > Definitely, the idea is funny, but I don't see how this could go
> very
> > > far
> > > > > than
> > > > > this funny idea (in addition to the complexity for implementing
> this
> > > > > format in
> > > > > tooling)
> > > > >
> > > > > Regards,
> > > > >
> > > > > Hervé
> > > > >
> > > > > Le lundi 15 mai 2017, 21:45:00 CEST Paul Hammant a écrit :
> > > > > > One more repo:
> > > > > >
> > > > > > https://github.com/paul-hammant/mc-xs-all/
> > > > > >
> > > > > > One branch for each of classes, javadoc, sources, and poms
> > > > > >
> > > > > > 15 javadoc original versions: 24.1M
> > > > > >
> > > > > > 16 sources original versions: 4.9M
> > > > > >
> > > > > > 27 classes original versions: 8.4M
> > > > > >
> > > > > > Afterwards git work the bare .git folder is: 8.4M
> > > > > >
> > > > > > *77.5% saving on storage*
> > > > > >
> > > > > > Any artifact, *including the poms,* can be pulled down via a
> single
> > > git
> > > > > > command
> > > > > >
> > > > > > git clone https://github.com/paul-hammant/mc-xs-classes --depth
> 1
> > > > > --branch
> > > > > > TAGNAME
> > > > > >
> > > > > > 74 TAGNAMEs: classes-0.1, classes-0.2, classes-0.3, classes-0.5,
> > > > > > classes-0.6, classes-1.0, classes-1.0.1, classes-1.0.2,
> > classes-1.1,
> > > > > > classes-1.1.1, classes-1.1.2, classes-1.1.3, classes-1.2,
> > > > classes-1.2.1,
> > > > > > classes-1.2.2, classes-1.3, classes-1.3.1, classes-1.4,
> > > classes-1.4.1,
> > > > > > classes-1.4.2, classes-1.4.3, classes-1.4.4, classes-1.4.5,
> > > > > classes-1.4.6,
> > > > > > classes-1.4.7, classes-1.4.8, classes-1.4.9, javadoc-1.2,
> > > > javadoc-1.2.1,
> > > > > > javadoc-1.2.2, javadoc-1.3, javadoc-1.3.1, javadoc-1.4,
> > > javadoc-1.4.1,
> > > > > > javadoc-1.4.2, javadoc-1.4.3, javadoc-1.4.4, javadoc-1.4.5,
> > > > > javadoc-1.4.6,
> > > > > > javadoc-1.4.7, javadoc-1.4.8, javadoc-1.4.9, pom-1.2, pom-1.2.1,
> > > > > pom-1.2.2,
> > > > > > pom-1.3, pom-1.3.1, pom-1.4, pom-1.4.1, pom-1.4.2, pom-1.4.3,
> > > > pom-1.4.4,
> > > > > > pom-1.4.5, pom-1.4.6, pom-1.4.7, pom-1.4.8, pom-1.4.9,
> > sources-1.1.3,
> > > > > > sources-1.2, sources-1.2.1, sources-1.2.2, sources-1.3,
> > > sources-1.3.1,
> > > > > > sources-1.4, sources-1.4.1, sources-1.4.2, sources-1.4.3,
> > > > sources-1.4.4,
> > > > > > sources-1.4.5, sources-1.4.6, sources-1.4.7, sources-1.4.8,
> > > > sources-1.4.9
> > > > > >
> > > > > >  - Paul
> > > > >
> > > > >
> > > > >
> > > > > ------------------------------------------------------------
> > ---------
> > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>

Reply via email to