Conversion to SVN

[John Baldwin]

On Saturday, October 22, 2011 12:00:10 am Doug Barton wrote:
> On 10/10/2011 10:01, John Baldwin wrote:
> > On Saturday, October 08, 2011 12:16:59 pm Simon L. B. Nielsen wrote:
> >>>> I'm not really sure where you would fit doc into the current repo...
> >>>> head/ etc. is on the top level.
> >>>
> >>> /doc and /www would be the obvious choices. Ed even jokingly (??) said
> >>
> >> Well, that seems like a bit of a mess as you mainly have branches at that level...
> >>
> >>> we should just rename /head to /src ... not sure I concur.
> >>
> >> Considering we have stable etc. on the same level that seems like a bad thing to do...
> > 
> > I agree with both of these.  The layout in svn currently is src-centric and
> > only setup to handle src. 
> 
> Right now under base/ we have:
> 
> cvs2svn
> head
> projects
> release
> releng
> stable
> svnadmin
> user
> vendor
> vendor-crypto
> vendory-sys
> ROADMAP.TXT
> 
> Those categories are primarily source-related, but not exclusively.

The branches are certainly very src-centric.  For example, where would you
put doc release tags?  If it were the same repository then what you would
really like to happen is to make the doc + src trees for a given tag live
in the same place.  I'm not sure how doable that is.  Perhaps we could
move 'doc' into the equivalent of 'src/doc' (so head/doc, releng/9.0/doc,
release/9.0/doc, etc.).  However, that forces docs to be branched (well,
you could copy doc from head into each releng tree during each release
instead and just delete it from stable branches if you wanted to avoid that,
but that's a bit of a PITA).  It also means docs can't be "tagged" until a
src release branch is created and historically docs have been tagged long
before src is ready.  I think it would be useful to allow docs to continue
to manage their tagging independent of what re@ does for src.

> > You would need to move the entire repo down into a
> > new "src" directory for it to really work, but we aren't going to do that now.
> > I think a separate SVN for doc+www is fine (and not near as much overhead to
> > manage as Ulrich fears).
> 
> My primary motivating factor is not the administrative overhead, it's
> the fact that elements from the doc repo are used as part of 'make
> release.'

But it's easy to just check them out from another repository.  Even the old
make release does a separate checkout operation for docs, and there's no
reason that has to use the same exact repository as src.

> > Also, I think the discontinuous history idea is a compelling reason to not put
> > the doc/www history into source svn.  Right now svn changes move forward
> > continuously with time (so change N + 1 is "newer" than change N), but
> > importing doc+www history as changes that are subsequent to the current top of
> > tree would break that.  OTOH, renumbering the current tree to put the doc+www
> > history in the "right" place is simply not workable now.  
> 
> I don't understand any of what you wrote above, but I'd like to. What
> I'm thinking is that the cvs->svn converter would simply start with the
> next available revision number and that would be the first revision for
> the oldest doc commit. When the import was done, the revision numbers
> would continue to increase monotonically regardless of whether it was a
> doc or src commit. Are you saying that this is not how it would work?

I'm saying that humans would find it confusing that revision N would be
from today and revision N+1 would be from 1996.

-- 
John Baldwin