largefiles: reuse hexsha1() to centralize hash calculation logic into it This patch also renames argument of hexsha1(), not only for readability ("data" isn't good name for file-like object), but also for reviewability (including hexsha1() code helps reviewers to confirm how these functions are similar). BTW, copyandhash() has also similar logic, but it can't reuse hexsha1(), because it writes read-in data into specified fileobj simultaneously.

py3: prove second commit works Finally it works.

py3: fix manifestdict.fastdelta() to be compatible with memoryview This doesn't look nice, but a straightforward way to support Python 3. bytes(m[start:end]) is needed because a memoryview doesn't support ordering operations. On Python 2, m[start:end] returns a bytes object even if m is a buffer, so calling bytes() should involve no additional copy. I'm tired of trying cleaner alternatives, including: a. extend memoryview to be compatible with buffer type => memoryview is not an acceptable base type b. wrap memoryview by buffer-like class => zlib complains it isn't bytes-like

crecord: use ProgrammingError

transaction: use ProgrammingError

bundle2: use ProgrammingError

merge: use ProgrammingError

repair: use ProgrammingError

py3: abuse r'' to preserve str-ness of literals passed to __setattr__()

py3: fix slicing of byte string in revlog.compress() I tried .startswith('\0'), but data wasn't always a bytes nor a bytearray.