Actually, it would be good if you did push the idea. :D I think if
Okay then.. ;-) It's a good discussion anyway..
I think these are all very good arguments for / against svn and git.
I'll just note that I've briefly tested out the Windows git installer, and it is pretty nice. I did get an error during a "clone" operation at one point, which was solved by just doing the same thing on the command line.. (yes, strange, but as you said, alpha.)
Svn is obviously way better than CVS, but I don't really follow the arguments about how Pd is different from Linux. In fact, I see a lot of similarity between pd and Linux:
- a kernel that takes pretty intense "hacking skillz" to understand and efficiently improve - externals that add useful functionality (kernel modules) - satellite projects that make it usable (abstractions)
Honestly I think that the only reason git (or at least, distributed SCM) seems "weird" is because we're all so used to thinking in a centralized way. I'm not at all convinced that a "newbie" would find CVS or Svn somehow easier or more natural than git.
Most of the weird commands in git are intended for doing odd things like retroactively fixing a broken commit or to pull a particular branch from another user's public repo.
Most of the time, git is like this:
git-clone http://some-server/pd-extended.git -- make a local copy of the repo *work work work *... git-commit -m "my fantastic new changes" *work work work*... git-commit -m "more fantastic new changes" git-push (to my public server..)
Oh look there's been a nice update, and they've pulled my changes git-pull *work work work*...
etc.
I'm not claiming there would be no learning curve. But I think there are some advantages.
In any case, as I said previously, using SVN doesn't necessarily rule out being able to use git along with it for those who want to. There is a script, git-svn, which can be used to keep a local git repo in sync with a public Svn repo. So you'd work exactly as I described above, but instead of the git-push command, you'd use git-svn and your Svn repo would be your public repository.
(I haven't tested this much, so it would be worth "trying before buying.")
Of course then you're back to everyone potentially stepping on toes. The thing I like best about it so far, especially since I've only used it on very small projects, is that you can commit many changes before actually publishing them. So you can really think of commits as "semantic building blocks" instead of as "publishing". It separates these two ideas nicely.
Anyways.. hm, also keep in mind there are other distributed SCMs around. There's even one that is more Svn-oriented, called SVK (which I haven't used.) I admittedly only jumped on git because of how it is used for Linux, but also because I've noticed more and more projects taking an interest in it lately. Also I was very attracted to the fact that you can publish your repo on a regular old http server without requiring any kind of special apache module or installing anything. (Since I don't have access to install things on my web server.)
I researched it for quite some time before actually moving one of my projects to it, so I did consider things carefully. So far it's been quite a satisfying move.
Steve