[00:00] hi poolie [00:00] I slept in this morning :) [00:02] spiv, igc, do you want to talk? [00:03] lifeless: i was just saying to john i woke up about 6:30 on my holiday but now i find it hard to get going [00:03] :) [00:03] Sure. [00:48] morning [00:49] morning igc [01:10] lifeless: what is the difference between InventoryFile.text_id and InventoryFile.file_id exactly? [01:11] text_id? wtf [01:11] lifeless: in particular, they don't ever seem to differ - can they? [01:11] text_id was bzr 0.0.6 and before only [01:11] ah, ok [01:12] its in the api for compatibility, you don't want to set it or consult it [01:12] I came across it trying to find a solution to two problems in bzr-git: [01:13] - ideally I'd like to use one-tuples rather than two-tuples for file texts [01:13] - I need a place to stash the file modes that are stored for all git files [01:14] what would be in the one-tuples? [01:14] igc, thumper was asking about an ETA for historycache. Can you give me something specific? [01:16] spiv: let me know when you've done that review please [01:17] lifeless: blob sha [01:17] lifeless: that would of course bring up the problem of file graphs [01:17] right, bzr core doesn't do this [01:18] note that a blob sha != sha of the bytes [01:18] its sha of the bytes + git header [01:18] lifeless: yes, I know [01:18] lifeless: the blob sha is what I get from git though, for the content sha I have to fetch and unpack the blob [01:19] anyway, the second issue is more pressing [01:20] I've thought of two ugly solutions so far [01:20] rockstar: I'll try to get something out this week, but I think next week is more likely [01:20] storing the changed modes in a revision property [01:20] by file modes you mean extended permissions? [01:20] storing the modes in the texts for the directories [01:20] lifeless: unix file modes [01:20] igc, that's straight gangsta [01:21] lifeless: not sure if that's what you mean by extended permissions? [01:21] jelmer: broadly [01:21] jelmer: more than 'x' ;) [01:21] lifeless: ah, extended in that sense, yes :-) [01:22] note that we don't do more than x because extended permissions get in the way of VCS [01:22] lifeless: yes, I'm not arguing bzr should do more [01:22] I thought git didn't store full unix bits anyway, only a subset [01:22] lifeless: it does, but recent versions of git restrict a little bit what you can set [01:23] lifeless: (it does store full unix bits I mean) [01:23] ok [01:23] well [01:23] lifeless: In order to be able to reproduce the exact git commits from a bzr revision I need to store these modes somewhere [01:23] how does etckeeper store modes [01:24] lifeless: plaintext file in the root [01:25] lifeless: I'd prefer to keep this data away from the user though [01:25] jelmer: so you could either: special case it for git; write a general solution for bzr core and then use that; do something compatible with one of the other 'backup via vcs' tools out there and use that for bzr-git [01:25] lifeless: hmm [01:26] I'm ok with more bits being storable in bzr and our UI leaving them unset (though it implies a trinary field not a binary - unknown, off, on) [01:27] or a mask + bits [01:27] or something like that [01:27] [we don't want to suddenly start having the problems associated with setting overly strict modes on files we create etc] [01:28] this would take discussion [01:28] I think its worth doing [01:28] yeah, I think that makes sense in that this is something to keep in mind for the future [01:29] lifeless: reviewed [01:29] jelmer: now is a good time as we have a new format in beta [01:29] jelmer: if you act fast --development7-rich-root could do this [01:30] lifeless: I doubt I'd have enough time for that, unfortunately [01:31] jelmer: well, you never know :) [01:49] hmm, that reminds me [01:49] it looks like bundlebuggy is ignoring my rio serializer patch [01:54] abentley: ping [02:04] Hi , when I use 'bzr branch lp:opencog', I got an sokcket error, it said that that 'Connection timed out' [02:04] but I can connect to lp:opencog using browser [02:05] xiaohui: do you have an HTTP proxy perhaps? [02:05] you may need to set the http_proxy environment variable so that bzr uses the same proxy as your browser. [02:05] yeah, I use the HTTP proxy [02:06] I have set this enviroment variable [02:09] hi, spiv, the tracback is : [02:09] File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 846, in run_bzr_catch_errors [02:09] return run_bzr(argv) [02:09] File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 797, in run_bzr [02:09] ret = run(*run_argv) [02:09] File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 499, in run_argv_aliases [02:09] return self.run(**all_cmd_args) [02:11] xiaohui: please, use a pastebin for tracebacks, not the channel. [02:12] xiaohui: you should set http_proxy to "http://PROXY:PORT/" [02:12] oh ,sorry spiv [02:12] lifeless, that is it. === xiaohui_ is now known as xiaohui [02:48] spiv: 9 less ;) [02:58] I used ' bzr branch http://bazaar.launchpad.net/~opencog-dev/opencog/trunk', it worked [03:00] spiv: ping [03:00] lifeless: pong [03:00] my ptch failed [03:00] incremental change: [03:00] mm, one more sec :P [03:00] Heh. [03:01] what was the initial count you knocked 14 and 9 off? [03:01] bob2: 6 and 9, 43 [03:01] === modified file 'bzrlib/tests/bzrdir_implementations/test_bzrdir.py' [03:01] --- bzrlib/tests/bzrdir_implementations/test_bzrdir.py 2009-03-23 14:59:43 +0000 [03:01] +++ bzrlib/tests/bzrdir_implementations/test_bzrdir.py 2009-04-15 02:01:15 +0000 [03:01] @@ -1712,13 +1712,17 @@ [03:01] def test_get_config(self): [03:01] my_dir = self.make_bzrdir('.') [03:01] config = my_dir.get_config() [03:01] - if config is None: [03:01] - self.assertFalse( [03:01] - isinstance(my_dir, (bzrdir.BzrDirMeta1, RemoteBzrDir)), [03:01] - "%r should support configs" % my_dir) [03:02] - raise TestNotApplicable( [03:02] - 'This BzrDir format does not support configs.') [03:02] - config.set_default_stack_on('http://example.com') [03:02] + try: [03:02] + config.set_default_stack_on('http://example.com') [03:02] + except errors.BzrError, e: [03:02] + if 'Cannot set config' in str(e): [03:02] + self.assertFalse( [03:02] + isinstance(my_dir, (bzrdir.BzrDirMeta1, RemoteBzrDir)), [03:02] + "%r should support configs" % my_dir) [03:02] + raise TestNotApplicable( [03:02] + 'This BzrDir format does not support configs.') [03:02] + else: [03:02] + raise [03:02] self.assertEqual('http://example.com', config.get_default_stack_on()) [03:02] my_dir2 = bzrdir.BzrDir.open(self.get_url('.')) [03:02] config2 = my_dir2.get_config() [03:02] spiv: ^ faster than pastebin ;> [03:02] xiaohui: I'm glad its working for you [03:02] By the time your irc client pastes that at a rate of 1 line per 2 seconds it would have been quicker to just use a pastebin... [03:02] we have a known bug with xmlrpc which is a python bug [03:03] spiv: my browser is paged out; I have a test run indexing code by test which is making everything crawl [03:03] spiv: it would have been several minutes to get it up to a pastebin :( [03:04] * spiv hands lifeless an ec2 instance [03:04] spiv: :) I need more glue for that though, its a plugin yada yada [03:04] lifeless: what is the difference between 'lp:opencog' and the URL [03:04] xiaohui: lp:opencog makes a xmlrpc request to get the URL [03:04] lifeless: seems reasonable, bb:approve [03:04] xiaohui: and the xmlrpc library in python does not support proxies :( [03:07] so ,you mean that I should always use the URL [03:08] xiaohui: I think you will need to until we work around the bug yes [03:08] lifeless: I see , thank you [03:09] spiv: and a new patch up, set_parent_location, push down to 28 [03:10] lifeless: that will be more convienent if it support the proxies:) [03:10] xiaohui: indeed, we want to fix it; need someone to have the time [03:10] spiv: [BzrDir.open, mkdir, mkdir, BzrDirFormat.initialize, BzrDir.open, BzrDir.find_repositoryV3, BzrDir.create_repository, Repository.set_make_working_trees, Repository.lock_write, Repository.has_revision, Repository.get_parent_map, Repository.get_parent_map, Repository.insert_stream, Repository.insert_stream, Repository.get_parent_map, Repository.insert_stream, BzrDir.create_branch, Branch.lock_write, Branch.set_config_option, Branch.un [03:10] spiv: do you see what I see [03:12] lifeless: It doesn't matter, thank you:-) [03:13] lifeless: I see a cut-off line :P [03:13] spiv: oh foo [03:13] lifeless: ...Branch.set_config_option, Branch.un [03:14] , Branch.unlock, Branch.lock_write, Branch.last_revision_info, Branch.set_last_revision_info, Branch.unlock, Branch.lock_write, [03:14] Branch.set_parent_location, Branch.unlock, Branch.get_stacked_on_url] [03:14] Nice. [03:14] spiv: or more, do you see what *isn't* there [03:14] No vfs aside from two mkdirs. [03:14] yup [03:14] I'm going to drive this to vfs-free today I think [03:14] Which, presumably, is doing the ensure_prefix or makedirs or whatever we call it. [03:14] yes [03:15] patch to get to what I pasted there is up for review now === timchen1` is now known as nasloc__ [04:02] * igc lunch [05:34] lifeless: google ads tell me "registry fixes are a rip off" [05:34] :) [05:34] heh [05:34] have you tried ec2 test or parallel testing yet? [05:42] nup [05:43] i think it was not merged when i left and i haven't run tests since i've been back [05:43] * lifeless encourages [05:47] spiv: I think we're sending too much data still [06:10] hmph, no python 2.6.2 dmg installer [06:24] spiv: look in bzrlib.tests.lock_helpers for __dict__ for some special code [06:38] igc, when you say "6 seconds to branch emacs" i'm presuming that's without building a tree [06:40] lifeless: hi, we may be getting disconnected regarding registries [06:41] it seems to me like centralizing them may be best i guess [06:41] call? [06:43] poolie: I don't really like centralising as an option, even though I raised it; because its hostile to plugins amongst other things [06:43] I'm searching for a single root cause fix. [06:47] i'd kind of rather not have a call, at least today [06:47] k [06:48] vila: ec2test broken again for knownfailure... this thing is cursed [06:48] spiv: poolie: I'd like a review for the patch I'm sending right now [06:48] it passes everything, finally [06:49] [sent] [06:51] poolie: no - that's 6 seconds *including* the tree build [06:51] igc: shared repo yes? [06:51] wow, so that makes the multiplier even more extreme [06:51] lifeless: yes [06:52] lifeless: and an existing tree already built for the trunk/mirror branch [06:58] poolie: so, registries. defer till we're face to face? [06:58] unless it's blocking you severely [06:58] i want to reply to igc and then get out of mail etc [06:59] its not blocking me [06:59] the review I asked or is much more urgent :) [07:02] hi all [07:02] lifeless: :) [07:03] it may be an old branch of bzr.dev, but I don't htink so :( [07:06] Going to be using bzr on win32 over the next 18 weeks. Windows dev wanna see how this tool I rave about works on their platform (I work linux and osx side of things normally) [07:06] BasicOSX: good luck! [07:07] I tend to need luck when I work on a windows box [07:14] * vila sends more luck to BasicOSX [07:14] 'the luck is in the mail' [07:15] cool, brisbane can serialize luck now? === thekorn_ is now known as thekorn [08:08] bah [08:08] provenance, not providence [08:08] need dinner [08:08] * lifeless shuts down ec2 [08:15] poolie: I'm done for the day [08:16] ok, good night [08:16] modulo one last email I'm drafting [08:16] i need to do some personal sysadmin stuff so will sign off in a bit to do that [09:36] me dinner [10:48] nice [10:49] new estimated import time for ooo.org: 4 hours [10:55] wow [10:55] * bob2 remebers when it was a trillion years [10:56] I'm sure the git folks have never been able to achieve speed improvements of that factor :-P [10:57] thumper: so that thread I was tugging on has been pulled - 1.15 <-> 1.15 will do 23 roundtrips (down from over 40) to push a new stacked branch [10:57] jelmer: what did you chnage [10:58] lifeless: various speed improvements to bzr-svn over the last couple of months, and --development6-rich-root [10:59] its always nice when a basic-analysis + design + turns out well ;) [11:02] lifeless: I think this has worked out really well [11:08] lifeless: what's the next hot topic? [11:08] subtrees? parallel imports? [11:08] network [11:08] and working area ease of use [11:08] ah [11:08] * jelmer mutters something about colocated branches [11:08] I'd like to do file copy support too but thats lower return and higher investment [11:09] lifeless: file copy as in file copy tracking or merge using that tracking as well, etc? [11:09] lifeless: ISTM file copy tracking and the mode bit stuff we talked about yesterday could well be collated [11:10] jelmer: I don't think they are that separated;) [11:37] lifeless, thank you thank you thank you [11:38] I hate git so much with a passion [11:38] It is so horrible [11:38] I don't know how I could live without bzr [11:39] * pygi shoots cody-somerville [11:41] Do I merge --squash or do I rebase? Do I patch-format or do I diff? Do I checkout, clone, or branch? To see changes in the working tree, what options must I pass to diff? -- git is confusing. [11:42] cody-somerville, once you get accustomed to it, no its not [11:42] and it has books to cover it up [11:42] free ones even [11:42] bzr just works the way one expects [11:42] thats what I like about it [11:45] with git i know what git is doing. with bzr i just hope it does what i want. [11:46] each DVCS have its use-cases, and their pros and cons [11:47] yep :) i still use bzr for committing to svn, i never liked the git svn support [11:48] I like git submodules for example ... and since a lot of projects use git, I use it too [11:48] I'm still not sure of nested branches support in bzr (and if they are in fact supposed to be something like svn:externals && submodules) [11:48] * Kinnison uses git when forced to [11:50] pygi: subtrees are landing at the moment [11:51] jelmer, oh? Bzr.dev then? 1.15 release? [11:51] pygi: they're similar to svn:externals and submodules [11:51] cody-somerville: :) [11:51] pygi: when complete they should be similar to gits subprojects [11:51] pygi: it's always hard to say, but I would guess 1.15 (Aaron has submitted nested trees for review, and review is happening atm) [11:51] not 1.15 [11:52] lifeless: oh, ok - why not? [11:52] there are performance implications and design decisions to finalise [11:52] it will be a 2.0 feature [11:54] lifeless, will that happen this year? [11:54] lifeless: when would 2.0 be due? [12:02] jelmer: when development6-rich-root has evolved to production ready [12:02] 2-3 months probably, maybe less [12:04] lifeless, weren't git subprojects a "weaker" form of today's submodules? [12:05] pygi: dunno [12:06] hhhhm [12:06] stbuehler, you know perhaps? :) [12:07] i did not use submodules myself yet, i only have to deal with them for debian cgit packaging [12:07] pygi: depends on what you mean by weak [12:08] pygi: they're less integrated into the core commands than the bzr subtrees afaiu [12:17] jelmer, right... [14:08] files named *.~1~ and *.~2~ -- bzr debris? [14:09] mgedmin: hi [14:09] mgedmin: yeah, bzr revert creates those files [14:09] hi, jelmer [14:09] ah, revert [14:09] mgedmin: you can use --no-backups to prevent it from creating those files [14:10] use case: user cd's to a project working dir, types bzr st to make sure it's clean, types ls to look around and is scared by files named *.~1~ [14:10] I honestly thought there was a failed merge with conflicts or something [14:10] but then remembered bzr uses .THIS and .THAT or something like that [14:10] a lot of editors also use files ending in ~ to indicate backups [14:10] ... I don't remember running bzr revert on at least some of those files [14:11] vim doesn't [14:11] mgedmin: if you "set backup" it will [14:11] "sample-graph.png.~1~" -- I'm pretty sure I didn't edit it with a *text* editor [14:11] oh, right -- this thing (lp:objgraph) was created by the setup.py script [14:11] I might've run bzr revert on it [14:12] * mgedmin looks at his sentence and wonders if it can be understood by anyone else [14:13] there's a project (lp:objgraph) with a README.txt that generates graphviz graphs and wants to include sample images [14:13] so the setup.py has a couple of lines to extract the doctests from the README and pipe the output through dot to produce pngs [14:13] ... iirc [14:14] it's a bit of a hack, really [14:15] I must've run it several times (to produce new images), which overwrote some of the original images, which bzr probably noticed (png has creation time as metadata inside?) and I reverted [14:15] mgedmin: have a look at 'bzr help clean-tree', experiment with bzr clean-tree --dry-run [14:19] thanks [14:23] so, I've some code in my working tree I want to check in and push to a new branch on launchpad without touching the old branch [14:23] what should I do? [14:23] in git/svn I'd create a new branch, switch in-place, then commit [14:24] is there way to remove branch/project from launchpad? i would like to use lp for converting CVS into bzr [14:36] is it just me that finds the last shelve question defaulting to "No" really odd? [14:36] and also infuriating at times? :-) [14:37] james_w: no, it's not just you [14:37] I tend to want to shelve just one piece of code often [14:37] so I press "n" until I get there, then press y a couple of times [14:37] and then enter my way until the end [14:37] but often I hit enter one time too much [14:39] yeah [14:39] it's not a destructive operation [14:39] at least not with --destroy [15:24] how do I make bzr forget the last push location? ie. make bzr status not show a push branch? [15:25] * mgedmin is about to edit .bzr/branch/branch.conf with trepidation, there's a scary "do not touch anything here" notice in .bzr/README [15:28] mgedmin: you can use 'push --remember ' to replace the existing one but you can't *clear* the existing one [15:29] * mgedmin dislikes [15:29] can you remember '.'? [15:30] interesting question [15:31] * Tak master of hackish workarounds [15:32] yes you can [15:32] "no new revisions to push" [15:43] hey, my bzr ci --fixes lp:NNN appears to have silently ignored the '--fixes lp:NNN' bit, what gives? [15:44] mgedmin, no, it's stored as meta-data [15:44] not sure how you can see it with the bzr client [15:44] but if you push to Launchpad [15:44] you'll see Launchpad will link that bug with that branch [15:45] oh, user error: bzr ci --fixes; look at list of files; abort; bzr revert file1 file2; bzr ci [15:47] mgedmin: oops! [15:47] :) [15:48] huh, I didn't know about the --fixes flag. that's cool. [15:48] yeah, well, I still blame bzr :) === Tak|work is now known as Tak [16:01] does anyone know how to use bzr-gtk? I have it installed but no clue how to "use" it === glen__ is now known as billybob === billybob is now known as fizzy === fizzy is now known as fizzyone [16:03] hello [16:03] fizzyone, run: bzr-gtk [16:03] in your terminal [16:03] that is what I thought [16:03] not changing your nickname every 3 seconds might work better if you want an answer [16:03] in the directory where you have a branch [16:03] no command found [16:03] fizzyone, actually, ignore that [16:03] you should have new commands in bzr [16:03] sorry about that... just wrestling with the client [16:03] bzr viz is one of the commands provided [16:03] "bzr help" [16:04] I've never used any of the others (assuming there are some, which there probably are) [16:05] you've also got gcommit [16:05] again, 'bzr help commands' should say [16:05] awesome thanks [16:05] I have the gui up now [16:05] all the g* stuff is bzr-gtk [16:10] launchpad rules [16:11] it does! === trmanco_ is now known as trmanco [17:51] vila: ping [17:54] Hi, while commiting to a svn server I get "bzr: ERROR: Please upgrade your Subversion client libraries to 1.5 or higher to be able to commit with Subversion mapping v4", although I do have libsvn 1.5.1 [17:56] jelmer: pong (not really there so except high lag:) [17:56] s/except/expect/ [17:58] marcoil: you have 1.5.1 locally ? [17:58] marcoil: is subvertpy linked against 1.5.1? [17:58] vila: I'm trying to think of a way to avoid that 401 on POST [17:59] jelmer: libsvn1 1.5.1dfsg1-1ubuntu2 [18:00] jelmer: how do I check what's subvertpy linked against? [18:01] jelmer: in any case, it's the one in the bzr ppa for hardy [18:05] marcoil: what is the server running? [18:06] jelmer: 1.4, I'm afraid [18:07] marcoil: hmm [18:07] marcoil: that might have something to do with it [18:08] jelmer: it did work last week, I'm sure of it, but I'm not sure which packages I've updated since [18:09] jelmer: hmm, 401 should be ConnectionError, I don't they are yet. From there.... ConnectionErrors may/should (need to be discussed ?) be translated into NotAbranch errors during probes... or something like that, but that should still allow prompting user :) [18:11] marcoil: no idea which things are out of date, sorry :-/ [18:11] marcoil: it does work, but you probably need to upgrade some of the packages on your client machine [18:11] vila: so we'd have to do two passes or something like that? [18:11] jelmer: I'm trying to compile subvertpy, let's see if that works [18:13] jelmer: I didn't look closely at the code since that mail thread, I'm not sure doing two passes (one without auth one with) is the way to go (ISTR that we probe recursively until root for some cases, so we already have a two-dimensions probe...) [18:15] jelmer: manually compiling and installing subvertpy 0.6.5 did the trick! thanks [18:16] marcoil: np [18:16] jelmer: may be the solution is to change or allows changes to the probe mechanism, I'm not that sure we can address all the funny ways an http server can be configured.... [18:17] vila: yeah, that's what I'm worried about too [18:17] vila: the quick solution for now is to probe for svn repositories before bzr repositories [18:18] I thought the quickest was to use nosmart+ :-) [18:19] vila: nosmart doesn't work, though svn+http does [18:19] jelmer: ? You got POST with nosmart+ ??? [18:20] that's a bug in nosmart then [18:20] vila: no, nosmart doesn't trigger svn [18:20] that's a bug too ! [18:21] it would even be wrong if that worked since svn is a smart server protocol too ;-) [18:22] jelmer: ha come on :-) Anyway dinner time here, I may come back later, but I think what we need is a better control of what probe does, being auto should remain the default, but having some way to tweak it by remote server will be needed in the end (whatever the smarts we put in the auto mode) [18:32] jelmer: ... and nosmart+ and svn+http are just two examples of why this is needed... [18:45] vila: re [18:45] vila: yeah, we do indeed need better control of probe [18:45] vila: also, for svn it's only necessary to probe the bottom-layer [18:46] vila: if /foo/bar/bloe/bloe is not a svn smart server then even if we can open /foo/bar/ it won't be a valid path [18:52] :q [18:59] jelmer: violent agreement I see :) [19:01] Hey jelmer [19:01] I'm having trouble using bzr-hg. [19:01] I have hg branch here, that I can do "hg st" in. [19:02] And I have trunk bzr-hg from launchpad with bzr 1.13.1 from jaunty. [19:03] But the branch directory (that contains the .hg directory) is not recognized by bzr as a branch. [19:03] (In case jelmer is unavailable at the time, anybody with a clue is welcome to help, too) [19:04] ddaa: hi [19:06] hi jelmer [19:06] I'm afraid I'm not going to be able to follow up on the test for bzr-svn. I have just quit that job at the bank. [19:07] Any suggestion how to debug that problem with bzr-hg? [19:08] I have a special hate for branch detection problems, they provide no feedback at all besides "NotABranch, get stuffed". [19:08] s/NotABranch/NotBranchError/ [19:08] ddaa: pushed a fix [19:09] ddaa: yeah, the probe stuff could use some improvement [19:09] ddaa: was just talking about that with vila :-) [19:09] Did you push on bzr+ssh://bazaar.launchpad.net/~bzr/bzr-hg/trunk/ ? [19:11] Because the last commit I see there is "merge new bzr-foreign" date Sun 2009-03-22 00:33:57 +0100. [19:11] ah, no - pushed to my private repo [19:11] pushing to lp now [19:11] done [19:11] please be aware that bzr-hg is still highly experimental, moreso than bzr-svn or bzr-git :-) [19:13] * jelmer dinner [19:13] When *I* was a kid, bzr was highly experimental ;( [19:13] I mean ;) [19:14] I just have a one-time import to do. [19:14] Gotta go offline. [19:14] BBL [19:47]