If you'd like to help, please contact firstname.lastname@example.org.
See SvN about commit email. All else seems basically done.
ViewCVS can be used for the web interface - currently I reused CVS' installation.
websvn is a PHP alternative. SVN::Web (http://search.cpan.org/\~clkao/SVN-Web/lib/SVN/Web.pm)might also support SVK, and hence would be nice to have.
svnmailer (Debian package svnmailer)
is the equivalent to
commit_prep+log_accum. It apparently have some
quirks as soon as you do start using a non-trivial setup (heard in the
Gna! mailing list, the latest being
Last version: 1.08 / April 2006
svn-notify (Debian package libsvn-notify-perl) (http://search.cpan.org/~dwheeler/SVN-Notify/) is another commit notification package, currently tested by the phpGroupWare project (http://savannah.gnu.org/support/?106102). Last version: SVN-Notify-2.66 / Jun 2007
Tasks needed for base support - done:
- DONE Support SVN in Savane
- DONE Clean-up the architecture to allow new SCMs
- DONE Type of write access: svn+ssh (provides more isolation than a site-wide WebDAV access where all the repositories belong to www-data)
- DONE Think where to place SVN data: along with the CVS repositories seems good - we reuse the IP and the ViewCVS/ViewVC install. It's the same kind of access, with no user login allowed (so as to preserve history integrity).
- DONE Document migrating CVS to SVN: SvN
- DONE: alter the Savane repository creation - do not try to enforce a repository layout
Tasks needed for better maintenance - not needed
- TODO Automatically import SVN dumps on user request (as SF does -
- beware of data loss if the project admin makes a mistake!
- TODO? Performance tweaks for serving 2500 repos at once: use ramfs for temporary files (goal: no hard-disk access during read-only access [I don't think SVN has read locks, though, unlike CVS, and thanks to the transaction / atomic commit design]).
- TODO Automatically migrate a CVS repository to SVN repository on user request; cvs2svn comes to mind, but see other tools at SvN