Sorry for breaking the thread; I'm not on this list, and my mail client doesn't seem to have a 'lie about history' field. > From: Stephen J. Turnbull > Date: 2009-06-29 23:37:53 GMT > > Karl Fogel writes: > > Stefan Monnier iro.umontreal.ca> writes: > > > In the Bzr world, there's always something new coming up providing this > > > and that performance improvement. So there's no point waiting for the > > > next one, cause when the time is passed, you'll end up wanting to wait > > > for the next next one, etc... ad nauseam. > > > > I understand what you mean, but This Time Is Different (or so I am told, > > in no uncertain terms, by every Bazaar developer I talk to). I think it is different. One thing that 2a gives us is *breathing space* - until now we've been playing catchup - everytime we improved performance, another group of users would pop up and say 'we want to use it, but damn its slow'. We're not finished - thats true, be we are now definitively over the performance hump. We haven't really promised to keep format changes out of the way in the past - and we've had a lot of pressure to deploy every single incremental improvement we made. We haven't changed the default format since Octobert 2007, and it's my hope that the performance wins in 2a will let us focus on higher level things that core history storage for the next Some reasons to use 2a rather than 1.9 or 1.9-rich-root. For starters, in 2a we've dropped all support for non-rich-root flavour, letting us finally put behind us a very early design defect in bzr. Using the 1.9 format would require emacs to migrate past that change - but its better and more efficient to start with a rich root format (which 2a is). Secondly, much of the performance improvements are obtained by using a better representation for the hash that contains versioned file data in a revision; 1.9 is _massively_ slower than 2a, and doing the conversion is inordinately time consuming (even though its simple to do, its hampered by having poor source format performance). 2a is approximately 1/3 the size on disk for most projects, which also adds to performance, by requiring less data transfer, less cache footprint etc. And 2a is supported. Its not going to get changed at this point [barring unforeseen critical issues], and we expect to keep it as-is for the entire bzr 2.x cycle. I heartily endorse the use of 2a because it will be better, faster, use less memory and provide a nicer environment. >Who are you talking to? The list traffic tells a very different >story. Mark Shuttleworth (Da Beeg Boos) wrote "Thou Shalt Have But >One Bazaar 2 Format", and got *lots* of pushback. AFAIK he gave up; >the Bazaar devs surely act like that pronunciamento is "inoperative". Mark has asked us to fix the current UI headaches that have emergerd - some of which we painted ourselves into. One aspect of that is getting rid of the huge list of formats, and another is not creating that problem again. I don't think Mark has given up his desire for us to fix this. What he has done is acknowledged is that fixing the UI requires some care and thought - and that with the dev team focusing on the plumbing changes to really put performance issues to be the cycles simply are not there to address the UI before 2.0, *or* we delay 2.0 (which primarily consists of changing the default output format to 2a and thus giving everyone a radically better experience). I don't think anyone is keen about delaying 2.0 once we've got all the things in place for changing the default. That list is pretty short now - one or two server tweaks, some remaining performance work mainly targeted at the migration process and finally some assistance for people migrating. > Robert Collins is *not* on board on "2a", specifically, looms are not > included in 2a, which means at least two variants of 2a will be out > there in the wild for a while. (Silver lining: looms are usable as a > local improvement, you don't actually need them on the server for many > common workflows.) Looms have never hooked into the history storage layer (which is what 2a is all about). Fixing the root cause for the UI friction I refer to above will likely bring in sufficient core capabilities that loom can stop being a separate branch type - this has been touched on a few times on the list I think. If not, I'm fairly sure its in the devnotes branch. > Aaron Bentley is *not* on board on "2a", > specifically nested trees have not landed, but they will. (Emacs > doesn't care, I think, but many projects want nested trees very badly. > It will land, not before 2.0, I suspect, but not too long thereafter. > This will mean a server upgrade, the formats are mutually incompatible > currently AIUI.) Four variants. And counting---don't kid yourself, > there will be more. Nested trees are unlikely to hit 2a, they need to be ironed out, transient code needs to be fully migrated, performance will need to be assessed and so on. I'm keen to see them completed because they are an important feature, but its not done till its done. In short - there is 2a, looms for people that want to use them sit on top of 2a today, and nested trees are not finished yet. We do need to find a way to gradually deploy such things; all VCS systems do this, at different rates and in different ways. I'm sure bzr doesn't have the tradeoffs right yet :(. > IMO (and that of the Python devs, see PEPs 374 and 385), Stefan is > right. You need to settle on a version that's either Available Now or > Coming Soon To A GNU/Linux Distro Near You. People who want to bleed >can always do that (to) themselves. :-) I heartily agree - pick a single format and release of bzr, get using it. That format should be 2a. -Rob