Date: Tue, 9 Jun 2020 20:40:54 -0600 From: Warner Losh <imp@bsdimp.com> To: Scott Long <scottl@samsco.org> Cc: =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= <uqs@freebsd.org>, freebsd-git@freebsd.org, Scott Long <scottl@freebsd.org>, Peter Wemm <peter@freebsd.org>, kensmith@freebsd.org, Sean Chittenden <sean@chittenden.org> Subject: Re: When were the stable and release branches actually created? Message-ID: <CANCZdfqL1mvPj2-rZXmej8oyp%2BFY19aT2yaJFLz0sqFZ4CiZCQ@mail.gmail.com> In-Reply-To: <CF742026-F96D-4024-82A6-0656BC44E67F@samsco.org> References: <CANCZdfpeZrvUUfojucheKG2YfGM0L2Zmxx5=eJwXb%2BDxZM1gOA@mail.gmail.com> <CF742026-F96D-4024-82A6-0656BC44E67F@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jun 9, 2020 at 5:13 PM Scott Long <scottl@samsco.org> wrote: > It=E2=80=99s best to leave the old history as it is and not try to replic= ate it or > detangle it. If anything, it=E2=80=99s a signpost the the old ways of doi= ng things > were not right, should not be reminisced over fondly, and certainly shoul= d > be taken as a warning to do things better going forward. > Yes. Understood. If it were easy to get, we'd grab it. If it's hard, like this one, we're leaving it behind... > I can=E2=80=99t stress enough that trying to import the entire history of= svn and > cvs into git is a bad idea. Please don=E2=80=99t do it. Don=E2=80=99t l= et perfect be the > enemy of good; allow people to be unhappy that the repo history isn=E2=80= =99t > perfect and unified, and move on. Please please please. > We're on the same page here. We've grabbed the relatively easy 95%. If it's easy to include, we're doing it. If it requires heroics, we're leaving it aside. The mainline conversion is done, and Ulrich is just making sure... The history we've published is reasonably complete but not perfect. We also know the repo is a little large and have looked at ways of subsetting should performance demand it. The current repo is 3/4 the size of the Linux kernel, so it's still in the 'sane' range as generally defined by the git folks :). However, there's a number of ways git will let you do a shallow clone for people with limited network and git is flexible about stitching together repos should we need to more generally subset and fight through that set of issues. If you notice any performance or other issues with the beta repo, please let us know. Warner Scott > > On Jun 9, 2020, at 4:37 PM, Warner Losh <imp@bsdimp.com> wrote: > > =EF=BB=BF > Thanks Scott. I suspected that we'd done things to destroy data and it's > not easy to recover. Thanks for confirming that was the case. > > Warner > > On Tue, Jun 9, 2020 at 11:11 AM Scott Long <scottl@samsco.org> wrote: > >> TLDR: don=E2=80=99t worry about 4, 5, or 6. Start the git repo at the = 11-stable >> branch point, not at the beginning of time. Let the old SVN repo be the >> read-only source of truth for 10.x and prior. >> >> In the CVS days, we made it a practice to =E2=80=9Cslip tags=E2=80=9D wh= en we wanted a new >> revision to be part of an existing branch or release. The effect of tha= t >> might >> be what you=E2=80=99re seeing for 4.10 vs 4.11. You are correct that 5-= STABLE >> wasn=E2=80=99t >> tagged until 5.2. I don=E2=80=99t remember what happened with 6-STABLE = and 6.1, >> and my email archives from that time period are lost. >> >> I=E2=80=99ve gone through source control switches several times at sever= al >> companies, >> and it=E2=80=99s always not worth the pain to do a conversion of the old= system. >> We=E2=80=99ve >> found that it=E2=80=99s best to start the new repo with little or no his= tory, and >> leave the >> old repo as a read-only archive. Interactive repo history is typically >> only useful >> for a few months, and after 6-12 months its use drops off rather >> exponentially. >> The effort required to curate the repo transposition is not worth it. >> Also, as someone who still regularly fouls up git repos and needs to wip= e >> and >> restart them, having a smaller repo with less ancient history makes >> downloading >> and managing it easier. >> >> My recommendation is to start a new repo with HEAD as of the FreeBSD 10, >> branch point, which then tracks 12-CURRENT and all branches onwards. >> That >> covers the need to do MFCs to 11-STABLE. People that want to examine >> older >> history can use a read-only copy of SVN. Given that 10.x is coming up o= n >> 8 >> years old, and everything prior is obviously even older, that=E2=80=99s = a >> reasonable >> amount of history to have in Git. >> >> >> Scott >> >> >> > On Jun 9, 2020, at 6:48 AM, Ulrich Sp=C3=B6rlein <uqs@freebsd.org> wro= te: >> > >> > Adding Scott, Ken and Peter who might have some vague recollections. >> Please >> > see below. >> > >> > On Mon, 2020-06-08 at 22:25:08 -0600, Warner Losh wrote: >> >> I'm unsure of this for sure. >> >> >> >> I have a vague memory that we created the release branches when we ha= d >> patches >> >> for security advisories. But things are fuzzy. Maybe the security >> advisories >> >> would hold a clue... Maybe the dates line up there? >> >> >> >> At the very lease, it would let you know that we created an extra >> level of dots >> >> referenced in the patches there... This will let you know if this is = a >> cvs2svn >> >> screw up, or a real artifact about the quirky nature of releases and >> security >> >> patches. CVS doesn't have super great fidelity in discovering >> tree-wide events >> >> due to small date skews as files are updated one at a time, each at t= he >> >> then-current gettimeofday(). >> >> >> >> Stable/5 was cut sometime after 5.2. That's legit timeline. 5 was >> smpng and it >> >> wasn't stable until two preview releases, and three actual releases >> into the >> >> process... >> >> >> >> Warner >> >> >> >> On Mon, Jun 8, 2020 at 11:36 AM Ulrich Sp=C3=B6rlein <uqs@freebsd.org= > >> wrote: >> >> >> >> Hey folks >> >> >> >> I'm investigating why the SVN repo differs from what's on the >> release >> >> CVS ISOs and of course you'll shout "CVS repo copies" but it would >> be >> >> really helpful if there was a record of when in time the various >> >> branches were created. Because SVN just ain't right. >> >> >> >> Here's the pre-SVN stable and releng branch creations in SVN: >> >> >> >> r8869 | cvs2svn | 1995-05-30 07:50:54 +0200 (Tue, 30 May 1995) | 2 >> lines >> >> A /stable/2.0.5 (from /head:8852) >> >> r8882 | cvs2svn | 1995-05-30 10:29:08 +0200 (Tue, 30 May 1995) | 1 >> line >> >> A /releng/2.0.5 (from /head:8881) >> >> r9211 | cvs2svn | 1995-06-13 20:05:17 +0200 (Tue, 13 Jun 1995) | 1 >> line >> >> A /stable/2.1 (from /head:9202) >> >> r19327 | cvs2svn | 1996-11-02 11:41:29 +0100 (Sat, 02 Nov 1996) | = 1 >> line >> >> A /stable/2.2 (from /head:19320) >> >> r42951 | cvs2svn | 1999-01-21 01:55:31 +0100 (Thu, 21 Jan 1999) | = 1 >> line >> >> A /stable/3 (from /head:42948) >> >> r57955 | cvs2svn | 2000-03-13 05:59:44 +0100 (Mon, 13 Mar 2000) | = 1 >> line >> >> A /stable/4 (from /head:57954) >> >> r57956 | cvs2svn | 2000-03-13 05:59:45 +0100 (Mon, 13 Mar 2000) | = 1 >> line >> >> A /releng/4.4 (from /stable/4:57955) >> >> r57960 | cvs2svn | 2000-03-13 05:59:49 +0100 (Mon, 13 Mar 2000) | = 1 >> line >> >> A /releng/4.5 (from /stable/4:57955) >> >> r63491 | cvs2svn | 2000-07-19 08:22:02 +0200 (Wed, 19 Jul 2000) | = 1 >> line >> >> A /releng/4.6 (from /stable/4:63490) >> >> r66473 | cvs2svn | 2000-09-30 04:49:38 +0200 (Sat, 30 Sep 2000) | = 1 >> line >> >> A /releng/4.7 (from /stable/4:66472) >> >> r75750 | cvs2svn | 2001-04-21 02:04:30 +0200 (Sat, 21 Apr 2001) | = 1 >> line >> >> A /releng/4.3 (from /stable/4:75749) >> >> r101416 | cvs2svn | 2002-08-06 10:24:47 +0200 (Tue, 06 Aug 2002) | >> 1 line >> >> A /releng/4.11 (from /stable/4:101415) >> >> r101418 | cvs2svn | 2002-08-06 10:24:49 +0200 (Tue, 06 Aug 2002) | >> 1 line >> >> A /releng/4.9 (from /stable/4:101415) >> >> r107811 | cvs2svn | 2002-12-13 07:54:34 +0100 (Fri, 13 Dec 2002) | >> 1 line >> >> A /releng/5.0 (from /head:107810) >> >> r108855 | cvs2svn | 2003-01-07 05:28:56 +0100 (Tue, 07 Jan 2003) | >> 1 line >> >> A /releng/4.10 (from /stable/4:108854) >> >> r111744 | cvs2svn | 2003-03-02 17:42:41 +0100 (Sun, 02 Mar 2003) | >> 1 line >> >> A /releng/4.8 (from /stable/4:111743) >> >> r115436 | cvs2svn | 2003-05-31 13:28:29 +0200 (Sat, 31 May 2003) | >> 1 line >> >> A /releng/5.1 (from /head:115435) >> >> r123193 | cvs2svn | 2003-12-07 04:02:28 +0100 (Sun, 07 Dec 2003) | >> 1 line >> >> A /releng/5.2 (from /head:123192) >> >> r133968 | cvs2svn | 2004-08-18 18:37:05 +0200 (Wed, 18 Aug 2004) | >> 1 line >> >> A /stable/5 (from /head:133920) >> >> r133969 | cvs2svn | 2004-08-18 18:37:06 +0200 (Wed, 18 Aug 2004) | >> 1 line >> >> A /releng/5.3 (from /stable/5:133968) >> >> r133971 | cvs2svn | 2004-08-18 18:37:08 +0200 (Wed, 18 Aug 2004) | >> 1 line >> >> A /releng/5.4 (from /stable/5:133968) >> >> r147906 | cvs2svn | 2005-07-11 06:14:43 +0200 (Mon, 11 Jul 2005) | >> 1 line >> >> A /stable/6 (from /head:147905) >> >> r147907 | cvs2svn | 2005-07-11 06:14:44 +0200 (Mon, 11 Jul 2005) | >> 1 line >> >> A /releng/6.0 (from /stable/6:147906) >> >> r147908 | cvs2svn | 2005-07-11 06:14:45 +0200 (Mon, 11 Jul 2005) | >> 1 line >> >> A /releng/6.1 (from /stable/6:147906) >> >> r147921 | cvs2svn | 2005-07-11 06:14:58 +0200 (Mon, 11 Jul 2005) | >> 1 line >> >> A /releng/6.2 (from /stable/6:147906) >> >> r147922 | cvs2svn | 2005-07-11 06:14:59 +0200 (Mon, 11 Jul 2005) | >> 1 line >> >> A /releng/6.3 (from /stable/6:147906) >> >> r158462 | cvs2svn | 2006-05-12 03:09:20 +0200 (Fri, 12 May 2006) | >> 1 line >> >> A /releng/5.5 (from /stable/5:158461) >> >> r172506 | cvs2svn | 2007-10-10 18:59:15 +0200 (Wed, 10 Oct 2007) | >> 1 line >> >> A /stable/7 (from /head:172505) >> >> r172507 | cvs2svn | 2007-10-10 18:59:16 +0200 (Wed, 10 Oct 2007) | >> 1 line >> >> A /releng/7.0 (from /stable/7:172506) >> >> >> >> >> >> I think stable/5 being created after 5.2 is what actually happened >> >> (IIRC), but 4.3 getting created after 4.7 and 4.11 predating 4.10 >> and >> >> 4.8 is highly bogus. >> >> >> >> Is there a record of when these things actually happened? Do I nee= d >> to >> >> trawl through newvers.sh for all of these? >> >> >> >> For example, in the releng/4.11 branch it gets first deleted, then >> >> r138454 brings it back on 2004-12-06 14:39:45 (that's about 2.3 >> years >> >> later) >> >> >> >> Thanks >> >> Uli >> > >> > >> > It's fairly easy to guess the true branchpoint by looking at the size = of >> > the tree. Taking 6.1 for example. SVN mentions it first in r147908 in >> > 2005, but that commit basically deletes 99% of everything and >> > accumulates a bunch of files here and there till r158179 on 2006-04-30 >> > when 99% of the files are being brought back. >> > >> > Ignoring the fact that re-writing git notes is a pain in the neck, we >> > could easily munge all the previous commits together into a single >> > commit on the 2006-04-30 after the full conversion run. >> > >> > Or, as an alternative, make r147908 *not* branch off of stable/6 and >> keep >> > it free-dangling, but then have r158179 record stable/6 as of 2006-04-= 30 >> > as a parent commit. That could be done in-line and not mess with the >> > iterative conversion as much. >> > >> > What I would need to know is at what stage and on which branch things >> > like newvers.sh were modified. Because for 6.1 the change of newvers.s= h >> > to 6.1-RC came in with r157593 on 2006-04-08 (so not the big massive >> > commit on 2006-04-30). Later on 2006-04-30 it was then bumped to RC2 >> with >> > r158153. >> > >> > Scott, Ken, what was standard practice back in the day? Was there ever >> > a single file branched off to releng/x.y before the big tagging of the >> > full tree? Or can I really take the massive commit of r158179 to mean >> > the branch was tagged and all other schmutz either happened on stable/= x >> > and later got its tag moved or was a repo-copy? >> > >> > Is there a way to get the dates from the email archives? Does someone >> > have a full copy of those? >> > >> > Thanks a lot >> > >> > Cheers >> > Uli >> >>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqL1mvPj2-rZXmej8oyp%2BFY19aT2yaJFLz0sqFZ4CiZCQ>