svn commit: r336448 - stable/10
John Baldwin
jhb at FreeBSD.org
Mon Jul 23 17:11:05 UTC 2018
On 7/18/18 12:05 PM, Peter Jeremy wrote:
> On 2018-Jul-18 07:41:23 -0700, "Rodney W. Grimes" <freebsd at pdx.rh.CN85.dnsmgr.net> wrote:
>>> Author: peterj
>>> Date: Wed Jul 18 09:32:43 2018
>>> New Revision: 336448
>>> URL: https://svnweb.freebsd.org/changeset/base/336448
>>>
>>> Log:
>>> Retrospectively document SVN branch point for stable-10 and its releases.
>>>
>>> This is a direct commit to stable/10 because the releases are taken
>>> from the stable/10 branch.
>>>
>>> Approved by: jhb (mentor)
>>> Differential Revision: D16263
>>
>> Actually I see no reason not to document these in the mainline
>> UPDATING file and making these MFC's. As is now when looking
>> at UPDATING from head I can not easily find the branch point
>> for any of these releases and that is probably the most useful
>> time for this information. If I already have a branch I probably
>> already know what its anchor point is.
>
> I only put the releng/x.y branch points into the relevant stable/x/UPDATING
> because releng/x.y is branched off stable/x and I don't think it makes much
> sense to document those in head/UPDATING. The stable/x branchpoints are in
> both head/UPDATING and stable/x/UPDATING. Note that the stable/10 branch-
> point was already in head/UPDATING.
I agree with this. We should document them in the source branch, but not
in grandparents like head where there is no single head commit that becomes
releng/X.Y.
> Do you have a quick way to find branch points? The best I've found is
> "svn log -r 1:HEAD --limit 1 --stop-on-copy" within a branch and that
> is quite resource intensive on the SVN server.
Finding a file that doesn't change often like MAINTAINERS and only doing the
log against that shouldn't be as bad.
--
John Baldwin
More information about the svn-src-all
mailing list