[RFC] tortoise implementation design

[Martin Pool]

On Tue, May 20, 2008 at 10:42 AM, Mark Hammond
<mhammond at skippinet.com.au> wrote:
> Hi all,
>  I've been following up the strategy document with some thoughts about the
> implementation of tbzr, particularly the RPC mechanism used between the C++
> client and the Python server.  In many ways it extends the "strategy"
> document, but I think it makes the most sense to keep this as a separate
> document - please let me know if you think otherwise.
>
> All feedback appreciated!

I'm not an expect there but it seems to make sense to me.

You raise some issues in there like per-user installs, that should
probably be directed to prospective users of the extension; they might
be unlikely to read them in the protocol document and so you could
consider sending a separate mail with just user-oriented questions.
For myself I think your first priority should be to get the basic
functions working and released, even if there are restrictions such as
needing a system-wide install.

> Thus, a structure like:
>
>  struct Foo {
>    int a;
>    wchar *str;
>  };

You need two colons at the end of the first line for ReST syntax, or
the rest of the document turns into italics.

> The general form of the wire protocol will be very simple serialization
> of binary data.  Each request and response will include the size of the

This serialization is OK with me if you think it's simple to implement
and sufficient.  However, I would strongly suggest that there is a
one-line identification at the start of the connection to detect
version mismatches and allow for replacing it later.

>  if there are 2 files selected, the entire folder is used in some cases?

Maybe (a pure guess) for speed they read back the status of the whole
folder to avoid roundtrips.



> In the meantime, I've been chatting with Alex Haro (who did the current tbzr
> implementation) and he created a new team
> (https://launchpad.net/~tortoisebzr-developers) and our current thinking is
> to create a team branch and work from that.  I'm a little concerned though
> that using a team branch implies we can't (or are discouraged from) making
> local branches, and instead should perform a checkout.  My lack of bzr
> experience is letting me down again, so I thought I'd ask for some advice
> here: are there recommendations for how to best manage the code for this
> work?  Maybe I should create a personal branch to work from, and the team
> branch is merged to only when stable?

Having a team branch is completely compatible with using your own
branches.  Typically you will have personal development branches, and
a team-owned main branch.  You will originally make your changes on a
personal branch devoted to that bug or feature.  There is no need to
push these unless you want to.  When the work is finished you might
get it reviewed.  Once it is landed, it can be merged into the main
branch.  This setup means that anyone can merge to the main branch.

Does that make sense?  Maybe this needs to be explained more in the
bzr and/or Launchpad user guide.


-- 
Martin <http://launchpad.net/~mbp/>