Stacked branching question

[Martin Pool]

On 7/22/08, Nicholas Allen <allen at ableton.com> wrote:
>  Aaron Bentley wrote:
>  | Nicholas Allen wrote:
>  | > I always thought the idea of a global cache of revisions would make
>  | > sense.
>  |
>  | We do not.  We want to make sure data doesn't get lost, and a global
>  | cache makes that far, far too easy.
>  How does data get lost by having a global cache? I don't understand your
> point. I am not suggesting that data would *only* be stored in the global
> cache but *also* be stored there. Therefore data is actually less likely to
> be lost and not more likely. It's just when retrieving a revision it would
> first check the cache so it doesn't have to go over the network - it would
> exist only to reduce network transmissions. Once it gets the revision (from
> the cache or remotely) it would be stored in the branch's repository as it
> normally would. If it did not have it in the cache it would download it, add
> it to the cache, and return it. The caller would not know if it came from
> the cache or was really downloaded.

The name 'cache' seems to imply it's something from which data can be
evicted to reduce space etc.  As long as we make sure it's guaranteed
to be also stored somewhere else appropriate this should be no
problem.

Of course this would mean some data will be stored twice on the
client, once in the cache and once in the real local repository.  And
even if it's only a cache the behaviour might be confusing if for
example sometimes you can see all of history on your laptop, but when
a cache purge happens you no longer can.

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