[00:01] New bug: #111826 in bzr-gtk "Broken menu items in nautilus integration " [Low,Fix committed] https://launchpad.net/bugs/111826 [00:01] New bug: #149061 in bzr-gtk "Cannot view diff of first revision" [Medium,Fix committed] https://launchpad.net/bugs/149061 [00:28] PenguinOfDoom: bzr branch lp:~subol-hackers/subol/shared.dev [00:28] oops, mischan [00:36] hi radix! [00:37] yo poolie :-) [00:42] Heya radix! [00:42] wow, it's a party [00:42] Hi RAOF :) [00:42] :) [00:43] lifeless: what are your thoughts on rich-root-pack conversion bugs and 1.3? [00:44] * Odd_Bloke pumps out the beats. [00:47] * TFKyle pumps out the beasts [00:49] * j1mc jumps to the pumped out beats [00:49] (aka. party-goers) [00:59] poolie: 1.3 is time based, I don't think those things are related [01:00] poolie: as the conversion issues are not regressions [01:01] lifeless: just wanted to say thank you for your explanations yesterday. you were very helpful. the history is now correct, and i've used bzr bind to ensure i won't have the same problem again. [01:01] in other words go ahead without it [01:01] j1mc: cool [01:01] :) [01:01] poolie: yah === kiko is now known as kiko-zzz === mw is now known as mw|out [01:09] poolie: what do you think [01:10] it does seem to have been present for a while [01:13] bbiab food ftw [01:37] squid folk are liking bzr fwiw [01:37] need to do some tweaks to bb for them [01:37] use the right bugtracker [01:37] and allow anonymous email voting [03:00] anybody have a sec to help me w/ an rspush error i'm getting? [03:00] sure [03:01] lifeless: 504 colossus$~/Sites/apartmentlines.com/www: bzr rspush watchdog:bzr/apartmentlines.com [03:01] bzr: ERROR: Rsync could not use the specified location. Please ensure that "watchdog:bzr/apartmentlines.com/" is of the form "machine:/path" [03:01] lifeless: if i run scp foo watchdog:bzr/apartmentlines.com [03:01] lifeless: works perfectly [03:02] lifeless: so i'm a bit confused what the issue is [03:02] hmm [03:02] hunmonk: The path you're giving isn't absolute, which the error message would suggest is required. [03:03] well spotted [03:03] Odd_Bloke: full path doens't work, either [03:03] also, are you aware of push-and-update ? its a plugin [03:03] I would look in .bzr.log and see if anyting interesting is there [03:03] also perhaps try strace and snarf the actual rsync command line being tried [03:06] lifeless: where is .bzr.log? [03:06] home dir? [03:06] * hunmonk looks [03:06] yup [03:12] lifeless: http://pastebin.ca/949874 [03:14] rsync is erroring [03:14] strace is your friend [03:15] lifeless: lol. no strace on my mac [03:15] lifeless: guess it's time to hit fink... [03:15] truss perhaps ? [03:15] nope [03:16] got to me some equivalent [03:16] dtrace11 [03:16] anyhow, rsync is existing with status 12 [03:17] lifeless: doesn't scp use rsync as well? [03:17] no, scp is like cat over ssh [03:17] hunmonk: no [03:17] oh [03:17] 'ktrace' [03:17] i think [03:18] I'd expect rsync is spitting an error somewhere. Try just running it manually. [03:18] fullermd: yeah, that was my next thought as well [03:20] lifeless: rsync error: error in rsync protocol data stream (code 12) at /SourceCache/rsync/rsync-30/rsync/io.c(359) [03:20] lifeless: i've never seen that before :| [03:21] Why, of course! You forget to giblinetch the huntra in the config file. Duh [03:21] could any of your login scripts on the remote machine be printing something out? [03:22] bob2: maybe [03:27] lol [03:27] lifeless: found the problem [03:27] lifeless: no rsync installed on destination server :) [03:41] lifeless: Do you want to preserve the code style differences between the loom plugin and bazaar? [03:47] I sense some restrained frustration there :) [04:04] poolie: how's the release going? [04:06] poolie: also, where's the branch for it? [04:07] abentley: which ones? [04:07] The imports are the main thing I'm noticing. [04:08] jml, http://bazaar-vcs.org/bzr/bzr.1.3 [04:08] In bazaar proper, we hardly ever do "import bzrlib.merge", for example. [04:08] It would be "from bzrlib import merge as _mod_merge" [04:08] abentley: oh, its because loom is old code [04:09] Or possibly a direct object import. [04:09] abentley: it was written in the same style as bzr of the time [04:09] * jml registers [04:09] By which I take it it's fine to use current Bazaar style in it? [04:09] totally [04:09] Cool. [04:11] I'm running into a test case failure because we can't represent a tree whose last_revision is NULL_REVISION that has pending merges. I think I'm going to drop it, but we should really fix that in Bazaar. [04:16] uhm [04:16] whats the reason for it ? [04:16] like is it an existing test [04:16] or a new one, and if new whats the use case? [04:17] No, I'm writing a new test, and I got an unexpected error. [04:17] I'm doing up_thread(); up_thread() [04:17] The second up_thread raises cannot switch threads with anout of date tree. Please run bzr update. [04:18] The underlying cause is that when last_revision is NULL_REVISION, tree.get_parents() is [] [04:19] So adding a pending merge sets the lefthand parent. [04:20] right, thats currently by design [04:20] its consistent with our history storage too [04:22] Well, intentional or not, it's a limitation on what Bazaar can do, and it's occasionally reported as a bug. [04:23] so I'm guessing your use case looks like [04:23] And in this case, it's causing looms to give an error that doesn't make a lot of sense. [04:23] loomify, create-thread, down-thread, commit, up-thread [04:23] And then up-thread again. [04:23] I would say in this case that up-thread leaving the new-thread the same as the bottom thread is actually fine [04:24] So you're saying that if up-thread changes the last_revision, it should change it on the branch also? [04:24] uhm [04:24] The bottom thread has a new revision. [04:24] Call it X [04:25] bzr up-thread will set X as the tree's last revision, but will set the branch's last_revision to NULL_REVISION [04:26] You are saying it should set the branch's last_revision to X as well? [04:27] I think it should set X as the threads last revision in this specific case; which will change the branch's last-revision as teh branch is just reflecting the thread state. [04:31] lifeless: What mechanism sets a thread's last revision? All I see being set is the branch and tree. [04:33] set_threads & _set_last_loom [04:36] see for instance LoomSupport.record_thread [04:36] thats the api you probably want to use here [04:45] lifeless: up_thread is currently doing Branch.generate_revision_history. Swapping Branch.record_thread in breaks things horribly [04:47] I'll leave it generating revision history, and update it so it sets it to X when appropriate. [04:50] abentley: you need both [04:50] abentley: here's why. [04:51] there is some duplicate data in the current loom branches, because of lazy-robert. [04:51] the duplicate data is the current branch tip in .bzr/branch/last-revision, and the current thread version of the same data in .bzr/branch/current-loom[branch.nick] [04:52] up-thread is normally just setting the last-revision to match the thread, but now it has to (sometimes) update the thread too [04:52] But hardly anything updates the thread copy, right? [04:52] Why isn't that calamitous? [04:55] abentley: with a last-loom format update to record the revno in each thread, we could drop last-revision from disk and remove the duplication [04:56] abentley: its not alamitous because looms hook in very lightly, and try to preserve regular branch behaviour as much as possible. [04:56] But commit doesn't update the thread copy, so why should up-thread update the thread copy? [05:01] commit updates it [05:01] now I need to remember how [05:02] or if it doesn't then thats an interesting bug [05:02] I was just assuming that the behavior was lazy enough that it didn't matter. [05:04] unlock does it [05:04] read the unlock code [05:04] so yes, you can be lazy here. [05:04] and just set branch.last_revision [05:04] as long as you'll be on the right thread when the branch is unlocked [05:05] * poolie starts 1.3 packaging [05:09] lifeless, abentley: any opinions on my mail about testing for unreleased locks? [05:12] As long as we do it, I don't care how. [05:13] i think i will keep a list of held locks [05:13] which is essentially what we're getting python to do for us, but in a flaky way [05:13] poolie: did we not plan this at allhands? [05:13] poolie: I thought the plan was to - provide a global event anyone can subscribe to which fires on lock and unlock [05:13] it rings a bell, i can't recall what was decided though? i think we said what i just said [05:14] poolie: then add to the root TestCase a subscriber to that which accumulates lock/unlock events. And finally an addCleanup that asserts they are all matched. [05:14] this is better than a global list of locks [05:15] k [05:17] its better because we can then write tests that test the number of locks actually taken/released by a command [05:17] and things like that [05:17] right, that sounds good [05:18] it also doesn't depend on gc() having been run before the test finishes, or no-loops, and other such implementation details [05:18] sure [05:18] it's a strict superset [05:19] of what i was proposing [05:19] i'll send a patch for it [05:19] sweet [05:20] stab stab stab get_revision_graph [05:20] "that, and a pair of testicles" [05:20] makes me smile every time i make a release [05:20] vale jdub [05:26] welcome back tim [05:32] it turns out jam's renvo code has some bugs. [05:35] At least it doesn't have a pair of testicles. [05:42] who knows [05:42] hno in squid called bb bundlebunny the other day [05:42] hehe. [05:51] jml: I'm struggling to get ``bzr merged-branches`` working at all. If I have a 'bzr' directory with 'bzr.dev' and my topic branches under it, how can I get it to tell me which of those topic branches have been merged? [05:53] that wasn't supported according to the release announcement [05:54] k, time to call it a week. [05:54] shee you folk tuesday; except for poolie of course :) [05:54] don't od on eggs [05:55] bob2: Right, but I can't work out what _was_ supported. [05:55] bob2: *blink* [05:55] lifeless: Happy Easter! [05:56] Odd_Bloke: ~/repository/bazaar/bzr/{trunk,fix-bug-41921921,make-foo-baz}, afaict [05:56] hello bob, odd [05:56] bob2: Right, so I have a symlink from trunk to bzr.dev now, but am still getting odd errors. [05:57] Odd_Bloke: ah, sorry, I imagined a comma (with 'bzr.dev', and my topic branches under it) [06:03] lifeless: Okay, I've merged in the up-thread stuff. Shall I do export-loom (with no default) too? [06:09] abentley: yes please; please be sure to do a merge into the trunk, or use a bound branch - I'd like the mainline to be like bzr's with only the result of feature branches, now that loom is released [06:09] gack [06:09] lifeless: Sure, I understand. [06:10] To be safe, you should set append_revisions_only [06:10] how do I do that [06:10] is there an api call? [06:10] also, append_revisions_only doesn't enforce all that I want ;) [06:10] bug 202778 killed my 1.3 merge [06:10] Launchpad bug 202778 in bzr "false test failure when run in a directory containing the version name" [High,Confirmed] https://launchpad.net/bugs/202778 [06:10] oh well [06:10] lifeless: Branch.set_append_revisions_only [06:11] it only prevents pivots; it doesn't prevent push as opposed to merge + commit [06:11] Oh. Perhaps that's another flag we should support. [06:12] Branch.set_commit_only_merges ? [06:13] abentley: something like that would represent want I want yes [06:13] abentley: but anyhoo I'm off [06:13] * lifeless waves [06:13] Happy bunny time. [06:14] Anyone have luck getting the eclipse plugin up? The updates site has no files according to eclipse? [06:15] i'm going to trivial in http://pastebin.ubuntu.com/5915/ [06:16] r=abentley [06:16] thanks [06:19] I think that could give a false success, though. [06:19] that's true though [06:19] If there was a file, but the version number was wrong. [06:19] particularly on the directory name [06:19] exactly [06:19] maybe i should check it's in the first line [06:20] or indeed the exact format of the first line [06:20] hm [06:21] Either one sounds good. I lean towards the second. [06:21] good point, thanks [06:21] are you in an unusual timezone or sleep pattern? [06:28] http://pastebin.ubuntu.com/5916/ instead then [06:29] The comment seems superfluous now. [06:30] you're right, thanks [06:34] poolie: sleep pattern. [06:56] jml: I've done some work on the merged-branches plugin that's at https://code.launchpad.net/~daniel-thewatkins/+junk/merged-branches [06:57] It now takes a target branch and a directory (which defaults to '.'), uses a transport and has some better user feedback. [07:18] Odd_Bloke: thanks. [07:18] * jml looks [07:22] jml: I'm writing some tests ATM. :) [07:23] Odd_Bloke: thanks! [07:24] ok i'm done, good nightall [07:24] jml, 1.3 is out [07:24] poolie: thanks- [07:24] jml, the tarball is up but the merge has not completed yet [07:24] :/ [07:25] poolie: no worries [07:25] poolie: I'll probably submit it tomorrow anyway [07:25] poolie: Congrats! :) [07:25] oh one more thing [07:25] yes? === poolie changed the topic of #bzr to: http://bazaar-vcs.org/ | Bazaar 1.3 is out 20 Mar | http://launchpad.net/bzr/1.3/1.3 [07:25] that. [07:26] cheers [07:26] heh heh [07:26] actually i'm going to visit Oksh briefly [07:26] see you === RichardL_ is now known as rml [07:30] jml: Some rudimentary tests have been pushed. === thekorn_ is now known as thekorn [10:43] * awilkins yawns [10:43] Dammit, 0400 hackathons do not suit me in my old age [11:56] New bug: #204211 in bzr-svn (universe) "Displays a version warning on every operation" [Undecided,New] https://launchpad.net/bugs/204211 === kiko-zzz is now known as kiko [12:52] mmmh, is there a way to use bzr-svn without the breakalot rich-root-format? or convert rich-root into pack-92 or something? [12:53] nekohayo: no, bzr-svn needs rich-root. what's your problem with it? [12:54] well, the fact that it seems to break :) https://bugs.launchpad.net/bzr/+bug/177874 [12:54] Launchpad bug 177874 in bzr "upgrading to rich-root-pack fails" [Medium,Confirmed] [12:55] so I was wondering if there was a way around it [12:56] more precisely I am the one who reported https://bugs.launchpad.net/bzr/+bug/202884 [12:56] Launchpad bug 202884 in bzr "can't merge (dup-of: 177874)" [Undecided,New] [12:56] Launchpad bug 177874 in bzr "upgrading to rich-root-pack fails" [Medium,Confirmed] [13:33] nekohayo: There are some problems with upgrading to it. I'm not aware of any problems for branches that are already in it. [13:34] abentley: well merging dirstate into rich-root fails [13:34] why is the description of a command in the output of "bzr help" indented to column 19 (starting with 1)?? shouldnt that be 20 ?? [13:35] http://en.wikipedia.org/wiki/Off-by-one_error ?? [13:35] nekohayo: Are you talking about the general case, or about the Bazaar source tree? [13:35] what do you mean? [13:35] The Bazaar source tree has some weirdness in it that is going to require extra care to upgrade. === mrevell is now known as mrevell-lunch [13:36] The bug you referenced is an upgrade of the source tree to Bazaar itself. [13:37] Now you're talking about merge of dirstate failing. [13:37] But I don't know if you're talking about the Bazaar source base in particular, or some other source base. [13:37] abentley: yeah, my bug is #202884, but it was marked a duplicate [13:40] nekohayo: Is this a really old branch? [13:41] abentley: the one in rich-root is a freshly made one from svn, and the other one is dating back from the summer I think [13:44] So the revision in the example is from 2007-05-17. At that time, we supported unique root ids in our development version, for a while. I don't believe it was in any released version. [13:45] abentley: that is what makes things break? [13:45] any way to have bzr convert that? [13:45] That's what's been diagnosed so far. [13:45] I haven't looked at your particular branch. [13:46] Though I was going to. [13:46] To answer your original question, rich-root is mandatory for bzr-svn. It was created especially for bzr-svn. [13:47] aah, that explains. the fact that there are multiple formats kind of puzzled me [13:49] nekohayo: I have inspected your branch, and it does have a unique id for the tree root. So it's the same *root* cause :-) [13:49] what is that unique id thing? [13:50] isn't an "ID" unique by definition ?_? [13:51] In pre-2007 trees, the root directory always has an ID of "TREE_ROOT" [13:51] Trees created in the rich-root format always have unique IDs. [13:53] We're working on making a rich-root format the default. It will be a slight tweak of rich-root-pack. [13:58] abentley: so can this be converted or salvaged without using the method "create a giant patch and lose history"? [14:02] We haven't yet got a solid patch that fixes it. You might be able to re-generate the history using rebase. [14:03] This would preserve metadata such as your comments, but would generate new revision-ids. [14:03] oh, but once such a patch comes in bzr, it should heal itself ? [14:04] Yes, we'll support that conversion one way or another. === mrevell-lunch is now known as mrevell === ja1 is now known as jam_ === jam_ is now known as ja1 === ja1 is now known as jam === mw|out is now known as mw [15:26] New bug: #125751 in bzr-svn "Push raises exception about invalid property changes" [Medium,Fix released] https://launchpad.net/bugs/125751 [15:40] Which repository format has the best performance (or will be the new standard in future releases)? I will be the only developer using the repo so I'm not concerned about backwards compatibility. [15:43] lnxtech: the current default, pack-0.92 [15:45] thanks === kiko is now known as kiko-afk [16:41] hi [16:42] poolie: i don't see any ops in this channel, i suspect announcer is still banned. i've fixed it now, know what I should do to get the ban lifted? [16:45] * jdong taps jelmer's shoulder... [16:45] bzr co on bzr-svn doesn't exactly create a "bound branch" , does it? [16:46] New bug: #204320 in bzr ""bzr patch" internal error" [Undecided,New] https://launchpad.net/bugs/204320 [16:46] I tried a bzr co svn+file:///some/svn/repo on system foo, then on bar I did bzr co sftp://foo/bzr/checkout [16:46] then when on bar I tried to ci, I got some sort of svn assertion error [16:47] then I checked bzr info and apparently everything was some sort of svn format, not standard rich-root-pack bzr branches [16:53] staik: The ops don't usually fly their flag. Hmm, how do I get ops again? [16:53] /msg ChanServ op #bzr abentley [16:53] I think [16:54] abentley: well /op user is used to give ops to 'user', but I think you have to be op first :) [16:55] Anyone know the syntax for listing/altering bans? [16:58] help /op [16:58] abentley: looking at plain help, I only see /kick, and no /ban [16:58] I think it's a mode you set on a wildcard. [16:58] abentley: then '/help mode' [16:59] something like /mode +b *announcer* [16:59] So /mode -b nick [16:59] something like that [17:00] /mode -b *!*announce@* [17:00] is there any chance to check out a svn repository with bzr via https? [17:01] it seems to fail, while svn works [17:02] i tried bzr svn-import https://subversion..... as well as bzr co [17:02] it responds with 401 Auth required [17:03] stammi: try svn+https://... [17:04] statik: How you like it now? [17:05] /mode -b *!announce@165.198.204.68.cfl.res.rr.com [17:05] ;) [17:05] it says "No Repository found at ... use bzr branch" if i do so there comes a legthy error which essentially says SubversionException: ("Undefined tunnel scheme 'https'" [17:05] abentley, after that there is no bans [17:05] abentley: thank you, we should see it work when the next PQM commit mail comes through [17:06] statik: shouldn't it join the channel first? [17:06] or will it auto-join by then? [17:06] dato: it is supposed to auto-join when it has something to announce [17:06] ok [17:06] statik: Okay, holler if it doesn't work. [17:07] * stammi just recently noticesd to be out of vcs for the next two weeks [17:07] but, I don't really have a good way to see the response from the IRC server to the IRC-talking part of the bot, I'm just re-using radix's publish-bot [17:07] abentley: thanks for the help [17:17] hi, is it possible to import tags from svn? [17:24] j^: yes, but only as branches not as bzr tags yet [17:25] stammi: Looks like your subversion library wasn't built with http support [17:26] jdong: still there? [17:27] jelmer: yeppers [17:27] jdong: you can't make a checkout of a checkout in bzr [17:27] jelmer, i was hoping for bzr tags, getting the revision numbers and creating the tags should not be to hard [17:27] jelmer: oh. [17:27] (which if I understand correctly, is what you're trying to do) [17:27] jelmer: I didn't know that :) well that explains a lot [17:27] jelmer, have ubuntu 7.10 and installed bzr-svn [17:28] and its https not http [17:28] stammi: the svn+https:// / svn+http:// syntax was broken in bzr-svn 0.4.1, which is what is in gutsy [17:28] jelmer, so i should just manually install bzr from the homepage? [17:28] there is a newer version in guty-backports [17:29] ahh ok [17:32] thx jelmer [17:44] j^: it's not trivial since tags may be in different locations across svn repositories [17:46] true, is there a way to map svn revision to the one used in bzr, that way one could collect the revision numbers and run a script to apply the tags, right now i would have to look up the commit message, find the one in bzr and map the revision that way [17:47] j^: just taking the revision in which the tag was created in svn won't help [17:48] since that will be a revision that's not actually in your bzr branch [17:48] you would have to take the revision from which the tag was created [17:48] but that's not going to be correct in a lot of cases either, since the revision that created the tag could also have slightly modified it === thekorn_ is now known as thekorn === jw2328_ is now known as james_w [17:55] what could cause [17:55] SubversionException: ("PROPFIND request failed on '/!svn/bc/12853/trunk/foobar'", 175007) [17:57] does "svn log -r12853 " work? [17:59] ------------------------------------------------------------------------ [17:59] is all i get === lamont` is now known as lamont [18:03] j^: is this a public branch? [18:04] at that revision there is nothing in svn log, its one before the trunk was moved from a branch [18:04] https://svn.xiph.org/trunk/theora [18:30] statik: you should have a new pqm email [18:30] I just had a patch merged [18:31] jam: cool, i hope we see an announcement in a couple of minutes [18:40] Does anyone know what happened to the webserve plug-in? [18:41] grutte_pier: it's still going [18:43] So which url should i branch from then? on the webpage there is a 'download' link and an 'URL to branch' link [18:43] the former gets me an 500-error (Internal Error) [18:43] the latter gets me the source-code of some webpage [18:43] https://code.launchpad.net/~bzr/bzr-webserve/webserve-dev [18:45] thanks a lot! Is there a way that I could or should have found this link myself? [18:46] grutte_pier: I'm not sure, maybe we should contact the author to update his webpage. [18:46] Note that launchpad is just mirroring his branch, so I imagine that he has reorganised things at some point and not updated the webpage. [18:51] sounds like something that could easily happen..... [19:10] What's the reason that e.g. "bzr status" does not list the files relative to the current working directory, but to the branch root? [19:11] It's not as easy to select filenames for further actions then, e.g. by doubleclicking them. [19:12] Because there might be more files modified than just within cwd [19:13] So how do you display those? [19:14] LeoNerd: well, good point for commands on the branch, but with e.g. "bzr st ." there's a path given.. [19:14] otherwise they could get prepended with "../" anyway. [19:15] What's the recommened way to push a local bzr branch to a fresh (not yet existing) SVN url? [19:15] New bug: #204370 in bzr "bzr bombs during push to svn" [Undecided,New] https://launchpad.net/bugs/204370 [19:15] nice ubotu detected my bug report ;) [19:25] Hi, using bzr-svn I get "CHECKOUT of ...: authorization failed" when trying to push to the repository... [19:25] bzr-svn 0.4.7 [19:25] bzr 1.2.0 [19:25] What do I need to do? [19:25] svn has my credentials cached already. [19:25] I'm pushing over http [19:25] ahhh, the newest version of bzr-svn works for bzr 1.1 *weep* [19:26] yacc: but not for 1.2.0? [19:34] Well, the wiki page shows only versions for up to 1.1 ;( [19:38] Please anybody tell me that there is svn support for current bzr versions? [20:02] hm, is there people working primarily on bzr-gtk? [20:03] New bug: #151825 in bzr-gtk "jumping progressbars" [Undecided,New] https://launchpad.net/bugs/151825 [20:06] New bug: #125144 in bzr-gtk "Crashes when directory contains broken symlink" [Undecided,Confirmed] https://launchpad.net/bugs/125144 [20:09] nekohayo: yeah [20:11] ok, so I assume my pile of bugs (a few of them with patches) were not seen [20:11] so I'm changing them all to be assigned to bzr-gtk [20:24] fbond: ok, the branch seems to be maintained :) => but the current head seems to work only with bzr >= 1.3 ;) [20:32] It still bombs :( [20:40] Is it possible to import a single file into my repo? [20:41] Or do I have to import the containing directory like SVN? [20:54] awmcclain: any repo is a directory so logically speaking your question does not make much sense ;) [20:55] yacc: s/repo/branch [20:55] :P [20:55] Yeah, still your question makes no sense ;) [20:56] Is it possible to commit a single file which does not live under an existing branch into a branch. I'm pretty sure the answer is no. [20:57] Hrm. Can you check out or branch a subset of a working tree? [20:58] those are two different questions? [20:58] yes [20:58] ok [20:58] (b) you can't do partial checkouts [20:58] hrm [20:58] Okee doke. [20:58] (a) I'm failing to see your question, how's what you ask different to `bzr add $FILE` ? [20:59] dato: Becauase I'm guess bzr add $FILE will only work if the containing directory is in a working tree [20:59] I'm trying to collect a bunch of conf files scattered about into source control [21:00] well [21:00] the file has to be underneath the branch, of course [21:00] I'll just put them in a directory and then move from there [21:12] bzr: ERROR: Revision {('andreas@andi-lap-20080318110425-b4uvstmj62j90z2s',)} not present in "". [21:12] on upgrade --rich-root-pack [21:12] yacc: Known issue. [21:13] Yeah, but what do I do, considering that I should deliver my stuff today? === kiko-afk is now known as kiko [21:13] Trying to do a svn-push I'm getting an error too :( [21:14] yacc: I don't know of a solution. [21:14] Well, I can try to revert to bzr 1.1, and see if that helps, ... [21:15] I dunno. [21:20] abentley, ping? [21:20] kiko: pong [21:20] abentley, do you have any advice for yacc's problem above? [21:22] At this point, we don't have a fix for that. [21:22] abentley, what's the source of the problem? [21:23] abentley: basically bzr svn-push craps out with the "SubversionException: ('At least one property change failed; repository is unchanged', 175008)" problem ;( [21:23] * yacc had such high hopes to have escaped svk, ... [21:24] Wait, which is your bug? SubversionException or Revision not present? [21:25] abentley: SubversionException. README in bzr-svn (I think, might been google) suggested that an upgrade --rich-root-pack might be useful, ... [21:26] Which version of bzr-svn have you been using? [21:26] head of stable with bzr 1.3 [21:26] Now I'm downgrading to bzr 1.1rc1 in Debian, that include bzr-svn 0.4.7 I think. [21:27] Well, bzr1.1 gives me the "at least one property changed" traceback too :( [21:28] bzr plugins should tell you the version number [21:28] 0.4.7 [21:28] and bzr 1.1 [21:28] Same error as it was with bzr 1.3/stable-head [21:29] So "stable-head" doesn't help me understand what's going on. [21:29] There was a major change at 0.4, and if you're using something earlier, the scenario is completely different. [21:29] stable head == an hour old pull from the branchurl on the plugins wiki page. [21:30] No it's the newest one. [21:31] yacc: trunk, or the bzr-0.4 branch? [21:31] http://people.samba.org/bzr/jelmer/bzr-svn/stable/ [21:32] Okay, so if you do bzr info -v in your branch, what does it say about formats? [21:32] dato: no idea which branch is stored at that url. [21:32] you mean the one that I try to push to svn? [21:32] yacc: yes [21:32] control: Meta directory format 1 [21:33] working tree: Working tree format 4 [21:33] branch: Branch format 6 [21:33] repository: Packs containing knits without subtree support [21:33] So is this a branch that you originated in Bazaar? [21:33] Yes, it orginated from a bzr init (with bzr 1.1rc1) [21:34] I wonder if it would help to push an empty bzr branch first to the SVN url, ... [21:35] any ideas how to get the stuff into svn? [21:36] Could you run this and tell me what the output is? [21:36] python -c 'from bzrlib.workingtree import WorkingTree; wt=WorkingTree.open("."); wt.lock_read(); print wt.inventory.root.file_id; wt.unlock()' [21:36] You need to run it in your working tree. [21:37] TREE_ROOT [21:38] Well, that's normal. I don't know why upgrade would be a problem. [21:39] I don't think you'll be able to push into svn until you change your format. [21:39] Well, it complains that a version does not exist where it expects it. but technically speaking the upgrade is less of an issue for me, bzr-svn is :( [21:39] To which format? [21:39] I would recomment rich-root-pack. [21:40] Well, rich-root-pack and rich-root both complain about non-existing versions, and it seems to be a known bug :( [21:41] abentley: fwiw pushing from !rich-root to svn works just fine. I use it in one of my projects. [21:41] dato: Ah, okay. It's been a while since I used bzr-svn. [21:41] Any hints that I can try? [21:42] We probably need Jelmer to debug the SubversionException. [21:43] jelmer: ping [21:43] It sounds like the upgrade's not necessary, and we're planning to fix it for branches like yours. [21:43] Which timezone jelmer is in? [21:44] CET [21:44] UTC+1 I think. [21:44] hi dato [21:44] yacc: One thing you could try is running "reconcile". [21:45] reconcile? [21:45] ie "bzr reconcile". [21:45] hi james_w. I meant to ask you the other day, were you in dc7? [21:45] dato: nope. [21:46] abentley: what does reconcile do? [21:46] ok. then no regrets I didn't meet you :-P [21:46] abentley: same SubversionError :( [21:46] dato: :-) [21:46] dato: are you going to dc8? [21:46] yacc: Running reconcile in your repository gives you a SubversionError? [21:47] no, but doing a svn+push after the reconcile. [21:47] the reconcile did fine. [21:47] bzr reconcile corrects some kinds of data inconsistency. [21:47] Whatever it did. [21:47] james_w: it's going to be a bit complicated, but so has been the previous 3 times and I always managed. but maybe I'm overconfident this time. :-) [21:47] Does the upgrade work? [21:47] abentley: but the upgrade to rich root pack did work :) [21:48] The question is if that will help the svn+push or not. [21:48] Nope, same thing as before. [21:49] I don't know enough about bzr-svn to understand that error. [21:50] I'm glad the upgrade worked, but you may want to go back. [21:51] It depends on whether you're expecting to pull/merge from bzr-svn. [21:52] Well, for the moment I'm the only one that will be commiting around that svn path ;) [21:52] I might try it out if pushing to my private svn repo works. [21:52] Probably you should stick with it. [21:53] Existing projects shouldn't convert to rich-root-pack unless all their members are willing to upgrade. [21:53] But yours is a new project, so it doesn't matter. [21:53] abentley: basically, I'm having a high level of aversion against svn, svk and git-svn, that doesn't leave many options when you need to work with a svn repo ;( [21:54] abentley: mine is a project where nobody but me will see the bzr branch, because all other will be pulling it from svn. [21:54] What's the command you're running? push or svn-push? [21:54] svn-push [21:54] push gives an IndexError. [21:55] Googling the error returns basically only the bzr-svn problems and one old svn error which was fixed back then by upgrading the svn client version, ... [21:55] yacc: Do the permissions on your SVN repo forbid changing revision properties? [21:56] abentley: as this is a public svn repo server, I have no idea. [21:56] abentley: but that's an interesting theory. [21:56] I know it's a configurable option. [21:56] abentley: It will most probably forbid changing revprop. [21:56] both for SVN and bzr-svn [21:57] i.e. bzr-svn does not do it by default [21:57] abentley: Actually it's a hook that decides which properties you are allowed to change. [21:57] dato: What? [21:57] my understanding is that bzr-svn uses properties in a way that is allowed by default in SVN repositories [21:58] and then it has a switch to override svn:date and svn:author, but I don't know if this was abentley meant or not [21:58] dato: which switches. [21:59] or maybe your repo is forbiding even the kind of safe properties bzr-svn needs, though it sounds unlikely [21:59] svn:date won't be overrideable in that repo for sure. [21:59] % grep override ~/.bazaar/bazaar.conf [21:59] override-svn-revprops = True [22:00] dato: I have no bazaar.conf ;) [22:00] k [22:00] yacc: You are allowed to create one :-) [22:01] abentley: yeah, but where do I learn about the options/sections (assuming that it's a ConfigParser thing) [22:01] It's ini format. There are no mandatory sections. [22:02] bzr help configuration will tell you about Bazaar's options, but not bzr-svn's. [22:02] Yeah, but where does that override-svn--revprops belong to? [22:02] I have in [DEFAULT] [22:03] But DEFAULT is optional. [22:03] Now, it would be highly interesting what the default for it is. [22:03] aha [22:03] I'm sure it defaults to False [22:03] You can just have a single-line file with "override-svn-revprops = True" [22:05] Well, technically it defaults to None, but yes that's false too *g* [22:05] Ok, the SubversionError is raised in something that looks like a decorator that catches SVN exceptions. [22:07] How does one set the debug.debug_flags in bzr? [22:08] With -Dfoo [22:08] where foo is the flag you want to set. [22:10] So let's see what bzr-svn is doing before it the bad thing happens :) [22:10] abentley: see you are bad. You made me start debugging myself, [22:11] ;) [22:12] You could also try doing import pdb; pdb.set_trace() in the final else clause of convert_error [22:12] Well, it's one of these then: [22:12] setting revision property 'bzr:file-ids' to '\tTREE_ROOT\n.bzrignore\tbzrignore-20080314001943-npoqulq31axmxa8g-1\nez_setup.py\tez_setup.py-20080314002020-4ktxnl1abormwysn-1\nsetup.py\tsetup.py-20080314002020-4ktxnl1abormwysn-2\nlookery\tlookery-20080314002159-q2mdytaryo7wbdcf-1\nlookery/__init__.py\t__init__.py-20080314002211-5qqxrkuk0wqqoyvi-1\nlookery/lib\tlib-20080314002211-5qqxrkuk0wqqoyvi-2\nlookery/lib/apachelog.py\tapachelog.py-200803140022 [22:12] 11-5qqxrkuk0wqqoyvi-4\nlookery/lib/__init__.py\t__init__.py-20080314002211-5qqxrkuk0wqqoyvi-3\nlookery/scripts\tscripts-20080314011426-ok2xe2a2a4am6oot-1\nlookery/scripts/llfp.py\tllfp.py-20080314011426-ok2xe2a2a4am6oot-3\nlookery/scripts/__init__.py\t__init__.py-20080314011426-ok2xe2a2a4am6oot-2\n' [22:12] setting revision property 'bzr:revision-info' to 'timestamp: 2008-03-14 02:15:10.638999939 +0100\ncommitter: Andreas Kostyrka \nproperties: \n\tbranch-nick: lookery\n' [22:13] setting revision property 'bzr:revision-id:v3-single-trunk/logs/Lookery-Base' to '1 andreas@andi-lap-20080314011510-z091afzyx1t7i3gq\n' [22:13] abentley: I'm not big on pdb style debugging. Lucky for me bzr-svn is not in an egg, so adding prints is not exactly hard. === Toksyuryel` is now known as Toksyuryel [22:17] Acutally, it would be better if convert_error just did "raise" when it couldn't convert. [22:18] That would give a more useful traceback. [22:18] Hi all. [22:19] I'm trying to do {{{ bzr export http://www.gnome.org/~jdub/bzr/planet/2.0/ }}} but it tells me "not a branch". [22:19] What's the equivalent of svn export URL in bzr? [22:20] rindolf: I don't know svn. In bazaar, it creates a copy of the working tree files, optionally gzipped, tarred, zipped, etc. [22:20] abentley: but does it work over remote? [22:21] oh, you'd need to give it a second arg [22:21] dato: thanks. [22:21] rindolf: bzr export target http://www.gnome.org/~jdub/bzr/planet/2.0/ [22:21] rindolf: personally I'd recommend you just clone instead of export, for easy updating [22:21] james_w: thanks. [22:21] rindolf: but your choice :) [22:21] OK, it's making slow progress. [22:22] dato: problem is that at the moment, my Internet connectivity sucks. [22:22] Now I wonder if there is a doc on the SVN API somewhere ;) [22:22] blame my ISP. [22:22] yacc: I have found API docs [22:23] rindolf: Also, it's in an older, less-efficient format. [22:23] I found them to be under-documented, but at least better than un-documented [22:23] james_w: me too ;) [22:23] abentley: what is? [22:24] http://www.gnome.org/~jdub/bzr/planet/2.0/ is in a slower format. [22:24] That's cool, http://svn.collab.net/svn-doxygen/search.php?query=change_dir_prop gives me the HTML source including PHP ;) [22:25] Well, at least there is google ;) [22:26] http://svn.collab.net/svn-doxygen/structsvn__delta__editor__t.html#o11 [22:27] Is 1.2 in gutsy yet? [22:29] awmcclain: No idea, but packages.ubuntu.com should know. Or you can use our gutsy APT repository. [22:29] abentley: Yeah, it's only at 0.9. Thanks! [22:31] awmcclain: If you mean *our* repository is at 0.9, that is unlikely. 0.9 was released in 2006 [22:32] No no gutsy. I'm using 1.2 from your repository now. [22:33] Gutsy includes 0.90, not 0.9 [22:33] gutsy-backports has 1.0 [22:36] I will update backports to bzr 1.3 if Hardy is going to get it plus bzr-svn and friends. [22:37] * abentley is completely disconnected from the Ubuntu release cycle. [22:38] who typically takes care of Ubuntu packaging for bzr? [22:39] jdong: package just migrates from debian [22:39] (fwiw I'll upload 1.3 to debian tomorrow; rc1 is in atm) [22:40] jdong: I can't remember who did the last sync, someone just pinged me on IRC one day to confirm that they had all the necessary bits together. [22:40] I wasn't going to FFe for 1.3 in Hardy. I've just submitted a patch to get bzr-svn to stop complaining about version mismatch. [22:40] james_w / dato: Ok, I'll take some time later tonight to look into this; I'd like to ensure we freeze Hardy with the latest bzr release in there. [22:40] james_w: are the syncs manual at this point? [22:41] dato: have been for a long time [22:41] dato: yes, and they have been for a while. [22:41] dato: thanks to your work it's just a quick test and a manual sync though. [22:41] james_w: unless bzr devs have any objection/hesitation, I'd have no problem FFe'ing bzr. I don't think any of the folks will complain [22:42] everyone in Ubuntu-land loves bzr anyway :) [22:42] *almost* everyone :-) [22:42] *g* [22:43] jdong: I don't think anyone will mind. I was just wary as it will be post-beta. [22:43] jdong: but I haven't got a feel for the Ubuntu release cycle yet, so that may be quite common. [22:43] james_w: normally I would be too, but you guys have such a solid track record [22:44] jdong: that's true. And there will probably be a boat load of fixes in there. [22:44] james_w: indeed [22:44] well the 1.3 NEWS is a little smaller than usual due to all the sprints/conferences etc. this month. [22:44] james_w: I'd rather not have a LTS kick off with outdated bzr :) [22:45] jdong: yeah, let's go for it. Anything you would like me to do? [22:45] well I think I'll have time later tonight to research the bits; just poke me when the Debian package is uploaded :) [22:46] jdong: sure. Though I will be online for limited periods this weekend. [22:46] ok [22:46] dato: would you mind poking jdong when you upload 1.3? [22:46] sure [22:46] The only other thing I haven't seen an upload for is bzr-gtk, is there a new release available? [22:46] dato: great, thanks. [22:47] jdong: you'll need bzr-svn as well I think, and I'd like it if you took bzr-builddeb as well. [22:47] and bzrtools [22:47] oh, of course. === mw is now known as mw|out === kiko is now known as kiko-afk