[MERGE] Integration ordering
aaron.bentley at utoronto.ca
Tue Jun 19 05:22:26 BST 2007
-----BEGIN PGP SIGNED MESSAGE-----
Robert Collins wrote:
> On Mon, 2007-06-18 at 23:29 -0400, Aaron Bentley wrote:
> Right. The way I hope to counter that risk is to have us do the core use
> case refactorings *now*, pushing the abstraction burden further down
> until its inside Branch or Repository and not exposed outside that. I
> think this can be done without performance compromises.
I think that's the clearest I've heard this strategy expressed. I
haven't tried an approach like this before, but it's worth pursuing.
>>> + * Be able to version files greater than memory in size:
>> I really really hate this change. It'll make development so much harder.
> Ok. I'm not particularly pushing for it myself - because I don't version
> big files. However I think it is needed to really consider ourselves
> mature. What can we do to reduce the impact on development?
Cases where we handle whole files texts at once fall into several groups:
1. we are trying to do optimal file operations (e.g.
2. we are trying to satisfy a suboptimal API. Possibly it has the
producer/consumer relationship inverted from the optimum.
3. an algorithm demands fast random access to a file, e.g. Patience sorting.
4. we're getting several versions of a file at once.
1 is an easy fix. 2 is conceptually simple, but time-consuming. I'm
not sure what to do about 3 and 4.
>> OTOH, bundles may contain multiparent deltas, and those can be used for
>> annotation quite efficiently.
> This is true. It may be that we end up using multiparent deltas at the
> core of the system and discard the xdelta concept. Do we have enough
> data to do a shoot out yet (including serial-IO performance benefits).
I was imagining supporting both Xdelta and mpdiff. mpdiff primarily for
bundles, where size is more important than extraction speed, Xdelta in
repositories, or for binaries. But bundles and probably repositories
could use a mixture.
I suppose it's probably worth doing a size comparison, to make sure
keeping mpdiff makes sense. I just have trouble imagining Xdelta being
so much better at compression that it makes up for the disadvantage of
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the bazaar