Cached files [was Re: Inner repos]

[John A Meinel]

Marco Canini wrote:
> On Saturday 31 December 2005 17:35, John A Meinel wrote:
>> Marco Canini wrote:
>>> Hi John,
>>> thanks for the fast reply.
>>> I'm playing a bit with bzr since yesterday, I'm happy to know I can do
>>> that. Another question: well maybe it's more than one
>>> Why the push cmd is not shipped with bzr?
>>> I think that for a distributed rcs it's really important to have the push
>>> cmd.
>> What version are you using? I'm assuming you are using bzr 0.6, which
>> was released a very long time ago (in bzr age).
> 
> Yes, I'm with 0.6.2
> I'll take the latest bzr.dev, however I think I don't need sftp cause my I 
> mount the server dir with NFS. I think local transport is the one that get 
> used in that case, right?
> 

It should be, since it looks like a local filesystem. Actually, with a
local branch like this, the builtin push should be able to update the
working tree.

...

>> Well, there are a few things here. First, bzr handles binary files just
>> fine. It never modifies file contents, so you don't have to worry about
>> keyword expansion or something like that.
> 
> When you say never you mean also for textual files? There's no $Id$ in bzr?

No, there is no $Id$ or $Revision$, or $Date$. There are people who
desire it, so we might end up adding it.
http://bazaar.canonical.com/KeywordExpansion

I would caution against the functionality, because it frequently not the
best answer to the problem.

I created a plugin:
http://bzr.arbash-meinel.com/plugins/version_info/

Which I eventually want inside bzr core. Basically, it gives a command
which lets you get version of your tree. It is useful during build time,
or possibly at export time.
I won't go into a whole lot more detail, but there are other issues
because bzr does whole tree commits, rather than per file, etc. I
suppose I should list the specific discussion on the wiki, so people can
see both sides.

> 
>> Its delta compression on binary files is relatively poor. It just hasn't
>> been something we focused on. (Our storage splits on newlines, which is
>> valid for even binary files, but is far from optimal).
>>
>> I'm not sure how you would make files "not revision controlled, but
>> known by the revision control system".
> 
> 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.

I think I have implemented that functionality in my bzr-rsync plugin.
Just by giving you a list of files that you want copied when you "bzr
rpush".
I don't think something like that would be in bzr core. Because it is a
revision control system. And it doesn't handle the working directory as
much as it handles the metadata under .bzr/

> 
> 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?

I do understand your idea. What you are asking for is for bzr to control
the remote working directory. I don't really know if official support
will happen. But as I mentioned my rsync plugin should do exactly what
you want. Just add the line:
*.png
Into .rsyncinclude (and you can revision control .rsyncinclude if you want).
And then any png files in your directory should be copied with 'rpush'.
We probably could get bzrtools push to also support this file.

Oh, and one final thing. While I'm sure the core of bzr supports nested
trees correctly, I'm not positive that any of the rsync commands (rpush,
bzrtools' push, etc) do the right thing. Though the definition of 'right
thing' is a little bit hazy. Should it update the child directory, or
leave it alone? I think my rpush would delete it, and my rpull would
leave it alone. (Because my rpush wants to create a pristine remote
tree, and ignored files are deleted)

John
=:->


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051231/4aa9c704/attachment.pgp