Some general status, move to Subversion

[Russ Allbery]

Hello all,

I'm very sorry that you've not seen more movement on INN development
lately.  The system on which the CVS repository was hosted suffered a NIC
failure and had been out of commission for several weeks.  It looks like
that's now been fixed, but alas I'm going to be out of town this coming
weekend and can't do the much delayed catch-up.

I've been thinking a lot about revision control systems for a while,
though, and I think I'm ready to take INN to Subversion.  I'm going to cc
Peter to let him know my thinking on this; I think it should be possible
to host it on the existing system, but I'm also willing to host the
Subversion repository on my own system if needed.

The reasons why I want to make this change are:

 * Better support for file and directory renames without losing history.

 * Much cleaner tagging and branching support, which I also find far more
   intuitive after having worked with it for a while.

 * Disconnected development via svk, which is something that I really want
   and will use.  If I have a disconnected INN repository before my yearly
   off-line, two-week vacation this October, I may actually get some INN
   development done during that period.

 * A generally more modern system that's under active development and has
   considerably more potential than CVS does at this point.

This is, however, going to break some things that people are used to, like
CVSup.  I think we can provide even better alternatives, but that's
something to be aware of.

My guess about how this would work is that commit access would use svn
over ssh, exactly like we use CVS over ssh right now.  Public access can
be handled via a copy of the repository served in read-only mode via the
Apache Subversion module, not to mention via something like svnweb.  This
again is something that I'm willing to host or work with ISC on hosting
there, as seems the easiest to do.

There is an equivalent of cvs2cl (svn2cl) that we can use to generate the
ChangeLog file for releases.

If there is anything else that I need to watch out for in making this
change, please speak up.  I have a fair bit of experience with svk at this
point and can add information to HACKING on how to use it with a
Subversion repository for disconnected development.

As part of the migration, I want to remove all generated files from the
repository and require that developers have the necessary bits locally to
regenerate them.  This will not affect snapshots or releases, of course.
This means developers will need appropriate versions of Autoconf and
pod2man; I think those are the main ones affected.  The system generating
the snapshots will generate those files as part of the snapshot generation
process.

My current plan is to try to get completely caught up on INN mail and
release INN 2.4.3, hopefully within a month or so (although I'm travelling
at the end of June and I'm not yet sure how much work I'll be able to do
then), and then do the Subversion switchover after that.  If I'm wrong
about the CVS repository problems being completely resolved and it drops
off again, though, I may take advantage of the opportunity to do the
conversion earlier, before I get caught up.  :)

The conversion itself would be done with cvs2svn.  It's not great, but it
seems to do close enough to the right thing to work for us (although
unfortunately it tends to create complex deltas that svk isn't
particularly thrilled with -- but that just means svk eats a lot of memory
and time when pulling down the repository the first time).

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.