Mercurial > hg > mercurial-source
view mercurial/base85.c @ 13704:a464763e99f1
dirstate: avoid a race with multiple commits in the same process
(issue2264, issue2516)
The race happens when two commits in a row change the same file
without changing its size, *if* those two commits happen in the same
second in the same process while holding the same repo lock. For
example:
commit 1:
M a
M b
commit 2: # same process, same second, same repo lock
M b # modify b without changing its size
M c
This first manifested in transplant, which is the most common way to
do multiple commits in the same process. But it can manifest in any
script or extension that does multiple commits under the same repo
lock. (Thus, the test script tests both transplant and a custom script.)
The problem was that dirstate.status() failed to notice the change to
b when localrepo is about to do the second commit, meaning that change
gets left in the working directory. In the context of transplant, that
means either a crash ("RuntimeError: nothing committed after
transplant") or a silently inaccurate transplant, depending on whether
any other files were modified by the second transplanted changeset.
The fix is to make status() work a little harder when we have
previously marked files as clean (state 'normal') in the same process.
Specifically, dirstate.normal() adds files to self._lastnormal, and
other state-changing methods remove them. Then dirstate.status() puts
any files in self._lastnormal into state 'lookup', which will make
localrepository.status() read file contents to see if it has really
changed. So we pay a small performance penalty for the second (and
subsequent) commits in the same process, without affecting the common
case. Anything that does lots of status updates and checks in the
same process could suffer a performance hit.
Incidentally, there is a simpler fix: call dirstate.normallookup() on
every file updated by commit() at the end of the commit. The trouble
with that solution is that it imposes a performance penalty on the
common case: it means the next status-dependent hg command after every
"hg commit" will be a little bit slower. The patch here is more
complex, but only affects performance for the uncommon case.
author | Greg Ward <greg@gerg.ca> |
---|---|
date | Sun, 20 Mar 2011 17:41:09 -0400 |
parents | a4e0908ce35b |
children | a8065323c003 |
line wrap: on
line source
/* base85 codec Copyright 2006 Brendan Cully <brendan@kublai.com> This software may be used and distributed according to the terms of the GNU General Public License, incorporated herein by reference. Largely based on git's implementation */ #include <Python.h> #include "util.h" static const char b85chars[] = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ" "abcdefghijklmnopqrstuvwxyz!#$%&()*+-;<=>?@^_`{|}~"; static char b85dec[256]; static void b85prep(void) { int i; memset(b85dec, 0, sizeof(b85dec)); for (i = 0; i < sizeof(b85chars); i++) b85dec[(int)(b85chars[i])] = i + 1; } static PyObject * b85encode(PyObject *self, PyObject *args) { const unsigned char *text; PyObject *out; char *dst; int len, olen, i; unsigned int acc, val, ch; int pad = 0; if (!PyArg_ParseTuple(args, "s#|i", &text, &len, &pad)) return NULL; if (pad) olen = ((len + 3) / 4 * 5) - 3; else { olen = len % 4; if (olen) olen++; olen += len / 4 * 5; } if (!(out = PyBytes_FromStringAndSize(NULL, olen + 3))) return NULL; dst = PyBytes_AsString(out); while (len) { acc = 0; for (i = 24; i >= 0; i -= 8) { ch = *text++; acc |= ch << i; if (--len == 0) break; } for (i = 4; i >= 0; i--) { val = acc % 85; acc /= 85; dst[i] = b85chars[val]; } dst += 5; } if (!pad) _PyBytes_Resize(&out, olen); return out; } static PyObject * b85decode(PyObject *self, PyObject *args) { PyObject *out; const char *text; char *dst; int len, i, j, olen, c, cap; unsigned int acc; if (!PyArg_ParseTuple(args, "s#", &text, &len)) return NULL; olen = len / 5 * 4; i = len % 5; if (i) olen += i - 1; if (!(out = PyBytes_FromStringAndSize(NULL, olen))) return NULL; dst = PyBytes_AsString(out); i = 0; while (i < len) { acc = 0; cap = len - i - 1; if (cap > 4) cap = 4; for (j = 0; j < cap; i++, j++) { c = b85dec[(int)*text++] - 1; if (c < 0) return PyErr_Format( PyExc_ValueError, "Bad base85 character at position %d", i); acc = acc * 85 + c; } if (i++ < len) { c = b85dec[(int)*text++] - 1; if (c < 0) return PyErr_Format( PyExc_ValueError, "Bad base85 character at position %d", i); /* overflow detection: 0xffffffff == "|NsC0", * "|NsC" == 0x03030303 */ if (acc > 0x03030303 || (acc *= 85) > 0xffffffff - c) return PyErr_Format( PyExc_ValueError, "Bad base85 sequence at position %d", i); acc += c; } cap = olen < 4 ? olen : 4; olen -= cap; for (j = 0; j < 4 - cap; j++) acc *= 85; if (cap && cap < 4) acc += 0xffffff >> (cap - 1) * 8; for (j = 0; j < cap; j++) { acc = (acc << 8) | (acc >> 24); *dst++ = acc; } } return out; } static char base85_doc[] = "Base85 Data Encoding"; static PyMethodDef methods[] = { {"b85encode", b85encode, METH_VARARGS, "Encode text in base85.\n\n" "If the second parameter is true, pad the result to a multiple of " "five characters.\n"}, {"b85decode", b85decode, METH_VARARGS, "Decode base85 text.\n"}, {NULL, NULL} }; #ifdef IS_PY3K static struct PyModuleDef base85_module = { PyModuleDef_HEAD_INIT, "base85", base85_doc, -1, methods }; PyMODINIT_FUNC PyInit_base85(void) { b85prep(); return PyModule_Create(&base85_module); } #else PyMODINIT_FUNC initbase85(void) { Py_InitModule3("base85", methods, base85_doc); b85prep(); } #endif