Re: About GIT Internals

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Mon, May 30 2022, Konstantin Khomoutov wrote:

> On Mon, May 30, 2022 at 09:49:57AM +0000, Kerry, Richard wrote:
>
> [...]
>> > > 1. I haven't had the experience of working with other (perhaps even
>> > > older) version control systems, like subversion. So when refering to
>> > > the "control" aspect,
>> > 
>> > The "control" aspect was from whoever was the 'manager' that limited
>> > access to the version system (i.e. acting like a museum curator), and deciding
>> > if your masterpiece was worthy of inclusion as a significant example of your
>> > craft, whether that was an engineering drawing or some software code.
>> 
>> I'm not sure I get that idea.  I worked using server-based Version Control
>> systems from the mid 80s until about 5 years ago when the team moved from
>> Subversion to Git.  There was never a "curator" who controlled what went
>> into VC.  You did your work, developed files, and committed when you thought
>> it necessary.  When a build was to be done there would then be some
>> consideration of what from VC would go into the build. That is all still
>> there nowadays using a distributed system (ie Git).  Those doing Open source
>> work might operate a bit differently, as there is of necessity distribution
>> of control of what gets into a release. But those of us who are developing
>> proprietary software are still going through the same sort of release
>> process.  And that's even if there isn't actually a separate person actively
>> manipulating the contents of a release, it's just up to you to do what's
>> necessary (actually there are others involved in dividing what will be in,
>> but in our case they don't actively manipulate a repository).
>
> I think, the "inversion of control" brought in by DVCS-es about a bit
> differet set of things.

Re the "I'm not sure I get that idea" from Richard I think his point
stands that some of the stories we carry around about the VCS v.s. DVCS
in free/open source software was more particular to how things were done
in those online communities, and not really about the implicit
constraints of centralized VCS per-se.

Partly those two mix: It was quite common for free software projects not
to have any public VCS (usually CVS) access at all, some did, but it was
quite a hassle to set up, and not part of your "normal" workflow (as
opposed setting up a hoster git repository, which everyone uses) that
many just didn't do it.

> I would say it is connected to F/OSS and the way most projects have been
> hosted before the DVCS-es over: usually each project had a single repository
> (say, on Sourceforge or elsewhere), and it was "truly central" in the sense
> that if anyone were to decide to work on that project, they would need to
> contact whoever were in charge of that project and ask them to set up
> permissions allowing commits - may be not to "the trunk", but anyway the
> commit access was required because in centralized VCS commits are made on the
> server side.

We may have tried this in different eras, but from what I recall it was
a crapshoot whether there was any public VCS access at all. Some
projects were quite good about it, and sourceforge managed to push that
to more of them early on by making anonymous CVS access something you
could get by default.

But a lot of projects simply didn't have it at all, you'll still find
some of them today, i.e. various bits of "infrastructure" code that the
maintainers are (presumably) still manually managing with zip snapshots
and manually applied patches.

> (Of course, there were projects where you could mail your patchset to a
> maintainer, but maintaining such patchset was not convenient: you would either
> need to host your own fully private VCS or use a tool like Quilt [1].
> Also note that certain high-profile projects such as Linux and Git use mailing
> lists for submission and review of patch series; this workflow coexists with
> the concept of DVCS just fine.)

I'd add though that this isn't really "co-existing" with DVSC so much as
using patches on a ML as an indirect transport protocol for "git push".

I.e. if you contributed to some similar projects "back in the day" you
could expect to effectively send your patche into a black-hole until the
next release, the maintainer would apply them locally, you wouldn't be
able to pull them back down via the DVCS.

Perhaps there would be development releases, but those could be weeks or
even months apart, and a "real" release might be once every 1-2 years.

Whereas both Junio and Linus (and other linux maintainers) publish their
version of the patches they do integrate fairly quickly.

> [...] it also has possible
> downsides; one of a more visible is that when an original project becomes
> dormant for some reason, its users might have hard time understanding which
> one of competing forks to switch to, and there are cases when multiple
> competing forks implement different features and bugfixes, in parallel.
> One of the guys behind Subversion expressed his concerns about this back then
> wgen Git was in its relative infancy [2].
>
>  1. https://en.wikipedia.org/wiki/Quilt_(software)
>  2. http://blog.red-bean.com/sussman/?p=20

It's interesting that this aspect of what proponents of centralized VCS
were fearful of when it came to DVCS turned out to be the exact
opposite:

    Notice what this user is now able to do: he wants to to crawl off
    into a cave, work for weeks on a complex feature by himself, then
    present it as a polished result to the main codebase. And this is
    exactly the sort of behavior that I think is bad for open source
    communities.

I.e. lowering the cost to publish early and often has had the effect
that people are less likely to "crawl off into a cave" and work on
something for a long time without syncing up with other parallel
development.