When at conferences and sprints, I often want to see what someone else is working on, or to let other people see what I am working on. Usually we end up pushing up to a shared server and using that as a way to exchange branches. However, this can be quite frustrating when competing for outside bandwidth when at a conference.
It is possible to share the branch from a local web server, but that still means you need to work out the addressing issues.
To make things easier, I wrote a simple Bazaar/Avahi plugin. It provides a command “bzr share“, which does the following:
- Scan the directory for any Bazaar branches it contains.
- Start up the Bazaar server to listen on a TCP port and share the given directory.
- Advertise each of the branches via mDNS using Avahi. They are shared using the branch nickname.
For the client side, the plugin implements a “bzr browse” command that will list the Bazaar branches being advertised on the local network (the name and the bzr:// URL). Using the two commands together, it is trivial to share branches locally or find what branches people are sharing.
I am not completely satisfied with how things work, and have a few ideas for how to improve things:
- Provide a dummy transport that lets people pull from branches by their advertised service name. This would essentially just redirect from scheme://$SERVICE/ to bzr://$HOST:$PORT/$PATH.
- Maybe provide more control over the names the branches get advertised with. Perhaps this isn’t so important though.
- Make “bzr share” start and stop advertising branches as they get added/removed, and handle branch nicknames changing (at this point, it is pretty much blue sky though).
- Perhaps some form of access control. I’m not sure how easy this is within the smart server protocol, but it should be possible to query the user over whether to accept a connection or not.
It will be interesting to see how well this works at the next sprint or conference.
Today we unveiled the