Steven Bergsieker
Steven Bergsieker
This is the idea behind the ResultsCachePriority in ExecuteRequest. At the moment that's a single integer, which the server can interpret in whatever way it sees fit. In the case...
@werkt Is there something yet to be done here, or can this issue be closed?
I've considered adding something like this at several points in the past, so I'm generally supportive. Given that the field is in an optional metadata message, it's important that it...
I agree that lack of higher-order caching within the API is a problem. I think it's most interesting in the case of either built-from-source tooling within a larger build, or...
I think the right course is an enum with UNKNOWN=0, WRITEABLE, READ-ONLY as the values. It's possible there are other CAS read-only CAS implementations (e.g., local caches), and we shouldn't...
After thinking about this further, I think that we should keep SemVer for the APIs, but switch to date-based versioning for the github releases. Doing so will alleviate a lot...
> In fact, a repeated field that only has a single element is encoded exactly the same way as a singular field. When an old client unmarshals a new message...
Should we specify any concept of ordering in this repeated field? For example, if we're talking about Bazel plus one proxy, I'd probably want Bazel's information to be in position...
> > As I read that link, the "last one wins" behavior is only true for primitive types--strings and numbers. For nested messages, as is the case here, the subfields...
I'd like to get a thumbs-up from Ed and Son before merging, if possible.