[00:27] <TeTeT> any idea what's wrong here:
[00:27] <TeTeT> % bzr push
[00:27] <TeTeT> Using saved location: bzr+ssh://tspindler@bazaar.launchpad.net/~canonical-training/ubuntu-desktop-course/ubuntu-desktop-course-beta/
[00:27] <TeTeT> No handlers could be found for logger "bzr"
[00:27] <TeTeT> Connection to bazaar.launchpad.net closed by remote host.
[00:27] <TeTeT> bzr: ERROR: exceptions.AssertionError: end of file reading from server
[00:35] <jkakar> Do the --fixes and --author options to 'bzr commit' do anything other than add metadata to the revision?
[00:36] <jkakar> TeTeT: That looks a misconfiguration in Launchpad (which is a complete guess on my part).
[00:37] <TeTeT> jkakar: ok
[00:38] <jelmer> jkakar: no, revision metadata is all it is
[00:38] <jkakar> jelmer: Ah, cool.  Thanks.
[00:40] <jkakar> Hmm.
[00:41] <jkakar> Can one pass multiple bug numbers to --fixes.  ie: Is it just a string that can be used like: bzr commit -m "My message." --fixes "1234,2345"
[00:45] <jkakar> Hmm.
[00:45] <jkakar> Am I missing something or are --fixes and --author values not shown in bzr log?
[00:45] <jkakar> How do I discover this data?
[00:50] <jkakar> Actually, it does appear to include an "Author: ..." line in the log.
[05:08] <lifeless> rofl
[05:08] <lifeless> btw, hi
[05:53] <jdub> how much space does bzr use when committing binary files?
[05:53] <spiv> jdub: "some" ;)
[05:55] <jdub> does it have another complete copy of the binary file in the repo, and a new one for each change, or...?
[05:55] <spiv> jdub: if you commit multiple versions of a binary file, it'll typically do ok deltas of that (splitting on \n, just like text files), and I think there's also some gzipping on top of that.
[05:57] <jdub> but the initial commit will pretty much double the size (between the working dir and repo)
[05:57] <jdub> ?
[05:57] <spiv> I'm not sure what you mean.
[05:57] <spiv> The initial commit has to make a copy of the file to record it in the repo.
[05:59] <spiv> So going from "bzr init . ; bzr add" to "bzr commit", it will double the disk usage (ignoring the gzipping).
[06:01] <jamesh> jdub: it depends on how well the binary compresses
[06:01] <jamesh> same for text
[06:06] <spiv> jdub: still here?
[06:10] <jdub> yeah, sorry
[06:10] <jdub> back
 I'm not sure what you mean.
 The initial commit has to make a copy of the file to record it in the repo.
 So going from "bzr init . ; bzr add" to "bzr commit", it will double the disk usage (ignoring the gzipping).
 bzr doesn't cope particularly gracefully with large files yet (binary or not).
 (hooray, lag)
 It'll hold the entire file in memory (sometimes two or three times) to do some operations.  So depending on the files, that might be a larger problem for you than the repo size.
