[00:00] <lifeless> that would permit doing what you wanted, no ?
[00:01] <lifeless> mwhudson: ^
[00:01] <mwhudson> lifeless: that would be great, yes
[00:02] <mwhudson> (although it would be /srv/bazaar.launchpad.net/production-logs/bzr-$time-$pid.log or something for us i guess)
[00:02] <lifeless> wel sure
[00:02] <lifeless> I wouldn't care at that point :P
[00:03] <lifeless> ok, nose down on this patch
[00:04] <poolie> jam, still here?
[00:04] <poolie> hi lifeless, mwhudson
[00:04] <lifeless> hi poolie
[00:07] <mwhudson> hello poolie
[00:24] <spiv> lifeless, mwhudson: for lp, including $lpuser in the filename would be ideal
[00:24] <spiv> Well, maybe.
[00:24] <mwhudson> spiv: it would be in the command line arguments that are logged to the file, would that be enough?
[00:24] <spiv> Harder to do, though.
[00:24] <spiv> mwhudson: yeah
[00:25] <lifeless> I think the criteria are:
[00:25] <lifeless>  - unique file name
[00:25] <spiv> If I'm e.g. debugging a user issue from IRC, or just testing something myself, I'm more likely to know the lpuser name than the pid or exact timestamp on the server.
[00:25] <lifeless>  - easy to do date trimming
[00:26] <lifeless> spiv: right, but thats l osa ping to get it rsynced immediately anyway
[00:26] <spiv> If I can grep for the username from a bunch of log files, then that's adequate, but not ideal.
[00:26] <lifeless> well
[00:26] <lifeless> step 1) do the core
[00:27] <mwhudson> spiv: it would be user id anyway
[00:27] <spiv> mwhudson: heh, ok
[00:28] <mwhudson> another option is to have the lpserve plugin change the log file
[00:28] <spiv> mwhudson: that's ok for me, I think I know my user id ;)
[00:28] <mwhudson> i don't know how fixed it is by the time the run() method gets control
[00:39] <spiv> Hmm, the classic "want to start logging as soon as the code starts, but can't actually log to a file until we have read the config" problem.
[00:39] <lifeless> spiv: oh, are you looking into this?
[00:40] <spiv> lifeless: no, just musing
[00:41] <poolie> so this remember_remote bug - should we mark this as a dupe and then create a SRU bug against 2.1?
[00:41] <spiv> lifeless: the "lpserve command might like to inform where logging goes" just struck me as another instance of that general issue.
[00:41] <lifeless> poolie: its a bug in ubuntu, not in upstream, so nothing to dup it against;
[00:41] <lifeless> poolie: we can use it for the SRU when 2.1.2 is released
[00:41] <spiv> I'm not sure if marking as a dupe has much practical benefit.
[00:42] <poolie> isn't it the same bug as 528041?
[00:42] <lifeless> bug 528041
[00:42] <poolie> this seems like just an Ubuntu task on that bug
[00:42] <lifeless> we could, but I think it would just add noise to the closed bug
[00:46] <lifeless> with an upstream bug it would reduce the bugs found in searches etc, but it won't do that here because the other task will stay open, but doesn't influence results in searches on /b zr
[00:56] <lifeless> ok, bbiab
[01:58] <igc> hi all
[02:03] <mgz> hey.
[02:03] <mgz> ...a sign I should be asleep
[02:04] <spiv> Heh.
[02:53]  * igc lunch
[03:36] <echo-area> spiv: I finally solved the problem using bzr-svn.  It was because the subversion client I used did not support http protocol
[03:40] <spiv> echo-area: huh, weird
[04:57] <thumper> poolie: bug 585126
[04:57] <poolie> hi
[04:57] <thumper> poolie: I'm trying to get more info
[04:58] <thumper> poolie: but since this process just calls into bzr
[04:58] <thumper> well, bzrlib
[04:58] <thumper> I'm guessing there is some memory issues
[04:58] <poolie> ok
[04:58] <thumper> I was going to add a bzr tag
[04:58] <thumper> not tag
[04:58] <thumper> task
[04:58] <thumper> but wanted more info first
[04:59] <poolie> ok i'm just trying to help with loggerhead first
[05:09] <lifeless> back for the afternoon shift ;)
[06:07] <bialix> hi igc
[06:17] <igc> hi bialix!
[06:18] <bialix> hi :-)
[06:18] <bialix> I always was curious about what is going on on the sprints. so this time I've written too much detailed report. I hope you like it
[06:25] <lifeless> in principle I can suspend and resume now
[06:26] <spiv> lifeless: That must be very handy, in principle.
[06:53]  * igc bbiab
[06:55] <echo-area> I see this in branch.conf after execute bzr join: submit_branch = file:///home/xgp/rank/trunk
[06:55] <echo-area> does this mean when I do bzr ci, the repository in file:///home/xgp/rank/trunk will also be updated?
[06:56] <lifeless> no
[06:56] <lifeless> it has to do with the 'bzr submit' command
[06:56] <lifeless> you can read about it in bzr help configuration
[06:57] <StevenK> I'm having trouble with bzrlib.transport -- it's a contrived example, but I'd like to connect, cd and then disconnect. I then check if the directory was created out-of-band, but I can't get that working by itself -- if I put in a few mkdir calls, it works.
[06:57] <echo-area> which plugin does submit belong to?  There seems no such command by default
[06:57] <StevenK> echo-area: pqm, I think
[07:01] <lifeless> sorry
[07:01] <lifeless> 'send'
[07:02] <lifeless> StevenK: so, transports don't 'cd'
[07:02] <lifeless> StevenK: ever
[07:02] <lifeless> if a protocol requires a cd operation, it will do that transparently as needed
[07:02] <lifeless> whats the protocol you are testing?
[07:02] <poolie> lifeless, is work on fetch performance still ongoing or is that now done?
[07:03] <lifeless> poolie: ongoing, network fetch is highly problematic
[07:03] <lifeless> I was talking with John about it this morning
[07:03] <lifeless> oh, about 5am your time
[07:03] <poolie> lifeless, http://sourcefrog.net/tmp/1w/kanban.png
[07:03] <poolie> i'm going to try keeping this up to date
[07:03] <StevenK> lifeless: Both FTP and SFTP
[07:04] <poolie> so is it still an active task, or just something we need to come back to as an ongoing issue?
[07:04] <lifeless> poolie: current critical bug
[07:04] <lifeless> which is approximately equal to 'active task'
[07:05] <echo-area> lifeless: ah I see, it is used as a position to be compared with
[07:05] <echo-area> StevenK: thanks
[07:05] <lifeless> poolie: I think you should add to the udd thing a 'dsc-import branch to loom converter'
[07:05] <lifeless> which spiv was interested in doing
[07:05] <poolie> as something we're working on now, or something we want to do?
[07:05] <lifeless> but I think its currently behind the sigwinch fallout
[07:06] <lifeless> and addressing network clone
[07:06] <lifeless> which is for udd too
[07:06] <lifeless> because initial clone is what they hit a lot
[07:06] <poolie> spiv, i agree, news merge is most interesting as an example of writing generic hooks
[07:07] <lifeless> poolie: I think there is a lower bound of branch size we should track in kanban; I'm not sure where that bound is.
[07:07] <lifeless> I mention that because of the sigwinch task; I feel its kindof close to the boundary
[07:07] <spiv> It's a bit of a question of "if we build it will they come", but so far there's just the debian/changelog hook and that seems to be Good Enough for current purposes.
[07:08] <poolie> lifeless, i agree on both points :)
[07:08] <lifeless> \o/
[07:08] <lifeless> now
[07:08] <lifeless> I need to do the I'm great review
[07:08] <lifeless> and then tickets
[07:08] <poolie> i plan to grope around until i find something that feels about right
[07:08] <lifeless> and *then* I get back into stuff
[07:08] <poolie> so are there any updates i should make for you?
[07:09] <lifeless> well this week is patch pilot
[07:09] <lifeless> I think thats kanban noteworthy
[07:09] <poolie> it's on there
[07:09] <lifeless> even though its roughly steadystate
[07:09] <lifeless> oh sorry, perhaps I should look and thing, not just engage fingers
[07:09] <poolie> i think we can get a couple of things out of this
[07:09] <poolie> np :)
[07:09] <poolie> one is making sure we don't unintentionally stall things
[07:10] <poolie> and the flip side also, which is not taking on too many things at once
[07:10] <poolie> the tool is a bit slow
[07:10] <poolie> and clumsy
[07:10] <poolie> so i'm not 100% sure it's worth mantaining, but it might be
[07:13] <lifeless> so this week I'm
[07:13] <lifeless> pp
[07:13] <lifeless> hopefully landing a spike I spent the weekend on to review stuff locally - process improvement for pp for any bzr+lp project
[07:14] <lifeless> reviewing/discussion test stuff with you - that spike has some factory objects for us to discuss how it feels
[07:14] <lifeless> beyond that its network performance
[07:14] <poolie> fixture factories?
[07:14] <poolie> i was thinking about that
[07:14] <lifeless> yeah
[07:14] <lifeless> just in the launchpad plugin
[07:14] <poolie> perhaps i will try to do it first by documenting the pattern and adding any hooks just in testtools
[07:14] <lifeless> for testing launchpadlib using code
[07:15] <lifeless> oh
[07:15] <lifeless> and waiting for the NZD to fall again
[07:15] <poolie> unlikely
[07:15] <poolie> imo
[07:15] <lifeless> heh
[07:15] <poolie> well, compared to aud, or something else?
[07:16] <lifeless> aud
[07:16] <lifeless> its much higher than usual
[07:16] <poolie> i wonder
[07:16] <lifeless> shrug
[07:16] <StevenK> lifeless: Like I said, it was a contrived example.
[07:16] <poolie> i think both au and nz look good compared to other places atm, and au just had the super profits tax
[07:16] <lifeless> StevenK: sorry, was checking code and poolie distracted me :)
[07:17] <lifeless> StevenK: in FTP, stat triggers a chdir
[07:17] <lifeless> StevenK: because thats how we check if its a dir - yes, sad but true.
[07:18] <lifeless> StevenK: is it chdir you specifically need to receieve on the backend server? What if someone doesn't chdir but just writes to 'thedir/afile'
[07:18] <StevenK> lifeless: So, this is a test for poppy -- it's a explicit test to see that CWD (ie, the FTP command) creates the directory.
[07:19] <lifeless> ok, in bzrlib, do stat(thedir)
[07:19] <lifeless> that will do a chdir
[07:19] <lifeless> fot FTP
[07:19] <lifeless> I'm checking SFTP protocol now
[07:20] <StevenK> So transport.stat() ?
[07:20] <lifeless> yes
[07:20] <lifeless> see line 69 in bzrlib/transport/ftp/__init__.py for the gore
[07:21] <StevenK> I'm not sure I want to. :-)
[07:21] <lifeless> SFTP does not have a CWD
[07:22] <lifeless> so I don't know how you'll write that test for sftp :)
[07:23] <StevenK> I just got IOError for SFTP
[07:23] <StevenK> Which, given what you just said, is expected
[07:23] <StevenK> lifeless: However, it does work great with FTP
[07:25] <lifeless> SFTP has REALPATH and the client uses absolute paths for everything
[07:25] <lifeless> http://tools.ietf.org/html/draft-ietf-secsh-filexfer-13
[07:25] <lifeless> section 8.9.1
[07:27] <StevenK> Well, ... bugger
[07:28] <spiv> StevenK: perhaps this is a silly question, but if you are testing FTP behaviours directly perhaps you should use ftplib directly?  (Perhaps in addition to a test that "bzrtransport.put_bytes('somedir/foo', 'bytes')" triggers the auto-creation of 'somedir' in your server, if that's what this aiming to achieve?)
[07:29] <lifeless> StevenK: what I'm interested in is why you care that 'cwd' makes the directory
[07:29] <lifeless> StevenK: because in FTP its possible - and efficient clients do this - to not cwd *at all*
[07:30] <lifeless> I would expect one of two things here
[07:30] <lifeless> a) client X needs to work and it cd's
[07:30] <lifeless> b) I've put the mkdir code behind the cwd trigger and ... oops
[07:31] <lifeless> if its A, I'd say you want *a* smoke test for it, because even if you rearrange things you want to be sure it still works
[07:31] <lifeless> if its B, I think the code is likely in the wrong place, and you really want to trigger it on all of cwd / put / list where that dir is included
[07:32] <StevenK> spiv: The tests in question did use ftplib, I'm changing it to test both FTP and SFTP, and would like to use the same test code.
[07:34] <spiv> StevenK: hmm, well given that neither SFTP or bzrlib.transport has the concept of chdir, it seems you need to rethink the constraints.
[07:35] <lifeless> I'd reuse the same test code for things that are common
[07:35] <StevenK> Yes, I'm thinking so. Given I create missing directories in the chain before mkdir and openFile, it should be fine ...
[07:36] <lifeless> your backend could just do 't.create_prefix
[07:36] <lifeless> ()' :)
[07:36] <StevenK> And, as you say, SFTP doesn't even have the concept of it
[07:36] <spiv> If you decide that what you want is to support automatically creating the directory on any sort of access, then perhaps changing the specific operation you use in the test from chdir to stat/mkdir/open would do.
[07:37] <lifeless> silly question
[07:37] <lifeless> but why isn't it the same code for both sftp and ftp ?
[07:37] <lifeless> single daemon, per-protocol glue back to a common engine ?
[07:37] <StevenK> lifeless: As in, server-side?
[07:37] <lifeless> yes
[07:37] <spiv> I think lifeless's remark about "reuse the same test code for things that are common" is key, all you have to do is redefine what you're doing to make as much as possible common ;)
[07:38] <lifeless> then you'd not need to care about all this details
[07:38] <StevenK> lifeless: Because I didn't want to rewrite poppy
[07:38] <lifeless> isn't poppy hugely unreliable ? :)
[07:38] <StevenK> And bigjools said not to :-)
[07:38] <lifeless> I think that that may be a mistake, unless you're turning FTP off in 6 months
[07:40] <StevenK> lifeless: I'm not sure what the timeline is.
[07:43] <lifeless> if its not trivially short
[07:43] <lifeless> you're going to be maintaining dual stacks
[07:43] <lifeless> that is rather painful. Just saying.
[07:44] <StevenK> Actually, I've got the SFTP code hooking into much of the guts of the FTP support code
[07:44] <StevenK> But yes, I agree
[07:44] <lifeless> *I* don't need to maintain it, though I may need to let you cry on my shoulder.
[08:03] <vila> hmm, looks like I didn't say hi... Hello bzr world !
[08:03] <poolie> hello vila
[08:30] <GaryvdM> Hi vila
[08:30] <GaryvdM> I fixed some bugs with annotate_find, and merged it in to trunk.
[08:30] <GaryvdM> One bug I could not reproduce, is that you could not type numbers in the goto line text box.
[08:30] <GaryvdM> http://irclogs.ubuntu.com/2010/03/17/%23bzr.txt
[08:30] <GaryvdM> vila: Please let me know if that still affects you.
[08:38] <vila> GaryvdM: great ! I will switch my qbzr branch back to trunk and let you know
[08:38] <GaryvdM> vila: Thanks
[08:38] <vila> GaryvdM: indeed, can't type numbers :-/
[08:40] <vila> GaryvdM: can't type anything for that matter...
[08:40] <vila> GaryvdM: well, except return which gives me a traceback with: ValueError: invalid literal for int() with base 10: '', but that's expected I suspect
[08:42] <GaryvdM> vila: Ok - I'm using a qt class to make sure that you can only type numbers in. I'll reimplement my own
[09:16] <igc> night all
[09:21] <GaryvdM> vila: Please could you run this and tell me what it outputs: http://paste.ubuntu.com/439248/
[09:24] <vila> GaryvdM: Acceptable
[09:25] <vila> GaryvdM: but why do you need *me* to test it ? Suspecting a weird qt version ?
[09:26] <GaryvdM> vila: yes - You are the only person that experiences the bug
[09:26] <GaryvdM> vila: Thanks
[09:27] <GaryvdM> the only person that I know of...
[09:28] <vila> ok, it may come from my X/keyboard combo though...
[09:28] <vila> GaryvdM: Is there a way to echo the characters typed on the console ?
[09:30] <GaryvdM> vila: Yes - I'm going to write another example.
[09:46] <GaryvdM> vila: http://paste.ubuntu.com/439258/
[09:47] <vila> GaryvdM: http://paste.ubuntu.com/439261/
[09:48] <GaryvdM> vila: Thanks
[09:50] <GaryvdM> vila: for me: http://paste.ubuntu.com/439262/
[09:50] <poolie> ok so that was pretty fun, but now that's enough
[09:50] <poolie> good night all
[09:50] <vila> g'night poolie
[09:50] <GaryvdM> Night poolie
[09:51] <vila> GaryvdM: weird
[09:55] <GaryvdM> Hey bialix
[09:55] <bialix> hey Gary!
[09:55] <vila> bialix: das vidania Sacha
[09:55] <vila> (not sure about spelling...)
[09:55] <bialix> da svadanya
[09:55] <bialix> da svidanya
[09:55] <bialix> vila: you left us?
[09:56]  * bialix even does not have a chance to say bonjour
[09:56] <vila> bialix: rats, spelling and meaning wrong, I thought it was hello :)
[09:56] <bialix> then: privet
[09:56] <bialix> vila: ring a bell!
[09:56]  * vila had to check with Valentine :)
[09:56] <vila> bialix: :-P
[09:57] <bialix> GaryvdM: how's your mac?
[09:58] <bialix> ;-)
[09:58] <GaryvdM> Non existent. I need to ping poolie
[09:59] <GaryvdM> bialix: I'm not sure what the process would be.
[09:59] <lifeless> GaryvdM: neither are we
[09:59] <lifeless> but we can figure it out
[09:59] <lifeless> email him
[09:59] <GaryvdM> lifeless: Ok
[10:10] <lifeless> GaryvdM: 20 hours to the crabatron for me :>
[10:11] <bialix> crabatron??? %-/
[10:11] <lifeless> the flash game jam introduced us to, in facebook
[10:18] <GaryvdM> bialix: backyard monsters
[10:19]  * bialix nods
[10:19] <GaryvdM> bialix: I'll invite you - but proceed with caution - highly addictive
[10:19] <bialix> no, thanks!
[10:19] <GaryvdM> ok
[10:37] <GaryvdM> vila: Please will you try http://paste.ubuntu.com/439276/
[10:37] <GaryvdM> vila: No output, please just check behavior.
[10:38] <vila> GaryvdM: works fine, output nothing :)
[10:38] <GaryvdM> vila: Great - Thanks
[10:39] <vila> GaryvdM: by the way, avoid variable names that are also basic python types (str)
[10:39] <GaryvdM> vila: Ah - thanks - good point
[10:40] <vila> GaryvdM: so you found a workaround, but do you understand what was happening ?
[10:40] <vila> just curious
[10:40] <GaryvdM> vila: no
[10:47] <ricotz> hello, is there something like "git format-patch"? Which does "bzr diff -r1320..1321 > ...diff" automatically for multiple revision starting with a specified one?
[10:55] <MvG> lifeless: Wrt https://code.launchpad.net/~gagern/bzr/bash_completion-ExecutableFeature/+merge/24951 is http://paste.ubuntu.com/439278/ more to your taste?
[10:59] <GaryvdM> ricotz: maybe bzr bundle. It's not what you are asking for, but may solve you problem.
[11:00] <GaryvdM> *your
[11:02] <lifeless> MvG: yes. I'd still just make path an attribute, I don't see where you depend on the None value
[11:03] <MvG> lifeless: I don't depend on the None value, but as I wrote, I want to impose no order constraints.
[11:03] <lifeless> MvG: but there *is* one
[11:04] <MvG> lifeless: In other words, it should be OK to first save the path in a local var, and then check the feature, and then use the path.
[11:04] <lifeless> you don't need to impose it, it exists a priori
[11:04] <ricotz> GaryvdM, i need a plain diff for every commit, i think this doesnt do it
[11:04] <MvG> lifeless: But the property ensures the check gets performed before a path is returned.
[11:04] <lifeless> I'm totally confused
[11:04] <lifeless> why would someone save the path in a variable
[11:04] <MvG> Why not?
[11:04] <lifeless> why
[11:05] <lifeless> gnar gnar gnar :P
[11:05] <GaryvdM> ricotz: Ok - I don't think we have something like that. You could script it.
[11:05] <ricotz> GaryvdM, yeah i wanted to avoid that ;-)
[11:05] <lifeless> MvG: I think its ok to land in this form. I'm saying though that I think its still more complex than needed due to how we use features
[11:06] <lifeless> MvG: it is ok for us to disagree
[11:06] <MvG> lifeless: I don't think it is too complex to understand, and it ensures that nobody will have to worry about the internals to use this thing, even if people do crazy stuff like save the path in a local var.
[11:06] <lifeless> the use of _probe has made me happy
[11:07] <lifeless> IME you can tie yourself in knots catching crazy stuff that never happens ;)
[11:07] <GaryvdM> ricotz: "bzr log -r-2..-1 -p" is close, but includes the revision info above each diff.
[11:07] <MvG> OK, then I'll commit and push, so you can approve, and we can get this merged one day.
[11:08] <lifeless> oh
[11:08] <lifeless> one more thing
[11:08] <lifeless> def path(self):
[11:08] <lifeless>     self.available()
[11:08] <lifeless>     return self._path
[11:08] <lifeless> self._path is inited to None
[11:08] <MvG> If you prefer.
[11:08] <lifeless> just a thought
[11:08] <lifeless> less code
[11:08] <lifeless> up to you
[11:09] <ricotz> GaryvdM, thanks, i will make a script
[11:09] <lifeless> doesn't seem much point initing self._path if you're going to never access it until after _probe
[11:10] <lifeless> I may be overanalysing :P
[11:11] <MvG> lifeless: pushed.
[11:43] <idnar> bzr info is telling me "ERROR: No repository present"
[11:43] <idnar> has my branch gotten corrupted or something?
[11:44] <idnar> oh, nevermind, I think I know what happened
[12:09] <MvG> lifeless: Do you want to approve https://code.launchpad.net/~gagern/bzr/bash_completion-ExecutableFeature/+merge/24951 ?
[12:14] <lifeless> MvG: bb:tweak
[12:15] <MvG> lifeless: Tweaking already. I assume the same holds for bash_feature.
[12:16] <lifeless> naturally
[12:44] <ia> hello. could anyone tell me, please, does exist some way to edit text of (not last) commit, which has been done?
[12:53] <maxb> Not without rewriting all history after the point of the change
[12:53] <maxb> So mostly, "no"
[13:04] <GaryvdM> vila: qannotate find bug fixed in trunk :-)
[13:04] <GaryvdM> sorry goto line
[13:04] <vila> GaryvdM: yeah !
[13:04] <vila> GaryvdM: I understood :)
[13:22] <MvG> lifeless: Tweak pushed and ready for approval. :-)
[13:40] <bialix> GaryvdM: is it intended change in qbzr that throbber now shown in the middle of the window and without label "Loading"?
[13:45] <GaryvdM> bialix: No.
[13:45] <GaryvdM> bialix: I fixed that a little while ago :-)
[13:46] <bialix> hmm, I've just updated to latest revno in trunk and its gone, or... lemme check
[13:47] <bialix> it seems ok now
[13:47] <GaryvdM> bialix: rev 1268 broke it, rev 1270 fixed
[13:48] <GaryvdM> Specifically 1166.1.14
[13:48] <bialix> yep, I had 1269, and just updated to 1270. ok, thanks!
[14:14] <GaryvdM> bialix: bug 485236 fixed \o/
[14:15] <bialix> aaaa! \o/ -o- \o/
[14:15] <bialix> cool!
[14:18] <GaryvdM> bialix: are you working on bug 485236 or can I tackle it?
[14:18] <GaryvdM> sorry Bug 585309
[14:18] <bialix> oh
[14:18] <bialix> anyway
[14:18] <bialix> cool
[14:19] <GaryvdM> bialix: were you looking at it?
[14:20] <jam> lifeless, GaryvdM: 23hrs to D.A.V.E. :)
[14:20] <jam> morning all
[14:21] <GaryvdM> jam: Morning - I don't like the sound of that :-(
[14:21]  * GaryvdM upgrades towers....
[14:22] <jam> well, honestly I'm also goo capped (about 8.6M), so I need to start rampaging a bit :)
[14:22] <GaryvdM> lucky I'm under protection for another few days.
[14:23] <GaryvdM> lifeless and I may need to team up...
[14:24] <bialix> what it means: GaryvdM>	bialix: were you looking at it?
[14:24] <GaryvdM> bialix: Were you looking at (working on) Bug 585309
[14:25] <bialix> no, I'm not working on that bug
[14:26] <bialix> GaryvdM: you can tackle it. please!
[14:26] <GaryvdM> bialix: Ok - I'm going to takkle it. I want it for https://code.launchpad.net/~craighewetson/qbzr/qlog-revert-multi-tree/+merge/25724
[14:27] <GaryvdM> bialix: I was thinking we could do "path (nick)"
[14:28] <GaryvdM> bialix: "long path... (long nick...)"
[14:30] <GaryvdM> bialix: I wonder if I can see if the nick is explicitly set, or if it is getting it from the path.
[14:30] <bialix> I think we can use url schemes as well, so for local trunk and remote trunk we can show: file://trunk bzr://trunk
[14:31] <bialix> just an idea
[14:31] <bialix> do we really want to show a nick?
[14:31] <GaryvdM> biailx: If the nick is set - yes
[14:32]  * bialix shrugs
[14:32] <GaryvdM> bialix: re url schemes - I think it's too long - rather show the full url in the tooltip.
[14:33] <GaryvdM> bialix: So most of the time, you don't set the nick, but if you do, you want it to show.
[14:33] <bialix>  dunno
[14:35] <GaryvdM> jam: I was wondering if it would be possible to do char level annotate. (I'm dreaming up a gobby like app with bzr as the back end.)
[14:37] <jam> GaryvdM: certainly, the most common thing to do is to use line-level comparison, and then do char level / word level matching afterwards
[14:37] <jam> It isn't exposed via our internals, but it is *possible* to do.
[14:37] <GaryvdM> jam: ok - cool
[14:39] <jam> GaryvdM: I guess one of the big things is to determine how you would represent that information as a dataset
[14:39] <jam> having an annotation per char would be expensive
[14:39] <jam> but you could probably do something with annotation ranges, etc.
[14:39] <GaryvdM> jam: represent in memory, or represent to the user?
[14:40] <GaryvdM> oh nvm - in memory
[14:44] <jam> ultimately, probably both, but yeah, figuring out how to represent the info efficiently would be a reasonable starting point
[14:45] <jam> and then figuring out how to break up ranges, etc.
[14:45] <MTecknology> any ideas what would cause this error? bzr: ERROR: Permission denied: "/bidding_system/": [Errno 13] Permission denied: '/bidding_system/'
[14:48] <jam> MTecknology: you don't have perms on '/bigging_system' ?
[14:48] <jam> :)
[14:50] <MTecknology> jam: i checked the guys permission on the server and client... it's fine :S
[14:50] <jam> MTecknology: what command are you using, and can you run with -Derror to get a traceback?
[14:52] <MTecknology> jam: bzr branch bzr+ssh://user@user.code.kalliki.com/home/user/project/branch
[14:55] <jam> MTecknology: and 'bidding_system' isn't involved at all?
[14:55] <MTecknology> jam: s/branch/bidding_system/
[15:18] <GaryvdM> Is it possible to hide the log and tracebacks when runing selftest, and only see the exception message?
[15:19] <GaryvdM> I only want to see :
[15:19] <GaryvdM> AssertionError: not equal:
[15:19] <GaryvdM> a = 'a'
[15:19] <GaryvdM> b = 'b'
[15:22] <mgz> yup, go back to r4919 :)
[15:22] <GaryvdM> mgz: :-(
[15:23] <mgz> not sure if I've filed a testtools regression bug for that one yet
[15:23] <mgz> but yeah, now you get everything printed in full, twice
[15:25] <mgz> there's no easy way just to get the exception instance string either, as testtools throws away the context and just stores the full traceback
[15:26] <mgz> (it used to just be print str(exc_info[1]) basically)
[15:30] <GaryvdM> MTecknology: Have you checked that the user running the bzr server has permissions to the path?
[15:31] <GaryvdM> MTecknology: I'm not sure if that would affect it.
[15:31] <MTecknology> GaryvdM: ya, we all use the same user account (teams) - i m\told him to delete his local branch and he never got back to me so i'm assuming it's working now..
[15:31] <GaryvdM> ok
[15:32] <MTecknology> thanks
[15:37] <mgz> would be nice to throw prettier permission denied errors
[15:38] <mgz> on nix you could at least get the user/group/bits of the problem file or directory
[15:57]  * bialix waves on mgz
[15:58] <mgz> hey alexander!
[15:58] <mgz> ...I need to comment on your diff thread
[15:59] <mgz> have three or four things to catch up with, have been concentrating bzr time on finishing off one scary bug
[16:03] <mgz> ugh, if Robert wants me to add news to this old branch, I'm gonna have to merge trunk
[16:05] <mgz> meh, will do it later.
[16:07] <bialix> mgz: if you will use my nick bialix I'll get aggressive notifications from Chatzilla wen you talking to me ;-)
[16:08] <bialix> but I don't have such nice bell as vila. heh
[16:11] <vila> bialix: grr :)
[16:12] <mgz> ehhehee
[16:13] <GaryvdM> vila: lol
[16:37] <bialix> GaryvdM: I'm still want a cookie^W visible square for checkbox "Word wrap" in the new qannotate toolbar. I forgot: is it possible?
[16:41] <GaryvdM> bialix: That would be good. We could do that if the options show in a popup widget, and not a menu.
[16:41] <bialix> and what we should do for this? we talked about this "word wrap" at uds, but I don't remember conclusion
[16:46] <GaryvdM> bialix:  It may make more senses if the other things in the menu are actually menu items.
[16:47] <GaryvdM> I like the idea of it being a menu, because then on macs, we put it in the menu
[16:47] <GaryvdM> bialix^
[16:48] <bialix> I thought you have in mind to avoid menu on all platfroms
[16:48] <GaryvdM> bialix: macs are special...
[16:49] <bialix> grrr
[16:49] <GaryvdM> bialix: I just noticed that other apps have boxes for checkable menu items, so it must be possible.
[16:51] <GaryvdM> biailx: Please tell me if there are boxes next to the options in the view menu in chatzilla on windows
[16:55] <mgz> boxes? there's a space for ticks to go, but no box in view menus here
[17:01] <GaryvdM> mgz, bialix: I have boxes... http://imagebin.ca/view/FW5LTMT.html
[17:02]  * GaryvdM going to get food.
[17:02] <mgz> ugh, that white thing by Show Timestamps isn't right, surely?
[17:02] <GaryvdM> mgz: yes
[17:02] <GaryvdM> let me see how it is on other themes
[17:05] <GaryvdM> mgz, bialix: http://imagebin.ca/view/w5d20MMc.html
[17:05]  * GaryvdM really goes now :-)
[17:06] <mgz> okay, that way is less offensive to the eye
[17:17] <bialix> GaryvdM: no boxes on Windows
[17:17] <bialix> that's why I'm complaining
[17:19] <bialix> GaryvdM: http://imagebin.ca/view/62EWypp.html
[17:19] <bialix> it looks incomplete this way on Windows
[17:20] <bialix> you make me cry
[17:23]  * bialix going home in sadness
[17:23] <bialix> ~~~
[17:23] <GaryvdM> bailix:
[17:24] <GaryvdM> dam - just got back
[17:24] <mgz> you killed him!
[18:08] <cody-somerville> Why is the commit method undocumented? :P
[18:10] <james_w> it's not an important one
[18:10] <james_w> why would anyone ever want to commit?
[18:18] <cody-somerville> good point
[18:18] <cody-somerville> :P
[18:20] <cody-somerville> Using bzrlib, how can I set the committer field?
[18:33] <GaryvdM> cody-somerville: tree.commit('first  post', committer="Joe Soap <joe@acme.com>",
[18:33] <GaryvdM>                             authors=["Foo Baa <foo@example.com>"])
[18:33] <cody-somerville> cool.
[18:33] <cody-somerville> And how do I create a new remote branch to push to?
[18:40] <mgz> meh? launchpad doesn't like me specifying multiple reviewers in a merge proposal? I swear I did that before
[18:42] <mgz> I thought just comma seperating names in the reviewer input field worked...
[18:42] <cody-somerville> GaryvdM, I figured I could just open a remote branch that doesn't exist and then push a local branch to it but opening the non-existent remote branch results in a NotBranchError.
[18:48] <GaryvdM> cody-somerville: Looking at the code for push, you can use branch.create_clone_on_transport
[18:48] <cody-somerville> I was thinking the same thing but was hoping it was going to be easier then that as it appears I need to construct a transport and everything myself using that function.
[18:51] <james_w> cody-somerville: there's not really a convenience function for doing that
[18:59] <mgz> argh. interrupted a launchpad push, and it's now got a lingering lock. can I break lp server side locks and resume the push?
[19:00] <mgz> okay, seems to have worked, let's hope I didn't screw anything up too badly
[20:19] <LeoNerd> bzr: ERROR: Can't export tree to non-empty directory.   <== This is somewhat awkward. I want to  bzr export  to a directory that already contains, among other things, a debian/ subdirectory...
[20:19] <LeoNerd> Any useful workarounds?
[21:01] <jam> LeoNerd: export to an empty dir and then mv debian on top of it?
[21:01] <lifeless> moin
[21:02] <jam> lifeless: /wave
[21:07] <lifeless> wow the fb profile change is bold
[21:10] <mgz> lifeless: if I want to have a prelim look at my testtools branch, would you prefer a merge proposal saying "not ready, just want this looked at", or... being told on IRC?
[21:10] <lifeless> either
[21:10] <mgz> +you
[21:10] <lifeless> a merge proposal is harder to forget
[21:11] <lifeless> and there are other testtools committers - its not even 'my' project
[21:11] <mgz> I didn't jump on j lange about it at the sprint though, so you're a better bet for starts.
[21:11] <lifeless> sure; just saying my slight lean it towards a mp
[21:12] <mgz> will poke a bit more then submit.
[21:13] <lifeless> ok, time to bring my computer system in from the car :)
[21:14] <lifeless> got it picked up from the movers last night
[21:14] <mgz> I am currently imagining you sitting in your car with a long power extension lead
[21:15] <lifeless> lol
[21:15] <lifeless> no
[21:15] <lifeless> my monitor, home server, desktop workstation, wifi point, home gateway :- I hope.
[21:15] <lifeless> and printer
[21:15] <lifeless> I suspect they will have missed some bits and we'll get them in 3 months or so when we have bought a home
[22:13] <jam> lifeless: I see you are now out of starter protection, shame I still have 15hrs on D.A.V.E. :)
[22:13] <jam> care for a test of your defenses?
[22:22] <lifeless> jam: I have 8 minutes till I need to pop into a car and go look at a house
[22:22] <lifeless> so sure
[22:23] <lifeless> I've signed out
[22:26] <lifeless> jam: ^
[22:29] <lifeless> ok
[22:30] <lifeless> we're off, back in 3 hours more-or-less
[23:41] <jbowtie> OK, I branch into a new repository. The branch is interrupted. Is the repository recoverable, or do I need to delete and re-branch?
[23:41] <jelmer> jbowtie: the repository should be resumable
[23:41] <jbowtie> jelmer: How do I resume? Try the branch operation again, or is there a flag I should be passing/
[23:42] <jbowtie> ?
[23:42] <jbowtie> jelmer: I'm asking because I have a flaky connection to a large repository and branch operations frequently lose the connection before they finish.
[23:42] <beuno> jbowtie, I think you then start pulling in, instead of branching
[23:43] <beuno> if you do it in a shared repo, then branching may still work
[23:43] <beuno> maybe that's what you meant by "branching into a repostory"
[23:43] <beuno> it should save the incomming revisions as they come
[23:43] <beuno> and just ask the remaining ones on each branch/merge/pull
[23:44] <jbowtie> beuno: Well, no, I mean the repository gets created as a result of the branch operation.
[23:44] <beuno> right, so then you'd either have to pull
[23:44] <beuno> or, use a shared repo
[23:44] <beuno> at least AFAIK
[23:44] <beuno> pulling may or may not work
[23:45] <jbowtie> beuno: I'll give that a try. From memory it says there's no branch, just a repository.
[23:45] <beuno> yeah, that sounds possible
[23:45] <beuno> maybe jelmer knows other magic for that
[23:45] <jbowtie> What happens is that a repository is created, populated with revisions, then a branch gets created in the repository, then a working copy is produced on disk.
[23:46] <beuno> right
[23:46] <jbowtie> It's the "populated with revisions" step that gets interrupted when the connection goes down.
[23:46] <beuno> a shared repo is what you want
[23:46] <beuno> re-branching will resume
[23:47] <jbowtie> beuno: so if only 10 of 20 revisions have been populated, re-branching will pull down the other 10 revisions from the parent?
[23:48] <beuno> correct
[23:49] <jbowtie> beuno: All right, I'll give that a shot.
[23:49] <jbowtie> beuno: Writing foreign VCS plugins is hard. :)
[23:50] <beuno> jbowtie, jelmer wrote like 3 of them, we've all seen him suffer!
[23:50] <beuno> he's also the guy to talk to if you need help
[23:50] <beuno> he's super nice and super smart
[23:52] <jbowtie> Don't worry, I'll pester him as soon as I have the green light from legal to publish the source for my plugin.
[23:52] <jbowtie> Hard to get things right when you can't show people the source code yet.
[23:54] <beuno> jbowtie, may I as what foreign VCS this is?
[23:54] <jbowtie> Sure - I've been working on a Team Foundation Server plugin for the last few weeks.
[23:55] <jbowtie> I've got read-only access pretty much rock solid and been working on round-tripping the last week or so.
[23:55] <beuno> interesting
[23:55] <beuno> what prompted you to work on it?
[23:56] <jbowtie> I work for a company that mandates use of TFS. So I am doing an end run around the policy by writing a plugin so I can actually use Bazaar.
[23:57] <beuno> heh
[23:57] <beuno> smart man
[23:57] <beuno> I see a lot of people doing that with SVN
[23:58] <jbowtie> That's what prompted me to take that route. Spent a lot of time studying the bzr-svn and bzr-hg plugins.
[23:59] <jbowtie> Problem I'm seeing though is that sometimes I "lose" revisions if a pull from TFS gets interrupted - they don't show up in a "bzr missing" and aren't re-pulled.