[00:00] <phinze> right that makes sense; the behavior i describe above is what's confusing to me
[00:00] <lifeless> oh right
[00:00] <lifeless> so the reason that happens is this:
[00:00] <phinze> our entire testsuite spits out to stdout
[00:00] <phinze> if i'm not making any silly mistakes
[00:00] <lifeless> bzr+ssh invokes bzr on the server by doing 'ssh host bzr'
[00:00] <phinze> sure
[00:01] <lifeless> so the bzr on the server, when it writes to stdout, the local bzr gets that on the socket read fd
[00:01] <phinze> right that makes sense
[00:01] <lifeless> when something on the server writes to stderr, ssh cpatures that and sends it back to the client, where it goes to the ssh's std err
[00:01] <lifeless> which bzr hasn't redirected
[00:01] <phinze> ahh so it must be stderr that is making it through
[00:02] <phinze> so i might be able to exploit that behavior to get my testsuite output shown to the user? :)
[00:03] <lifeless> phinze: yes, as long as you don't start serving bzr+hhtp ;)
[00:03] <phinze> so basically add 2>&1 on the end of my commands and i'm right as rain
[00:04] <phinze> err
[00:04] <phinze> other way around
[00:05] <phinze> hah, beautiful
[00:05] <lifeless> phinze: I'm going to file a bug to capture this requirement
[00:05] <phinze> lifeless: you've been incredibly helpful, great explanations
[00:06] <lifeless> its one we deferred in getting streaming up
[00:06] <lifeless> and it would be lovely to have some sort of answer for bzr+http
[00:06] <lifeless> phinze: anytime
[00:06] <phinze> yeah an official way of handling this would be better
[00:07] <phinze> awesome; based off james_w's code i now have a 30 line "poor man's PQM"
[00:08] <james_w> phinze: perhaps the plugin should do that
[00:08] <phinze> james_w: where 'that' == the output redirection?
[00:09] <james_w> yeah
[00:10] <phinze> well it doesn't look like subprocess.Popen has a clear way of doing that
[00:10] <phinze> can't just set stdout=subprocess.STDERR (STDERR not defined)
[00:11] <phinze> stdout can be set to an int though
[00:11] <makiolo> bazaar is down ?
[00:11] <phinze>             elif isinstance(stderr, int): errwrite = msvcrt.get_osfhandle(stderr)
[00:12] <makiolo> can download ? bzr branch lp:wiithon i have timeout
[00:14] <phinze> makiolo: i branched that with no problems
[00:14] <makiolo> ok ...
[00:14] <makiolo> thx
[00:14] <phinze> sure
[00:16] <phinze> james_w: this works, but there must be a cleaner way? subprocess.call(command, cwd=export_dir, shell=True, stdout=2)
[00:16] <james_w> phinze: you can set stdout=suprocess.STDIN though
[00:16] <james_w> err
[00:16] <james_w> nonsense
[00:16] <james_w> you can set stderr=subprocess.STDOUT
[00:16] <james_w> which is what we want isn't it?
[00:17] <james_w> oh, no, I see now
[00:17] <phinze> james_w: no, re above discussion w/ lifeless... stdout is interpreted as server communication, but stderr makes it all the way through
[00:17] <lifeless> james_w: there isn't a way to send the data via bzr+ssh atm
[00:17] <james_w> phinze:
[00:18] <phinze> so stdout=STDERR is what i want... but is STDERR=2 set somewhere in python for me to reference?
[00:18] <james_w> so we want to write nothing on stdout?
[00:18] <james_w> and everything on stdin
[00:18] <phinze> as everything is working beautifully now with stdout=2... test suite runs; i see output; and if it passes, my push is accepted
[00:18] <james_w> that's possible, but it's a pain
[00:18] <phinze> s/stdin/sterr yes
[00:19] <phinze> sigh: STDERR
[00:19] <james_w> err, yeah, I don't know what's wrong with me tonight :-)
[00:19] <phinze> typing plague
[00:19] <james_w> redirect stderr -> stdout by calling with stderr=subprocess.STDOUT
[00:19] <james_w> so that both streams are interleaved as you want
[00:19] <james_w> then capture stdout
[00:20] <james_w> with stdout=subprocess.PIPE
[00:20] <phinze> right, but stdout is not sent across the wire currently; bzr+ssh offers no way of getting it though
[00:20] <james_w> so that stdout isn't sent and you don't get the failure
[00:20] <phinze> yeah i tried that but then i get no output on the terminal
[00:20] <james_w> then manually output stdout on stderr
[00:20] <phinze> i have no way of accessing subprocess.PIPE from my remote bzr client... so i get no output
[00:21] <james_w> by reading from proc.stdout and using "info" on each line
[00:21] <phinze> well then it would be all in one chunk wouldn't it?
[00:21] <james_w> or "warning" perhaps
[00:21] <james_w> both from bzrlib.trace
[00:21] <james_w> nope, you can read per-line
[00:21] <phinze> i like how it's working now because as the testsuite runs i see the output
[00:21] <james_w> for line in subprocess.stdout:
[00:21] <james_w>     trace.warning(line)
[00:21] <phinze> but i have to wait for subprocess.call to complete
[00:21] <james_w> retcode = subprocess.wait()
[00:22] <james_w> the other way would be to redirect both to a pipe, and then select on the two filehandles, and "info" the stdout, and "warning" the stderr, so that "commit -q" suppresses the normal output
[00:23] <phinze> ahh then use subprocess.Popen() rather than subprocess.call() ..?
[00:23] <james_w> your stdout=2 might be a simple way to do it, but I don't know if that would work on windows
[00:23] <james_w> yeah Popen
[00:23] <james_w> perhaps sys.stderr would be more robust than "2"
[00:23] <phinze> yeah you're thinking in terms of doing it the right way rather than my hacking things together :)
[00:24] <phinze> will sys.stderr be coerced into an integer?
[00:25] <phinze> suppose i can check
[00:25] <phinze> yes, yes it will
[00:26] <jam> phinze: sys.stderr.fileno() if you need it
[00:26] <jam> But Popen() already knows about fileno() for file objects
[00:26] <james_w> hi jam
[00:26] <jam> hi james_w
[00:27] <phinze> jam look what james_w gifted me: http://paste.ubuntu.com/155612/
[00:28] <jam> phinze: poor mans PQM, looks good
[00:29] <phinze> we're just cleaning up the input redirection
[00:29] <phinze> works with no redirection on local machine, but over bzr+ssh stdout of testsuite iinterpreted as smart server output over wire and barfs
[00:30] <phinze> can take advantage of the fact that stderr makes it all the way through because of ssh
[00:30] <lifeless> james_w: info on the server won't do the right thing
[00:30] <james_w> oh, of course not
[00:30] <jam> I thought there was a way to suppress stdin, etc
[00:30] <jam> but I don't see it specifically
[00:32] <jam> phinze: well, stdout *is* being redirected via ssh
[00:32] <jam> it just happens that we listed to the ssh stdout locally as bzr+ssh return values :)
[00:32] <jam> and don't directly listen to stderr
[00:32] <phinze> exactly, so it's a bit of a hack that pushing output through stderr happens to work :()
[00:32] <lifeless> using stderr today is your best bet
[00:32] <lifeless> I've filed a bug to enhance things to improve on that
[00:33] <phinze> lifeless: can you link?
[00:33] <jam> phinze: I would say that you could use 'close_fds' to force stdin to be closed
[00:33] <jam> however, that raises exceptions on windows (if you care)
[00:33] <phinze> jam: why do i care about stdin in this case?
[00:34] <jam> phinze: I would set it to "/dev/null" so that anything that wants input aborts immediately
[00:34] <jam> rather than hanging indefinitely
[00:34] <jam> I also see stuff like: http://paste.ubuntu.com/155618/
[00:35] <jam> so you may not really care about windows
[00:35] <phinze> ahh gotchya, because we're executing an arbitrarily specified command
[00:37]  * phinze indeed does not care about windows... but wouldn't mind supporting them if it's easy :)
[00:37] <lifeless> jam: stdin=PIPE; process.stdin.close() is better
[00:37] <jam> lifeless: sure
[00:37] <jam> I thought there was a way to do 'stdin=NULL'
[00:37] <jam> but I think stdin.close() is the best you can get
[00:38] <jam> phinze: for your case, it would mean using Popen() rather than .call()
[00:38] <jam> the other odd thing
[00:38] <jam> you can pass "stderr=subprocess.STDOUT"
[00:39] <jam> but there doesn't seem to be a "stdout=subprocess.STDERR"
[00:39] <jam> weird
[00:39] <phinze> yeah i know isn't it?
[00:39] <jam> as that is probably what you would want over sys.stderr
[00:39] <phinze> yeah i went down that same path
[00:39] <lifeless> jam: was my index building thoughts mail useful to you?
[00:40] <jam> lifeless: so I'm not sure that it is N log N, I have the feeling it is N*C where C is the number of entries in a single page
[00:41] <jam> I did like the info about how many keys we read, etc.
[00:41] <jam> as for checking 'late'
[00:41] <jam> I think we need to check as we go in at least the local dict
[00:42] <jam> and then we could check during the recombine step
[00:42] <lifeless> we currently check the local dict
[00:42] <jam> lifeless: right, we currently check both the local dict and the spilled
[00:42] <lifeless> jam: actually we don't
[00:42] <lifeless> jam: add_node checks self._keys, not the spilled indices
[00:43] <lifeless> jam: its definitely superlinear, N*C would be linear with a high constant
[00:43] <jam> lifeless: _insert_record_stream calls add_records() which calls _get_entries(keys)
[00:43] <jam> which goes through iter_entries(keys)
[00:43] <lifeless> I am quite sure its NlogN with a large down-scale factor
[00:43] <jam> Which *definitely* checks everything
[00:43] <phinze> jam: better? http://paste.ubuntu.com/155622/
[00:44] <lifeless> jam: yes, thats in how we use the index though, I'm talking specifically about the contract the index offers
[00:44] <jam> phinze: looks good to me
[00:44] <lifeless> jam: I think it would be ok if it *either* errors in add_node on dupes, *or* errors in finish on dupes
[00:44] <phinze> jam: danke :)
[00:45] <lifeless> jam: erroring *sometimes* in add_node and *sometimes* in finish, depending on whether the dupe has been paged out would be odd to work with and surprising for users of the index layer
[00:45] <jam> well, if you wanted to error always during finish
[00:46] <jam> you would have to check during add, and queue it for a later error
[00:46] <jam> since otherwise you are just doing dict[key] = value
[00:46] <jam> and it just overwrites the previous value
[00:50] <lifeless> jam: thats true. Ok, scratch that, erroring in both add_node and finish, depending on when the collision is found
[00:52] <SamB> jelmer: thanks for the help, btw
[00:53] <phinze> thanks all
[01:00]  * SamB wishes someone would bother to vote for http://bundlebuggy.aaronbentley.com/project/bzr/request/<E1LupWj-0005Cp-WD%40hydrogen> -- it just adds a sentence to an error message!
[01:10] <jfroy> jelmer: sorry that I pinged you and then dropped off the face of the earth. I've been debugging a kernel panic all day :p
[01:10] <SamB> jfroy: on real hardware?
[01:11] <jfroy> SamB: yeah, graphics drivers
[01:11] <jfroy> (my day job, etc. etc.)
[01:11] <SamB> not fun :-(
[01:11] <jfroy> loads of fun :p
[01:11] <SamB> well ... I don't find it fun to have to debug stuff like that running on real hardware ...
[01:11] <jfroy> Eh, it's OK with 2 computers
[01:11] <SamB> maybe if you have an ICE
[01:12] <SamB> or, okay, a kernel debugger
[01:12] <jfroy> yeah, using our kernel debugging facilities
[01:12] <jfroy> I haven't been able to resurrect a kernel yet though :p
[01:12] <jfroy> It's a feat only the masters know the secrets of :p
[01:18] <SamB> I can't even do that for DOS
[01:18] <fullermd> DOS can't even do it for DOS   :p
[01:18] <SamB> (not that it's worth bothering ;-)
[01:18] <SamB> (rebooting gives better results anyway ;-)
[01:19]  * SamB wonders if there are any kernel debuggers of the sort jfroy uses for DOS ...
[01:21] <fullermd> You don't need a kernel debugger for DOS.  It's, what, like 20 lines of code?  You find bugs by inspection.
[01:21] <lifeless> fullermd: you can get a lot in 20 lines of forth :)
[01:21] <SamB> fullermd: er, not the one I looked at!
[01:22] <SamB> of course, that one was written in C
[01:22] <fullermd> Well, maybe later versions are longer, after they added all those decadent extra features like directories...
[01:22] <lifeless> jam: is phinx @ the drizzle con?
[01:23] <SamB> fullermd: what's the point of using a DOS if it doesn't give you directories ... okay, sure, I suppose file names are nice ...
[01:23] <fullermd> Well, that was sorta my meta-point   ;)
[01:23] <SamB> but really, I have never in my life used DOS 1!
[01:23] <lifeless> original disks were too small to bother with directories
[01:23] <lifeless> waste of disk space
[01:24]  * SamB is still bothered by the fixed-size root dir in FAT
[01:25] <fullermd> Yeah.  Only so much room in 360k to put stuff.  Heck, I've got directories bigger than that now...
[01:28] <SamB> fullermd: you mean just the directory entries occupy more space than that, I assume ?
[01:31] <Peng_> I've got a 1,024,000k directory entry from when a program spammed my /tmp dir. :D
[01:32] <Peng_> Err, byte, not kilobyte, I suppose. :P
[01:33] <SamB> jelmer: shouldnsvn-set-revprops
[01:33] <SamB> er.
[01:33] <SamB> jelmer: shouldn't svn-set-revprops be in "bzr help svn"?
[01:55] <wgrant> SamB: Only FAT1[26] have a fixed root dir size.
[02:02] <SamB> wgrant: okay, sure. I was reading a book that didn't talk about any version of DOS more recent than 3.x, so ...
[02:03] <wgrant> SamB: Ah, that could do it.
[02:56] <lifeless> spiv: I'm still futzing around with refactoring the start of push
[02:56] <lifeless> its rather unsatisfying
[04:54] <lamalex> so i just pushed from a branch right into our trunk, instead of merging my branch and then pushing
[04:55] <lamalex> is there a way i can revert this?
[04:55] <jfroy> jelmer: I just had a thought.
[04:55] <jfroy> I am fairly certain I did an uncommit on the branch I am having trouble with.
[04:56] <jfroy> Could it be the root cause of the missing revision problem?
[04:59] <fullermd> lamalex: Find the rev that should be its head, and use push or pull to set it.
[05:00] <lamalex> fullermd: can you give me example syntax?
[05:01] <fullermd> lamalex: "cd $TRUNK ; bzr pull --overwrite -r$OLD_HEAD ."  or  "cd mybranch ; bzr push --overwrite -r$OLD_HEAD $TRUNK"
[05:02] <fullermd> Then set append_revisions_only in the $TRUNK/.bzr/branch/branch.conf to guardrail it a bit in the future   8-}
[05:03] <lamalex> :)
[05:06] <lamalex> fullermd: thank you!
[07:01] <lifeless> later folks
[07:59] <BasicOSX> lifeless made a funny on the mailing list :-)
[07:59] <lifeless> I did?
[08:00] <BasicOSX> response to my final vs rc3
[08:00] <BasicOSX> I don't think additional testing will make this bug more severe. :)
[08:00] <lifeless> right
[08:00] <BasicOSX> 2am that's funny to me for some reason
[08:00] <lifeless> :)
[08:00] <BasicOSX> ;-P
[08:00] <lifeless> it was ironic I guess
[08:57] <jelmer> jfroy: it shouldn't but I guess it could
[08:58] <jelmer> jfroy: did you push the original branch (from before the uncommit) anywhere?
[09:12] <jfroy> jelmer: urg sorry, just noticed your messages
[09:13] <jfroy> I don't remember if I pushed the branch to svn before doing the uncommit or after
[09:17] <jelmer> jfroy: so you didn't use anything like --overwrite when pushing?
[09:17] <jfroy> I don't believe so.
[09:41] <jfroy> jelmer: so in any case, if you need data to figure it out, just let me know.
[09:43] <jelmer> jfroy: Ok
[09:51] <SUPERSONICXX5> HOLAS
[09:52] <SUPERSONICXX5> ALGUIEN ME HECHA UNA MANO
[09:52] <SUPERSONICXX5> NO PUEDO ENTRAR EN NINGUN CHAT CASI, OPERA ME DICE QUE AHY UN ERROR CON UN DDL
[09:52] <SUPERSONICXX5> FIREFOX NO LOS CARGA
[09:52] <SUPERSONICXX5> GOOGLE CRHOME O COMO SEA VALE CALLAMPA
[09:53] <SUPERSONICXX5> Y EXPLORER ME SACA, DICE ID NO VALIDA
[09:53] <huf> are you for real?
[10:05] <LarstiQ> jelmer: no, the bzr-svn at the time I filed the bug, with recent improvements I hope it is all fixed now, but I'll let you know when I try again
[10:46] <jelmer> LarstiQ: I suspect so
[10:54] <fullermd> Furrfu.  Remember those wonderful days when everybody's on vacation and the list is silent?
[10:55] <LarstiQ> fullermd: I can't keep track anymore, at 1910 unread now :/
[10:56] <fullermd> However did we survive without 30 rounds of "No, see, it does XYZ."  "You're wrong, it does exactly what you said."  "Yes, that's my point, it does what I said."  "No, you're blowing FUD, it does exactly what you said."  [..........]
[10:57] <yogsototh> Hi all! What is the good way to handle this? make a modifications m1 and commit then a modification m2 and commit in branch B. How to push only modifications m2 on a branch A?
[10:57] <yogsototh> I already made the error not making an m2 branch
[10:58] <fullermd> In a strict sense, you can't.  The nearest you can do is cherrypick it over with merge.  There's no ancestral link behind that, though.
[10:58] <yogsototh> so bad! Thanks fullermd
[10:59] <LarstiQ> or well, rebase
[10:59] <fullermd> Or use a loom.  That's just like rebase, right?
[10:59] <LarstiQ> fullermd: tsk :P
[10:59]  * LarstiQ read part of that thread yesterday
[11:00] <fullermd> Did you read at least 2 mails of it?
[11:00] <LarstiQ> yes
[11:00] <fullermd> You pretty much read the whole thing then.
[11:01] <yogsototh> ok I'll look for that, thanks
[11:01] <fullermd> yogsototh: Cherrypicking with merge is almost certainly what you want.  In this case, rebase is probably just a really roundable way of doing exactly that.
[11:03] <yogsototh> I see, I can also play with bzr diff and bzr patch I suppose. Thanks
[11:04] <fullermd> That'll end up in the same place as the cherrypick.  Using merge will be a bit simpler.
[11:04] <yogsototh> Yep
[13:57] <ricardokirkner> guys.. I am trying to push to an svn repo , and I am getting a traceback
[13:57] <ricardokirkner> http://ricardokirkner.pastebin.com/d61d26395
[13:58] <ricardokirkner> can anyone help me figure out why this is happening?
[14:01] <lifeless> jelmer: ^ this one is for you
[14:01] <lifeless> jelmer: do you highlight on 'svn' yet?
[14:11] <sohmestra> how do I display the revid for a given revision? bzr log --verbose doesn't show it. I'm using bzr 1.13
[14:13] <LarstiQ> lifeless: I think he stopped
[14:13] <LarstiQ> ricardokirkner: are the bzr branch and svn repo public btw?
[14:14] <ricardokirkner> LarstiQ, no, sorry... they are internal to our company
[14:14] <LarstiQ> ricardokirkner: k
[14:14] <ricardokirkner> if you need any info, tell me and I will provide it if I can
[14:14] <LarstiQ> ricardokirkner: just enough to reproduce it :)
[14:15] <LarstiQ> ricardokirkner: are there merged revisions in what you are trying to push?
[14:15] <LarstiQ> ricardokirkner: what does bzr think the revno for the local bzr branch and what is in svn are?
[14:16] <ricardokirkner> LarstiQ, yes, there are merged revisions in there
[14:16] <jelmer> ricardokirkner: one sec
[14:16] <jelmer> ricardokirkner: please file a bug
[14:16] <ricardokirkner> jelmer, alright...
[14:18] <ricardokirkner> jelmer, bug on bzr, or bzr-svn?
[14:18] <jelmer> ricardokirkner: bzr-svn
[14:18] <jelmer> ricardokirkner: actually
[14:18] <ricardokirkner> right
[14:18] <jelmer> ricardokirkner: this is fixed in a recent version of bzr-svn
[14:19] <ricardokirkner> jelmer, the thing is 0.5.3 (what I am using) is the latest version compatible with bzr 1.13 (the latest release version of bzr)
[14:19] <ricardokirkner> for 0.6 I need 1.14
[14:19] <ricardokirkner> which is rc
[14:19] <ricardokirkner> should I post the bug anyway?
[14:19] <jelmer> ricardokirkner: 0.5.4 is for 1.14
[14:22] <ricardokirkner> jelmer, so, in order to avoid this issue I have to use bzr 1.14?
[14:23] <jelmer> ricardokirkner: Yes, it looks similar to a bug I fixed for 0.5.4
[14:24] <lifeless> sohmestra: log --show-ids
[14:24] <sohmestra> lifeless: thanks
[14:24] <ricardokirkner> mhhh... I'll try to test it using 1.14
[14:24] <ricardokirkner> and let you know
[14:24] <ricardokirkner> thx
[14:28] <jelmer> lifeless: no, I don't do svn highlights, it would be annoying for #svn-dev :-)
[14:37] <LarstiQ> ricardokirkner: I'd like to know if that fixes it for you too, it looks similar to something I have trouble reproducing but my colleagues run into from time to time.
[14:37] <phinze> so can bzr-email be used in a hook on a shared branch or is it only for client-based hooking
[14:37]  * phinze knows about bzr-hookless-email as well but is evaluating the options
[14:38] <LarstiQ> phinze: afaik, bzr-email will be used on a remote branch regardeless of client installs _if_ you are using the smartserver and have email configured for that branch
[14:38] <LarstiQ> phinze: but not if people use transports like sftp://
[14:39] <phinze> LarstiQ: cool; my group uses bzr+ssh so i think we should be good if i install it systemwide on the shared server then
[14:39] <ricardokirkner> LarstiQ, as soon as I finish testing I let you know
[14:39] <LarstiQ> ricardokirkner: thanks
[14:39] <LarstiQ> phinze: I admit to not knowing exactly how to configure it
[14:40] <LarstiQ> phinze: but branch.conf I'd think
[14:41] <phinze> LarstiQ: yeah that's my guess... i'll try it out
[14:41] <phinze> james_w: ping
[14:42] <james_w> hi phinze
[14:43] <phinze> hey, you interested in throwing bzr-testrunner out to the world?
[14:43] <james_w> sure
[14:43] <phinze> i'm not well versed in lp-fu, but i assume it wouldn't be too difficult?
[14:43] <james_w> maybe it should have a better name first though?
[14:43] <james_w> yeah, it's easy to set up a project for it
[14:44] <phinze> yeah i'm at a loss for names
[14:45] <phinze> bzr-sentinel, bzr-branchguard, bzr-guardian
[14:45] <phinze> thinking something more generic to imply that testsuite is not required but any command?
[14:45] <ricardokirkner> jelmer, LarstiQ no luck. I tried with 1.14rc2 and bzr-svn 0.5.4 and 0.6
[14:45] <ricardokirkner> and neither solves the push issue
[14:45] <jelmer> ricardokirkner: please file a bug
[14:45] <ricardokirkner> I do that now
[14:46] <jelmer> ricardokirkner:  thanks
[14:46] <james_w> bzr-canary
[14:47] <james_w> also, I'm not sure if the shell-hooks plugin makes it unnecessary
[14:49] <james_w> phinze: have you put it in a branch?
[14:58] <ricardokirkner> jelmer, the bug is https://bugs.launchpad.net/bzr-svn/+bug/365108
[14:58] <ricardokirkner> thanks for the support
[15:02] <ivan> why does switching branches and switching back crap all over my working tree?
[15:03] <ivan> http://rafb.net/p/tUZ9c479.html
[15:03] <ivan> maybe because the branch is old :(
[15:04] <ivan> and now that I switched back I have all these conflicts, http://rafb.net/p/bfiY8c60.html
[15:09] <phinze> james_w: just locally... latest version is http://paste.ubuntu.com/155933/
[15:09] <james_w> phinze: cool, thanks
[15:09] <james_w> phinze: bzr-testrunner seems to be the best name to me, what do you think?
[15:10] <phinze> yeah straightforward
[15:10]  * phinze looks at shell-hooks quickly
[15:12] <james_w> probably still useful to save every script having to implement the "checkout the tree" bit
[15:12] <james_w> and the redirection
[15:13] <phinze> yeah plus shell-hooks sends a bunch of arguments along
[15:13] <phinze> yeah i think it's still worthwhile to throw out there
[15:16] <james_w> phinze: https://launchpad.net/bzr-testrunner
[15:16] <james_w> please push your branch to lp:~bzr/bzr-testrunner/trunk
[15:20] <phinze> james_w: will do
[15:26] <Stavros> hello
[15:26] <Stavros> i am trying to merge from a diverged branch, how can i see the uncommited changes i had before the merge?
[15:27] <jelmer> ricardokirkner: do you have a way to reproduce this bug?
[15:33] <phinze> james_w: Paul Hinze is not a member of Bazaar Developers...
[15:35] <phinze> james_w: looking into https://launchpad.net/~bzr/+mentoring ... ~= "fix a bug to join the club"?
[15:36] <james_w> a new team for this plugin seems like overkill
[15:37] <phinze> i would hope to contribute enough to be considered for Bazaar Developers membership... but i have not yet
[15:37] <james_w> I could push the branch up, then merge your changes as needed until you are a member
[15:37] <james_w> how would that suit you?
[15:40] <phinze> james_w: works for me... lp:~phinze/+junk/bzr-testrunner
[15:54] <lifeless> a new team is fine
[15:54] <lifeless> teams are cheap
[15:54] <lifeless> and its appropriate if phinze is maintainer
[15:55] <lifeless> names wise, I'd suggest bzr-testoncommit or something
[15:55] <lifeless> testrunner is ok, but perhaps it can be improved
[15:55] <lifeless> *night all*
[15:55] <james_w> night
[15:55] <james_w> and it's not just commits
[15:55] <lifeless> phinze: oh the bug number - Ididn't have that before, just look at bzr's new bugs
[15:56] <lifeless> james_w: I know that
[16:03] <ricardokirkner> jelmer, sort of... I don't know when this was first introduced, but since then, (almost) every push crashes
[16:03] <ricardokirkner> jelmer, I think at some point I merged changes from two different branches and  then tried to push them to the svn repo
[16:04] <ricardokirkner> and after that the problems started, but I am not entirely sure about that
[16:13] <jelmer> ricardokirkner: is it a public branch?
[16:14] <ricardokirkner>  jelmer no... sorry .. it's customer private code
[16:14] <ricardokirkner> if I can run the tests you need, just tell me
[16:14] <ricardokirkner> and I tell you back the results
[16:37] <james_w> phinze: pushed as lp:bzr-testrunner. It should be added to http://bazaar-vcs.org/BzrPlugins as well so that people can find it
[16:37] <james_w> do you want to do that?
[16:37] <phinze> james_w: awesome, thanks... yeah i can add it
[16:37] <james_w> cool, thanks
[16:40] <phinze> james_w: did you want to try and mess with a group as suggested by lifeless?  or just let me bother you with merge requests :)
[16:41] <james_w> I don't mind you bothering me, but we can set up a group if you want to be recognised as an author
[16:46] <phinze> https://launchpad.net/%7Ebzr-testrunner <-- james_w
[16:48] <james_w> thanks
[16:48] <james_w> all changed
[16:48] <james_w> you should have full access now
[16:49] <phinze> beautiful, ty
[16:58]  * SamB_irssi wonders what he should do with his debugger branch in the DOSEMU svn repository now that he's merged it back to trunk with bzr-svn
[16:59] <SamB_irssi> I want to make more debugger changes ... should I pull in trunk and make more, or delete and make a new branch, or what?
[17:01] <LarstiQ> disregarding svn backing, I'd pull trunk to debugger and then continue there
[17:01]  * SamB_irssi wonders if he should disregard svn backing
[17:06] <Kobaz> is there an unmerge?
[17:06]  * SamB_irssi wonders why sf.net isn't allowing svn:mergeinfo
[17:07] <LarstiQ> Kobaz: what would that do?
[17:07] <Kobaz> LarstiQ: undo the merge that was just done
[17:07] <LarstiQ> Kobaz: bzr revert?
[17:08] <SamB_irssi> what about the merge did you want to undo?
[17:08] <Kobaz> the whole thing?
[17:08] <LarstiQ> evening bialix
[17:08] <bialix> jam: are you here?
[17:08] <bialix> heyo LarstiQ
[17:09] <bialix> LarstiQ: how are you?
[17:10] <bialix> does anybody knows about new dependency in 1.14: pylzma. I assume it's optional. Is it correct?
[17:11] <LarstiQ> bialix: mistakenly thought it was no longer cold weather with the sun, and thus caught a cold
[17:11]  * LarstiQ could be better
[17:11] <LarstiQ> bialix: how about you?
[17:11] <bialix> ah
[17:12] <bialix> too much work. and my daughter going to the school this year, I have to help her
[17:14] <bialix> do you know when the jam appears here usually this week?
[17:19] <asac> lifeless: hi. now that gnome moved to git, is there any bzr-git in sight?
[17:19] <bialix> https://launchpad.net/bzr-git
[17:20] <LarstiQ> bialix: ah, primary school?
[17:20]  * LarstiQ would expect jam awake by now
[17:20] <LarstiQ> bialix: I expect pylzma is optional too
[17:20] <asac> how good does that work?
[17:21] <LarstiQ> asac: not as good as bzr-svn, but better than bzr-hg
[17:22] <bialix> LarstiQ: yes, primary school
[17:23] <LarstiQ> bialix: cool, I imagine that's very exiting for her?
[17:23] <asac> LarstiQ: hmm. guess i will have to try ... thanks
[17:23] <bialix> LarstiQ: the school today seems much complex than in my time. sometimes I think it's much harder to get to the school than to University
[17:23] <LarstiQ> bialix: woha. How much complexity can there be in primary schooling?
[17:23] <LarstiQ> apparently more than I think
[17:24] <LarstiQ> asac: I haven't used it, so I can't really make definitive statements.
[17:24] <bialix> LarstiQ: may be it's my country made it so complex. or may be I am
[17:24] <LarstiQ> asac: I know people use it and developt it, but yes, trying seems best
[17:24] <bialix> LarstiQ: there is something like entrance examination
[17:24] <LarstiQ> bialix: well, I don't have kids yet, so maybe I'm just ignorant :)
[17:25]  * LarstiQ blinks
[17:25] <bialix> yep
[17:25] <LarstiQ> bialix: can that be failed? And if so, what is one supposed to do then
[17:26] <bialix> LarstiQ: yes, there is very high chances to fail the examination in the good school. of course men who have enough money can ignore this
[17:27] <bialix> and there is less good schools there
[17:27] <LarstiQ> bialix: ah, so the implication is that you have to go to a less good school?
[17:27] <LarstiQ> right
[17:28] <bialix> things are too complex, or at least seem so. in m time we go to the school 10 years. now it's 12 years
[17:29] <bialix> things are changed
[17:29] <bialix> hi Gary
[17:40] <bialix> it seems jam traveling these days. (sigh) ok, will wait for his response in ML
[17:41]  * bialix waves
[17:51] <bialix> I have questions about http://doc.bazaar-vcs.org/bzr.dev/developers/plugin-api.html
[17:52] <bialix> especially about section "Plugin metadata before installation". why for it supposed to be?
[18:04] <SamB_irssi> jelmer: can bzr-svn put in svn:mergeinfo properties retroactively ?
[18:16]  * SamB_irssi wishes bzr viz was as good as gitk :-(
[18:18] <luks> what features are you missing?
[18:19] <SamB_irssi> well, it doesn't seem to have great graph layout
[18:19] <luks> maybe you should try bzr qlog
[18:32] <SamB_irssi> luks: it looks like that would require too much disk space to install
[18:36] <garyvdm> Hi bialix
[18:36] <luks> SamB_irssi: let me guess, gentoo user? :)
[18:38] <ricardokirkner> jelmer, regarding the svn push bug... I have some update
[18:38] <ricardokirkner> sometimes the push is performed correctly (although bzr crashes) -- I can see the commit done in svn
[18:39] <ricardokirkner> sometimes the push is done partially -- only a few revisions are committed and then it breaks
[18:39] <ricardokirkner> for example, the last push I did was submitted correctly, but bzr crashes
[18:39] <ricardokirkner> I will wait until there is something to update my branch, and after a pull, it should work again
[20:21] <phinze> so... rails has some fixtures in its tests that ensure that some of its functions pull in templates properly
[20:21] <phinze> so it has files called like template.erb~ and template.erb~1~
[20:22] <phinze> will bzr clean-tree --detritus nuke those?
[20:23] <garyvdm> I don't know, but you can test with --dry-run
[20:59] <sevenseeker> I just updated bzr, subvertpy, and bzr-svn to the latest via easy_install, but when trying to add a file to my local working copy I receive:
[20:59] <sevenseeker> zr: ERROR: The API for "<module 'bzrlib' from '/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/bzr-1.14rc2-py2.6-macosx-10.5-i386.egg/bzrlib/__init__.pyc'>" is not compatible with "(1, 12, 0)". It supports versions "(1, 13, 0)" to "(1, 14, 0)"
[21:01] <james_w> sevenseeker: it sounds like that bzr-svn is too old for that bzr
[21:03] <sevenseeker> according to http://bazaar-vcs.org/BzrForeignBranches/Subversion 0.5.4 works with 1.14, and that is what I have
[21:03] <sevenseeker> maybe it is just a config bug, I will make a backup and try editing the reqs
[21:05] <james_w> do you by any chance have two copies of bzr-svn installed?
[21:05] <sevenseeker> checking
[21:13] <sevenseeker> ah drat... yes somehow I still have 0.5.3 lurking around
[21:55] <ja1> phinze: Also clean-tree prompts before deleting
[21:55] <ja1> (sorry if I'm coming late)
[21:55] <ja1> oh, and I think our pattern is ".~1~" not "~1~" so it may ignore them
[21:56] <ja1> that said, *who* uses ~1~ in real files ... :)
[21:56] <phinze> ja1: yeah turns out rails is inappropriately *preferring* those files when selecting templates
[21:56] <phinze> bad rails
[21:59]  * davidstrauss can't wait for the next Stephen Turnbull post to the mailing list.
[22:02] <phinze> we've got a bug open with the rails folks though... hopefully it will be fixed soon on their end
[22:35] <lamalex> Is there a thing in bzr that does something similar to git's url config shortening?
[22:36] <lamalex> like in git I can do git config --global url.git://git.gnome.org/.insteadof gnome: to use gnome: as the prefix for my gnome git branches
[22:36] <lamalex> this looks like lp: so I assume I can, but is this a specific plugin?
[22:36] <lamalex> im not sure what to google for
[22:36] <lifeless> hmm
[22:37] <lifeless> I *think* the url bookmarks thing can do that
[22:37] <lamalex> how does  launchpad do it?
[22:37] <lifeless> also plugins can, I know jamesh did one for gnome
[22:37] <lifeless> lamalex: the launchpad plugin registers with the bzr directory service provider api
[22:38] <lifeless> lamalex: so it gets called into, and the plugin then does an xmlrpc lookup
[22:38] <lifeless> I'm not sure what to google for either :(
[22:39] <lifeless> jamesh may know if someone generalised/made configurable his plugin for gnome, he'll be up in about 3-4 hours
[22:40] <lamalex> lifeless: ok, so right now at least it's not a simple as it is with git
[22:40] <lamalex> ill look at the bookmarks plugin
[22:42] <mwhudson> it may be prejudice, but i'm not sure that git config line is entirely 'simple' :)
[22:44] <lamalex> mwhudson: but it appears to be simpler than in bzr
[22:44] <mwhudson> in some sense
[22:44] <mwhudson> yes
[22:44] <lamalex> and the git config line is pretty straight forward
[22:44] <lamalex> discoverable maybe not
[22:44] <mwhudson> more convenient, for sure
[22:44] <lamalex> but looking at the line it's clear what it does
[22:45] <lamalex> and zsh autocompletes git commands, so that helps
[22:45] <lamalex> including the config variables
[22:46] <lamalex> yah, i <3 bzr im not here to say bzr sucks git rules
[22:46] <mwhudson> that completion sounds nice :)
[22:46] <lamalex> indeed
[22:46]  * mwhudson should go back to doing useful stuff, not grousing
[22:46] <lamalex> :)
[22:47] <james_w> bzr-bookmarks can do it I think
[22:47] <james_w> well, that's what it's intended to do, but I'm not sure how slick it is
[22:47] <lamalex> so is there /any/ kind of documentation about the bookmarks plugins? even just a "this is what it does" blog post?
[22:47] <lamalex> ah, in the code
[22:47] <james_w> "bzr help bookmarks"
[22:48] <james_w> if you've installed it that is :-)
[22:48] <lamalex> right, i wanted to see what it did before installing it
[22:48] <lamalex> looking at it in lp now
[22:49] <james_w> yeah, it's not good you have to do that
[22:50] <lamalex> agreed
[22:50] <lifeless> memo to self, plugin-info should be able to do that
[22:50] <lamalex> even if just the lp front page had "this is what I am"
[22:51] <lamalex> hm, bzr needs sexy zsh expansions
[22:52] <lamalex> my TODO list seems to be ever expanding
[22:52] <lamalex> hm, it also has no usage info
[22:52] <lamalex> ah, i am mistaken
[22:55] <bob2> it is relatively sexy already
[22:55] <lamalex> yah the bookmarks plugin seems to let me make a shortcut to a specific branch which is nice, but not a prefix like lp or gnome
[23:04] <lifeless> lamalex: I'd file a bug somewhere
[23:04] <lifeless> actually
[23:04] <lifeless> have a look through bzr help configuration
[23:04] <luks> it can do a prefix
[23:05] <luks> just bookmark the prefix and use bm:foo/path/to/branch
[23:05] <lamalex> ah, i had no idea help configuration existed
[23:06] <lamalex> it doesn't show up in zsh tab expansion
[23:06] <lamalex> when other stuff does- hence i never looked further
[23:06] <lifeless> lamalex: anyhow luks has rescued the day
[23:08] <lamalex> kind of, i still dont see it in there
[23:09] <lifeless> lamalex: luks says use the bookmarks plugin, which won't be patching bzr help configuration (perhaps it should :P).
[23:09] <lifeless> lamalex: so bookmark gnome as <whatever> then do gnome:/foo/bar/baz
[23:10] <luks> bm:gnome/foo/bar/baz actually
[23:10] <luks> it doesn't register a new protocol for each bookmark
[23:11] <lamalex> literally bm:
[23:11] <lamalex> ?
[23:12] <lifeless> luks: ah ok
[23:12] <lifeless> lamalex: bm:BOOKMARKNAME/suffix
[23:12] <lamalex> not as nice, but it works
[23:12] <luks> it *could* register gnome:suffix, but that would get messy pretty soon
[23:13] <lifeless> luks: it might be nice though, when people want it
[23:14] <lamalex> just dont go crazy with it, it's not the same a bookmark
[23:14] <lamalex> but being able to easily register a protocol is a nice thing to be able to do
[23:18] <lifeless> I'm all for allowing people to have rope
[23:18] <lifeless> as long as its not actually dangerous