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. 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. (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.) This approach has been effectively reversed by what was a killer-feature of Github (I honestly am not sure whether Github was the first to implement it but it was, and arguably is, the most popular): a network of "forks". If a project is hosted using a DVCS, anyone is free to clone it and push their work _elsewhere._ This point is crucial: you do not need to ask the project maintainers to publish your modifications. Github pushed this concept quite far: creating a fork and pushing your work there is actually a device to create a pull request - a request to incorporate your changes into the original project. While this approach has obvious upsides, 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
