Commit notifications

Derek Price and I recently (20008?) unforked the Savannah version of log_accum and integrated it upstream.

You can find the script at /subsystems/cvs/usr/local/bin/log_accum.pl and http://cvs.sv.gnu.org/viewcvs/cvs/ccvs/contrib/log_accum.pl

CVSROOT/loginfo files are mass-generated via infra/cvs/generate_log_accum.pl, but there are plans to integrate that in Savane.

To update our version of log_accum.pl:

  chroot /subsystems/cvs
  cd /usr/local/bin/upstream
  cvs update
  cd ..
  make # substitute @PERL@

Features we need

  • Integrate current patches:

    • Using a centralised, unique config file sounds great and it now possible (-c /etc/cvs.conf). But, the LockDir section is specific to each repository. It would be good a have something like LockDir=/var/lock/cvs/%r/%p. /var/lock/cvs is where savannah keeps cvs locks, not in the repository.
    • I also patched CVS to never rely on CVSROOT/passwd for authentication (except for anonymous and anoncvs). There should be a way to do that directly in CVS. Debian has a --password-file switch which unfortunately requires a user list section for each repository (not a centralised one). A AnonymousAuth=yes option, combined with a CvsAuth=no would be an alternative.
    • autopackage support
    • on a side note, we integrated zlib-read-compressed.diff which should be included in the latest 1.12.13, as it's a known bug
    • other patches were included in HEAD, so planned for release with 1.12.14, when it comes out
  • log_accum

  • Implement a way to rebuild manual/ for GNU projects on commit in webcvs. Maybe we'll need to maintain a local checkout at Savannah and use rsync to transfert to www.[non]gnu.org. That way we'll have more flexibility. Sticking to SCM updates is still an option (the lightest one at first glance). People mentioned this script: http://cvs.savannah.gnu.org/viewcvs/texinfo/texinfo/util/gendocs.sh to rebuild the manual.

  • No more errors in ViewCVS/ViewVC (https://savannah.gnu.org/support/index.php?105417). Possible more efficient and with a better template system.
  • Trackers integration http://savannah.gnu.org/support/?104643
  • Prevent branch deletion, cf. node taginfo in the CVS manual and https://savannah.gnu.org/support/?105773
  • Offer CVSup in addition to rsync access for mirroring purposes?? I don't know what CVSup can do. Maybe we actually already support it.
  • VCP (http://public.perforce.com/public/revml/) supports "bidirectional exchanges between any two CVS". Gotta check that!
  • Tailor (http://www.darcs.net/DarcsWiki/Tailor) "is a tool to migrate changesets between ArX, Bazaar, Bazaar-NG, CVS, Codeville, Darcs, Git, Mercurial, Monotone, Subversion and Tla repositories.". Whoa!

Notes

Previously, Savannah created very small subsystems relying on vanilla chroot(2), one per CVS directory

Cons:

  • This environment is hence very poor, executables need to statically compiled, Perl scripts need to be compiled as well, the mail system relies on a in-house forwarder that becomes buggy. It cannot be improved much, for harddisk space reasons (multiple its size by 2500 projects). It is not maintenable, namely we cannot have APT there, and more importantly we cannot easily add new applications (eg. a simple script to update the Savannah trackers on commit).
  • This setup is strictly the same for all projects, so it gets the symetry effect: if one environment has a security hole, all others most likely have it as well.
  • It was often too much complicated and hence errors were introduced; for example in the absence of NSS, the user name was initially not found and replaced by uidXXXX. Currently this is worked around via the USERNAME environment variable...

We actively discussed among all the Savannah stakeholders in order to drop it, and agreed. The plan was then to switch back to a setup where all repositories are at the same level, possibly in a per-service (not per-project) subsystem.

subtopics: