RFC: Always use remote branches?

[Martin Pool]

On Mon, Nov 17, 2008 at 3:30 PM, Robert Collins
<robertc at robertcollins.net> wrote:
> Here are the downsides I see:
>  - in-process will work badly (python isn't really threaded)

No, but it is at least somewhat able to do coroutines.  I've been
saying for a while that it would be nice to be able in testing to
execute Remote requests inprocess and synchronously, and it would also
make sense for this kind of ad-hoc testing.  Streaming requests will
be a bit complex but possible.  If we added bidirectional streaming it
would require some more magic: either python2.6 bidirectional yield(),
some kind of twisted-like callback mechanism, or something else.

>  - out-process requires another large-fraction-of-a-second to startup
>  - on uniprocessor machines we're adding serialised serialisation and
>   deserialisation of all our branch and history data
>  - there is extra complexity (such as making sure we run the same bzr
>   again for out-process stuff) which could lead to bugs or issues.

So we could, without going to serialization, at least have everything
go through the same functional bottleneck, but in process simply
evaluate it rather than serializing it.  I don't really see enough
benefit to motivate it though - as Robert notes, it won't be any
faster on a multicore machine unless we take the considerable lump of
starting an external process.  If there are ways to reduce code by
taking this approach it would be great, but not at the expense of
making either the local or remote scenario substantially slower.

For testing, I think having a loopback+file:///foo/ optionally
available would be a good start.

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