Conversion to SVN

[John Baldwin]

On Monday, October 24, 2011 6:05:22 pm Doug Barton wrote:
> On 10/24/2011 05:27, John Baldwin wrote:
> > 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? 
> 
> What prevents them from being put under release/ ?

So right now what happens is that a release is tagged by re@ doing
'svn cp stable/9 releng/9.0' and eventually 'svn cp releng/9.0 release/9.0'.

Are you foreseeing having re@ add extra steps to do a fixup so that, say,
you do 'svn cp doc releng/9.0/doc' or 'svn cp doc release/9.0/doc' after the
initial copy?  Note that this would have to happen _after_ the source copy is
done as otherwise svn won't let you do the copy for source.  This is part of
what I was talking about below about forcing doc to tag after src has tagged.
Also, if you do this, then doc will show up in a checkout of the release, but
not in head, which may or may not be confusing to some folks since the
implicit assumption about the checkout of a release being "symmetric" with
head and stable branches would be broken.

I also think it might do some very bizarre things in our downstream CVS repo
(or possibly require substantial hackery to our existing SVN -> CVS
conversion scripts).  Keep in mind that we don't have an svn replacement for
cvsup (esp. in checkout mode) which many users still depend on, so we can't
just ignore that entirely (though perhaps we could choose to not replicate
the release version of docs to CVS, or tolerate them showing up as 'src/doc'
in CVS instead).  However we'd need to think about the full implications of
doing any approach in this regard.

> > 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.
> 
> I'm not sure why that wouldn't be able to continue. The impression I'm
> getting is that you're thinking of worst case scenarios because you
> don't like the idea of combining repos, rather than being willing to
> look at obvious solutions and/or lack of actual problems.

No, I'm thinking about the actual mechanics of when the svn operations would
happen vs how the equivalent actions happen now during a 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.
> 
> The question is not how can we continue to do what we've always done,
> but how can we do better?

But the solution has to actually be better.  I thinking having docs in SVN vs
CVS might be better (changesets, etc.), but I'm not convinced that having them
in the same SVN as src is any better than a dedicated repository.

> >>> 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.
> 
> I think you're dramatically overestimating how confused people would be
> by this. Just like the fact that version numbers increase over the whole
> repo, this is something that people would just get used to over time.

Maybe so.  Still, I depend on this implicit stuff a good bit when dealing
with historical info in the form of commit logs via 'annotate', etc.
(which I actually do a lot in src).  Since the doc and src bits wouldn't
actually overlap, perhaps that would not matter for someone in the future
who is looking at past history since the streams should not cross.

However, if the plan is to allow concurrent changes to manpages and docs
(which can be a valid reason to merge), then you can get the odd behavior
where revision N of a doc file is "older" than revision M (where M < N)
of some change in a manpage and if you are walking back in history
because you are investigating a change in the future made to both files
that might be a bit confusing.  OTOH, if that is a desired feature there
isn't really any way around that at this point.

-- 
John Baldwin