=== jamesh__ is now known as jamesh [00:57] lifeless: shouldn't 192743 be reassigned to bzr? [00:58] jelmer: not sure; may want to wontfix it [01:12] New bug: #162970 in trac-bzr "bzr not reconized" [Undecided,Incomplete] https://launchpad.net/bugs/162970 [01:23] yay @ first stacked test passing. [01:27] lunch [01:29] lifeless: congrats! [02:00] New bug: #192803 in bzr-svn "Presence of bzr-svn plugin causes BzrDir.find_branches to leak memory" [Undecided,New] https://launchpad.net/bugs/192803 [02:19] say, does anyone want to explain InterRepository._walk_to_common_revisions() to me? [02:19] mwhudson: sure [02:20] lifeless: specifically i want to understand when it raises errors.NoSuchRevision [02:20] mwhudson: it starts from a set of revisions and walks back the graph until it has found all the common points [02:20] (i'm trying to diagnose the InstallFailed oopses we're seeing, at least a little bit) [02:21] mwhudson: NoSuchRevision is raised when you ask for some revision R which is not in the target, nor in the source. [02:21] hmm [02:21] but here, revision_ids == [target.last_revision()] i think [02:22] right [02:22] so walking out from there to something that is not in the target seems a bit eccentric [02:22] not true [02:22] ok [02:22] target_branch.last_revision()==R does not always imply target_branch.repository.has_revision(R) [02:23] its invalid for it to fail to imply it [02:23] i mean, there could be ghosts, but that doesn't seem super-likely here [02:23] _walk_to_common is used when we're not looking for ghosts; but adjacent and absent revisions are collected [02:23] lifeless: sorry i don't understand your last line there [02:24] so we get local ghosts but not deep ghosts, if that makes sense [02:24] mwhudson: race conditions, quote the line [02:25] * mwhudson thinks [02:27] I have to switch battery sooin [02:27] lifeless: let me worry about another confusing problem for a bit then, can i bug you in 10-20 minutes? [02:27] sure [02:28] * lifeless does the suspend-resume dance [02:28] ta [02:39] back [02:40] mwhudson: -> code; will look back in every test or so [02:56] lifeless: so, i would like to understand "target_branch.last_revision()==R does not always imply target_branch.repository.has_revision(R)" [03:07] mwhudson: bzr init-repo foo [03:07] mwhudson: bzr init-repo bar [03:07] bzr init foo/branch [03:08] bzr commit -m 'f' foo/branch [03:08] cp -a foo/branch bar/branch [03:11] lifeless: oh right [03:11] lifeless: that shouldn't have happened on the supermirror though :) [03:13] mwhudson: who knows what has happened [03:13] mwhudson: but this is why the bzr code does what it does [03:27] mwhudson: what problem are thou incurring? [03:27] lifeless: occasionally the upload branch puller craps out with one of these exceptions [03:27] this is for importd? [03:27] (raising InstallFailed from InterPackFetcher) [03:27] lifeless: no [03:28] hosted branches? [03:28] lifeless: yes [03:28] does it recur on the same branch? [03:28] I saw a hosted branch the other day with this problem [03:28] no [03:28] someone had managed to set a last_revision_id not in the branch's repository [03:29] and it was (naturally) not mirroring; and other users (group branch) couldn't merge from the hosted side either [03:29] is it possibly a bug in the sftp or smart server glue ? [03:29] I'm assuming bzr is perfect [03:31] hi here too [03:31] lifeless: i was wondering that, but it seems a bit unlikely [03:31] hi BasicOSX [03:31] mwhudson: that bzr is perfect? [03:32] lifeless: no, that a bug in the smart server glue would show up in this way [03:33] mwhudson: I suggest that you change the puller so that the next time this occurs a cp -R of the branch is made [03:33] mwhudson: (of the source branch) [03:41] yeah, i guess that makes sense [03:41] jml: hello [03:42] mwhudson: hi [03:42] jml: what do you think of lifeless's idea above? [03:44] mwhudson: I think it will definitely help us figure out what's going on and that's it's kind of yucky. [03:45] but I can't think of anything better. [03:46] right === jamesh__ is now known as jamesh === asac_ is now known as asac === beuno changed the topic of #bzr to: http://bazaar-vcs.org/ | Bazaar 1.2 is out! w00t! | http://bazaar-vcs.org/releases/src/bzr-1.2.tar.gz [06:19] * beuno goes to bed now [07:53] Oh, cool. 1.2. === Peng_ is now known as Peng [09:41] New bug: #192859 in bzr "AttributeError on parent.children in add when adding a symlink" [Undecided,New] https://launchpad.net/bugs/192859 [11:33] hi! just transitioned to bzr from svn and I'm experiencing some problems. whenever I push an update to the server, there's a 70 % chance that the push just hangs and nothing happens. If i ctrl-c it, I get a SFTPError: Garbage package received. [11:33] Anything I can do on my end? [11:33] I mean, I get this almost ALL the time [11:33] but sftping in works fine every time [11:49] Using bzr+ssh seems to work better, but is there a way to store BZR_REMOTE_PATH for just one project? === mrevell is now known as mrevell-lunch [12:50] appcine: yes, you can set bzr_remote_path in your ~/.bazaar/locations.conf [12:50] appcine: e.g, I have: [12:51] [bzr+ssh://host/] [12:51] bzr_remote_path=/home/andrew/bzr.dev/bzr [12:51] in mine. (where "host" is something different, obviously...) [13:00] spiv: Ah, sweet. Thanks :) === aadis_ is now known as aadis === mrevell-lunch is now known as mrevell [13:21] Hmm, using bzr+ssh really didn't solve my woes. It's terrible slow to send a two-line change over two files. It just stalls on 0/0 (the dash that's spinning isn't .. spinning) [13:22] ssh/sftp works fine though [13:47] hey folks [13:47] will anyone request freeze exception for Bzr-1.2 ? [14:07] anybody works on netbeans plugin? [14:11] hsn_: there is nobody working on one, or at least they haven't publicly announced so [14:21] New bug: #192924 in bzr "quick-start-summary.svg missing in Python based installer for windows" [Undecided,New] https://launchpad.net/bugs/192924 [15:05] hmm, pushing my updates to the server is constantly crashing on me .. both bzr+ssh and scp.. the cursor just hangs on 0/0 and nothing happens. [15:05] I can't even control-c out of it when using bzr+ssh [15:06] The connection is established - I need to break-lock on the server to try again. Ssh and scp directly works like a charm [15:06] "TooManyConcurrentRequests: The medium '' has reached its concurrent request limit." [15:07] Is what I get when the push finally fails [15:07] (using ssh= [15:07] anything I can solve on my end? [15:15] appcine: Does .bzr.log on either the client or server say anything interesting? [15:16] appcine: Maybe the server kills processes that consume any resources. [15:20] Peng: nothing intresting on server, but "not updating child fraction" in my client's .. A LOT! :) [15:21] It's like it's spit into my bzr.log until my ctrl-c finally has any effect [15:23] Probably unrelated. That's to do with the progress bar updating, IIRC. [15:24] it works sometimes, sometimes it doesn't [15:34] hmm, is 1.2 released or not? The webpage says yes, the changelog says 1.2rc1 is still in development, and doc.b-v.org doesn't have a dir for it. [15:58] thatch: There are a couple debs up in the PPA. [16:04] Peng: I also see the tarball... however, there's no changelog entry for 1.2 actually being out :) [16:07] thatch: yeah the wiki has not been updated to point to the right changelog but 1.2 has been out for a few days [16:07] you can find the changelog in NEWS of the tarball [16:09] seriously. nothing i can further investigate to solve my stalling push problem? I can't work :P [16:34] jdong: here's the first real heading in NEWS of bzr.dev. [16:34] bzr 1.2rc1 (not released yet) [16:35] What about NEWS of bzr.1.2? [16:36] Peng: aha, it's in there. [16:37] so if https://launchpad.net/bzr/1.2/1.2/ also contains the changelog... why have an outdated changelog link on the front page of the wiki? [16:40] thatch, changed, thanks [16:43] beuno: great! [17:40] Hello all, I have an issue with the bzr eclipse plugin. Is someone using it? [17:41] BigMadWolf, sure, what seems to be the problem? [17:42] I think I have properly installed bzr-xmloutput and the bzr plugin for eclipse according to the documentation, but when I click on "Synchronize Bazaar" in Eclipse, I can't do anything. [17:43] I can only click on "Finish" and not on "Next", so nothing happens. [17:43] BigMadWolf, what OS are you on? [17:43] Ubuntu Gutsy [17:44] BigMadWolf, can you run: bzr plugins [17:44] in a terminal [17:44] just to see if bzr-xmloutput is correctly installed [17:45] jeremy@laptop-jeremy:~$ bzr plugins [17:45] /usr/lib/python2.5/site-packages/bzrlib/plugins/xmloutput [0.4.0] [17:45] This plugin provides xml output for status, log, annotate, missing, info, version and plugins [17:45] /usr/lib/python2.5/site-packages/bzrlib/plugins/multiparent.pyc [unknown] [17:45] Implementation of multiparent diffs for versionedfile-like storage [17:45] /usr/lib/python2.5/site-packages/bzrlib/plugins/launchpad [unknown] [17:45] Launchpad.net integration plugin for Bazaar. [17:45] yep, sounds ok [17:46] BigMadWolf, and you've got the branch in the top dir of the project? [17:47] hoho, I think the issue is solved... :o [17:48] I was clicking on windows-> open persepctive -> team then synchronize [17:48] but when I click on the root of my project, then team -> share project, it seems ok [17:50] I'm goin' to check if everything works well, I will let you know if it is okay [17:59] mmh, it sucks, I can't do any commit when clicking on $PROJECT -> Team [17:59] before doing that, I did "Share project" using the existing .bzr dir [18:02] do you know how can I remove the bzr support of my project in eclipse? [20:48] * fullermd thinks the format list in init-repo's help should be a little less... [20:51] well, it would seem that --metaweave should be hidden by now [20:51] and probably --weave [20:52] and maybe --knit [20:52] I might hide --rich-root for only --rich-root-pack [20:53] because if you are going for --rich-root you are incompatible with pre-packs anyway [20:53] "New in 0.15" should probably be "Since 0.15" :-) [20:53] jam: I think there was actually one release with one but not the other [20:54] jelmer: pff not enough for me to care [20:54] not right now anyway [20:54] And the help doesn't clarify that [20:55] hmmno, looks like I'm wrong [20:55] +1 on removing --rich-root [20:55] well, they both say "New in 1.0" [20:55] I think rich-root-pack was marked experimental longer [20:55] but that doesn't matter now [20:56] Well, not so much that. But rather than a lot of them don't make sense for init-repo. [20:56] is --rich-root-pack at the "safe to use as default for people who don't mind reporting bugs" stage? [20:56] Like --weave, which is totally impossible. And --dirstate and --dirstate-tags don't make any sense, since they're no different from --knit at the repo level. [20:56] yeah [20:57] --dirstate changes the WT, and --dirstate-tags changes the Branch [20:57] bob2: I think it is more stable than that, even [20:57] metaweave should be hidden all over, I'd say. [21:11] jam: actually, pulling into rich-root-pack from non-rich roots breaks inventory sha1's still. [21:11] I filed a bug. [21:11] Does that break just pull, or upgrade too? [21:16] afaik it doesn't actually break anything, it just has data which isn't strictly valid [21:16] but last I checked we never validated it [21:16] and that was true for -subtree as well [21:17] Verterok, check out logs, someone was here with all kinds of questions about bzr-eclipse [21:17] (and hi) [21:20] hi [21:20] beuno: thanks, I'll. [21:23] jam: check tries to validate it, but there is a bug in the API [21:23] * beuno -> out [21:25] jam: when the inventory sha doesn't match the inventory I consider it broken. [21:26] jam: its a bug that we don't check that always. [22:06] New bug: #177890 in bzr-svn "bzr-svn badly horks svn repository if pushing a changeset which includes a new symlink" [High,Fix released] https://launchpad.net/bugs/177890 [22:11] New bug: #160085 in bzr-svn (universe) "push over svn+ssh:// crashes" [Undecided,Fix released] https://launchpad.net/bugs/160085 [22:31] morning [22:43] good morning === cprov is now known as cprov-out [23:35] New bug: #193089 in bzr "UnicodeDecodeError exception in bzr whoami" [Undecided,New] https://launchpad.net/bugs/193089 [23:46] jam: ping [23:54] lifeless, i feel like we are having a "get it done" vs "done right" distinction [23:54] on plugins [23:55] poolie: to some degree; I feel there is a difference between 'doing part wrong' and 'getting it done'. [23:57] poolie: which is to say - I think we have agreed on 'get it done' up to a point [23:58] poolie: beyond that, I'm arguing against some particular things, because I think they will cause problems we don't have today. [23:58] and that we don't have to have.