| === ronny is now known as Guest28036 | ||
| === jelmer_ is now known as Guest29580 | ||
| === ronny is now known as Guest27644 | ||
| LaserJock | are there any tricks to getting pulls going any faster? | 03:02 |
|---|---|---|
| LaserJock | 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:04 |
| dobey | LaserJock: what version? | 03:05 |
| LaserJock | especially when there's no new revisions it seems to take a long time considering | 03:05 |
| LaserJock | I've got 1.6.1 (intrepid default) | 03:05 |
| dobey | ah | 03:05 |
| LaserJock | but for instance I timed a multi-pull in a repo with 5 branches and it took over 1 minute | 03:06 |
| LaserJock | and there were no new revisions so it should have just been checking to see | 03:06 |
| dobey | 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 |
| dobey | s/think/thing/ | 03:06 |
| dobey | not me though. i'm just a user for the most part | 03:07 |
| LaserJock | 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:09 |
| AfC | I never quite got it straight what the conclusion was on the list... | 03:13 |
| dobey | not sure | 03:13 |
| AfC | is format=1.9 backwards compatible, or did it introduce rich-root (thereby putting a floor on | 03:14 |
| AfC | backwards compatibility, of something 1.9 (or $whatever)? | 03:14 |
| dobey | i'm not sure | 03:16 |
| AfC | [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:18 |
| lifeless | AfC: there is 1.9 and 1.9-rich-root | 03:30 |
| AfC | lifeless: ah | 03:34 |
| AfC | So we haven't culled rich-root yet. Ok. | 03:34 |
| AfC | Can a ~1.6 client read a 1.9 branch and downgrade? | 03:35 |
| AfC | (format=1.9 branch, that is; I know a bzr version 1.9 server will work) | 03:35 |
| LarstiQ | lifeless: on the off hand it's a simple answer, what is keeping rich-root from becoming default? | 03:53 |
| Peng_ | AfC: 1.9 repos are only compatible with 1.9. | 04:45 |
| Peng_ | 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:46 |
| Peng_ | (Well, 1.9rc1 I guess) | 04:47 |
| stampp- | Howdy folks | 05:17 |
| codeRat | 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:30 |
| jszakmeister|awa | 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:35 |
| codeRat | so there's no way around? | 08:36 |
| jszakmeister|awa | dunno. | 08:37 |
| codeRat | ok, thank you | 08:37 |
| jszakmeister|awa | I'm not sure how/when that module is used. | 08:37 |
| codeRat | at least I know what to look for :) | 08:37 |
| jszakmeister|awa | Looks like bzrlib/shellcomplete.py is the culprit | 08:38 |
| codeRat | but it strange that a program that is made for windows does use a module for unix :S | 08:39 |
| * jszakmeister|awa agrees | 08:39 | |
| === jszakmeister|awa is now known as jszakmeister | ||
| === Guest27644 is now known as ronny | ||
| === jszakmeister is now known as jszakmeister|awa | ||
| alefteris | hello all. why when i commit with bzr ci -x a_folder, deleted files in the bzr root directory are not being removed? | 10:00 |
| alefteris | i meant in the bzr branch root directoy | 10:02 |
| pygi | hi ho | 10:24 |
| willwill | hello, I want bzr branch to branch my repository then another one | 13:17 |
| willwill | (like apt-get dependencies) | 13:17 |
| AfC | Write a shell script? | 13:19 |
| willwill | AfC, I think svn can do this | 13:19 |
| AfC | so? | 13:20 |
| willwill | OK, I found this http://bazaar-vcs.org/NestedTreeSupport | 13:24 |
| willwill | still not supported yet :( | 13:32 |
| hno | 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:25 |
| hno | this is a lightweight checkout from a local repository where the branch is bound to the remote repository. | 19:27 |
| jelmer | hi hno | 19:28 |
| hno | hi jelmer | 19:28 |
| jelmer | hopefully one of the Australians can have a look when they wake up | 19:28 |
| hno | 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:30 |
| hno | does the same without the bind as well.. | 19:38 |
| hno | next, upgrade to 1.9... | 19:38 |
| berto- | i have a branch of bzr's repo; how can i view the 1.9 release? | 19:41 |
| berto- | i tried bzr tags but got nothing on the command line. | 19:41 |
| Peng_ | Yeah, there aren't tags. | 19:41 |
| berto- | how do i find out what rev v1.9 was cut from? | 19:42 |
| Peng_ | The 1.9 release branch is http://bazaar-vcs.org/bzr/bzr.1.9/ . I'd assume it was cut from that. | 19:43 |
| berto- | 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 |
| berto- | i'm about to try that. | 19:44 |
| berto- | it would be silly for me to have to rebranch the whole thing when i have the repo already. | 19:45 |
| Peng_ | If you use a shared repo, it won't have to download the data again. | 19:46 |
| berto- | right, ok, cool. | 19:47 |
| rocky | jelmer: ready for a simple bzr-svn bug report? :) | 19:54 |
| jelmer | rocky, always :-) | 19:55 |
| rocky | jelmer: http://cluebin.appspot.com/pasted/3001 | 19:55 |
| hno | 19 behaved better. Still not good, but much better. | 19:56 |
| hno | 1.9 i meant.. | 19:56 |
| jelmer | rocky, thanks, fixed | 20:02 |
| Peng_ | 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:04 |
| hno | Peng_: The local was already updated to btree, but the remote can not be updated as it's a shared repository. | 20:05 |
| Peng_ | Ah. | 20:05 |
| hno | 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:08 |
| Peng_ | Yeah, it /should/. | 20:10 |
| hno | 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:15 |
| hno | bzr upgrade still running... | 20:26 |
| rocky | jelmer: there a branch i should get? | 20:27 |
| jelmer | rocky, yes, the 0.4 one | 20:28 |
| rocky | jelmer: hm, launchpad isn't seeing the fix ... http://bazaar.launchpad.net/~jelmer/bzr-svn/0.4/changes/1741?start_revid=1741 | 20:29 |
| rocky | http://bazaar.launchpad.net/~jelmer/bzr-svn/0.4/changes rather | 20:29 |
| jelmer | rocky, launchpad isn't the main location for bzr-svn, it just has a mirror | 20:29 |
| rocky | ohhh | 20:30 |
| jelmer | http://people.samba.org/bzr/jelmer/bzr-svn/0.4 | 20:30 |
| rocky | 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 |
| rocky | basically i'm trying to see the last revision so i can just do a manual fix here ;) | 20:30 |
| jelmer | I don't have the right plugin installed from my current machine | 20:31 |
| jelmer | so it's not updated atm | 20:31 |
| rocky | gotcha | 20:31 |
| meoblast001 | hi | 20:34 |
| rocky | jelmer: how does your bzr/http setup work? you using the stock http smart server or something more ? | 20:35 |
| jelmer | no, I'm pushing to a remote server using bzr+ssh | 20:36 |
| jelmer | the location I push to is accessible using http | 20:36 |
| rocky | gotcha | 20:36 |
| rocky | 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:36 |
| lifeless | rocky: there are | 20:38 |
| lifeless | rocky: the uk NHS's bzr repos are read-write http(s I think) | 20:39 |
| hno | lifeless: Hi! | 20:39 |
| lifeless | hno: hi | 20:39 |
| rocky | oh cool | 20:39 |
| lifeless | rocky: on windows with IIS for extra fun :P | 20:39 |
| rocky | 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:39 |
| lifeless | rocky: bzr+ssh is what most people use I think, because its basically zero setup | 20:40 |
| lifeless | bzr: is a registered port with the IANA, so its not that proprietary :P | 20:40 |
| rocky | 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:40 |
| lifeless | rocky: sure, but you asked about other people :P | 20:41 |
| rocky | ;) | 20:41 |
| lifeless | bbiab, morning $foo | 20:41 |
| hno | how long is an bzr upgrade supposed to take? | 20:43 |
| rocky | jelmer: it's too bad easy_install bzr-svn doesn't install bzr-svn properly | 20:45 |
| jelmer | rocky: install should work though | 20:46 |
| rocky | jelmer: yeah "python setup.py install" works fine | 20:46 |
| rocky | 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 |
| rocky | it'd be nice if the last step was ./bin/easy_install bzr-svn | 20:46 |
| lifeless | hno: if its in the same model and local, a few minutes | 20:47 |
| jelmer | What would be required to support easy_install? I must admit I've never used it | 20:47 |
| lifeless | hno: what exact command did you run ? | 20:47 |
| hno | bzr upgrade --format=1.9-rich-root | 20:47 |
| lifeless | hno: cancel that | 20:47 |
| lifeless | hno: remove .bzr, rename backup.bzr to .bzr | 20:48 |
| hno | it was on a copy.. | 20:48 |
| lifeless | then just cancel it | 20:48 |
| hno | done, and restored. | 20:48 |
| lifeless | hno: is this the squid repo ? | 20:48 |
| hno | yes, still having trobles with those indexes.. | 20:48 |
| lifeless | hno: 'bzr upgrade --1.9' | 20:48 |
| lifeless | hno: and you need a 1.9 client to use a 1.9 repository | 20:49 |
| rocky | 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 |
| rocky | i wouldn't think it'd be much work | 20:49 |
| hno | lifeless: 1.9 on both. | 20:50 |
| lifeless | hno: cool, was just answering your question from scrollback | 20:50 |
| jelmer | rocky, I'll happily apply patches that fix easy_install, as long as there's no overhead per release | 20:50 |
| hno | lifeless: 1.9 did behave better than 1.8, but still very heavy. | 20:50 |
| rocky | jelmer: should just be a one-time change | 20:51 |
| hno | 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 |
| lifeless | hno: sounds about right | 20:52 |
| hno | lifeless: followed by 75KB of actual pack data. | 20:54 |
| hno | 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) | 20:59 |
| lifeless | hno: the btree index will help immensely I think | 21:00 |
| lifeless | hno: 4K pages, 100-way fanout | 21:00 |
| lifeless | breakfasttime | 21:02 |
| hno | lifeless: Testing.. | 21:03 |
| hno | done. | 21:04 |
| hno | lifeless: Using 1.9 format on the remote result in a transfer of indicies 448673 bytes, packs 70842 bytes. | 21:06 |
| jelmer | the smart server should be smarter :-) | 21:08 |
| lifeless | hno: interesting | 21:21 |
| hno | packs got a little smaller as upgrade also repacks the repository. | 21:32 |
| hno | but still, that's at least 445k unwanted overhead.. | 21:33 |
| lifeless | hno: we're agreed that it should stream | 21:35 |
| lifeless | 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:35 |
| lifeless | which is arge | 21:36 |
| lifeless | *large* | 21:36 |
| hno | lifeless: I can tar up my local repository for you to experiment from, if you need a startingpoint to trigger this.. | 21:38 |
| lifeless | hno: I have a separate performance issue I'm working on at the moment | 21:39 |
| lifeless | hno: but thanks | 21:39 |
| hno | lifeless: Ok. I'll keep a copy around for some time anyway. | 21:40 |
| lifeless | jelmer: bug 295611 - whats the summary? | 21:41 |
| ubottu | Launchpad bug 295611 in bzr "NoSuchRevision: KnitPackRepository" [Undecided,Confirmed] https://launchpad.net/bugs/295611 | 21:41 |
| jelmer | lifeless, basically it's similar to the bug we looked at during the summer | 21:42 |
| * jelmer looks again | 21:43 | |
| jelmer | lifeless, sorry, it's actually related to ghosts | 21:43 |
| jelmer | where "bzr diff" assumes that the revision info for the last-changed-revision of all files in the tree are present | 21:44 |
| lifeless | 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 |
| jelmer | lifeless, nope | 21:49 |
| jelmer | lifeless, bzr diff prints the timestamp of the original text of a file and of the new revised one | 21:50 |
| lifeless | with you so far | 21:51 |
| jelmer | in order to obtain the timestamp for the old text, it uses the text revision and calls Repository.get_revision(text_revision) | 21:51 |
| jelmer | if that text_revision happens to be a ghost, things break | 21:51 |
| lifeless | ah | 21:51 |
| lifeless | so there are some interactions here | 21:51 |
| lifeless | we really need to sit down and clean up the ghost handling once and for all | 21:52 |
| lifeless | the interaction I'm thinking of is: we only copy text (id,X) when we copy revision X | 21:52 |
| lifeless | so that repository isn't clonable by bzr at all anyhow | 21:52 |
| lifeless | (as it currently stands) | 21:52 |
| jelmer | that would break bzr-svn, which usually only pushes lhs revisions | 21:53 |
| jelmer | that may contain references to texts introduced by rhs revisions | 21:53 |
| jelmer | *those lhs revisions may contain references to texts introduced by rhs revisions | 21:54 |
| lifeless | jelmer: 'does break' | 21:57 |
| lifeless | jelmer: though I think I've mentioned before that having those references isn't strictly valid | 21:58 |
| lifeless | under the current rules. And thus the need to fix this forever | 21:58 |
| lifeless | 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 | 21:59 |
| jelmer | lifeless, ah, that makes sense | 22:10 |
| lifeless | the problem at the moment is that doing 'inventory_delta(X,Y)' is very expensive | 22:11 |
| lifeless | 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:11 |
| lifeless | 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 |
| lifeless | and that is very very bad on big trees; which are also likely to have more committers and thus trigger it more often | 22:12 |
| yml | 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:19 |
| yml | 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 |
| lifeless | yml: I imagine we just need to upload a new package to the ppa | 22:20 |
| lifeless | yml: if you are using the ppa | 22:20 |
| yml | lifeless: Yes I am using PPA | 22:21 |
| yml | lifeless: else is there a place where I could download bzr-svn .deb ? | 22:22 |
| jelmer | yml, Debian should have one | 22:23 |
| jelmer | lifeless, what's the ETA on split-inventories? | 22:23 |
| lifeless | jelmer: draft results are promising | 22:25 |
| lifeless | jelmer: no specific timeline, you know how software dev goes | 22:25 |
| jelmer | lifeless: Ah, cool - how complete is it though? | 22:26 |
| jelmer | Initial work done? Some things already work ? Only a few tests left that need fixing? | 22:26 |
| lifeless | 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:26 |
| lifeless | needs lots of profiling and feedback cycle | 22:27 |
| lifeless | compression is not really touched, call that 10% | 22:27 |
| jelmer | ah, so this is the CHK stuff I've seen scrolling past on bazaar-list.. :-) | 22:27 |
| lifeless | yes | 22:27 |
| lifeless | chk is content hash key | 22:28 |
| lifeless | which is the obvious implementation to satisfy a canonical representation with nested hashability | 22:29 |
| yml | jelmer : Is that the deb that I should download ? | 22:29 |
| yml | http://packages.debian.org/fr/experimental/bzr-svn | 22:29 |
| jelmer | yep | 22:29 |
| lifeless | its slightly more general than git's keys, because its forward extensible (in disk layout) to sha256 etc | 22:30 |
| jelmer | lifeless, ah, nice | 22:30 |
| lifeless | CHKMap is a dict built in that layer | 22:31 |
| lifeless | which as a basic datatype is reusable | 22:31 |
| yml | ubuntu complains about libsvn1 being to hold ? | 22:46 |
| jelmer | yml, They probably have different versions of libsvn1 | 22:48 |
| yml | ok I will wait for a while | 22:49 |
| fullermd | lifeless: Speaking of inventory stuff... does the new stuff you're working on support referencing unchanged files in a revision? | 23:21 |
| lifeless | fullermd: how do you mean? | 23:23 |
| fullermd | bzr ci --unchanged some/file | 23:23 |
| lifeless | fullermd: no | 23:25 |
| fullermd | I'm going to give you another chance to answer :) | 23:25 |
| lifeless | fullermd: no | 23:25 |
| lifeless | fullermd: because.. | 23:25 |
| === rocky1 is now known as rocky | ||
| jelmer | fullermd, why would you ever want to do that? | 23:28 |
| fullermd | Well, why would you ever want to commit --unchanged? | 23:28 |
| fullermd | If there's a reason for the one, there's a reason for the other. | 23:29 |
| lifeless | 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 |
| poolie | hello | 23:30 |
| poolie | hello lifeless | 23:31 |
| lifeless | 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 |
| lifeless | 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 |
| lifeless | hi poolie | 23:31 |
| poolie | i'm going to try running john's packaging script | 23:33 |
| fullermd | 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 |
| lifeless | fullermd: I think you asked about a variation ;P | 23:35 |
| lifeless | fullermd: or my thinking has refined | 23:35 |
| fullermd | Well, we could always use more refinery. Or distillery, anyway. | 23:36 |
| lifeless | k, time for full screen code, poolie - ping me via skype(chat|voice) when ready | 23:37 |
| poolie | lifeless: ok, the net here may be a bit slow to actually do voip | 23:38 |
| poolie | we'll see | 23:38 |
| fullermd | Dragonfly ended up with git, BTW. | 23:41 |
| fullermd | http://article.gmane.org/gmane.os.dragonfly-bsd.kernel/12212 | 23:41 |
| fullermd | (not overly surprising; hg had a late surge, but git was up 2:1 most of the voting time) | 23:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!