[00:07] ok [00:08] packaged bzr-loom, bzr-avahi and bzr-upload [00:08] nice [00:08] bzr-search ? :P [00:08] hmm [00:08] time to grab trackerd's source [00:09] lifeless: Sure, once it's not under such heavy development anymore :-) [00:13] lifeless, I thought of something I'll need for loggerhead in bzr-search. Using custom locations for indexes [00:14] beuno: open_index_for is the place to extend to do that [00:14] I'll take a shot at a patch as soon as I properly get LH using bzr-search [00:14] I wrote it with that in mind, e.g. to allow indexing bzr-svn repositories to ~/.bazaar/search/UUID/ [00:15] great, should be easy-ish then [00:15] specifically, an index is given a root transport when its opened [00:15] and separate branch object [00:17] jelmer, have you continued using bzr-upload? [00:17] beuno: yeah, I use it now and then [00:17] vila was relunctant to make it public yet, but, if there's going to be a deb, I suppose we should announce it somehow [00:18] beuno: Symlink support is a problem for some branches though, so I have to fallback to manual copying :-( [00:18] I have too, and haven't run into any major issues [00:18] beuno: I've just created a package, it's not been uploaded yet [00:18] If you'd rather not have it out there yet, I'd be happy to wait [00:19] actually, I'd prefer it is, so we can have more contributors :) [00:19] and it seems to work good enough en most cases [00:19] but, well, vila has to agree too [00:24] beuno: did you upload your bzr-search LH branch ? [00:25] lifeless, not yet, no. I was burnt out yesterday and was having problems getting the branch PATH to send to bzr-search (aka, don't hardcode the path) [00:25] I'm looking at it now, but I'm leaving to a birthday in ~20-30 minutes, so I don't know if I'll make it :/ [00:26] it's a stupid thing, really. I was just going around in circled yesterday [00:32] release early release often :) [00:32] just push-with-caveats [00:33] yes, I just thought making people edit the source code to change my local path seemed pushing that too far [00:33] I'll try to fix it, and, if now, push anywa [00:33] *anyway [00:58] lifeless, pushed it to: lp:~beuno/loggerhead/bzr-search_integration [00:58] beuno: cool [00:58] beuno: so why does LH need non-colocated indices? [00:59] I mean: [00:59] lifeless, it may not, but there may be use cases where LH can't write to the .bzr directories [00:59] if a user creates an index [00:59] then other pull/push operations update it [00:59] LH doesn't need to do indexing [00:59] yes, that should be the default behaviour [01:00] having that hook is perfect [01:00] right now we have an odd timer which re-scans every 6 hours :/ [01:01] but I can see a few use cases where LH will only be able to read the repos, not write to them [01:01] oh man [01:01] I am loving this [01:01] I'm looking around the tracker source code [01:02] so to find where dpopen occurs I do a bzr search dpopen :) [01:02] desktop integration, very sexy [01:03] well [01:03] I don't think bzr-search is a good idea for the searchbar ;) [01:04] but I wanted to see what tracker does under the hood [01:04] also look at telling it to ignore .bzr [01:05] (I may be wrong about bzr-search being a good idea for the deskbar search, its just current opinion) [01:06] why don't you think it's a good idea? [01:06] context [01:06] which is another way of saying that it will reduce precision [01:06] hm, I haven't used tracker to know about how that can be achieved. It's the first thing I remove when doing fresh installs :) [01:07] but, conceptually, being able to track down commits and source code *does* sound good for someone who uses such a thing [01:08] of course, there are many other more interesting places to get it working first, like bzr-gtk [01:08] and bzr-gedit [01:09] which I suspect can share the code [01:09] yah [01:12] I'm off to get drun... ehm, a birthday party [01:12] :) [01:23] oh oh oh I should do suggestions [01:27] vila: no packages for 1.6 for ubuntu yet. i didn't want to install it from source, that's all :) [01:46] vila: nm. i see there's a beta-ppa repo available now. i'll install from there [02:08] ok, this should be interesting [02:08] indexing all debian source [02:08] haha [02:08] remember that mega repo I created? [02:08] 16K branches, 22G [02:08] while index is per-branch the underlying code isn't so coupled [02:08] so: [02:09] >>> import bzrlib [02:09] >>> from bzrlib.plugins import search [02:09] >>> index = search.index.open_index_url('.') [02:09] >>> r = bzrlib.repository.Repository.open('..') [02:09] >>> from bzrlib.ui.text import TextUIFactory [02:09] >>> bzrlib.ui.ui_factory = TextUIFactory() [02:09] >>> [02:09] >>> index.index_revisions(index._branch, r.all_revision_ids()) [02:09] :) [02:12] bwaha [02:19] what does this mean? "bzr: ERROR: Repository KnitPackRepository('https://myusername@server.org/bzr/.bzr/repository/') is not compatible with repository KnitPackRepository('file:///home/tro/code/asdf/.bzr/repository/')" [02:19] i'm trying to push an existing checkout to a remote webdav branch [02:19] webdav repo, sorry [02:21] is bzr-svn involved? [02:27] tro: one of the repositories is rich root, one isn't [02:28] bob2: i thought it was, but i just tried with a brand-new empty one and it didn't work [02:28] tro: how did you make the brand new empty one? [02:28] bbiab [02:28] lifeless: i think i created the repo with the same version of bzr, but maybe 1.5 instead of 1.6 [02:28] i used bzr init-repo --no-trees [02:29] i'll try updating the bzr version on the remote side and recreate the repo (it's empty now anyway) [02:30] the remote one seems to be rich root [02:30] what's the default that is created with "bzr init-repo" [02:32] --pack-092 [02:32] i don't have to worry about old bzr versions. should i just recreate the repo with --rich-root-pack ? [02:33] well, once you figure out which is whichm yeah [02:43] how do i find out which format a tree is in? [02:43] repository, technically. bzr info https://myusername@server.org/bzr/.bzr/repository/ ; bzr info file:///home/tro/code/asdf/.bzr/repository/ [02:44] ok, now i see that my checkout is the one that's in pack-0.92. any way to convert it to rich-root-pack? [02:45] what command ddi you run that caused that error? co? [02:46] bzr push [02:46] hmm .. when both the remote repo and the local checkout are in pack-0.92 i get the same error [03:46] dunno how you can get that error if both sides are pack-0.92, sorry [04:30] tro: bzr info -v will tell you the format of a url [04:30] tro: can you do that and show the repository format line here from each output [04:32] afk again [05:14] lifeless: from the shared repo: [05:14] control: Meta directory format 1 [05:14] repository: Packs containing knits without subtree support [05:14] from the checkout: [05:14] control: Meta directory format 1 [05:15] working tree: Working tree format 4 [05:15] branch: Branch format 6 [05:15] repository: Packs containing knits without subtree support [05:15] they're both pack-0.92 [06:08] tro: but you get that error when you push ? [06:08] tro: did you do 'bzr info -v URLITISPUSHINGTOO' ? [06:30] hm, on linux I see a No handlers could be found for logger "bzr" message when I use the bzr command [06:30] and I get duplicate messages on stdout [06:30] [ 8249] 2008-06-12 23:11:37.746 INFO: All changes applied successfully. [06:30] All changes applied successfully. === mwhudson__ is now known as mwhudson [08:02] kumi2: please file a bug, that shouldn't happen === Verterok is now known as Guest51306 === _Verterok_ is now known as Verterok === mwhudson__ is now known as mwhudson [11:36] codespeak's svn still seems to defeat bzr-svn [11:40] 0.4 branch? [11:41] yeah [11:41] jelmer: http://pastebin.ubuntu.com/20308/ [12:12] hmm, something is not concatenating urls right === Leonidas is now known as Zedshawnidas [12:30] Hi all === Zedshawnidas is now known as Leonidas === bigdo2 is now known as bigdog [15:22] hi! i get a traceback when running 'bzr parent bzr+ssh://some/repository/some/file'. see http://pastebin.com/m1c159a5c . not sure if thati [15:23] not sure if that's supposed to work, but it seems wrong to get a traceback anyways... [15:25] what's "bzr parent"? [15:29] james_w: by the look of the arguments list in the output, not the problem [15:29] no, I was just curious [15:29] probably the parent of the current branch [15:30] it's not a command I've seen before, I was wondering where it came from. It might be useful to have in the core. [15:30] mysql_plugins /home/sven/.bazaar/plugins/mysql_plugins [0.3.7] [15:32] sorry, bzr parent is from a plugin library i'm using. new paste with `bzr parent` substituted: http://pastebin.com/m4523db02 [15:32] jamesh, james_w ^ [15:32] sven_: so, looking at your output, the error came from the "bzr annotate" call rather than the "bzr parent" call in backticks [15:33] jamesh, yes [15:35] sven_: just trying to reproduce locally [15:36] I think you are seeing https://bugs.edge.launchpad.net/bzr/+bug/237067 [15:36] Launchpad bug 237067 in bzr ""bzr check" on bzr+ssh:// branch returns ObjectNotLocked error" [Undecided,New] [15:37] read John's first comment for the details. [15:37] don't see an exception, but it is pegging the CPU (this is bzr+ssh to localhost) [15:49] hmm, ok. i don't understand the thread completely. should i add my paste to that bug report? [15:51] I don't think it's needed, John seems to know what's goind on. [15:52] I triaged the report, so hopefully it will get noticed and fixed. [15:53] james_w, jamesh, thank you! [15:56] no problem === sven_ is now known as sven_|away [16:32] Does bazaar support something like this: http://upload.wikimedia.org/wikipedia/en/a/ac/Hgk.png ? [16:32] I don't mean the graphical program, but the tree merging [16:32] If it exists in bzr, how do you do it? [16:35] (and is there a way to generate those fancy graphics? :)) [16:35] "bzr viz" is similar to hgk [16:35] (part of bzr-gtk) [16:44] hi qense [16:44] hello james_w [16:44] bzr viz looks great [17:15] qense: yes, it is really great === qense is now known as qense|away === dpm_ is now known as dpm === qense|away is now known as qense [19:59] Hey devs, I'd like to take a whack at fixing bug 109115. It's marked trivial, so I didn't think it'd require too much. [19:59] Launchpad bug 109115 in bzr "nicer error when unable to commit large files" [Medium,Confirmed] https://launchpad.net/bugs/109115 [19:59] hey rockstar [19:59] Hi james_w [20:01] I'm not sure how that should be tested, perhaps create a file like class that returns a huge amount of data [20:01] the fixing it shouldn't be too hard though, just finding an appropriate place to put a try block. [20:02] you might want to start off by creating the exception that will be thrown when the error is hit: bzrlib/errors.py [20:07] james_w, yea, I think I've got a fix. The testing method seems to be the most difficult part. [20:08] it might be something that will be allowed in without a test, but if we can come up with a way then it would be better. [20:08] Yea, it's always better to have a test. [20:08] However, writing a test is what's going to help me personally start understanding the code base itself. [20:09] true [20:09] so the problem is when you commit it reads a copy of the file in to memory, and then falls over? [20:10] Yea, if the file is too big, it fills up virtual memory. [20:12] at what level did you put the try block? [20:14] bzrlib.tuned_gzip:352 has an if statement that makes sure the filesize > 0. I added a filesize max limit to it. [20:15] ah, ok. [20:15] so this can be tested really low then [20:15] I've never looked at tests for that area though. [20:16] Yea, I'll have to explore. I'm still reading HACKING.txt - Thought it would be good to just give everyone a heads up that I was working on it. [20:17] ah cool, thanks for working on it. [20:18] had you used bzr before you started your current job? [21:02] are there any plans to allow blocking and unblocking of revisions like svnmerge.py === mwhudson_ is now known as mwhudson [21:42] Any insight how to run bzr like in launchpad.net? I mean the client uses bzr+ssh:// but don't want to provide the shell access to the users. Using /usr/bin/scponly didn't work. [21:43] well, launchpad uses a custom ssh server [21:43] Hmm tricky... [21:43] You could do it with any restricted shell. I think scponly has some configurability... [21:43] but you can allow users to only be able to execute 'bzr serve --inet --allow-writes /' [21:44] or whatever it is bzr+ssh uses [21:44] So basically using the shell that only allows to run bzr? [21:45] not really [21:46] it's an openssh thing, you can restrict the commands a given user can run [21:46] * mwhudson has to run away, biab [21:46] Ok, many thanks! === keir_ is now known as keir [22:10] Wow the solution was very easy. I made this script as the bzr-use-only shell: http://dev.blankonlinux.or.id/browser/infrastruktur/bzr-ssh-shell/bzr-ssh-shell === tro|| is now known as tro === Pricey is now known as PriceChild === tro|| is now known as tro [23:22] mwhudson, I've been spying on your paste branch... seems we're close to dropping turbogears and cherrypy :_ [23:22] :) [23:23] beuno: yeah, let's hope so [23:23] it's very very hackish at the moment, but it does work [23:27] mwhudson, btw, you wouldn't happen to know a good way to get a branch's path through the history object, would you? [23:27] path? [23:27] yes, absolute path to it [23:28] i guess by looking at the bzrlib branch object [23:28] why do you want it though? [23:28] currently loggerhead works fine with branches access over e.g. http [23:29] bzr-search integration :) [23:29] and, mumble, it would be nice if it carried on that way [23:30] http://bazaar.launchpad.net/~beuno/loggerhead/bzr-search_integration/annotate/argentina%40gmail.com-20080614235107-upywmflu0p2b1t1w?start_revid=argentina%40gmail.com-20080614235315-sd5uapabc2aym4f0&file_id=search.py-20080614235103-lpt63f7b2drplju8-1 [23:30] that's where I need to plug it in [23:31] (I call that within the History class, so I can pass on an extra value) [23:32] moin [23:33] howdy lifeless [23:34] lifeless: morning [23:37] hi thumper [23:38] lifeless: are you at the vibe? [23:38] not yet [23:38] going though? [23:39] wtoday for sure [23:39] other days will depend on stacked progress [23:56] beuno: ah, um, ok [23:56] beuno: h._branch.transport.base ? [23:56] no, that probably isn't right [23:56] hello [23:57] me too [23:57] mwhudson, I suppose I can pass whatever location LH is using too, of course. I meant [23:57] absolute path as in "branch location" :) [23:57] hi poolie [23:57] beuno: right :) [23:57] i think the kids call these things URLs nowadays [23:58] mwhudson: the function is open_index_url :P [23:58] beuno: I refactored though, there is open_index_branch too now [23:59] sounds like a better fit [23:59] * beuno looks [23:59] lifeless: quick heads up on that performance testing - all ok at first glance