[Spice-devel] repository reorg

[Uri Lublin]

On 06/22/2011 06:00 PM, Alon Levy wrote:
> Hi All,
>
>   We currently have the following repositories:
>    spice-protocol
>    spice
>    spice-gtk

also
      spice-vdagent (for both Windows and Linux)
      spice-xpi/active-x (as mentioned below)

>
>   spice-protocol contains the following parts:
>    qxl_dev.h - required by qemu and drivers
>    controller.h - required by spice client and xpi/active-x
>    the rest - protocol definitions for server and client
>
>   spice is composed of
>    codegen - generation of marshallers, demarshallers, and defines that go into spice-protocol.
>    server - server implementation
>    client - old client implementation
>    common - shared by server and client, further subdivided to:
>     glz/lz/quic encoders and decoders
>     cache implementation
>     canvas rendering implementation
>     used by the server, old client and new client.
>
>   Inefficiencies with the current repositories:
>    1. updates to the protocol need to go to spice/spice.proto, run the codegen,
>      and put the results to spice-protocol
>    2. common exists in both spice and spice-gtk. since it hasn't been touched in
>      a while it isn't a real problem, but still the code duplication is bad and
>      in the future (3d canvas) it will be modified.
>
>   Suggested changes:
>    spice - merge spice-protocol into it
>    spice-protocol - kill it

What will you do with other components that require spice-protocol, such as 
spice-vdagent.

>    common - extract to a separate library, it's own configure, pkg-config, name it spice-render,
>     and have spice-gtk and spice (server and old client) rely on it.
>    spice-gtk - keep it as is. easier to develop with a separate configure since it doesn't contain
>    all the requirement checks for the server.

Many times changes in "common/" files come with changes in "server/" or 
"client/" files (for example, adding a parameter to an existing function, or 
adding a new function). So we're back to committing into two repositories (plus 
synchronizing their versions).

Maybe using git magic is a better solution (?).
Specifically I'm thinking of "git submodule", but there may be a better way.

Uri.