=== ronny is now known as Guest28036 === jelmer_ is now known as Guest29580 === ronny is now known as Guest27644 [03:02] are there any tricks to getting pulls going any faster? [03:04] I'm guessing not, but it just seems like it's awfully slow compared to other VCSs and I wonder if there are any tricks to it [03:05] LaserJock: what version? [03:05] especially when there's no new revisions it seems to take a long time considering [03:05] I've got 1.6.1 (intrepid default) [03:05] ah [03:06] but for instance I timed a multi-pull in a repo with 5 branches and it took over 1 minute [03:06] and there were no new revisions so it should have just been checking to see [03:06] 1.9 was just released. i think it's a bit faster than 1.6. performance is one think people are working on [03:06] s/think/thing/ [03:07] not me though. i'm just a user for the most part [03:09] I was wondering if it was maybe a bzr-svn thing as most of my branches are from svn repos, but it seems like the native bzr ones are "slow" too [03:13] I never quite got it straight what the conclusion was on the list... [03:13] not sure [03:14] is format=1.9 backwards compatible, or did it introduce rich-root (thereby putting a floor on [03:14] backwards compatibility, of something 1.9 (or $whatever)? [03:16] i'm not sure [03:18] [recognizing that bzr 1.9 client, bzr 1.9 server, and format=1.9 promises some fairly juicy improvements, it seems worth trying for, but in a public project I'm not sure if I'm going to screw people over, so it seemed prudent to ask] [03:30] AfC: there is 1.9 and 1.9-rich-root [03:34] lifeless: ah [03:34] So we haven't culled rich-root yet. Ok. [03:35] Can a ~1.6 client read a 1.9 branch and downgrade? [03:35] (format=1.9 branch, that is; I know a bzr version 1.9 server will work) [03:53] lifeless: on the off hand it's a simple answer, what is keeping rich-root from becoming default? [04:45] AfC: 1.9 repos are only compatible with 1.9. [04:46] AfC: I mean, you can certainly downgrade them to pack-0.92 or knit or whatever, but you'd need to do it with 1.9 or newer. [04:47] (Well, 1.9rc1 I guess) [05:17] Howdy folks [08:30] Hi, I installed bzr 1.9rc1 on my windows XP machine. When I try to use tortoise I allways get the "ImportError: No module named command" error. The overlays icons shows right on the projects I already have set up. What does this error mean? [08:35] codeRat: it sounds like its using a module that's not installed in the Windows version of Python (the command module is Unix only) [08:36] so there's no way around? [08:37] dunno. [08:37] ok, thank you [08:37] I'm not sure how/when that module is used. [08:37] at least I know what to look for :) [08:38] Looks like bzrlib/shellcomplete.py is the culprit [08:39] but it strange that a program that is made for windows does use a module for unix :S [08:39] * jszakmeister|awa agrees === jszakmeister|awa is now known as jszakmeister === Guest27644 is now known as ronny === jszakmeister is now known as jszakmeister|awa [10:00] hello all. why when i commit with bzr ci -x a_folder, deleted files in the bzr root directory are not being removed? [10:02] i meant in the bzr branch root directoy [10:24] hi ho [13:17] hello, I want bzr branch to branch my repository then another one [13:17] (like apt-get dependencies) [13:19] Write a shell script? [13:19] AfC, I think svn can do this [13:20] so? [13:24] OK, I found this http://bazaar-vcs.org/NestedTreeSupport [13:32] still not supported yet :( [19:25] Argh.. now bzr again downloaded over 10MB of data for a simple pull operation.. nearly all .tix index crap. Have -Dhpss logs if anyone is interested to look into this. bzr 1.8 on both sides, using bzr+ssh:// protocol. [19:27] this is a lightweight checkout from a local repository where the branch is bound to the remote repository. [19:28] hi hno [19:28] hi jelmer [19:28] hopefully one of the Australians can have a look when they wake up [19:30] a pull within the local repository seems to do the same thing so it's not due to the lightweigth checkout.. will try it without the bind also. [19:38] does the same without the bind as well.. [19:38] next, upgrade to 1.9... [19:41] i have a branch of bzr's repo; how can i view the 1.9 release? [19:41] i tried bzr tags but got nothing on the command line. [19:41] Yeah, there aren't tags. [19:42] how do i find out what rev v1.9 was cut from? [19:43] The 1.9 release branch is http://bazaar-vcs.org/bzr/bzr.1.9/ . I'd assume it was cut from that. [19:44] since i already have a copy of the dev branch can i pull from there and my local copy will reflect that branch? [19:44] i'm about to try that. [19:45] it would be silly for me to have to rebranch the whole thing when i have the repo already. [19:46] If you use a shared repo, it won't have to download the data again. [19:47] right, ok, cool. [19:54] jelmer: ready for a simple bzr-svn bug report? :) [19:55] rocky, always :-) [19:55] jelmer: http://cluebin.appspot.com/pasted/3001 [19:56] 19 behaved better. Still not good, but much better. [19:56] 1.9 i meant.. [20:02] rocky, thanks, fixed [20:04] hno: 1.9 introduces a new index format which should be much more efficient. Of course, it's not compatible with older versions of bzr. [20:05] Peng_: The local was already updated to btree, but the remote can not be updated as it's a shared repository. [20:05] Ah. [20:08] Peng_: And I think it's silly. The basic bzr pull/update over bzr+shs SHOLD do a smart call getting a bundle back of the new revisions, not raw reading of the indexes and packs.. [20:10] Yeah, it /should/. [20:15] Peng_: Waiting for a test upgrade of the remote to see how much of a difference the new index format makes in this operation. [20:26] bzr upgrade still running... [20:27] jelmer: there a branch i should get? [20:28] rocky, yes, the 0.4 one [20:29] jelmer: hm, launchpad isn't seeing the fix ... http://bazaar.launchpad.net/~jelmer/bzr-svn/0.4/changes/1741?start_revid=1741 [20:29] http://bazaar.launchpad.net/~jelmer/bzr-svn/0.4/changes rather [20:29] rocky, launchpad isn't the main location for bzr-svn, it just has a mirror [20:30] ohhh [20:30] http://people.samba.org/bzr/jelmer/bzr-svn/0.4 [20:30] jelmer: any reason the log isn't up to date when viewing http://people.samba.org/bzr/jelmer/bzr-svn/0.4/ with a browser? [20:30] basically i'm trying to see the last revision so i can just do a manual fix here ;) [20:31] I don't have the right plugin installed from my current machine [20:31] so it's not updated atm [20:31] gotcha [20:34] hi [20:35] jelmer: how does your bzr/http setup work? you using the stock http smart server or something more ? [20:36] no, I'm pushing to a remote server using bzr+ssh [20:36] the location I push to is accessible using http [20:36] gotcha [20:36] i'm a little surprised that there doesn't seem to be any bzr repos out there with r/w using the http smart server [20:38] rocky: there are [20:39] rocky: the uk NHS's bzr repos are read-write http(s I think) [20:39] lifeless: Hi! [20:39] hno: hi [20:39] oh cool [20:39] rocky: on windows with IIS for extra fun :P [20:39] why don't more people use that? i mean r/w http: is way more accessible then proprietary bzr: repos ... is it that much slower or something? [20:40] rocky: bzr+ssh is what most people use I think, because its basically zero setup [20:40] bzr: is a registered port with the IANA, so its not that proprietary :P [20:40] i have 1 dedicated box, giving people shell access is not acceptable for my setup ... and i know a lot of people in the same boat... plus people coming from svn backgrounds are accustomed to only dealing with http [20:41] rocky: sure, but you asked about other people :P [20:41] ;) [20:41] bbiab, morning $foo [20:43] how long is an bzr upgrade supposed to take? [20:45] jelmer: it's too bad easy_install bzr-svn doesn't install bzr-svn properly [20:46] rocky: install should work though [20:46] jelmer: yeah "python setup.py install" works fine [20:46] but my steps for installing new bzr these days is: virtualenv.py bzr-1.9; cd bzr-1.9; ./bin/easy_install bzr [20:46] it'd be nice if the last step was ./bin/easy_install bzr-svn [20:47] hno: if its in the same model and local, a few minutes [20:47] What would be required to support easy_install? I must admit I've never used it [20:47] hno: what exact command did you run ? [20:47] bzr upgrade --format=1.9-rich-root [20:47] hno: cancel that [20:48] hno: remove .bzr, rename backup.bzr to .bzr [20:48] it was on a copy.. [20:48] then just cancel it [20:48] done, and restored. [20:48] hno: is this the squid repo ? [20:48] yes, still having trobles with those indexes.. [20:48] hno: 'bzr upgrade --1.9' [20:49] hno: and you need a 1.9 client to use a 1.9 repository [20:49] jelmer: well it's not really an issue of supporting easy_install, it's making sure bzr-svn is packaged properly to be an egg ... are there any other bzr plugins packaged as eggs? [20:49] i wouldn't think it'd be much work [20:50] lifeless: 1.9 on both. [20:50] hno: cool, was just answering your question from scrollback [20:50] rocky, I'll happily apply patches that fix easy_install, as long as there's no overhead per release [20:50] lifeless: 1.9 did behave better than 1.8, but still very heavy. [20:51] jelmer: should just be a one-time change [20:52] lifeless: with the old index format that is. Upgrade of bzr brought the operation down from 8MB of indextransfer to ca 1MB I think. [20:52] hno: sounds about right [20:54] lifeless: followed by 75KB of actual pack data. [20:59] lifeless: Corrected numbers. 1.8 read 9576413 of indicies 71598 bytes of packs. 1.9 read 3426251 bytes of indicies, same packs. (from the main squid3 repo with old index format) [21:00] hno: the btree index will help immensely I think [21:00] hno: 4K pages, 100-way fanout [21:02] breakfasttime [21:03] lifeless: Testing.. [21:04] done. [21:06] lifeless: Using 1.9 format on the remote result in a transfer of indicies 448673 bytes, packs 70842 bytes. [21:08] the smart server should be smarter :-) [21:21] hno: interesting [21:32] packs got a little smaller as upgrade also repacks the repository. [21:33] but still, that's at least 445k unwanted overhead.. [21:35] hno: we're agreed that it should stream [21:35] hno: I'll need to check and see if we are doing prefetching on btree indices, because 445K of index data is 111 pages [21:36] which is arge [21:36] *large* [21:38] lifeless: I can tar up my local repository for you to experiment from, if you need a startingpoint to trigger this.. [21:39] hno: I have a separate performance issue I'm working on at the moment [21:39] hno: but thanks [21:40] lifeless: Ok. I'll keep a copy around for some time anyway. [21:41] jelmer: bug 295611 - whats the summary? [21:41] Launchpad bug 295611 in bzr "NoSuchRevision: KnitPackRepository" [Undecided,Confirmed] https://launchpad.net/bugs/295611 [21:42] lifeless, basically it's similar to the bug we looked at during the summer [21:43] * jelmer looks again [21:43] lifeless, sorry, it's actually related to ghosts [21:44] where "bzr diff" assumes that the revision info for the last-changed-revision of all files in the tree are present [21:49] jelmer: I can't parse that. Is a valid rephrasing 'the last-changed-revision is used as the key for the file text'? [21:49] lifeless, nope [21:50] lifeless, bzr diff prints the timestamp of the original text of a file and of the new revised one [21:51] with you so far [21:51] in order to obtain the timestamp for the old text, it uses the text revision and calls Repository.get_revision(text_revision) [21:51] if that text_revision happens to be a ghost, things break [21:51] ah [21:51] so there are some interactions here [21:52] we really need to sit down and clean up the ghost handling once and for all [21:52] the interaction I'm thinking of is: we only copy text (id,X) when we copy revision X [21:52] so that repository isn't clonable by bzr at all anyhow [21:52] (as it currently stands) [21:53] that would break bzr-svn, which usually only pushes lhs revisions [21:53] that may contain references to texts introduced by rhs revisions [21:54] *those lhs revisions may contain references to texts introduced by rhs revisions [21:57] jelmer: 'does break' [21:58] jelmer: though I think I've mentioned before that having those references isn't strictly valid [21:58] under the current rules. And thus the need to fix this forever [21:59] the inventory work being done at the moment will open the door to handling this efficiently and preserving arbitrary revision text values, which would make the revision-being-absent a valid bug [22:10] lifeless, ah, that makes sense [22:11] the problem at the moment is that doing 'inventory_delta(X,Y)' is very expensive [22:11] so we can't tell what texts are new for a set of inventories by doing that, instead what we do is a bit of hack by examining all the delta'd lines [22:12] the problem there is that fulltext inventories cause every line to be examined, so we end up either copying, or checking-for, the entire tree on every pull of 200 revs (on average) [22:12] and that is very very bad on big trees; which are also likely to have more committers and thus trigger it more often [22:19] I have a quick question regarding bzr-svn and bzr 1.9. I am working to on Ubuntu and as of now I cannot install it because : bzr-svn: Depends: bzr (< 1.8~) but 1.9-1~bazaar1~hardy1 is to be installed [22:20] I would like to know if this is going to be solve in a matter of day or if I should downgrade to bzr 1.8 [22:20] yml: I imagine we just need to upload a new package to the ppa [22:20] yml: if you are using the ppa [22:21] lifeless: Yes I am using PPA [22:22] lifeless: else is there a place where I could download bzr-svn .deb ? [22:23] yml, Debian should have one [22:23] lifeless, what's the ETA on split-inventories? [22:25] jelmer: draft results are promising [22:25] jelmer: no specific timeline, you know how software dev goes [22:26] lifeless: Ah, cool - how complete is it though? [22:26] Initial work done? Some things already work ? Only a few tests left that need fixing? [22:26] chk layer is about 95%, dictionary built on that is ~60% I would say, inventories on that are very thin, mainly need optimisers and tuning call it 70% [22:27] needs lots of profiling and feedback cycle [22:27] compression is not really touched, call that 10% [22:27] ah, so this is the CHK stuff I've seen scrolling past on bazaar-list.. :-) [22:27] yes [22:28] chk is content hash key [22:29] which is the obvious implementation to satisfy a canonical representation with nested hashability [22:29] jelmer : Is that the deb that I should download ? [22:29] http://packages.debian.org/fr/experimental/bzr-svn [22:29] yep [22:30] its slightly more general than git's keys, because its forward extensible (in disk layout) to sha256 etc [22:30] lifeless, ah, nice [22:31] CHKMap is a dict built in that layer [22:31] which as a basic datatype is reusable [22:46] ubuntu complains about libsvn1 being to hold ? [22:48] yml, They probably have different versions of libsvn1 [22:49] ok I will wait for a while [23:21] lifeless: Speaking of inventory stuff... does the new stuff you're working on support referencing unchanged files in a revision? [23:23] fullermd: how do you mean? [23:23] bzr ci --unchanged some/file [23:25] fullermd: no [23:25] I'm going to give you another chance to answer :) [23:25] fullermd: no [23:25] fullermd: because.. === rocky1 is now known as rocky [23:28] fullermd, why would you ever want to do that? [23:28] Well, why would you ever want to commit --unchanged? [23:29] If there's a reason for the one, there's a reason for the other. [23:30] fullermd: the last-changed field on inventory entries is derived data; we don't provide (nor should we) a knob to fiddle it; its not included in testaments for instance [23:30] hello [23:31] hello lifeless [23:31] fullermd: annotating history so you can find a commit that marked 'foo' interesting is really quite orthogonal - I would approach it by adding a rule to the derived data logic that adds a last-change value for the commit, probably by recording in the commit that that path was interesting [23:31] fullermd: and as such the inventory layer is unaffected - its no more or less capable of doing what you desire than current inventories [23:31] hi poolie [23:33] i'm going to try running john's packaging script [23:35] Hm. 'k... it seemed to me that last time we discussed it, you said it needed inventory-level changes, and so would end up falling into the next round of inv work. Guess I misunderstood. [23:35] fullermd: I think you asked about a variation ;P [23:35] fullermd: or my thinking has refined [23:36] Well, we could always use more refinery. Or distillery, anyway. [23:37] k, time for full screen code, poolie - ping me via skype(chat|voice) when ready [23:38] lifeless: ok, the net here may be a bit slow to actually do voip [23:38] we'll see [23:41] Dragonfly ended up with git, BTW. [23:41] http://article.gmane.org/gmane.os.dragonfly-bsd.kernel/12212 [23:44] (not overly surprising; hg had a late surge, but git was up 2:1 most of the voting time)