| 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:27 |
| jkakar | Do the --fixes and --author options to 'bzr commit' do anything other than add metadata to the revision? | 00:35 |
| jkakar | TeTeT: That looks a misconfiguration in Launchpad (which is a complete guess on my part). | 00:36 |
| TeTeT | jkakar: ok | 00:37 |
| jelmer | jkakar: no, revision metadata is all it is | 00:38 |
| jkakar | jelmer: Ah, cool. Thanks. | 00:38 |
| jkakar | Hmm. | 00:40 |
| 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:41 |
| 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:45 |
| jkakar | Actually, it does appear to include an "Author: ..." line in the log. | 00:50 |
| === mw is now known as mw|out | ||
| lifeless | rofl | 05:08 |
| lifeless | btw, hi | 05:08 |
| jdub | how much space does bzr use when committing binary files? | 05:53 |
| spiv | jdub: "some" ;) | 05:53 |
| 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:55 |
| 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:57 |
| spiv | So going from "bzr init . ; bzr add" to "bzr commit", it will double the disk usage (ignoring the gzipping). | 05:59 |
| jamesh | jdub: it depends on how well the binary compresses | 06:01 |
| jamesh | same for text | 06:01 |
| spiv | jdub: still here? | 06:06 |
| jdub | yeah, sorry | 06:10 |
| jdub | back | 06:10 |
| spiv_ | <spiv> I'm not sure what you mean. | 06:11 |
| spiv_ | <spiv> The initial commit has to make a copy of the file to record it in the repo. | 06:11 |
| spiv_ | <spiv> So going from "bzr init . ; bzr add" to "bzr commit", it will double the disk usage (ignoring the gzipping). | 06:11 |
| spiv_ | <spiv> bzr doesn't cope particularly gracefully with large files yet (binary or not). | 06:11 |
| spiv_ | <spiv> (hooray, lag) | 06:11 |
| spiv_ | <spiv> 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:11 |
| 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:12 | |
| jamesh | ISO images? | 06:13 |
| spiv_ | Ah-hah. I thought you might have large files given that you were worried about repo size... | 06:13 |
| jdub | jamesh: almost -- windows xp install files 8) | 06:14 |
| === spiv_ is now known as spiv | ||
| jamesh | jdub: ah. 514 MB of files total rather than a single 514 MB file | 06:15 |
| jdub | yeah | 06:15 |
| 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:23 |
| spiv | The good thing about compressed files is they typically have \n bytes at regular intervals... | 06:24 |
| weigon_ | jelmer: g'morn ... bzr branch against a svn-tree still doesn't work: http://p.caboo.se/111476 | 10:03 |
| fullermd | Boy, it sure is nice and quiet when everybody's off at meetings... | 14:48 |
| lifeless | morning | 15:06 |
| 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:07 |
| lifeless | heh | 15:17 |
| lifeless | hi thumper, phanatic | 15:45 |
| phanatic | hey lifeless | 15:45 |
| thumper | lifeless: howdy | 15:45 |
| Verterok | beuno: ping? | 16:49 |
| beuno | Verterok, pong! | 16:55 |
| Verterok | Hi! | 16:55 |
| bialix | hey lifeless | 16:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| Verterok | beuno: xml correctness in deep merges | 16:59 |
| 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:00 |
| 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:01 |
| beuno | Verterok, so it's when you have nested merges? how does the regular bzr log output show that? it keeps tabulating? | 17:02 |
| 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:03 |
| Verterok | beuno: the nested merge is revno 2208.4.4 | 17:06 |
| beuno | Verterok, that's odd, 2447.1.7 is only one level deep | 17:07 |
| beuno | I see 2466 > 2447.1.7 | 17:07 |
| 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:08 |
| 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:10 |
| 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:11 |
| 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:12 |
| * Verterok agrees | 17:13 | |
| 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:14 |
| Verterok | beuno: I finished almost all unittest, only misssing is missing (what a problem ;) ) | 17:15 |
| beuno | Verterok, hahahah, I saw, I'm still not sure how the tests work though, haven't played around with em | 17:16 |
| Verterok | beuno: no prob, I'll write it. | 17:17 |
| Verterok | beuno: Also, I created a XMLLineLogFormatted to use it in pending merges, i think it can be usefull for missing | 17:18 |
| 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:19 |
| Verterok | sure! if you need some help, and I can do something, just tell | 17:21 |
| 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:22 |
| 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:24 |
| beuno | because I only fixed it where I had the problem, didn't sanitize all the XML as I probably should of | 17:25 |
| 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:26 |
| Verterok | beuno: the branch-nick it's handled in log, but not in version, fixing it. thanks! | 17:27 |
| beuno | Verterok, np, you're basically fixing things that I won't have to, so it's convenient :D | 17:28 |
| 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:29 |
| 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:30 |
| beuno | that might make it easier to re-use that bit of code from everywhere else | 17:31 |
| 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:32 |
| 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:33 |
| beuno | Verterok, right, the code *is* already structured pretty much that way... | 17:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| Verterok | yes, last night I make some cleanup of the xml logger and started to work that way cheking the merge_depth value | 17:40 |
| beuno | ah, you've been doing a lot of "doing", I haven't gotten past tossing it around in my head | 17:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:49 |
| Verterok | tought, the pre_alpha warning scared some users :P | 17:51 |
| Verterok | maybe a "its' beta" warning is more user friendly :D | 17:51 |
| * Verterok lunch | 17:55 | |
| === Verterok is now known as Verterok__ | ||
| Verterok__ | beuno: seeya later | 17:55 |
| beuno | Verterok__, buen provecho | 17:56 |
| Verterok__ | thx! | 17:57 |
| === AnMaster_ is now known as AnMaster | ||
| hsn_ | release schedule for 0.92? | 20:44 |
| === Verterok__ is now known as Verterok | ||
| jelmer | weigon_: thanks, fixd | 23:02 |
| weigon_ | what ever I touch breaks :) | 23:02 |
| jelmer | that was actually a bit of carelessness on my side | 23:03 |
| Peng | "knitpack"? Not "knit-pack"? | 23:05 |
| 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:06 |
| 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' | 23:08 |
| === me_too is now known as too_short | ||
| === too_short is now known as me_too | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!