pulkit added a comment.
In https://phab.mercurial-scm.org/D2593#47511, @martinvonz wrote: > In https://phab.mercurial-scm.org/D2593#44291, @indygreg wrote: > > > Not sure where to record this comment in this series. So I'll pick this commit. > > > > I think we want an explicit version header in the state files so clients know when they may be reading a file in an old format. For example, if I start a merge in one terminal window, I sometimes move to another terminal window to resolve parts of it. The multiple windows may be running different Mercurial versions. For example, sometimes one of the shells has a virtualenv activated and that virtualenv is running an older Mercurial. We don't want the older Mercurial trampling on state needed by the new Mercurial. > > > Also, it doesn't seem like CBOR defines any magic bytes to start the top-level object with, so it's not obvious to me that an old state file (e.g. on containing just a nodeid) could not be parsed as a valid CBOR file. Perhaps cmdstate should help with that? We could make it always add a first item that's just "CBOR" or something (it seem very unlikely that we'd have that in an old state file), and we could fail when reading a state file that doesn't have that. Or would could require any new state files to have a new name than the old ones? I can add another key value pair 'magicstring: CBOR' which should be present in the cbor format state files, or we can start storing statefiles in .hg/state/ folder. REPOSITORY rHG Mercurial REVISION DETAIL https://phab.mercurial-scm.org/D2593 To: pulkit, #hg-reviewers Cc: martinvonz, indygreg, durin42, mercurial-devel _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
