Very surprising behaviour with --files-from

[Robin Lee Powell]

On Fri, Dec 10, 2010 at 02:42:45PM -0800, Steven Levine wrote:
> In <20101210220340.GI27025 at digitalkingdom.org>, on 12/10/10 at
> 02:03 PM, Robin Lee Powell <rlpowell at digitalkingdom.org> said:
> 
> Hi,
> 
> >On the other hand, given this:
> 
> >cpool/b/c/5/bc50007d8ab0221cb2b2b61e0754224c
> >cpool/b/c/5/bc500094bb43d0f4235363f65658d231
> >cpool/7/7/8/77865de94585b4581f07e54065c7b1e3
> 
> >, that is, same files, changed order, we have:
> 
> >In the middle case, it checks all the /b/ stuff a second time
> >because of *the order of the file*.
> 
> I missed this.  My test case was right, but I did not supply
> sufficient -v's to see it and I did not have time to look at the
> code.  The list I saw was after sorting and the duplicates were
> gone.
> 
> >Which is fine and appropriate in terms of RAM usage, I guess, but
> >very very surprising.
> 
> I don't think the issue is RAM use per se.  Reviewing the code,
> I'd say it's more likely that no one considered the performance
> impact of huge, out of order file lists.  I would not consider
> your use case standard.

Oh, I completely agree that my use case is unusual.  The resulting
behaviour is still a shock, though.

> >I call this a feature, but a documentation fail.  At least, I
> >can't find anything in the docs that mentions "and you'd better
> >sort the file or you won't like the results at all".
> 
> I recommend you put in an documentation enhancement ticket for
> this.

Doing that now.

-Robin

-- 
http://singinst.org/ :  Our last, best hope for a fantastic future.
Lojban (http://www.lojban.org/): The language in which "this parrot
is dead" is "ti poi spitaki cu morsi", but "this sentence is false"
is "na nei".   My personal page: http://www.digitalkingdom.org/rlp/