[03:02] <LaserJock> are there any tricks to getting pulls going any faster?
[03:04] <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:05] <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:06] <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:07] <dobey> not me though. i'm just a user for the most part
[03:09] <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:13] <AfC> I never quite got it straight what the conclusion was on the list...
[03:13] <dobey> not sure
[03:14] <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:16] <dobey> i'm not sure
[03:18] <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:30] <lifeless> AfC: there is 1.9 and 1.9-rich-root
[03:34] <AfC> lifeless: ah
[03:34] <AfC> So we haven't culled rich-root yet. Ok.
[03:35] <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:53] <LarstiQ> lifeless: on the off hand it's a simple answer, what is keeping rich-root from becoming default?
[04:45] <Peng_> AfC: 1.9 repos are only compatible with 1.9.
[04:46] <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:47] <Peng_> (Well, 1.9rc1 I guess)
[05:17] <stampp-> Howdy folks
[08:30] <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:35] <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:36] <codeRat> so there's no way around?
[08:37] <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:38] <jszakmeister|awa> Looks like bzrlib/shellcomplete.py is the culprit
[08:39] <codeRat> but it strange that a program that is made for windows does use a module for unix :S
[08:39]  * jszakmeister|awa agrees
[10:00] <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:02] <alefteris> i meant in the bzr branch root directoy
[10:24] <pygi> hi ho
[13:17] <willwill> hello, I want bzr branch to branch my repository then another one
[13:17] <willwill> (like apt-get dependencies)
[13:19] <AfC> Write a shell script?
[13:19] <willwill> AfC, I think svn can do this
[13:20] <AfC> so?
[13:24] <willwill> OK, I found this http://bazaar-vcs.org/NestedTreeSupport
[13:32] <willwill> still not supported yet :(
[19:25] <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:27] <hno> this is a lightweight checkout from a local repository where the branch is bound to the remote repository.
[19:28] <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:30] <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:38] <hno> does the same without the bind as well..
[19:38] <hno> next, upgrade to 1.9...
[19:41] <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:42] <berto-> how do i find out what rev v1.9 was cut from?
[19:43] <Peng_> The 1.9 release branch is http://bazaar-vcs.org/bzr/bzr.1.9/ . I'd assume it was cut from that.
[19:44] <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:45] <berto-> it would be silly for me to have to rebranch the whole thing when i have the repo already.
[19:46] <Peng_> If you use a shared repo, it won't have to download the data again.
[19:47] <berto-> right, ok, cool.
[19:54] <rocky> jelmer: ready for a simple bzr-svn bug report? :)
[19:55] <jelmer> rocky, always :-)
[19:55] <rocky> jelmer: http://cluebin.appspot.com/pasted/3001
[19:56] <hno> 19 behaved better. Still not good, but much better.
[19:56] <hno> 1.9 i meant..
[20:02] <jelmer> rocky, thanks, fixed
[20:04] <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:05] <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:08] <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:10] <Peng_> Yeah, it /should/.
[20:15] <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:26] <hno> bzr upgrade still running...
[20:27] <rocky> jelmer: there a branch i should get?
[20:28] <jelmer> rocky, yes, the 0.4 one
[20:29] <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:30] <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:31] <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:34] <meoblast001> hi
[20:35] <rocky> jelmer: how does your bzr/http setup work? you using the stock http smart server or something more ?
[20:36] <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:38] <lifeless> rocky: there are
[20:39] <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:40] <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:41] <lifeless> rocky: sure, but you asked about other people :P
[20:41] <rocky> ;)
[20:41] <lifeless> bbiab, morning $foo
[20:43] <hno> how long is an bzr upgrade supposed to take?
[20:45] <rocky> jelmer: it's too bad  easy_install bzr-svn doesn't install bzr-svn properly
[20:46] <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:47] <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:48] <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:49] <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:50] <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:51] <rocky> jelmer: should just be a one-time change
[20:52] <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:54] <hno> lifeless: followed by 75KB of actual pack data.
[20:59] <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)
[21:00] <lifeless> hno: the btree index will help immensely I think
[21:00] <lifeless> hno: 4K pages, 100-way fanout
[21:02] <lifeless> breakfasttime
[21:03] <hno> lifeless: Testing..
[21:04] <hno> done.
[21:06] <hno> lifeless: Using 1.9 format on the remote result in a transfer of indicies 448673 bytes, packs 70842 bytes.
[21:08] <jelmer> the smart server should be smarter :-)
[21:21] <lifeless> hno: interesting
[21:32] <hno> packs got a little smaller as upgrade also repacks the repository.
[21:33] <hno> but still, that's at least 445k unwanted overhead..
[21:35] <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:36] <lifeless> which is arge
[21:36] <lifeless> *large*
[21:38] <hno> lifeless: I can tar up my local repository for you to experiment from, if you need a startingpoint to trigger this..
[21:39] <lifeless> hno: I have a separate performance issue I'm working on at the moment
[21:39] <lifeless> hno: but thanks
[21:40] <hno> lifeless: Ok. I'll keep a copy around for some time anyway.
[21:41] <lifeless> jelmer: bug 295611 - whats the summary?
[21:42] <jelmer> lifeless, basically it's similar to the bug we looked at during the summer
[21:43]  * jelmer looks again
[21:43] <jelmer> lifeless, sorry, it's actually related to ghosts
[21:44] <jelmer> where "bzr diff" assumes that the revision info for the last-changed-revision of all files in the tree are present
[21:49] <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:50] <jelmer> lifeless, bzr diff prints the timestamp of the original text of a file and of the new revised one
[21:51] <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:52] <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:53] <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:54] <jelmer> *those lhs revisions may contain references to texts introduced by rhs revisions
[21:57] <lifeless> jelmer: 'does break'
[21:58] <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:59] <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
[22:10] <jelmer> lifeless, ah, that makes sense
[22:11] <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:12] <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:19] <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:20] <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:21] <yml> lifeless: Yes I am using PPA
[22:22] <yml> lifeless: else is there a place where I could download bzr-svn  .deb ?
[22:23] <jelmer> yml, Debian should have one
[22:23] <jelmer> lifeless, what's the ETA on split-inventories?
[22:25] <lifeless> jelmer: draft results are promising
[22:25] <lifeless> jelmer: no specific timeline, you know how software dev goes
[22:26] <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:27] <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:28] <lifeless> chk is content hash key
[22:29] <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:30] <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:31] <lifeless> CHKMap is a dict built in that layer
[22:31] <lifeless> which as a basic datatype is reusable
[22:46] <yml> ubuntu complains about libsvn1 being to hold ?
[22:48] <jelmer> yml, They probably have different versions of libsvn1
[22:49] <yml> ok I will wait for a while
[23:21] <fullermd> lifeless: Speaking of inventory stuff...   does the new stuff you're working on support referencing unchanged files in a revision?
[23:23] <lifeless> fullermd: how do you mean?
[23:23] <fullermd> bzr ci --unchanged some/file
[23:25] <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:28] <jelmer> fullermd, why would you ever want to do that?
[23:28] <fullermd> Well, why would you ever want to commit --unchanged?
[23:29] <fullermd> If there's a reason for the one, there's a reason for the other.
[23:30] <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:31] <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:33] <poolie> i'm going to try running john's packaging script
[23:35] <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:36] <fullermd> Well, we could always use more refinery.  Or distillery, anyway.
[23:37] <lifeless> k, time for full screen code, poolie - ping me via skype(chat|voice) when ready
[23:38] <poolie> lifeless: ok, the net here may be a bit slow to actually do voip
[23:38] <poolie> we'll see
[23:41] <fullermd> Dragonfly ended up with git, BTW.
[23:41] <fullermd> http://article.gmane.org/gmane.os.dragonfly-bsd.kernel/12212
[23:44] <fullermd> (not overly surprising; hg had a late surge, but git was up 2:1 most of the voting time)