Ways to Delete Messages in a Matrix Federation?

The topic of purging obsolete/old/unwanted content is an important one for the Matrix ecosystem, as for other distributed systems. It’s not easy for developers and users to get our heads around all the desired and possible meanings of removal — from a user selectively removing items just from their own view, through servers garbage-collecting unreachable content, right up to a federation admin asking all servers in their federation to remove content and push that request out to their client apps which might honour the request.

It would be helpful if we could develop or refer to a set of descriptions of the different scenarios, that link the user’s point of view on the one hand to the system/protocol/server point of view on the other hand, with analogies to more familiar technologies like paper mail and email. Probably someone in the distributed systems world has already written this up. What would be very helpful is having some labels/terms/URIs to refer to them.

Without that, we are always going to be asking what a particular “Delete room” or “Delete user” or “Delete message” API or UI button really means. Without that, we are always going to be wrongly guessing what a user or another admin really wants to achieve.

Anybody know of such a write-up that we could borrow?

 

Subversion 1.12 Released

I’m happy to announce the release of Apache Subversion 1.12.0.
Please choose the mirror closest to you by visiting:

https://subversion.apache.org/download.cgi#supported-releases

This is a stable feature release of the Apache Subversion open source
version control system.

SHA-512 checksums are available at:

https://www.apache.org/dist/subversion/subversion-1.12.0.tar.bz2.sha512
https://www.apache.org/dist/subversion/subversion-1.12.0.tar.gz.sha512
https://www.apache.org/dist/subversion/subversion-1.12.0.zip.sha512

PGP Signatures are available at:

https://www.apache.org/dist/subversion/subversion-1.12.0.tar.bz2.asc
https://www.apache.org/dist/subversion/subversion-1.12.0.tar.gz.asc
https://www.apache.org/dist/subversion/subversion-1.12.0.zip.asc

For this release, the following people have provided PGP signatures:

Julian Foad [4096R/1FB064B84EECC493] with fingerprint:
6011 63CF 9D49 9FD7 18CF  582D 1FB0 64B8 4EEC C493
Stefan Sperling [2048R/4F7DBAA99A59B973] with fingerprint:
8BC4 DAE0 C5A4 D65F 4044  0107 4F7D BAA9 9A59 B973
Johan Corveleyn [4096R/B59CE6D6010C8AAD] with fingerprint:
8AA2 C10E EAAD 44F9 6972  7AEA B59C E6D6 010C 8AAD
Stefan Fuhrmann [4096R/99EC741B57921ACC] with fingerprint:
056F 8016 D9B8 7B1B DE41  7467 99EC 741B 5792 1ACC

Release notes for the 1.12.x release series may be found at:

https://subversion.apache.org/docs/release-notes/1.12.html

You can find the list of changes between 1.12.0 and earlier versions at:

https://svn.apache.org/repos/asf/subversion/tags/1.12.0/CHANGES

Questions, comments, and bug reports to users@subversion.apache.org .


— from the announcement email

The Stupidest Things

Dear Rachel, …

my email spell checker stupidly flagging the name of a recipient who is in my address book.

WARNING: VERY HOT WATER

in a disabled toilet in Sheffield Teaching Hospital. I’m reluctant to scald my hands, so what will I do? Or a disabled person or a toddler? So much for teaching hand wash hygiene. (An old thermostatic regulator is visible in the pipework. How hard would it be to repair or replace it?)


Svn Code Developments in my Head

Thoughts on where Subversion should be going, code-wise.

A companion page to What’s In My Head which is about community and project management aspects of Subversion.

General remarks:

  • Progress is slow: attempting to do anything with svn code is slow going. Reasons?
  • Technical debt: low level C code doing business logic, compatibility (almost bug-for-bug) trumps rewrites.
  • Functionality that may not suit all users (diff, patch, merge, externals, keywords, eol-style, WC storage, repo storage, …) has usually been built in, where pluggable interfaces would encourage modularity. Pluggable “diff” is crude, incomplete. Pluggable RA layers are our best example.
  • Writing third-party software that uses Svn is not as easy as it should be. See: Bindings; etc.
  • Companies writing commercial systems do not interact much; how can we improve that?
  • Rewrite clients (svn) and high level libs (libsvn_client) in a more suitable language?

