This is an archive of the discontinued Mercurial Phabricator instance.

narrow: move .hg/narrowspec to .hg/store/narrowspec (BC)
ClosedPublic

Authored by martinvonz on Aug 3 2018, 5:24 PM.

Details

Summary

The narrowspec is more closely related to the store than to the
working copy. For example, if the narrowspec changes, the set of
revlogs also needs to change (the working copy may change, but that
depends on which commit is checked out). Also, when using the share
extension, the narrowspec needs to be shared along with the
store. This patch therefore moves the narrowspec into the store/
directory.

This is clearly a breaking change, but I haven't bothered trying to
fall back to reading the narrowspec from the old location (.hg/),
because there are very few users of narrow out there. (We'll add a
temporary hack to our Google-internal extension to handle the
migration.)

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

martinvonz created this revision.Aug 3 2018, 5:24 PM
martinvonz updated this revision to Diff 9874.Aug 3 2018, 8:12 PM
yuja added a subscriber: yuja.Aug 5 2018, 9:04 AM

Queued, thanks.

def savebackup(repo, backupname):

if repository.NARROW_REQUIREMENT not in repo.requirements:
    return
vfs = repo.vfs
vfs.tryunlink(backupname)
  • util.copyfile(vfs.join(FILENAME), vfs.join(backupname), hardlink=True)

+ util.copyfile(repo.svfs.join(FILENAME), vfs.join(backupname), hardlink=True)

Maybe move backup file to svfs as well?

This revision was automatically updated to reflect the committed changes.

There are non-Google users of narrow at this point (recall we've gotten non-Googler patches), so please publish the temporary migration hack someplace for the benefit of the other users.

(A phabricator review that we immediately abandon would probably be fine, but we should definitely make a note in the relnotes for 4.8)

pulkit added a subscriber: pulkit.Aug 7 2018, 10:29 AM

There are non-Google users of narrow at this point (recall we've gotten non-Googler patches), so please publish the temporary migration hack someplace for the benefit of the other users.
(A phabricator review that we immediately abandon would probably be fine, but we should definitely make a note in the relnotes for 4.8)

Yes, we might roll-out narrow with mercurial 4.7 first, so this script will be of great help. (BTW, isn't it just a move of file?)

In D4099#64268, @pulkit wrote:

There are non-Google users of narrow at this point (recall we've gotten non-Googler patches), so please publish the temporary migration hack someplace for the benefit of the other users.
(A phabricator review that we immediately abandon would probably be fine, but we should definitely make a note in the relnotes for 4.8)

Yes, we might roll-out narrow with mercurial 4.7 first, so this script will be of great help. (BTW, isn't it just a move of file?)

It's "just" a move, but typically the way we handle these migrations at Google is we write an extension that does one of the following:

  1. Hijacks reads for the new file and reads the old file
  2. Hijacks reads for the new file if it doesn't exist and moves the new file

we run in mode 1 when we're doing the rollout and might roll back, then switch to mode 2 when we're past the rubicon on the rollout and can finalize the data migration. Once everyone has run the extension in mode 2 for a while, we reap the extension.

In D4099#64268, @pulkit wrote:

There are non-Google users of narrow at this point (recall we've gotten non-Googler patches), so please publish the temporary migration hack someplace for the benefit of the other users.
(A phabricator review that we immediately abandon would probably be fine, but we should definitely make a note in the relnotes for 4.8)

Yes, we might roll-out narrow with mercurial 4.7 first, so this script will be of great help. (BTW, isn't it just a move of file?)

It's "just" a move, but typically the way we handle these migrations at Google is we write an extension that does one of the following:

  1. Hijacks reads for the new file and reads the old file
  2. Hijacks reads for the new file if it doesn't exist and moves the new file

we run in mode 1 when we're doing the rollout and might roll back, then switch to mode 2 when we're past the rubicon on the rollout and can finalize the data migration. Once everyone has run the extension in mode 2 for a while, we reap the extension.

Oh, I missed that clients need to be updated in real time. It will really be great if this extension is shared. Thanks @durin42 for the explanation.