This looks good to me. Greg?
I think the rest of the stack from this patch are independent of the ones before, so if reviewers are intimidated by D6255, they should still be able to take this section of the stack.
This series looks reasonable to me, but I have no experience with this code. Anyone else feels like reviewing? Otherwise I'll probably just queue it in a day or two.
Tue, Apr 23
Mon, Apr 22
I don't like to queue patches that are written mainly for Google's benefit, but it's been a month and we haven't heard any complaints. I'll start reviewing this now and will queue it when I'm done (assuming I have no major comments, of course).
Sun, Apr 21
Fri, Apr 19
Thu, Apr 18
An idea to consider (which may have been proposed already) is to write a *no copy metadata* entry into extras when writing copy metadata to the changelog. If we did things this way, a new client could know definitively that no copy metadata is available and to not fall back to reading from the filelogs. I haven't fully thought this through, but that should provide better compatibility between older and newer clients. Obviously the tradeoff is you could have a mixed repo (some changesets wouldn't have copy metadata in changelog) and you would need to duplicate copy metadata across changelog and filelogs to maintain compatibility. Something to contemplate...
I support experimenting with putting copy metadata in the changelog. And the patches before this one did a lot of work to allow copy metadata to be read from alternate sources, which is great, since it can allow flexibility in the future (think copy caches, copy modifications outside of a commit, etc).
Wed, Apr 17
I haven't run tests on this, but I'm guessing one of the test-check* tests will tell you that your subject line ("Typos") does not follow our style guide (you could change it to something like "setdiscovery: fix a few typos").
Yes, I also considered that. I wasn't sure what a good name for the method would be and I gave up. I'll try again.