"bzr missing" should store the downloaded data in order to make "pull" (and "missing") faster

[Daniel Clemente]

Tested with http://bzr.notengoamigos.org/emacs/trunk/ (format: pack-0.92) with bzr.dev from right now.

After some time without updating:
- bzr missing → downloads 3 Mb
- bzr missing (right after that) → downloads the 3 Mb again
- bzr missing → again the 3 Mb, etc.
- bzr pull → must download a lot of data again (>3 Mb)

After the first "missing", the downloaded data could be stored in the local branch, so that successive calls to "missing" do only a remote check to confirm that there's nothing else (or download just the differences).
A "pull" after the "missing" could also be instantaneous.

This is similar to what git does: "git fetch" downloads the data. Then "git pull" is instantaneous.

[Wesley J. Landaker (wjl)]

I also would really like this.

One concern that one might have is that if you run missing on a lot of branches and don't then pull/merge from them, it will fill up your local repository with lots of junk.

I still think having missing pull in the data is a good default, though, as network access is generally more expensive than disk space, and doing pull after missing is probably a very typical case. Even if it's not the default, there should be a way to save the data, like "bzr missing --save" for example (that name isn't great, but you get the idea).

Any wasted space in the repository wouldn't be much worse than what you get if you uncommit all the time, or use a shared repository with dead-end branches, and can be cleaned the usual way by re-branching. A "bzr gc"-type operation--which we need eventually anyway--would make this workaround unnecessary.

[Matthew Fuller (fullermd)]

I probably push after missing more often than I pull after missing. Would you suggest it sync both ways?

[Martin Pool (mbp)]

There is a need for a better way to automatically keep an up-to-date mirror of a remote branch so you can easily work with it.

However making a logically read-only operation like missing actually copy data around is not the direction we want to go.

I would instead suggest having, inside the same directory, a mirror of the remote branch, pulling into that, then running missing etc.

[Daniel Clemente (n142857)]

I agree. Then it shouldn't be "missing" who stores revisions, but a generic revision cache which can be triggered by "missing" and others.
Bug 328088 is about having that cache.