[RFC][2.0] large file support design

[Martin Pool]

2009/6/5 Robert Collins <robert.collins at canonical.com>:
> On Fri, 2009-06-05 at 15:44 +1000, Martin Pool wrote:
>> 2009/6/5 Robert Collins <robert.collins at canonical.com>:
>> > This is a proposed change for 2.0.
>>
>> Hi,
>>
>> This sounds like a good thing to fix and a pretty clear description of
>> how one might start fixing it.  But I really don't think we should be
>> adding any new features to 2.0 now, even ones that can be done quite
>> quickly.  We should now be trying to stabilize and ship what we have,
>> not add new things and really even trying to hold back a bit from
>> thinking about post 2.0 things.
>
> We have a few big glaring bugs [as opposed to missing features] that
> people keep running into:
>  - dirstate on windows
>  - parallel imports
>  - large files
>
> It may be that we can't fix any of these for 2.0.
>
> Given the direction of having no format bumps during 2.x, we're raising
> the cost of doing 2.0 without fixing these. If there is (say) a year
> before 3.0, then its pretty disconcerting to think that we'll be saying
> 'there is no way to use bzr in these circumstances' for a year after we
> fix these issues.

I would desperately like to fix all of them.  However, if we try to
fix all of them it is not likely we will release 2.0 for at least
several months, and I'd like to get 2.0's brisbane-core features out
and visible to everyone.

Look at it in the same way we look at a regular release: I'd like to
fix every open bug for 1.16 too, but I don't want to slip 1.16
indefinitely until it's done.

How we do land and release future format changes deserves a bigger
answer, but maybe not tonight (at least not from me.)  Things that
aren't done in 2.0 won't necessarily be waiting a year to come out.

-- 
Martin <http://launchpad.net/~mbp/>