| lifeless | Noldorin: so, as best as I can see here is whats happening: | 00:00 |
|---|---|---|
| lifeless | bzr asks for lock/held to be renamed | 00:00 |
| lifeless | its not renamed | 00:00 |
| Noldorin | right | 00:01 |
| lifeless | bzr does an rm and rmdir which do not error, so bzr assumes they succeeded(or perhaps we ignore errors at this stage - I'll check in a second) | 00:01 |
| lifeless | bzr then tries to take out a new lock, and it fails because the old one is there. | 00:01 |
| lifeless | this suggests to me that the FTP server is a) running on windows and b) is keeping a file open within lock/held - either the directory is the cwd for a thread, or the lock/held file still has a read handle open in the ftp server | 00:02 |
| lifeless | or | 00:02 |
| lifeless | a virus scanner or other async task has opened the lock/held/info file or lock/held directory and thus prevents the ftp server from doing the rena,e | 00:02 |
| lifeless | now, I've just checked our code | 00:03 |
| lifeless | we do the rename (held, RANDOM) unconditionally, without try:except: | 00:04 |
| Noldorin | hmm, what you're saying seems to make sense to me. | 00:04 |
| lifeless | so that call isn't returning an FTP error | 00:04 |
| Noldorin | right | 00:04 |
| lifeless | the delete of the info file is the same, bzr is not receiving an error. | 00:04 |
| Noldorin | so the problem is that windows is holding a lock on the file? | 00:04 |
| lifeless | we do catch a specific error on the rmdir of the temporary directory, but I can tell from the log that this isn't happening. | 00:04 |
| Noldorin | a lock on the lock file, that is | 00:05 |
| lifeless | Noldorin: yes, I believe so. | 00:05 |
| lifeless | or something like that | 00:05 |
| Noldorin | heh | 00:05 |
| Noldorin | well i'm glad we're starting to understand the root cause of this now | 00:05 |
| Noldorin | i suspected from the start is just wasn't a great FTP server :( | 00:05 |
| Noldorin | hrmm | 00:06 |
| Noldorin | lifeless: can you consider any simple workaround for this issue, or would i in fact have to change FTP servers to resolve it? | 00:08 |
| lifeless | what FTP server is it, if you don't mind me asking? | 00:09 |
| Noldorin | lifeless: it's a windows 2003 server hosted by storm internet. more than that, i do not know | 00:11 |
| lifeless | ah | 00:11 |
| Noldorin | oh lol | 00:11 |
| Noldorin | it dos say actually | 00:11 |
| Noldorin | when i log in | 00:11 |
| Noldorin | Microsoft FTP Service | 00:11 |
| Noldorin | so IIS6 i presume | 00:11 |
| lifeless | ok | 00:11 |
| lifeless | my guess is a virus scanner actually. | 00:11 |
| Noldorin | interesting | 00:11 |
| lifeless | virus scanners have caused trouble for bzr users in the past, without ftp being involved | 00:12 |
| Noldorin | i do succeed with the command *once* in a while | 00:12 |
| lifeless | with similar symptoms | 00:12 |
| Noldorin | but not often | 00:12 |
| Noldorin | would that sound right to you? | 00:12 |
| Noldorin | hmm | 00:12 |
| lifeless | it does sound plausible | 00:12 |
| lifeless | consider that the virus scanner is opening, reading, closing the files that are written, shortly after they are written | 00:12 |
| lifeless | if the unlock rename takes place too quickly, it and the virus scanner will be trying to do things concurrently | 00:13 |
| lifeless | we can test this | 00:13 |
| lifeless | lets add a 2 second delay on unlock | 00:13 |
| Noldorin | lifeless: but surely the scanner would only be looking at the files i'm dealing with momentarily? | 00:13 |
| lifeless | bzrlib/lockdir.py | 00:13 |
| Noldorin | ok | 00:13 |
| Noldorin | sure | 00:13 |
| lifeless | the unlock() method in that file | 00:14 |
| Noldorin | lifeless: i should warn you know, i haven't really coded python before :) | 00:14 |
| Noldorin | though i can read it well enough | 00:14 |
| Noldorin | ok | 00:14 |
| lifeless | at the top of that method, after the docstring. | 00:14 |
| lifeless | put | 00:14 |
| lifeless | time.sleep(2) | 00:14 |
| lifeless | this will make things rather slow :) but if it makes them reliable on ftp, we will have some data. | 00:14 |
| Noldorin | ok | 00:16 |
| Noldorin | lifeless: right. compiled now | 00:17 |
| Noldorin | lifeless: push again? (with -Dtransport?) | 00:19 |
| lifeless | yes please | 00:20 |
| Noldorin | http://pastebin.ca/1523399 | 00:22 |
| lifeless | no joy :( | 00:22 |
| Noldorin | :( | 00:22 |
| Noldorin | so what does that mean, you think? | 00:22 |
| Noldorin | virus scanner or not? | 00:22 |
| lifeless | I'm not sure | 00:23 |
| lifeless | how often has it worked - 1 in 10 ? 1 in 3? | 00:23 |
| Noldorin | 1 in 20 maybe | 00:23 |
| lifeless | ok | 00:23 |
| lifeless | well please try 4 more times | 00:24 |
| lifeless | if it has helped we'd expect a significantly better success rate | 00:24 |
| Noldorin | lifeless: rubbish. just realised i ran the wronbg bzr.exe | 00:24 |
| lifeless | but not necessarily perfect | 00:24 |
| Noldorin | sorry, let me try again | 00:24 |
| Noldorin | http://pastebin.ca/1523402 | 00:26 |
| Noldorin | lifeless: that's the actual one :P | 00:26 |
| lifeless | doesn't look like a 2 second delay to me | 00:27 |
| lifeless | add a | 00:27 |
| lifeless | print "waiting two seconds" | 00:27 |
| lifeless | line there as well | 00:27 |
| Noldorin | ok | 00:27 |
| poolie1 | hello all | 00:28 |
| lifeless | hi poolie1 | 00:28 |
| Noldorin | lifeless: http://pastebin.ca/1523408 | 00:31 |
| Noldorin | that should be the onw finally | 00:31 |
| Noldorin | one* | 00:31 |
| lifeless | it printed out the message to you? | 00:32 |
| Noldorin | yep | 00:32 |
| Noldorin | lifeless: http://pastebin.ca/1523409 | 00:33 |
| lifeless | I'm going to get you to move the sleep statement | 00:34 |
| Noldorin | ok | 00:34 |
| lifeless | can you move it down to right above the line | 00:34 |
| lifeless | self.transport.rename(self._held_dir, tmpname) | 00:34 |
| lifeless | (move the print with it) | 00:34 |
| lifeless | you'll need to indent, with spaces, to line up. | 00:35 |
| lifeless | as python is whitespace sensitive | 00:35 |
| Noldorin | yep, i'm aware of that much :) | 00:35 |
| lifeless | cool :) | 00:35 |
| Noldorin | but thanks | 00:35 |
| lifeless | the reason we're moving it i s that the log shows a read right before the rename | 00:36 |
| lifeless | and the hypothetical virus scanner could be doing on-demand scanning too | 00:37 |
| lifeless | this should give it time to quiesce | 00:37 |
| Noldorin | got it | 00:37 |
| igc | morning all | 00:39 |
| igc | hi poolie1, lifeless | 00:39 |
| Noldorin | lifeless: http://pastebin.ca/1523414 | 00:39 |
| poolie1 | hi igc | 00:41 |
| lifeless | Noldorin: ok, thats clearly got a 2 second gap. try repeating this 3 or 4 times | 00:42 |
| lifeless | just to see if it fails less often than an unmodified bzr | 00:42 |
| Noldorin | ok sure | 00:42 |
| lifeless | back in a few minutes | 00:44 |
| Noldorin | lifeless: no luck | 00:48 |
| Noldorin | lifeless: i need to go now unfortunately | 00:52 |
| Noldorin | (it's quite late here) | 00:53 |
| Noldorin | will talk to you again soon hopefully | 00:53 |
| Noldorin | again, thanks for all the help :) | 00:53 |
| igc | poolie1: you're intending to release 1.18rc today, yes? | 00:53 |
| poolie1 | yes | 00:53 |
| Noldorin | bye | 00:53 |
| igc | poolie1: can you co-ordinate with me before announcing? I'd like to build the docs before then and have them uploaded | 00:54 |
| igc | poolie1: I believe that RT request for sphinx is still outstanding so I'll need to do it by hand | 00:54 |
| igc | poolie1: also the alldocs website has been translated to Japanese, French and Russian now so it will be cool to roll those out at the same time! | 00:55 |
| poolie1 | wow, nice one | 00:56 |
| spiv | Good morning. | 00:59 |
| jelmer | james_w`: what are these "collision" type bug reports about? | 01:50 |
| GoStOzInhO | entrem na sala do brasil | 02:15 |
| GoStOzInhO | valew | 02:15 |
| GoStOzInhO | jklçj | 02:35 |
| GoStOzInhO | kfhkf | 02:35 |
| GoStOzInhO | kfhkg | 02:35 |
| GoStOzInhO | hgk | 02:35 |
| GoStOzInhO | kfgk | 02:35 |
| GoStOzInhO | gkfgkh | 02:35 |
| GoStOzInhO | fgk | 02:35 |
| GoStOzInhO | khgfk | 02:35 |
| lifeless | poolie1: zing! bug 410745 | 02:45 |
| ubottu | Launchpad bug 410745 in bzr "PPA GPG key needs more signatures" [Wishlist,Incomplete] https://launchpad.net/bugs/410745 | 02:45 |
| poolie1 | mm? | 02:46 |
| lifeless | oh, perhaps you didn't intend the sarcasm in your comment? | 02:46 |
| poolie1 | oh the last comment? | 02:47 |
| lifeless | yah | 02:47 |
| poolie1 | well, not much | 02:47 |
| poolie1 | what do you think of it? | 02:49 |
| lifeless | I don't think the reporter understands the ppa system | 02:51 |
| poolie1 | how about comment #5? | 02:52 |
| lifeless | as jelmer says, someone that can change a ppa archive signature can suborn the buildds to output different binaries under the original key | 02:52 |
| lifeless | hang on, let me start up a browser. | 02:52 |
| lifeless | clearer :) | 02:53 |
| * igc lunch | 04:30 | |
| lifeless | EOD | 06:56 |
| vila | hi all | 07:06 |
| LarstiQ | moin vila | 07:56 |
| vila | hey LarstiQ | 07:57 |
| LarstiQ | lifeless: did you see my question about what the correct submit branch is for me to submit changes to pqm for 1.17.1? | 07:59 |
| poolie1 | hello vila | 08:01 |
| poolie1 | LarstiQ: it should be http://bazaar-vcs.org/bzr/bzr.1.17 | 08:01 |
| LarstiQ | then maybe I'm just not authorized | 08:02 |
| LarstiQ | or should leave the slash off? | 08:03 |
| LarstiQ | All lines of log output:Sender not authorised to commit to branch http://bazaar-vcs.org/bzr/bzr.1.17/ | 08:03 |
| * LarstiQ tries again | 08:03 | |
| spm | lifeless: spiv: hrm. still no joy. 1. use trash icon in LP UI, remove existing 1.18 2. ~/source/bzr.dev/bzr branch .. to get local 1.18; info -v on this looks fine. 3. ~/source/bzr.dev/bzr push --remember to lp. Have verified it's landing on a different area /00/02/a9/99/ ==> /00/02/a9/9a/ for the new. | 08:03 |
| spm | still getting: bzr: ERROR: Server sent an unexpected error: ('error', "KnitPackRepository('lp-45197264:///~bzr-pqm/bzr/1.18/.bzr/repository') has no revision pqm@pqm.ubuntu.com-20090807010459-nw1f0r9y1igi19xf") | 08:03 |
| spm | bzr.dev/bzr is 1.17. Halp? | 08:04 |
| spiv | spm: huh. | 08:04 |
| poolie1 | LarstiQ: leave the slash off, it's too picky | 08:05 |
| poolie1 | because pqm just matches the string, i think it doesn't know anything about the way bzr would interpret that url | 08:05 |
| spm | spiv: I'm happy to do the "idiot do exactly this"; it may be pebkac.... :-/ | 08:05 |
| vila | spm: Are you sure you access the same branch on the super mirror ? I.e. do you have write access in both cases ? Otherwise you may access a different copy in read-only mode | 08:05 |
| spiv | spm: I don't see an obvious pebkac in that description. | 08:05 |
| spiv | It *is* 5pm, though, which is prime time for overlooking pebkacs! | 08:06 |
| spm | spiv: exactly my thinking :-) | 08:06 |
| spm | vila: I assume I would have Write access - this is as the pqm user for bzr, so if that has issues.... :-) | 08:07 |
| spm | I'll paste the session. one sec. | 08:07 |
| spiv | spm: that'd be good. Hang on -- it's failing on *push*? | 08:08 |
| vila | spm: ok, just checking, the write-branch not mirrored on the read-branch in some cases was worth a try, it's a hard one to realize otherwise | 08:08 |
| spm | spiv: vila: https://pastebin.canonical.com/20949/ | 08:08 |
| spm | spiv: no pushed fine, it's an info that barfs | 08:08 |
| spiv | Ah, ok. | 08:08 |
| spm | if you info locally, you should see it as well; certainly I do. | 08:08 |
| spm | vila: ah, right. | 08:09 |
| poolie1 | any suggestions for stuff to mention in the announcement, beyond what's in NEWS already? | 08:09 |
| spiv | Ah, it may just be a bug in server-side HPSS info on a stacked branch? | 08:09 |
| spiv | spm: the important question is "does bzr branch via bzr+ssh work?", I'm testing that atm. It appears the answer is yes. | 08:10 |
| spm | spiv: so info may be a red herring of sorts? | 08:10 |
| spiv | Yeah. A bug, not an important one, and not due to a pebkac. Well, that's my current hypothesis anyway. | 08:11 |
| spiv | Not important in this context, obviously it's a fairly important bug for bzr to fix :) | 08:11 |
| spm | heh | 08:12 |
| spiv | Hmm, I can't trivially reproduce with another stacked branch. Curious! | 08:12 |
| spm | spiv: worth getting me to try and reproduce with eg debugging mode on? | 08:12 |
| spm | eg push to bzr-1.18-break-me-if-you-dare ? | 08:13 |
| spiv | I wonder if any new stacked branch (i.e. with no data of its own) will trigger... | 08:13 |
| LarstiQ | poolie1: hmm, http://pqm.bazaar-vcs.org/ again mentions: Request for non-PQM managed branch. | 08:13 |
| spiv | spm: nah, just file a bug | 08:14 |
| spm | heh, oki | 08:14 |
| spiv | spm: paste/link that session, etc. | 08:14 |
| spiv | spm: I think we can figure it out from there without pestering you further :) | 08:14 |
| * spm is spoilt for rude choices to respond with, so won't. ;-) | 08:15 | |
| spiv | :) | 08:15 |
| poolie1 | LarstiQ: um check with spm? | 08:16 |
| spm | LarstiQ: how long ago, and was this against an lp:bzr style branch? | 08:17 |
| spiv | spm: FWIW, I can reproduce with a new stacked branch I make myself. | 08:17 |
| spm | spiv: cool | 08:17 |
| LarstiQ | spm: merge http://bazaar.launchpad.net/~spiv/bzr/bzr-1.17 http://bazaar-vcs.org/bzr/bzr.1.17 | 08:18 |
| LarstiQ | spm: mail to pqm was at 07:13 UTC | 08:20 |
| vila | spm: we still have problems with lp: style branches ? (Trying to keep up without trying myself :-/) | 08:20 |
| spm | vila: yeah - hence my question. that &*%^*&$^&^%$(*&^(&^$&^%#$&^&%)(*&^*&^$&*%^$&^%$ing ~/.bazaar/authentication.conf was back again. | 08:21 |
| LarstiQ | spm: would you be the one to do the pqm upgrade part of https://bugs.edge.launchpad.net/bzr/+bug/390502 (or is that even what you're doing right now?) | 08:21 |
| ubottu | Launchpad bug 390502 in bzr "bzr's development should dogfood format 2a" [High,Confirmed] | 08:21 |
| vila | spm: authentication.conf is involved, my word, who would have thought ? | 08:21 |
| spm | LarstiQ: I'm one of the losa's; so somewhat yes; and I believe 1.17 is 2a already? I was creating the pqm config setup for 1.18. | 08:23 |
| LarstiQ | spm: 1.17 reads 2a, yes | 08:24 |
| * spiv heads off for the evening (doing yoga on Monday for a change) | 08:24 | |
| spm | LarstiQ: "Sender not authorised to commit to branch http://bazaar-vcs.org/bzr/bzr.1.17" | 08:25 |
| spm | LarstiQ: recent gpg key change or anything? | 08:26 |
| LarstiQ | spm: nope, same key I've used recently to submit to bzr.dev pqm | 08:27 |
| LarstiQ | spm: could be that 1.17 has a more restricted list? | 08:27 |
| LarstiQ | or, peraps, the mail is not getting signed | 08:27 |
| spm | possibly the latter? try again? looking atthe main pqm log, it all looks correct. email from the correct sender and all. | 08:28 |
| LarstiQ | --dry-run does show it getting signed | 08:29 |
| spm | hmm. well poolies got something in the queue atm, see if that works for him; ie effects all vs just you. | 08:29 |
| spm | crap | 08:30 |
| LarstiQ | spm: iirc spiv also had trouble submitting for the 1.17 queue | 08:30 |
| spm | about 12 hours ago? | 08:31 |
| spm | spiv: ^^ ? | 08:31 |
| LarstiQ | hmm, longer ago I think | 08:31 |
| * LarstiQ checks mail | 08:31 | |
| spm | gah. he's at yoga. | 08:31 |
| spm | 2009-08-09 18:19 - was a fail, same reason | 08:32 |
| lifeless | LarstiQ: its on lp now | 08:32 |
| lifeless | I thought I sent mail about that? | 08:32 |
| LarstiQ | lifeless: ah, that explains it. | 08:33 |
| lifeless | spm: none of the bzr branches should be in 2a format yet. | 08:33 |
| * lifeless is gone again | 08:33 | |
| LarstiQ | lifeless: thanks! | 08:33 |
| spm | LarstiQ: ah. the one I'm looking at, is one of yours. | 08:35 |
| LarstiQ | spm: woops :) | 08:37 |
| spm | LarstiQ: which in a way is *some* good news - it's been busted for a while. :-) | 08:37 |
| LarstiQ | spm: I've sent another request, this time as lifeless suggested with the submit branch on lp, not bazaar-vcs.org | 08:38 |
| spm | boom. same error. | 08:39 |
| LarstiQ | ahem, forget the product | 08:39 |
| spm | LarstiQ: I've been summonsed to dinner. I'll have a look after, but I suspect it'll have to wait till tomorrow | 08:40 |
| LarstiQ | spm: eet smakelijk! | 08:41 |
| spm | errr? English? :-) | 08:41 |
| LarstiQ | spm: yay, got it going! | 08:41 |
| LarstiQ | spm: bon appetit? ;) | 08:41 |
| spm | yay! | 08:41 |
| spm | and g'night! | 08:41 |
| poolie1 | spm: now i'm being told i can't commit to 1.18 | 08:46 |
| poolie1 | is it still broken? or was pqm unhappy? | 08:46 |
| lifeless | poolie1: what url are you submitting to? | 08:47 |
| bialix | igc1: hi | 08:52 |
| === igc1 is now known as igc | ||
| poolie1 | merge http://bazaar.launchpad.net/~mbp/bzr/prepare-1.18 http://bazaar-vcs.org/bzr/bzr.1.18 | 08:52 |
| poolie1 | Command failed! | 08:52 |
| igc | hi bialix | 08:52 |
| poolie1 | All lines of log output:Sender not authorised to commit to branch http://bazaar-vcs.org/bzr/bzr.1.18 | 08:52 |
| poolie1 | hi bialix | 08:53 |
| bialix | igc: after 1-2 hours from now I'll start to prepare qbzr release. garyvdm said he will do release today, maybe he'll appear here soon | 08:54 |
| bialix | poolie1: hello | 08:54 |
| bialix | poolie1: today is release day? | 08:54 |
| igc | bialix: that sounds fine. It would have been nice to get qexport in before the 0.13 release but landing it at the start of 0.14 might be better? | 08:56 |
| poolie1 | yes, i just did it in fact | 08:56 |
| poolie1 | i didn't announce it yet - we can try to make packages first | 08:56 |
| === Noldorin_ is now known as Noldorin | ||
| bialix | poolie1: ok | 08:56 |
| igc | poolie1: ok, I'll build the docs now then | 08:56 |
| bialix | igc: qexport is not ready yet | 08:56 |
| lifeless | poolie1: since 1.17 they are on launchpad; I mailed the list at the time | 08:56 |
| lifeless | poolie1: I suspect I failed to land a doc update | 08:56 |
| poolie1 | i suspect you did | 08:56 |
| poolie1 | actually i know you did | 08:57 |
| poolie1 | maybe pqm rejected it :-P | 08:57 |
| lifeless | [sorry] | 08:57 |
| poolie1 | np | 08:57 |
| bialix | igc1: I've reviewed qexport yesterday, maybe you've missed my mail | 08:57 |
| igc | bialix: I did sorry | 08:57 |
| * lifeless is really really gone | 08:57 | |
| lifeless | ring me if you still have trouble | 08:57 |
| poolie1 | so submit_branch = http://bazaar.launchpad.net/~bzr/bzr/bzr.1.18 | 08:57 |
| igc | bialix: btw, explorer got preferences support over the weekend | 08:58 |
| igc | bialix: does Tools/Options work for you? | 08:58 |
| bialix | igc: I saw commit mails, will try it now | 08:58 |
| igc | bialix: I've only tested it on Ubuntu at this point | 08:58 |
| bialix | igc: http://imagebin.ca/view/yMiG8e7.html | 09:00 |
| bialix | Suite has only one option: qbzr | 09:01 |
| igc | bialix: that's right. gtk will only appear if bzr-gtk is installed | 09:01 |
| bialix | ok | 09:01 |
| igc | bialix: do the toolbar preferences work ok on Windows? | 09:02 |
| bialix | I believe official plugin name is QBzr, but people usually understand either case | 09:02 |
| igc | bialix: and maybe the dialog ought to be called Options on Windows | 09:02 |
| bialix | while switching content to expanded I've got traceback | 09:02 |
| igc | bialix: as a setting, it's the python package name used for the plugin | 09:02 |
| bialix | igc: http://pastebin.com/m348e2c2c | 09:03 |
| igc | bialix: I need to i18n all those combo choices as I don't really want to expose the internal values | 09:03 |
| bialix | style working ok | 09:03 |
| igc | bialix: but my QComboBox foo isn't up to it yet | 09:03 |
| bialix | igc: I will be able to look at i18n stuff only tomorrow | 09:04 |
| bialix | da you want me to file bug report? | 09:04 |
| bialix | *do | 09:04 |
| bialix | (something wrong with my keyboard) | 09:04 |
| igc | bialix: please | 09:05 |
| bialix | hmm | 09:06 |
| bialix | it works now | 09:06 |
| vila | bialix: blame the gremlins | 09:06 |
| bialix | bonjour vila! | 09:06 |
| vila | hi bialix :) | 09:07 |
| bialix | igc: gremlins here | 09:09 |
| bialix | igc: I'm not sure about bug report now | 09:09 |
| igc | bialix: try deleting explorer.conf - it will be a one-off init bug | 09:09 |
| bialix | igc: gotcha! | 09:10 |
| bialix | vila: gremlin name was 'explorer.conf' | 09:12 |
| vila | that kind of bug is really annoying especially for *non* devs as they are a royal pain to even understand (there was one in bzr-gtk that remained hidden for months....) | 09:13 |
| vila | mabey years even | 09:13 |
| bialix | igc: https://bugs.launchpad.net/bzr-explorer/+bug/411304 | 09:15 |
| ubottu | Launchpad bug 411304 in bzr-explorer "Tools -> Options: changing contents to `expanded` fails if there is no explorer.conf" [Undecided,New] | 09:15 |
| bialix | ubottu is really fast! | 09:15 |
| ubottu | Sorry, I don't know anything about is really fast! | 09:15 |
| bialix | good ubottu, take a cookie | 09:15 |
| * bialix bbl | 09:19 | |
| * igc dinner | 09:37 | |
| lvh | hi :-) | 10:00 |
| === Noldorin_ is now known as Noldorin | ||
| ronny | jelmer: aware of any docs for the git http proto? i would implement a wsgi app for dulwich | 10:33 |
| ronny | hmm, meh | 10:35 |
| ronny | the more i read about it, the more it seems like one doesnt actually want that | 10:35 |
| LarstiQ | vila: where can I find the buildbot status page? | 11:22 |
| bialix | hi garyvdm | 11:26 |
| garyvdm | Hi bialix | 11:26 |
| === Noldorin_ is now known as Noldorin | ||
| garyvdm | I'm fixing bug 395937, then I'm going to do the release | 11:27 |
| ubottu | Launchpad bug 395937 in qbzr "qannotate: Crash when opening qbzr/lib/log.py annotate from qbrowse" [High,Confirmed] https://launchpad.net/bugs/395937 | 11:27 |
| garyvdm | I'm not sure if I will include the fix or not. I'm worried about lack of testing. | 11:28 |
| garyvdm | If not - I will include the fix that we had for 0.12 | 11:28 |
| bialix | garyvdm: I have problem with proper disabling of UI when operation starte | 11:28 |
| bialix | started | 11:28 |
| bialix | did you saw it? | 11:28 |
| bialix | or this is again Qt 4.4 bug... | 11:29 |
| garyvdm | bialix: I do remember seeing something. I did not look in detail, and now I cant find it. Was it in a mail, or a bug? | 11:30 |
| bialix | nope | 11:30 |
| bialix | no mail no bug | 11:30 |
| bialix | I've recently change signal subprocessStarted et al to disableUi | 11:31 |
| garyvdm | Ok - That'ss what I saw. | 11:31 |
| bialix | and now I see that UI disabled and then enabled once there is incoming data from subprocess | 11:31 |
| garyvdm | LarstiQ: The reason why there is no syntax highlighting in unidiff, is it would overwrite the colors for unidiff. | 11:32 |
| bialix | actually I see it everytime I do qpull | 11:32 |
| garyvdm | ok | 11:32 |
| garyvdm | Let me try reproduce. | 11:32 |
| bialix | garyvdm: is there some debug utility for qt to trace signals? | 11:32 |
| LarstiQ | garyvdm: right, I'd like both :) | 11:33 |
| garyvdm | bialix: Not that I know of. It can be quite frustrating. | 11:33 |
| LarstiQ | bialix, garyvdm: there is, QSignalSpy | 11:34 |
| * bialix googling | 11:34 | |
| LarstiQ | last I checked that didn't have PyQt bindings though | 11:35 |
| bialix | LarstiQ: it seems it's still none | 11:35 |
| garyvdm | LarstiQ: So would the unidiff colors overwrite the syntax colors? | 11:37 |
| garyvdm | or the other way arround? | 11:37 |
| LarstiQ | garyvdm: I'd go with backgrounds ala side-by-side deletion/addition blocks | 11:38 |
| garyvdm | Ok | 11:38 |
| garyvdm | Like launchpad | 11:38 |
| LarstiQ | euh, possibly :) | 11:38 |
| * LarstiQ takes a look | 11:38 | |
| LarstiQ | garyvdm: I'm coming from vim myself | 11:38 |
| bialix | garyvdm: I found! | 11:39 |
| garyvdm | LarstiQ: can you send me a screen shot. | 11:39 |
| bialix | garyvdm: the problem in on_error method | 11:39 |
| garyvdm | bialix: I can reproduce on linux with qt4.5 | 11:39 |
| * garyvdm looks at on_error | 11:39 | |
| bialix | it seems some code calling on_error all the time | 11:40 |
| bialix | garyvdm: it seems readStderr send it | 11:41 |
| bialix | oh | 11:41 |
| LarstiQ | garyvdm: hmm, I realize that's actually more of a side-by-side than unidiff thing | 11:42 |
| garyvdm | Yes - So something is writing to stderror that should not be? | 11:42 |
| bialix | it's never ending discussion: does bzr should emit non-error messages to stderr? | 11:42 |
| bialix | well | 11:42 |
| bialix | garyvdm: bzr writing to stderr too much data | 11:42 |
| bialix | not errors! | 11:42 |
| bialix | and this is known intended behavior | 11:42 |
| bialix | rats | 11:42 |
| LarstiQ | garyvdm: but basically one background color for old and one for new makes sense to me | 11:42 |
| bialix | LarstiQ: IIRC unidiff has used bg colors instead of fg | 11:43 |
| bialix | but then luks has changed it this way | 11:43 |
| bialix | perhaps to avoid height problems | 11:43 |
| garyvdm | bialix: no height problems in unidiff. | 11:44 |
| garyvdm | may be another reason. | 11:44 |
| bialix | perhaps just for estetic reasons | 11:44 |
| garyvdm | bialix: We could emit only if a line starts with "bzr: ERROR:" | 11:45 |
| bialix | I remeber his comment: if somebody want old behavior -- then make it configurable | 11:45 |
| bialix | garyvdm: I think I'm just remove my signal from on_error | 11:45 |
| bialix | if I found the case whne it's needed, I'll try to figure out how to deal with this problem | 11:46 |
| bialix | so for now (for release) I'll stick with this | 11:46 |
| garyvdm | Oh yes - the ui should be enabled on failed/finished. | 11:46 |
| bialix | fte | 11:47 |
| bialix | (wrong window) | 11:47 |
| LarstiQ | bialix: ok, I'll go look for luks change | 11:51 |
| bialix | LarstiQ: ? | 11:52 |
| jml | hello from Prague | 11:52 |
| bialix | jml: hi | 11:52 |
| LarstiQ | bialix: and see about what he wanted made configurable | 11:52 |
| bialix | LarstiQ: IIUC colors | 11:53 |
| bialix | what color should be used for + or - | 11:53 |
| bialix | ink and papaer colors pair | 11:53 |
| bialix | paper | 11:53 |
| LarstiQ | bialix: makes sense | 11:54 |
| bialix | LarstiQ: it was changed long ago | 11:54 |
| bialix | around end of 2007 - beginning of 2008 | 11:54 |
| bialix | LarstiQ: revno 186 | 11:59 |
| bialix | btw, garyvdm , I'd like to measure speed of syntax highlighting | 12:00 |
| garyvdm | --lsprof | 12:00 |
| bialix | perhaps it's one of major slowdown factor for qdiff I see all the time with big files | 12:01 |
| garyvdm | Probably correct. | 12:01 |
| bialix | well, I'm thinking about put time.time() in some points here and there and looks at numbers | 12:01 |
| bialix | there is another narrow place: detector of NUL bytes | 12:02 |
| garyvdm | bialix: --lsprof will give you a good estimate. | 12:02 |
| bialix | why --lsprof? | 12:02 |
| garyvdm | I wonder if you can run KCachegrind on windows. | 12:03 |
| luks | woo, looking at history is cool. nice to see the commit dialog from qbzr r1 still working :) | 12:03 |
| ronny | jelmer: how does one propperly set the commit date of a svn rev using subvertpy, passing svn:date as revprop seems to fail | 12:03 |
| garyvdm | luks: :-) | 12:03 |
| bialix | luks: hi :-) | 12:04 |
| luks | hey | 12:04 |
| garyvdm | bialix: have you ever use --lsprof[-file]. It gives you the time spent in each method. | 12:04 |
| garyvdm | Then I use KCachegrind to browse through the data. Before I used excel on windows to browse. | 12:05 |
| bialix | garyvdm: I think I've always used just plain --profile | 12:05 |
| garyvdm | Oh | 12:05 |
| bialix | garyvdm: I was under impression it does not work here | 12:05 |
| garyvdm | bialix: the other way the will give you a more accurate measurement is to time it, and them time it with pygments uninstalled. | 12:06 |
| bialix | what is lsprof? | 12:07 |
| bialix | I can't find it in standard python docs | 12:07 |
| bialix | it's 3rd party lib? | 12:07 |
| garyvdm | See bzr help global-options | 12:07 |
| LarstiQ | bialix: yes, but it got into 2.5 (or 2.6?) as `profile` | 12:07 |
| LarstiQ | bialix: however, it doesn't publically expose some of the lsprof methods we were using | 12:08 |
| bialix | --profile calims it uses hotshot std lib | 12:08 |
| bialix | hmm | 12:09 |
| bialix | cProfile, a module written in C, with a reasonable overhead that makes it suitable for profiling long-running programs. Based on lsprof, contributed by Brett Rosen and Ted Czotter. New in version 2.5. | 12:09 |
| bialix | that's one? | 12:09 |
| LarstiQ | bialix: yeah | 12:09 |
| bialix | I'm using it for my own programs | 12:09 |
| bialix | very useful | 12:09 |
| LarstiQ | bialix: do you also use the callgrind output it can generate? | 12:10 |
| bialix | callgrind? | 12:10 |
| luks | imo the main advantage of lsprof is generating the call tree | 12:10 |
| luks | messing with kcachegrind was so useful when I was working on the c patiencediff | 12:11 |
| garyvdm | bialix: KCachegrind is what I use to look at the .callgrind. I'm not sure if you can run it on windows though. | 12:11 |
| garyvdm | bialix: there are 2 things to measure for syntax highlighting: How long pygments takes, and how much extra it takes the QTextBrowser to do the format. | 12:11 |
| bialix | http://docs.python.org/library/profile.html#module-pstats | 12:11 |
| bialix | I'm using output as in docs | 12:12 |
| bialix | QTextBrowser definitely slow to render our diffs with lines | 12:12 |
| bialix | it is long standing wish to put every file diff in separate tab | 12:13 |
| bialix | I wonder if it helps with scolling slowness | 12:13 |
| bialix | *scrolling | 12:13 |
| garyvdm | Scrolling slowness? | 12:13 |
| garyvdm | Are you maybe trying to scroll before it's finished loading? | 12:14 |
| bialix | when you have a big diff in many files then scroll down the entire diff is dead slow | 12:14 |
| bialix | does not matter actually | 12:14 |
| bialix | it slow even after loading is finished | 12:14 |
| === mrevell is now known as mrevell-lunch | ||
| garyvdm | That might be our code that is drawing the lines. | 12:15 |
| bialix | as good example of slowness we can use any qbzr revno where I did "sync translations with lp" | 12:16 |
| bialix | there is a lot changes in many files | 12:16 |
| garyvdm | luks: Why did you change annotate from using a QTextBrowser, to using a list controll? | 12:16 |
| luks | garyvdm: I wanted columns | 12:17 |
| bialix | is it possible to force text selection with mouse here? | 12:17 |
| luks | yes, but probably not easily | 12:18 |
| garyvdm | But you were using a html table. What was the problem with that? The reason I'm asking is that I think that might be the solution to not been able to select text. | 12:18 |
| * bialix mutters: we really needs policy to land new features with corresponding NEWS entry | 12:19 | |
| luks | you can't resize the columns in a html table | 12:19 |
| luks | and names can get quite wide | 12:19 |
| garyvdm | bialix: sorry - I'm bad with that. | 12:19 |
| garyvdm | luks: ok - I see | 12:19 |
| bialix | garyvdm: ok, so I leave NEWS for 0.13 for you | 12:20 |
| luks | but it's not that I use qannotate anyway | 12:20 |
| luks | I was mostly just copying qannotate :) | 12:20 |
| bialix | copying qannotate? | 12:20 |
| luks | I mean gannotate | 12:20 |
| garyvdm | It would also be nice if when you scroll horizontally in qannotate, it only scrolled the text, not all columns | 12:21 |
| bialix | luks: what you think about adding line numbers to qdiff? what QT widget need to be used? | 12:21 |
| luks | bialix: I'd like that, but we would have to write that ourselves | 12:22 |
| garyvdm | bialix: I see what you say about the scolling in qdiff. Is there a bug loged. | 12:22 |
| luks | you can have a margin in QTextBrowser | 12:22 |
| luks | but you need to draw it in your code | 12:22 |
| luks | the whole diff view should be a c++ widget | 12:22 |
| luks | there is too much slow python code | 12:22 |
| bialix | when I'm select the text to copy with margin, the numbers will be omiitted? | 12:23 |
| luks | no, the margin is totally separate | 12:23 |
| bialix | that's nice | 12:23 |
| luks | it's intended for line numbers in a text editor, mainly | 12:23 |
| bialix | luks: IIRC you has tried to start writing special C++ code for qdiff | 12:24 |
| garyvdm | luks: we could probably use that for annotate too. | 12:24 |
| luks | garyvdm: yeah, that could be one way to solve it | 12:24 |
| luks | garyvdm: but it would need some more code, to handle margin resizing | 12:24 |
| garyvdm | luks: oh yes | 12:25 |
| === Noldorin_ is now known as Noldorin | ||
| garyvdm | luks: What do you think of LarstiQ's idea to have the unidiff colors as background colors, so that we can do syntax highlighting in unidiff? | 12:28 |
| luks | garyvdm: we would need a custom painter for unidiff then | 12:29 |
| luks | garyvdm: or maybe not, but Qt used to not handle <div style="background-color:#..."> correctly when scrolling | 12:30 |
| garyvdm | luks - yes - if we want the background across the whole line | 12:30 |
| ronny | jelmer: what is this 1000000 magic factor in the subvertpy timestamp functions about? | 12:30 |
| garyvdm | luks: No - it does not have that abiliy afaik | 12:31 |
| bialix | is not div element should be resized on full width of window? | 12:32 |
| bialix | then it can draw background on full width | 12:32 |
| garyvdm | not in QTextBrowse | 12:32 |
| bialix | bad | 12:32 |
| * bialix bbl | 12:32 | |
| garyvdm | bialix: On thing that we currently do in qdiff is run the whole file through pygments. You could may be experiment with passing only the part of the file we diapaly through pygments | 12:32 |
| garyvdm | *display | 12:33 |
| bialix | I need to collect speed statistics first | 12:33 |
| bialix | btw, I like how WinMerge shows the diff | 12:34 |
| bialix | there is always full file | 12:34 |
| bialix | and deletion on each side shown as holes | 12:34 |
| luks | I'm not sure if pygments can do that | 12:34 |
| bialix | I'd like to accomodate this for qdiff | 12:34 |
| luks | higlighting parts of a file is a more complex problem | 12:35 |
| === cprov-afk is now known as cprov | ||
| jelmer | ronny: hi | 12:37 |
| jelmer | ronny: you can't change the commit date during a commit | 12:37 |
| jelmer | ronny: the only way you can change the commit time is by changing the revision property afterwards | 12:37 |
| jelmer | (which requires the commit hooks to be adjusted to allow that) | 12:38 |
| ronny | oh darn | 12:38 |
| ronny | jelmer: btw, why that magic timestamp factor? | 12:39 |
| jelmer | yes | 12:39 |
| jelmer | ronny: magic timestamp facto? | 12:39 |
| garyvdm | luks/bialix: When I get around to it, I want to create "qdiffmerge" which will allow 3-way diff, editing, and (this is why I want to write it, not just use meld) the ability to annotate in that window. | 12:40 |
| garyvdm | It's a big job, so I keep on putting it off :-~ | 12:40 |
| ronny | jelmer: the 1000000 you use in time_from/to_ctime | 12:40 |
| ronny | jelmer: how do i get the revno a commit created | 12:45 |
| ronny | meh, svn is fail :( | 12:45 |
| ronny | jelmer: i'll print a warning instead of setting a svn date for now | 12:48 |
| garyvdm | ->lunch, bbl | 12:49 |
| jelmer | ronny: there's a callback used by commit that will be called with the result author, date and revno | 13:02 |
| jelmer | ronny: the 10^6 stuff is used because that seems the times are usually usecs in the svn world | 13:04 |
| === mrevell-lunch is now known as mrevell | ||
| poolie1 | hi vila? | 13:23 |
| vila | poolie1: hey ! | 13:24 |
| ronny | jelmer: how can i use that calback stuff when using a ra editor | 13:40 |
| === james_w` is now known as james_w | ||
| === kiko-fud is now known as kiko | ||
| === Edwin is now known as Guest70933 | ||
| Ng | --help | 14:33 |
| garyvdm | Bazaar -- a free distributed version-control tool | 14:35 |
| garyvdm | http://bazaar-vcs.org/ | 14:35 |
| garyvdm | Basic commands: | 14:35 |
| garyvdm | bzr init makes this directory a versioned branch | 14:35 |
| garyvdm | ...... | 14:35 |
| === sabdfl1 is now known as sabdfl | ||
| === Guest70933 is now known as EdwinGrubbs | ||
| jelmer | ronny: you can specify a callback to get_commit_editor() | 15:56 |
| jelmer | I think it's called "done" or something in the docstring | 15:56 |
| ronny | its called callback | 16:18 |
| * SamB wonders why it is *repository formats* that are considered rich-root or not, rather than branches/revisions | 16:48 | |
| SamB | spiv: so, 1.18 *is* going to have this Repository.insert_stream_1.18 hpss method, yes? | 16:56 |
| jelmer | SamB: it's repositories that store revisions, not breanches and not working trees | 17:00 |
| SamB | jelmer: yeah, I know | 17:00 |
| SamB | but don't only some of the revisions actually use rich-root at all? | 17:01 |
| === ja1 is now known as jam | ||
| jam | ping vila about kerguelen :) | 17:04 |
| vila | jam: goood morning jam :) | 17:05 |
| jam | so... you have to delete bzrlib/_chunks_to_lines.pyd before running setup.py, as it loads osutils.py which loads chunks_to_lines | 17:06 |
| SamB | evil! | 17:07 |
| jam | SamB: evil-ish. Mostly that you can't delete an open file on Windows, which causes difficulties sometimes | 17:07 |
| SamB | jam: I meant having the C-ish module import a python module, actually ... | 17:08 |
| jam | SamB: it doesn't | 17:09 |
| jam | setup.py imports osutils.py imports chunks_to_lines.pyd | 17:09 |
| SamB | oh | 17:09 |
| jam | just that setup.py also *rebuilds* chunks_to_lines.pyd | 17:10 |
| jam | if it is considered out of date | 17:10 |
| jam | but it always fails if it already exists... | 17:10 |
| SamB | I guess I didn't interpret "it" correctly | 17:10 |
| === deryck is now known as deryck[lunch] | ||
| bialix | garyvdm: how it's going? | 17:20 |
| garyvdm | Hi bialix | 17:20 |
| bialix | hi garyvdm | 17:20 |
| garyvdm | hmmmm | 17:20 |
| garyvdm | Not on to release yet. | 17:20 |
| bialix | is there some blockers for you? | 17:20 |
| bialix | jam: hello | 17:21 |
| garyvdm | Fixing qdiff perferformance | 17:21 |
| garyvdm | Nearly done with that :-) | 17:21 |
| jam | hi bialix | 17:21 |
| jam | and garyvdm | 17:21 |
| bialix | jam: garyvdm working on qbzr release | 17:21 |
| jam | bialix: I'm not on as strict timetable for 1.18rc1, so just let me know when you think you're ready | 17:21 |
| bialix | what's your plans on bzr installer? | 17:21 |
| garyvdm | Hi jam - when do you plan to do the wininstallers for 1.18rc? | 17:22 |
| bialix | :-) | 17:22 |
| bialix | all windows people looking at jam | 17:22 |
| garyvdm | jam - never mind. there was a irc delay | 17:22 |
| jam | garyvdm, bialix: I plan to do them.... eventually :) | 17:22 |
| garyvdm | jam - I'll let you know when I've done the qbzr release. | 17:22 |
| garyvdm | Please will you wait for that before you do 1.18rc1 installers | 17:23 |
| bialix | if garyvdm will fall asleep I'll do it | 17:23 |
| garyvdm | bialix: I've got qdiff much faster - just some small bug to fix. | 17:24 |
| bialix | that's great! | 17:24 |
| garyvdm | bialix: Please can you try out the qannotate changes. | 17:24 |
| bialix | does they're already in trunk? I did not saw commit mail yet | 17:24 |
| bialix | garyvdm: do you remember what's problem with bzr-pipeline? Bug #395817 | 17:25 |
| ubottu | Launchpad bug 395817 in qbzr "qbzr and bzr-pipeline not compatible." [Medium,New] https://launchpad.net/bugs/395817 | 17:25 |
| garyvdm | Yes - I know how I think we should fix that - will just take a while. | 17:26 |
| garyvdm | I'll explain in a sec | 17:26 |
| bialix | if you think we have to fix it on our side, then I'd mark bug as Confirmed | 17:27 |
| garyvdm | bialix: It probably involve changes in bzrlib, qbzr and bzr-pipeline | 17:31 |
| garyvdm | or just bzrlib, and qbzr | 17:31 |
| bialix | should we involve bzr into bug report then? | 17:32 |
| garyvdm | Not yet | 17:33 |
| bialix | ok, so won't touch it yet | 17:34 |
| bialix | so I won't | 17:34 |
| === patrick is now known as Guest65098 | ||
| Guest65098 | ~~~~~~~~/qIRCNICK patrickcd | 17:37 |
| garyvdm | bialix: re pipeline problem - I've got a 2 ideas on how to fix. Both are a lot of work :-( I have not decided which is best. | 17:39 |
| garyvdm | Idea 1: | 17:40 |
| garyvdm | Add --using to merge --preview | 17:41 |
| garyvdm | and | 17:41 |
| garyvdm | Add a way to hook qdiff into diff --using | 17:42 |
| garyvdm | which would be reused by merge --preview | 17:42 |
| garyvdm | so you could do merge --preview --using qdiff | 17:42 |
| garyvdm | Idea 2: | 17:42 |
| === beuno is now known as beuno-lunch | ||
| garyvdm | Change bzrlib to some how allow for multiple plugins to change a command. | 17:44 |
| garyvdm | Not 100% certain how that can be done though. | 17:44 |
| garyvdm | bialix: so I have pushed my qdiff improvements if you want to try them out. | 17:45 |
| garyvdm | And I'm going to start updating news now. | 17:45 |
| bialix | idea #2 require discussion with core devs | 17:45 |
| garyvdm | Yes | 17:45 |
| bialix | perhaps Aaron or Martin should know better | 17:45 |
| luks | Idea 3: monkey patching :) | 17:45 |
| garyvdm | luks: what's that? | 17:46 |
| luks | modify cmd_merge instead of subclassing it | 17:46 |
| luks | you can add an option and overwrite _do_preview | 17:46 |
| luks | and now I should hide :) | 17:46 |
| bialix | why not? | 17:46 |
| bialix | does monkey patching taboo in #bzr? | 17:47 |
| garyvdm | luks: Yes - that way one of my ideas, but I'm not sure where one would do that? | 17:47 |
| luks | bialix: I guess any bzr dev would complain | 17:47 |
| luks | since it's misusing a private API | 17:47 |
| bialix | about monkey patching from qbzr plugin? | 17:47 |
| luks | from any plugin | 17:48 |
| garyvdm | Which we are doing atm.... | 17:48 |
| bialix | recently there was added some hooks re command loading | 17:48 |
| luks | garyvdm: in bzrlib.plugins.qbzr.__init__ | 17:48 |
| bialix | I wonder if they will be used here | 17:48 |
| luks | but of course proper hooks in cmd_merge would be a better solution | 17:48 |
| garyvdm | luks: lazly? | 17:49 |
| luks | garyvdm: you can overwrite the method by a trivial method that either calls something else or the original _do_preview | 17:49 |
| garyvdm | A pro of Idea 1 would get us away from interfacing a private method | 17:50 |
| luks | the something else would be lazily loaded | 17:50 |
| garyvdm | luks - I see | 17:50 |
| luks | not that I suggest using something like this long-term | 17:50 |
| luks | but it would work until there are proper hooks in cmd_merge for --using | 17:50 |
| bialix | IIUC you mean registry of diff viewers | 17:51 |
| garyvdm | Yes - that is what I had in mind for idea 1 | 17:52 |
| bialix | it's could be complicated because PreviewTree is internal representation of merge results and has not actual mirror on the disk | 17:52 |
| garyvdm | bialix: It would be easy to write to disk. | 17:53 |
| garyvdm | However, for qdiff, it would not be written to disk. | 17:53 |
| bialix | just to throw it after? | 17:53 |
| luks | bialix: well, that | 17:54 |
| luks | 's what diff --using does | 17:54 |
| bialix | right | 17:54 |
| bialix | +1 then | 17:54 |
| garyvdm | bialix: have you tried qdiff yet? | 17:54 |
| bialix | so, we'd need to start supporting `bzr diff --using qbzr` first, I guess | 17:55 |
| garyvdm | yea | 17:55 |
| bialix | garyvdm: not yet | 17:55 |
| * bialix pulls | 17:55 | |
| garyvdm | bialix, luks: I found that qdiff was spending more time in format_for_ttype than in pygmentstaking longer in | 17:56 |
| garyvdm | ^H^H^H^H^H^H^H^H^H^H^H | 17:56 |
| garyvdm | So I now cache that. | 17:56 |
| garyvdm | And I made the line/block drawing only draw what's on screen. | 17:57 |
| garyvdm | much faster now. | 17:57 |
| bialix | garyvdm: WOW | 17:58 |
| bialix | WOW WOW WOW | 17:58 |
| bialix | it flies now | 17:58 |
| garyvdm | :-) | 17:58 |
| bialix | you're wizard! | 17:58 |
| * bialix heads to home now, be back after ~ 1 hour | 17:59 | |
| === raimue is now known as Raim | ||
| fsufitch | hey. who do i complain to about bzr rspush deleting vital files which were part of .bzrignore? | 18:05 |
| emmajane | beuno-lunch, I'm just headed out for lunch myself. But I've sent a summary to the mailing list for the wireframes. it would be great if you could take a peek and hopefully pass this along to one of your designers. | 18:13 |
| === mrevell is now known as mrevell-dinner | ||
| garyvdm | jam: qannotate can now annotate the working tree - so now qannotate can do every that gannotate can do :-) | 18:34 |
| garyvdm | *everything | 18:34 |
| === deryck[lunch] is now known as deryck | ||
| luks | except for moving between revisions | 18:34 |
| garyvdm | luks: It can! | 18:34 |
| luks | oh | 18:35 |
| === EdwinGrubbs is now known as Edwin-lunch | ||
| luks | cool | 18:35 |
| garyvdm | luks: right click on a revision, click on "Annotate this revision." | 18:35 |
| luks | UI bug, it should not have a trailing period :) | 18:35 |
| * garyvdm fixes | 18:36 | |
| beuno-lunch | emmajane, will do | 18:36 |
| * garyvdm -> dinner | 18:38 | |
| * SamB wonders why bzr switches packs in mid-transfer | 18:40 | |
| SamB | (why can't it just write to a temporary pack and then figure out where to really put the the revisions later?) | 18:41 |
| luks | hm, I find myself running "bzr branch ../foo ../bar && bzr switch ../bar" too often. has anybody thought about adding a --switch option to branch before? | 18:41 |
| SamB | luks: bzr switch -b | 18:41 |
| luks | oh? | 18:42 |
| SamB | the ../ is sorta implicit, too | 18:42 |
| luks | in what version was that included? | 18:42 |
| SamB | so you would just do "bzr switch -b bar", if foo was what you had checked out | 18:42 |
| SamB | luks: 1.17, maybe? | 18:43 |
| luks | I have 1.17 here and no switch -b | 18:43 |
| SamB | oh | 18:43 |
| SamB | well, whatever's in the PPA then | 18:43 |
| luks | hm, but switch -b branches of the current branch, right? | 18:43 |
| SamB | I believe you could specify a second arg if you wanted to branch from something else | 18:44 |
| SamB | it's inspired by git checkout -b | 18:44 |
| luks | oh, so apparently I have 1.17rc here | 18:45 |
| luks | and it was added in 1.17 | 18:45 |
| luks | weird that there was a new feature added after the rc | 18:45 |
| SamB | yeah | 18:45 |
| luks | I must be blind | 18:48 |
| luks | upgraded to 1.17, still don't see the option | 18:48 |
| SamB | oh? | 18:49 |
| luks | not in builtins.py either | 18:49 |
| luks | and not mentioned in NEWS | 18:50 |
| luks | but the docs on bazaar-vcs.org mention it | 18:50 |
| luks | strange | 18:50 |
| luks | last entry in New Features in the tarball is "bzr send now aborts if ..." | 18:51 |
| SamB | maybe you're looking at the bzr.dev docs? | 18:51 |
| === beuno-lunch is now known as beuno | ||
| luks | I am, but under the 1.17 section | 18:51 |
| SamB | oh? | 18:51 |
| luks | it was probably added on the wrong place in bzr.dev | 18:52 |
| * LarstiQ annotates | 18:53 | |
| luks | hm, right, to switch -b is not useful to me | 18:56 |
| luks | I'm usually in a situation where I have a feature branch and I want to work on another feature | 18:56 |
| luks | this way I'd have to switch to trunk, switch -b to the new branch | 18:56 |
| luks | which is not not easier than branch && switch | 18:56 |
| LarstiQ | luks: how about cbranch? | 18:56 |
| SamB | LarstiQ: doesn't that do something almost entirely different? | 18:57 |
| luks | what does it do? the help text is confusing | 18:57 |
| LarstiQ | SamB: something witt branches and checkouts? ;) | 18:57 |
| luks | I don't want to create a new checkout | 18:57 |
| SamB | LarstiQ: but it makes a new checkout, doesn'ty it? | 18:57 |
| luks | I want to use the same checkout, but create a new branch | 18:58 |
| LarstiQ | SamB: ah hmm, you'd still need to switch, yeah ok, doesn't help | 18:58 |
| luks | what do you think about adding "bzr switch -b [SOURCE] TO_LOCATION"? | 18:59 |
| luks | would it be acceptable to add a new argument between the existing ones? | 19:00 |
| SamB | luks: should be the other way, I think | 19:01 |
| SamB | bzr switch -b to_location [source] | 19:01 |
| luks | yeah, well, that would be compatible with older switch, but inconsitent with branch | 19:01 |
| LarstiQ | bzr switch source -b to_location? | 19:01 |
| luks | that's the same as -b source to_location | 19:02 |
| LarstiQ | not if -b is an option | 19:02 |
| luks | I believe the option parser ignores position of --options | 19:02 |
| luks | oh, even more confusing :) | 19:02 |
| SamB | the idea is to mimic 'git checkout -b' | 19:02 |
| LarstiQ | luks: one of us is confused about argument/option :) | 19:02 |
| luks | argument is 'foo', option is '-f' or '--foo' | 19:03 |
| luks | right? | 19:03 |
| LarstiQ | luks: argument doesn't take an argument, option takes an argument | 19:03 |
| luks | well, to_location is not -b's argument | 19:04 |
| LarstiQ | d'oh | 19:04 |
| SamB | it apparantly should be? | 19:04 |
| luks | probably not, because you need it even without -b | 19:05 |
| luks | bzr switch to_location is the main use case | 19:05 |
| SamB | or maybe checkout is just supposed to treat it's args different depending on whether or not -b was passed | 19:05 |
| luks | git indeed uses "checkout -b target source" | 19:06 |
| SamB | luks: well, I meant judging by git-checkout(1) | 19:06 |
| luks | I'd prefer the argument ordering from branch | 19:06 |
| luks | which is the same as for cp/mv | 19:06 |
| SamB | it would mess up our finger memory | 19:06 |
| luks | well, I'll write the patch and let people on the bazaar ML judge it | 19:07 |
| SamB | and having optional arguments at the beginning is quite odd | 19:07 |
| luks | it would depend on -b | 19:08 |
| luks | "bzr switch foo bar" would raise an error | 19:08 |
| SamB | even so | 19:08 |
| luks | or, "source" could be -b's argument | 19:08 |
| SamB | no, that's an incompatible change | 19:08 |
| SamB | or, darn, it's not in a release is it? | 19:09 |
| LarstiQ | incompatible changes aren't outruled per se | 19:09 |
| SamB | well, anyways, it isn't terribly compatible with my fingers ... | 19:09 |
| LarstiQ | and especially when not released :) | 19:09 |
| luks | isn't it possible to have an option with has optional argument? | 19:09 |
| SamB | I'd want the '-b' short form removed if you're going to do things so different | 19:10 |
| luks | so both "-b" and "-b source" are valid? | 19:10 |
| SamB | luks: no... | 19:10 |
| SamB | well, I hope not, anyway | 19:10 |
| luks | oh well, I'll just write it the hacky way and let the patch to be rejected :) | 19:11 |
| luks | hm, or I write a plugin | 19:11 |
| SamB | dunno how I missed that bzr switch -b bar foo | 19:12 |
| SamB | doesn't work yet | 19:12 |
| luks | cool, it seems optparse explicitly supports optional arguments in the middle | 19:17 |
| luks | I can have takes_args = ['source?', 'to_location'], def run(self, to_location, source=None) and it does the right thing | 19:18 |
| SamB | the wrong thing! | 19:19 |
| SamB | well, what you meant, sure ;-) | 19:19 |
| LarstiQ | interesting :) | 19:20 |
| luks | hm, or maybe not | 19:22 |
| luks | does anybody know of a bzr command that take arguments in "target source" other? | 19:24 |
| LarstiQ | export | 19:25 |
| SamB | luks: I think the order to use is "required [optional]", generally | 19:27 |
| luks | SamB: I know, but I couldn't live with switch source target | 19:28 |
| luks | it seems everything fails, so I'll write a sbranch plugin for myself | 19:29 |
| luks | er, sorry, with source target source | 19:29 |
| LarstiQ | luks: `bzr export` wasn't helpful? | 19:29 |
| luks | (but you can see, it's hard to write the other way :)) | 19:29 |
| SamB | needs more source | 19:29 |
| luks | LarstiQ: I always found it weird | 19:29 |
| * SamB pours on some worcestershire source | 19:29 | |
| luks | LarstiQ: I just wanted to know if there is a precedent | 19:30 |
| luks | I wonder why was the option added to switch and not branch though | 19:35 |
| luks | since branch has more options for things like revision | 19:35 |
| SamB | luks: it's a convenience command | 19:44 |
| jam | luks: because at the time I got motivated enough to implement "-b" I was thinking about switch | 19:46 |
| jam | there is certainly an argument for "bzr branch --switch" | 19:46 |
| jam | nobody has cared enough to do it :) | 19:46 |
| jam | in fact, I generally work that way as well, but I wrote 'bzr-start' to handle that for me | 19:47 |
| jam | lp:~jameinel/+junk/bzr-start | 19:47 |
| jam | uses the 'submit:' branch to decide what the source should be | 19:47 |
| jam | so "bzr start ../lp/my-new-feature" | 19:48 |
| jam | branches from bzr.dev, and switches to it | 19:48 |
| luks | jam: does http://paste.pocoo.org/show/133506/ look sensible? | 19:48 |
| luks | (for inclusion in bzr.dev) | 19:48 |
| jam | luks: I think if we add the "two location" variant, we should just make "bzr branch --switch" rather than "bzr switch -b target source" | 19:48 |
| luks | ok | 19:49 |
| jam | luks: though that is *my* opinion | 19:49 |
| luks | I'll submit a patch for that | 19:49 |
| jam | note there has been some recent discussion | 19:49 |
| luks | I like it better, too | 19:49 |
| jam | where lifeless and abentley have mentioned wanting "bzr switch --new" | 19:49 |
| jam | because they want to use it for bzr-loom and bzr-pipeline | 19:49 |
| luks | ah | 19:49 |
| jam | and they didn't like "-b" since it would be "new-loom" or "new-pipe" | 19:50 |
| jam | or whatever | 19:50 |
| jam | so at least think about that briefly | 19:50 |
| jam | *I* like "bzr branch --switch ../source ../target" | 19:50 |
| luks | me too | 19:50 |
| LarstiQ | maybe minus the ../ ? | 19:51 |
| luks | in my case it's more often ../branches/source ../branches/target | 19:51 |
| luks | or would that relative location handle that as well? | 19:51 |
| jam | luks: so "switch" knows about relative locations and "branch" doesn't | 19:51 |
| jam | one of the problems about *creating* branches is that it can be unclear | 19:52 |
| jam | if you typed "bzr branch source target" | 19:52 |
| jam | is source relative to the current tip? | 19:52 |
| jam | is target? | 19:52 |
| jam | or is target relative to the working dir? | 19:52 |
| luks | I generally like using real path, because I can tab-complete on that | 19:52 |
| jam | if source is relative to X is target then relative to X ? | 19:52 |
| LarstiQ | luks: that's incentive for better tab completion | 19:53 |
| luks | LarstiQ: hard to implement as a bash extension if bzr startup time is as it is | 19:53 |
| jam | luks, LarstiQ: I think, in general, it is a UI issue that is hodgepodged right now, and nobody has gone through and figured out what it should be | 19:54 |
| luks | I really like the way it works in git | 19:54 |
| bialix | garyvdm: ping | 19:54 |
| jam | switch, IIRC, is the *only* command to support "bzr switch foo" to mean "bzr switch $CURRENT/../foo" | 19:54 |
| garyvdm | Hi bialix | 19:54 |
| jam | garyvdm: so is it ready yet ? | 19:54 |
| jam | :) | 19:54 |
| garyvdm | Busy with the release... | 19:54 |
| bialix | evening Gary | 19:54 |
| garyvdm | not yet | 19:54 |
| jam | btw garyvdm, you seem to be doing *far* too much development work on release day | 19:55 |
| bialix | garyvdm: I've fixed some typos in NEWs | 19:55 |
| jam | take it from the bzr project, that is a very good way to break things :) | 19:55 |
| bialix | garyvdm: can you look at them? | 19:55 |
| garyvdm | bialix: Yes | 19:55 |
| bialix | one sec | 19:56 |
| garyvdm | yam: I know it not good. If there are bugs, I'll do 0.13.1 before bzr 1.18(2.0?) final. | 19:57 |
| luks | loggerhead should really not annotate files by default | 19:57 |
| garyvdm | *jam | 19:57 |
| bialix | garyvdm: http://paste.ubuntu.com/250990/ | 19:58 |
| garyvdm | jam/bialix: do you guys think I should leave the annotate and diff change out the release. | 19:58 |
| bialix | diff fixes are superious | 19:58 |
| jam | garyvdm: I don't really care. I think they seem like good things | 19:58 |
| bialix | jam: we have regressions all the time | 19:59 |
| garyvdm | bialix: Please commit and push. | 19:59 |
| jam | Just recommending that you do the work right after a release | 19:59 |
| jam | rather than right before | 19:59 |
| bialix | so even release day is ok | 19:59 |
| jam | bialix: "spurious" ? | 19:59 |
| bialix | ? | 19:59 |
| bialix | WDYM? | 19:59 |
| jam | (1:58:54 PM) bialix: diff fixes are superious | 19:59 |
| jam | I'm trying to understand what you mean by "superious" | 20:00 |
| bialix | SUPER++ | 20:00 |
| garyvdm | bialix: Normally we catch the regressions before we release. | 20:00 |
| bialix | it seems I've construct the word using russian grammar | 20:00 |
| jam | bialix: I was concerned you meant :http://www.merriam-webster.com/dictionary/spurious | 20:00 |
| jam | " outwardly similar or corresponding to something without having its genuine qualities" | 20:00 |
| jam | (often used as, you changed something that didn't really need to be changed, for no real net benefit) | 20:01 |
| bialix | jam! | 20:01 |
| bialix | you are laughing fromme | 20:01 |
| bialix | don;t | 20:01 |
| jam | not laughing | 20:01 |
| jam | just not sure whether you meant "those are really good" | 20:01 |
| jam | versus "those really didn't help anything" | 20:01 |
| jam | spurious == don't help | 20:01 |
| jam | super++ == help a lot | 20:02 |
| bialix | the latter | 20:02 |
| bialix | I've just realized | 20:02 |
| bialix | Gary perhaps pronounced similar to Harry? | 20:02 |
| garyvdm | Yes | 20:03 |
| bialix | wizard Gary | 20:03 |
| garyvdm | Lol | 20:03 |
| bialix | I'm glad 0.13 won't be boring maintenance release | 20:04 |
| bialix | pushed | 20:04 |
| bialix | wow, paste.ubuntu.com correctly displays russian. kudo for people coding it | 20:05 |
| bialix | garyvdm: do you need any other help with release from me? | 20:06 |
| garyvdm | I don't think so. Maybe with Inno, but If I get stuck, I'll mail you. | 20:06 |
| bialix | I'll build installer tomorrow morning, don't worry about it | 20:07 |
| bialix | it seems official bzr rc installer will go first ;-) | 20:07 |
| bialix | garyvdm: so, write some optimistic announce mail, this release really deserve it. there is a lot of tasty improvements | 20:09 |
| bialix | thanks a lot | 20:09 |
| garyvdm | Ok - I'll maybe include some screen shots | 20:10 |
| bialix | good idea | 20:10 |
| fjalvingh | Sorry for the intrusion, but is there anyone here that can help me with something which looks like a corrupted bzr repository (bug 405251)? | 20:13 |
| ubottu | Launchpad bug 405251 in bzr "Huge data transfers/bad performance OVERALL" [Undecided,Incomplete] https://launchpad.net/bugs/405251 | 20:13 |
| luks | jam: it seems I might take the lazy way and just start using your bzr-start instead of patching branch :) you shouldn't point me to the plugin | 20:14 |
| jam | :) | 20:14 |
| jam | well, I wrote it because it works well for this mode of operation | 20:14 |
| jam | and is *just* special enough | 20:14 |
| jam | that i didn't think it was worthy of being a core command | 20:15 |
| luks | 99% of cases I branch from trunk, so submit location works fine for me | 20:15 |
| jam | I don't really like the name 'start', though it works well for me | 20:15 |
| garyvdm | jam: qbzr 0.13 tar uploaded and taged revision pushed. | 20:16 |
| === Edwin-lunch is now known as EdwinGrubbs | ||
| jam | of course, I usually also wait for bzrtools 1.18 to be released, so no real pressure from you guys :) | 20:18 |
| garyvdm | lol | 20:18 |
| garyvdm | luks: There is a command in the .deb building world that automatically downloads the latest source package. I can't remember what it is. I think it starts with "u". Do you know what it is? | 20:20 |
| luks | uscan? | 20:21 |
| luks | why are you not using bzr builddeb though? | 20:21 |
| luks | (or maybe you mean uupdate) | 20:22 |
| luks | I used to work with watch files that called uupdate automatically | 20:22 |
| luks | but now I only use bzr builddeb, it takes care of the boring work | 20:22 |
| garyvdm | luks: Yes - Thats its. I am using bzr bd for some things, Maybe I'm not aware of all of bzr bd features | 20:22 |
| luks | well, it can download tarballs for you :) | 20:23 |
| LarstiQ | fjalvingh: that bug doesn't seem to mention corruption? | 20:23 |
| garyvdm | luks: Ok, how? | 20:23 |
| luks | garyvdm: bzr bd :) | 20:23 |
| luks | it will download the tarball and build everything | 20:23 |
| luks | I think there is a separate command for downloading the tarball too | 20:23 |
| garyvdm | Oh wow. | 20:24 |
| fjalvingh | LarsiQ: Thanks for answering; at the end of the bug there seems to be the actual problem: the repository grows 170MB for a simple commit,,, And has grown 3x as big in a month | 20:24 |
| emmajane | ping beuno | 20:25 |
| fjalvingh | So performance is a symptom... I cannot go back to an earlier bzr because the repo itself looks corrupt | 20:25 |
| beuno | pong emmajane | 20:25 |
| emmajane | beuno, I'm not sure I understand your concern with the front page... do you have some time to go over it before you hand it over? | 20:25 |
| beuno | emmajane, sure | 20:26 |
| beuno | my main concern is that it's too much content | 20:26 |
| beuno | maybe it will not look so much with design slapped on it | 20:26 |
| emmajane | too much content, or too many regions? | 20:26 |
| beuno | but it seems like a lot to grab your attention | 20:26 |
| beuno | I think content | 20:26 |
| garyvdm | luks: That did not work. Do I have to update the changelog first? (can't remember the command for that.) | 20:26 |
| LarstiQ | fjalvingh: I'm out of my depth there | 20:27 |
| luks | garyvdm: yes | 20:27 |
| beuno | emmajane, and regions as a result of it | 20:27 |
| LarstiQ | garyvdm: dch | 20:27 |
| emmajane | beuno, are you trying to include the footer as contnet? It really does not count. | 20:27 |
| emmajane | beuno, the footer should be muted and in a small font and out of the way of the main content. | 20:27 |
| luks | garyvdm: btw, you can use the scripts from bzr to do ppa packaging | 20:27 |
| fjalvingh | LarsiQ: thanks anyway... | 20:27 |
| luks | garyvdm: it gets boring to build packages for 3 distros | 20:27 |
| emmajane | beuno, people seem to be having a hard time looking past it and I wish I hadn't included it in the design, but it shows how the sections flow into the rest of the site | 20:28 |
| garyvdm | Ok - I look at that. | 20:28 |
| beuno | emmajane, I think the regions are good, I just think that no matter how you look at it, it's too much | 20:28 |
| LarstiQ | fjalvingh: jam might be of more help | 20:28 |
| emmajane | beuno, I'm not sure how it's too much though.... it's essentially two regions broken down into smaller areas. | 20:29 |
| beuno | emmajane, well, just to show you how much I trust you, I have already sent it off to get a designer on it | 20:29 |
| beuno | we can see once it looks more like a web page | 20:29 |
| emmajane | beuno, heh. It's not about trust. :) It's about getting it right. ;) | 20:29 |
| beuno | and decide based on that | 20:29 |
| beuno | emmajane, I jump around a dozen different projects per day, I may be over-siplifying it | 20:30 |
| jam | fjalvingh, LarstiQ: Not sure I can be of more help without context :) | 20:30 |
| beuno | I don't have my head in this too deeply | 20:30 |
| emmajane | beuno, when I gave the examples of simplified home pages (e.g. open atrium someone complained those sites were too bare). | 20:30 |
| emmajane | beuno, I'm just tryign to find that post now. | 20:31 |
| jam | but if I'm guessing the user correctly | 20:31 |
| beuno | emmajane, so if you feel it will fit, we'll see in (hopefully) a few days, and tweak based on that | 20:31 |
| jam | he's been talking with me fairly directly for a while now :) | 20:31 |
| jam | (well, on the bug page, at least) | 20:31 |
| fjalvingh | jam: what do you need? I'm very eager to get this fixed because end of this week I'll be forced to move back to Subversion - and I hate that 8-( | 20:31 |
| fjalvingh | jam: yes, I'm the one on bug 405251 (fjalvingh). | 20:33 |
| ubottu | Launchpad bug 405251 in bzr "Huge data transfers/bad performance OVERALL" [Undecided,Incomplete] https://launchpad.net/bugs/405251 | 20:33 |
| jam | fjalvingh: Unfortunately I don't have great answers for you just yet. I could say "bzr log -n1 -r0..-1" might be helpful | 20:33 |
| jam | sorry "bzr log -n1 -r0..-1 -v" | 20:33 |
| jam | however, my quick guess | 20:33 |
| jam | is just that you change a *lot* of files every commit | 20:33 |
| jam | the pull results you showed | 20:33 |
| jam | show a lot of files changing on each revision | 20:34 |
| fjalvingh | jam: Did you look the last comments where I pulled one by one? Because a growth of 170MB in the repository for a few files seems excessive? | 20:35 |
| jam | fjalvingh: can you point to a specific rev | 20:35 |
| jam | as I was seeing *lots* of changes for each revision | 20:35 |
| jam | but I didn't go one by one | 20:35 |
| jam | also, it is just as possible that someone is doing "bzr add big-subdir; bzr commit; bzr rm subdir; bzr commit" | 20:36 |
| fjalvingh | One moment, I'll look in the log to find one. | 20:36 |
| jam | and that causes a lot of churn | 20:36 |
| jam | that wouldn't show up in the pull | 20:36 |
| jam | since it only compares the start and end states | 20:36 |
| jam | and not all the intermediate states | 20:36 |
| fjalvingh | jam: Yes, I understand but that *would* be visible when doing the log verbose for that revno? | 20:37 |
| jam | fjalvingh: not for that revno | 20:37 |
| jam | but if you logged *all* revnos | 20:37 |
| jam | well, all revisions | 20:37 |
| jam | hence -n0 versus -n1 | 20:37 |
| jam | meh, I typed it wrong again | 20:37 |
| garyvdm | luks: bzr.dev/tools/packaging/update-packaging-branches.sh and the other files have strings that a specific to bzr. Should I copy them to qbzr and modify? | 20:37 |
| jam | bzr log --include-merges -r 0..-1 -v | 20:38 |
| emmajane | beuno, huh. It was an email from Stephen Turnbull specifically that said the front page was too empty on sites like open atrium. But I can't find it in the archives. the list was CC-d on it, so it should be there?. | 20:38 |
| jam | (using the long form for -n0) | 20:38 |
| jam | emmajane: though realize that Stephen Turnbull is one person with their own opinions, and not necessarily a well paid home-page designer :) | 20:38 |
| emmajane | https://lists.ubuntu.com/archives/bazaar/2009q3/061067.html <--- that's the message but it doesn't have the full text that I have. | 20:38 |
| beuno | emmajane, I know what you mean. Let's see it in action, and we'll go from there | 20:39 |
| emmajane | jam, correct. But this is a community process so that means I can't flat out ignore people. :) | 20:39 |
| beuno | emmajane, you can | 20:39 |
| beuno | you shouldn't | 20:39 |
| beuno | different things :) | 20:39 |
| emmajane | beuno, bah. I have to at leave throw bones or give reasons. :) | 20:39 |
| jam | design-by-committee can often be crap | 20:39 |
| jam | especially when the committee is the masses | 20:40 |
| jam | rather than experts | 20:40 |
| jam | anyway | 20:40 |
| emmajane | and it can often reveal really useful information when it's filtered back through experts. | 20:40 |
| jam | I've stayed away from the general discussion because of this sort of thing | 20:40 |
| jam | I have very little idea ,and I'm willing to say so | 20:40 |
| jam | rather than assuming my quick opinion is actually correct | 20:40 |
| beuno | emmajane, my comment was just to be prepared to cut content by a significant chunk | 20:40 |
| emmajane | jam, but just thought you'd throw your piss into the discussion without being productive. ;) | 20:40 |
| fjalvingh | jam: Ok, the revno with the largest increase is from 1321 to 1322, the repo grows from 415MB to 585MB. | 20:40 |
| beuno | so when we come back with "it's too crammed", you have idea of what can go | 20:41 |
| jam | fjalvingh: so you can do "bzr log -v -r1321..1322 --include-merges" | 20:41 |
| fjalvingh | jam: willdo. Will take a while. | 20:41 |
| emmajane | beuno, I've kept the word counts low and the link lists can go. That shouldn't be a problem. | 20:41 |
| jam | emmajane: I'm being productive in saying that if you significantly disagree with someone, *your* opinion probably matters more than the rest of us | 20:41 |
| jam | I can say what I'd like to see, but you aren't going to be putting a pony up on the home page :) | 20:42 |
| beuno | emmajane, cool. You can jump into other pages meanwhile I think. | 20:42 |
| emmajane | jam, awww. But I thought we were getting a new logo! :) | 20:42 |
| jam | and as far as it goes | 20:43 |
| jam | I'm pretty sure I would trust beuno's opinon over stephen's | 20:43 |
| emmajane | beuno, cool. | 20:43 |
| emmajane | jam, :) | 20:44 |
| LarstiQ | I sure would. | 20:45 |
| fjalvingh | jam: Ok, I did the full log on that revision. It is a merge containing several revisions (rather big). But it does not actually change much data at all and certainly does not add/remove/add/remove huge subdirectories. | 20:55 |
| fjalvingh | I can post the log if you want. All in all this commit grew the working space by 1MB while the repo grew 170MB | 20:55 |
| jam | fjalvingh: if you could post the log, it would probably be helpfull | 20:56 |
| jam | helpful | 20:56 |
| jam | in the end, having direct access would be the most helpful | 20:56 |
| jam | but at least I could start there | 20:56 |
| fjalvingh | jam: I'll add it to the bug report. | 20:56 |
| jam | I'll also mention, if you have large binary files being versioned | 20:57 |
| jam | they may show up as simply modified | 20:57 |
| jam | and not grow by much | 20:57 |
| jam | but they may not delta well | 20:57 |
| jam | however, the first problem | 20:57 |
| jam | is that you have 700k file texts, for only 7k revisions, which seems *really* *really* strange | 20:57 |
| fjalvingh | jam: we do not have large binaries and certainly do not change them often. I wondered about those 700K text files but cannot find any way to locate them. Is there some way to dump the repository? | 21:00 |
| SamB | fjalvingh: I think he means you have 700K different versions of files | 21:02 |
| jam | fjalvingh: well, you can do "for f in .bzr/repository/indices/*.tix; do bzr dump-btree --raw $f; done" | 21:02 |
| SamB | meaning that you change an average of 100 files in each revision | 21:02 |
| jam | to at least get the list ofthem | 21:02 |
| jam | fjalvingh: but in theory "bzr log -v" should be showing a line for each change | 21:03 |
| jam | though that may require doing it across all revisions | 21:03 |
| jam | to find the ones that are causing this | 21:03 |
| fjalvingh | jam: ok; I already did a full history dump (all revisions all merges verbose) and got only about 20K lines - meaning bzr does not see the 700K texts in the log! | 21:04 |
| fjalvingh | jam: 50K lines, sorry. | 21:05 |
| SamB | fjalvingh: maybe those texts aren't in the history? | 21:05 |
| fjalvingh | jam: in addition, a change that *was* very big (changing every source file in the repo) only grew the repo a small bit | 21:05 |
| fjalvingh | SamB: Ok, I know little of bzr internals; but where can they be otherwise? | 21:06 |
| jam | SamB: if they weren't in the history, then they shouldn't be a factor doing "bzr branch" | 21:06 |
| jam | fjalvingh: you can have multiple histories in one repository | 21:06 |
| jam | though a thought occurs to me | 21:06 |
| jam | what is the size in the target repo after doing "bzr branch shared/branch standalone" ? | 21:07 |
| jam | you tested how long it took | 21:07 |
| jam | but I don't think we had you determine the number of "text keys" in the standalone repo | 21:07 |
| jam | only in the source | 21:07 |
| alex-weej | i branched bzr-fastimport and ran setup.py install but it doesn't work. bzr claims fastimport isn't a command | 21:07 |
| fjalvingh | jam: Not sure what you mean; the results we are talking about now are in a standalone repo which was branched off the shared one? | 21:08 |
| jam | fjalvingh: I'm trying to figure out how many text keys are present in the standalone repository | 21:08 |
| jam | so in the repo where you are doing "pull" | 21:09 |
| jam | and how that compares to the one you are pulling from | 21:09 |
| jam | fjalvingh: we've got several threads going concurrently | 21:09 |
| jam | one is about the *size* of the new repo | 21:09 |
| jam | which is one concern | 21:09 |
| jam | another is about the fetch performance | 21:09 |
| jam | fetch performance seems to be primarily impacted by the fact you have 700k texts | 21:09 |
| jam | which may or may not be related to why your repo is so big | 21:10 |
| fjalvingh | jam: I understand, but related the fetch performance to the delta size in the repo pulled into; assuming that the 170GB growth also meant a huge fetch. | 21:10 |
| jam | fjalvingh: there is also a plugin you could try: | 21:10 |
| garyvdm | luks: Do you know what going wrong here: http://paste.ubuntu.com/251025/ | 21:10 |
| jam | lp:bzr-repodetails | 21:10 |
| garyvdm | luks: uscan worked fine. | 21:11 |
| jam | fjalvingh: I assume you mean 170MB not Gigabyte | 21:11 |
| jam | the plugin provides: | 21:11 |
| jam | "bzr repository-details" | 21:11 |
| jam | which gives some basic stats about how big various parts of the repository are | 21:11 |
| fjalvingh | jam: yes, 170MB sorry. I will do plugin now. | 21:13 |
| jam | revision 1310.9.10 seems a bit suspicious | 21:17 |
| jam | it claims to be a [merge] but doesn't have any children | 21:17 |
| jam | oh wait, I'm reading it backwards | 21:17 |
| jam | nm | 21:17 |
| jam | (I always log --forward) | 21:17 |
| jam | hmm... maybe I'm right | 21:18 |
| jam | anyway, it at least looks like you are doing a giant merge that changes lots of files | 21:18 |
| jam | but I don't see the revisions that are actually introducing those changes | 21:18 |
| jam | 1310.911 seems to be a similar merge, and you can see the list of 0.30.149 stuff that got merged in | 21:20 |
| awilkins | Clippy : "Hi, it looks like you are doing a giant merge that changes lots of files. Would you like to install Visual SourceSafe?" (sorry, couldn't resist) | 21:20 |
| fjalvingh | awilkins: ;-) | 21:20 |
| Colonel-Rosa | Where does bazaar store plugin information? | 21:24 |
| Colonel-Rosa | I've deleted automirror, but bzr is still looking for it | 21:25 |
| LarstiQ | Colonel-Rosa: 'looking for it'? | 21:25 |
| fjalvingh | jam: I do not understand 1310.9.10?? It certainly does not look like a merge. | 21:25 |
| Colonel-Rosa | http://codepad.org/x0wNoO88 | 21:25 |
| jam | fjalvingh: well: revno: 1310.9.11 [merge] | 21:26 |
| jam | means bzr thinks its a merge | 21:26 |
| LarstiQ | Colonel-Rosa: it mentions the path it is loading from | 21:26 |
| jam | you could try "bzr log --show-ids -r 1310.9.11" | 21:26 |
| jam | to get more info on what it thinks is being merged | 21:26 |
| jam | certainly the number of *changes* would usually be caused by a real merge | 21:26 |
| jam | ah you know what | 21:26 |
| LarstiQ | Colonel-Rosa: so either rename C:/Program Files (x86)/Bazaar/plugins/bzr-automirror, or remove it | 21:26 |
| jam | it is probably merging trunk into your dev branch | 21:26 |
| Colonel-Rosa | LarstiQ, but nothing is there, that's my problem | 21:27 |
| jam | and then that is getting merged back to trunk later | 21:27 |
| jam | and that doesn't show anything indented, because they are already in trunk | 21:27 |
| Colonel-Rosa | bzr has a reference somewhere, there's no folders in there | 21:27 |
| fjalvingh | jam: yes I see bzr thinks it is a merge but I cannot see why. It will be though because I added merge to the commit comment also. | 21:27 |
| LarstiQ | Colonel-Rosa: then hava look at the `bzr plugins` and `bzr --version` output | 21:27 |
| jam | I should have looked at the commit message | 21:27 |
| LarstiQ | Colonel-Rosa: that should tell you where to look for plugins | 21:27 |
| Colonel-Rosa | Yeah, I know where to put them, and it says it's installed in that path | 21:28 |
| Colonel-Rosa | But as I said, the folder is empty | 21:29 |
| fjalvingh | jam: I did the --show-ids but had to add -n0 --verbose; it then shows a merge from __another__ branch that was merged-with-history. | 21:30 |
| fjalvingh | Which I cannot do anymore because it triggers another bug now | 21:30 |
| jam | fjalvingh: if you just log that one rev, it is possible we will show you the "trunk" revisions | 21:30 |
| jam | you might look closely at the "branch nick:" entry | 21:31 |
| fjalvingh | jal@mabillon:~/bzr/vp-split/vp$ bzr log --show-ids -r 1310.9.11 -n0 --verbose | 21:32 |
| fjalvingh | 21:32 | |
| fjalvingh | ------------------------------------------------------------ | 21:32 |
| fjalvingh | revno: 1310.9.11 [merge] | 21:32 |
| fjalvingh | revision-id: jal@etc.to-20090717172307-qqjfa5fms7p60yxk | 21:32 |
| fjalvingh | parent: jal@etc.to-20090717171804-sz02tktpmnalvuzi | 21:32 |
| fjalvingh | parent: jal@etc.to-20090717171329-sp6sps0a9l4o7l8w | 21:32 |
| fjalvingh | committer: Frits Jalvingh <jal@etc.to> | 21:32 |
| fjalvingh | branch nick: vp | 21:32 |
| fjalvingh | timestamp: Fri 2009-07-17 19:23:07 +0200 | 21:32 |
| fjalvingh | message: | 21:32 |
| fjalvingh | Merge with trunk of DomUI; this merges all of the Query Event and new QDataContext code | 21:32 |
| LarstiQ | Colonel-Rosa: there are two possible plugin paths | 21:34 |
| Colonel-Rosa | Yep, program files and the roaming folder in windows 7 | 21:35 |
| LarstiQ | Colonel-Rosa: ah, Windows7? | 21:35 |
| Colonel-Rosa | Yep | 21:35 |
| LarstiQ | possibly that introduces strange and new bugs | 21:36 |
| LarstiQ | Colonel-Rosa: does .bzr.log help any/ | 21:36 |
| Colonel-Rosa | Might hold the answer yes, hold on | 21:37 |
| Colonel-Rosa | http://codepad.org/Izu7RfTA | 21:38 |
| LarstiQ | Colonel-Rosa: that does seem to imply it thinks that directory is not empty | 21:43 |
| Colonel-Rosa | :\ | 21:44 |
| Colonel-Rosa | I even uninstalled and reinstalled it | 21:44 |
| Colonel-Rosa | And removed those folders | 21:45 |
| Colonel-Rosa | blergh | 21:45 |
| LarstiQ | Colonel-Rosa: what does python -c "import os; print os.listdir('C:/Program Files (x86)/Bazaar/plugins | 21:45 |
| LarstiQ | ')" | 21:46 |
| LarstiQ | say? | 21:46 |
| Colonel-Rosa | gimme a sec | 21:46 |
| Colonel-Rosa | ['bzrtools', 'launchpad', 'netrc_credential_store', 'qbzr', 'rebase', 'svn'] | 21:50 |
| LarstiQ | ho hum | 21:50 |
| Colonel-Rosa | Fixed it | 21:52 |
| Colonel-Rosa | I had to empty out this folder "C:\Users\Mathew\AppData\Local\VirtualStore\Program Files (x86)\Bazaar\plugins" | 21:53 |
| LarstiQ | Colonel-Rosa: oooh boy | 21:55 |
| LarstiQ | Colonel-Rosa: so it is sneakily overlaying that over the regular filesystem.. | 21:55 |
| Colonel-Rosa | Yep, if you do a bzr branch in your program files folder they get written to that path instead | 21:56 |
| LarstiQ | wonder what can do about that | 21:56 |
| RenatoSilva | Am I connected? | 22:13 |
| latexer | can annoyone comment on the status of the EOL content filtering? It seems that branching something over an sftp:// transport is not applying the EOL filters as specified in my rules file. | 22:13 |
| fullermd | latexer: Likely the issue is that filtering only happens on a non-default working tree format. | 22:20 |
| latexer | fullermd: yeah, i'm *just* noticing that. | 22:25 |
| latexer | fullermd: it seems that when I branch, it defaults to working tree format 4. | 22:25 |
| latexer | fullermd: how do I control the chosen working tree format? | 22:26 |
| latexer | hrm... /me guesses that creating a repository with a new enough format *beforehand* might force it. | 22:28 |
| * latexer tries. | 22:28 | |
| latexer | hrm.. it already was *in* a repository created with a newer format. | 22:29 |
| latexer | (note, this is using bzr 1.16.1 on windows) | 22:30 |
| jam | latexer: for source repositories with no working trees, you have to use --2a | 22:31 |
| jam | it is an open bug | 22:31 |
| jam | I don't remember the number offhand | 22:31 |
| jam | I believe the person reporting it said they wrote a plugin to set the default WT format | 22:32 |
| latexer | jam: ok, so if I'm pushing a branch to a server, and then branching from that remote location, that remote server must have a repository for the branch in the --2a format? | 22:32 |
| latexer | right now the server has an older bzr release, so I had figured (wrongly?) that I could simply use the sftp:// transport and not have to have anything special on the server. | 22:33 |
| latexer | (i suppose I could create the *repository* locally as well and sftp the whole thing over...) | 22:33 |
| jam | latexer: so you can update the local client to change the default WT format | 22:34 |
| jam | or yes, have the remote format in a --2a format | 22:34 |
| latexer | jam: ok, i'll dig a bit for that plugin, and try both approaches. | 22:34 |
| latexer | jam: thanks. | 22:34 |
| jam | if you are using sftp:// then you don't even need bzr installed remotely | 22:34 |
| jam | though performance is generally much worse | 22:35 |
| latexer | jam: I know, this is a legacy system that previously stored branches used only on linux, etc. | 22:35 |
| latexer | jam: only now investigating bzr for a windows project, and wanted to do EOL stuff "right" | 22:35 |
| lifeless | moin | 22:50 |
| beuno | hiya lifeless | 22:51 |
| fullermd | latexer: You can use the 1.14 format, that's just a WT change vs. 1.9. 2a changes a lot more. | 22:56 |
| latexer | fullermd: ok, so just ensuring that the remote repository is at least 1.14 format should do it? | 22:58 |
| latexer | fullermd: I think as I had it, there was no actual repository for the remote push/pull location. | 22:58 |
| latexer | I just tested, and ensuring 2a on the remote side seemed to do it. | 22:58 |
| latexer | will try with 1.14 on the remote as well. | 22:58 |
| fullermd | It may not, because of details of what happens where. | 23:01 |
| fullermd | You could use 1.14 locally with 1.9 (or pack-0.92 for that matter) remotely with no trouble; doing that with 2a locally wouldn't work unless the remote were rich-root. | 23:01 |
| fullermd | Of course, if you're in a position to just use 2a everywhere, that's the way forward. | 23:02 |
| latexer | fullermd: any additional risk by using 2a? Less tested format, etc? | 23:03 |
| jam | fullermd: 1.14 == 1.9 without a working tree | 23:03 |
| jam | with the main problem that "bzr branch remote" will create 1.9 locally, *not* 1.14 | 23:04 |
| * fullermd nods at jam. | 23:04 | |
| jam | latexer: it is expected to become the default format in the next release | 23:04 |
| jam | well, 1.18+1 | 23:04 |
| jam | (likely to be called 2.0 :) | 23:04 |
| fullermd | Well, it's naturally less tested, since it's newer. But going forward it's likely to be the standard (and if it's not, a descendent of it is), so... | 23:05 |
| latexer | fair enough. | 23:05 |
| fullermd | There may still be some bumpy bits with it. I think the 'send' fix for it isn't in a release yet, frex. | 23:05 |
| fullermd | But that smoothes as we speak. | 23:06 |
| fullermd | The main risk you take is not having compatibility with people using older versions of bzr. | 23:06 |
| latexer | ok, creating a standalone branch (no parent repo) off a remote 1.14 repo results in a WT 4 (bad). Doing the same off a remote 2a repo results in a WT format 6 (good) | 23:06 |
| fullermd | But that may well not be a concern at all in your place, so... | 23:06 |
| fullermd | Yah, you'd have to.... uh... | 23:07 |
| latexer | i'm not too concerned about older bzr versions, since it's a small team, all installing bzr fresh into windows VMs. | 23:07 |
| fullermd | Well, crap, I thought branch had a --format. | 23:07 |
| latexer | however, if I do the same branching into existing repos on the client side, what happens? | 23:07 |
| * latexer performs that test. | 23:07 | |
| jam | fullermd: it is in 1.18rc1 which is released-ish as of today | 23:08 |
| fullermd | No difference, since the repo format doesn't affect the WT format. | 23:08 |
| jam | (windows installers aren't built because I'm waiting on bzrtools 1.18, etc) | 23:08 |
| latexer | fullermd: correct. | 23:09 |
| latexer | ok, so really, the logical choice here is: go with 2a format everywhere for this new work requiring windows EOL stuff to jive. | 23:09 |
| fullermd | It's one of the big strengths of the bzr gestalt, except when it's one of the big annoyances :) | 23:09 |
| latexer | heh. | 23:09 |
| poolie | hi jam | 23:10 |
| jam | hi poolie | 23:11 |
| poolie | want to chat? | 23:11 |
| jam | yep | 23:12 |
| jam | skype should work fine | 23:12 |
| poolie | k | 23:12 |
| lifeless | hi poolie | 23:13 |
| jam | hi lifeless | 23:14 |
| lifeless | hi jam | 23:14 |
| jam | do we know if abentley is on vacation or something? | 23:14 |
| lifeless | what do you think the priority for 'commit doesn't honour stacking invariants' should be vis-a-vis 2.0 | 23:14 |
| jam | I haven't seen him around, and he didn't release bzrtools 1.18 | 23:14 |
| lifeless | check the staff calendar for that question | 23:14 |
| jam | lifeless: looks like he is gone until Tuesday *next week* :( | 23:16 |
| SamB | lifeless: what are stacking invariants for? | 23:18 |
| * SamB wonders if it is safe to change the owner of a launchpad branch mid-push | 23:21 | |
| lifeless | SamB: data integrity | 23:27 |
| poolie | SamB: no | 23:43 |
| latexer | fullermd, jam: thanks for the help, standardizing on 2a format has us moving forward again finally. | 23:44 |
| SamB | poolie: as I discovered | 23:45 |
| SamB | I was wondering that after I already did it | 23:45 |
| spiv | SamB: no, the insert_stream_1.18 verb won't be in 1.18; I'll be renaming it to 1.19 before merging I guess (although we hope the next release is 2.0!) | 23:56 |
| SamB | spiv: that's not a basis for renaming it, though! | 23:57 |
| SamB | the release being 2.0 instead of 1.19, I mean | 23:58 |
| fullermd | Well, you could compromise and call it _2.19. Then everybody would be equally happy :p | 23:58 |
| SamB | fullermd: that's even dumber then "let's compromise and call it ISO" | 23:58 |
| SamB | s/then/than/ | 23:58 |
| fullermd | I aim to excel. | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!