Date: Wed, 02 Nov 2011 12:36:31 -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: <4EB19BBF.70608@FreeBSD.org> In-Reply-To: <201111021421.30777.jhb@freebsd.org> References: <20111007141312.GJ26743@acme.spoerlein.net> <201110251405.46493.jhb@freebsd.org> <4EABB0AB.9070808@FreeBSD.org> <201111021421.30777.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
See, this is why conversation/discussion is a good thing. :) On 11/02/2011 11:21, John Baldwin wrote: > 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 Sure, but compare base/vendor, and base/vendor-crypto, base/vendor-sys. And/or vendor/bind9/dist, and vendor/bind9/dist-9.N. >> 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. Sure, it's logical in one sense, but too painful to do in another. If we can make the paths "pretty" that's a bonus, but "works, with minimal pain" is more important. >>> 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. Ok, then I misunderstood you, and I apologize for the red herring accusation. I thought it went without saying that we don't want to break svn->cvs for src, but I'm glad that you're saying it. :) >>>> 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. Fair enough. >>> 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. Um, I use annotate all the time. I still don't see see how a higher revision number on a chronologically older document is going to bring about the zombie apocalypse. Yes, it might look "odd" at first, and may take half a second of mental processing the first few times someone sees it. But I think that in a year this will just be "one of those things about the svn transition," just like the fact that successive versions of any given document have dramatically different revision numbers. But now I'm repeating myself (again). > If you really want to do this in the same repo, I won't object. Just to be clear, I personally do think it's the right design choice, sure. But there are also plenty of people who have been talking about the benefits that this would bring. It would be nice if some of those people speak up now. :) Doug > 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). -- "We could put the whole Internet into a book." "Too practical." 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?4EB19BBF.70608>