[RFC] Caching in Stacked Branches

[Alexander Belchenko]

John Arbash Meinel пишет:
> At the moment stacked branches only contain what you have pushed into
> them. Which means they work fairly well for "publishing" (bzr push
> --stacked).
> 
> There is another use for stacked branches, which is the "get me the tip
> of a project so I can make a quick patch". As an example, to branch
> "python/trunk" takes about 200+ MB to download. By comparison, doing
> "bzr branch --stacked" only really needs to download about 21MB to get
> all of the working files.

I guess this is related to old specs called HistoryHorizon and/or ShallowBranches?

> The downside, though, is that you download that 21MB, and then have to
> download it *again* whenever doing any more work. (Such as during,
> commit, diff, etc.)

My first reaction is: why you don't store the data you already has at branch time?
It's ... it's just not wise.

IIUC roughly the same thing used in svn: it holds "cace" of pristine copies of
all checked out files, so it don't need to ask server for plain svn diff. It's correct?

> One fairly obvious possibility, would be to have Stacked branches cache
> any data that gets requested from a fallback.
> 
> I was looking into it in the past, and the problem is that stuff like
> "diff" only has a read lock, and to insert things into the repo, you
> really need a write_lock() + start_commit_group().
> 
> We could add a new locking, which would be aware of wanting to cache
> things in the stacked branch.
> 
> Any thoughts? It would be pretty slick if doing:

I guess it was discussed in the past by the name "load data by demand".
I'm not familiar with Arch, but from what I've read in this ML I guess
Arch has this feature.

> 
>  bzr branch --stacked $BIG_PROJECT work
>  cd work
>  < change stuff >
>  bzr diff
>  bzr commit -m "my local change"
>  bzr send
> 
> Could download just the content for the working files, and then not have
> to download anything extra.
> 
> (I was able to hack this together as a test, but it seems like something
> we would really want to support.)

+1.