SoylentNews is people
SoylentNews
from the where-will-they-store-the-source-code? dept.
Chris Ball, about whom I know very little, gave a talk to the Data Terra Nemo conference on 23/24 May in Berlin. From the conference site, I gathered the following: "Data Terra Nemo is a technical conference for discussing the ideas behind systems and protocols without centralized ownership and how they impact the landscape of the Internet".
Chris gave a presentation regarding a decentralized git repository which he has dubbed 'GitTorrent'. His notes, which he describes as an 'aspirational transcript' of the talk, take the story up:
Why a decentralized GitHub?
First, the practical reasons: GitHub might become untrustworthy, get hacked — or get DDOS'd by China, as happened while I was working on this project! I know GitHub seems to be doing many things right at the moment, but there often comes a point at which companies that have raised $100M in Venture Capital funding start making decisions that their users would strongly prefer them not to.
There are philosophical reasons, too: GitHub is closed source, so we can't make it better ourselves. Mako Hill has an essay called Free Software Needs Free Tools, which describes the problems with depending on proprietary software to produce free software, and I think he's right. To look at it another way: the experience of our collaboration around open source projects is currently being defined by the unmodifiable tools that GitHub has decided that we should use.
So that's the practical and philosophical, and I guess I'll call the third reason the "ironical". It is a massive irony to move from many servers running the CVS and Subversion protocols, to a single centralized server speaking the decentralized Git protocol. Google Code announced its shutdown a few months ago, and their rationale was explicitly along the lines of "everyone's using GitHub anyway, so we don't need to exist anymore". We're quickly heading towards a single central service for all of the world's source code.
So, especially at this conference, I expect you'll agree with me that this level of centralization is unwise.
The talk continues in the first link at the start of this summary.
Original Submission
(Score: 1, Interesting) by Anonymous Coward on Sunday May 31 2015, @03:16AM
(Choosing Washington because I live in the USA; of course it could probably be any large country).
Every so often one of the two parties seizes the intellectual initiative and captures the attention of the media and the press. The Democrats did it with Obamacare; then GOP responded with the Tea Party. Years later, the Democrats came back with Gay Marriage, etc. Like the saying "no publicity is bad publicity", it's not so much whether you're right or wrong as whether you're able to grab the podium and the national stage.
That's what GitHub did. Git was the darling VCS, so SVN was the "legacy" tool. Even though Git is really most appropriate for huge sprawling projects like the Linux kernel, and SVN does quite well for most other projects.
(Score: 5, Informative) by NCommander on Sunday May 31 2015, @03:32AM
I'd agree with this except for the fact having using both SVN and git heavily over the course of years, SVN's branching and merging support is not much better than CVS in many ways. Git on the other hand makes it trivial to merge multiple independent branches togethers, figure out who did what, and help keep patches across multiple trees (we've got some patches going across slashcode and rehash right now). I've also use bzr (and to a much lesser extent, hg), and neither is as good at git at handling branches and stuff. bzr is basically decentralized SVN. hg is fast, but it seems a bit clumsy to merge from multiple heads.
Still always moving
(Score: 0) by Anonymous Coward on Sunday May 31 2015, @03:49AM
(sighs)
I guess I'll have to spend more time learning git then.
(Score: 3, Interesting) by MichaelDavidCrawford on Sunday May 31 2015, @04:08AM
all those long strings of hex digits, guids or some such.
Yes I understand there is some point to them but they also make git quite unpleasant for me to use. With subversion I can just look for things like "commit 42".
Yes I Have No Bananas. [gofundme.com]
(Score: 3, Informative) by pe1rxq on Sunday May 31 2015, @12:40PM
man git-tag
(Score: 2, Insightful) by Anonymous Coward on Monday June 01 2015, @07:38AM
You are mistaken. I chose Git for my personal projects because CVS, SVN, etc are too heavy for simple hobby use. They require a server, and while Linux can multitask just fine, so "server" doesn't necessarily mean hardware, that still means somebody needs to set up the bloody thing. Yes, there's probably a howto for that. I tried to read the one for CVS, probably fell asleep on the first page. SVN is even worse, it runs as an Apache module, so now not only do I need to hire an SVN administrator, I also need somebody who can configure Apache securely. My personal web server does not run Apache because Apache is too complex.
Setting up git for a hobby project is as simple as
cd projectdirectory
git init
Done.
No servers needed, no separate user accounts, no nothing. And if I should decide to publish the repository, I can use any web server (even IIS), no modules needed. Git push to such a repository is done via SSH (usually), with no additional setup.