[00:02] bash? People still use that? :p [00:02] *BSD? People still use that? ;) [00:03] * fullermd is single-handedly keeping it from dying. [00:03] keyboards? [00:03] "The keyboard. How quaint." [00:03] (People still use those?) [00:04] does anyone know what irc nick marius uses? [00:06] 99 round trips to push a new trivial branch [00:06] lifeless: amanic [00:06] abentley: thanks [00:07] Take one down, pass it around... [00:07] fullermd: yeah looking at that :) [00:07] vila: ping [00:07] Next format: 'bottlesofbeer-core' [00:11] fullermd, Odd_Bloke: :) === abentley1 is now known as abentley [00:41] this is weird [00:41] pqm hates my branch, but the failing test passes locally >< === ameoba_ is now known as ameoba [00:50] lifeless: which test? [00:52] branch_implementations.test_branch.TestTestCaseWithBranch.test_branch_format_matches_bzrdir_branch_format(RemoteBranchFormat-v2) [00:52] branch_implementations.test_branch.TestTestCaseWithBranch.test_branch_format_matches_bzrdir_branch_format(RemoteBranchFormat-default) passes [00:52] which adds to the oddity [00:53] lifeless: oops. let me just remove the "fail-lifeless'-branches-spuriously" config option from bzr pqm.... :-P [00:59] spm: pqm runs make check yes? [01:00] lifeless: yup (verified) [01:00] python 2.4? [01:02] Python 2.4.3 [01:02] in the chroot as in [01:03] thanks === orospakr` is now known as orospakr [01:37] I have a repository object that is on my local filesystem [01:37] and I want to pull in some revisions from a remote branch [01:37] without creating a branch locally [01:37] how do I do this? [01:38] thumper: Shared repositories are purely a storage mechanism. [01:38] Which is to say: there isn't a way. [01:38] Odd_Bloke: well, abentley told me there was a way :) [01:38] But branching into the shared repo and then deleting the branch should have the desired effect. [01:38] Odd_Bloke: and I think jamesh has done the before [01:39] Actually, 'bzr pull -r revid:... ' might do it. [01:39] repository.fetch() perhaps? [01:39] And it's certainly possible in bzrlib. [01:40] (Which it now occurs to me you might have been talking about. >.<) [01:40] jamesh: ta [01:41] ah [01:41] ha [01:41] y'know what [01:41] this code is written already [01:42] * thumper smacks himself [01:43] Howdy, I'm having trouble deciding how to convert my svn repo... where to draw the branch lines, basically. [01:43] thumper: the code I did for that bzr-gnomeserver plugin? [01:43] jamesh: no, it came from a gobby session I had with abentley [01:44] thumper: ah. I think I did something like this in that gnomeserver plugin to make sure a repository contained all the revisions from another repository without creating a branch. [01:44] jamesh: yeah, I remember you writing it [01:45] jamesh: I'm working on my version of your old pending reviews [01:45] script [01:45] making it launchpadlib aware? [01:45] yep [01:45] I have all the launchpadlib bits in place now [01:45] or will have very shortly [01:45] cool. are you allowed to make that code public yet? [01:46] I've got top-level dirs in SVN like app/ and lib1/ lib2/. The libs are used by app/ but also could be used without app/ [01:46] jamesh: it will be public as soon as it is written [01:46] Best to put all three in one repo? or three separate repos? [01:46] jamesh: users will be able to run it locally [01:48] hmm.. Branch.open doesn't like lp: style urls [01:48] load plugins maybe? [01:49] yep, that did it [01:50] Any advice? [01:51] baxissimo: 'bzr svn-import SVN-REPO-ROOT BZR-REPO-ROOT' [01:52] lifeless: q isn't what command to use but whether it's better in general to have three .bzrs for three related but independent things, or one .bzr containing all three. [01:53] baxissimo: I don't think there is a general answer to the question [01:53] I frequently make changes to the libs same time as the app, so like being able to have all changes committed with one commit. [01:54] But I'd also like to be able to branch just a lib or just the app. [01:54] Is it the case I have to pick one or the other of those capabilities? [01:55] yes [01:55] (sorry) [01:56] Ok. No, that's helpful. Now I can stop looking for how to get both at once. :-) [01:57] Any chance of "bzr externals" at some point a la svn externals? [01:59] I.e. have multiple branched locations collected in a single directory tree so that one update/commit/pull will hit all the locations. [01:59] I think you mean "branch" not "repository" btw :) [01:59] baxissimo: not yet, but there is some hope we'll get something soon [01:59] you can do that with the repo-push or multi-pull plugins [02:00] bob2: grr. Ok what do I call the stuff that's in a .bzr dir? [02:00] bob2: That actually contains all the history [02:02] baxissimo: .bzr/repository is a repository [02:02] baxissimo: .bzr/branch is a branch :) [02:02] it might be simpler to just forget about repositories entirely [02:03] baxissimo: a .bzr can have either or both of these things (and more besides, like working trees [.bzr/checkout], search indices [.bzr/bzr-search], etc) [02:03] bob2: ok. I mostly meant "a place where all the history actually lives" as opposed to one of those lightweight or stacked branches that doesn't actually contain any history. [02:04] baxissimo: that is indeed a repository [02:05] bob2: I'll check out those repo-push and multi-pull plugins. [02:05] they don't give you commit coherency [02:05] which was one of the things you asked for [02:05] lifeless: so what do you call the .bzr dir that can have all of that? [02:06] baxissimo: a .bzr dir [02:06] (literally, in the code its 'BzrDir') [02:06] lifeless: .bzr dir. Ok. I'll see if I can remember that one at least. :-) [02:06] baxissimo: you can't 'push' or 'checkout' or 'clone' or run nearly any UI commands just on a '.bzr' dir though - you generally have to have a branch [.bzr/branch] to run any UI commands [02:07] baxissimo: bzr is very focus on branch level operations [02:08] lifeless: ok I was focusing on the .bzr dirs since they seem to be the easiest way to see if the files I have are all part of one branch or come from separate branches. [02:08] baxissimo: 'info' and 'branches' are two commands you might like [02:09] lifeless: ok, but I can see right from Explorer if there's a .bzr or not without typing any commands. :-) [02:09] Should we still be using curl or is it time to stop building with that? [02:10] lifeless: what did you mean by "no commit consistency" -- that I'll have to issue commit once for each branch even with those plugins? [02:10] baxissimo: exactly [02:11] AfC: ask vila on the list - he knows all https :) [02:11] lifeless: so they make it so pulling/updating can be done with one command? [02:11] yes [02:13] lifeless: um, oh, right. I was using bzr:// so I guess curl doesn't come into it. [02:14] lifeless: I was a bit surprised to see it sitting for 40 seconds at 0/7805 while it downloaded something huge and then over about 3 seconds cycled through all the integers up to 7805 and moved onto the next thing that it sat at 0/ for a while. [02:15] lifeless: I naively wondered if the to-curl-or-not-to-curl thing was to blame. [02:15] AfC: what release? [02:15] 1.12 [02:15] lifeless: ^ [02:15] AfC: and were you seeing network download counters? [02:15] no [02:15] lifeless: come to think of it, having seen a download counter in a pull was why I tried the raw branch [02:15] lifeless: wanting to see what it said. Let me try again. [02:16] thats odd, I was sure there was a patch to do network counters for bzr*:// [02:16] Does bzrtools work on Windows? The lack of a .zip is usually a bad sign. [02:16] * AfC notes that there seems to be an awful lot getting packed onto that progress line. I wonder if a standard 80 char wide terminal isn't wide enough [02:19] Nope [02:19] Doh, [/me smacks forehead] looks like bzrtools are installed by default with the Windows installer. [02:19] that's not a problem [02:21] lifeless: I'd have to guess that the download counter only works over http transport. [02:21] And indeed 80 columns is NOT wide enough. Yetch. [02:22] lifeless: yeah. It's http only (in 1.12, anyway) [02:23] AttributeError: 'RemoteBranch' object has no attribute 'supports_rich_root' [02:23] poos [02:23] thumper: branches don't affect rich root support [02:24] thumper: what are you doing? [02:28] There's a patch for hpss download counters, but I didn't get time to decide how it should interact with vila's socket-wrapping approach for the HTTP ones. [02:28] lifeless,bob2: ok, seems like repo-push isn't what I want. I don't want to "push all branches to another [single] location", I'd want to push all branches to their different respective locations. [02:28] So I decided against rushing it into 1.12 late in the release cycle. [02:28] But multi-pull looks good. Thx for the pointer. [02:29] baxissimo: that's what repo-push does [02:30] bob2: the command description makes it sound like it only works with 1 destination location. [02:30] thumper: jml: mwhudson: lp:foo through proxies - http://docs.python.org/library/xmlrpclib.html#example-of-client-usage [02:30] baxissimo: yes... [02:30] jamesh just dug that up [02:31] baxissimo: /local/foo/liba -> /remote/whatever/liba, /local/foo/libb -> /remote/whatever/libb [02:31] ideally, at least, it was broken last time I tried it [02:32] bob2: ok, so you couldn't have a --> /remote/whatever/a b --> /somewhere/else/something/b then? [02:32] lifeless: repository.fetch from a branch [02:33] thumper: b = Branch.open('remote') [02:33] refs = b.get_last_revision_info()[0] + b.tags.get_tags_dict().values() [02:33] for ref in refs: target.fetch(b.repository, ref) [02:34] * thumper tries [02:34] or something ~= to that [02:37] AttributeError: 'RemoteBranch' object has no attribute 'get_last_revision_info' [02:37] last_revision()? [02:38] last_revision_info(), or sure, last_revision() [02:41] does bzr tag it's revisions in lp:bzr? [02:41] 'cause I'm not seeing any using Branch.open('lp:bzr').get_tag_dict() [02:41] insert a .tags in there too === _[PUPPETS]Gonzo is now known as [PUPPETS]Gonzo [02:47] thumper: there is something weird with pqm, they don't propogate through the merge process [02:47] thumper: in the general case, tags for releases aren't in trunk anyhow [02:47] thumper: anyhow, see that link above? [02:48] there is a bug/limitation in the bzr-lp plugin which it allows fixing [02:48] which one? [02:48] the docs.python.org one? [02:49] yes [02:59] thumper: bug 330823 - its a dup of a much older one [02:59] Launchpad bug 330823 in bzr "Branching from Launchpad (direct via http) fails behind HTTP/DNS proxy" [Undecided,New] https://launchpad.net/bugs/330823 [03:06] base = graph.find_unique_lca(rev1, rev2) [03:06] why does this raise ObjectNotLocked? [03:07] thumper: because your backing repository isn't locked [03:07] lifeless: and I lock and unlock how? [03:07] we used to autolock but had too many cases of 'its slow because its continually refreshing the object list' [03:08] tree|branch|repository.lock_read(), unlock() [03:09] * igc heads off for lunch & medical stuff [03:10] thumper: why do you need that though? [03:10] lifeless: ;-) you'll see [03:11] bzrlib.errors.NoCommonAncestor: Revisions have no common ancestor: [03:11] I don't believe it [03:13] how can I manually confirm? [03:13] I think it is lying to me [03:14] lifeless: I wonder if 2.4 supports that: http://www.python.org/doc/2.4.4/lib/module-xmlrpclib.html [03:15] jml: if it doesn't, we could version-check [03:15] lifeless: anyway, I *think* I knew about that already :) [03:17] abentley: ping [03:17] * thumper calculates time zones [03:17] * thumper thinks abentley may still be up [03:17] thumper: you can traverse the graph by hand, but its not lying to you [03:18] lifeless: the graph is obviously not complete [03:18] lifeless: as the revisions are related [03:18] baxissimo: you can, but afaik repo-push nor multi-pull will do it for you [03:18] thumper: or something; but without some details on what you're doing I can't comment sensibly [03:18] lifeless: I have a repo with no branches but a bunch of revisions [03:19] lifeless: which I have populated with repository.fetch yadda yadda [03:19] baxissimo: in practice 'for dir in *(/); (cd $dir ; bzr pus) ; done' may suffice [03:19] lifeless: I'm trying to generate preview diffs without using working trees [03:19] lifeless: abentley tried to give me an outline [03:19] lifeless: and we're close [03:19] lifeless: I've got it so I get the repository populated with the revisions [03:20] lifeless: but I need to work out the lca to pass into the 3 trees merger [03:20] lifeless: or preview tree thingy [03:20] lifeless: I'm at the stage of trying to find the lca [03:21] thumper: and why are you sure the revisions are related? [03:22] lifeless: because I branched one from the other [03:22] lifeless: one is lp:pqm [03:22] lifeless: and the other is one of my pqm branches [03:22] lifeless: so I'm pretty sure they are related [03:22] well [03:22] make sure you're using the right key type [03:23] if graph is repository.get_graph(), its a simple string otherwise its a key tuple [03:24] rev1, rev2 = repo.get_revisions(['my-revid', 'trunk-reviid']) # not real revids [03:24] I used repository.get_graph() [03:24] base = graph.find_unique_lca(rev1, rev2) [03:24] secondly, you don't need a shared repo for this sort of thing if you have recent repositories you can just add a temporary fallback repo during the calculation [03:25] lifeless: lets just say I have a local copy of all the revisions [03:25] sure, just letting you know :P [03:25] so why does the graph not think they are related? [03:26] We really should improve the "here's a traceback, please file a bzr bug" message to peek at the traceback to see if a plugin is obviously involved, and if so blame the plugin rather than bzr... [03:26] lifeless: can you please take a look at https://bugs.launchpad.net/bugs/330823 [03:26] Ubuntu bug 330823 in bzr "Branching from Launchpad (direct via http) fails behind HTTP/DNS proxy" [Undecided,New] [03:26] thumper: You rang? [03:27] jml: in what sense [03:27] abentley: yes, I'm having mad issues [03:27] thumper: lol [03:27] abentley: I have my local repo with revisions now [03:28] abentley: but the graph doesn't seem to think that the two revs are related [03:28] jml: oh its a more complex report than I knew [03:29] thumper: Well, it's possible they're not... [03:29] abentley: the branches that they are from are related [03:29] How are you creating them? [03:30] abentley: pulled from real branches [03:30] thumper: Can you run bzr find-merge-base against them? [03:30] thumper: oh [03:30] thumper: don't pass in revision objects [03:31] thumper: pass in revision ids [03:31] grr [03:31] nearly everything works in terms of identifiers [03:31] full revision objects are expensive when not needed [03:31] the docstring says revision not revision_id [03:31] so I assumed revision objects [03:31] fair enough [03:32] thumper: Sorry, I'm a bit sloppy with that distinction. [03:32] hah [03:32] have a base now [03:33] * thumper attempts to generate a preview diff [03:33] hey, anyone know if/when a osx 10.5 installer will be available for 1.12 [03:33] abentley: where does the preview tree code live? [03:34] kkubasik: i saw some swearing in here about bzr-svn on os x, so hopefully soon [03:34] slash, I'm totally willing to build it if anyone can point me to how the 1.11 package was built [03:34] thumper: In transform.py, but you won't use it directly. [03:34] mwhudson: thanks! [03:34] abentley: so given base_id, rev1_id, and rev_2 id [03:34] abentley: and a repo [03:34] abentley: what do I do to generate the treeless diff? [03:35] thumper: Instantiate a Merge3merger [03:35] found in? [03:35] merge? [03:35] thumper: merge.py [03:35] thumper: have you seen http://pastebin.ubuntu.com/119504/ ? [03:35] (from my lpreview hackery( [03:35] kkubasik: there is already one uploaded last I checked [03:36] thumper: You'll need to get RevisionTrees for all the revisions first. [03:36] abentley: a Merge3Merger wants working trees [03:36] me has a shiny loggerhead branch he wants everyone to try! [03:36] ah, only a 10.4 one here: https://edge.launchpad.net/bzr/1.12/1.12 [03:36] not sure why [03:36] lp:~mwhudson/loggerhead/unified-by-default-sbs-by-ajax [03:36] thumper: Yeah, but you can get away with just revisiontrees. [03:36] or if it matters [03:37] abentley: RevisionTrees are created how? [03:37] mwhudson: I have no real trees [03:37] thumper: Repository.revision_tree [03:37] thumper: repository.revision_trees([revision_id1, revision_id2]) [03:37] thumper: neither does that code [03:38] jam:at https://launchpad.net/bzr/+download ? [03:38] branch.basis_tree() == branch.repository.revision_tree(branch.last_revision()) [03:38] I can't find one.... [03:39] thumper: Make sure you pass in do_merge=False. [03:39] mwhudson: I don't have a branch [03:39] thumper: but you have a repository and a revision tree [03:39] kkubasik: On the page you linked, I see: Bazaar-1.12-OSX10.4-universal.dmg [03:39] thumper: but you have a repository and a revision id [03:39] (rather) [03:39] but you're right that I don't see a 10.5 one [03:40] lifeless: thanks [03:40] jam: yeah, i need OSX10.5 [03:41] hmm [03:41] KeyError: 'pop(): dictionary is empty' [03:41] line 1694, in _iter_inventory_xmls [03:41] chunks = text_chunks.pop(key) [03:41] that is attempting repo.revision_trees [03:42] Why doesn't this work?: bzr svn-import --trees http://svn.dsource.org/projects/multiarray/trunk/multiarray/dflat [03:42] thumper: that's odd-- it should just fail if it can't find the right inventories. [03:44] :( [03:44] thumper: Did you pass revision_ids in as a list? [03:44] yes [03:45] base_tree, rev1_tree, rev2_tree = repo.revision_trees(base, rev1, rev2) [03:45] hang on [03:45] wrong line [03:45] thumper: That should be repo.revision_trees([base, rev1, rev2]) [03:45] base_tree, rev1_tree, rev2_tree = repo.revision_trees([base, rev1, rev2]) [03:45] I tried the first after the second [03:45] but it failed with wrong number of args [03:46] base, rev1 and rev2 are all revision ids [03:47] thumper: Can you put a pdb in _iter_inventory_xmls where it's looping through records? [03:47] * thumper wonders which bzrlib he's using [03:48] abentley: I'm in the interactive interpreter right now [03:48] so I should just be able to invoke pdb [03:48] and set a break point right? [03:48] thumper: Could be. I always do it the hard way :-) [03:49] ok [03:49] abentley: do you want to skype? [03:50] thumper: sure. [04:12] baxissimo: file a bug on bzr-svn [04:13] spiv: is making a repo with init-repo first a requirement? [04:13] baxissimo: not [04:13] "no", rather [04:14] spiv: Ok. I'll file a bug. [04:14] baxissimo: cool. jelmer's pretty good at fixing them :) [04:18] Can someone tell me why I get this response from launchpad-login ? http://dpaste.com/121983/ [04:19] jblount: hmm, because of a bug with progress bars [04:20] its not being ifnished() [04:20] spiv: submitted https://bugs.launchpad.net/bzr/+bug/330832 [04:20] Ubuntu bug 330832 in bzr "svn-import doesn't import anything" [Undecided,New] [04:21] jblount: I don't think that bug has been reported yet [04:21] * jblount heads off to LP [04:21] or possibly its reporting when there isn't a progress bar? [04:21] lifeless: I could take a video if you like, but it does go into "progress bar mode" briefly and then report the paste. [04:26] fwif http://etc.joshuablount.com/bzr-launchpad-login-weirdness.ogv [04:27] jblount: heh [04:27] you have far too much bandwidth [04:27] Are those progress bar warnings disabled in release builds? [04:28] Peng_: not yet [04:28] lifeless: :) [04:28] ...That's unfortunate. [04:28] perhaps using "script" might produce a more australia-friendly recording [04:29] actually, that is a fairly small ogv [04:29] 49KB [05:41] jblount: is that perfectly reproducible? [05:41] and thanks for the video, i think that's the first time i've seen one used in a bug report [06:15] If I have branches foo/ and bar/ how can I reorganize that so bar is under foo -- like foo/bar? [06:16] merge keeps telling me they have no common ancestor. [06:21] oh... bzr merge -r0..-1 is the magic I'm looking for. [06:22] Dang, I merged into the wrong place. Is there an undo? [06:23] baxissimo: bzr revert [06:24] baxissimo: probably you want to just make a checkout of bar under foo [06:25] foo/ already has foo/baz and foo/bif as part of the same branch though. [06:25] poolie: bzr revert ... very nice. [06:30] So ... think about it more actually maybe what I'd rather do is break baz and bif into their own branches. They are all pretty independent. [06:37] baxissimo: there is a merge-into plugin too [06:39] lifeless: that sounds like what I'm after. But I guess it pretty much just does a merge 0..-1. [07:01] hi all [07:03] hi vila! [07:04] Is there an efficient way to unmerge a branch? [07:05] davidstrauss: bzr revert I think [07:05] baxissimo: I mean one that's long committed. [07:07] davidstrauss: you can uncommit [07:07] The merge is about 20 commits down. [07:59] Can I somehow change a repo to --no-trees after it's already created? [08:01] baxissimo: right now not through bzr [08:01] however, you can simply touch .bzr/repository/no-working-trees [08:02] jfroy: What about http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#remove-tree [08:02] that operates on a branch [08:02] Or do you mean shared storage [08:02] oh [08:02] I think baxissimo was asking about the --no-trees option for repositories [08:03] I have a shared repo that I just filled up with a bunch of different branches. [08:03] Well "repository" can mean many things in Bazaar. [08:03] No :p [08:03] A repository is what gets made by init-repo :p [08:03] Now I'm thinking I'd like to convert all those branches to --no-trees style. [08:04] jfroy: No. "A branch consists of the state of a project, including all of its history. All branches have a repository associated..." [08:04] baxissimo: touching that file will turn on the no trees option on the repo. [08:04] jfroy: And not all branches use shared storage. [08:04] You'll need to remove-tree on any existing branch however [08:04] jfroy: remove-tree before or after touching the file? [08:05] davidstrauss: don't actually consider that relevant. Branches may have internal storage of their deltas or use external storage e.g. a repository [08:05] jfroy: The fact that there's a command "init-repo" doesn't change that all revision storage, branch-local or not, are called "repositories." [08:05] Saying that "branches may contain a repository" just confuses things. [08:05] IMO [08:05] But, I suppose, "shared storage" is more accurate. [08:05] jfroy: Well, then the docs need updating, because the quote I pulled was from them. [08:05] I'm aware of that. [08:05] "All branches have a repository associated" [08:05] http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#remove-tree [08:06] But the confusion about bzr shared repositories is well known... [08:06] bzr terminology is definitely confusing. [08:06] Which is rather unfortunate. [08:06] baxissimo: it isn't, once you have clearly separate things [08:06] And "shared storage" doesn't mean it's a repository in the collaborative "main line" sense, either. [08:07] It's shared by many branches. [08:07] I use shared storage on my laptop to avoid pulling revisions twice for my own dev branches [08:07] And yes, again, the terminology isn't as clear as it could be. [08:07] But the concepts are, however. [08:07] jfroy: Also: "Repositories in Bazaar are where committed information is stored." [08:07] jfroy: That is true of non-shared storage, as well. [08:08] I ind that quote, again, unfortunate. [08:08] *find [08:08] It's unnecessarily confusing. [08:08] And: "By default just running 'bzr init' will create a repository" [08:08] Repositories are such an unimportant, technicality of bzr. [08:08] The core concept is that of a branch. [08:08] Agreed [08:08] init creates a branch [08:09] repository has clearly defined semantics by virtue of other, past VCS [08:09] All I'm doing is quoting the docs [08:09] I know [08:09] I think it would help if the words were more often coupled with their concrete implementation [08:09] :| [08:09] Like a repository is generally implemented as a .bzr/repository directory containing the data. [08:09] And saying I'm justified for not assuming removing a tree from a repository means from shared storage ;-) [08:10] That helps demystify the terms I think. [08:10] Bazaar should stop using the term repository entirely, I think [08:10] I agree [08:10]