From owner-freebsd-current@freebsd.org Fri Dec 25 22:44:15 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8E84A4CC8CC for ; Fri, 25 Dec 2020 22:44:15 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D2hnp3vR9z4Tpr for ; Fri, 25 Dec 2020 22:44:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x72e.google.com with SMTP id v126so4651584qkd.11 for ; Fri, 25 Dec 2020 14:44:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Dmk+eGeudbNcbnUnJgDDj1qV8POoIX5UDgsVp7G2fxA=; b=AG/feSoE9XdEXecTPFYBirucHtZzXffJhhHPdQCKg9npVr2exRzMPwW7FNNmEsSMBe Wrft6ZpwaB53w+ngVLPQ7RE9uqhqRuIeCq3VOAJLnLw0/gKI+mkdtp2thpgEzP+MaRJu NfmvFJIvHNdMPMZQBGOZqM4hUqJWQ9jCCTbWiXk4N9uZBNt8VcGbdZMYaRGxZ5OMUkPk i35EI4sSb6VY3jchzqGL5Kc3e9F/hgGIRF01hDxtdZKxxqW9Wc9oJmwL2BXFg6HCCsj2 U1g236Y6o8c+S8askiMGhcLDXncm8j6PyJUqOF3JzGugarfQZgCiPVmBfUNjMiYMvAVX 2Kxw== X-Gm-Message-State: AOAM533OiRxKjde+c2tvtD+freEfRKmYj5+AZPr0dqF/SHNv0e2/HNBa gR0La9DuhzYId5xAfxkZsDFEgQamedNQOCVX2ehFfQ== X-Google-Smtp-Source: ABdhPJxofH8pzla+bUPxmdVZ8LfvoTWglsKuyb4LeZ7RDmuNob9WtfwSIIiQUNUJEk9XHuPkCuhFssMThEYspKH56dM= X-Received: by 2002:a37:83c2:: with SMTP id f185mr6812142qkd.206.1608936253136; Fri, 25 Dec 2020 14:44:13 -0800 (PST) MIME-Version: 1.0 References: <20201223143545.Wf_Ww%steffen@sdaoden.eu> <20201225214041.jVKMU%steffen@sdaoden.eu> <20201225222510.JyYwH%steffen@sdaoden.eu> In-Reply-To: <20201225222510.JyYwH%steffen@sdaoden.eu> From: Warner Losh Date: Fri, 25 Dec 2020 15:44:01 -0700 Message-ID: Subject: Re: src: continued use of Subversion for getting updates To: Warner Losh , FreeBSD Current X-Rspamd-Queue-Id: 4D2hnp3vR9z4Tpr X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::72e:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::72e:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::72e:from]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; MAILMAN_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Dec 2020 22:44:15 -0000 On Fri, Dec 25, 2020 at 3:25 PM Steffen Nurpmeso wrote= : > Warner Losh wrote in > : > |> On Fri, Dec 25, 2020 at 2:41 PM Steffen Nurpmeso > |> wrote: > |>> Ulrich Sp=C3=B6rlein wrote in > |>> : > |>>|On Wed, 2020-12-23 at 15:35:45 +0100, Steffen Nurpmeso wrote: > |>>|>Jeffrey Bouquet wrote in > |>>|> : > |>>|>|On Wed, 23 Dec 2020 11:13:07 +0100, Johan Hendriks > |>> |>>|>|om> wrote: > |>>|>|> On 23/12/2020 09:49, Warner Losh wrote: > |>>|>|>> On Wed, Dec 23, 2020, 1:48 AM Graham Perrin < > |>> grahamperrin@gmail.com> \ > |>>|>|>> wrote: > |>>|> ... > |>>|>|> First of all a big thank you for all your time and effort you an= d > |>> all > |>>|>|> the other people put in this tremendous task. > |>>|> > |>>|>Yes, it is great to have FreeBSD as a stable git repository now, > |>> ... > |>>|>I really dislike that vendor imports have been tagged. Because > |>>|>there is only one tag namespace you cannot avoid getting all this > |>>|>cruft. I mean, it is too late now, but one could have used > ... > |>>|That's basically what was done? I don't understand what you're sayin= g > |>>|here ... > |>> > |>> Well, cgit-beta did not have had all these tags if i recall > |>> correctly, did it? I mean it has been two months or so since > |>> i last had it because "git fetch" bailed here due to the errors > |>> that i have reported, and fetching more than a gigabyte for > |>> brand-new fetches devastates here. > |> > |> It had them, but not under the refs/head/vendor space but under the > |> refs/vendor space. > > These are not tags but branches. I have nothing against the > branches, of course. Only the tags are the problem. > > |> The multiple gigabyte fetch is because we changed the hashes two or > three > |> times in the last few months. > > Yes i know. No problem (well, for me, of course), i tried it at > least once more by the end of November, but the server did not > finish my request (the simple "git fetch" in a non-clean repo). > > |> But i _think_ all the tags below refs/tags/vendor/ like > |>> > |>> vendor/wpa/2.9 > |>> vendor/wpa_supplicant/0.3.8 > |>> vendor/wpa_supplicant/0.5.10 > |>> vendor/wpa_supplicant/0.5.11 > |>> vendor/x86emu/4.6 > |>> vendor/xe/1.13 > |>> > |>> etc. did not exist in cgit-beta? I surely would have said > |>> something once comments have been requested, wouldn't i? > |> > |> They did exist. They were under refs/vendor rather than > refs/head/vendor > |> though. > > Under refs/tags/vendor? refs/tags/ is the "special" namespace > managed by "git tag", this is different than the rest. > > |>> The thing is if i do > |>> > |>> #?0|kent:free-src.git$ git ls-remote|wc -l > |>> From https://git.freebsd.org/src.git > |>> 6814 > |>> > |>> This is a tremendous amount of head references that need to be > |>> compared. > ... > |>> there is > |>> > |>> #?0|kent:free-src.git$ git sr|wc -l > |>> 2137 > |>> > |>> but if i go for "the real" FreeBSD itself it is just > |>> > |>> #?0|kent:free-src.git$ git sr | grep -v vendor | wc -l > |>> 19 > |> > |You might be happier tracking on github, once we start pushing there as > the > |vendor branches won't be published there. > > No problem with any number of branches, Warner. Just tags under > refs/tags this is above. > They were tags in the cgit-beta as well (and a few branches). I don't believe that detail changed, but my old copies of the repo are gone. > ... > |>> and thus > |>> > |>> #?0|kent:free-src.git$ git sr | grep vendor | wc -l > |>> 2118 > |>> > |>> Which is a pity since all these references will be checked during > |>> "git fetch" unless i am mistaken. > |> > |Yes. So far it's been doing it quite quickly for me, but I'm decently > |connected... > > Yes, terrible here, shared with many. > You may be happier running custom refs, or grab from github. The source of truth has a lot of stuff. We may work to prune some of the vendor branches into their own repos in the future, but today there's a lot of stuff that's there, some of which is for the convenience of the developer and you may need to trim (at least in the short term). ... > |>>|That's a valid point, we debated whether to keep vendor tags and > |>> decided > |>>|for now to replicate what we have in SVN. We can still delete all th= e > |>>|vendor tags on the main repo anytime we want ... > |>> > |>> I personally would track that in the commit message of the import > |>> on the vendor branch that anyway exists(!), and then when merging > |>> this into the mainline, but not create a real tag in the tag > |>> namespace. Also the backups/ and such, because why? > |> > |We need tags to keep track of what's been done, and to revert and do > other > |management things with vendor imports. > > But why? You have the commit on a topic/vendor branch, and yppou > revert nothing but the commit. In fact doing so messes the tag,p > it has to be retagged when you do re-commit an import proper, > which requires a forced push even! > I'm not sure I follow. Unless I misunderstand, you are describing a different problem with different issues. But the nice thing about refs is that you can always change them later if the current scheme isn't working out... So far, it is for most people, so we're not changing the vendor import stuff right away. I've taken note of your issues and will keep that in mind if there's others with the same problems. Warner