Compare local working tree with remote

[Martin Albisetti]

The plugin should be able to compare the local working tree with the remote one (something similar to "missing", but with files, not revisions).

A clear use case for this would be to know what is going to be uploaded.

[Vincent Ladeuil (vila)]

Would a --dry-run option provide a good answer to your use case ?

[Martin Albisetti (beuno)]

Would this compare changes both ways?

I'm looking for something that gives me back the differences, no matter where they are.

Would it be pull or push?

[Vincent Ladeuil (vila)]

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.

[James (james-ellis-gmail)]

I would be happy with bzr upload reporting the files it is about to upload. It obviously knows this before it is going to upload.

My use case is that I have a client with a dumb server that contains test and live sites. Lots of revisions get uploaded to the test site but the live site usually gets an upload of multiple revisions (sometimes development over multiple days).
It would be nice to know what is being uploaded to a live site before it happens, to act as a failsafe around unwanted files appearing.

Thanks!