We can just move to "narrow" or similar when we finalize the
format. I'm not sure what the migration process from one requirement
to another should look like, but we're about to cross that bridge at
Google once this change lands, so hopefully we'll know soon.
Details
- Reviewers
indygreg - Group Reviewers
hg-reviewers - Commits
- rHGe14821b290eb: narrowrepo: make repo requirement include the string 'experimental'
Diff Detail
- Repository
- rHG Mercurial
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Event Timeline
We can treat two requirements strings as equivalent.
The trick is once we introduce a requirements string in the wild, we can't make BC changes to its format. i.e. the behavior surrounding a store requirement must be immutable over time. So e.g. if we introduce narrowhg-experimental today, any repos with that requirement will be openable by any Mercurial supporting that requirement, even if we change the store format. That's not good. Especially if we ship narrowhg-experimental with different behavior in say 4.6 and 4.7.
One trick I like to do (which I'll be doing with the wire protocol shortly), is introduce a version component. e.g. experimental-narrow-0001. If you make a change to the format, you bump to experimental-narrow-0002. This basically requires that a specific revision of Mercurial must be used for all operations. When we finally make the transition to non-experimental, you can optionally teach new clients to treat the latest experimental version as equivalent to the final version.
tests/test-narrow-pull.t | ||
---|---|---|
169 | I'd glob the line number while you are here. Also, I think one of my many review comments will make this warning go away :) |
I'd glob the line number while you are here. Also, I think one of my many review comments will make this warning go away :)