Date: Mon, 24 Oct 2011 15:05:22 -0700 From: Doug Barton <dougb@FreeBSD.org> To: John Baldwin <jhb@freebsd.org> Cc: "Simon L. B. Nielsen" <simon@nitro.dk>, freebsd-doc@freebsd.org, doc@freebsd.org, doceng@freebsd.org, =?ISO-8859-1?Q?Sp=F6rlein?= <uqs@freebsd.org> Subject: Re: Conversion to SVN Message-ID: <4EA5E122.8030303@FreeBSD.org> In-Reply-To: <201110240827.50750.jhb@freebsd.org> References: <20111007141312.GJ26743@acme.spoerlein.net> <201110101301.37276.jhb@freebsd.org> <4EA23FCA.10309@FreeBSD.org> <201110240827.50750.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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/ ? > 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. >>> 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. The question is not how can we continue to do what we've always done, but how can we do better? >>> 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. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EA5E122.8030303>