Re: [Quilt-dev] Another shell re-write of backup-files.

[Jean Delvare]

Hi Kaz,

On Friday 18 March 2011 11:28:04 pm Kaz Kylheku wrote:
> On Fri, 18 Mar 2011 21:00:12 +0100, Jean Delvare <address@hidden>
> 
> wrote:
> > On Friday 18 March 2011 05:50:18 pm Kaz Kylheku wrote:
> >>    if [ $opt_nolink ] ; then
> >>            cpio --quiet -pd "$opt_prefix" < $file_list
> >>    else
> >>            cpio --quiet -pdl "$opt_prefix" < $file_list
> >>    fi
> >
> > You have implemented the "no link" backup improperly. "No link"
> > means that the _source_ ends unlinked. The backup is still linked
> > to all other files the source was originally linked to.
> 
> I have hard time agreeing with this requirement, because if files in
> the
> tree are multiply hard linked and you are patching
> them, that relationship basically goes out the window.
> 
> Even if "quilt pop" restores the hard link structure of the original
> tree, it still has to touch the timestamp, which will affect all
> views of the multiply linked object.

This is correct.

> I can't decide which behavior is better (break the link
> relationship for one entry, but keep all the other views
> unmodified, or keep the link relationship and expose
> the timestamp modification through all the aliased views).

You don't get to decide anything. backup-files behaves in a certain way 
today, so the decision was already taken. Any reimplementation has to 
mimic the current behavior.

> The one argument for the latter is that storage is minimized
> when you revert everything with "quilt pop -a"
> (hard to justify with 3 terabyte drives in the consumer market).

Disk space isn't the main concern as far as I know, but can still not be 
ignored. Sure, large drives exist, but I don't have a 3 TB disk in my 
2006 laptop, and I'm sure I am not an exception in this matter. 
Furthermore, disk space maybe doesn't matter when you have one source 
tree with a hundred files, but it starts being a concern when working 
with many large trees in parallel, as I am doing (and again I'm sure I 
am not an exception.)

As an example, I currently have 21 expanded Linux kernel trees on my 
disk right now, 8 of which are raw upstream kernel versions. The 
remaining ones (13) are linked copies of the raw upstream versions, with 
many patches managed with quilt on top. All these trees occupy a total 
of 7.3 GB on my relatively small laptop drive. If the working trees were 
simple copies (as opposed to the linked copies I have right now), the 
required disk space would be a lot more. I'm not going to try just to 
give you the exact number, but my estimation would be between 3.5 and 4 
extra GB.

But more importantly, what I really care about is the time it takes to 
setup a new working tree. When a simple recursive copy of the raw 
upstream kernel tree takes 66 seconds on my system, a linked copy takes 
3 seconds. And this is something I do several times every day. Of course 
it takes some time to apply the patches in both cases, but the 1 minute 
saved at the beginning is definitely good to take.

So in the end there really is no reason to not use linked copies, when 
it saves both disk space and setup time. And the fact that the linked 
copies have their timestamp updated as I work is not a problem at all in 
practice. In the worst case, it will simply cause an unneeded rebuild 
once in a while. The cost is very small if you consider the benefits of 
this approach. And I can't think of a better alternative.

> Anyone who hard-links their text files (in some logically
> necessary way, not just to save space) and manages them with quilt
> (and many other tools) will run into problems. Realistically,
> care will have to be taken to maintain the link relationship
> with a script.

No, not necessarily. We (Suse kernel developers) don't run into any 
problem with the way we use quilt. Which shouldn't be a surprise, BTW, 
given that quilt was heavily developed by Andreas Gruenbacher, why once 
was responsible for the kernel source tree management tools here at 
Suse!

-- 
Jean Delvare
Suse L3