Silly Saturday idea - If Maven Central were a bunch of Git repos

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Silly Saturday idea - If Maven Central were a bunch of Git repos

Paul Hammant
I was discussing this of the list today, and it may interest people on dev@

https://paulhammant.com/2017/05/13/maven-central-as-multiple-git-repos/

     "Maven Central as multiple Git repositories"

Enjoy,

- Paul
Reply | Threaded
Open this post in threaded view
|

Re: Silly Saturday idea - If Maven Central were a bunch of Git repos

Paul Hammant
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
Reply | Threaded
Open this post in threaded view
|

Re: Silly Saturday idea - If Maven Central were a bunch of Git repos

Paul Hammant
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 <[hidden email]> 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 <[hidden email]>
> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Silly Saturday idea - If Maven Central were a bunch of Git repos

Aldrin Leal
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, <[hidden email]> / http://about.me/aldrinleal

On Wed, May 17, 2017 at 9:37 AM, Paul Hammant <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > 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: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Silly Saturday idea - If Maven Central were a bunch of Git repos

Paul Hammant
I would agree that it has the potential to be a new repository
implementation, Robert.
But I am not sure I follow your second sentence.  Maybe I do. There is one
Git repo per group/artifact. That's true for whether it is the principal
artifact you're after or a transitive dep.

1. For https://github.com/paul-hammant/mc-xs-all I have the sources,
classes, and javadoc as separate branches in one repo.

2. For https://github.com/paul-hammant/mc-xs-classes and
https://github.com/paul-hammant/mc-xs-javadocs and
https://github.com/paul-hammant/mc-xs-sources I have three Git repos per
group/artifact.

#1 and #2 are alternate coices. #1 has poms in their own branch in that Git
repo too - and they too are one-line retrievable from the remote.

- Paul

On Wed, May 17, 2017 at 1:27 PM, Robert Scholte <[hidden email]>
wrote:

> I consider this as a new repository implementation. But this also implies
> that in your pom, for every dependency you have to add a repository-entry
> as well, right?
>
> Robert
>
>
> On Wed, 17 May 2017 17:10:49 +0200, Aldrin Leal <[hidden email]>
> 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, <[hidden email]> / http://about.me/aldrinleal
>>
>> On Wed, May 17, 2017 at 9:37 AM, Paul Hammant <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>> > 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: [hidden email]
>>> > > For additional commands, e-mail: [hidden email]
>>> > >
>>> > >
>>> >
>>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Silly Saturday idea - If Maven Central were a bunch of Git repos

Paul Hammant
In reply to this post by Aldrin Leal
There is that, yes. And Git's general upper limits which are subject of "I
heard of a team that had a corruption at 2GB".  I've field tested Git up to
7GB for a git-svn-clone myself (a team considering saying bye bye to Svn),
but wouldn't put that live versus hive off history to a R/O repo, and start
over with HEAD of the old becoming the initial commit of the new.

- Paul

On Wed, May 17, 2017 at 2:40 PM, Aldrin Leal <[hidden email]> wrote:

> Still, once github gets an outage, our repositories are basically
> 'left-padded' (taken offline)
>
> --
> -- Aldrin Leal, <[hidden email]> / http://about.me/aldrinleal
>
> On Wed, May 17, 2017 at 1:35 PM, Paul Hammant <[hidden email]> 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 <[hidden email]>
> 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, <[hidden email]> / http://about.me/aldrinleal
> > >
> > > On Wed, May 17, 2017 at 9:37 AM, Paul Hammant <[hidden email]>
> 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 <[hidden email]>
> 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 <
> > [hidden email]>
> > > > > 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: [hidden email]
> > > > > > For additional commands, e-mail: [hidden email]
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Silly Saturday idea - If Maven Central were a bunch of Git repos

Paul Hammant
Aldrin, The blog entry I wrote on saturday mulled classes, javadocs and
sources -
https://paulhammant.com/2017/05/13/maven-central-as-multiple-git-repos/ (re
your "way more than" comment).

The GH repo I linked you to earlier has all three in one repo (see the
branches drop-down) - https://github.com/paul-hammant/mc-xs-all

- Paul



On Wed, May 17, 2017 at 2:54 PM, Aldrin Leal <[hidden email]> wrote:

