##// END OF EJS Templates
repair: migrate revlogs during upgrade...
repair: migrate revlogs during upgrade Our next step for in-place upgrade is to migrate store data. Revlogs are the biggest source of data within the store and a store is useless without them, so we implement their migration first. Our strategy for migrating revlogs is to walk the store and call `revlog.clone()` on each revlog. There are some minor complications. Because revlogs have different storage options (e.g. changelog has generaldelta and delta chains disabled), we need to obtain the correct class of revlog so inserted data is encoded properly for its type. Various attempts at implementing progress indicators that didn't lead to frustration from false "it's almost done" indicators were made. I initially used a single progress bar based on number of revlogs. However, this quickly churned through all filelogs, got to 99% then effectively froze at 99.99% when it got to the manifest. So I converted the progress bar to total revision count. This was a little bit better. But the manifest was still significantly slower than filelogs and it took forever to process the last few percent. I then tried both revision/chunk bytes and raw bytes as the denominator. This had the opposite effect: because so much data is in manifests, it would churn through filelogs without showing much progress. When it got to manifests, it would fill in 90+% of the progress bar. I finally gave up having a unified progress bar and instead implemented 3 progress bars: 1 for filelog revisions, 1 for manifest revisions, and 1 for changelog revisions. I added extra messages indicating the total number of revisions of each so users know there are more progress bars coming. I also added extra messages before and after each stage to give extra details about what is happening. Strictly speaking, this isn't necessary. But the numbers are impressive. For example, when converting a non-generaldelta mozilla-central repository, the messages you see are: migrating 2475593 total revisions (1833043 in filelogs, 321156 in manifests, 321394 in changelog) migrating 1.67 GB in store; 2508 GB tracked data migrating 267868 filelogs containing 1833043 revisions (1.09 GB in store; 57.3 GB tracked data) finished migrating 1833043 filelog revisions across 267868 filelogs; change in size: -415776 bytes migrating 1 manifests containing 321156 revisions (518 MB in store; 2451 GB tracked data) That "2508 GB" figure really blew me away. I had no clue that the raw tracked data in mozilla-central was that large. Granted, 2451 GB is in the manifest and "only" 57.3 GB is in filelogs. But still. It's worth noting that gratuitous loading of source revlogs in order to display numbers and progress bars does serve a purpose: it ensures we can open all source revlogs. We don't want to spend several minutes copying revlogs only to encounter a permissions error or similar later. As part of this commit, we also add swapping of the store directory to the upgrade function. After revlogs are converted, we move the old store into the backup directory then move the temporary repo's store into the old store's location. On well-behaved systems, this should be 2 atomic operations and the window of inconsistency show be very narrow. There are still a few improvements to be made to store copying and upgrading. But this commit gets the bulk of the work out of the way.

File last commit:

