* Industrywide breakthrough innovation - Git as a key role of distribution
@ 2011-03-20 21:08 Kalle Launiala
2011-03-21 13:59 ` Getting started with git Jonathan Nieder
2011-03-21 14:12 ` Industrywide breakthrough innovation - Git as a key role of distribution Marc Weber
0 siblings, 2 replies; 6+ messages in thread
From: Kalle Launiala @ 2011-03-20 21:08 UTC (permalink / raw)
To: git
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Getting started with git
2011-03-20 21:08 Industrywide breakthrough innovation - Git as a key role of distribution Kalle Launiala
@ 2011-03-21 13:59 ` Jonathan Nieder
2011-03-22 0:21 ` Kalle Launiala
2011-03-21 14:12 ` Industrywide breakthrough innovation - Git as a key role of distribution Marc Weber
1 sibling, 1 reply; 6+ messages in thread
From: Jonathan Nieder @ 2011-03-21 13:59 UTC (permalink / raw)
To: Kalle Launiala; +Cc: git
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Getting started with git
2011-03-21 13:59 ` Getting started with git Jonathan Nieder
@ 2011-03-22 0:21 ` Kalle Launiala
0 siblings, 0 replies; 6+ messages in thread
From: Kalle Launiala @ 2011-03-22 0:21 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Industrywide breakthrough innovation - Git as a key role of distribution
2011-03-20 21:08 Industrywide breakthrough innovation - Git as a key role of distribution Kalle Launiala
2011-03-21 13:59 ` Getting started with git Jonathan Nieder
@ 2011-03-21 14:12 ` Marc Weber
2011-03-21 15:37 ` Randal L. Schwartz
1 sibling, 1 reply; 6+ messages in thread
From: Marc Weber @ 2011-03-21 14:12 UTC (permalink / raw)
To: git
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-03-22 0:21 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-03-20 21:08 Industrywide breakthrough innovation - Git as a key role of distribution Kalle Launiala
2011-03-21 13:59 ` Getting started with git Jonathan Nieder
2011-03-22 0:21 ` Kalle Launiala
2011-03-21 14:12 ` Industrywide breakthrough innovation - Git as a key role of distribution Marc Weber
2011-03-21 15:37 ` Randal L. Schwartz
2011-03-21 17:28 ` Junio C Hamano
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).