SVN notes
My rough notes on where I'm at with a full-scale svn for freebsd.org demo.
Scripts needed - easy stuff - most already "out there"
- pre-propedit hook to sanitize property edits. eg: ensure correct syntax of svn:keywords, perhaps disallow edits of svn:log or svn:author (I'm undecided on that)
- start-commit hook for access controls
- pre-commit hook to check for sane properties (ie: svn:keywords is correct, subject to an exclude list etc), log messages, things like enforce the Approved by: stuff for releng branches in freezes etc.
- pre-commit hook to check that $FreeBSD$ in files is correctly collapsed - this means that the client is $FreeBSD$ aware, or at least wont trash the repo.
post-commit hook to edit/clean up the svn:log property. remove duplicate blank lines. Remove empty tags, eg: ^PR:\s*$
- post-commit hook to generate commit mail
Harder stuff - needed though
- something like the p4repl scripts we have that export p4 branches to cvs on cvsup10, except for exporting svn commits to the cvs tree.
- exporter has to deal with branches too... eg: the 7.x has to go to RELENG_7 and 7.0 has to got to RELENG_7_0 etc.
- either a config file rule to drive this or have it implied.
Scripts "nice to have"
- post-commit hooks to generate signatures of changeset files.
- some sort of integrity checker that periodically verifies the signatures.
Docs
- We also need to write a formal roadmap guide for the repository layout
- a transition guide for committers (howto do various things), etc.
- A plan for doing releases is needed... Do they come from the exported cvs tree or from svn?
Still to think about
What do we do with $FreeBSD$? If we expand it on svn with the aim of eventually switching over entirely from cvs to svn, then we need a svn-centric $id$ tagging system. This is actually a complex problem because cvs will change them when we export them. Do we switch to a new $BSD$ tag or something like that?
security officer has to know how they're going to handle all this.
re@ needs to know how they're going to handle all this
the ctm folks need a plan.. there's still about 200 of them. (I dont see the cvs tree ever going away)
We need a plan to provide a p4-like playground. Do we do it in the core tree or provide a second playground like we do with p4?
What about repository replication? (backups?) Hotcopy and incremental backup? distribute the svn repo with svnsync? (if so, do we distribute the playground area?)
Do we use svn-1.5 from the start? There are good reasons to do this - svnsync can do partial mirrors etc - and bad ones
Timeframe
The ideal window to do a cutover is in the immediate aftermath of the 7.0-RELEASE going out. We dont want to screw up and delay 7.0-R due to scm issues. We need as much time as possible to sort out the teething problems before 7.0.1 or 7.1 is on the agenda.
Hardware
I have a wimpy box available and some faster ones. I've requested better hardware from work.