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