Thu, 18 Jan 2018 00:45:27 +0100 streamclone: rework canperformstreamclone
Boris Feld <boris.feld@octobus.net> [Thu, 18 Jan 2018 00:45:27 +0100] rev 35757
streamclone: rework canperformstreamclone There is code about bundle2 laying around in `canperformstreamclone` but not put to any uses. As we discovered with the previous patch, streambundle 'v1' won't work on bundle2 because they are readline based. So we jump to 'v2' as the first expected supported version.
Thu, 18 Jan 2018 00:48:56 +0100 streamclone: define first iteration of version 2 of stream format
Boris Feld <boris.feld@octobus.net> [Thu, 18 Jan 2018 00:48:56 +0100] rev 35756
streamclone: define first iteration of version 2 of stream format (This patch is based on a first draft from Gregory Szorc, with deeper rework) Version 1 of the stream clone format was invented many years ago and suffers from a few deficiencies: 1) Filenames are stored in store-encoded (on filesystem) form rather than in their internal form. This makes future compatibility with new store filename encodings more difficult. 2) File entry "headers" consist of a newline of the file name followed by the string file size. Converting strings to integers is avoidable overhead. We can't store filenames with newlines (manifests have this limitation as well, so it isn't a major concern). But the big concern here is the necessity for readline(). Scanning for newlines means reading ahead and that means extra buffer allocations and slicing (in Python) and this makes performance suffer. 3) Filenames aren't compressed optimally. Filenames should be compressed well since there is a lot of repeated data. However, since they are scattered all over the stream (with revlog data in between), they typically fall outside the window size of the compressor and don't compress. 4) It can only exchange stored based content, being able to exchange caches too would be nice. 5) It is limited to a stream-based protocol and isn't suitable for an on-disk format for general repository reading because the offset of individual file entries requires scanning the entire file to find file records. As part of enabling streaming clones to work in bundle2, #2 proved to have a significant negative impact on performance. Since bundle2 provides the opportunity to start fresh, Gregory Szorc figured he would take the opportunity to invent a new streaming clone data format. The new format devised in this series addresses #1, #2, and #4. It punts on #3 because it was complex without yielding a significant gain and on #5 because devising a new store format that "packs" multiple revlogs into a single "packed revlog" is massive scope bloat. However, this v2 format might be suitable for streaming into a "packed revlog" with minimal processing. If it works, great. If not, we can always invent stream format when it is needed. This patch only introduces the bases of the format. We'll get it usable through bundle2 first, then we'll extend the format in future patches to bring it to its full potential (especially #4).
Fri, 19 Jan 2018 22:52:35 +0100 util: implement varint functions
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 19 Jan 2018 22:52:35 +0100] rev 35755
util: implement varint functions This will be useful in an incoming version-2 of the stream format.
Fri, 19 Jan 2018 20:51:35 +0100 util: move 'readexactly' in the util module
Boris Feld <boris.feld@octobus.net> [Fri, 19 Jan 2018 20:51:35 +0100] rev 35754
util: move 'readexactly' in the util module This function is used in multiple place, having it in util would be better. (existing caller will be migrated in another series)
Fri, 19 Jan 2018 19:13:11 -0500 lfs: separate a debug message from the subsequent abort message
Matt Harbison <matt_harbison@yahoo.com> [Fri, 19 Jan 2018 19:13:11 -0500] rev 35753
lfs: separate a debug message from the subsequent abort message
Fri, 19 Jan 2018 14:25:09 -0800 sshserver: add a couple of tests for argument parsing
Siddharth Agarwal <sid0@fb.com> [Fri, 19 Jan 2018 14:25:09 -0800] rev 35752
sshserver: add a couple of tests for argument parsing I noticed that we didn't have any unit tests covering wire protocol argument parsing.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -6 +6 +10 +30 +100 +300 +1000 +3000 +10000 tip