Date: Wed, 2 Nov 2011 14:21:30 -0400 From: John Baldwin <jhb@freebsd.org> To: Doug Barton <dougb@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: <201111021421.30777.jhb@freebsd.org> In-Reply-To: <4EABB0AB.9070808@FreeBSD.org> References: <20111007141312.GJ26743@acme.spoerlein.net> <201110251405.46493.jhb@freebsd.org> <4EABB0AB.9070808@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday, October 29, 2011 3:52:11 am Doug Barton wrote: > On 10/25/2011 11:05, John Baldwin wrote: > > 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? > > No, that would be silly. :) Something more along the lines of: > > svn cp doc/foo/bar release/9.0-doc Ok, that would work, though it's a bit hackish. :-P > I don't see any value in duplicating the src process line by line, only > the bits that are relevant. The point was that if you were going to call it release/9.0/doc instead (which is the "logical" name for our current branching scheme) you would have to engage in careful coordination. > > 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). > > If that turns out to be true then obviously we need to figure out the > right way to handle it. Correct. Mostly we just have to think about this before making any changes to make sure whatever is done doesn't break CVS. > > 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. > > I'm not sure we need to duplicate all the features we have for cvs in an > svn world. We haven't needed to do that for src, so saying "we need to > solve this for doc" in this context is a red herring. Err, no, that's not what I said. What I said was that src in SVN is not as feature complete as CVS (cvsup), so src has to maintain CVS until that problem is solved. Thus, we can't just ignore the CVS tree and trash it through ignorance. Instead, we have to make sure that things that we do in SVN don't kill CVS. > >> 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. > > And my point is that having them in the same repo is certainly no worse, > and gives us the opportunity to do something better. I am still not convinced it will really buy anything better, but on that we'll just have to disagree. > > 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. > > I can see how what you're describing could happen, but I don't see why > anyone would care. If you're updating a file in the doc tree in the same > change set as a file in the src tree, the numbers of the current > revisions of the files are (almost certainly) going to be different. The > fact that the revision number for a file which is chronologically older > is numerically higher than the other is a useless piece of trivia. In the case of docs that might be true. However, I have frequently been using annotate on one file in src and needed to align when a change occurred with another file. In fact, I just did this Monday trying to figure out the history of the 'wcommitsize' not-quite-implemented mount option for NFS as I was comparing the histories of both the in-kernel NFS client bits and the mount_nfs program. Maybe you never use annotate, but other people _do_. In the case of docs though, I have not specifically used annotate to the same level of detail as src, but I wouldn't want to presume that people may not have that same need in the future. If you really want to do this in the same repo, I won't object. However, you do need to talk to the SVN/CVS admins first to make sure we don't blow up the CVS repo in unexpected ways, and to decide if you want to propagate any of the changes from SVN to CVS (it might be nice to preserve the "head" of docs in CVS, but it might also not be necessary as cvsup probably isn't that relevant for docs). -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201111021421.30777.jhb>