Comment 3 for bug 206770

No it will not compare both ways.

The scope of the upload plugin, IMHO, is extend bzr in the following situation:
- bzr is not available on the remote site
- the local working tree is associated with a bzr branch

From there, the plugin helps managing the remote working tree by associating a revision id, stored remotely.

The design *is* asymetric, on one end we have bzr on the other we have... nearly nothing. The trick used by the plugin is remote revision id which allows re-ynchronization with the local bzr tree.

If the remote working tree does not match the remote revision id anymore, a recovery mode is needed (the --full option aims to implement that recovery mode).

I'd say the upload plugin is a mix of 'bzr export' and 'bzr push' (with limitations on mode bits that needs to be addressed) but trying to make it handle some sort of bzr pull is outside of its scope.

The main problem I see with trying to handle more features related to the remote working tree is that... well, bzr is not available remotely and neither are all of the bzr features: the remote tree is mostly unknown.

This implies that, to compare the remote and local trees, we will need to *download* the remote tree (where do we stop ?) and store it somewhere before being able to compare it to the local tree. Sounds like a lot of bandwidth and latency barriers.