Reconsider switching from svn to git?
uqs at freebsd.org
Wed Feb 22 14:53:43 UTC 2017
2017-02-22 0:47 GMT+01:00 Warner Losh <imp at bsdimp.com>:
> On Tue, Feb 21, 2017 at 1:22 PM, Ed Maste <emaste at 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
>> 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
>> 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
restore the CVS part of the history that got brutally mangled with the cvs2svn
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
> Anyway, don't take concerns I have for opposition to a switch, just
> nerves that need to be quelled a bit first :)
More information about the freebsd-git