Industrywide breakthrough innovation - Git as a key role of distribution

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

Hi!

Kalle Launiala wrote:

[30 lines of filler]

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

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

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

Hi Kalle Launiala,

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

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?".

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

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