Internal improvements needed:

  • WC APIs. The WC layer needs API that reflects operational units. For example, “a tree in the repository” should function interchangeably as the base of a copy or of a checkout; and “the modifications to a tree”; but not “merge” and “update” which are client level concepts; thus both higher and lower level than current APIs. See: SVN-4786 “WC working-mods editor”, for a start.
  • Diff in particular shows up many inconsistencies due to bitty implementation. Once generic changes APIs are in place, rewrite ‘diff’ to use them: diff(WC, repo): {a=tree_open(WC), b=tree_open(repo); diff_trees(a,b)}.
  • Diff: distinguish “diff a commit” from “diff two trees”.
  • Bindings. State is poor, inconsistent. What’s needed is an OO generic interface, implemented in several languages. An implementation technique: write C++ OO layer on top of existing C API, then wrap it in other languages. Problem: underlying svn API design is not OO. Opportunity: design the APIs we would like to provide; reimplement libs to provide them. See Brane’s current “svncxx” work.
  • Repository API: Eliminate no-op changes.
  • Repository API: Copy content without recording ‘copy-from’.

Feature improvements:

  • Server-side “pull request” merging.
  • Renames. TODO: Write up how my strict element-id scheme (see svnmover) can improve handling renames in update and merge, even in a primitive form without server-side support. To integrate it in existing svn, depends on: WC APIs; rewrite of merge code. Develop a variation where directories are ephemeral, for better real-life semantics (like splitting and joining dirs).
  • Query language (Hg revsets; Paul Hammanthttps://graphql.org/learn/GraphQL).
  • Repo syncing (revprops and locks as versioned/sequenced events; Merkle trees).

General Remarks

Subversion’s client side code is particularly obtuse.

The server side is considerably cleaner. Its user is the network protocols, it is focused on doing its job quickly and accurately, and its API surface is relatively compact and stable. The API semantics are not perfectly clean and the implementation is complicated by a lot of optimization and caching which sometimes introduces bugs, but overall it is a lot better than the client.

Rewrite clients (svn) and high level libs (libsvn_client) in a more suitable language? This code consists of simple logic, filters, configuration, hashes, composition, etc., which in C is tedious, error-prone, inconsistent, contributing to buggy inconsistent UX. Python would make sense for the client itself. For the libs, difficulty is how to provide bindings; C is good base language for that. Rewrite might not make a lot of sense for the existing client, because it has too many idiosyncrasies which would have to be either recreated in excruciating detail or smoothed out losing compatibility. However, a rewrite dropping a lot of oddities and little-used features such as externals might make make a lot of sense if we want a new client for e.g. Android and IOS.

WC APIs

The WC layer needs an API that reflects the granularity and shape of the operations we want to perform on it. Usually these operations are reading or modifying a given subtree to a given depth, with criteria such as selecting items with a certain set of statuses.

When the client commit code is scanning a WC, looking for items to commit according to the user’s given criteria, it should not itself have to iterate over a list of children, deciding which ones fit the criteria, looking up the child’s schedule status and deciding whether to recurse into a subdirectory based on its schedule and other options. Instead it should be able to invoke a suitable tree walker which does all that, and just perform commit processing on each item found. This same tree walker should be shared with other client functions such as diff and shelve that also want to operate on a similar selection.

The base of a checkout and the base of a copy are both “a tree in the repository”, more or less. There should be APIs to put such a tree into the WC storage, read it out, use it as the base of a checkout, use it as the base of a copy, use it as the base of a diff, and so on, and these operations should all use a common, interchangeable “tree” object. At present there is no such “tree” object concept in the APIs, and each of these operations is implemented implicitly by code that is specific to each use case, all different from each other, so that there is no chance of obtaining consistent results and no easy way to spin up a new instance of such behaviour in the implementation of shelving.

To improve this, I plan to create a set of interfaces for accessing the WC and other WC-like data such as shelves. One part of this interface is dedicated to accessing the local modifications that can be committed; this must be compatible with the interface used to commit changes to a repository and read them out. Another part is dedicated to accessing the base state of the WC; this will have something in common with the repository access interfaces too, but also will have notions such as “switched”. A third part is dedicated to accessing the uncommittable WC state such as changelists, conflicts, obstructed, missing, and unversioned items.

For the “committable changes” interface, svn_delta_editor_t is a good starting point as by definition it must support the necessary operations for a commit.

For the “uncommittable changes” interface, something new must be invented, perhaps starting with the WC “status” APIs.

For the “base state” API, the recent experimental “viewspec” output feature built on top of the WC “reporter” shows how we can describe the base state. To that must be added some way of transferring the necessary content. The present implementation directly contacts the repository URL through the RA layer when it needs to fetch base content; this needs to be abstracted out to the new interface.

Subversion’s “copy” operation comprises not just local changes but also a request for a new base subtree to be fetched. Therefore there is some dependency between the “committable changes” interface and the “base state” interface. Either the “committable changes” interface will need to depend directly on “base state” in order to fetch more base content when it needs to, or the caller will need to ensure that the necessary base content has been provided in advance and the “copy” method will need to be able to find it.

WC Tree-of-Changes Walker

(May be needed by: “Revert”, “unshelve”, …)

Need a tree-of-changes walker that visits nodes in a depth-first order with: (1) visit a dir before its children and also afterwards; and (2) visit a replaced subtree twice, once for the delete and then again for the add. Useful especially but not only for WC.

Diff a Commit vs. Diff Two Trees

Repository API: Eliminate No-op Changes

A curse of inconsistency. Some operations in the commit API, such as “open a file”, leave a trace in the FS even if no change in content is made, which then manifests in a similar API method call sequence when the commit is replayed. We often call these “no-op changes”, though “touches” may be more descriptive.

Arguing from a written description of the issue, without concrete details, it has proven hard to convince people that this is a bug: they can argue that storing and retrieving an extra flag that “the object was touched” is a feature. Using two approaches I am confident we can show it is a bug. (1) Show that the behaviour is inconsistent. (2) Argue that the Subversion data model is supposed to be based on stored state, and this amounts to “hidden state”.

  1. There are different potential cases where a no-op change might be considered: open a file and close it, open and apply a null text-delta, copy and apply a null text-delta, change existing property to its same value, delete nonexistent property, etc. TODO: test many cases and report the inconsistencies between them.
  2. There are different methods for information retrieval: list changes, replay revision, delta-dirs, update editor, etc. There are different API levels to try: FS, repos, RA. TODO: test retrieval methods and report the inconsistencies between them.

(2) Data model. In the general model of versioning a series of snapshots of user’s data, we should be able to extract any two stored states and calculate the difference between them, but a “touched” flag does not work like that; it is a function of some hidden state.

Repository API: Copy Content Without ‘Copy-From’

Should be able to:

  • commit a reintegrate merge from WC to repo efficiently, in O(1) time and size.
  • perform a reintegrate merge server-side, in O(1) time and size (new feature)

When committing changes, it is sometimes the case that the target content (of a file, subtree, or branch) is a content that already exists somewhere else in the repository. This is common in merging, where the merged content of a file (or subtree) on the target branch is identical to a content that exists on the source branch. In a reintegrate (or “copy up”) merge, the entire content of the target branch becomes equal to the current content of the source branch.

It is inefficient for the client to transmit changes against its working copy base to recreate the desired content on the server, when in principle it could instead tell the server where else that content may be found.

The existing “copy” method in the editor API copies the referenced content. At the same time it rewrites the history pointer to point to the “copied from” location. What we need is a variant of “copy” which keeps the default “natural predecessor” history.

(There is a “link” method in the FS API, which is not exposed in the RA API. It appears to be somehow related to this. TODO: investigate whether that is of any use.)

Server-side “pull request” merging

Thoughts about Svn Design and Code

A companion page to What’s In My Head.

Some specific code enhancements

  • WC subtree read/write APIs. The WC layer needs API that reflects operational units such as “a tree in the repository” to function consistently as the base of a copy or of a checkout; and “the modifications to a tree”; but not “merge” and “update” which are client level concepts; thus both higher and lower level than current APIs. See: SVN-4786, for a start.
  • Diff in particular shows up many inconsistencies due to bitty implementation. Once generic changes APIs are in place, rewrite ‘diff’ to use them: diff(WC, repo) := {a=open(WC), b=open(repo); diff(a,b)}.

System-level topics

  • Renames
    • My strict element-id scheme (see svnmover) can improve handling renames in update and merge. Write it up, esp. how it can be used primitively without server-side support. To integrate it in existing svn, depends on: WC subtree read/write APIs. Develop a variant where directories are ephemeral, for better real-life semantics (like splitting and joining dirs).
  • Query language
  • Repo syncing
    • The design of repo syncing (svnsync) is incomplete: especially revprops and locks
    • revprops and locks as versioned/sequenced events; Merkle trees?
  • Rewrite high level libs (libsvn_client) and clients (svn) in Python
    • They consist of simple logic, filters, config, hashes, composition, etc., which in C is tedious, error-prone, inconsistent, contributing to buggy inconsistent UX. For libs, difficulty is how to provide bindings; C is good base language for that.
  • OO Bindings
    • Bindings state is poor, inconsistent. What’s needed is an OO generic interface, implemented in several languages. An implementation technique: write C++ OO layer on top of existing C API, then wrap it in other languages. Problem: underlying svn API design is not OO. Opportunity: design the APIs we would like to provide; reimplement libs to provide them.
  • Plug-ins
    • Functionality is built-in first, where pluggable interfaces would be better (diff, patch, merge, externals, keywords, eol-style, WC storage, repo storage, …)
    • example: ‘diff’ plug-in support exists but is weak: want different diff tools for different file types, want to configure an external tool for tree diffs
  • A new ‘svn’ client
    • Consider writing an alternative ‘svn’ client from scratch with consistent functionality built from layers of blocks, not attempting to emulate CVS, and taking inspiration from git/hg/bzr. For example it should provide a function to output a tree (or file) which should encompass all of the existing ‘ svn list’, ‘svn cat’, ‘svn proplist’, ‘svn export’, ‘svn diff -r0:REV’, ‘svnrdump dump’; and a function to input a tree (or file) which should provide the inverse of all of those output modes, encompassing ‘svn propset’, ‘svnmucc put’, the hypothetical ‘svn addremove’, etc.

General observations

Progress seems to be stifled. Why?

  • It’s a “maturing” project with decreasing volunteer activity.
  • Technical debt: low level C code doing business logic, compatibility (almost bug-for-bug) trumps rewrites.
  • Writing third-party software that uses Svn is not as easy as it should be. See: Bindings; etc.
  • Companies writing commercial systems do not interact much; how can we improve that?

Goodbye G+, Hello Matrix and Indieweb

And, poof!, there goes another “walled garden”. Goodbye Google+, I won’t miss you. Rather than jump ship to another silo such as FB, I’ve been getting very interested in non-silo, “own your own digital self” alternatives, sometimes referred to as “re-decentralizing” the Internet because it originally was that way before these monoliths came to dominate it.

The website switching.social suggests “ethical, easy-to-use and privacy-conscious alternatives” to popular sites. I can agree with most of their suggestions. For blogging, there are several lightweight, Open alternatives.

To ensure you keep ownership and control of your next website or blog, there are two requirements:

  1. Connect it to your own domain name (mine’s at blog.foad.me.uk) so you don’t lose control of it and your links don’t break and addresses don’t change when you have to leave your service provider. If you pay someone (like wordpress.com) to run it, you’ll need to pay them for the privilege, as well as registering your domain name in the first place; each of these may be around £1 to £2 a month.
  2. Make sure it’s open source, so it can in practice be set up again somewhere else when your previous service provider shuts down or you need to leave them.

For how to Own your Own Data in terms of blog posts and responses, etc. — see IndieWeb.

For messaging, it’s got to be Matrix. It provides a user experience like WhatsApp and Slack but is Open, so you can choose who runs your server and how much it integrates with other services.

Matrix Big Issues

I’d be very interested to see the Matrix.org team’s list of Big Issues. Here’s mine.

(As someone who runs my own homeserver but otherwise not closely involved with Matrix development. A very sketchy first draft, totally uncomprehensive and unauthoritative.)

Kill off Matrix.org (the server)

The existence of a “central” or “default” server works utterly against the goal of a decentralized system. Some important benefits are obtained from it in the short term, such as building an initial community and real-life testing of the server. However, to ensure the community prioritizes solving the problems of decentralization, there needs to be a goal of killing it off.

Some specific issues:

  • identity decoupling
    • Matrix spec issues: Decentralised user accounts #915 and others referenced from it.
    • I should be able to create an identity that is not tied to a particular homeserver, as that server may not remain suitable for my use, or even survive at all, for as long as I want my identity. The most obvious alternative would be to have my identity tied to a DNS name. DNS is a global identity system on which I can register and control an address, and set up automatic responses to arbitrary queries to that address.
    • Portable identity: Having let one homeserver handle the “account” for my identity, I need to be able to transfer that account to another homeserver. And not just directly; I need to be able to make a backup of that account, and upload that backup to a new homeserver if the previous one becomes unusable.
  •  homeserver discovery
    • Matrix spec issue: Consider options for discovering homeservers on a local network #1444
    • A matrix client should be able to discover a local homeserver when a user is not logged in and has not given a user-id. The client should suggest that the user can register or log in to that homeserver(s) by default instead of matrix.org.
    • To be effective, need to standardize across Matrix ecosystem a mechanism for configuring something on the local network, using maybe DNS-SD or zeroconf/bonjour, to advertise the local homeserver(s).
    • (With Riot-web, local site admin can easily provide it hosted on their own domain and customized to prefer their own homeserver. But for traditional clients distributed via app stores etc that’s not possible.)
    • Note that a “local” homeserver need not be running on a local machine: in many cases it would be running as SaaS somewhere else, but using the domain name of the local network, with the existing .well-known and/or DNS SRV mechanisms to locate it.

URLs for Matrix entities

Matrix spec issue: Do we want to specify a matrix:// URI scheme for rooms? (SPEC-5) #455

It should be possible to address any Matrix user (like “mailto:”), room (to view or join the room), and message (to view a certain message in the channel history) using some sort of URL (or URI or similar).

The scheme MUST identify the entity, at least these:

  • user
  • room
  • message

The scheme MUST provide some way for the entity to be found by Matrix-aware client software, and SHOULD also provide for the entity to be found and displayed by non-aware client software such as a generic web browser.

The scheme SHOULD support requesting an action on the entity.

  • the actioning software would not be obliged to support all actions and should fall back to simply “finding” and displaying some interface to the given entity;
  • examples:
    • join a given room as “myself” (if user following the link is already logged in to Matrix)
    • view a given room’s history
    • send a given message (to given user/room)
    • start composing a new message (to given user/room)
    • invite a given user to join a given room
    • invite the (unspecified) actioning user to register to join a given room
    • invite (given/actioning) user to start a new conversation with given originator

AFAIK such a scheme is in very early “ideas” stage.

matrix.to“, a clumsy work-around, gives some idea of the “problem space”.

Riot

It’s important to have a glossy, popular, widely available client app that competes directly with the likes of WhatsApp and Slack.

  • Looks to me like Riot’s 98% done and has sufficient momentum. Success!

A Non-Messenger Application

To ensure Matrix does not get stuck as just an instant messenger, there should be a concerted effort to have at least one other application domain well served.

For comparison, see how email has evolved into a system that is only really suitable for human-readable messages. It could alternatively have evolved into a system in which automated responders are common and well supported. A few examples exist, for example the “mailman” mailing list server responds automatically to a few simple command messages, but that is far from a world where users routinely plug automation apps in to their email accounts.

Message Format (Mark-Up, etc.)

I am not sure what Matrix messaging should be doing with regard to message formatting.

I’m concerned about the state of mark-up in software systems in general. It’s so …

  • fragmented: umpteen different markup formats at different levels of capability. Every word processor, wiki, instant messaging system, has its own variant. HTML, Open Document, variants of markdown, and mostly unspecified proprietary.
  • incompatible: many systems have partial compatibility at a trivial level (like bold and italics) while completely incompatible at higher levels (e.g. displaying a table, or linking sub-pages into a main page)
  • many conversions, e.g. implemented when you copy and paste, attempt to perform a conversion but exactly what they do is partial, undocumented and unpredictable.
  • open-ended: HTML for example, no limit to the richness it can express, but in the same way it does not express much semantics itself, it is a lower level formatting system, despite the “semantic” emphasis of HTML5. At the same time there are limits to the HTML richness the system will heed, but the limits are seldom stated.

In Matrix / Riot, we seem to have in each message a “plain text” and a “formatted text”, much like email containing both plain text and HTML. In email, we see huge variation in the quality of conversion between plain and HTML, usually poor, and sometimes a plain text that says “If you see this please check the web version instead”.

 

Very exciting to see how Matrix is gearing up to provide a sorely needed Open alternative to the proprietary silo chat systems. This blog post gives a good, long, round-up of how it’s coming along.

https://matrix.org/blog/2018/12/25/the-2018-matrix-holiday-special/

Svn: What’s in my Head

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.

Community

Ways to modernize the Subversion project’s communications and reach, and encourage its community.

Communication technology

General

  • 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.

We 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 permalinks).

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.

Matrix 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.

In future 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 bridges/integrations.

Examples of migration to Matrix in other IRC-based communities: Wikimedia, Drupal

Tasks:

Integrate archives / logs, permalinks, searching

Problem: 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:

An 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 “/issue/1234“.

A 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.

Initial tasks:

  • 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

Deeper 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.

Software Distribution

Problem: Subversion packages are outdated or unavailable for many platforms, especially server/cloud environments (e.g. Docker) and mobile (e.g. Android).

Examples:

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.

Mobile (client)

(Android, IOS)

We 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.)

Documentation

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

The 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.

Tasks:

  • Generate svn help and man pages from common source: there is an old patch as a starting point