Contents
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:
- CVS: 561 (details below)
- Subversion: 516 (details below)
- Bazaar: 56 (only "pkg-bazaar" was active in 2017)
- Mercurial: 29 (last changes in 2014)
- Darcs: around 4 (all of them seem to have moved away)
Some numbers may be inaccurate due to missing non-privileged read permissions on alioth.
- Conclusion
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.
CVS
- three active repositories in 2017:
- webwml
- pkg-upslug2
- pkg-octave
- some repositories were not browseable without privileges (100 out of 561), thus the above list of active repositories may be incomplete
Subversion
Number of repositories with most recent change in year:
- 8 2003
- 18 2004
- 38 2005
- 57 2006
- 42 2007
- 54 2008
- 49 2009
- 40 2010
- 33 2011
- 30 2012
- 28 2013
- 26 2014
- 13 2015
- 25 2016
- 55 2017
Source:
find /srv/svn.debian.org/svn/ -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.
Subversion
Repository Access
HTTP(S): not a problem
Access Control can easily be done with a plain text file (http://svnbook.red-bean.com/en/1.7/svn.serverconfig.httpd.html#svn.serverconfig.httpd.authz) - 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:
- fine if there is a single repository per user
what if a user accesses multiple repositories? (different svnserve -r ... instances are not possible with a single ssh key)
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
- Language: Python
- packaged in Debian
- seems maintained (at a glance)
- needs filesystem access
- can actually handle CVS as well
- probably needs to be checked and tuned a bit, security wise (path disclosure on invalid paths, etc)
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
- processes:
- new project: create a local account
- assign user to project: manually add ssh key to the authorized_keys file
- each ssh key contains the following information:
- svn username ("committer") - via environment
- Repository path (parameter for svnserve in "command")
- write access is based on the user (owner of the repository path)
- advantages:
- quite simple
- non-DD may take part
- disadvantages:
- user may need to submit the same ssh key multiple times for multiple projects
Approach B: group == project
- processes:
- new project: create a local group
- assign user to project: manually add the (ldap) user to the local group
configure via sshd (?ForceCommand") that (e.g. all non-root) users are running svnserve (e.g. with "-r /svn")
- this results in read-only access for all users to all repositories
- write access is controlled via unix permissions (based on the group, g+w permissions)
- advantages:
- ssh keys from ldap are re-used
- the only manual process is group management (create group, assign user to group)
- disadvantages:
- non-DDs require manual key entry in the authorized_keys (can't be taken from ldap)
Announcements
- two drafts for announcements regarding the future of version control system are preprared as gobby documents