The svn2git section contains a number of repositories automatically converted from the puredata SVN repository at sourceforge.

They are browsable and can be cloned directly from the webpage. however, these repos are meant as starting points, so we do not provide any write access. So once you forked, push to your own server (or gitlab, github, sourceforge, you name it) and let us know.

The process is documented (a little bit) by the scripts used, but some parts of the migration had to be done manually (namely the selection of the paths to base the various libraries on; and the merging/re-rooting of repositories with independent branches).

An automated, history preserving, migration of the current SVN directory into multiple git repositories, one for each library.

If anybody who wants to start working on any of the pd-repo libraries uses the same git repo as root, it is trivial to merge those changes back together. So using those repositories as starting point, should make collaboration between independent devs a lot easier (compared to, when everybody does their own conversion, or just starts off wherever they think).

I tried to capture as many libraries as possible (even those that had been removed from the svn a while ago). I tried to only include "libraries" (addons, plugins), regardless of whether they are "abstractions", "externals", "scripts" or "gui-plugins".

libraries that were only included via svn:externals (thus hosted on different servers). This is mostly, Gem, GridFlow and grrrr. Also some other libs that were not maintained on the svn but where only added/removed a few times (without adding any real history): these turned out to be too much of a hazzle for little value.

I did not discriminate between the two. A few libraries were split on the two directories (e.g. abstractions/footils and externals/footils) and I have taken the liberty to re-combine them ("footils.git" contains both abstractions and externals)

svn2git migration wise, probably not too much. However, I haven't really checked the resulting repositories (apart from generic sanity), so there might be bugs in the migration script itself.

Please report any problems with the repositories via GitHub tickets.

The deployment section contains a repository that allows you to get automatically built binaries for Gem (and probably others).

The binaries are automatically produced via continuous-integration whenever a new change is pushed to github. These binaries are not meant for production use.