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
configfile 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=yesoption, combined with a
CvsAuth=nowould 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
- Using a centralised, unique
- Use the commit log instead of the list of files in the mail subject (personal preferences)
- Try to support tla-sync-commit unless that's complicated: http://lists.gnu.org/archive/html/savannah-hackers/2006-01/msg00868.html
- Allow custom diff options (already done in log_accum, needs support in the web interface)
- Deal with commit log encodings (http://savannah.gnu.org/support/?105528)
- 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.nongnu.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
taginfoin 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!
- Our latest biggest problem was that CVS commits are not signed. This is available in CVS now (http://ximbiot.com/cvs/wiki/index.php?title=GPG-Signed_Commits).
- http://lists.gnu.org/archive/html/bug-cvs/2007-05/msg00012.html contains various patches as attachments. Presents inclusion of --allow-root-regexp
- One interesting Debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=169967 - using --allow-root in
cvs server. Also posted at http://savannah.nongnu.org/bugs/?func=detailitem&item_id=14900
- Could we need libcvs-perl? Apparently no, it seems it can extract revisions from a CVS repository, but does not provide tools for administration
Previously, Savannah created very small subsystems relying on vanilla chroot(2), one per CVS directory
- 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.