[06:12] <spiv_> (not sure how much of that got through the first time)
[06:12] <jdub> yep, go all that
[06:12] <spiv_> Ah, good :)
[06:12]  * jdub has a starting point of 514MB of binary files... ;-)
[06:13] <jamesh> ISO images?
[06:13] <spiv_> Ah-hah.  I thought you might have large files given that you were worried about repo size...
[06:14] <jdub> jamesh: almost -- windows xp install files 8)
[06:15] <jamesh> jdub: ah.  514 MB of files total rather than a single 514 MB file
[06:15] <jdub> yeah
[06:23] <jamesh> jdub: so you probably need to worry more about the maximum sized file
[06:23] <jamesh> and the gzip compression probably won't help much, since the install files would already be compressed
[06:24] <spiv> The good thing about compressed files is they typically have \n bytes at regular intervals...
[10:03] <weigon_> jelmer: g'morn ... bzr branch against a svn-tree still doesn't work: http://p.caboo.se/111476
[14:48] <fullermd> Boy, it sure is nice and quiet when everybody's off at meetings...
[15:06] <lifeless> morning
[15:07] <lifeless> fullermd: bite your tongue
[15:07] <lifeless> :)
[15:07] <fullermd> Did that yesterday, actually.  It'll be a few more days yet before I forget how much it hurt and do it again.
[15:17] <lifeless> heh
[15:45] <lifeless> hi thumper, phanatic
[15:45] <phanatic> hey lifeless
[15:45] <thumper> lifeless: howdy
[16:49] <Verterok> beuno: ping?
[16:55] <beuno> Verterok, pong!
[16:55] <Verterok> Hi!
[16:55] <bialix> hey lifeless
[16:56] <beuno> hey, I finally re-implemented the new XML format and been using it for a week or so
[16:56] <bialix> luks: ping
[16:56] <Verterok> beuno: availabale for a chat about xmloutput? (mainly about log --xml)
[16:56] <beuno> Verterok, everything works great. Just had that small glitch with the XML format, which I saw you already fixed in trunk
[16:57] <beuno> Verterok, sure
[16:57] <luks> bialix, hi
[16:57] <Verterok> beuno: nice!
[16:57] <bialix> hello, luks
[16:57] <bialix> did you see my e-mail about QBzr(qlog) + packs
[16:57] <Verterok> beuno: it's fixed more or less :P. I found a few cases not handled (correctly) by the plugin
[16:57] <luks> yes
[16:58] <luks> it probably just need some lock_read/unlock calls
[16:58] <luks> *needs
[16:58] <beuno> Verterok, is it skipping revisions, or just XML correctness?
[16:58] <luks> but I haven't tested it on any pack repo yet
[16:58] <bialix> luks: I think so
[16:59] <Verterok> beuno: xml correctness in deep merges
[17:00] <bialix> luks: goffredo did good job with unidiff, I integrated second version of his patch to my branch.
[17:00] <beuno> Verterok, when specifically does it fail?  I haven't bumped into it these days yet
[17:00] <Verterok> beuno: the current issue is how to correctly show some cases like a merge who has a merge inside it
[17:01] <beuno> (I'm parsing XML in a much more stricter way so I can eventually release the code and help test the XML a bit better)
[17:01] <Verterok> beuno: I found it testing with in bzr.dev
[17:02] <beuno> Verterok, so it's when you have nested merges?   how does the regular bzr log output show that?  it keeps tabulating?
[17:03] <Verterok> beuno: running bzr log -r 2420..2481 in bzr.dev (with and without --xml switch)
[17:03] <Verterok> beuno: the case can be found in the revno 2447.1.7
[17:06] <Verterok> beuno: the nested merge is revno 2208.4.4
[17:07] <beuno> Verterok, that's odd, 2447.1.7 is only one level deep
[17:07] <beuno> I see 2466 > 2447.1.7
[17:08] <beuno> Verterok, I see what you mean with 2208.4.4
[17:08] <Verterok> 2447.1.7 -> 2208.4.4 (without a log )
[17:08] <Verterok> beuno: the current xml don't support this kind of nested merge, the problem seems to be that we expect that all merge have a <log>, but this case doesn't have one :P
[17:10] <Verterok> beuno: it's not a problem for your parser (at least I think so), because the revision is included in the xml, but it isn't nested correctly
[17:10] <beuno> Verterok, AFAIK, it breaks the structure, right?  the <merge> bit
[17:10] <Verterok> beuno: yes
[17:11] <beuno> Verterok, I don't think we have 2 level merges yet, but I do want to make the parser as strict as possible, to help test the plugin out as much a possible
[17:12] <Verterok> beuno: I'm working in a test case for it and thinking how we should handle this case. any ideas are wellcome :D
[17:12] <beuno> Verterok, <merge> within <merge> comes to mind
[17:12] <beuno> although it isn't pretty, but come to think of it, neither is XML  :p
[17:13]  * Verterok agrees
[17:14] <Verterok> ok, if it's ok with you, I can fix this with nested <merge> tags
[17:14] <beuno> Verterok, absolutely, I can't think of a better way
[17:15] <Verterok> beuno: I finished almost all unittest, only misssing is missing (what a problem ;) )
[17:16] <beuno> Verterok, hahahah, I saw, I'm still not sure how the tests work though, haven't played around with em
[17:17] <Verterok> beuno: no prob, I'll write it.
[17:18] <Verterok> beuno: Also, I created a XMLLineLogFormatted to use it in pending merges, i think it can be usefull for missing
[17:19] <beuno> Verterok, I've been thinking on the best way to structure that, even for future use cases
[17:19] <beuno> I might try and actually put my idea down as code
[17:21] <Verterok> sure! if you need some help, and I can do something, just tell
[17:22] <Verterok> beuno: ah, I see your fix to the path escaping. I found that in bzrlib.xml_serializer there is a _escape_cdata to handle entities escaping
[17:24] <beuno> Verterok, oh, yeah, I was pretty sure that wasn't the best approach, I just needed to get it working at that point, so I did one of those ugly workarounds expecting you to come up with a much more elgant solution  :D
[17:24] <beuno> did you implement that on all user input?
[17:24] <Verterok> jajaja
[17:25] <beuno> because I only fixed it where I had the problem, didn't sanitize all the XML as I probably should of
[17:26] <Verterok> not sure if it's in all user input, i need to check that. I added it to path, commiter, commit message
[17:26] <beuno> Verterok, I think all that would be left is branch-nick
[17:27] <Verterok> beuno: the branch-nick it's handled in log, but not in version, fixing it. thanks!
[17:28] <beuno> Verterok, np, you're basically fixing things that I won't have to, so it's convenient :D
[17:29] <beuno> about the code restructure thing, I was thinking we might want to have a specific class that takes a revision number and returns it in XML, and we can use that from all commands
[17:30] <beuno> then just loop through whatever command, and add any magic needed (<merge>, etc)
[17:30] <beuno> that way we can centralize all data sanatization in one place
[17:30] <beuno> (I'm thinking ahead here, for when we try and push this as part of the actual bzr code)
[17:31] <beuno> that might make it easier to re-use that bit of code from everywhere else
[17:32] <beuno> I was thinking maybe just passing the revision number to it, and let it return it nicely formated
[17:32] <Verterok> sure, in the case of log, this is done in XMLLogFormatter.logrevision, but it recieves a LogRevision not revno
[17:32] <beuno> not sure how that would hit on performance though
[17:32] <beuno> right, LogRevision sounds saner
[17:33] <beuno> but don't we have much duplicated code?
[17:33]  * beuno goes and looks at the latest version
[17:33] <Verterok> LogRevision actually is bzrlib.log.LogRevision
[17:35] <beuno> Verterok, right, the code *is* already structured pretty much that way...
[17:36] <Verterok> yes, but in not convinced with the current logformatter in bzrlib, in the case of the xml output we need to do a lots of workarounds to handle merges, etc
[17:37] <beuno> right, that does seem the root of the messy code
[17:37] <Verterok> the issue is that the logformatter recieves one revision at a time, and doesn't known anithing about the context of that revision (if it's in merge or whatever)
[17:38] <Verterok> s/anithing/anything/
[17:38] <beuno> we should atempt to clean that up in a way that's convenient to format, and see if that still works cleanly with bzrlib
[17:39] <beuno> Verterok, the current output adds tabs to it, so it does know at some point if it's a merge
[17:39] <beuno> maybe we can hook there
[17:39] <beuno> tab == merge
[17:39] <beuno> no tab now, but yes before == close merge
[17:39] <beuno> might be cleaner
[17:39] <beuno> and offloads the scaling problem to bzr devs  :D
[17:40] <Verterok> yes, last night I make some cleanup of the xml logger and started to work that way cheking the merge_depth value
[17:41] <beuno> ah, you've been doing a lot of "doing", I haven't gotten past tossing it around in my head
[17:42] <Verterok> I'm quite sure that the way to go, and keep the logfomatter untouched
[17:42] <Verterok> me neighter ,I screwed log --xml badly  :D
[17:42] <beuno> muahahah
[17:43] <beuno> well, aside from the little tweak I added, the rest went perfectly this week
[17:43] <beuno> even added the feature for users to see their commits from our software
[17:44] <Verterok> great!
[17:44] <beuno> so everybody had their attention put on if they actually showed up
[17:44] <beuno> found a few bugs in the way I was doing things thanks to that
[17:45] <beuno> I'm confident I'll be able to release a loggerhead-like thingie in php in a near future
[17:45] <Verterok> user feedback is really helpful
[17:46] <Verterok> thanks to that I have 4 or 5 bugs to fix in bzr-eclipse, but first I need to close the nested merges things
[17:46] <beuno> yes, once I gather the patience to listen to absurd complaints from the windows-using graphic designers, feedback is great  :p
[17:47] <beuno> Verterok, ah, yes, I have steared a few ppl asking questions about bzr-eclipse here towards Launchpad these days
[17:47] <beuno> to bugs/questions
[17:47] <beuno> haven't atempted to use it in a long time know, so I'm not confident enough to answer anything
[17:49] <Verterok> it's slowly becoming more usable, maybe in a few days (with xmloutput fixed, and the changes to bzr-eclipse) I can promote it to "beta" and make a 0.1 release
[17:51] <Verterok> tought, the pre_alpha warning scared some users :P
[17:51] <Verterok> maybe a "its' beta" warning is more user friendly :D
[17:55]  * Verterok lunch
[17:55] <Verterok__> beuno: seeya later
[17:56] <beuno> Verterok__, buen provecho
[17:57] <Verterok__> thx!
[20:44] <hsn_> release schedule for 0.92?
[23:02] <jelmer> weigon_: thanks, fixd
[23:02] <weigon_> what ever I touch breaks :)
[23:03] <jelmer> that was actually a bit of carelessness on my side
[23:05] <Peng> "knitpack"? Not "knit-pack"?
[23:06] <weigon_> jelmer: I'm on 760 now, but still exploding
[23:06] <weigon_> but I think "StopIteration" is the bzr.dev on from 2-3 days ago
[23:08] <weigon_> jelmer: http://p.caboo.se/111576
[23:08] <weigon_> bzr.dev and bzr-svn are current
[23:08] <weigon_> it is a clean 'bzr branch'