Cached files [was Re: Inner repos]

[Marco Canini]

On Saturday 31 December 2005 18:55, John A Meinel wrote:
> Marco Canini wrote:
> > On Saturday 31 December 2005 17:35, John A Meinel wrote:
>
> ...
>
> > I mean I don't want the rcs to make copy of the file kept under .bzr with
> > all deltas. In my case I've big binary files, that are likely to never
> > change, but you never know.
> > But I want them to belong to the branch, so that if I modify one of those
> > files or I add a new one, after I do bzr push, the file is sent to
> > parent/remote branch.
> >
> > Another example that comes to my mind is this:
> > I've a lot of images that are automatically generated with gnuplot, or
> > they are in .svg and are converted to some raster format.
> > In one philosophy one could think that it's wrong to store into the
> > branch something that is automatically generated.
> > However it's really convenient because those images are linked into some
> > documents and sometimes the thing I want to do is read/modify the
> > document without worrying if I have all the sw stack installed to
> > generate the images. In this situation I would keep the most up to date
> > version of the images in the branch without keeping all their revisions.
> > They would be like cached files.
> >
> > I hope I've described the idea better this time.
> > What do you think?
>
> Just thinking about this some more... This would be one of the only
> cases where we might think of adding another classification to files.
> Right now they are either version controlled, unknown, or ignored. You
> would be adding something like 'precious' to use a term from Arch.
>
> The biggest problem is that we rarely update working tree to working
> tree. We generally say "get the other branch, and pull its changes, then
> merge them into my working tree". Not "get the other working tree".
> Usually, you don't want to merge uncommitted changes.
>
Yeah, that's right. However in this case, those precious files would not be 
uncommitted changes, just files that are useful, convenient in the working 
tree.
Anyway I'm gonna try your rsync plugin, which seems to me to do the job.

> If I wanted to write a plugin which hooked into bzr to add this sort of
> functionality, I think I would decorate WorkingTree.pull(). So that when
> it grabs the other branch, it would look for special files on the other
> side, which it try to update locally.
> So adding a file like .bzr/x-extra-precious-files, and then something
> like this:
>
> import bzrlib.workingtree
> _real_pull = bzrlib.workingtree.WorkingTree.pull
>
> def wrapped_pull(wt, branch, overwrite=False):
>   ret = _real_pull(wt, branch, overwrite=overwrite)
>
>   # Now that we've done the normal update, do extra stuff
>
>   # Can't do anything unless we can access the remote working tree
>   try:
>     remote_wt = branch.working_tree()
>   except errors.NoWorkingTree:
>     return ret
>
>   # See if we have extra files listed
>   try:
>     f = branch.controlfile('x-extra-precious-files')
>   except errors.NoSuchFile:
>     return ret
>
>   files = [line.rstrip('\n') for line in f]
>   # Now you have a list of files which need to be updated
>   for f in files:
>     # Check the local sha1 sum, if it doesn't match, you
>     # need to copy the contents, etc.
>
>   return ret
>
> bzrlib.workingtree.WorkingTree.pull = wrapped_pull
>
> Anyway, I think this would work, mostly because of python allowing you
> to change functions on the fly.
> You're welcome to try it if you want.
>
> John
> =:->

-- 
Marco Canini