facebook/sapling
1
1
Fork 0
mirror of https://github.com/facebook/sapling.git synced 2024-10-10 16:57:49 +03:00
Code Issues Projects Releases Wiki Activity
446ebff30f
sapling/eden/scm/tests/test-commitcloud-backup-sql2.t

90 lines
3.9 KiB
Perl
Raw Normal View History

mark all tests requiring Python 2 Summary: This diff marks **ALL** mercurial tests requiring Python 2 feature. After you fixes some tests, simply remove the `py2` feature requirement and that tests will be continuously run after your diff is landed. To bypass this feature requirement, run the tests command with `HGTEST_FORCE_PY2=1`. For example: ``` HGTEST_FORCE_PY2=1 buck test //eden/scm/tests:hg_run_tests ``` or ``` HGTEST_FORCE_PY2=1 python run-tests.py ``` ---- Basically this diff are created with the following commands: ``` $ sed -i 's/import feature\(.*\)$/import feature\1\n\nfeature.require(["py2"])/' test-*-t.py $ sed -i '1s/^/#require py2\n/' test-*.t $ ls | grep -P "^test.*(?<\!-t)\.py$" > list && vim -p $(cat list) # manually adding feature requires for these Python tests. ``` (Note: this ignores all push blocking failures!) ignore-conflict-markers Reviewed By: singhsrb Differential Revision: D19655148 fbshipit-source-id: 985e3ccb4010cc559049f1d89f8909bc2d9b5e20
2020-01-31 05:40:49 +03:00
#require py2
tests: enable chg for 572 tests Summary: Add `#chg-compatible` to 572 tests that seem to pass with chg enabled. This should make them run faster. Reviewed By: xavierd Differential Revision: D18870507 fbshipit-source-id: fe895e733efffc9286cd3d17c7a156c803124395
2019-12-10 02:24:31 +03:00
#chg-compatible
commitcloud: incorporate infinitepush backups into commitcloud Summary: Merge the functionality of the infinitepushbackup extension (backing up commits to commit cloud) into the commitcloud extension. These two extensions are highly coupled, and the commitcloud extension monkey-patches the infinitepushbackup extension for a lot of its functionality. There is also a lot of code duplication between the two extensions which we can remove if they are part of the same extension. The infinitepushbackup commands (`hg pushbackup`, ...) are moved to subcommands of the `hg cloud` command, e.g. `hg cloud backup`. Each feature of the infinitepushbackup extension is moved to a new module in the commit cloud extension: The `background` module controls background execution of `hg cloud backup` and `hg cloud sync`. The `backupbookmarks` module tracks and updates scratch bookmarks for backups. This will be deprecated in the future. The `backupstate` module tracks whether or not a commit has been backed up. This is now tracked separately from backup bookmarks in a new file: `.hg/commitcloud/backedupheads.<remote-identifier>`. This also covers hidden commits, preventing a re-backup of previously backed up commits when they are unhidden. Previously the commitcloud extension customized the smartlog annotations: `Backing up` became `Syncing`, etc. This is now removed for consistency. Previously the infinitepushbackup extension disabled background backup by injecting an `infinitepushbackup.disableduntil` config entry into the user's config. This is now replaced with a state file at `.hg/commitcloud/autobackup`. Either option can be set to disable auto backup. Commit cloud will wait until both have expired before starting to run background backups again. Reviewed By: DurhamG Differential Revision: D15276939 fbshipit-source-id: 1d28989a157286e47d3dd97ca9c70b27f692dda1
2019-05-20 16:11:59 +03:00
#if no-windows no-osx
infinitepush: backup local heads and bookmarks Summary: Backuping changesets is not enougn for restore. We also want to backup heads and bookmarks to completely capture the state of the repo. This diff is the first step in implementing this functionality. It adds new bundle2 part which contains encoded dict (simple json encoding is used). If value in the dict is empty then key is the bookmark pattern to delete. If value is not empty then key is the bookmark name to save and value is a node hash. The reason to put them in the same part is to make it possible to delete and insert into indexapi in one transaction. It's also possible to pass patterns to delete in part parameters but there is a bug in upstream hg that limits parameters' size to 256 and we can potentially have longer bookmarks. Local bookmarks are saved in infinitepush in the following form: infinitepush/backups/USERNAME/HOSTNAME/REPOROOT/bookmarks/LOCAL_BOOKMARK_NAME Local heads are saved in infintiepush in the following form: infinitepush/backups/USERNAME/HOSTNAME/REPOROOTheads/HEAD_HASH Hostname, username and repo root is necessary to distinguish different backups. Test Plan: Run `test-infinitepush-*` Reviewers: durham, rmcelroy, mitrandir, quark Reviewed By: quark Subscribers: quark, mjpieters, #sourcecontrol Differential Revision: https://phabricator.intern.facebook.com/D4245080 Tasks: 12479677 Signature: t1:4245080:1480518959:aa199d67fac4e2cd2f543651ff56fdd649dac729
2016-12-01 19:44:57 +03:00
$ . "$TESTDIR/library.sh"
infinitepush: move library-infinitepush.sh to infinitepush/library.sh Summary: Makes more sense to have this structure after D6691821. Test Plan: Ran all the tests. Reviewers: quark, #mercurial, #sourcecontrol Reviewed By: quark Differential Revision: https://phabricator.intern.facebook.com/D6694171 Signature: 6694171:1515609818:1142419346e3458db7674b1b69036d88e82a1903
2018-01-10 21:44:15 +03:00
$ . "$TESTDIR/infinitepush/library.sh"
infinitepush: backup local heads and bookmarks Summary: Backuping changesets is not enougn for restore. We also want to backup heads and bookmarks to completely capture the state of the repo. This diff is the first step in implementing this functionality. It adds new bundle2 part which contains encoded dict (simple json encoding is used). If value in the dict is empty then key is the bookmark pattern to delete. If value is not empty then key is the bookmark name to save and value is a node hash. The reason to put them in the same part is to make it possible to delete and insert into indexapi in one transaction. It's also possible to pass patterns to delete in part parameters but there is a bug in upstream hg that limits parameters' size to 256 and we can potentially have longer bookmarks. Local bookmarks are saved in infinitepush in the following form: infinitepush/backups/USERNAME/HOSTNAME/REPOROOT/bookmarks/LOCAL_BOOKMARK_NAME Local heads are saved in infintiepush in the following form: infinitepush/backups/USERNAME/HOSTNAME/REPOROOTheads/HEAD_HASH Hostname, username and repo root is necessary to distinguish different backups. Test Plan: Run `test-infinitepush-*` Reviewers: durham, rmcelroy, mitrandir, quark Reviewed By: quark Subscribers: quark, mjpieters, #sourcecontrol Differential Revision: https://phabricator.intern.facebook.com/D4245080 Tasks: 12479677 Signature: t1:4245080:1480518959:aa199d67fac4e2cd2f543651ff56fdd649dac729
2016-12-01 19:44:57 +03:00
$ setupcommon
$ mkcommit() {
> echo "$1" > "$1"
> hg add "$1"
> hg ci -m "$1"
> }
$ hg init server
$ cd server
infinitepush: pass reponame to 'DELETE from bookmarkstonode...' query Summary: I forgot to insert it, fixing it now. It didn't cause problems before because we delete bookmarks only during backups and backups usually have different bookmark names Test Plan: arc unit Reviewers: #mercurial, quark Reviewed By: quark Subscribers: mjpieters, #sourcecontrol Differential Revision: https://phabricator.intern.facebook.com/D4795310 Tasks: 15389402 Signature: t1:4795310:1490810441:0a044ebe776c65b03c633017c33771d32bfa3e77
2017-03-30 11:16:06 +03:00
$ setupsqlserverhgrc babar
infinitepush: backup local heads and bookmarks Summary: Backuping changesets is not enougn for restore. We also want to backup heads and bookmarks to completely capture the state of the repo. This diff is the first step in implementing this functionality. It adds new bundle2 part which contains encoded dict (simple json encoding is used). If value in the dict is empty then key is the bookmark pattern to delete. If value is not empty then key is the bookmark name to save and value is a node hash. The reason to put them in the same part is to make it possible to delete and insert into indexapi in one transaction. It's also possible to pass patterns to delete in part parameters but there is a bug in upstream hg that limits parameters' size to 256 and we can potentially have longer bookmarks. Local bookmarks are saved in infinitepush in the following form: infinitepush/backups/USERNAME/HOSTNAME/REPOROOT/bookmarks/LOCAL_BOOKMARK_NAME Local heads are saved in infintiepush in the following form: infinitepush/backups/USERNAME/HOSTNAME/REPOROOTheads/HEAD_HASH Hostname, username and repo root is necessary to distinguish different backups. Test Plan: Run `test-infinitepush-*` Reviewers: durham, rmcelroy, mitrandir, quark Reviewed By: quark Subscribers: quark, mjpieters, #sourcecontrol Differential Revision: https://phabricator.intern.facebook.com/D4245080 Tasks: 12479677 Signature: t1:4245080:1480518959:aa199d67fac4e2cd2f543651ff56fdd649dac729
2016-12-01 19:44:57 +03:00
$ setupdb
$ cd ..
$ hg clone -q ssh://user@dummy/server client
$ cd client
$ setupsqlclienthgrc
$ mkcommit initialcommit
commitcloud: incorporate infinitepush backups into commitcloud Summary: Merge the functionality of the infinitepushbackup extension (backing up commits to commit cloud) into the commitcloud extension. These two extensions are highly coupled, and the commitcloud extension monkey-patches the infinitepushbackup extension for a lot of its functionality. There is also a lot of code duplication between the two extensions which we can remove if they are part of the same extension. The infinitepushbackup commands (`hg pushbackup`, ...) are moved to subcommands of the `hg cloud` command, e.g. `hg cloud backup`. Each feature of the infinitepushbackup extension is moved to a new module in the commit cloud extension: The `background` module controls background execution of `hg cloud backup` and `hg cloud sync`. The `backupbookmarks` module tracks and updates scratch bookmarks for backups. This will be deprecated in the future. The `backupstate` module tracks whether or not a commit has been backed up. This is now tracked separately from backup bookmarks in a new file: `.hg/commitcloud/backedupheads.<remote-identifier>`. This also covers hidden commits, preventing a re-backup of previously backed up commits when they are unhidden. Previously the commitcloud extension customized the smartlog annotations: `Backing up` became `Syncing`, etc. This is now removed for consistency. Previously the infinitepushbackup extension disabled background backup by injecting an `infinitepushbackup.disableduntil` config entry into the user's config. This is now replaced with a state file at `.hg/commitcloud/autobackup`. Either option can be set to disable auto backup. Commit cloud will wait until both have expired before starting to run background backups again. Reviewed By: DurhamG Differential Revision: D15276939 fbshipit-source-id: 1d28989a157286e47d3dd97ca9c70b27f692dda1
2019-05-20 16:11:59 +03:00
$ hg cloud backup
infinitepushbackup: back up commits stack-by-stack Summary: Use the new stack-by-stack commit backup for infinitepushbackup as well as commitcloud. Reviewed By: DurhamG Differential Revision: D8241380 fbshipit-source-id: 0c1481ad1ab5759ab642d0b02c7fe08523056292
2018-06-05 14:24:26 +03:00
backing up stack rooted at 67145f466344
infinitepush: backup local heads and bookmarks Summary: Backuping changesets is not enougn for restore. We also want to backup heads and bookmarks to completely capture the state of the repo. This diff is the first step in implementing this functionality. It adds new bundle2 part which contains encoded dict (simple json encoding is used). If value in the dict is empty then key is the bookmark pattern to delete. If value is not empty then key is the bookmark name to save and value is a node hash. The reason to put them in the same part is to make it possible to delete and insert into indexapi in one transaction. It's also possible to pass patterns to delete in part parameters but there is a bug in upstream hg that limits parameters' size to 256 and we can potentially have longer bookmarks. Local bookmarks are saved in infinitepush in the following form: infinitepush/backups/USERNAME/HOSTNAME/REPOROOT/bookmarks/LOCAL_BOOKMARK_NAME Local heads are saved in infintiepush in the following form: infinitepush/backups/USERNAME/HOSTNAME/REPOROOTheads/HEAD_HASH Hostname, username and repo root is necessary to distinguish different backups. Test Plan: Run `test-infinitepush-*` Reviewers: durham, rmcelroy, mitrandir, quark Reviewed By: quark Subscribers: quark, mjpieters, #sourcecontrol Differential Revision: https://phabricator.intern.facebook.com/D4245080 Tasks: 12479677 Signature: t1:4245080:1480518959:aa199d67fac4e2cd2f543651ff56fdd649dac729
2016-12-01 19:44:57 +03:00
remote: pushing 1 commit:
remote: 67145f466344 initialcommit
commitcloud: incorporate infinitepush backups into commitcloud Summary: Merge the functionality of the infinitepushbackup extension (backing up commits to commit cloud) into the commitcloud extension. These two extensions are highly coupled, and the commitcloud extension monkey-patches the infinitepushbackup extension for a lot of its functionality. There is also a lot of code duplication between the two extensions which we can remove if they are part of the same extension. The infinitepushbackup commands (`hg pushbackup`, ...) are moved to subcommands of the `hg cloud` command, e.g. `hg cloud backup`. Each feature of the infinitepushbackup extension is moved to a new module in the commit cloud extension: The `background` module controls background execution of `hg cloud backup` and `hg cloud sync`. The `backupbookmarks` module tracks and updates scratch bookmarks for backups. This will be deprecated in the future. The `backupstate` module tracks whether or not a commit has been backed up. This is now tracked separately from backup bookmarks in a new file: `.hg/commitcloud/backedupheads.<remote-identifier>`. This also covers hidden commits, preventing a re-backup of previously backed up commits when they are unhidden. Previously the commitcloud extension customized the smartlog annotations: `Backing up` became `Syncing`, etc. This is now removed for consistency. Previously the infinitepushbackup extension disabled background backup by injecting an `infinitepushbackup.disableduntil` config entry into the user's config. This is now replaced with a state file at `.hg/commitcloud/autobackup`. Either option can be set to disable auto backup. Commit cloud will wait until both have expired before starting to run background backups again. Reviewed By: DurhamG Differential Revision: D15276939 fbshipit-source-id: 1d28989a157286e47d3dd97ca9c70b27f692dda1
2019-05-20 16:11:59 +03:00
commitcloud: backed up 1 commit
infinitepush: backup local heads and bookmarks Summary: Backuping changesets is not enougn for restore. We also want to backup heads and bookmarks to completely capture the state of the repo. This diff is the first step in implementing this functionality. It adds new bundle2 part which contains encoded dict (simple json encoding is used). If value in the dict is empty then key is the bookmark pattern to delete. If value is not empty then key is the bookmark name to save and value is a node hash. The reason to put them in the same part is to make it possible to delete and insert into indexapi in one transaction. It's also possible to pass patterns to delete in part parameters but there is a bug in upstream hg that limits parameters' size to 256 and we can potentially have longer bookmarks. Local bookmarks are saved in infinitepush in the following form: infinitepush/backups/USERNAME/HOSTNAME/REPOROOT/bookmarks/LOCAL_BOOKMARK_NAME Local heads are saved in infintiepush in the following form: infinitepush/backups/USERNAME/HOSTNAME/REPOROOTheads/HEAD_HASH Hostname, username and repo root is necessary to distinguish different backups. Test Plan: Run `test-infinitepush-*` Reviewers: durham, rmcelroy, mitrandir, quark Reviewed By: quark Subscribers: quark, mjpieters, #sourcecontrol Differential Revision: https://phabricator.intern.facebook.com/D4245080 Tasks: 12479677 Signature: t1:4245080:1480518959:aa199d67fac4e2cd2f543651ff56fdd649dac729
2016-12-01 19:44:57 +03:00
$ mkcommit commitwithbookmark
$ hg book abook
commitcloud: incorporate infinitepush backups into commitcloud Summary: Merge the functionality of the infinitepushbackup extension (backing up commits to commit cloud) into the commitcloud extension. These two extensions are highly coupled, and the commitcloud extension monkey-patches the infinitepushbackup extension for a lot of its functionality. There is also a lot of code duplication between the two extensions which we can remove if they are part of the same extension. The infinitepushbackup commands (`hg pushbackup`, ...) are moved to subcommands of the `hg cloud` command, e.g. `hg cloud backup`. Each feature of the infinitepushbackup extension is moved to a new module in the commit cloud extension: The `background` module controls background execution of `hg cloud backup` and `hg cloud sync`. The `backupbookmarks` module tracks and updates scratch bookmarks for backups. This will be deprecated in the future. The `backupstate` module tracks whether or not a commit has been backed up. This is now tracked separately from backup bookmarks in a new file: `.hg/commitcloud/backedupheads.<remote-identifier>`. This also covers hidden commits, preventing a re-backup of previously backed up commits when they are unhidden. Previously the commitcloud extension customized the smartlog annotations: `Backing up` became `Syncing`, etc. This is now removed for consistency. Previously the infinitepushbackup extension disabled background backup by injecting an `infinitepushbackup.disableduntil` config entry into the user's config. This is now replaced with a state file at `.hg/commitcloud/autobackup`. Either option can be set to disable auto backup. Commit cloud will wait until both have expired before starting to run background backups again. Reviewed By: DurhamG Differential Revision: D15276939 fbshipit-source-id: 1d28989a157286e47d3dd97ca9c70b27f692dda1
2019-05-20 16:11:59 +03:00
$ sleep 1 # Resolution of the database is in seconds. This avoids test flakiness
$ hg cloud backup
infinitepushbackup: back up commits stack-by-stack Summary: Use the new stack-by-stack commit backup for infinitepushbackup as well as commitcloud. Reviewed By: DurhamG Differential Revision: D8241380 fbshipit-source-id: 0c1481ad1ab5759ab642d0b02c7fe08523056292
2018-06-05 14:24:26 +03:00
backing up stack rooted at 67145f466344
infinitepush: backup local heads and bookmarks Summary: Backuping changesets is not enougn for restore. We also want to backup heads and bookmarks to completely capture the state of the repo. This diff is the first step in implementing this functionality. It adds new bundle2 part which contains encoded dict (simple json encoding is used). If value in the dict is empty then key is the bookmark pattern to delete. If value is not empty then key is the bookmark name to save and value is a node hash. The reason to put them in the same part is to make it possible to delete and insert into indexapi in one transaction. It's also possible to pass patterns to delete in part parameters but there is a bug in upstream hg that limits parameters' size to 256 and we can potentially have longer bookmarks. Local bookmarks are saved in infinitepush in the following form: infinitepush/backups/USERNAME/HOSTNAME/REPOROOT/bookmarks/LOCAL_BOOKMARK_NAME Local heads are saved in infintiepush in the following form: infinitepush/backups/USERNAME/HOSTNAME/REPOROOTheads/HEAD_HASH Hostname, username and repo root is necessary to distinguish different backups. Test Plan: Run `test-infinitepush-*` Reviewers: durham, rmcelroy, mitrandir, quark Reviewed By: quark Subscribers: quark, mjpieters, #sourcecontrol Differential Revision: https://phabricator.intern.facebook.com/D4245080 Tasks: 12479677 Signature: t1:4245080:1480518959:aa199d67fac4e2cd2f543651ff56fdd649dac729
2016-12-01 19:44:57 +03:00
remote: pushing 2 commits:
remote: 67145f466344 initialcommit
remote: 5ea4271ca0f0 commitwithbookmark
commitcloud: incorporate infinitepush backups into commitcloud Summary: Merge the functionality of the infinitepushbackup extension (backing up commits to commit cloud) into the commitcloud extension. These two extensions are highly coupled, and the commitcloud extension monkey-patches the infinitepushbackup extension for a lot of its functionality. There is also a lot of code duplication between the two extensions which we can remove if they are part of the same extension. The infinitepushbackup commands (`hg pushbackup`, ...) are moved to subcommands of the `hg cloud` command, e.g. `hg cloud backup`. Each feature of the infinitepushbackup extension is moved to a new module in the commit cloud extension: The `background` module controls background execution of `hg cloud backup` and `hg cloud sync`. The `backupbookmarks` module tracks and updates scratch bookmarks for backups. This will be deprecated in the future. The `backupstate` module tracks whether or not a commit has been backed up. This is now tracked separately from backup bookmarks in a new file: `.hg/commitcloud/backedupheads.<remote-identifier>`. This also covers hidden commits, preventing a re-backup of previously backed up commits when they are unhidden. Previously the commitcloud extension customized the smartlog annotations: `Backing up` became `Syncing`, etc. This is now removed for consistency. Previously the infinitepushbackup extension disabled background backup by injecting an `infinitepushbackup.disableduntil` config entry into the user's config. This is now replaced with a state file at `.hg/commitcloud/autobackup`. Either option can be set to disable auto backup. Commit cloud will wait until both have expired before starting to run background backups again. Reviewed By: DurhamG Differential Revision: D15276939 fbshipit-source-id: 1d28989a157286e47d3dd97ca9c70b27f692dda1
2019-05-20 16:11:59 +03:00
commitcloud: backed up 1 commit
test-infinitepush: allow database password to be empty When mysql password is empty, we should not pass `-p` flag.
2017-10-17 23:05:18 +03:00
$ mysql -h $DBHOST -P $DBPORT -D $DBNAME -u $DBUSER $DBPASSOPT -e 'SELECT bookmark, node, reponame from bookmarkstonode'
infinitepush: pass reponame to 'DELETE from bookmarkstonode...' query Summary: I forgot to insert it, fixing it now. It didn't cause problems before because we delete bookmarks only during backups and backups usually have different bookmark names Test Plan: arc unit Reviewers: #mercurial, quark Reviewed By: quark Subscribers: mjpieters, #sourcecontrol Differential Revision: https://phabricator.intern.facebook.com/D4795310 Tasks: 15389402 Signature: t1:4795310:1490810441:0a044ebe776c65b03c633017c33771d32bfa3e77
2017-03-30 11:16:06 +03:00
bookmark node reponame
infinitepush/backups/test/.*\$TESTTMP/client/bookmarks/abook 5ea4271ca0f0cda5477241ae95ffc1fa7056ee6f babar (re)
infinitepush/backups/test/.*\$TESTTMP/client/heads/5ea4271ca0f0cda5477241ae95ffc1fa7056ee6f 5ea4271ca0f0cda5477241ae95ffc1fa7056ee6f babar (re)
Preserve order of revisions after hg pullbackup Summary: This diff fixes hg pullbackup so it retrieves commits in the same order that there were pushed. This was caused by commits being stored in sets and dictionare which are by unorered types. These have been replaced by OrderedDict to mantain the order. **Description of the task:** Infinitepush is a mercurial extension that allows sharing commits easily. Among other things it also backs up all local commites that were made on devservers and laptops. That means that we always have up-to-date backup You can read more about it here - https://our.intern.facebook.com/intern/dex/mercurial-workflow/infinitepush/ . Backup is triggered whenever mercurial transaction is triggered i.e. during commit, rebase or any other operation that changes mercurial repo. `hg pullbackup` is the way to pull backed up commits. There is a problem. Let's say host A has this repo: ` o` ` |` ` o C1` ` | /` ` | C2` ` | /` ` o` So we have two draft commits: C1 and C2. C2 is probably an older commit. But if we restore it on another host we can get another output: ` o` ` |` ` o C2` ` | /` ` | C1` ` | /` ` o ` This happens because `hg sl` orders commits by it's revision number in revlog - https://www.mercurial-scm.org/wiki/Revlog . The point of the task is to make sure commits are ordered by their creation date. Link to comment: http://www.facebook.com/groups/scm/permalink/1504906422892306/?comment_id=1505017576214524&reply_comment_id=1506426179406997 Reviewed By: StanislavGlebik Differential Revision: D6884670 fbshipit-source-id: 3281dbc1e25e24662a4b6ba78b96b85d5bae78c9
2018-02-06 20:57:21 +03:00
commitcloud: incorporate infinitepush backups into commitcloud Summary: Merge the functionality of the infinitepushbackup extension (backing up commits to commit cloud) into the commitcloud extension. These two extensions are highly coupled, and the commitcloud extension monkey-patches the infinitepushbackup extension for a lot of its functionality. There is also a lot of code duplication between the two extensions which we can remove if they are part of the same extension. The infinitepushbackup commands (`hg pushbackup`, ...) are moved to subcommands of the `hg cloud` command, e.g. `hg cloud backup`. Each feature of the infinitepushbackup extension is moved to a new module in the commit cloud extension: The `background` module controls background execution of `hg cloud backup` and `hg cloud sync`. The `backupbookmarks` module tracks and updates scratch bookmarks for backups. This will be deprecated in the future. The `backupstate` module tracks whether or not a commit has been backed up. This is now tracked separately from backup bookmarks in a new file: `.hg/commitcloud/backedupheads.<remote-identifier>`. This also covers hidden commits, preventing a re-backup of previously backed up commits when they are unhidden. Previously the commitcloud extension customized the smartlog annotations: `Backing up` became `Syncing`, etc. This is now removed for consistency. Previously the infinitepushbackup extension disabled background backup by injecting an `infinitepushbackup.disableduntil` config entry into the user's config. This is now replaced with a state file at `.hg/commitcloud/autobackup`. Either option can be set to disable auto backup. Commit cloud will wait until both have expired before starting to run background backups again. Reviewed By: DurhamG Differential Revision: D15276939 fbshipit-source-id: 1d28989a157286e47d3dd97ca9c70b27f692dda1
2019-05-20 16:11:59 +03:00
Create a few more commits to test that cloud restorebackup preserves order
Preserve order of revisions after hg pullbackup Summary: This diff fixes hg pullbackup so it retrieves commits in the same order that there were pushed. This was caused by commits being stored in sets and dictionare which are by unorered types. These have been replaced by OrderedDict to mantain the order. **Description of the task:** Infinitepush is a mercurial extension that allows sharing commits easily. Among other things it also backs up all local commites that were made on devservers and laptops. That means that we always have up-to-date backup You can read more about it here - https://our.intern.facebook.com/intern/dex/mercurial-workflow/infinitepush/ . Backup is triggered whenever mercurial transaction is triggered i.e. during commit, rebase or any other operation that changes mercurial repo. `hg pullbackup` is the way to pull backed up commits. There is a problem. Let's say host A has this repo: ` o` ` |` ` o C1` ` | /` ` | C2` ` | /` ` o` So we have two draft commits: C1 and C2. C2 is probably an older commit. But if we restore it on another host we can get another output: ` o` ` |` ` o C2` ` | /` ` | C1` ` | /` ` o ` This happens because `hg sl` orders commits by it's revision number in revlog - https://www.mercurial-scm.org/wiki/Revlog . The point of the task is to make sure commits are ordered by their creation date. Link to comment: http://www.facebook.com/groups/scm/permalink/1504906422892306/?comment_id=1505017576214524&reply_comment_id=1506426179406997 Reviewed By: StanislavGlebik Differential Revision: D6884670 fbshipit-source-id: 3281dbc1e25e24662a4b6ba78b96b85d5bae78c9
2018-02-06 20:57:21 +03:00
$ hg up -q 0
$ mkcommit anothercommit > /dev/null
commitcloud: incorporate infinitepush backups into commitcloud Summary: Merge the functionality of the infinitepushbackup extension (backing up commits to commit cloud) into the commitcloud extension. These two extensions are highly coupled, and the commitcloud extension monkey-patches the infinitepushbackup extension for a lot of its functionality. There is also a lot of code duplication between the two extensions which we can remove if they are part of the same extension. The infinitepushbackup commands (`hg pushbackup`, ...) are moved to subcommands of the `hg cloud` command, e.g. `hg cloud backup`. Each feature of the infinitepushbackup extension is moved to a new module in the commit cloud extension: The `background` module controls background execution of `hg cloud backup` and `hg cloud sync`. The `backupbookmarks` module tracks and updates scratch bookmarks for backups. This will be deprecated in the future. The `backupstate` module tracks whether or not a commit has been backed up. This is now tracked separately from backup bookmarks in a new file: `.hg/commitcloud/backedupheads.<remote-identifier>`. This also covers hidden commits, preventing a re-backup of previously backed up commits when they are unhidden. Previously the commitcloud extension customized the smartlog annotations: `Backing up` became `Syncing`, etc. This is now removed for consistency. Previously the infinitepushbackup extension disabled background backup by injecting an `infinitepushbackup.disableduntil` config entry into the user's config. This is now replaced with a state file at `.hg/commitcloud/autobackup`. Either option can be set to disable auto backup. Commit cloud will wait until both have expired before starting to run background backups again. Reviewed By: DurhamG Differential Revision: D15276939 fbshipit-source-id: 1d28989a157286e47d3dd97ca9c70b27f692dda1
2019-05-20 16:11:59 +03:00
$ hg cloud backup -q
Preserve order of revisions after hg pullbackup Summary: This diff fixes hg pullbackup so it retrieves commits in the same order that there were pushed. This was caused by commits being stored in sets and dictionare which are by unorered types. These have been replaced by OrderedDict to mantain the order. **Description of the task:** Infinitepush is a mercurial extension that allows sharing commits easily. Among other things it also backs up all local commites that were made on devservers and laptops. That means that we always have up-to-date backup You can read more about it here - https://our.intern.facebook.com/intern/dex/mercurial-workflow/infinitepush/ . Backup is triggered whenever mercurial transaction is triggered i.e. during commit, rebase or any other operation that changes mercurial repo. `hg pullbackup` is the way to pull backed up commits. There is a problem. Let's say host A has this repo: ` o` ` |` ` o C1` ` | /` ` | C2` ` | /` ` o` So we have two draft commits: C1 and C2. C2 is probably an older commit. But if we restore it on another host we can get another output: ` o` ` |` ` o C2` ` | /` ` | C1` ` | /` ` o ` This happens because `hg sl` orders commits by it's revision number in revlog - https://www.mercurial-scm.org/wiki/Revlog . The point of the task is to make sure commits are ordered by their creation date. Link to comment: http://www.facebook.com/groups/scm/permalink/1504906422892306/?comment_id=1505017576214524&reply_comment_id=1506426179406997 Reviewed By: StanislavGlebik Differential Revision: D6884670 fbshipit-source-id: 3281dbc1e25e24662a4b6ba78b96b85d5bae78c9
2018-02-06 20:57:21 +03:00
$ hg up -q 0
commitcloud: incorporate infinitepush backups into commitcloud Summary: Merge the functionality of the infinitepushbackup extension (backing up commits to commit cloud) into the commitcloud extension. These two extensions are highly coupled, and the commitcloud extension monkey-patches the infinitepushbackup extension for a lot of its functionality. There is also a lot of code duplication between the two extensions which we can remove if they are part of the same extension. The infinitepushbackup commands (`hg pushbackup`, ...) are moved to subcommands of the `hg cloud` command, e.g. `hg cloud backup`. Each feature of the infinitepushbackup extension is moved to a new module in the commit cloud extension: The `background` module controls background execution of `hg cloud backup` and `hg cloud sync`. The `backupbookmarks` module tracks and updates scratch bookmarks for backups. This will be deprecated in the future. The `backupstate` module tracks whether or not a commit has been backed up. This is now tracked separately from backup bookmarks in a new file: `.hg/commitcloud/backedupheads.<remote-identifier>`. This also covers hidden commits, preventing a re-backup of previously backed up commits when they are unhidden. Previously the commitcloud extension customized the smartlog annotations: `Backing up` became `Syncing`, etc. This is now removed for consistency. Previously the infinitepushbackup extension disabled background backup by injecting an `infinitepushbackup.disableduntil` config entry into the user's config. This is now replaced with a state file at `.hg/commitcloud/autobackup`. Either option can be set to disable auto backup. Commit cloud will wait until both have expired before starting to run background backups again. Reviewed By: DurhamG Differential Revision: D15276939 fbshipit-source-id: 1d28989a157286e47d3dd97ca9c70b27f692dda1
2019-05-20 16:11:59 +03:00
$ sleep 1 # Resolution of the database is in seconds. This avoids test flakiness
Preserve order of revisions after hg pullbackup Summary: This diff fixes hg pullbackup so it retrieves commits in the same order that there were pushed. This was caused by commits being stored in sets and dictionare which are by unorered types. These have been replaced by OrderedDict to mantain the order. **Description of the task:** Infinitepush is a mercurial extension that allows sharing commits easily. Among other things it also backs up all local commites that were made on devservers and laptops. That means that we always have up-to-date backup You can read more about it here - https://our.intern.facebook.com/intern/dex/mercurial-workflow/infinitepush/ . Backup is triggered whenever mercurial transaction is triggered i.e. during commit, rebase or any other operation that changes mercurial repo. `hg pullbackup` is the way to pull backed up commits. There is a problem. Let's say host A has this repo: ` o` ` |` ` o C1` ` | /` ` | C2` ` | /` ` o` So we have two draft commits: C1 and C2. C2 is probably an older commit. But if we restore it on another host we can get another output: ` o` ` |` ` o C2` ` | /` ` | C1` ` | /` ` o ` This happens because `hg sl` orders commits by it's revision number in revlog - https://www.mercurial-scm.org/wiki/Revlog . The point of the task is to make sure commits are ordered by their creation date. Link to comment: http://www.facebook.com/groups/scm/permalink/1504906422892306/?comment_id=1505017576214524&reply_comment_id=1506426179406997 Reviewed By: StanislavGlebik Differential Revision: D6884670 fbshipit-source-id: 3281dbc1e25e24662a4b6ba78b96b85d5bae78c9
2018-02-06 20:57:21 +03:00
$ mkcommit anothercommit2 > /dev/null
commitcloud: incorporate infinitepush backups into commitcloud Summary: Merge the functionality of the infinitepushbackup extension (backing up commits to commit cloud) into the commitcloud extension. These two extensions are highly coupled, and the commitcloud extension monkey-patches the infinitepushbackup extension for a lot of its functionality. There is also a lot of code duplication between the two extensions which we can remove if they are part of the same extension. The infinitepushbackup commands (`hg pushbackup`, ...) are moved to subcommands of the `hg cloud` command, e.g. `hg cloud backup`. Each feature of the infinitepushbackup extension is moved to a new module in the commit cloud extension: The `background` module controls background execution of `hg cloud backup` and `hg cloud sync`. The `backupbookmarks` module tracks and updates scratch bookmarks for backups. This will be deprecated in the future. The `backupstate` module tracks whether or not a commit has been backed up. This is now tracked separately from backup bookmarks in a new file: `.hg/commitcloud/backedupheads.<remote-identifier>`. This also covers hidden commits, preventing a re-backup of previously backed up commits when they are unhidden. Previously the commitcloud extension customized the smartlog annotations: `Backing up` became `Syncing`, etc. This is now removed for consistency. Previously the infinitepushbackup extension disabled background backup by injecting an `infinitepushbackup.disableduntil` config entry into the user's config. This is now replaced with a state file at `.hg/commitcloud/autobackup`. Either option can be set to disable auto backup. Commit cloud will wait until both have expired before starting to run background backups again. Reviewed By: DurhamG Differential Revision: D15276939 fbshipit-source-id: 1d28989a157286e47d3dd97ca9c70b27f692dda1
2019-05-20 16:11:59 +03:00
$ hg cloud backup -q
Preserve order of revisions after hg pullbackup Summary: This diff fixes hg pullbackup so it retrieves commits in the same order that there were pushed. This was caused by commits being stored in sets and dictionare which are by unorered types. These have been replaced by OrderedDict to mantain the order. **Description of the task:** Infinitepush is a mercurial extension that allows sharing commits easily. Among other things it also backs up all local commites that were made on devservers and laptops. That means that we always have up-to-date backup You can read more about it here - https://our.intern.facebook.com/intern/dex/mercurial-workflow/infinitepush/ . Backup is triggered whenever mercurial transaction is triggered i.e. during commit, rebase or any other operation that changes mercurial repo. `hg pullbackup` is the way to pull backed up commits. There is a problem. Let's say host A has this repo: ` o` ` |` ` o C1` ` | /` ` | C2` ` | /` ` o` So we have two draft commits: C1 and C2. C2 is probably an older commit. But if we restore it on another host we can get another output: ` o` ` |` ` o C2` ` | /` ` | C1` ` | /` ` o ` This happens because `hg sl` orders commits by it's revision number in revlog - https://www.mercurial-scm.org/wiki/Revlog . The point of the task is to make sure commits are ordered by their creation date. Link to comment: http://www.facebook.com/groups/scm/permalink/1504906422892306/?comment_id=1505017576214524&reply_comment_id=1506426179406997 Reviewed By: StanislavGlebik Differential Revision: D6884670 fbshipit-source-id: 3281dbc1e25e24662a4b6ba78b96b85d5bae78c9
2018-02-06 20:57:21 +03:00
$ hg log -T '{rev}:{node}\n'
3:e1c1c1f2871f70bd24f941ebfec59f14adf7a13d
2:f0d24965f49e87fc581a603dee76196f433444ff
1:5ea4271ca0f0cda5477241ae95ffc1fa7056ee6f
0:67145f4663446a9580364f70034fea6e21293b6f
Pull backup and check that commits are in the same order
$ cd ..
$ hg clone -q ssh://user@dummy/server client2
$ cd client2
commitcloud: incorporate infinitepush backups into commitcloud Summary: Merge the functionality of the infinitepushbackup extension (backing up commits to commit cloud) into the commitcloud extension. These two extensions are highly coupled, and the commitcloud extension monkey-patches the infinitepushbackup extension for a lot of its functionality. There is also a lot of code duplication between the two extensions which we can remove if they are part of the same extension. The infinitepushbackup commands (`hg pushbackup`, ...) are moved to subcommands of the `hg cloud` command, e.g. `hg cloud backup`. Each feature of the infinitepushbackup extension is moved to a new module in the commit cloud extension: The `background` module controls background execution of `hg cloud backup` and `hg cloud sync`. The `backupbookmarks` module tracks and updates scratch bookmarks for backups. This will be deprecated in the future. The `backupstate` module tracks whether or not a commit has been backed up. This is now tracked separately from backup bookmarks in a new file: `.hg/commitcloud/backedupheads.<remote-identifier>`. This also covers hidden commits, preventing a re-backup of previously backed up commits when they are unhidden. Previously the commitcloud extension customized the smartlog annotations: `Backing up` became `Syncing`, etc. This is now removed for consistency. Previously the infinitepushbackup extension disabled background backup by injecting an `infinitepushbackup.disableduntil` config entry into the user's config. This is now replaced with a state file at `.hg/commitcloud/autobackup`. Either option can be set to disable auto backup. Commit cloud will wait until both have expired before starting to run background backups again. Reviewed By: DurhamG Differential Revision: D15276939 fbshipit-source-id: 1d28989a157286e47d3dd97ca9c70b27f692dda1
2019-05-20 16:11:59 +03:00
$ hg cloud restore -q
Preserve order of revisions after hg pullbackup Summary: This diff fixes hg pullbackup so it retrieves commits in the same order that there were pushed. This was caused by commits being stored in sets and dictionare which are by unorered types. These have been replaced by OrderedDict to mantain the order. **Description of the task:** Infinitepush is a mercurial extension that allows sharing commits easily. Among other things it also backs up all local commites that were made on devservers and laptops. That means that we always have up-to-date backup You can read more about it here - https://our.intern.facebook.com/intern/dex/mercurial-workflow/infinitepush/ . Backup is triggered whenever mercurial transaction is triggered i.e. during commit, rebase or any other operation that changes mercurial repo. `hg pullbackup` is the way to pull backed up commits. There is a problem. Let's say host A has this repo: ` o` ` |` ` o C1` ` | /` ` | C2` ` | /` ` o` So we have two draft commits: C1 and C2. C2 is probably an older commit. But if we restore it on another host we can get another output: ` o` ` |` ` o C2` ` | /` ` | C1` ` | /` ` o ` This happens because `hg sl` orders commits by it's revision number in revlog - https://www.mercurial-scm.org/wiki/Revlog . The point of the task is to make sure commits are ordered by their creation date. Link to comment: http://www.facebook.com/groups/scm/permalink/1504906422892306/?comment_id=1505017576214524&reply_comment_id=1506426179406997 Reviewed By: StanislavGlebik Differential Revision: D6884670 fbshipit-source-id: 3281dbc1e25e24662a4b6ba78b96b85d5bae78c9
2018-02-06 20:57:21 +03:00
$ hg log -T '{rev}:{node}\n'
3:e1c1c1f2871f70bd24f941ebfec59f14adf7a13d
2:f0d24965f49e87fc581a603dee76196f433444ff
1:5ea4271ca0f0cda5477241ae95ffc1fa7056ee6f
0:67145f4663446a9580364f70034fea6e21293b6f
infinitepush: pass reponame to 'DELETE from bookmarkstonode...' query Summary: I forgot to insert it, fixing it now. It didn't cause problems before because we delete bookmarks only during backups and backups usually have different bookmark names Test Plan: arc unit Reviewers: #mercurial, quark Reviewed By: quark Subscribers: mjpieters, #sourcecontrol Differential Revision: https://phabricator.intern.facebook.com/D4795310 Tasks: 15389402 Signature: t1:4795310:1490810441:0a044ebe776c65b03c633017c33771d32bfa3e77
2017-03-30 11:16:06 +03:00
Create a server with different name that connects to the same db
$ cd ..
$ rm -rf server
$ hg init server
$ cd server
$ setupsqlserverhgrc newserver
$ echo "sqlhost=$DBHOST:$DBPORT:$DBNAME:$DBUSER:$DBPASS" >> .hg/hgrc
Go to client, delete backup state and run pushbackup. Make sure that it doesn't delete entries from another repo
$ cd ../client
infinitepush backup: separate depends on the remote infinitepush path Summary: We are going to support 2 different backends of Commit Cloud: Mercurial and Mononoke. Each of them should maintain local backup state separately. Output of some tests have been slightly changes, this is because a separate backup state, the same error appears earlier when we are trying the backup stacks. The idea is to have separate backup states for different remote paths, but there will be only one cloud sync state for the current source of truth. We could include there the remote path and then validate that cloud sync state is correct if the remote path has been changed. However, for backup states it is much easier to have them separately (and we will backup in 2 places) Reviewed By: markbt Differential Revision: D14138496 fbshipit-source-id: 0a7a763a395be5456cbd724bff7ebc069f03fb0e
2019-02-21 02:20:11 +03:00
$ rm -r .hg/infinitepushbackups
commitcloud: incorporate infinitepush backups into commitcloud Summary: Merge the functionality of the infinitepushbackup extension (backing up commits to commit cloud) into the commitcloud extension. These two extensions are highly coupled, and the commitcloud extension monkey-patches the infinitepushbackup extension for a lot of its functionality. There is also a lot of code duplication between the two extensions which we can remove if they are part of the same extension. The infinitepushbackup commands (`hg pushbackup`, ...) are moved to subcommands of the `hg cloud` command, e.g. `hg cloud backup`. Each feature of the infinitepushbackup extension is moved to a new module in the commit cloud extension: The `background` module controls background execution of `hg cloud backup` and `hg cloud sync`. The `backupbookmarks` module tracks and updates scratch bookmarks for backups. This will be deprecated in the future. The `backupstate` module tracks whether or not a commit has been backed up. This is now tracked separately from backup bookmarks in a new file: `.hg/commitcloud/backedupheads.<remote-identifier>`. This also covers hidden commits, preventing a re-backup of previously backed up commits when they are unhidden. Previously the commitcloud extension customized the smartlog annotations: `Backing up` became `Syncing`, etc. This is now removed for consistency. Previously the infinitepushbackup extension disabled background backup by injecting an `infinitepushbackup.disableduntil` config entry into the user's config. This is now replaced with a state file at `.hg/commitcloud/autobackup`. Either option can be set to disable auto backup. Commit cloud will wait until both have expired before starting to run background backups again. Reviewed By: DurhamG Differential Revision: D15276939 fbshipit-source-id: 1d28989a157286e47d3dd97ca9c70b27f692dda1
2019-05-20 16:11:59 +03:00
$ hg cloud backup
nothing to back up
test-infinitepush: allow database password to be empty When mysql password is empty, we should not pass `-p` flag.
2017-10-17 23:05:18 +03:00
$ mysql -h $DBHOST -P $DBPORT -D $DBNAME -u $DBUSER $DBPASSOPT -e 'SELECT bookmark, node, reponame from bookmarkstonode'
infinitepush: pass reponame to 'DELETE from bookmarkstonode...' query Summary: I forgot to insert it, fixing it now. It didn't cause problems before because we delete bookmarks only during backups and backups usually have different bookmark names Test Plan: arc unit Reviewers: #mercurial, quark Reviewed By: quark Subscribers: mjpieters, #sourcecontrol Differential Revision: https://phabricator.intern.facebook.com/D4795310 Tasks: 15389402 Signature: t1:4795310:1490810441:0a044ebe776c65b03c633017c33771d32bfa3e77
2017-03-30 11:16:06 +03:00
bookmark node reponame
infinitepush/backups/test/.*\$TESTTMP/client/bookmarks/abook 5ea4271ca0f0cda5477241ae95ffc1fa7056ee6f babar (re)
infinitepush/backups/test/.*\$TESTTMP/client/heads/5ea4271ca0f0cda5477241ae95ffc1fa7056ee6f 5ea4271ca0f0cda5477241ae95ffc1fa7056ee6f babar (re)
Preserve order of revisions after hg pullbackup Summary: This diff fixes hg pullbackup so it retrieves commits in the same order that there were pushed. This was caused by commits being stored in sets and dictionare which are by unorered types. These have been replaced by OrderedDict to mantain the order. **Description of the task:** Infinitepush is a mercurial extension that allows sharing commits easily. Among other things it also backs up all local commites that were made on devservers and laptops. That means that we always have up-to-date backup You can read more about it here - https://our.intern.facebook.com/intern/dex/mercurial-workflow/infinitepush/ . Backup is triggered whenever mercurial transaction is triggered i.e. during commit, rebase or any other operation that changes mercurial repo. `hg pullbackup` is the way to pull backed up commits. There is a problem. Let's say host A has this repo: ` o` ` |` ` o C1` ` | /` ` | C2` ` | /` ` o` So we have two draft commits: C1 and C2. C2 is probably an older commit. But if we restore it on another host we can get another output: ` o` ` |` ` o C2` ` | /` ` | C1` ` | /` ` o ` This happens because `hg sl` orders commits by it's revision number in revlog - https://www.mercurial-scm.org/wiki/Revlog . The point of the task is to make sure commits are ordered by their creation date. Link to comment: http://www.facebook.com/groups/scm/permalink/1504906422892306/?comment_id=1505017576214524&reply_comment_id=1506426179406997 Reviewed By: StanislavGlebik Differential Revision: D6884670 fbshipit-source-id: 3281dbc1e25e24662a4b6ba78b96b85d5bae78c9
2018-02-06 20:57:21 +03:00
infinitepush/backups/test/.*\$TESTTMP/client/heads/e1c1c1f2871f70bd24f941ebfec59f14adf7a13d e1c1c1f2871f70bd24f941ebfec59f14adf7a13d babar (re)
infinitepush/backups/test/.*\$TESTTMP/client/heads/f0d24965f49e87fc581a603dee76196f433444ff f0d24965f49e87fc581a603dee76196f433444ff babar (re)
infinitepush: pass reponame to 'DELETE from bookmarkstonode...' query Summary: I forgot to insert it, fixing it now. It didn't cause problems before because we delete bookmarks only during backups and backups usually have different bookmark names Test Plan: arc unit Reviewers: #mercurial, quark Reviewed By: quark Subscribers: mjpieters, #sourcecontrol Differential Revision: https://phabricator.intern.facebook.com/D4795310 Tasks: 15389402 Signature: t1:4795310:1490810441:0a044ebe776c65b03c633017c33771d32bfa3e77
2017-03-30 11:16:06 +03:00
infinitepush/backups/test/.*\$TESTTMP/client/bookmarks/abook 5ea4271ca0f0cda5477241ae95ffc1fa7056ee6f newserver (re)
infinitepush/backups/test/.*\$TESTTMP/client/heads/5ea4271ca0f0cda5477241ae95ffc1fa7056ee6f 5ea4271ca0f0cda5477241ae95ffc1fa7056ee6f newserver (re)
Preserve order of revisions after hg pullbackup Summary: This diff fixes hg pullbackup so it retrieves commits in the same order that there were pushed. This was caused by commits being stored in sets and dictionare which are by unorered types. These have been replaced by OrderedDict to mantain the order. **Description of the task:** Infinitepush is a mercurial extension that allows sharing commits easily. Among other things it also backs up all local commites that were made on devservers and laptops. That means that we always have up-to-date backup You can read more about it here - https://our.intern.facebook.com/intern/dex/mercurial-workflow/infinitepush/ . Backup is triggered whenever mercurial transaction is triggered i.e. during commit, rebase or any other operation that changes mercurial repo. `hg pullbackup` is the way to pull backed up commits. There is a problem. Let's say host A has this repo: ` o` ` |` ` o C1` ` | /` ` | C2` ` | /` ` o` So we have two draft commits: C1 and C2. C2 is probably an older commit. But if we restore it on another host we can get another output: ` o` ` |` ` o C2` ` | /` ` | C1` ` | /` ` o ` This happens because `hg sl` orders commits by it's revision number in revlog - https://www.mercurial-scm.org/wiki/Revlog . The point of the task is to make sure commits are ordered by their creation date. Link to comment: http://www.facebook.com/groups/scm/permalink/1504906422892306/?comment_id=1505017576214524&reply_comment_id=1506426179406997 Reviewed By: StanislavGlebik Differential Revision: D6884670 fbshipit-source-id: 3281dbc1e25e24662a4b6ba78b96b85d5bae78c9
2018-02-06 20:57:21 +03:00
infinitepush/backups/test/.*\$TESTTMP/client/heads/e1c1c1f2871f70bd24f941ebfec59f14adf7a13d e1c1c1f2871f70bd24f941ebfec59f14adf7a13d newserver (re)
infinitepush/backups/test/.*\$TESTTMP/client/heads/f0d24965f49e87fc581a603dee76196f433444ff f0d24965f49e87fc581a603dee76196f433444ff newserver (re)
infinitepush: backup local heads and bookmarks Summary: Backuping changesets is not enougn for restore. We also want to backup heads and bookmarks to completely capture the state of the repo. This diff is the first step in implementing this functionality. It adds new bundle2 part which contains encoded dict (simple json encoding is used). If value in the dict is empty then key is the bookmark pattern to delete. If value is not empty then key is the bookmark name to save and value is a node hash. The reason to put them in the same part is to make it possible to delete and insert into indexapi in one transaction. It's also possible to pass patterns to delete in part parameters but there is a bug in upstream hg that limits parameters' size to 256 and we can potentially have longer bookmarks. Local bookmarks are saved in infinitepush in the following form: infinitepush/backups/USERNAME/HOSTNAME/REPOROOT/bookmarks/LOCAL_BOOKMARK_NAME Local heads are saved in infintiepush in the following form: infinitepush/backups/USERNAME/HOSTNAME/REPOROOTheads/HEAD_HASH Hostname, username and repo root is necessary to distinguish different backups. Test Plan: Run `test-infinitepush-*` Reviewers: durham, rmcelroy, mitrandir, quark Reviewed By: quark Subscribers: quark, mjpieters, #sourcecontrol Differential Revision: https://phabricator.intern.facebook.com/D4245080 Tasks: 12479677 Signature: t1:4245080:1480518959:aa199d67fac4e2cd2f543651ff56fdd649dac729
2016-12-01 19:44:57 +03:00
#endif
Reference in New Issue Copy Permalink