http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/49888 Am Mittwoch, den 03.12.2008, 23:39 +0100 schrieb Jelmer Vernooij: Now that my other patch has landed, this one is no longer necessary. Please forget about it :-) Cheers, Jelmer Jelmer Vernooij 2008-12-04T00:56:25 http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/49887 Jelmer Vernooij 2008-12-04T00:29:52 http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/49886 Jelmer Vernooij 2008-12-04T00:08:10 http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/49885 Jelmer Vernooij 2008-12-03T22:39:34 http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/49884 Bundle Buggy has detected this merge request. For details, see: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C493709CC.4090307%40arbash-meinel.com%3E Project: Bazaar Bundle Buggy 2008-12-03T22:37:28 http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/49883 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I don't really feel like repeating everything again here. But the justification for this patch can be found in the bug report: https://bugs.edge.launchpad.net/bzr/+bug/304841 Basically, there is a fairly large collection of things that has to happen to trigger this case. But in the end there was a merge revision that was triggering the "expand to fulltext" fallback, but was doing so before it had actually gotten enough of the delta chain to actually be able to do so. We triggered the fallback because the direct parent was present, just not one of its ancestors, and the merge parent was present in the fallback but not in the target. The *easy* fix is to just sort topologically, because then you can't get things out of order. I also went ahead and added that as a fix because it seems the best way to avoid further bugs in 1.10-final. We can remove it for bzr.dev if we want to keep pushing this code to be correct in any other corner cases we get. The *correct* f John Arbash Meinel 2008-12-03T22:35:56 http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/49882 Bundle Buggy has detected this merge request. For details, see: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C4936F5EF.2060208%40arbash-meinel.com%3E Project: Bazaar Bundle Buggy 2008-12-03T21:12:52 http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/49881 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 To make it easier to test edge-cases with 'get_record_stream()' I added a decorator class that can allow tests to specific what the order should actually be when we get "unordered" as the requested order. I think this class is generally useful, and I'll be specifically using it to write nice tests for fixing: https://bugs.edge.launchpad.net/bzr/+bug/304841 (One of the stacking fetch bugs.) I figured I could submit it as a separate patch to make review easier. I will end up wanting this in the 1.10 release, so I've built it against that branch, but it is applicable to both 1.10 and bzr.dev. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkk29e8ACgkQJdeBCYSNAANg2wCgiLH6z6gVXVntvP/Hm/1CM/6I C9IAn0bWzScCc6F9D/f+lABtodZGAruL =vjMX -----END PGP SIGNATURE----- # Bazaar merge directive format 2 (Bazaar 0.90) # revision_id: john< at >arbash-meinel.com-20081203210501-fej John Arbash Meinel 2008-12-03T21:11:11 http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/49880 There are four different formats at play: The format of ".bzr" (the control directory), the format of ".bzr/checkout" (the working tree), the format of ".bzr/branch" and the format of ".bzr/repository". For example, "pack-0.92" is a name for a combination of control directory format 1, branch format 6, a pack repository, and I don't remember the working tree format. For some reason, when everything is up-to-date, "bzr upgrade"'s error message only mentions the control dir's format. I don't know why; that message could really be improved. Matt Nordhoff 2008-12-03T18:05:22 http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/49879 OK, it is good that there is a sane and consistent default, the question is how is a "mere user" supposed to decide whether to use formats 1.6 or 1.9? Should people be going straight to 1.9-rich-root? Trying "bzr help formats" gives me a list of formats. There is a long list of formats looking like a complete history of Bazaar formats since bzr v0.0 and no real guidance as to the fact that there is a history. I think there needs to be a lot more thought put into this presentation so as to make it far clearer what users should be doing with the different formats. So the section on Experimental Formats and the section on Deprecated Formats are very clear -- basically this is background information of no import for a user. For the first section there are 11 formats, one designated as the default and not enough guidance about the others. OK, one can deduce and infer using information about Bazaar version numbers quite a lot of information about the fact that half of the formats are close to becoming dep Russel Winder 2008-12-03T17:14:44 http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/49878 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Russel Winder wrote: "bzr upgrade" with no options always upgrades to the *default* format. 1.6 and 1.9 are officially blessed, but you have to actually ask for them. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkk2ubQACgkQJdeBCYSNAANjjwCg1IPg3Il2AHyJmoo927h+9GTz ccEAnifcbmvHMjoDXOA1nZ7OJkxJVxn/ =PfNx -----END PGP SIGNATURE----- John Arbash Meinel 2008-12-03T16:54:12 http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/49877 I just ran "bzr upgrade" on a pack-0.92 format branch and it said: bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format. Two questions: Why does bzr info report pack-0.92 as the format but upgrade reports format 1? These two are clearly not equivalent! Is pack-0.92 the current official most recent format, meaning that all formats such as 1.6 and 1.9 are not yet officially blessed. Thanks. Russel Winder 2008-12-03T16:53:48 http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/49876 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ATM if you use "-Dpack" during an autopack or otherwise you'll get a bug with regular repositories (in the brisbane branch). I went ahead and just committed this fix directly to the branch, since it is fairly obviously correct. All it does is move the mutter underneath the "if new_pack.chk_index is not None" check. John =:-> === modified file 'bzrlib/repofmt/pack_repo.py' - --- bzrlib/repofmt/pack_repo.py 2008-11-20 19:41:26 +0000 +++ bzrlib/repofmt/pack_repo.py 2008-12-03 16:48:57 +0000 < at >< at > -783,12 +783,12 < at >< at > # the items? How should that interact with stacked repos? if new_pack.chk_index is not None: self._copy_chks() - - if 'pack' in debug.debug_flags: - - mutter('%s: create_pack: chk content copied: %s%s %d items t+%6.3fs', - - time.ctime(), self._pack_collection._upload_transport.base, - - new_pack.random_name, - - new_pack.chk_index.key_count(), - - John Arbash Meinel 2008-12-03T16:50:53 http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/49875 Bundle Buggy has detected this merge request. For details, see: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C4936B2A6.1050405%40arbash-meinel.com%3E Project: Bazaar Bundle Buggy 2008-12-03T16:25:16 http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/49874 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is a minor update on top of my earlier patch, which just has the "_obsolete_packs()" function also move away the ".cix" indices. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkk2sqYACgkQJdeBCYSNAAP96wCaAgK9tJd+O/3k1eGLdnUl03Yd mJsAn0lz9ycYSmYFNfmImfpuPyW+5h63 =69cf -----END PGP SIGNATURE----- # Bazaar merge directive format 2 (Bazaar 0.90) # revision_id: john< at >arbash-meinel.com-20081203035643-0x4npc4s8mh8nqlh # target_branch: http://bzr.arbash-meinel.com/branches/bzr/brisbane\ # /core # testament_sha1: 2dacdfb407d437bc659bd1a81c01283b02694d70 # timestamp: 2008-12-03 10:14:57 -0600 # source_branch: http://bzr.arbash-meinel.com/branches/bzr/brisbane\ # /chk_map # base_revision_id: john< at >arbash-meinel.com-20081202235625-\ # h5fo44xy2hxeopo2 # # Begin patch === modified file 'bzrlib/repofmt/pack_repo.py' --- bzrlib/repofmt/pack_repo.py2008-11-20 19:41:2 John Arbash Meinel 2008-12-03T16:24:06 http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/49873 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John Arbash Meinel wrote: To follow up on this a bit, I started a MySQL conversion and let it run overnight. When I checked on it this morning it had converted 39k revisions (out of something like 65k) and was consuming 900MB of RAM. More critically, I'm seeing a *lot* of waste in the pack files. I went ahead and hacked in some code to give the size of the packs being packed versus the size of the final pack. And I'm attaching a trimmed log file. The key parts are lines like this: 35166.635 Auto-packing ... which has 20 pack files, containing 38000 35184.372 Auto-packing ... completed 101.269MB => 14.456MB 36581.414 Auto-packing ... which has 21 pack files, containing 39000 36601.117 Auto-packing ... completed 117.795MB => 17.208MB That means that in those 10 pack files that we decided we needed to recompact, we had 86% waste. I don't know exactly why yet. Whether it was because we weren't applying deltas properly, so it was causing us to rebuild the en John Arbash Meinel 2008-12-03T16:14:27 http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/49872 Dashes are to be avoided, because those are customarily reserved for distro packging purposes. But anything in format: N.[.N]+ is fine. Like: X.Y.Z.YYYYMMDD Jari Jari Aalto 2008-12-03T15:30:45 http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/49871 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen J. Turnbull wrote: My suggestion would be to just fold the date into the version string. 1.10-20090101 You have the obvious date, and you have a number indicating "quality". It *is* a bit verbose, but it is also obviously a date, and does satisfy the "wow my bzr-0.7-20060109 really is old". John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkk2ojUACgkQJdeBCYSNAAOJXQCffqX0O6BQ1bVIT0OoQawlH7Jk mt8An07QwG6buZTQx+eWW2J2NTkeLYhE =JHP+ -----END PGP SIGNATURE----- John Arbash Meinel 2008-12-03T15:13:57 http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/49870 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ... ... I have a fix for this specific bug in the patch I just posted. If it gets reviewed it should land in brisbane-core soon. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkk2oFYACgkQJdeBCYSNAAMRJgCfR3Z6+WzfK5XGmgFA1ducHW9H iP8AoLPSab14PeC7/YvJpV5fD7AYoReE =HCDJ -----END PGP SIGNATURE----- John Arbash Meinel 2008-12-03T15:05:58 http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/49869 > was 1.0 released? or 1.1? Person complaining that his bzr 1.x "does not > work", cannot see that his bzr is old. With date based versions it'd be > obvious: > > YYYYMMDD The date is obvious, but whether anything important has changed, and how much has changed, since then is not. > Btw, the "rc*" naming is nightmare for automatic watching of new > releases. With pure "sort" naming, a bot could examine web page and send > mail when new release is available. This is what overridable methods are for. Several packages are available for dealing with this, including one in Python which specifically has code for dealing with the rcN style. Stephen J. Turnbull 2008-12-03T10:33:40 http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/49868 Any versioning scheme that increases is fine. For packagers of bzr the ideal is the logical sort(1) order, which means that these, although nice for ordinary people, won't "sort" nicely: 1.1 1.10 So, whatever is used, the 2 number versioning would be preferrable: 2.01 2.02 .. 2.20 Using the date based releases automatically solves this. I like this because it is possible to immediately see the release date. Think, when was 1.0 released? or 1.1? Person complaining that his bzr 1.x "does not work", cannot see that his bzr is old. With date based versions it'd be obvious: YYYYMMDD About X.Y.Z.ZZ releases, people mostly associate that to Kernel workflow, which is logical. For Bzr maybe something like: 2.x For major changes; new repository layout etc 2.x.y For minor changes, improvements bug fixes 2.x.y.z "Point releases", or current "rc" series. Btw, the "rc*" naming is nightmare for automatic watching of new releases. With pure "sort" naming, a bot could examine web pag Jari Aalto 2008-12-03T08:55:17 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.version-control.bazaar-ng.general