Industrywide breakthrough innovation - Git as a key role of distribution

Industrywide breakthrough innovation - Git as a key role of distribution

[Kalle Launiala]

Respectful Git mailing list readers.

I was encouraged to "Ask the Git community directly" as is writtein
the www.git-scm.com site.


== Disclaimer

This is not a trolling post or suggestion of something that is not
finished. The technology that I'm "lightly" referring as industry
breakthrough exists. I just happened to find out that Git (alongside
with social coding sites such as Gitorious and GitHub) already fills
up the repository and distribution technology that the "abstractions"
require.

Please do not let the current platform examples fool you; our
technology base was on Microsoft's stack, yet this technology is
totally platform agnostic. This however means that the material is
nonexistent on Linux technology demos (although there are solid
demonstrations available for Microsoft's stack).

I have tried to approach Linux community (through Linux Foundation,
LDN and finally www.linux.com, but I have failed to meet any
centralized point to help us figure out Linux development - we know
our technology, but we need help getting reference implementations on
Linux common languages to be able to abstract them).

== End of Disclaimer.


Now in brief; I claim that software development can be trivialized
(and its efficiency boosted) to absolute maximum. The technology is
ridiculously simple stack on top of existing technologies (it's
moreover a methodology).

It is by its very nature completely open and completely free, platform
agnostic. Usable by anyone; learning curve is really simple
(considering the learning includes understanding how to define the
architectural design and include reference implementation within it).

The thing that Git solves perfectly is described in this visualization:
http://abstraction.codeplex.com/wikipage?title=Subscribing%20to%20Reference%20Abstractions&referringTitle=Documentation

The full technology case theory, key differentiators and examples
(although light with videos) can be found:
http://abstraction.codeplex.com/documentation

The absolutely trivialized software development is presented in the
documentation's first link's video followed by visualization of
multilevel abstraction stack - I know this does not open properly
without any hands-on experience on abstractions.


I am very willing and happy to discuss how this can be applied to
Linux (both applications and kernel) development, as it is applicable
to anything that needs documentation and structured implementation of
any size. This technology brings Linux in-par and way beyond of
Windows in end-developer experience; and allows huge advantage in
Linux because of its versatility (that no longer needs to be
sacrificied for solid-base for developer experience).


However in this post I am simply asking help to understand Git
properly, so that I can design the distribution mechanism (updating
both ways) and for example understand the way of making statistical
calculations (so that any individual abstraction-provider can be
ranked in terms of follow-up "repository forks").



Please apologize my newbieness in mailing lists and groups, as I have
just entered the world of open-source-development.


Happy spring from Helsinki, Finland,

Kalle Launiala

Getting started with git

[Jonathan Nieder]

Hi!

Kalle Launiala wrote:

> [Subject: Industrywide breakthrough innovation - Git as a key role of distribution]
[30 lines of filler]
> == End of Disclaimer.

Please don't do that.  Most of your audience isn't going to get
past that.

> However in this post I am simply asking help to understand Git
> properly

Are you a programmer?  I'd recommend starting with

 http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html

and moving on to

 http://www.kernel.org/pub/software/scm/git/docs/gittutorial-2.html

and

 http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#hacking-git

Hope that helps,
Jonathan

Re: Industrywide breakthrough innovation - Git as a key role of distribution

[Marc Weber]

Hi Kalle Launiala,

> However in this post I am simply asking help to understand Git
> properly,

You should start your mail with the most important request top (like
newspapers do).
I feel that could have been tha sentence which should have been top.

I wrote this mail because I saw your mail - I even clicked on your
links - but it didn't make any sense to me previously.

Marc Weber

Re: Industrywide breakthrough innovation - Git as a key role of distribution

[Randal L. Schwartz]

>>>>> "Marc" == Marc Weber <marco-oweber@gmx.de> writes:

Marc> I wrote this mail because I saw your mail - I even clicked on your
Marc> links - but it didn't make any sense to me previously.

This one didn't make much sense either. I had to read it three times to
even begin to contemplate "what action am I being asked to do?".

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion

Re: Industrywide breakthrough innovation - Git as a key role of distribution

[Junio C Hamano]

merlyn@stonehenge.com (Randal L. Schwartz) writes:

>>>>>> "Marc" == Marc Weber <marco-oweber@gmx.de> writes:
>
> Marc> I wrote this mail because I saw your mail - I even clicked on your
> Marc> links - but it didn't make any sense to me previously.
>
> This one didn't make much sense either. I had to read it three times to
> even begin to contemplate "what action am I being asked to do?".

You read it three times?  You have too much time on your hand....

Re: Getting started with git

[Kalle Launiala]

Hello!

Thanks for the links of overall programmer requirements, been reading
such so far as well. The hacking guide was fresh compared to what I
discovered.

Now the reason of specific detail understanding of the Git was to use
it on wide-range software-code-block distribution. I would like to
know if the following scenario either will "blow up" something or has
some other anti-Git patterns hidden inside.

1. Git repositories vs. "traditional" branch/merge

Within the current spec, we have identified "branching/merging" that
is VCS supported conflict management only feasible option. With Git
this seems to turn to forked/linked independent repositories; this
seems the best option. Every independent software-block would have an
independent root-repository of its own.

Any reason why Git would be using branching at all in distributing
between-project data, even when in traditional VCS they would be
within same repository?

2. Scalability, when having tiny repositories that are chained to the
end-developer

Basically none of the "bottom" is going to push back any changes, so
they're effectively just readers, and also from the nearest
repository; the repository syncing (while likely can be automated out)
will go with normal pulls. I'm not worrying about "seconds to pull",
but moreover is there something architectural structure, that will
cause single-bottleneck.

Is there any scalability issue, if there are say 10 levels from root
repository to the end-user-bottom (in between various feature-adding
or modifying tailoring), and total number of children of the bottom
level grows to hundreds of thousands?


3. Distribution of catalogues, registering "Abstractions"

Registering of new "Abstractions" from any provider (be it major
organization or single consultant) would be dealt with specific
"distribution" repository chain. Pushing the "Registration Request"
within the catalogue would be fullfilled by validating the data in the
claimed repository. The format of the data is strongly schema based
XML all the way. The openly used "root" catalogue would be synced
globally (daily or so, not immediatelly); the dedicated "private" or
other independent catalogue providers would be in charge of their
policies.

Are there any experience on this kind of use for Git?


4. Handling "private" catalogues; repository access filtered with
client-access-control

Private catalogues would be handled in a way, that their
existence/registration would be standard-pushed up to the chain.
However all the information of their data and their content would be
contained only within the repository. Hence, only the clients that
have the access to connect to the repository could fetch the actual
catalogue of information. They would cache their catalogues with same
manner as would the root catalogue.

Even if the clients would get improper private entires in their
connection lists, they would only get any real information out, if
their credentials authorized on the target repository.

Any blockers that come in mind with this?


Kalle