Conversion to SVN

[Ulrich Spörlein]

On Sat, 2011-10-08 at 11:03:51 +0200, Marc Fonvieille wrote:
> On Fri, Oct 07, 2011 at 04:17:07PM -0700, Doug Barton wrote:
> > On 10/07/2011 14:15, Gavin Atkinson wrote:
> > > On Fri, 7 Oct 2011, Rene Ladan wrote:
> > >> Op 07-10-2011 16:13, Ulrich Sp?rlein schreef:
> > >>> it looks like I'm not the only one thinking about moving the doc/www
> > >>> repos from CVS to SVN, and other people actually have not only thought
> > >>> about it but already played around with conversions.
> > >>>
> > >>> gavin did some preliminary conversions and it turns out that we end up
> > >>> with ~50k revisions and about 650MB of changes (IIRC). There are also
> > >>> lots of weird branches, so perhaps we could size that down a bit.
> > >>>
> > >>> What I, personally, would like to see is us using the same svn repo as
> > >>> src. That means we would have to stop svn.freebsd.org for the
> > >>> conversion, turn off email sending, dump 50k revisions into it (under
> > >>> /doc and /www perhaps? where should branches/tags end up?), then turn
> > >>> everything back on.
> > > 
> > > The more I think about this, the less I like the idea.  I really don't 
> > > like the idea of having revision numbers which no longer increase with 
> > > commit date (i.e. having revisions 1-250,000 correspond to the existing 
> > > src tree, 250,000-300,000 being the imported doc tree, and then the 
> > > combined repo being 300,001 onwards).
> > 
> > I'm sorry, I don't understand your concern here. The commit ids
> > increment monotonically in svn, and the number is global to the whole
> > repo. Given that the individual files won't be increasing to a
> > deterministic value, I don't understand why we care what the actual
> > number is.
> >
> [...]
> 
> Till now, in this thread, no one really thought about translators.
> Having many version of the same doc will kill translators effort cause
> they could not follow.  It's already difficult to follow the current doc
> tree, so I imagine what will happen when there will be a -CURRENT,
> -STABLE, -WHATEVER branch to follow...

Thanks for bringing up another view on this. If we decide to go from 1
branch to N branches, the bets are really off as to how big N is going
to be ...

> The other concern is about the numbers mentioned above, if you use to
> translate docs, the current CVS numbering scheme is really interesting
> to follow revision of one file, with SVN we'll loose that.

Would merge properties help to track which revisions of the original
docs have been "merged" into Dutch, German, etc? That way you can use
the svn mergeinfo --show-revs=eligible /path to give you a list of
revisions to look at.

> This said I'm not against a VCS change but it should be done in a wise
> way and not to add things that we could not support cause of lack of
> manpower or interest.  And before doing the change, some things should
> be done: complete separation between release docs and doc/, a possible
> move from SGML to XML, a trim or update of outdated things, a move from
> teTeX to a more modern LaTeX (if XML tools allow it), etc.  Well, a lot
> of work...

I think that the move to SVN should be done *before* the move to XML, or
the split of release docs, as we can track file renames better in SVN
than in CVS of course.

Cheers,
Uli