svn commit: r308789 - head/sys/conf

[Warner Losh]

On Fri, Dec 23, 2016 at 11:36 AM, Warner Losh <imp at bsdimp.com> wrote:
> On Fri, Dec 23, 2016 at 9:35 AM, Ed Maste <emaste at freebsd.org> wrote:
>> On 17 November 2016 at 19:13, Gleb Smirnoff <glebius at freebsd.org> wrote:
>>> Author: glebius
>>> Date: Fri Nov 18 00:13:30 2016
>>> New Revision: 308789
>>> URL: https://svnweb.freebsd.org/changeset/base/308789
>>>
>>> Log:
>>>   If FreeBSD source tree is a subproject of a bigger project, then .git or
>>>   .hg may reside above FreeBSD sources root.  Provide function findvcs()
>>>   that will climb up and seek for presence of a VCS directory.
>>
>> This can incorrectly find an unrelated .git directory and provide a
>> git revision unrelated to the FreeBSD source being built. For example,
>> a build from my Subversion tree now reports "FreeBSD 12.0-CURRENT #2
>> ad3f46a(master)" instead of "FreeBSD 12.0-CURRENT #5 r310482M".
>>
>> Can you explain your use case in a little more detail so that I can
>> avoid breaking it with a change here? Do you commit FreeBSD snapshots
>> into the "bigger project"?
>
> This is done at work (Netflix). We import all the FreeBSD revisions
> from github into our repo, and then merge them into the top level
> FreeBSD directory from time to time using git's subtree functionality.
> We also pull in our ports tree this way (so we have a ports directory
> at the same level as our FreeBSD directory). So we don't have a
> $TOPSRC/.git like you would if you'd just cloned directly from github.
> Our .git directory lives in $TOPSRC/.git as a result. newvers.sh
> should find the 'deepest' SCM it can, and use that instead of
> apparently using the topmost (I'm surprised that you have FreeBSD
> under a directory that has a git checkout in it, btw, but I know that
> with my dotfile management repo, that sometimes happens by mistake).
> And if this somehow produces a 'tie', the tie should go to svn.
>
> Looking at how to fix this mess... woof. There's all kinds of crazy
> here. Support for: git, git + svn, hg, p4, svn and svnlite. Sometimes
> $VCS_cmd is defined if it exists at all on the system, other times
> it's only defined if it exists on the system AND we think the tree is
> under $VCS.
>
> But the base of all this woe is that findvcs is called on a per-vcs
> basis, rather than being called early to match one of N VCS
> signatures. It would be better off searching each directory for each
> file rather than finding any file at any level.

After chatting with Ed on IRC, I've posted this review.

https://reviews.freebsd.org/D8895

which should fix the issues.

Warner