r29019:210bb28c stable
r30779:38aa1ca9 default
Show More
exewrapper.c
175 lines | 4.4 KiB | text/x-c | CLexer
/*
exewrapper.c - wrapper for calling a python script on Windows
Copyright 2012 Adrian Buehlmann <adrian@cadifra.com> and others
This software may be used and distributed according to the terms of the
GNU General Public License version 2 or any later version.
*/
#include <stdio.h>
#include <windows.h>
#include "hgpythonlib.h"
#ifdef __GNUC__
int strcat_s(char *d, size_t n, const char *s)
{
return !strncat(d, s, n);
}
int strcpy_s(char *d, size_t n, const char *s)
{
return !strncpy(d, s, n);
}
#endif
static char pyscript[MAX_PATH + 10];
static char pyhome[MAX_PATH + 10];
static char envpyhome[MAX_PATH + 10];
static char pydllfile[MAX_PATH + 10];
int main(int argc, char *argv[])
{
char *p;
int ret;
int i;
int n;
char **pyargv;
WIN32_FIND_DATA fdata;
HANDLE hfind;
const char *err;
HMODULE pydll;
void (__cdecl *Py_SetPythonHome)(char *home);
int (__cdecl *Py_Main)(int argc, char *argv[]);
if (GetModuleFileName(NULL, pyscript, sizeof(pyscript)) == 0)
{
err = "GetModuleFileName failed";
goto bail;
}
p = strrchr(pyscript, '.');
if (p == NULL) {
err = "malformed module filename";
goto bail;
}
*p = 0; /* cut trailing ".exe" */
strcpy_s(pyhome, sizeof(pyhome), pyscript);
hfind = FindFirstFile(pyscript, &fdata);
if (hfind != INVALID_HANDLE_VALUE) {
/* pyscript exists, close handle */
FindClose(hfind);
} else {
/* file pyscript isn't there, take <pyscript>exe.py */
strcat_s(pyscript, sizeof(pyscript), "exe.py");
}
pydll = NULL;
/*
We first check, that environment variable PYTHONHOME is *not* set.
This just mimicks the behavior of the regular python.exe, which uses
PYTHONHOME to find its installation directory (if it has been set).
Note: Users of HackableMercurial are expected to *not* set PYTHONHOME!
*/
if (GetEnvironmentVariable("PYTHONHOME", envpyhome,
sizeof(envpyhome)) == 0)
{
/*
Environment var PYTHONHOME is *not* set. Let's see if we are
running inside a HackableMercurial.
*/
p = strrchr(pyhome, '\\');
if (p == NULL) {
err = "can't find backslash in module filename";
goto bail;
}
*p = 0; /* cut at directory */
/* check for private Python of HackableMercurial */
strcat_s(pyhome, sizeof(pyhome), "\\hg-python");
hfind = FindFirstFile(pyhome, &fdata);
if (hfind != INVALID_HANDLE_VALUE) {
/* path pyhome exists, let's use it */
FindClose(hfind);
strcpy_s(pydllfile, sizeof(pydllfile), pyhome);
strcat_s(pydllfile, sizeof(pydllfile),
"\\" HGPYTHONLIB ".dll");
pydll = LoadLibrary(pydllfile);
if (pydll == NULL) {
err = "failed to load private Python DLL "
HGPYTHONLIB ".dll";
goto bail;
}
Py_SetPythonHome = (void*)GetProcAddress(pydll,
"Py_SetPythonHome");
if (Py_SetPythonHome == NULL) {
err = "failed to get Py_SetPythonHome";
goto bail;
}
Py_SetPythonHome(pyhome);
}
}
if (pydll == NULL) {
pydll = LoadLibrary(HGPYTHONLIB ".dll");
if (pydll == NULL) {
err = "failed to load Python DLL " HGPYTHONLIB ".dll";
goto bail;
}
}
Py_Main = (void*)GetProcAddress(pydll, "Py_Main");
if (Py_Main == NULL) {
err = "failed to get Py_Main";
goto bail;
}
/*
Only add the pyscript to the args, if it's not already there. It may
already be there, if the script spawned a child process of itself, in
the same way as it got called, that is, with the pyscript already in
place. So we optionally accept the pyscript as the first argument
(argv[1]), letting our exe taking the role of the python interpreter.
*/
if (argc >= 2 && strcmp(argv[1], pyscript) == 0) {
/*
pyscript is already in the args, so there is no need to copy
the args and we can directly call the python interpreter with
the original args.
*/
return Py_Main(argc, argv);
}
/*
Start assembling the args for the Python interpreter call. We put the
name of our exe (argv[0]) in the position where the python.exe
canonically is, and insert the pyscript next.
*/
pyargv = malloc((argc + 5) * sizeof(char*));
if (pyargv == NULL) {
err = "not enough memory";
goto bail;
}
n = 0;
pyargv[n++] = argv[0];
pyargv[n++] = pyscript;
/* copy remaining args from the command line */
for (i = 1; i < argc; i++)
pyargv[n++] = argv[i];
/* argv[argc] is guaranteed to be NULL, so we forward that guarantee */
pyargv[n] = NULL;
ret = Py_Main(n, pyargv); /* The Python interpreter call */
free(pyargv);
return ret;
bail:
fprintf(stderr, "abort: %s\n", err);
return 255;
}