Cached files [was Re: Inner repos]

[Marco Canini]

Well, it seems that I should be fine with your rsync plugin.
Though I don't understand in which order I should run the rpush, push or the 
rpull, pull commands, and how they differ.
It would be cool to have both rsync add / remove commands instead of editing 
the file by hand.

Many thanks John

On Saturday 31 December 2005 18:23, John A Meinel wrote:
> 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
> =:->

-- 
Marco Canini