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