Date: Wed, 22 Feb 2017 15:53:40 +0100 From: =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= <uqs@freebsd.org> To: Warner Losh <imp@bsdimp.com> Cc: Ed Maste <emaste@freebsd.org>, freebsd-git@freebsd.org Subject: Re: Reconsider switching from svn to git? Message-ID: <CAJ9axoQnAdki9N9ZXvcgg86ufy9bNumM4uS0YDn0G501k4Uv7g@mail.gmail.com> In-Reply-To: <CANCZdfqxydVvcJMqLPfbok9gOjdWjOGrAzN0_mrc-3r7j60ipA@mail.gmail.com> References: <49da18e4-b211-c48d-5486-368cda912fc0@multiplay.co.uk> <86mvdfy3qs.fsf@desk.des.no> <CANCZdfpA-odwrpd=ya2NmjesDxZr1rcUhv%2BnaVWicpq7U_KT2w@mail.gmail.com> <CAPyFy2CKdHW_KkOOQozPW04jBDz8ZaNWSJLqFWAdzKcaDfSzcA@mail.gmail.com> <CANCZdfqxydVvcJMqLPfbok9gOjdWjOGrAzN0_mrc-3r7j60ipA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
2017-02-22 0:47 GMT+01:00 Warner Losh <imp@bsdimp.com>: > On Tue, Feb 21, 2017 at 1:22 PM, Ed Maste <emaste@freebsd.org> wrote: >>> If, and this is a big if, we go to using git, I'd like to *STRONGLY* >>> request that we not change the hashes we have on github today. There's >>> lots of people with branches from that and changing the hashes would >>> make them all useless. Well, not completely useless, but quite >>> difficult to recover from unless the branches were simple without >>> merges. >> >> This is a very tricky issue. I agree that there's a(n incredibly) >> large cost with changing existing hashes, and previously argued that >> it was an absolute nonstarter. Also, I think this is independent of >> switching to git as the source of truth: we have the same open issue >> with the current svn2git mirror. > > I know. I know the pain it will cause for Netflix should that issue be resolved. Zero pain, really. If I give you the commit hashes of broken-repo and new-repo at the same state you can instruct git to merge these two commits, preferring the tree of whichever side. You can then continue to pull/merge from the new-repo's master. There's probably a magic three-line incantation required, but really it's no biggy (albeit annoying). If even that surgery is too much, you can also export a complete diff of your-branch to origin/master in the old repo, and that would apply w/o conflicts to new-repo, as long as you sync them both to the same tree-object (which they would have, as the problem is only in the metadata). >> That said, I also strongly believe that, as long as SVN is the "source >> of truth" repo, the git conversion must be reproducible by third >> parties. I believe developers and others who consume FreeBSD via git >> must be able to validate that the data and metadata are consistent >> between svn and git. Unfortunately today even the subversion mirrors >> (svn.freebsd.org) have inconsistent metadata relative to >> repo.freebsd.org, so it's not currently possible for end users to >> validate the svn2git conversion. > > As one of the users that would be affected by hash changes, I'm > finding that argument less persuasive given the pain I know it will > cause. > >> I've briefly discussed with uqs@ what it would entail to migrate to a >> "fixed" view of the history, and believe it's possible to facilitate a >> relatively painless migration. It could look roughly like: >> >> 1. Broadly announce the plan >> 2. Make a new alias for current master (e.g. master-legacy) >> 3. Start a new, reproducible conversion and push to a new master (master-ng) >> 4. As new commits are made to SVN update both master-ng and master-legacy >> 5. Provide guidance on migrating both rebase- and merge-based >> workflows to master-ng >> 6. Give notice of upcoming switch in what master points to >> 7. Switch master from master-legacy to master-ng >> 8. Stop updating master-legacy if/when it becomes infeasible to >> continue doing so, or when it's no longer used Before doing any re-roll of the repository, it would be nice if we could actually restore the CVS part of the history that got brutally mangled with the cvs2svn conversion. Or, we say fuck it, and only convert the SVN history (starting 2008) and tell people to use graft-points into https://github.com/dspinellis/unix-history-repo/ if they are interested in what "git blame" produces. > > If there were tools to help migrate, that would be useful. But I'm > unsure what those might be since many of git's most powerful features > don't work when you don't have a proper shared ancestor that's recent. > > Though a plan like that might be able to mitigate some of our concerns > given the rather quirky way we import sources at Netflix (we do them > as a subtree and do odd things to create merge points). It would take > some experimentation to be able to know if this is a viable path > forward. Our master tree is a twisty maze of commits, merges, etc that > bedevil automation. > > As for switching source of truth, what's the thinking on $FreeBSD$ and > the currently nice property of it that it includes the branch / > release in the path. "Nice property"? If there was something I could kill it would be this. Have you ever migrated a system from stable/9 to stable/10 and then dealt with all the mergemaster fallout because the frigging IDs change w/o any content changes? That is a totally useless feature. I would much prefer we had CVS IDs back, so that you could at least see how many revisions there were to the file in between. > > Anyway, don't take concerns I have for opposition to a switch, just > nerves that need to be quelled a bit first :) > > Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ9axoQnAdki9N9ZXvcgg86ufy9bNumM4uS0YDn0G501k4Uv7g>