=== joerg is now known as Guest15623
[03:49] <arose> Is it possible to separate a file into two or more pieces in a way that bazaar is aware that it's not just some code deleted in one file and other code created in a new one?
[03:50] <exarkun> arose: What if you 'bzr copy' the file and then edit each?
[03:50] <arose> Sounds like that would work, thanks
[03:52] <arose> ...is there a 'bzr copy'?
[03:55] <exarkun> :(
[03:55] <exarkun> not sure why I thought so, I must be mixing up systems, sorry
[03:59] <arose> I guess not quite yet, finally found info on it, so in that sense "bzr copy" helped http://wiki.bazaar.canonical.com/BzrFileCopies
[04:37] <exarkun> Ughh
[04:37] <exarkun> The Windows installer fails with a "Runtime Error!"
[04:37] <exarkun> R6034
[04:38] <exarkun> Actually, it fails with about a thousand of them.
[04:38] <exarkun> ... each has to be dismissed individually
[05:57] <exarkun> Should I be trying to make bzr-svn use python-tdb on Windows too?  Or is that beyond the realm of conception?
[10:14] <mgz> hm, two interesting things since last I were here.
[10:15] <mgz> alexander hit the testtools traceback-isn't-unicode issue (good news there, nearly done with fix)
[10:17] <mgz> and a twisted guy has a french nix system (bit more work, getting non-english errors printing correctly is also on my list)
[10:48] <lifeless> mgz: cool
[10:50] <mgz> on the less cool side of things, bug 583941 ...ugh
[10:50] <ubot5> Launchpad bug 583941 in Bazaar "program crashes with "bzr: ERROR: socket.error: (4, 'Interrupted system call')" (affected: 1, heat: 56)" [Medium,Triaged] https://launchpad.net/bugs/583941
[10:51] <lifeless> uhmm
[10:51] <lifeless> that 56 would be better as 56/TOP
[10:51] <lifeless> who runs ubotu again
[10:53] <jpds> lifeless: tsimpson on #ubuntu-irc.
[10:53] <lifeless> meh, that channel mocks people
[10:53] <lifeless> :P
[10:54] <lifeless> and its sunday evening ;)
[10:54] <mgz> okay, actually that bug isn't our problem.
[10:55] <mgz> can I dupe something against a Python bug?
[10:55] <mgz> or is even launchpad not that amazing yet...
[10:56] <lifeless> what you do
[10:56] <lifeless> is click on 'affects other project'
[10:56] <lifeless> add the url there to the python upstream bug
[10:57] <lifeless> and mark our task as you think is appropriate
[10:58] <mgz> hm, this is actually a little complicated, better explain in a comment
[11:08] <mgz> wow, that... picked up the bugs from my comment?
[11:10] <lifeless> no?
[11:10] <mgz> there's a "Remote bug watches" thing on the right, with the bug numbers
[11:11] <lifeless> ah, yes. nice
[11:17] <mgz> might be something else to bug exarkun about, he landed the other socket bug for us, getting the fix for <http://bugs.python.org/issue1628205> on 2.6 as well would be great
[11:19] <lifeless> exarkun: ^
=== Pilky_ is now known as Pilky
[15:28] <exarkun> lifeless: http://buildbot.twistedmatrix.com/builders/winxp32-py2.5-select/builds/8/steps/bzr/logs/stdio :)
[15:28] <exarkun> lifeless: maybe we can trade
[15:31] <spiv> exarkun: get one builder to do the conversion from svn, and have the rest branch from that?
[15:31]  * spiv -> zzz
[15:33] <mgz> a trade is fair :)
[15:33] <mgz> and that looks like a straight-up bug in bzr-svn on windows
[15:33] <mgz> the retrying thing is bogus though
[15:33] <exarkun> I need a little more info about <http://bugs.python.org/issue1628205> though.  The last few comments sound like "fix applied" to me.
[15:34] <mgz> it is applied, on trunk.
[15:34] <mgz> http://svn.python.org/view?view=rev&revision=74426
[15:34] <mgz> I'm right in thinking that the next 2.6 is going to be the last bug fix release, right?
[15:35] <exarkun> People have said stuff to that effect, I think
[15:35] <exarkun> So, backport the fix, gotcha
[15:36] <exarkun> This patch looks super awesome
[15:36] <exarkun> My favorite part so far:
[15:36] <exarkun> del data  # explicit free
[15:38] <jelmer_> mgz: it's a known issue with sqlite caching on windows
[15:38] <jelmer_> mgz: unfortunately there isn't really a good way around it with sqlite
[15:38] <mgz> that is a little special, and ideally all this catching and retrying would happen at the C level in Python
[15:38] <mgz> but... that's been an open bug since 2002 or so.
[15:39] <mgz> got a bug number jelmer?
[15:40] <jelmer_> 520694
[15:40] <mgz> ta.
=== jelmer_ is now known as jelmer
[15:43] <mgz> okay, so a fix for twisted would be to serialise bzr-svn operations on windows
[15:45] <jelmer> mgz: the proper fix is to use a caching format that allows multiple concurrent writers; I have a plan on how to do this using bzr pack files
[15:45] <exarkun> which I could try to cobble together in an ad hoc way inside my buildbot configuration... or which bzr-svn itself could try to enforce on windows, where concurrent access is known to always be broken?
[15:45] <jelmer> but serializing bzr-svn operations is a good workaround
[16:02] <mgz> http://bugs.python.org/issue210599 was the one I was thinking of
[16:03] <mgz> the current signal/interrupt semantics in Python make it close to impossible to both 1) use signals, 2) use the standard library, and still write correct code
[16:04] <jelmer> ah
[16:10] <exarkun> mgz: Providing sensible semantics for combining blocking I/O and asynchronous signals might be beyond Python.
[16:31] <Lor> Pretty much any language, except Haskell.
[16:59] <exarkun> Could be
[16:59] <exarkun> mgz: issue1628205 backported to release26-maint, in any case
[17:02] <mgz> thanks!
[17:04] <mgz> I owe you some well-handled french OSError messages.
=== radoe_ is now known as radoe
[18:33] <mkanat> Okay. I have local commits, I do bzr up, and I get a cryptic: bzr: ERROR: [Errno 13] Permission denied
[18:33] <mkanat> This is with 2.1.1.
[18:42] <mgz> look in your .bzr.log for the full traceback
[18:43] <mkanat> mgz: Yeah, I realized that.
[19:06] <exarkun> Anyone seen tree corruption on Windows with 2.1.1?
[19:10] <jelmer> exarkun: what do you mean by tree corruption?
[19:11] <exarkun> A file in a checkout has extra garbage at the end of it.  Perhaps bytes that belong to another file.
[19:11] <exarkun> Looking for possible causes other than bzr now, though.
[19:39] <mathbr> Hi. Is there some way to have --show-diff enabled by default for commits? I couldn’t really find an option for bazaar.conf.
[19:39] <cbz> jelmer: i have an odd problem where - for some reason - bzr-svn decided to commit a bunch of files to which there had been no changes. this was across a rebase operation (those files had been changed in the main branch - though other files had been changed too and were not committed). This only appears in the local repository
[19:40] <jelmer> cbz: I'm not sure I follow - the files were actually changed incorrectly?
[19:41] <cbz> jelmer: the files had been updated in the svn branch upstream. A subset of them show up in my commit after the rebase operation
[19:48] <jelmer> cbz: so what did bzr-svn do incorrectly exactly?
[19:50] <cbz> jelmer: i assume for some reasonnwhen bzr-svn pulled the files down (they are binaries btw png files) the modified time was marked incorrectly, which is why commit thought they were new?
[19:50] <cbz> or rather 'updated)
[20:07] <jelmer> cbz: modification times aren't used anywhere
[20:07] <cbz> odd - i wonder why commit thought they had been updated then
=== Guest15623 is now known as joerg
[20:29] <lifeless> exarkun: extra bytes - not that I know of
[20:29] <jelmer> cbz: how do you tell they've been modified?
[20:30] <jelmer> if they haven't actually changed in content I mean
[20:31] <cbz> jelmer: i don't, bzr (q)commit tries to commit them
[20:31] <cbz> or actually commited them
[20:35] <jelmer> cbz: what changes does it claim they have?
[20:43] <lifeless> poolie: morning!
[20:44] <poolie> hi there
[20:44] <lifeless> jetlagged ?
[20:44] <poolie> a bit
[20:44] <lifeless> :P
[21:19] <cbz> jelmer: when i double click it says the files are identical (the change has already gone in)
[21:46] <poolie> lifeless, https://code.edge.launchpad.net/~mbp/bzr/doc/+merge/25400 updated if you want to reread it; not urgent
=== poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: lifeless | bzr 2.1.1 is out
[21:47] <poolie> lifeless, btw, you're it this week for pp
[21:55] <lifeless> thanks
[21:56] <lifeless> I have another small tweak up for hydrazine btw
[21:58] <poolie> i'm going to finish an output_encoding option for bialix
[22:31] <lifeless> poolie: your doc branch
[22:31] <lifeless> poolie: I've commented -twice- - the second one is just 'please mention commit messages on merge proposals' ;) but it should be landed
[22:33] <poolie> ok, i just asked again because you said you only scanned it
[22:33] <lifeless> ah
[22:34] <lifeless> if you want a line by line review I can, but it seems to be largely moves, which is a pain to deal with IME
[22:34] <lifeless> I'm inclined with large doc changes to get them in and deal with fallout as it is discovered - a lot more mutable than code.
[22:35] <mgz> ugh, I need to commit something here before this diff gets any bigger
[22:35] <mgz> it's already nightmarish
[22:35] <mgz> Robert is going to hate me.
[22:35] <lifeless> no
[22:35] <lifeless> I don't hate contributors
[22:35] <lifeless> I may find it hard to review.
[22:42] <poolie> lifeless, i agree about the moves and about docs
[22:42] <poolie> it's easier to read the whole resulting product and see if it makes esnse
[23:05] <wapcaplet> Hello all. Long time bzr user, first time caller :-) I recently started using bzr-svn, and noticed that when I use 'bzr log', it reports the svn revno for everyone else's commits, but not for my own commits. Anyone know what's up with that?
[23:05] <lifeless> well, you're probably committing locally, in bzr ?
[23:06] <wapcaplet> lifeless: I don't remember exactly how I originally branched, but my commits are going straight to svn
[23:06] <lifeless> could you run 'bzr info' in your branch, and paste it somewhere
[23:07] <lifeless> if there is stuff you want to obfuscate thats fine - just keep the sense of it intact
[23:07] <wapcaplet> sure - http://pastebin.com/M4mJFxzm
[23:07] <wapcaplet> not sure what's up with that related branch... that was from a while ago
[23:11] <wapcaplet> IIRC, I originally checked out like 'bzr init-repo tovid; cd tovid; bzr checkout svn+ssh:// ....'
[23:11] <lifeless> ok
[23:11] <lifeless> you have a local reop
[23:11] <lifeless> reop
[23:11] <lifeless> that is getting your commits
[23:11] <lifeless> and then they are translated to svn commits
[23:12] <lifeless> so your commits *start* in bzr and don't get an svn revno attached as a result
[23:12] <wapcaplet> aha
[23:12] <lifeless> you could file a bug, if you like - this is in principle fixable
[23:12] <lifeless> -> bank for a few minutes.
[23:14] <wapcaplet> svn has a similar quirk of its own... the revno of the last commit isn't correctly reported until after doing an 'svn up'