> There was an internal discussion about the possible merits of switching to git to increase user contributions. That's a great discussion for a FLOSS project

> There was an internal discussion about the possible merits of switching to git to increase user contributions. That's a great discussion for a FLOSS project to have. It makes me think of a broader issue of how to judge whether or not to devote time to contributing to a given project. Here's the logic I'd use as a reference case for making that decision. Hopefully others agree, or if not have some feedback for my course of thought... The two reasonable initial branches to take in a discussion of changing the repo tech are a) that increased contributions are an important priority for the project at this time, or b) they are not. If consensus is they are not, there is little reason to discuss switching to git (or at least no urgency in this context). If it is a priority, then there there are two obvious follow-ups: a) whether changing to git would even increase contributions to a significant level, and b) the cost of switching to git. These are the obvious follow-ups because a) git is wildly popular with an enormous knowledgebase accessible in the usual places, and b) git is stable, actively maintained, and has lots of stable, actively maintained tooling around it. As a side-note, I can think of an unlikely yet possible objection: that the popular usage of git has a design flaw that causes data corruption, catastrophic usability issues, or security problems that are trivially avoided with other stable, actively-maintained software. But outside of that, it seems to me a healthy functioning project would focus their attention on the branches I outlined above. A nice side-effect of such focus is that a community could quickly make a decision (e.g., "too costly for too little gain atm") without stepping on toes or closing themselves off from future discussion. (Alternatively, they could spend more time and even take a more assertive position, but again without starting flamewars or unduly closing off future possibilities.) To me, any of these branches seem like a sign of a functioning developerbase that is minimally welcoming from an outsider's perspective, and not so likely to waste new developer's time. > On Sun, Feb 26, 2017, at 14:59, Poul-Henning Kamp wrote: > It is fundamentally wrong to ask "SVN or Git ?" I'm stuck here. I can't figure out how this could be a relevant branch to take in such a discussion, nor how a project could have a leader who so casually takes this branch. Keep in mind one obvious branch I mentioned above was consensus on a desire to increase contributions. Even if that isn't a priority now, it's always a potential priority in the near future. But now if that ever becomes the consensus, the project will have an immediate inescapable conflict because everyone knows a leading dev doesn't even think git is a VCS. And even without a leader opining, someone is going to reference this obscurantist notion that git and SVN cannot be compared. Remember the time so-and-so wrote that screed, and do we agree with it it? It's a guarantee of wasted time, both now and more importantly in the future of the project. Honestly, I find the quoted message fascinating wrt the history of version control in FreeBSD. I can see why the author keeps coming back to it. But as part of a FLOSS dev-process it looks quite dysfunctional to an outsider. If I make a suggestion to switch from SVN to git in order to increase contribs, the response should not feel like it was chosen by spinning a roulette-wheel of obscurantist responses. (And even then, the obscurantist response probably shouldn't alienate the entire userbase of Github.)