Skip to content
  • Georges Racinet's avatar
    MercurialRepositoryService, initial definition · c2b6480dbea2
    Georges Racinet authored
    This is the first definition of Mercurial (or Heptapod)
    gRPC methods. It takes the form of a dedicated service,
    in a separate `hgitaly` protobuf package.
    
    ## About the separate package
    
    The protobufs `package` directive translates directly into a
    the module name in Ruby generated code. This doesn't happen with
    Python because Python modules and packages names are derived from
    the file system layout, wich is obviously out of control of the
    code generation.
    
    Upstream's Ruby generated code is packaged in a separate gem,
    historically from the `gitaly-proto` project, and soon to be
    built from the bundled proto files within Gitaly. We are not
    not going to fork either of those, and hence we need our own
    package.
    
    At some point, we may also need to generate a Go library,
    which require a `option go_package` statement that we couldn't
    provide right away because it means choosing the appropriate
    full path (see examples in upstream GitLab proto files).
    
    A consequence of using our own protobuf package for the declaration
    itself is that we need to reference the Gitaly types with their
    fully qualified name (`.gitaly.SomeType` in absolute form). Same applies
    to the options.
    
    References:
    
    - https://developers.google.com/protocol-buffers/docs/proto3#packages
    
    - https://developers.google.com/protocol-buffers/docs/proto#customoptions
      Quote: "Note that if you want to use a custom option in a package other
      than the one in which it was defined, you must prefix the option name
      with the package name, just as you would for type names." (example
      follows)
    
    ## About MercurialRepositoryService itself
    
    This service is for Mercurial specific methods
    that are considered to be global with respect to a given
    repository.
    
    It should cover the needs of #60 and #62
    
    This follows the general Gitaly style: each method gets its own pair
    of request/response messages, even if that looks to be redundant.
    The main advantage should be to give unlimited room for future change
    that would introduce actual changes.
    
    Reference: https://gitlab.com/gitlab-org/gitaly/blob/master/proto/README.md#design-decisions
    c2b6480dbea2