search

attic-labs / noms

The versioned, forkable, syncable database
Apache License 2.0
7.44k stars 266 forks source link

Bring back general-purpose noms migration #3595

Open aboodman opened 7 years ago

aboodman commented 7 years ago

cc @willhite, @cmasone-attic

aboodman commented 7 years ago

Note that I pushed a v7.12 branch to the noms repo to make this work, and renamed all the imports in that branch: https://github.com/attic-labs/noms/commit/4d4f0239061a8bfe7151076b874ff01ccb0198ff

I'm not sure whether vendoring the v7 dependency is worth it or not. The gopkg.in dependency will redirect automatically to the biggest v7.x branch on github. Maybe that's sufficient to avoid duplicating all this storage in our repo?

aboodman commented 7 years ago

Answering myself ... I think the branch is sufficient. No need to clutter up the repo. I'll take out the vendored noms before landing this.

aboodman commented 7 years ago

Also after thinking on it, I feel like the package names should be fine-grained with the subversion. So in this case, the package names in the branch should be 7.12. That way we can support migrating across minor versions if desired.

ghost commented 7 years ago

Sorry. Forgot this was waiting on me. Is it ok if I review on Monday?

aboodman commented 7 years ago

It's not high priority. @willhite and I were talking about it in meatspace.

ghost commented 7 years ago

In general, I'm still ok with this approach. I'd put money on their already being other subtle issues here that I'm not thinking of, but I buy the argument that we need this and now that we have data that we want to migrate, it's worth getting experience with how well this works.

It's kind of a bummer that the binary size of noms is going to nearly double here, but we can always split it out later if we want.