On Tue, Nov 17, 2020 at 2:25 AM Thomas Mueller <mueller6722_at_twc.com> wrote: > from Warner Losh and my last message: > > > > Thanks for the information, but if you feel the need to send me a > > > not-quite-CC, please don't send me the multipart/alternative version > when > > > you send the plain-text version to the list. > > > > I hate multipart/alternative! > > > I must apologize. Sadly, I use gmail, so I have no control over how it > > decides to encode things, sadly. I've tried in the past, and alas, > nothing > > I've tried works for any length of time. Please forgive me whatever > > unspeakable MIME atrocities it sends on my behalf. I've removed you from > > the cc line in the hopes that the FreeBSD mail server cleans things up > to > > be more to your liking. > > The message on the list had only the plain-text part. Either you sent it > differently, or the list server stripped the HTML attachment. > > > > When git becomes the source of truth on FreeBSD after the flag day, > will > > > it be necessary to git-clone the whole tree from scratch, or will > there be > > > a conversion tool to switch the svn download to proper git format? > > > > For the supported stable branches, you'll be able to download via > > subversion and switch over at any time before the end of project support > > for the branch. > > I suppose this applies only to the current stable branches (11 and 12) but > not to future stable branches, beginning with 13? > Correct. It's a migration aid for people that have svn tooling based on the supported FreeBSD branches. Future branches, as well as the main development branch, will be in git only. > > However, when you make the switch to git (either due to the flag day and > > tracking -current, or jumping from svn on a stable branch), there's no > tool > > to convert the subversion checked out tree to a git tree. The needed > > information needed to create the git tree isn't easily available from the > > subversion checkout, so you'll need to do a git clone. If bandwidth is a > > problem, you can do a shallow clone that omits all the history and just > > grabs the branch of interest. Git is a bit more link efficient than > > subversion, which is helpful. Git also has ways to help you share one > local > > repo across checked out versions, which can also help if you have to > track > > multiple branches. > > I suppose I would then git-clone the current/13 src tree separately and > delete the svn version. > Yes. If you have the space, I'd grab new sources from git, make sure they are good and then delete the svn version once you've made the switch. > > > The doc tree is much smaller than the src tree, while the ports tree is > > > much bigger than the src tree. Is that the reason for the > few-months-long > > > lag switching the ports trree to git? > > > > There's a couple of things that make it trickier. The ports tree does > > quarterly branches. So there's a window around the quarterly branch when > > it's easiest to make the switch. In addition, the character of the files > in > > the ports tree differs from src. Unlike subversion, git infers copies, > > moves, etc. The mostly similar nature of the ports tree is likely to > cause > > git grief when ports are copied, resurrected from the attic, etc. The > ports > > folks are still figuring out how to best use git to track the history > they > > need to track without creating undue issues. It's not clear if that will > > all be sorted out before the next window in December, or if they will > have > > to defer until March. This is why I hedged a bit as to the exact time, > > since it's not been nailed down yet. So it's not so much the size, as the > > difference in makeup and character between the two trees. The doc tree > is, > > as you point out, much smaller, less active and its needs are more modest > > and largely mirror the src tree, so it can be done quickly at any time. > > > Warner > > Now I see the reason for timing the switch of the ports tree from svn to > git. > > I never tracked the quarterly ports tree, just as I never followed the > quarterly (NetBSD) pkgsrc, only the current version. > > NetBSD is readying to switch src trees and pkgsrc from cvs to hg > (Mercurial), but it takes some time to prepare and not mess things up. > > I am under the impression that they intend to switch everything over at > once when ready. > > Pkgsrc has both current and quarterly, so maybe they will have issues > similar to FreeBSD ports on switching to hg. > > I have git installed on both FreeBSD and NetBSD, but no Mercurial. > > As far as I can see, git repositories greatly outnumber mercurial > repositories. > Yea. Mercurial is interesting too. It's got a saner CLI command set than git (though, honestly, that's a low bar), but doesn't have as many of the easy history rewriting tools that git does and isn't as forgiving to 'oopses' in the middle of complex operations. In researching open source repos, I found that maybe 85% were git, 10% were svn and 2% mercurial and 3% other, though the numbers were quite noisy. WarnerReceived on Tue Nov 17 2020 - 17:10:24 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:25 UTC