Keep in mind, it has been looked into already. And there are steps (e.g. developers have scripts for certain tasks) in the development/release process that need heavy work to be change.
So changing the main repro is a big task (bigger than you would think)
You should probably rewrite all these "old" scripts as the design is bad if it needs svn and cannot run on other directory structures easily.
Yes. Worse, they will have to be significantly enhanced, as GIT's mergetracking is inferior to SVNs.
Nowadays your scripts run automatically if triggered by commit/user action on your Github/Gitlab/Gitee instance.
CVS already had pre/post-commit hooks, such things are already in place for 20 years.
Therefore the release process happens almost automatically and needs only some checks to verify that everything went well. Sure, it might need some time to rewrite your scripts but the benefits of it are totally worth it.
The trouble is that when you actually want to write anything for it, and get stuck (as in said defective merge tracking), all advocates suddenly take a giant step back and only mutter things "you shouldn't want that".
* Pull request easier for the developer than patches?
Well not for me.
I already work with git, on my local pc, and applying a patch and comparing it in git is as easy as looking at a pull request.
I should say that for me, the online interface to compare pullrequests is no good (So my feedback comes by mail, no annotations via the online interface). I always pull the requests to my local repro, and compare them locally.
So patch/pull requests, is the exact same amount of work to me.
The very small commits are not the problem anyway. So that benefit is definitely not for the developer. Maybe for the submitter, but more often than not that ease is paired with a dropping of submission quality (like people reformatting/renaming/recasing). An extreme is the
serbod chm repository, which took me several evenings to mine anything from it. The fixes were good, but it was totally unusable, and couldn't be submitted piecemeal.
Too many unexperienced developers (either in absolute terms, or just inexperienced in working in teams where they don't call the shots), just go ahead, and only at submission time they start thinking. That is a big problem with any VCS, and it won't be solved by a sliver of web over it.
It is an issue of spirit of teamwork/cooperation, and that is not fixed by tools.
It depends on your view and workflow but in general it's easier to accept small patches like this, this or that one. There is not really a need to check it out locally as the review process can happen directly through your browser (additionally with CI you and the contributor see directly when creating the PR if it breaks something).
(Personally I prefer a good diff tool over the webjunk, CI per request takes too long for trivial changes. CI is a good principle, but not universal)
With hub a contributor don't need to leave the console at all to fork and create a pull request. The reviewer can also comment on specific lines and give suggestions, advices or hints.
In my opinion these things are big advantages for both - reviewer and contributor - compared to the current workflow with issues/patches.
Note that those are just fixing of problems of GIT that makes simple patch creation apparently difficult.
* More contributors?
I agree that moving to e.g. Github won't bring 100 new developers but it will bring some publicity (blogs could write about the move) and that might lead to a few people who try it out and might stick to it. And after some time they might start to add their "missing feature".
I don't expect it to. Interested people will find a project, and are usually searching for live content, rather than autogenerated pages. We do bad there too (as in updating websites etc), but that won't change on github.
Recent
