Version Control Repositories on alioth

The following thoughts were exchanged during the Alioth Sprint 2017.

Providing "git" with the new development platform is a requirement. Thus only other VCS are discussed below.

Current Usage of different Version Control Systems

Number of repositories:

Some numbers may be inaccurate due to missing non-privileged read permissions on alioth.


gitlab (the new development platform picked during the Alioth Sprint 2017) only supports git for version control. The above usage numbers of other VCS do not seem to justify the hosting of these version control systems on Debian infrastructure. Thus existing users will need to either migrate their repositories to git or move to a different repository hosting.



Number of repositories with most recent change in year:


find /srv/ -maxdepth 1 -type d | while read a; do [ -r "$a/format" ] || continue; printf "%s %s\n" "$(svnlook info "$a" | sed -n 2p | awk '{print $1}')" "$a"; done | sort -n | cut -f 1 -d - | uniq -c

Migration discussion

The participants of the sprint decided to not run other non-git VCS services. Thus the notes below regarding potential hosting concepts are not relevant. But maybe they are interesting for someone else.


Repository Access

HTTP(S): not a problem

Access Control can easily be done with a plain text file ( - this should be acceptable for manual administration.

Disadvantage: only password-based access (http-auth)

SSH+SVNServe: authorization is complicated

The usual trick is to use the --tunnel option of svnserve, and force a command in authorized_keys per user (i.e. a single login user on the server). We could actually re-use the user/team information, taken from gitlab API. (how? Do we want this?)

Problems with this approach:

Web Interface for browsing repositories

(to browse repositories with a web browser)

Options? Most look very old (svn *is* out of fashion)

Good candidate: ViewVC

Proposals for a potential subversion server concept

The two proposals below describe the write access via ssh.

Anonymous read access (for everything, no access control) via https is trivially done via apache2 (bonus: browsing via viewvc).

Both approaches should work reasonably well for the use-case of the current alioth subversion repositories.

Approach A: account == project

Approach B: group == project