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
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
These binaries are not meant for production use.