> I understand the approach is basically general, but maven artifacts are way
> more than binary code (there's source and javadoc). I also understand its
> an interesting option for distribution.
>
> I really would like to see something close to what "go get" does. If not
> github and bitbucket (and go get includes git, hg and bzr among scms), it
> open the URL itself and resolve it into a(by means of HTML metadata).
>
> Just distributing the source allowing it to easily updates would be
> awesome, since it would allow less effort to create and distribute. Of
> course, we could have to limit the scope of what to do to avoid abuse.
>
>
> --
> -- Aldrin Leal, <[hidden email]> / http://about.me/aldrinleal
>
> On Wed, May 17, 2017 at 1:49 PM, Paul Hammant <[hidden email]> wrote:
>
> > There is that, yes. And Git's general upper limits which are subject of
> "I
> > heard of a team that had a corruption at 2GB".  I've field tested Git up
> to
> > 7GB for a git-svn-clone myself (a team considering saying bye bye to
> Svn),
> > but wouldn't put that live versus hive off history to a R/O repo, and
> start
> > over with HEAD of the old becoming the initial commit of the new.
> >
> > - Paul
> >
> > On Wed, May 17, 2017 at 2:40 PM, Aldrin Leal <[hidden email]> wrote:
> >
> > > Still, once github gets an outage, our repositories are basically
> > > 'left-padded' (taken offline)
> > >
> > > --
> > > -- Aldrin Leal, <[hidden email]> / http://about.me/aldrinleal
> > >
> > > On Wed, May 17, 2017 at 1:35 PM, Paul Hammant <[hidden email]>
> 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 <[hidden email]>
> > > 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, <[hidden email]> / http://about.me/aldrinleal
> > > > >
> > > > > On Wed, May 17, 2017 at 9:37 AM, Paul Hammant <[hidden email]>
> > > 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 <[hidden email]>
> > > 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 <
> > > > [hidden email]>
> > > > > > > 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: [hidden email]
> > > > > > > > For additional commands, e-mail: [hidden email]
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Silly Saturday idea - If Maven Central were a bunch of Git repos

Aldrin Leal
thats my point: the golang approach does no magic at all. It simply stores
the source code and bases it on a convention. Just the files, and thats it.

--
-- Aldrin Leal, <[hidden email]> / http://about.me/aldrinleal

On Wed, May 17, 2017 at 2:38 PM, Paul Hammant <[hidden email]> wrote:

> Aldrin, The blog entry I wrote on saturday mulled classes, javadocs and
> sources -
> https://paulhammant.com/2017/05/13/maven-central-as-multiple-git-repos/
> (re
> your "way more than" comment).
>
> The GH repo I linked you to earlier has all three in one repo (see the
> branches drop-down) - https://github.com/paul-hammant/mc-xs-all
>
> - Paul
>
>
>
> On Wed, May 17, 2017 at 2:54 PM, Aldrin Leal <[hidden email]> wrote:
>
> > I understand the approach is basically general, but maven artifacts are
> way
> > more than binary code (there's source and javadoc). I also understand its
> > an interesting option for distribution.
> >
> > I really would like to see something close to what "go get" does. If not
> > github and bitbucket (and go get includes git, hg and bzr among scms), it
> > open the URL itself and resolve it into a(by means of HTML metadata).
> >
> > Just distributing the source allowing it to easily updates would be
> > awesome, since it would allow less effort to create and distribute. Of
> > course, we could have to limit the scope of what to do to avoid abuse.
> >
> >
> > --
> > -- Aldrin Leal, <[hidden email]> / http://about.me/aldrinleal
> >
> > On Wed, May 17, 2017 at 1:49 PM, Paul Hammant <[hidden email]> wrote:
> >
> > > There is that, yes. And Git's general upper limits which are subject of
> > "I
> > > heard of a team that had a corruption at 2GB".  I've field tested Git
> up
> > to
> > > 7GB for a git-svn-clone myself (a team considering saying bye bye to
> > Svn),
> > > but wouldn't put that live versus hive off history to a R/O repo, and
> > start
> > > over with HEAD of the old becoming the initial commit of the new.
> > >
> > > - Paul
> > >
> > > On Wed, May 17, 2017 at 2:40 PM, Aldrin Leal <[hidden email]>
> wrote:
> > >
> > > > Still, once github gets an outage, our repositories are basically
> > > > 'left-padded' (taken offline)
> > > >
> > > > --
> > > > -- Aldrin Leal, <[hidden email]> / http://about.me/aldrinleal
> > > >
> > > > On Wed, May 17, 2017 at 1:35 PM, Paul Hammant <[hidden email]>
> > 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 <[hidden email]>
> > > > 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, <[hidden email]> /
> http://about.me/aldrinleal
> > > > > >
> > > > > > On Wed, May 17, 2017 at 9:37 AM, Paul Hammant <[hidden email]>
> > > > 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 <[hidden email]
> >
> > > > 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 <
> > > > > [hidden email]>
> > > > > > > > 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: [hidden email]
> > > > > > > > > For additional commands, e-mail: [hidden email]
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Silly Saturday idea - If Maven Central were a bunch of Git repos

Manfred Moser-4
Having worked with repository managers and the implementation for various formats on Nexus for years I think such a format is a bit like Bower. It is a registry format that in turn points to git repositories that have the content.

From a corporate usage and implementation point of view this is a utter nightmare since you would have to open up your systems to all those different repositories and sites hosting them instead of just one.

You also cant simply make a copy of the content or analyze it in the way it manifests as binaries.

I am not sure what you are looking for as benefits but from my point of view this is maybe a fun experiment but not something that will ever take off..

Manfred

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Silly Saturday idea - If Maven Central were a bunch of Git repos

Paul Hammant
And as I'm comfortable advocating for a few Git-centric alternates, GitHub
could be a hosting platform for jars of classes too.  I think I've
established that it is efficient for storing binary classes.

The https://github.com/paul-hammant/mc-xs-classes/releases page on the
mc-xs-classes I did for the blog entry, has downloads of tags. That's all
the classes you'd want and the manifest in a a zip. The trouble is GitHub
made a root directory which will break Java.

So I raised a feature request - https://cloud.githubusercontent.com/assets/
82182/26177670/9d0cc4b8-3b28-11e7-88e1-7e97f727623c.png

Don't worry, I'm 0 for 10 or so.

- Paul

On Wed, May 17, 2017 at 5:37 PM, Paul Hammant <[hidden email]> wrote:

> The Maven-using developer community cares that the dependency downloader
> does its think that the uploader/deploy does too. Some new releases of
> those, and some back releases for the hard breaks (if any) going back in
> time - Maven1, Maven2 and whatever.
>
> Works well enough for Homebrew (https://github.com/homebrew - the core
> repo is at 125MB). Sure there's been teething troubles, and Ruby was the
> wrong choice for the DSL versus Python, but it is great really.
>
>
>
> On Wed, May 17, 2017 at 5:25 PM, Manfred Moser <[hidden email]>
> wrote:
>
>> If you would run Central on git like that in a centralized manner you
>> would have to find someone that does that hosting for you and you would
>> have to get buy in from the community to use that - both extremely hard or
>> impossible.
>>
>> And if you dont do that but instead go with the distributed system you
>> end up with the registry model that I think just doesnt really work in the
>> real world.
>>
>> manfred
>>
>> Paul Hammant wrote on 2017-05-17 13:39:
>>
>> > Actually I'm proposing a predictable structure on 'central :
>> >
>> > [hidden email]:
>> > maven2/<group-name-with-slashes-for-dots</<artifact-name>.git
>> >
>> > (one minor fix versus previous description of the git:// location)
>> >
>> > Or for the three separate variant:
>> >
>> > [hidden email]:
>> > maven2/<group-name-with-slashes-for-dots</<artifact-name>-classes.git
>> > [hidden email]:
>> > maven2/<group-name-with-slashes-for-dots</<artifact-name>-javadocs.git
>> > [hidden email]:
>> > maven2/<group-name-with-slashes-for-dots</<artifact-name>-sources.git
>> >
>> > More likely though (as you mentioned in your opening line) is the way
>> > homebrew works - you point at repos elsewhere, but control poms/shas
>> etc on
>> > 'central.
>> >
>> >
>> >
>> >
>> > On Wed, May 17, 2017 at 3:59 PM, Manfred Moser <
>> [hidden email]>
>> > wrote:
>> >
>> >> Having worked with repository managers and the implementation for
>> various
>> >> formats on Nexus for years I think such a format is a bit like Bower.
>> It is
>> >> a registry format that in turn points to git repositories that have the
>> >> content.
>> >>
>> >> From a corporate usage and implementation point of view this is a utter
>> >> nightmare since you would have to open up your systems to all those
>> >> different repositories and sites hosting them instead of just one.
>> >>
>> >> You also cant simply make a copy of the content or analyze it in the
>> way
>> >> it manifests as binaries.
>> >>
>> >> I am not sure what you are looking for as benefits but from my point of
>> >> view this is maybe a fun experiment but not something that will ever
>> take
>> >> off..
>> >>
>> >> Manfred
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [hidden email]
>> >> For additional commands, e-mail: [hidden email]
>> >>
>> >>
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Silly Saturday idea - If Maven Central were a bunch of Git repos

Paul Hammant
In reply to this post by Paul Hammant
Of course that content-based-storage system isn't a whole FS. That'll take
us back to where we were with some of the ClearCase modes of operaton where
all IO slowed down.  Or worse -  PVCS Dimensions in regular use. It's just
for read only pieces of our build-centric world.

-ph

On Thu, May 18, 2017 at 6:11 AM, Paul Hammant <[hidden email]> wrote:

> You know, I think it would be cool if there were file systems that would
> implement a form of a 'link' as part of a content-based-storage mechanism
> like Git itself.  Meaning if I ran the above git-clone/jar command twice in
> two different directories it would only store the result once (assuming
> idempotence).  Hard and soft links are not it because they need a canonical
> version that the duplicates point to.  What you want is the thing stored
> once, and regardless of the order of deletion, the last deletion means it
> is truly gone.  The Mac's 'alias' feature is closer because it allows you
> to at least move the original/canonical.
>
> Kind of like String.intern(..) in Java.
>
> People are, of course, pushing the file system science in the direction of
> content-based (with dire/filenames a logical overlay).
>
> https://dev.arvados.org/projects/arvados/wiki/Keep
> https://github.com/ipfs/ipfs
> https://en.wikipedia.org/wiki/Content-addressable_storage
>
>
> - paul
>