repocafe - self-service for svn hosting
Repocafe helps admins and users to manage subversion repositories.
Admins can easily set up svn hosting.
Users can create repositories and manage access rights, using a web application.
Authentication is ldap based, but guest accounts can be created as well.
Central to a repocafe installation is the config file. It is used by the web application, and all setup- and support scripts.
Creating a config file is the biggest part of setting up a repocafe.
The default locations of the config file are :
A config file looks like this :
+-------------------------------------------------- |# lines that start with '#' are comment |# blank lines are ignored too |# tabs are replaced by a space | |# the config entries are 'key' and 'value' pairs |# a 'key' begins in column 1 |# the 'value' is the rest of the line |somekey part1 part2 part3 ... |otherkey part1 part2 part3 ... | |# keyword EMPTY represents the empty string ; |# in the next line some_key's part2 is set to '' |somekey part1 EMPTY part3 ... | |# indented lines are glued |# the next three lines mean 'somekey part1 part2 part3' |somekey part1 | part2 | part3 | |# lines starting with a '+' are concatenated |# the next three lines mean 'somekey part1part2part3' |somekey part1 |+ part2 |+ part3 | |# lines starting with a '.' are glued too |# don't use a '.' on a line by itself |# 'somekey' gets the value "part1\n part2\n part3" |somekey part1 |. part2 |. part3 +--------------------------------------------------
In some places in the config (so indicated below) you can glue a
``string with spaces'' into one part by replacing spaces with
underscores as in string_with_spaces.
Specify the full pathname of the admin tree.
dir_admin /path/to/admin-tree
Specify the full pathname of the www tree.
dir_www /path/to/www-tree
Specify the full pathname of the directory where the data lives.
dir_data /path/to/data-tree
The data directory is created by setup-data in the setup phase.
It contains subdirectories admin, archive, logs and repos.
Specify the name of your organisation ; this will be embedded in the user documention, so an url is fine.
organisation <a href="http://www.my.org">my organisation</a>
Specify the hostname of your database server
db_host pghost.some.name.org
Specify the name of the database where the repocafe tables live.
See db_pref below.
Specify the username for the database connections in applications.
Specify the password for the database connections in applications.
Specify the uid (name or number) of the user who owns the files in the admin tree and the www tree. This information is used only in the setup-scripts.
Specify the gid (name or number) of the admin_user. This information is used only in the setup-scripts.
Specify the uid (name or number) of the apache httpd run-user (APACHE_RUN_USER). All files created by the httpd (including the repositories, logs etc) will be owned by this uid. This information is used only in the setup-scripts.
Specify the gid (name or number) of the www_user (APACHE_RUN_GROUP). This information is used only in the setup-scripts.
Specify the name of your web server
www_server repocafe.science.uu.nl
Specify a long, secret (random) string ; this secret is used in the web applications to checksum the contents of sessions, protect plots from prying eyes etc.
www_secret jlsadywr4n8sdydf8wery
Your secret should be random, and at least 16 characters long.
Specify an email address, so users can contact the svn-admins.
www_contact svn-admins@my.org
This address is also used in (the default for) the From:-line of
mail sent to guests ; see mail_from_admin.
Specify one or more user classes. When a user attempts to login, the clas-lines are tried in turn to verify the user's username and password. The line that succeeds, determines the logged-in user's class.
The description should describe the user class (staff, students, sales, marketing). Write blanks as underscores to make it a single string. The descriptions are shown on the login page, and should explain which users should use what username/passwd. The default for description is the configured class.
For an ldap user class, the ldap server, identified by ldap-tag, is queried anonymously. If/when a DN is returned, it is matched against pattern. If it matches, an authenticated bind is done. If it succeeds, the user is authenticated. Use optional config entry ldap to configure ldap-servers.For the guests user class, a database table lookup is done. If it succeeds and the password matches, the user's class is 'guests'. If you want guests, copy this line into the config:
clas guests table repo_guests login passwd name
The extra parameters (table, repo_guests, login, passwd, name) are there for possible future enhancements.
A simple setup would be :
ldap myldap ldap.your.org ou=people,dc=my.org,dc=nl usual clas guests table repo_guests login passwd name clas user ldap myldap ,ou=people my.org_users
You have guest accounts, and one class of ldap users. The login page says :
guests : use the login/password we sent you
my.org users : use your usual login/password
A more complicated example :
ldap sci ldap.science.uu.nl dc=science,dc=uu,dc=nl solis-id/password ldap art ldap.arts.uu.nl dc=arts,dc=uu,dc=nl arts.uu.nl_id
clas guests table repo_guests login passwd name clas sci ldap sci ou=staff,ou=users science_staff clas edu ldap sci ou=students,ou=users science_students clas staff ldap art ou=people,ou=staff arts_staff clas students ldap art ou=people,ou=students arts_students
Here we define two ldap servers, one for 'science' (with usernames known as solis id's) and one for 'arts' (with arts.uu.nl id's).
We have five user classes: guests, science staff and students, arts staff and students.
Specify one or more tree-lines. It describes how actual repository
names are structured. Field user-classes is a (possibly empty)
comma-separated list of user classes (eg staff,students).
When a user creates a repository, he/she supplies an alpha-numeric name for the repository. Optionally, this name is prefixed with a tag that depends on the user's class and/or username. For instance, if you want staff repository names to be prefixed with 'stf', and student's repository names with 'edu', you specify
tree stf %p staff tree edu %p student
If you want student's repository names prefixed with 'edu.loginname', you specify
tree edu %p.%o student
Admins can create repositories in all trees ; if no user-classes are specified in a tree-line, users are told repositories in that tree can be created on request. You configure :
tree <path> <prefix> EMPTY
For a simple, flat namespace, specify
tree EMPTY EMPTY clas1,clas2,clas3
where keyword EMPTY represents the empty string and clas1,clas2,clas3
sums up the user classes that may create repositories.
The name of a repository will be the name supplied by
the owner/creator of the repository.
In general, each tree-line specifies which user classes can create repositories prefixed with the given path. The actual repository names are generated by substituting, in the given prefix, the given path for '%p' and the username of the creator for '%o'.
Caveat: Once you configure a certain tree layout, you can't change or remove a tree-line, if/when repositories in that tree have been created. The actual file path of a new repository isn't saved in the database after creation. Instead, the pathname is recomputed each time when needed, based on tree, owner and name and the config file. So, if/when the (user or tree) config changes, we can't compute the proper repo's pathname from the info in the database. Hm, a quick fix seems obvious. However, the best solution would be to put user/tree stuff in the database and under application control, so a change in 'config' could result in a proper 'renaming' of repo's.
Optionally specify the classes of users that may create guests.
create_guests staff
If only admins may create guests, don't specify create_guests
or configure
create_guests EMPTY
If you don't have package viewvc installed (yet), configure
no_viewvc
to get rid of the (non-working) viewvc-urls in the web pages.
If you don't want your repocafe to have groups, configure
no_groups
Optionally specify a message-of-the-day which will be displayed prominently on every page.
Optionally specify one or more ldap-hosts that can authenticate users. When a user attempts to login, the ldap-hosts are queried, using base base.
The description should be name for the username/password verified by the ldap (school id, unix/linux, usual). The descriptions are shown on the login page, and should explain which users should use what username/passwd. Write blanks as underscores to make it a single string.
ldap cs ldap.cs.uu.nl dc=cs,dc=uu,dc=nl cs.uu.nl_user_id
The default for description is the configured tag.
See optional configuration entries bind and attr
for more configuration options.
Optionally specify a dn and password for the indicated ldap-server ; useful only if the ldap-server does not allow anonymous binds.
Optionally specify the attribute-names for the indicated ldap-server.
The default is
attr <ldap-tag> uid cn mail
Some ldap-servers use this set of attribute-names :
attr <ldap-tag> cn displayName mail
Optionally specify some html to be included at the beginning
(end) of the HEAD-section of every page.
Optionally specify some html to be included at the beginning
(end) of the BODY-section of every page.
Optionally specify one or more LI items to be included in the user documentation page, as the first bullets under rules - usage.
top_rules_usage <LI>never, never, ....
<LI>always follow instructions of ....
Optionally specify one or more LI items to be included in the user documentation page, as the last bullets under rules - usage.
aux_rules_usage <P>
<LI>finally, remember that ...
Optionally specify one or more LI items to be included in the user documentation page, as the first bullets under statistics.
Optionally specify one or more LI items to be included in the user documentation page, as the last bullets under statistics.
Optionally specify a prefix for the names of all database tables. The default is EMPTY ('') ; a prefix must be all lowercase.
Optionally specify a the owner of the database.
This user must be allowed to create/drop tables etc.
it is used to connect to the database in the setup-db
and upd-admins scripts script. The default is EMPTY ('').
Optionally specify the database password of the database owner ;
it is used to connect to the database in the setup-db
and upd-admins scripts. The default is EMPTY ('').
Optionally specify the From: address used in mail to guests ;
by default, the configured www_contact mail address is used.
Optionally specify the From: address used in commit emails ;
by default, svn-no-reply@www_server is used ;
where www_server is the configured www server hostname.
Optionally specify the scheme for the www_server ; the default is
www_scheme https
Optionally specify the name of the svn accessfile. The default is 'svnaccessfile'.
Optionally specify the name of the DB file where the apache server looks up the guests' credentials. The default is 'guestusers'.
Optionally specify the name of the file where logins/outs etc are logged.
The default is repocafe_log.
This option now obsolete.
Optionally specify the full pathname of the svnadmin command.
The default is /usr/bin/svnadmin.
Optionally specify the full pathname of the svnlook command.
The default is /usr/bin/svnlook.
Optionally specify the full pathname of the perl command.
The default is /usr/bin/perl.
The setup support scripts are documented in section INSTALLATION.
Program mk_stats collects version and size info of each repository. It should be run daily by cron from the configured directory dir_admin.
42 05 * * * ( cd <dir_admin> ; /usr/bin/perl mk_stats -f )
A plot is genererated by gnuplot.
Usage: mk_stats [-v] [-q] [-d] [-f] [-p] [-t] [-c conf]
option v : be verbose
option q : be quiet
option d : show debug info
option f : action ; otherwise dry-run
option p : just do the plots
option t : initialize table 'repo_tots' ; use only for upgrades
option c : use config file <conf>
----------------------------------------
- mk_stats - collect repocafe statistics.
- For each repo, collect version and size into table repo_stats.
- Program mk_stats should be run daily by cron.
- Cronjob :
( cd <DIR_ADMIN> ; perl mk_stats -f )
----------------------------------------
Program upd-xusers updates table repo_xusers (ex-users).
It should be run daily by cron from the configured directory dir_admin.
44 05 * * * ( cd <dir_admin> ; /usr/bin/perl upd-xusers -f )
Running it as upd-xusers -l -v will show a detailed list of all logins.
Usage: upd-xusers [-v] [-q] [-d] [-f] [-l] [-c conf] [ login ... ]
option v : be verbose
option q : be quiet
option d : show debug info
option f : action ; otherwise dry-run
option l : list xusers (no updates) ;
option c : use config <conf>
arguments login ... : restrict to login1, login2, ...
----------------------------------------
- upd-xusers - update the repo_xusers table.
- Table repo_xusers contains repocafe users that can't be found
in the configured ldap(s) or table repo_guests.
- The repo_xusers table in only used in the statistics page.
- Running "upd-xusers -l -v" gives a detailed listing of all logins
found as owners, in access-rights or as group members.
- Because running upd-xusers may take some time to complete,
we suggest to run it daily by cron.
- Cronjob : ( cd <DIR_ADMIN> ; /usr/bin/perl upd_xusers -f )
----------------------------------------
The scripts in this section are called by the php programs. Normally, they are not used by repocafe admins.
After a commit, program mail-watchers notifies (by mail) the
repository's watchers. It inspects the diff, which contains
various parts.
A user is notified if he/she is a watcher of any part.
The notification mail contains only the relevant parts of the diff.
Usage: mail-watchers [-v] [-q] [-d] path-to-repo rev repo_id
option v : be verbose ; dry-run
option q : be quiet
option d : show debug info
----------------------------------------
- mail-watchers - send commit-mail to watchers.
- mail-watchers is called from 'REPO/hooks/post-commit' as
mail-watchers REPO REVISION REPO_ID
- It computes the watchers and uses SVN::Notify to notify each watcher ;
mail-watchers picks the relevant parts from the "svn-diff".
- Normally mail-watchers is not used by admins.
----------------------------------------
Program mk_guest_list creates the DB file, used by the httpd
to authenticate guests.
Usage: mk_guest_list [-v] [-q] [-d] [-c conf] out
option v : be verbose
option q : be quiet
option d : show debug info
option c : use config <conf>
----------------------------------------
- mk_guest_list - create the login:password file for guests.
- Program mk_guest_list is called by the php programs when a guest is added/deleted,
or when a guest changes his/her password.
- Specifically it creates:
out.db : a DB_file with (user -> password) pairs, used by httpd ;
out.txt : for your information, as text, the same pairs.
- Normally, mk_guest_list is not used by repocafe admins.
----------------------------------------
Program new-post-commit creates post-commit hooks.
Usage: new-commit-hook [-v] [-q] [-d] [-f] [-c conf] [-pre] [-post] [-a | repo_id]
option v : be verbose
option q : be quiet
option d : show debug info
option f : action ; otherwise dry-run
option c : use config file <conf>
option a : install new commit hooks for all repo's
option pre : only install pre-commit hooks
option post : only install post-commit hooks
argument repo_id : install commit hooks for repo with id <repo_id>
----------------------------------------
- new-commit-hook - create repocafe commit hooks.
- new-commit-hook creates commit-hooks for one specified repo, or all repo's (-a) ;
- by default, both 'pre-commit' and 'post-commit' hooks are installed,
from templates in 'lib/'.
- It is called by the web application when a new repository is created.
- Normally, new-commit-hook is not used by repocafe admins.
----------------------------------------
Required Perl modules : DBI, DBD::Pg, Net::LDAP, SVN::Notify
Because the application handles usernames and passwords, the webserver should support https connections and have a valid certificate.
The statistics plots use 'jpgraph', which is easy to install. The daily plots are generated with gnuplot.
The software now runs on apache 2.2 with php-5 ; mod_dav is required.
To dress up an Ubuntu Server (10.10), you need the following :
sudo apt-get install apache2 sudo apt-get install subversion sudo apt-get install apache2 libapache2-svn sudo apt-get install libapache2-mod-php5 sudo apt-get install perl sudo apt-get install postgresql sudo apt-get install gnuplot-nox sudo apt-get install libdbi-perl sudo apt-get install libdbd-pg-perl sudo apt-get install libnet-ldap-perl sudo apt-get install php5-ldap sudo apt-get install php5-pgsql sudo apt-get install libio-socket-ssl-perl sudo apt-get install viewvc sudo a2enmod authn_alias sudo a2enmod authn_dbm sudo a2enmod rewrite sudo a2enmod ssl sudo a2enmod ldap sudo a2enmod authnz_ldap
Edit /etc/viewvc/viewvc.conf :
root_parents = /data/svn/repos : svn docroot = /viewvc-doc
JPGraph: dowload and install latest version from jpgraph website, because the packages distributed in Ubuntu are old (version 1.5) ; possibly due to the license of jpgraph (commercial, but free for opensource and non-profit use).
Repocafe needs some postgresql database tables to store information. To set up the database, talk to your database administrator (DBA).
First determine a database user (username, password) that can select/delete/update the tables ; you configure :
db_user ... db_pswd ...
How you obtain a new, empty database depends on your DBA.
If your DBA lets you own a database, determine a database owner (username, password).
Ask your DBA to create a database repocafe where owner has
been granted all priviliges :
CREATE DATABASE repocafe WITH OWNER <owner>
or
CREATE DATABASE repocafe GRANT ALL ON DATABASE repocafe TO <owner>
You configure the database owner's username and password :
db_owner .... db_opswd ....
If your DBA can't let you own a database, she has to create the database tables for you. There are two cases :
You configure :
db_pref EMPTY db_owner EMPTY db_opswd EMPTY
Now your DBA may want to prefix the table names with a common prefix my_prefix. You configure :
db_pref <my-prefix> db_owner EMPTY db_opswd EMPTY
When you have finished creating your config, send your DBA the output of
setup-db -sql
The DBA can create the tables for you, and your database setup is complete.
If you expect that your users will create many (hundreds of) repositories, and you have two or more identifiable user groups, you may want to divide up the repository name space, so the repository overviews will look more organised. For details, see the config entries for user and tree. Please note that if you decide not to structure your name space, adding (or changing) structure later, will require a lot of hand-work.
Checkout the software ; the latest release :
checkout https://svn.science.uu.nl/repos/project.repocafe.dev/release
or the development version (recommended) :
checkout https://svn.science.uu.nl/repos/project.repocafe.dev/trunk
The development version (trunk) is stable and used in production
by the authors.
The distro has two parts : the admin tree and the www tree.
The admin tree is used for setup and maintenance ;
the www tree will be your apache's DOCUMENTROOT.
Later, you can move each tree to a new location ; if you do,
remember to fix the config file and www/local.ppp (see below).
The documentation is in de admin/doc directory :
repocafe.htmla html page
repocafe.1a man(1) source
repocafe.txta formatted man page
All three pages contain the same information.
In the admin tree, create the config file repocafe.conf.
Here is a start :
organisation <a href="http://www.my-org.org/"> . Name of My Organisation</a>
dir_admin /path/to/admin/tree dir_data /path/to/data/tree dir_www /path/to/www/tree
admin_user <some uid> admin_group <some gid>
www_user <some uid> www_group <some gid> www_server repocafe.my-org.org www_secret ********** www_contact svn-admin@my-org.org
db_host pghost.my-org.org db_name repocafe db_user apache db_pswd **********
ldap my_tag ldap.my-org.org dc=my-org,dc=nl usual
clas users ldap my_tag ou=people my-org_users clas guests table repo_guests login passwd name
# users and guests can create repositories
tree EMPTY EMPTY users,guests
Test the config by running configtest.
Program configtest just loads the config ; any detected errors will be shown. Optionally, it connects to the database as the configured database user db_user or db_owner. The program can also test the ldap connections(s).
Usage: configtest [-v] [-q] [-d] [-u] [-o] [-t] [-l] [-V] [-R] [-a] [-c conf]
option v : be verbose
option q : be quiet
option d : show debug info
option u : also try to connect to the database as 'db_user'
option o : also try to connect to the database as 'db_owner'
option t : also try to check the database has all the tables
option l : also try to bind to all the ldap servers
option a : test all : implies -u -o -t -l
option c : use config file <conf>
option V : show repocafe version ; exit
option R : show repocafe revision ; exit
----------------------------------------
- configtest - test the repocafe configuration.
- Program configtest just loads the config ; any detected errors will be shown.
- Optionally, configtest connects to the database as the configured database
user db_user or db_owner.
- The program can also test the ldap connection(s).
----------------------------------------
Run setup-data to setup the various files and directories. It should run as root so it can chown stuff to www_user/www_group.
Usage: setup-data [-v] [-q] [-d] [-f] [-c conf] option v : be verbose option q : be quiet option d : show debug info option f : action ; otherwise dry-run option c : use config-file <conf> ---------------------------------------- - setup-data - setup the repocafe data. - setup-data creates and/or chowns the configured data files and directories. - setup-data must run as root or the configured <www_user>, unless in dry-runs. ----------------------------------------
Run setup-vhost ; it shows (on STDOUT) the suggested vhost setup.
Catch the output and use it to set up an appropriate apache vhost.
Use -a to see the suggested apache authconfig.
You may have to tweak the vhost and auth configs to make them fit in your distro's default apache setup.
Usage: setup-vhost [-v] [-q] [-d] [-a] [-c conf]
option v : be verbose
option q : be quiet
option d : show debug info
option a : show the 'authconfig' config
option c : use config-file <conf>
----------------------------------------
- setup-vhost - show the suggested repocafe vhost or auth apache config.
- setup-vhost generates apache configs from templates ; you may have to
tweak them.
- The generated configs must be placed in the apache config tree ;
the precise locations depend on the distro/apache installation.
----------------------------------------
If you own the repocafe database, you can use program setup-db
to setup the repocafe tables.
If not, you can send your DBA the output of
setup-db -sql
and she can create the tables for you.
Please note:
-f
Program setup-db checks the database for the presence of required
tables, contraints, triggers etc.
After doing a dry-run, create/fix the database setup with option -f.
When upgrading, make a backup of your database before you use
program setup-db ; always use dry-runs.
Repocafe requires that database-language plpgsql is enabled for the repocafe database. To check if it is, use :
SELECT * FROM pg_catalog.pg_language WHERE lanname = 'plpgsql'
Program setup-db will attempt to create the language,
if it is not enabled for your database :
CREATE LANGUAGE plpgsql
but may lack permission. To avoid the problem, make sure language
plpgsql is enabled for the repocafe databse, before running
program setup-db :
psql to check :
SELECT * FROM pg_catalog.pg_language WHERE lanname = 'plpgsql' ;
CREATE LANGUAGE plpgsql ;
Usage: setup-db [-v] [-q] [-d] [-f] [-sql] [-c conf] [ table ]
option v : be verbose
option q : be quiet ; print only sql commands
option d : show debug info
option f : action ; otherwise dry-run
option sql : just show the sql to be executed
option c : use config-file <conf>
argument table : only process <table> (unless -sql is specified)
----------------------------------------
- setup-db - setup the repocafe database tables.
- Program setup-db creates missing tables, foreign key constraints etc.
- After doing a dry-run, create the database setup with option -f.
If, during setup, you change your config, re-run setup-db.
- Use 'setup-db -f' with care, after setup is complete.
----------------------------------------
Define repocafe admins with upd-admins.
Normally, only the configured db_owner can do actual add/deletes,
and database user db_user can only do SELECT and UPDATE on the
repo_roots database table. However, if db_owner or db_opswd
is empty or not configured, the db_user, db_pswd username and
password are used by upd-admins.
Before an admin is added, the specified admin login is looked up.
Usage: upd-admins [-v] [-q] [-d] [-f] [-del admin] [-add admin] [-c conf]
option v : be verbose
option q : be quiet
option d : show debug info
option f : action ; otherwise dry-run
option del : delete admin <admin>
option add : add admin <admin>
option c : use config-file <conf>
----------------------------------------
- upd-admins - create/delete repocafe admins.
- By default, upd-admins lists the current admins.
- Normally, only the configured db_owner can do actual add/deletes, and
database user db_user can only do SELECT and UPDATE on the repo_roots
database table. However, if db_owner or db_opswd is empty or not
configured, upd-admins uses db_user/db_pswd for the database-connection.
- Before an admin is added, the specified admin login is looked up.
----------------------------------------
local.ppp
Check the contents of file dir_www/local.ppp
(created by setup-data) ; it should
contain the full pathname of the config file ; for example :
<? $CONF_ROOT = '/home/repocafe/repocafe.conf' ; ?>
Make sure the apache/php config allows php scripts to read the config file.
The repocafe setup is now almost complete. A few more details remain :
Install package viewvc, or do it later ; nothing depends on it. You can (temporarily) configure
no_viewvc
to get rid of the (non-working) viewvc-urls in the web pages.
jpgraph
Install php package jpgraph ; this should work :
require_once 'jpgraph/src/jpgraph.php' ; require_once 'jpgraph/src/jpgraph_line.php' ;
Package jpgraph is used in plot.php.
gnuplot
Make sure program gnuplot is installed ; it is used by mk_stats
to plot the data.
Remember to setup cronjobs for mk_stats and upd-xusers.
42 05 * * * ( cd <dir_admin> ; /usr/bin/perl mk_stats -f ) 44 05 * * * ( cd <dir_admin> ; /usr/bin/perl upd-xusers -f )
You may want to set an email alias for the configured www_contact.
If you have configured a (non-EMPTY) db_owner and db_opswd,
you can now remove them from the config.
You will have to put them back in later, if/when you
want to add or delete svn-admins with upd_admins.
If you got this far, please send some feedback to the authors (repocafe@cs.uu.nl) What was the hardest part of setting up the cafe ? What was unclear (or wrong) ? Ideas for improvement ?
After setting up a repocafe, there is not a lot to do for the admins. Here are a few points an admin should know :
When you (an admin) login, you are either active or inactive (as an admin). When active, you have full admin rights ; when inactive repocafe treats you as it would any other user.
When you are logged in, every page shows a button with which you can switch between active and inactive.
Use config_option create_guests to specify which user classes
are allowd to create guests.
Guest accounts are created by web form. You only need to specify a full name and an email address. A login-name is generated from the full name ; the login-name and a random password are mailed to the guest.
When a guest tries to login, and her password fails, the guest can request that her password is sent to her (again).
A logged-in guest can change her password.
If you have structured your repository names, and the config has tree-lines without user-classes, then repositories in those trees can only be created on request ; that means you, because only the admins can create them.
When a user or admin deletes a repository, the repository is moved from
dir_data/repos/ to dir_data/archive/. The repository's name
is suffixed with a number, so deleting more than one repository with
the same name, doesn't give a name conflict in dir_data/archive.
On deletion, the repository directory is touched, so with ls -lart
you can list (and remove) the archived repostories by deletion date.
In the statistics page, there is a list of revision 0 repositories : repositories that were created, but were used to put stuff in. The list is ordered by date. You may want to delete them after some (fixed, announced) time.
The statistics page also has lists of unused guests and unused groups ; unused meaning unreferenced.
An ex-user is a login-name that appears in a repocafe (as owner, in the repository rights, or as group member) but can't be found in the cafe's guest list or ldap(s).
The statistics page shows a list of repositories owned by ex-users.
The statistics page also shows a list of ex-users holding access rights and/or group memberships. For every ex-user you see :
Here are a few things we would like to add to Repocafe :
git
postgresql
active directory
lock users who are exceeding their quota
A base quotum per user-class ; plus a quotum per user.
© 2010 - 2016 Koos van den Hout - Henk P. Penning
ICT-β, Faculty of Science, Utrecht University
repocafe version 0.13.6 - Tue Jan 19 16:00:37 2016 - revision 257