[RFC] Out of memory during BzrDir.find_branches

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Bennetts wrote:
> Even if it is sidestepping a bug, a lazy iterator still seems like a good idea
> to me.  It won't slow things down significantly, and it will start returning
> results faster, especially for huge directory trees.

If find_branches took less than a second, I really don't think you'd
care whether it was incremental or not.

Iterators aren't universally good.  You can't increment progress bars
within them, and you have to be very careful about how you manage locks
and other resources.  And since I knew I'd be dealing with objects that
have locks, I thought it would be best to avoid those issues when I
wrote it.

> I'm all for fixing whatever bug(s) make find_branches slow.  I don't think that
> should prevent us from allowing BzrDir implementations of find_branches to
> return a lazy iterator.  It's a simple change with clear benefits today.  If it
> was just to sidestep a bug I'd understand your objection.  But it seems to me to
> be a good idea independent of the fact that it sidesteps the bug a little (it
> doesn't make it faster, it just gives feedback to the user sooner).

I never actually said we *shouldn't* make it iterable.  I just said that
the size and speed arguments didn't seem reasonable to me.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIDdfm0F+nu1YWqI0RAgTYAJ4iKH43k5470pdaL0Z7EJJM5nqEZACfQp1z
sKjlYbvZ1bpcd+ATVOrnDOw=
=aV7B
-----END PGP SIGNATURE-----