This week I took a break from coding to write about some non-coding ways I’ve been thinking about to modernize the Subversion project’s communications and reach, and encourage its community.
Here’s a snapshot of “What’s In My Head” copied from Subversion’s Wiki.
In a later post I write about some potential svn code developments in my head.
Ways to modernize the Subversion project’s communications and reach, and encourage its community.
- keep using Open technologies
- keep plain email the baseline standard of communication
- integrate ‘forum’ and ‘mailing list’ forms of access
- integrate long-form and chat-form if possible
- integrate archives / logs, permalinks, searching
Email: Forums and Mailing Lists
Problem: Simple old mailing lists are inconvenient for new and occasional users. They have weak or no integration with their own archives, our issue tracker, etc.
Some proprietary forums e.g. Google groups already attempt to mirror and integrate with our lists, with some degree of success, but we are mainly ignoring it.
should seek to integrate better with forums. For a start: let users
know that it’s an option for them (on our ‘mailing-lists’ web page); and
see if we can make some better steps of integration (such as unified
For a longer term solution, I wonder if any suitable open source software exists, or if an ASF group might consider developing/adapting something.
Chat (IRC, Matrix)
Problem: The IRC chat systems we use
are inconvenient for new and occasional users. They have weak
integration with archives, issue tracker, etc.
Use Matrix as an upgrade path from IRC. That is my strong recommendation.
Matrix is Open, bridges to existing IRC channels, has good UI on mobile and desktop, is simple enough for newbies, has permalinks and can act as an archive, can be self-hosted.
is ready for immediate ad-hoc use by individual participants in our IRC
channels, through the Freenode bridge operated by matrix.org, and is
being used in this way by at least two svn-dev members.
the ASF should run its own Matrix infrastructure: server, bridges, etc.
The ASF would then control its own data, its own user accounts, and its
own integrations with archives, commits, issue trackers, etc. Usability
advantages: use ASF single-sign-on; install specialist
Examples of migration to Matrix in other IRC-based communities: Wikimedia, Drupal
Integrate archives / logs, permalinks, searching
Past communications are scattered across systems and storage locations,
with no consistent archives or permalinks, so cross-referencing is
difficult and non-permanent. Our issue tracker and wiki provide only
links that are tied to their current provider technology.
The types of information include:
important step is to develop a URL “permalink” scheme to refer to our
various resources. These would be technology-ignorant URLs, all under
subversion.apache.org, like “
baby step is the ‘.message-ids.tsv’ file in our web site directory,
holding a mapping from haxx archive URLs used in our web pages to email
message ids, with (in the commit log message) a script to generate it.
There is, as yet, no automation to use the mapping in any way.
- start documenting a URL-space map for our resources
- populate one entry, e.g. “/issue/<number> → issue <number>”
- implement some simple automated handling (e.g. redirects) for that
- well, well… we already have this in our .htaccess which covers that exact case along with some aliases:
"RedirectMatch ^/issue[^A-Za-z0-9]?(\d+)$ https://issues.apache.org/jira/browse/SVN-$1"
- start using it: update existing direct links to point here instead; publicize it
integration: A permalink URL should not merely redirect the user to its
technology-specific target URL, but present the target in such a way
that other inbound and outbound URLs also use the permalink form. With a
big third-party system like Jira or Confluence the feasibility of that
is going to depend entirely on whether the system has built-in support
for that usage.
Subversion packages are outdated or unavailable for many platforms,
especially server/cloud environments (e.g. Docker) and mobile (e.g.
What could we do?
- reach out to individual maintainers and ask if they need any help or just a ping?
- encourage companies to take on packaging (Assembla?)
- make dedicated efforts to establish builds that may be important
Traditional OS / Desktop
(Windows, Linux, BSD, Solaris)
pkgs.org lists the current package versions for many traditional Linux/BSD distributions.
Some companies maintain up to date package builds for several platforms, notably WANdisco & CollabNet.
Cloud / Server / Containers
(Docker, SNAP, VM, etc.)
On Docker Hub the most comprehensive svn server seems to be elleflorio/svn-server (http + svnserve). Next is garethflowers/svn-server (very simple; svnserve only). None seem to be an enterprise-grade installation.
There are no ‘subversion’ or ‘svn’ packages in the SNAP store.
should be able to have functional svn client apps on Android and IOS.
The libs and bindings might be the best focus. The command-line client
won’t so often be wanted, but no reason it should not be available.
For Android, the only open-source client is OAsvn, based on svnkit 1.7.5. It works, but is unmaintained and primitive.
Small / Personal Servers
(Home NAS; Raspberry Pi, etc.; also personal server software platforms like Sandstorm, UBOS, Yunohost, etc.)
Integrations with IDEs etc.
(Visual Studio, Netbeans, IntelliJ, XCode, etc.)
The Svn Book
The authors of the Svn Book no longer maintain it have recently been offering to hand its ownership to the Subversion project.
What should we do with it?
Man Pages and Help Text
built-in help is half way between a summary and a detailed reference.
The Book contains an index which is a variation on this. We never got
around to generating man pages or other formatted help.
- Generate svn help and man pages from common source: there is an old patch as a starting point