=== beuno_ is now known as beuno [00:08] do any dvcses aside from darcs have superfly cherrypicking? [00:08] I think arch did OK. [00:09] Probably not as good as darcs though, since it's fundamentally first-class in darcs. [00:13] fullermd: last time i checked arch was rather broken [00:14] and i dont think it got any better [00:19] mwhudson_, any ideas why tests now always fail for me in LH (on all branches, so it's not the broken tests)? [00:19] http://paste.ubuntu.com/187005/ [00:19] jelmer, hi [00:19] beuno, hello [00:20] jelmer, quick question [00:20] Well, AFAIK it's not moving anywhere. But it still sorta cherrypicked OK :p [00:20] jelmer, when was bzrlib.foreign introduced in bzr? [00:22] 1.13/1.14 [00:22] jelmer, just to figure out if I have to bump the min bzrlib version [00:22] ok, I do then [00:22] thanks lifeless [00:22] beuno, good question, I think it was 1.11 [00:22] lifeless, that late? [00:25] morning [00:25] hi igc [00:25] hi beuno [00:27] jelmer, I'm not sure what to expose on the UI for this [00:27] as in [00:27] I have no idea what this is: (('203ae883-c723-44c9-aabd-cb56e4f81c9a', 'trunk', 230), BzrSvnMappingv3(TrunkBranchingScheme(0))) [00:27] beuno, So in that particular case the interesting bit would be "trunk" and 230 [00:28] jelmer, so it's not key value pairings, just values with no explanation to them? [00:28] beuno: You can call use the second part of the tuple to get a key/value representation [00:28] What is returned is a tuple with foreign_revid and mapping [00:29] foreign_revid is specific to the foreign vcs [00:29] jelmer, could we refactor this so it gives us the key:value entries directly? [00:29] that way it's very clear what should be exposed :) [00:30] beuno, mapping.vcs.show_foreign_revid(foreign_revid) will return a dictionary with key/value pairs (all strings) [00:30] that's what's used for "bzr log" [00:30] you might also be interested in mapping.vcs though, e.g. for displaying a git/svn/hg/etc icon [00:32] hey, bzr people. [00:32] grr [00:33] moin jml [00:33] wb beuno [00:33] beuno, did you see those last few lines? [00:34] jelmer, saw: 20:30 < jelmer> you might also be interested in mapping.vcs though, e.g. for displaying a git/svn/hg/etc icon [00:34] las [00:34] last [00:34] beuno_, yeah, that's right [00:35] jelmer, it's starting to get more complex than exposing it on the UI === beuno_ is now known as beuno [00:36] beuno: Perhaps we should focus on just the foreign rev info first, and other fancy stuff like icons later [00:41] jelmer, sounds good [00:41] can you update the branch to ad that [00:44] jelmer: I was sure it was in by then, and a later than actual answer is still useful :) [00:45] jelmer: $ rmadison subunit [00:45] subunit | 0.0.2~bzr66-1 | karmic/universe | source, all [00:46] lifeless, \o/ [00:46] beuno, will do [00:48] abentley, thanks for your suggestion earlier, but I am still stuck: http://pastebin.ca/1445563 [00:48] abentley, thanks for your suggestion earlier, but I am still stuck: http://pastebin.ca/1445563 ; I have committed my changes before this [00:50] FurnaceBoy2: if you want your local branch to overwrite the solaris10-port, add --overwrite to your push command, just once. [00:51] hm, ok. i think i have succeeded by doing that in the past, I wonder why it didn't occur to me this time. [00:51] * FurnaceBoy2 goes to try [00:52] ok that certainly pushed. [00:52] thanks [00:53] beuno, sorry, phone call. I'm working on the foreign revid stuff now === abentley1 is now known as abentley [00:58] beuno, lp:~jelmer/loggerhead/foreign [01:05] igc: ping [01:05] jelmer, thanks, dinner, but will look at it later [01:05] igc: I'd like to try and convince you to change the core iter_changes and put excludes into it too :) [01:05] lifeless, your evil plan worked [01:05] beuno: which one was that? [01:05] lifeless: +1 [01:06] lifeless: I've come to the same conclusion [01:06] \o/ [01:06] lifeless: trying to do it as a decorator is too fragile w.r.t. locking [01:06] and consistency [01:07] igc: it will also tend to trigger full inventory scans from dirstate, I suspect [01:07] its just more work, but hey, that's ife [01:07] how much memory can I expect bzr 1.14 to use when cloning a 1.2 GB branch stacked on a 450MB branch? [01:07] jml: a few hundred MB probably [01:07] limited on-production experimentation suggests 4.5GB+ [01:07] jml: bugger a file [01:07] lifeless: cool. [01:08] lifellif"get slightly involved and then get sucked in/obbssessed" [01:08] lifeless: will do that, but would like to experiment locally first. [01:08] beuno: :) with loggerhead? [01:09] I think it was loggerhead I tried to do that with [01:48] jelmer, ping [01:48] cody-somerville, hi [01:48] jelmer, using the latest bzr-git, 0.3.2, locally I get a different error [01:48] http://pastebin.ubuntu.com/187048/ [01:49] cody-somerville, what git repository was this again? [01:50] git://git.debian.net/git/debian-live/live-helper.git [01:53] cody-somerville: Hmm, that looks different indeed. Any chance you can file a bug report? [01:54] jelmer, sure. bzr-git on launchpad? [01:55] cody-somerville, yep [01:55] igc: ping [01:55] hi jam [01:57] jelmer, filed as lp #382993 [01:57] Launchpad bug 382993 in bzr-git "AttributeError: children when performing git-import" [Undecided,New] https://launchpad.net/bugs/382993 [01:58] igc: I was hoping you would get a chance to run some Usertest stuff on Jelmer's most recent bencode serializer code [01:58] We really need to come up with a disk format for 2.0 rather soonish [01:58] jam: that's on my list for today [01:58] I'm still on check FWIW [01:58] spiv: are you copacetic on network deltas? [01:59] jam: the main thing I need is a patch/branch with all the proposed bits including a placeholder format, e.g. development8-rr [01:59] jam: jelmer did exactly that fro me to benchmark the rio stuff [02:00] jam: to test on OOo, I also need 36 hours to generate a repo in the proposed new format [02:00] igc: I'm pretty sure he had a --dev7-rr format [02:00] also, I would expect converting from --dev6 => --dev7 would be much faster [02:00] and it could be mysql, it wouldn't have to be OOo [02:01] jam: great. I'll take a look at his latest patches [02:01] yes, mysql would be faster. I don't have it converted to development6 yet though. [02:01] jam: can you upload a converted repo for me? [02:07] jelmer: I don't see the index problem [02:07] jelmer: care to fix? [02:08] lifeless, I tried, but couldn't easily find out where the unicode objects were being introducecd [02:09] what was their value? [02:09] Is there a way to specify the ssh port to use when pushing something to your private branch? [02:09] bzr+ssh://host:port/... [02:10] lifeless, checking [02:11] So instead of "bzr push lp:~kizzobot/blah/blah", the location would be "bzr+ssh://launchpad.net:22/..."? [02:11] I'll try it out now. [02:11] kizzo: uhm [02:12] kizzo: the default port for lp/bzr+ssh is 22, so it should Just Work [02:12] kizzo: what are you seeing happen? [02:12] (and it would be bzr+ssh://bazaar.launchpad.net:22/~kizzobot/blah/blah) [02:12] My /etc/ssh/ssh_client specifies a default port of NOT 2222. [02:12] interesting [02:12] ok [02:12] Oh wait .. s/NOT// [02:13] so the above should work [02:13] Yeah. [02:13] and please file a bug that lp: isn't forcing the port [02:13] cody-somerville, looks like a symlink target that's been changed to include an extra / [02:13] Yeah I would think so too. [02:13] I think it is actually.. [02:13] kizzo@crashtest:~/work/new-bindings$ bzr push bzr+ssh://code.launchpad.net:22/~kizzobot/+junk/python-bindings [02:13] in fact, bzr+ssh should possibly force the port [02:13] ssh: connect to host bazaar.launchpad.net port 2222: Connection timed out [02:14] hmm [02:14] not code.launchpad.net - bazaar.launchpad.net [02:14] lifeless, a bit related, it also looks like "bzr index" doesn't like ghosts [02:14] redirectors in the middle will give you grief [02:14] kizzo: another thing you could do, in ~/.ssh/config [02:14] Host bazaar.launchpad.net [02:14] port 22 [02:14] lifeless: why should it force the port ? [02:15] jelmer, does that mean an easy fix? [02:15] lifeless, node is (, ('1545',), u'p mapping.py') [02:15] SamB: because there is a well known port [02:15] cody-somerville, not sure yet [02:15] lifeless: Oh ok that works - thanks. [02:15] And specifying the port in the URL successfully works. [02:15] lifeless: wouldn't that be a major abuse of the URL syntax ? [02:15] SamB: no [02:15] it's not necessarily the case that ALL ssh servers run on that port ... [02:15] SamB: naturally [02:15] there may be situations where a SINGLE machine has MORE THAN ONE [02:16] SamB: I think you have misinterpreted what I said [02:16] lifeless: what did you mean ? [02:16] SamB: If a user tells bzr 'bzr+ssh://host/' bzr should be attempting to connect to port 22 [02:16] oh, sure! [02:16] that's not forcing, that's defaulting! [02:17] SamB: so it should be forcing the port when it invokes ssh [02:17] oh [02:17] you mean it should pass the default port on to SSH [02:17] no, I mean it should tell ssh the port to use, always. [02:17] instead of just assuming that SSH has the default default? [02:17] right [02:18] SamB: I think lifeless is saying that it would be bad if the bzr tool itself was always forcing the port to be 22, and not letting the user specify another port. [02:18] jelmer: is that a path in your tree? [02:18] kizzo: I'm pretty sure that's what I was trying to say to lifeless ... [02:18] lifeless, mapping.py is, not the "p " bit [02:18] Oh nvm haha. [02:18] jelmer: p is path [02:18] jelmer: its the entry type [02:18] lifeless, ah, right [02:19] so [02:19] search should be ghost friendly, as long as the ghosts aren't required to calculate deltas - which they must not be [02:20] lifeless: copacetic on network deltas? I only just woke up, so I'm hardly copacetic on anything right atm ;) [02:26] jelmer: what are you indexing? [02:26] lifeless: anything [02:28] jelmer: line 978 of index.py [02:28] can you insert [02:28] lifeless, it's looking very similar to the reconcile text ghost handling bug [02:29] === modified file 'index.py' [02:29] --- index.py 2009-01-21 07:59:57 +0000 [02:29] +++ index.py 2009-06-03 01:29:17 +0000 [02:29] @@ -975,6 +975,9 @@ [02:29] if document_key in self._document_ids: [02:29] return self._document_ids[document_key] [02:29] next_id = str(self.document_index.key_count()) [02:29] + value = "%s %s %s" % document_key [02:29] + if type(value) is unicode: [02:29] + import pdb;pdb.set_trace() [02:34] lifeless, (Pdb) print document_key [02:34] ('p', '', u'mapping.py') [02:35] When you do something like "bzr branch lp:whatever", what is the expanded version of "lp"? [02:35] hi [02:35] dumb question: how do i restore a deleted file? [02:36] lifeless, unrelated question, could it be that bzr is fixing the formatting of InventoryEntry.symlink_target [02:37] jelmer: peng filed this as a dev6 specific bug [02:37] lifeless, the bzr-search thing you mean? [02:37] jelmer: can you give me the backtrace for that? [02:37] kizzo: its the result of an xmlrpc call [02:38] i have committed the deletion and done other changes since then [02:38] moldy: bzr revert -r FILENAME [02:38] lifeless, http://pastebin.ubuntu.com/187068/ [02:39] lifeless: thanks! is there any better way to find than to read through the logs? [02:39] moldy: bzr log -v | less , /FILENAME :) [02:40] moldy: (for now) [02:41] lifeless: ok, i see. thank you! [02:41] jelmer: pull trunk [02:42] lifeless, I can confirm that works, thanks! [02:43] igc: lp:///~jameinel/bzr/bencode_serializer [02:43] That should be the latest version of the serializer, with all the bits sewn together [02:44] well, once it finishes uploading :) [02:45] I think the machine with my mysql conversion is offline right now, I'll see what I can do [02:47] Hmm why is "bzr branch lp:~kizzobot/+junk/python-bindings" talking SSH? (I have a packet sniffer running and seeing the traffic). [02:47] I'm under the impression that I'm branching FROM launchpad - why would SSH be involved? [02:47] kizzo: Why shouldn't it? [02:48] kizzo: If you've run "bzr launchpad-login", lp: expands to bzr+ssh://bazaar.launchpad.net/ [02:48] Peng_: It's a public branch. Like, anyone should be able to get it. [02:48] hmm [02:48] jelmer: cool [02:48] kizzo: Anyone can get it. If they haven't logged in, it'll use http. [02:49] Who what works? [02:49] jam: thanks [02:49] igc: just make sure you run 'make' :) [02:49] jam: and thanks for the reivews as well [02:49] jam :-) will do [02:49] the numbers tend to stand out if do forget :-) [02:50] s/if/if I/ [02:53] I'm trying to use bzr-svn to create a subversion repo on a remote server and push my bzr branch to it. I tried using "bzr svn-push svn+ssh://server.com/home/username/svnrepos/project", but got "bzr: ERROR: No repository present" [02:54] xnevermore, a repository ahs to alreday exist [02:54] and I need to fix my spelling [02:54] jelmer: do you know what the svn command for that is? [02:55] xnevermore, on the remote server: svnadmin create /path [02:55] jelmer: bzr init --svn svn+ssh://server.com/home/username/svnrepos/project would be cute :) [02:56] jelmer: and the api definitely supports it:) [02:56] lifeless, the remote one doesn't unfortunately [02:56] lifeless: well enough ? [02:56] SamB: EPARSE [02:56] lifeless, locally "bzr init-repo --subversion" already works [02:56] the API may believe it supports a thing, but it might not actually be possible to make it work in a real situation ... [02:57] SamB: I don't see why it wouldn't [02:57] SamB: or I wouldn't have said that the api supports it ;) [02:57] lifeless: that's usually on account of not having tried and failed ;-) [02:58] SamB: are you arguing hypothetically, or from experience with this particular api ? [02:58] jelmer: ok, i issued that command, then issued the svn-push command, but got "bzr: ERROR: These branches have diverged. Use the merge command to reconcile them." [02:58] jelmer: how does it fall down for you? [02:58] lifeless: hypothetically, I guess [02:58] I haven't tried and failed either [02:58] xnevermore, you need to push to somewhere inside of the repository, e.g. URL/trunk [02:58] SamB: 'nuff said [02:58] but the way jelmer keeps doing it I wouldn't have been surprised either way [02:59] lifeless, the API for creating a repository requires you to specify a local path [02:59] jelmer: whose api [02:59] lifeless, The SVN one [02:59] oooh [02:59] jelmer: I was meaning 'ssh host svnadmin ...' [02:59] lifeless, The only API that works with svn+ssh://, svn:// and http:// doesn't allow creating repositories [02:59] for once it's not bzrlib's fault [03:00] lifeless, ahh [03:00] jelmer: which you have enough data to do [03:00] lifeless, Yeah, I guess we could do that [03:00] jelmer: certainly it could try [03:00] what does svn+ssh need from a remote anyway ? [03:02] jelmer: cool, thanks. that worked fine [03:03] SamB: it uses libsvn locally with a remote url [03:03] SamB: as opposed to the bzr rpc server [03:03] lifeless: I meant, what does libsvn need from the remote ... [03:03] SamB, it needs svnserve present on the remote server [03:06] just like bzr really, except our serve is a subcommand [03:10] svnserve should be an alias for "bzr serve --svn" [03:18] that would be cool in a strange sort of way [03:50] jelmer: http://launchpadlibrarian.net/27418534/ubuntu-tweak-master-log.txt [03:50] jelmer: still awake? [04:06] So, um, how do bzr serve --git and --svn work? Do they serve native git/svn branches over the git/svn protocols? Bzr branches? [04:07] How do you check if a transport is read-only? [04:07] Peng_: there's .is_readonly() on the transport object [04:08] spiv: Oh, that's simple and obvious. Thanks. [04:08] Peng_: of course, a transport may think its read-write and then get PermissionDenied from all write ops ;) [04:08] .readonly is a misfeature [04:08] I advise against using it [04:08] it really just reflects that a particular transport will deny *all* write operations, not that *any given* operation will succeed [04:08] Peng_: so the reliable way is to actually try writing and be prepared to catch errors :) [04:09] I'm interested in making sure the transport is read-only, not making sure it's not. :) [04:10] Peng_: context? [04:12] lifeless: Loggerhead, both in general, and specifically for serving .bzr/smart. [04:17] Peng_: I'm not sure why you would care there? [04:17] is there any reason loggerhead shouldn't be able to write when its serving, just as bzr:// can ? [04:18] That's a good point. Still, it doesn't allow configuring that (yet), and it should default to read-only. [04:18] sure [04:19] I'd make sure bzr serve's facility for configuring this is reused directly [04:20] Thanks to how "bzr serve" works, it already is. [04:20] "bzr serve" passes a transport to Loggerhead; if --allow-writes was not passed, it's read-only. [04:20] But start-loggerhead and serve-branches are still around, and the latter takes arbitrary URLs. [04:34] jam: ping [04:39] Making Loggerhead writable is spooky and totally cool. [04:46] * igc lunch === abentley1 is now known as abentley [04:49] Peng_: for sex, have clients at the trunkof the branch get updates pushed via ajax when someone commits via loggerhead === abentley1 is now known as abentley [05:01] It's totally cool that pushing from a bzr client -> bzr+http server -> bzr server works, right? [05:01] Peng_: yes [05:01] :) [05:16] lifeless: Thanks. [05:42] Do you think it's worth running a bzr+http server? [05:42] Especially since that entails running an old version of bzr that actually works? [05:43] lifeless: so, regarding the memory thing I mentioned earlier [05:43] I'm not sure what percentage of that was a serious question and what was whining. [05:43] lifeless: http://paste.ubuntu.com/187123/ has a traceback I got from doing C-\ while the memory was climbing [05:43] lifeless: can you please help me file a good bug for this, now that I can reproduce the error locally? [05:44] sure [05:44] let me look [05:44] Peng_: yeah, sorry about that, that bug is on my todo list... [05:44] so that particular point is in index processing [05:44] and you don't have the C extensions built [05:45] first thing, see if they make a difference. [05:46] jml: secondly, grab jam's memory profiler tool [05:46] and use it when you break in [05:47] I wonder why they aren't built. I'm running from the nightly ppa [05:49] jml: I may be wrong [05:49] import bzrlib._btree_serializer_c [05:49] it's not there. [05:50] 1.15+4368+109 should be recent enough, right? [05:51] bug in the ppa builds [05:51] I'll file it [05:52] thanks. [05:53] spiv: <3 [05:53] hah, I don't even have pyrex installed. [05:54] Actually, I wasn't just whining. Branching bzr.dev's entire history over bzr+http would probably make my server catch fire. [05:54] Peng_: with what format ?:) [05:57] pygi: 1.9. [05:57] Peng_: try with brisbane? :) [05:58] pygi: Not possible. If I upgrade my bzr+http server to a version that supports bbc, it'll also suffer from bug 348308. [05:58] Launchpad bug 348308 in bzr "Smart server jail breaks bzr+http with shared repos" [High,Triaged] https://launchpad.net/bugs/348308 [05:58] Obviously I could set up two servers, but that'd be a pain. [05:59] And anyway, trying it means risking an OOM. [06:04] hmm. rate of climbing seems slower, but it's still over 1g. [06:05] time for the memory profiler [06:06] hurh, it's not using the c module [06:06] * jml bangs the box a couple of times. [06:24] hmmmmm. [06:24] now that I'm using C extensions, seems to be capped at ~721MB [06:25] thats still high [06:25] if you could build and use jams profiler that would be good [06:25] lifeless: sure thing. where does it live? === jfroy is now known as cami === cami is now known as jfroy [06:27] lol http://mac.wareseeker.com/free-john-arbash-meinel/ [06:28] (spam search hit in google) [06:29] https://lists.ubuntu.com/archives/bazaar/2009q2/056433.html [06:29] ^ jml: [06:29] ta [06:30] lifeless: interested at all in the pure python data? [06:31] jml: not really. [06:31] choosing battles etc [07:18] hi all [07:55] Gar, why does PQM not want to send me failure mail... [08:04] No handlers could be found for logger "bzr" [08:04] Permission denied (publickey). [08:04] bzrlib.errors.ConnectionReset: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required) [08:12] Ah, right. Ok. [08:13] I guess the PQM user isn't properly set up to cope with lp: URLs :/ [08:46] spiv: rt it? [08:53] jelmer: im kinda missing how i should store objects i created in a dulwich repo, any hints on what im missing? [08:55] ah, found my issue [08:55] searched the wrong file for that === sabdfl1 is now known as sabdfl [10:09] lifeless: did you go to jkakar's commandant talk? === Kissaki^0ff is now known as Kissaki [10:59] How do I throw out all the changes in my current working directory? i.e. rebase on current HEAD. [11:00] balor: ..."bzr revert"? [11:01] Peng_: thanks [11:01] Oh, good. [12:20] I've written an init script for bzr server. Should I submit a patch to bzr or should I just put it in the debian package? === abentley1 is now known as abentley === mrevell is now known as mrevell-lunch [13:24] I [13:25] *I'm trying to setup bzr over svn with bzr-svn, and thought the process was to make a new folder and use bzr-svn import --trees into the new location. But I accidentally did "bzr init" not in the new folder, but in the current svn one. [13:25] the svn repository is huge and it's doing "something" - is that something wrong and should I cancel? === mrevell-lunch is now known as mrevell [13:32] vadi2, hi [13:32] vadi2, init in the svn one? [13:32] vadi2, doesn't sound like what you'd want [13:32] yeah, after a long while it gave "bzr: ERROR: Already a branch: "."." [13:33] But I'm having a problem getting it to import into my proper folder now though [13:33] http://paste.pocoo.org/show/120769/ [13:34] vadi2, You're importing from a svn repo into a svn repo? [13:34] why's that [13:35] I did "bzr init" in yorba3 folder [13:35] vadi2: That creates a branch, not a repository [13:35] vadi2: A svn repository contains multiple branches [13:35] you don't need to run "bzr init" before svn-import [13:36] What would be the proper way? [13:36] vadi2, don't running anything at all [13:36] just "bzr svn-import yorba yorba3" [13:37] or "bzr svn-import --trees yorba yorba3" if you want working trees === beuno_ is now known as beuno [13:37] Sorry. What folder to run that in? [13:38] http://paste.pocoo.org/show/120770/ [13:38] vadi2, I think you may have a incomplete .bzr directory in Programs/ ? [13:38] It should be run in Programs, ideally yorba3 should not exist yet [13:39] no, don't have a .bzr in Program [13:39] *s [13:39] going to try deleting yorba3 [13:40] "No repository present: "file:///home/vadi/Programs/"" :/ [13:40] I'm using the stock jaunty version of bzr-svn though, not the ppa one because bzr-gtk breaks [13:41] maybe try in a different directory [13:41] e.g. bzr svn-import /path/to/yorba /tmp/yorba3 [13:42] $ bzr svn-import --trees /home/vadi/Programs/yorba /tmp/yorba3 [13:42] bzr: ERROR: No repository present: "file:///home/vadi/Programs/" [13:42]