| tolstoy | Hm. Startup like things seem to have changed. | 00:01 |
|---|---|---|
| MTecknology | a cron to rotate images would have some issues | 00:03 |
| MTecknology | * wrong chan | 00:03 |
| tolstoy | Works! | 00:04 |
| MTecknology | form? | 00:15 |
| MTecknology | formapi? | 00:15 |
| MTecknology | fine.. | 00:16 |
| mwhudson | tolstoy: cool | 00:16 |
| tolstoy | mwhudson: I see it now displays tags. | 00:16 |
| mwhudson | yes | 00:17 |
| tolstoy | Headings are centered, but the data in the columns isn't. Now I can't remember if it's always been that way. | 00:18 |
| MTecknology | ok - this shouldn't be too hard..... | 00:47 |
| MTecknology | I'm getting this error warning: mysqli_fetch_object() expects parameter 1 to be mysqli_result, array given in /var/www/d6/includes/database.mysqli.inc on line 144. which seems to be coming from thsi line $rslts = db_fetch_array(db_query('SELECT title, image, titlelink, content FROM {udsidebar} ORDER BY position')); | 01:58 |
| Peng_ | Wrong channel? | 02:00 |
| MTecknology | yup.... | 02:00 |
| MTecknology | sorry | 02:00 |
| * Peng_ /away! | 02:00 | |
| * igc out for a bit - bbl | 02:11 | |
| awmcclain | Is there no way to specify the umask for bzr+ssh, is there? How do other people set up servers with shared branches? | 02:11 |
| tolstoy | We did it the hokey way. All our accounts on that machine have umask of 000, with the same group as the bzr repo. | 02:13 |
| awmcclain | tolstoy: Hrm. How did you specify the umask? Altering the umask in /etc/profile doesn't seem to work with bzr+ssh. (new branches are still 755 instead of 775) | 02:19 |
| awmcclain | We have the same group set up with everything as well | 02:19 |
| tolstoy | Also set it in .bashrc | 02:19 |
| tolstoy | Our repos are on Solaris. I think interactive shells source one, and non-interactive source the other. | 02:20 |
| tolstoy | I can never remember, and maybe it varies from platform to platform. | 02:20 |
| awmcclain | tolstoy: that's ~/.bashrc, right? | 02:20 |
| tolstoy | yes, of the account that's doing the logging in. | 02:21 |
| awmcclain | ok, i'll try that | 02:21 |
| awmcclain | Nope. | 02:22 |
| awmcclain | drwxr-sr-x 3 andrew dev 4096 Oct 2 01:22 badges3 | 02:22 |
| tolstoy | So, you're doing something like bzr push sftp://tolstoy@host/path/to/repo? | 02:23 |
| tolstoy | ~tolstoy is the thing that should have the bashrc/profile/bash_profile umask setting. | 02:24 |
| tolstoy | Er, the account. | 02:24 |
| awmcclain | ah, no, we're doing it over bzr+ssh | 02:27 |
| awmcclain | bzr+shh://host/path/to/repo | 02:27 |
| awmcclain | ssh | 02:27 |
| awmcclain | Heh. Ssh is somthing else entirely. | 02:27 |
| tolstoy | I thought sftp was on top of ssh. | 02:28 |
| awmcclain | Isn't pushing over bzr+ssh much faster than sftp? | 02:28 |
| awmcclain | "Smart server" and all that? | 02:28 |
| tolstoy | Maybe. | 02:28 |
| tolstoy | You have a smart server running? | 02:28 |
| tolstoy | We don't have that, so no doubt things are different. | 02:28 |
| awmcclain | tolstoy: Well, smart server is basically invoking bzr on the server side. Nothing really runs, per se. | 02:29 |
| tolstoy | Right. I thought it had a config file for perms and so on. But it's been a while. | 02:29 |
| tolstoy | We didn't use it because a year or so ago, it was just one too many steps. | 02:30 |
| awmcclain | ok, a tiny bit slower, but not by much | 02:30 |
| awmcclain | oh? maybe that's why i'm missing. | 02:30 |
| awmcclain | ug, and no, sftp:// still gives me 755. >:( | 02:30 |
| tolstoy | Hm.. | 02:31 |
| tolstoy | What I ended up doing under similar circumstances was reading the bash man page on that particular server and trying to determine which files it sourced under which conditions. | 02:33 |
| verterok | emmajane: around? | 02:35 |
| emmajane | verterok, ish :) | 02:35 |
| verterok | emmajane: hi, I have a *experimetal* pyqt4 installer for 10.5 | 02:35 |
| emmajane | verterok, oh! cool! | 02:36 |
| verterok | emmajane: do you know of someone willing to try it? | 02:36 |
| emmajane | verterok, let me see if jacine is around. | 02:36 |
| * emmajane pings everyone she can find.... | 02:39 | |
| verterok | oh, I can ask in the channel :) anyone with OS X 10.5 willing to try a PyQt4 installer? | 02:39 |
| emmajane | hehe :) | 02:39 |
| verterok | emmajane: don't worry, we can test it tomorrow :) | 02:39 |
| verterok | emmajane: is just the first one that looks like it's working :p | 02:39 |
| * emmajane hates waiting :) | 02:40 | |
| emmajane | I've got two peeps :) | 02:42 |
| emmajane | litwol and dww are both on 10.5 | 02:42 |
| litwol|mac | hmm? | 02:42 |
| emmajane | :) | 02:42 |
| verterok | litwol|mac: hi | 02:42 |
| litwol|mac | link me | 02:42 |
| emmajane | \o/ | 02:43 |
| verterok | litwol|mac: http://verterok.com.ar/PyQt-4.5.4.dmg | 02:43 |
| verterok | litwol|mac: it requires Qt installed (I used 4.5.2 for the build) | 02:43 |
| litwol|mac | fail http://litwol.com/sites/litwol.com/files/Install_PyQt_4-20091001-214409.jpg | 02:44 |
| verterok | litwol|mac: hmm, looks like it never prompted for admin password, right? | 02:44 |
| litwol|mac | bingo | 02:45 |
| verterok | litwol|mac: building a new one :) | 02:45 |
| litwol|mac | k | 02:45 |
| verterok | gimme 2' | 02:45 |
| dww | verterok: emmajane just had me try your installer... | 02:45 |
| litwol|mac | in the mean while maybe you can explain what am i installing ? | 02:45 |
| dww | verterok: "Install Failed" | 02:46 |
| dww | verterok: "The Installer could not install some files in "/". Contact the software manufacturer for assistance." | 02:46 |
| litwol|mac | dww: http://litwol.com/sites/litwol.com/files/Install_PyQt_4-20091001-214409.jpg | 02:46 |
| verterok | dww: litwol|mac, it's a PyQt4 standalone installer, but if it works, it will be included in the bzr OS X installer | 02:46 |
| verterok | dww: I'm uploading a new one 2' | 02:46 |
| litwol|mac | brb | 02:47 |
| * dww nods and agrees with litwol|mac's screenshot | 02:47 | |
| verterok | litwol|mac, dww: uploaded new version that ask for admin rights: http://verterok.com.ar/PyQt-4.5.4-1.dmg | 02:48 |
| * dww tries again | 02:49 | |
| dww | "Mounting failed" ;) | 02:49 |
| verterok | dww: hmm, looks like the upload did't finished yet :/ | 02:50 |
| dww | that'd explain it. ;) | 02:50 |
| verterok | yeap, looks like the scp is stalled | 02:51 |
| verterok | I'll cancel it and try again | 02:51 |
| verterok | dww: now it fully uploaded | 02:53 |
| dww | that's more like it... | 02:54 |
| verterok | dww: do you have Qt installed right? | 02:54 |
| dww | says it worked. | 02:54 |
| dww | i'm honestly not sure... I don't write GUIs. ;) | 02:54 |
| verterok | dww: ok, coo. could you try something? | 02:55 |
| dww | sure. | 02:55 |
| verterok | dww: in a terminal: python -c "from PyQt4 import QtCore, QtGui" | 02:55 |
| dww | (is Qt included with osx and/or xcode at all?) | 02:55 |
| verterok | dww: no, is a separate download | 02:55 |
| verterok | dww: and not a small one :( | 02:55 |
| dww | yeah, no Qt here. | 02:56 |
| dww | ImportError: dlopen(/Library/Python/2.5/site-packages/PyQt4/QtCore.so, 2): Library not loaded: QtCore.framework/Versions/4/QtCore | 02:56 |
| verterok | dww: ok, so it's working in some way...but wihtout qt we can't test it | 02:56 |
| verterok | dww: thanks a lot! | 02:56 |
| dww | where's the "uninstall" button? ;) | 02:57 |
| verterok | dww: that was about to say :) | 02:57 |
| verterok | dww: open thre installer again | 02:57 |
| dww | ok, did so | 02:57 |
| verterok | dww: Cmd + i | 02:57 |
| dww | k | 02:58 |
| verterok | dww: it expand the two items, those are the files installed | 02:58 |
| verterok | dww: I can give a script to remove them ;) gimme a minute | 02:58 |
| dww | so just manually purge them? | 02:58 |
| dww | no, that's fine... i see them. | 02:58 |
| verterok | dww: yes, nothing else is needed | 02:58 |
| verterok | dww: ok, cool. | 02:58 |
| dww | wow, except: ultra annoying the cmd-i window disappears whenever I make any other app (e.g. iterm) active. :( | 02:59 |
| dww | verterok: also, might be nice if "sip" made its own subdir in site-packages instead of using the root... | 03:01 |
| verterok | dww: I can't change the layout :( | 03:01 |
| dww | drat | 03:02 |
| dww | any idea how to keep the cmd-i window from disappearing? :( | 03:02 |
| dww | i was about to take a screenshot of it. ;) | 03:02 |
| verterok | dww: no ide :( | 03:03 |
| verterok | dww: rm -Rf /Library/Python/2.5/site-packages/sip* /Library/Python/2.5/site-packages/PyQt4* | 03:03 |
| dww | that was the easy part. ;) | 03:03 |
| dww | it's the stuff in /System I'm being a little more careful about. | 03:03 |
| verterok | dww: yeap :) rm /System/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5/sip.h | 03:04 |
| dww | verterok: fear not, I have a screenshot now. ;) | 03:04 |
| dww | working fine. | 03:04 |
| verterok | dww: ok | 03:04 |
| verterok | dww: thanks! | 03:04 |
| dww | interesting: FYI: sip.h was installed chmod 664 instead of 644 like everything else in that dir... | 03:05 |
| dww | verterok: not sure if that's something you control. | 03:05 |
| verterok | dww: yes, I can change that. good catch | 03:05 |
| litwol|mac | back | 03:06 |
| dww | sadly, I didn't look closely at any others before I did. | 03:06 |
| litwol|mac | what to test ? | 03:06 |
| dww | verterok: but you might want to go through and check the perms on all the files... | 03:06 |
| verterok | litwol|mac: dww already installed it, thanks! | 03:06 |
| litwol|mac | cool | 03:06 |
| litwol|mac | cheers | 03:06 |
| verterok | dww: yes I just need to click one button in PackageManager: "apply recomendations" :) | 03:07 |
| dww | good idea. | 03:07 |
| * verterok is still learning this mac installers thing | 03:07 | |
| * dww shrugs | 03:08 | |
| verterok | dww: also I'll change the location of the sip stuff that it's in System/ to /Library | 03:09 |
| emmajane | verterok, did you make it work? :) | 03:09 |
| verterok | emmajane: partially :) | 03:09 |
| emmajane | WOO! :) | 03:09 |
| lifeless | spiv: https://bugs.edge.launchpad.net/bzr/+bug/427736 | 03:10 |
| ubottu | Launchpad bug 427736 in bzr "bzr1.17 on launchpad streams wrong data, causes "unknown object type identifier 60" in bencode pulling from pack into 2a repository" [Critical,In progress] | 03:10 |
| lifeless | spiv: don't set 2.0.1 as a milestone in trunk; target to release 2.0, then milestone that task | 03:10 |
| spiv | Oh, blah. Right. | 03:10 |
| lifeless | spiv: I've done it for you | 03:10 |
| spiv | I guess I see how that makes sense. | 03:10 |
| spiv | Thanks. | 03:11 |
| lifeless | it lets use record what actual trunk release it makes it into | 03:11 |
| lifeless | while still recording it as a blocker for 2.0.1 [thats what you intended, right?] | 03:11 |
| spiv | As a user I just think "this should go into 2.0.1" | 03:11 |
| spiv | And there's a drop down right there that lists 2.0.1. | 03:11 |
| lifeless | in which case, don't set a milestone at all | 03:11 |
| lifeless | yeah | 03:11 |
| spiv | So I unthinkingly did the obvious thing :/ | 03:11 |
| lifeless | so, I've unmilestoned it completely now | 03:12 |
| lifeless | I'll add a bug comment to explain the noise | 03:12 |
| spiv | Thanks for cleaning my mess :) | 03:12 |
| dww | verterok: anything else? I'm about to flee. | 03:13 |
| verterok | dww: no, thanks a lot! | 03:13 |
| dww | no problem. | 03:13 |
| * dww bows | 03:13 | |
| verterok | emmajane: dww didn't have Qt installed, and it's big install/download :) | 03:14 |
| lifeless | spiv: you might like to eyeball how I've leftit. | 03:14 |
| emmajane | verterok, that was the 1+Gig one that jacine had to wait for last night, IIRC | 03:14 |
| verterok | emmajane: yes, actually. the non-sdk is a bit smaller ~140MB | 03:15 |
| verterok | emmajane: if jancine wants to download, here is a direct link: http://get.qt.nokia.com/qt/source/qt-mac-opensource-4.5.3.dmg | 03:16 |
| emmajane | verterok, she got Explorer working last night. :) | 03:16 |
| verterok | emmajane: oh, good to know | 03:16 |
| emmajane | she has fast internets | 03:16 |
| emmajane | or rather: she got it *installed* | 03:16 |
| emmajane | http://dl.getdropbox.com/u/912092/bzr-install.txt <--- I have to update the wiki with her instructions | 03:17 |
| verterok | emmajane: cool | 03:19 |
| emmajane | yah | 03:20 |
| lifeless | spiv: UI bug filed | 03:20 |
| igc | emmajane: fyi, I've changed the banner image to be explorer until you have the carousel going | 03:33 |
| emmajane | igc, perfect | 03:34 |
| spiv | lifeless: btw, I haven't updated the 2.0 branch to use subunit yet. I'm not sure how to do it nicely while retaining the '[ascii]' prefix on the 2nd test run... | 04:06 |
| lifeless | spiv: just nested progress would do it; there isn't a CLI for that yet | 04:07 |
| lifeless | it would look like | 04:07 |
| lifeless | echo "progress: 2" | 04:08 |
| lifeless | before the tests run at all | 04:08 |
| MTecknology | Is it possible to pull just the head of a bzr branch? I'd like to be able to pull it sometimes w/o the .bzr directory | 04:08 |
| lifeless | but, may need testing to make sure it all hangs together correctly. | 04:08 |
| lifeless | could also tag the second half, but I haven't put tags into the PQM UI | 04:08 |
| lifeless | MTecknology: do you mean 'get a copy of the content of the head' ? | 04:09 |
| MTecknology | ya | 04:09 |
| lifeless | bzr export | 04:09 |
| MTecknology | thanks :) | 04:09 |
| === ivan`` is now known as ivan | ||
| === ivan is now known as Guest83508 | ||
| spiv | spm: around? Would you mind zapping my current PQM request? It has an mildly embarrassing wrong commit message. | 04:34 |
| spiv | I did specify a sane message to pqm-submit, but I forgot to write "-m"... | 04:35 |
| spiv | And so pqm-submit silently ignored that argument and just used the last commit on the branch :/ | 04:35 |
| spiv | I should hack my copy of pqm-submit to require -m, the automatic behaviour is never what I want. | 04:36 |
| lifeless | spiv: or update your local copy | 04:37 |
| lifeless | I doubt you've done so in uhm 2 years | 04:37 |
| lifeless | revno: 55 [merge] | 04:37 |
| lifeless | timestamp: Tue 2008-04-01 18:00:47 +0800 | 04:38 |
| lifeless | Merge John's changes to make --message mandatory. | 04:38 |
| spiv | lifeless: Oh, hmm. | 04:41 |
| spiv | lifeless: odd, I've definitely gone through and systematically updated all my plugins several times since that date. | 04:41 |
| spiv | lifeless: "No revisions to pull.", and bzr plugins -v says it is using the copy I think it is. | 04:43 |
| spiv | (I have revno 60) | 04:43 |
| === Guest83508 is now known as ivan | ||
| Nannu | hi | 04:51 |
| Nannu | how to run bzr-gtk? | 04:51 |
| spiv | lifeless: hmm, no spm it seems... I don't suppose you can kill that PQM job for me? | 05:06 |
| spiv | Ah well. | 05:08 |
| * spiv grabs some lunch. | 05:08 | |
| lifeless | spiv: no, I can't | 05:12 |
| lifeless | spiv: pjdc can | 05:12 |
| lifeless | spiv: want to merge 2.0 to .dev? or shall I? | 06:13 |
| spiv | lifeless: I was about to :) | 06:13 |
| lifeless | cool, shoo :) | 06:13 |
| spiv | lifeless: I was going to use it as an opportunity to make my intended commit text appear somewhere, at least ;) | 06:14 |
| lifeless | we need a report 'fixed in .dev fix committed in malone' | 06:14 |
| spiv | Yes. Or even better for LP to just do it... | 06:14 |
| lifeless | do you mean change the status? | 06:21 |
| lifeless | spiv: did you send it to pqm? I see rev 4722 from poolie yesteday, nothing playing, | 06:50 |
| lifeless | spiv: I'm guessing it failed or you were distracted ;) | 06:54 |
| lifeless | spiv: if it failed I'd like to help, if I can | 06:54 |
| spiv | lifeless: you must have refreshed PQM a second too soon! | 06:55 |
| lifeless | heh:) | 06:55 |
| spiv | I did spend a bit of time puzzling over the NEWS conflicts and checking that I was supposed to duplicate them etc. | 06:56 |
| lifeless | yeah | 06:56 |
| lifeless | ETOOMANUAL | 06:56 |
| spiv | I'm a bit puzzled by the current state of the 2.0 NEWS file, actually... why does it have apparently current sections for both 2.0 series and 2.0.1? | 06:56 |
| lifeless | its not an obvious useful thing *today*, but once 2.1b1 is released the utility will be clear | 06:56 |
| lifeless | spiv: grawk, possibly me. Possibly someone else | 06:57 |
| spiv | Yes, I agree that the policy for lp:bzr's news file is sane. I just needed to dig up the email to ensure that sanity was also the official policy :) | 06:58 |
| lifeless | spiv: :) - I wasn't doubting that, just idly commenting | 06:59 |
| vila | hi all | 07:01 |
| vila | lifeless, spiv : just to help me wake up, can you remind me in a few (and slow) words what that policy is ? | 07:01 |
| vila | numerical or chronological ? | 07:02 |
| lifeless | numerical | 07:05 |
| lifeless | I htink | 07:05 |
| lifeless | it may not be strictly defined in fact | 07:05 |
| spiv | vila: the policy I'm referring to is that when merging from 2.0 -> dev, NEWS entries for things added in 2.0 should appear in dev's NEWS in both the appropriate 2.0.x section, and the appropriate 2.1.x section. | 07:06 |
| vila | lifeless: ha, good, I thought so and was wondering if I misunderstood something | 07:06 |
| spiv | And, yes, I think numerical. | 07:06 |
| spiv | But I haven't had cause to really care about that yet :) | 07:06 |
| lifeless | vila: you've seen the pqm bling, I presume? :) | 07:06 |
| vila | spiv: Hmm, I think I'm rather strongly against duplicating NEWS entries... | 07:07 |
| vila | lifeless: ooooh yes | 07:07 |
| spiv | vila: then you should reply to the relevant thread :P | 07:07 |
| vila | only the screenshot so far | 07:07 |
| lifeless | vila: the reason is that once 2.1b1 released, a NEWS entry in 2.0.1 (say) *doesn't* indicate that it was fixed in 2.1b1 | 07:07 |
| vila | spiv: damn, so I *missed* something or is that a today's thread ? | 07:08 |
| lifeless | vila: weeks ago | 07:08 |
| spiv | vila: but I think it's best to have the entry appear at the right point in each release series, so it's obvious what is fixed, and not fixed, in each release. | 07:08 |
| lifeless | another good point | 07:08 |
| lifeless | over and above inferred data | 07:08 |
| lifeless | vila: which reminds me :) | 07:08 |
| lifeless | vila: please refuse the temptation to guess about milestones for already fixed bugs | 07:09 |
| vila | I did that ? | 07:09 |
| lifeless | vila: its better to have it unknown than wrong, I think. Unknown means 'we don't know'. <VALUE> means 'buggy-before' to folk looking at the bug tracker | 07:09 |
| lifeless | vila: yes, about 3 hours ago :) | 07:09 |
| spiv | The duplication does grate a bit, but I think it's really just a natural consequence of the duplication of effort inherent in maintaining multiple concurrent release series. | 07:09 |
| vila | I thought I rather mark fix released *without* milestone than putting an unverified one | 07:10 |
| vila | lifeless: I slept this night, I'm sure, so 3 hours ago wasn't me, bug # ? | 07:10 |
| lifeless | vila: you put 2.1b1 as the milestone for a report that came in | 07:10 |
| lifeless | vila: uhm maybe you did it your evening. I noticed my afternoon :) | 07:10 |
| vila | lifeless: hmm, that rings a bell, but I was 90% sure for that one, I'll double-check | 07:11 |
| lifeless | https://bugs.edge.launchpad.net/bzr/+bug/363452 | 07:12 |
| ubottu | Launchpad bug 363452 in bzr "bzr revert crashes after shelving a file add on a new repo." [Undecided,Fix released] | 07:12 |
| vila | lifeless: ooh, that one, ok | 07:13 |
| vila | hmm | 07:13 |
| lifeless | of course, I could be wrong;) | 07:13 |
| lifeless | but, I fixed revert a while back now | 07:14 |
| vila | well, I think in that case I thought that occurred in bzr.dev and things are a bit blurry these weeks, so, yes, you're right I shouldn't have guessed, | 07:16 |
| vila | but on the other hand, I *had* some rough idea of when... | 07:17 |
| lifeless | spiv: btw, 3918 - don't close it ;) | 07:28 |
| lifeless | the merge improves but does't complete i | 07:28 |
| lifeless | t | 07:28 |
| lifeless | \o/ | 07:31 |
| spiv | lifeless: I won't :) | 07:33 |
| spiv | lifeless: as the commit message says, it's a fix "for" 3918, not necessary a fix *of* ;) | 07:33 |
| lifeless | spiv: thanks, was just being preemptive, as its a grey area | 07:36 |
| lifeless | thought I'd save you some overhead | 07:36 |
| spiv | Yes, actually I was going to forget to update bugs at all until you said that! | 07:36 |
| spiv | So it's good you did :) | 07:36 |
| lifeless | :P | 07:37 |
| lifeless | I've done 403322 | 07:37 |
| bialix | hello bzr | 07:45 |
| lifeless | hai | 07:46 |
| lifeless | bialix: I would appreciate if you could give dirstate2 a test spin; just to know how it behaves on windows (only use it on copies :)) | 07:46 |
| bialix | lifeless: ok, maybe this weekend | 07:47 |
| bialix | what should I test specifically? | 07:47 |
| lifeless | bzr commit | 07:47 |
| bialix | just run some commit-status-diff? | 07:47 |
| lifeless | # other window | 07:47 |
| lifeless | bzr diff | 07:47 |
| lifeless | bzr status | 07:47 |
| lifeless | bzr diff | more | 07:47 |
| lifeless | # go to editor | 07:47 |
| lifeless | # put in commit message and have it do the commit | 07:47 |
| lifeless | --- that sort of thing | 07:47 |
| bialix | ok, I understand | 07:48 |
| lifeless | try to break it; I expect you can | 07:48 |
| lifeless | its a prototype, but I want to get a feeling for how far off it is | 07:48 |
| bialix | I'll try | 07:49 |
| lifeless | thanks ^^ | 07:51 |
| bialix | gary gary where are you | 07:52 |
| lifeless | spiv: I'm fairly happy with: https://bugs.edge.launchpad.net/bzr/+bugs?field.tag=dirstate - all the in progress are dirstate2 | 07:54 |
| lifeless | spiv: and I haven't found any other dirstate bugs in the bts | 07:55 |
| spiv | lifeless: nice | 07:55 |
| spiv | lifeless: very nice, in fact! | 07:55 |
| spiv | Ok, I'm off. Have a lovely weekend everyone! | 07:56 |
| lifeless | ciao | 07:56 |
| fullermd | Holy crow, I just typed 'bzrip2'. There was some serious evil going on in the naming process somewhere... :| | 08:03 |
| lifeless | :) | 08:04 |
| === fullermd_ is now known as fullermd | ||
| === t0mm13b is now known as t0mmieb_away | ||
| * igc dinner | 09:41 | |
| vila | lifeless: wow, nice bling on pqm... we lost the timings though, do you plan to do more than addressing the failures/errors mismatch there ? Like, hmmm, an option to get back the subunit output even for successful submissions ? | 10:34 |
| lifeless | vila: no | 10:34 |
| lifeless | vila: raw subunit should still be in the log | 10:35 |
| lifeless | its just the status region that parses | 10:35 |
| vila | ok, but there is no option to get that log back right ? | 10:35 |
| lifeless | I think its rsynced around somewhere in the dc | 10:35 |
| lifeless | you thinking for baseline timing stuff? The machine has other PQM instances on it. | 10:35 |
| lifeless | so potentially noisy | 10:36 |
| vila | yeah, no, not really the timing stuff itself, more generally have some reference about what tests are skipped, etc | 10:36 |
| vila | and even if noisy, the timings can give some indications | 10:36 |
| lifeless | Patchs Gratefully Accepted | 10:36 |
| vila | :D | 10:36 |
| vila | I can put that on my TODO list, but that does not mean it will occur any time soon :-/ | 10:37 |
| lifeless | vila: me neither which is why I'm not offering | 10:38 |
| vila | lifeless: but no worries, the new feedback is *very* welcome, thks for that | 10:38 |
| lifeless | I wanted '% complete', that was the main thing :) | 10:38 |
| vila | sure, me too, that's what I'm thanking about :D | 10:38 |
| vila | should I also thank spiv may be ? | 10:38 |
| lifeless | vila: he took the 'risk' of turning it on once I had the pieces in place ;) | 11:06 |
| lifeless | so perhaps yes | 11:06 |
| vila | lifeless, spiv: seeing 97% is indeed soooo good :) | 11:09 |
| vila | makes me hungry, will grab some food :) | 11:09 |
| fullermd | Me, I usually get hungry by about 75%... | 11:15 |
| vila | fullermd: Oh ! You're there | 11:20 |
| fullermd | No I'm not, I'm here. You're there. | 11:21 |
| vila | fullermd: So I had more and more crash with the 8.0rc1 | 11:21 |
| vila | fullermd: and it seems that changing the IDE controller did the trick... | 11:21 |
| fullermd | Same crash? | 11:21 |
| vila | no, different ones, but I updated from beta4 to rc1 | 11:22 |
| vila | and from there I had a different failure mode: attempt to dump the core, encounter file system full 8-( | 11:22 |
| vila | another new detail was that it rebooted on failure (Well I mostly suppose here because I was always late in the game...) | 11:23 |
| SamB_XP_ | my Debian box keeps doing that ... I'm thinking something is overheating, maybe ... | 11:24 |
| SamB_XP_ | ... there is definately a fan down :-( | 11:24 |
| vila | SamB_XP_: hmm, I don't have virtual fans in my MVs :D | 11:24 |
| SamB_XP_ | vila: hehe | 11:25 |
| SamB_XP_ | didn't realize you were talking about VMs -- didn't know you could swap out IDE controllers in those ;-) | 11:25 |
| vila | fullermd: So I commented dumpdev="auto" but I were wondering how to specify something else to avoid dumping in '/' ! | 11:25 |
| fullermd | Obviously, that's the problem. If it had virtual fans, it wouldn't overheat :p | 11:25 |
| SamB_XP_ | fullermd: lol | 11:26 |
| vila | I didn't know I could, I just followed my intuition and tried :D | 11:26 |
| fullermd | vila: Well, it dumps to the swap. savecore(8) copies it into the filesystem on next boot. $dumpdir sets where it's saved to (/var/crash by default; changing it or setting a symlink would move it) | 11:26 |
| vila | fullermd: nope, /var/crash exists and doesn't point to / | 11:27 |
| vila | and / and /var are on different volumes | 11:28 |
| SamB_XP_ | vila: but did you check whether there was a /var/crash hidden behind the mount point ? | 11:28 |
| fullermd | vila: As for the rebooting, the kernel debugger is part of the debugging that tends to be taken out around the first RC. | 11:28 |
| vila | df / /var | 11:28 |
| vila | Filesystem 1K-blocks Used Avail Capacity Mounted on | 11:28 |
| vila | /dev/ad0s1a 507630 313616 153404 67% / | 11:28 |
| vila | /dev/ad0s1d 3027598 1338820 1446572 48% /var | 11:28 |
| fullermd | Shouldn't matter, the filesystems are mounted by that time. | 11:28 |
| SamB_XP_ | okay | 11:29 |
| vila | I may be wrong, but the fact is I found a ps.core on / and a / full at 109% (haha, always love that one) | 11:30 |
| vila | and the recipe to come back to a half-stable setup was to boot in single user mode, issue fsck -y and reboot | 11:31 |
| vila | issuing fsck -y in "normal" mode didn't seem enough | 11:31 |
| SamB_XP_ | why -y ? | 11:32 |
| vila | That may sound a bit hammer debugging (it was), but it worked and I had to do it once or twice a day only | 11:32 |
| SamB_XP_ | didn't have time to sit there and say yes ? | 11:32 |
| fullermd | Wye -i? | 11:32 |
| SamB_XP_ | oh, it happened over and over again? | 11:33 |
| vila | SamB_XP_: yes | 11:33 |
| * SamB_XP_ missed that | 11:33 | |
| vila | fullermd: what -i ? | 11:33 |
| SamB_XP_ | that's for interactive, probably? | 11:33 |
| fullermd | E -i E -i O. | 11:33 |
| SamB_XP_ | okay, now he's being silly ... | 11:33 |
| SamB_XP_ | fullermd: had some DUCKS | 11:33 |
| vila | fullermd: so back to my initial question, why core dumps on '/', how to avoid that (while still having core dumps, just in case) | 11:34 |
| SamB_XP_ | vila: I don't suppose you could reapportion space such that there is enough space on / ? | 11:35 |
| fullermd | Well, it doesn't... on boot it copes into $dumpdir. | 11:36 |
| fullermd | And copies, even. | 11:36 |
| SamB_XP_ | fullermd: where does it do that? | 11:36 |
| vila | SamB_XP_: It's a default freebsd install, so no, I don't want to spend time on that | 11:36 |
| fullermd | "Where" in what sense? | 11:36 |
| SamB_XP_ | I mean, what script or binary does it ? | 11:36 |
| fullermd | savecore(8), as called from /etc/rc.d/savecore | 11:37 |
| SamB_XP_ | so, maybe vila should read that script and manpage? | 11:37 |
| vila | fullermd: dumpdir is not set in *my* rc.conf, how can I check ? | 11:37 |
| vila | SamB_XP_: sshhhh, I have a translator handy | 11:37 |
| fullermd | The default is /var/crash (as seen in /etc/defaults/rc.conf) | 11:37 |
| fullermd | Yes, I translate sh to IRC :p | 11:38 |
| SamB_XP_ | well, I just mean I find it helpful to look at init scripts when they go wrong ... | 11:38 |
| vila | dumpdir="/var/crash" in /etc/default/rc.conf :-/ | 11:38 |
| fullermd | There's a minfree file in that dir that savecore(8) checks and won't write if it would leave less than that much free. But the default is like 2 megs, and surely you're not THAT close to the line. | 11:39 |
| SamB_XP_ | vila: how about adding a line to the /etc/rc.d/savecore to display the mounts at that time to make sure fullermd was right about the filesystems being mounted? | 11:39 |
| fullermd | Well, let's back up; is savecore(8) actually what's giving you the error? It should be in your `dmesg -a` if not scrollback. | 11:40 |
| vila | fullermd: ETOOOLD | 11:40 |
| SamB_XP_ | vila: say what ? | 11:41 |
| fullermd | They are. It requires syslogd, which requires filesystems. And if it didn't, it would have been seen _ages_ ago, since nobody would be able to get at their crashdumps. | 11:41 |
| SamB_XP_ | oh, TOO OLD | 11:41 |
| SamB_XP_ | fullermd: okay, okay | 11:41 |
| vila | the last boots were clean, the last crash was yesterday when I tried the controller change | 11:41 |
| SamB_XP_ | don't boot logs get saved somewhere ? | 11:42 |
| fullermd | Yeah, it'll probably be in the messages file. | 11:42 |
| vila | I have a dmesg.yesterday | 11:42 |
| fullermd | Actually, retract that, it's probably not... | 11:42 |
| SamB_XP_ | fullermd: why's that ? | 11:42 |
| vila | it mention 6 python pid core dumped at the end of the file and nothing more | 11:43 |
| fullermd | Because the rc messages don't end up in syslog. | 11:44 |
| SamB_XP_ | fullermd: nowhere ? | 11:44 |
| SamB_XP_ | is that configurable? | 11:44 |
| NET||abuse | hey guys.. i have a branch on my machine, i'm pushing it up to an empty repo up on my web server outside of webroot. I then want to update the local WT on the web server and use that as a source to copy some of the subdirs in the WT out to operating locations in the web server, | 11:44 |
| vila | pids: 1548 1549 1807 1808 1965 1966, so may be in several waves | 11:44 |
| fullermd | They end up in the /dev/console output that dmesg -a holds, but that's not dumped anywhere by default TTBOMK. | 11:44 |
| NET||abuse | can i copy directly from the WT without bringing bzr cruft along for the ride? | 11:44 |
| vila | NET||abuse: bzr export ? | 11:45 |
| fullermd | vila: I always seem to have a .core left from something after a selftest run. | 11:45 |
| NET||abuse | i would consider it bad practice to allow bzr or svn hidden dirs to be published to the live website along with the code files. | 11:45 |
| vila | fullermd: ps.core ? | 11:45 |
| SamB_XP_ | yeah, was about to say I thought there was a "bzr export" ... | 11:45 |
| NET||abuse | vila, so export to a location adjacent to the WT, then copy from the export to the operational locations on the webserver? | 11:45 |
| fullermd | No, python.core. | 11:45 |
| SamB_XP_ | NET||abuse: well, working trees aren't usually updated on push anyway ;-) | 11:45 |
| vila | NET||abuse: you can also have a look at lp:bzr-upload | 11:45 |
| NET||abuse | vila, bzr-upload doesn't allow for sub tree nodes to be pushed up seperately. | 11:46 |
| SamB_XP_ | NET||abuse: you can't symlink to the desired parts of the exported tree? | 11:46 |
| vila | fullermd: wow, yeah, found one, but it's named python.core and in the right dir (at least the expected one | 11:47 |
| vila | NET||abuse: ha, right, well, bzr export neither I think | 11:47 |
| NET||abuse | SamB_XP_, hmm, symlinking eh.... | 11:47 |
| SamB_XP_ | hmm, is there a way to refer to the parent branch of the parent branch of the branch I'm on? | 11:47 |
| NET||abuse | SamB_XP_, haha, why? | 11:48 |
| SamB_XP_ | also ... I couldn't find any docs for e.g. :push or :parent when I tried ... | 11:48 |
| SamB_XP_ | I expect this is mostly because google is not very helpful on such queries ... | 11:48 |
| SamB_XP_ | NET||abuse: oh, I just want to check an SVN branch for new revisions | 11:49 |
| SamB_XP_ | and it happens that I'm in a bzr branch of a pull of that SVN branch | 11:49 |
| fullermd | No, it's more likely because they're not documented anywhere... | 11:49 |
| SamB_XP_ | fullermd: well, okay, that would also do it | 11:49 |
| SamB_XP_ | I was expecting something in urlspec | 11:50 |
| SamB_XP_ | which is awfully hard to find | 11:50 |
| SamB_XP_ | you have to remember "no hyphen, no plural, spec not specification" | 11:51 |
| vila | SamB_XP_: Don't file a bug about that ? I saw one yesterday just about that | 11:51 |
| SamB_XP_ | vila: about which? | 11:51 |
| vila | :<aliases> documentation missing | 11:51 |
| SamB_XP_ | ah | 11:51 |
| SamB_XP_ | I filed a bug about a need for "apropos", as well | 11:52 |
| SamB_XP_ | does that spelling plugin help with the spelling of help topic names? | 11:52 |
| vila | NET||abuse: So, to come back to your initial question, you can copy from a working tree and since there is only one /bzr directory at the top you should never copy bzr data | 11:53 |
| NET||abuse | ahhh, that's it the, you can copy out of the WT as long as you don't copy the .bzr dir at the root. | 11:54 |
| vila | NET||abuse: keep in mind though that if you always override you may miss deleted files | 11:54 |
| NET||abuse | hmm, that's a point. | 11:54 |
| NET||abuse | well.,,, i can wipe the webroot and application dirs just before re-copying the WT versions over. | 11:56 |
| NET||abuse | just don't delete the mysql store or log dirs | 11:57 |
| vila | NET||abuse: sure | 11:57 |
| NET||abuse | and tmp uploads..... | 11:57 |
| NET||abuse | damn, theres upload in webroot. | 11:57 |
| NET||abuse | hmm, could i use a relative symlink to a dir below webroot for uploaded images, and have that symlink tracked in bzr? | 11:57 |
| NET||abuse | thereby have the webroot deleted without following symlinks, and the symlink is just recopied in from WT relatively? | 11:58 |
| NET||abuse | .. hehe | 11:58 |
| NET||abuse | hacky hacky.. | 11:58 |
| NET||abuse | i still have a jquery tabs problem.. | 11:58 |
| NET||abuse | content isn't showing up on last tab for safari and chrome,,, | 11:59 |
| NET||abuse | hmm, bzr uploads on push to remote are slow..... 56KB/s taken a while for 24MB. | 12:00 |
| bialix | bonjour vila | 12:08 |
| vila | hi bialix | 12:08 |
| bialix | webdav plugin is yours? | 12:08 |
| vila | yes | 12:09 |
| bialix | one man complain (to me) it does not wrk with bzr 2.0 | 12:09 |
| * SamB_XP_ wishes bzr knew enough to help out zsh with it's completion of arguments | 12:09 | |
| bialix | version check said that bzr >= 1.12 required | 12:09 |
| * SamB_XP_ wishes zsh would bother to ask bzr about flags, too | 12:09 | |
| bialix | vila ^ | 12:09 |
| vila | there were a glitch (fixed on trunk) in the version checking | 12:10 |
| bialix | ok, glad to know | 12:10 |
| SamB_XP_ | there are often glitches like that that show up when a major version gets bumped ;-) | 12:10 |
| vila | timestamp: Tue 2009-08-11 18:29:12 +0200 | 12:11 |
| vila | message: | 12:11 |
| vila | Fix version checking for bzr-2.0. | 12:11 |
| bialix | oh, ok | 12:11 |
| vila | bialix: it may well be that the fix didn't find its way into packaged versions though... | 12:11 |
| bialix | I suspect so | 12:12 |
| vila | what os was your man using ? | 12:12 |
| SamB_XP_ | hmm ... bzr missing --theirs-only seems to give the wrong message when nothing was missing | 12:12 |
| SamB_XP_ | since it's the local branch that would be missing stuff | 12:12 |
| SamB_XP_ | but it says "Other branch is up to date." | 12:13 |
| vila | SamB_XP_: sounds correct to me: *they* miss nothing from me | 12:13 |
| bialix | vila: I'm not sure, some Linux distro, maybe Ubuntu or Gentoo. I need to ask | 12:13 |
| vila | bialix: ok, that would explain it | 12:14 |
| Peng_ | What does "bzr missing --mine-only" say? | 12:15 |
| SamB_XP_ | vila: but they are missing tons from me! | 12:19 |
| vila | you used --theirs-only that means you're not interested by what they miss from you | 12:20 |
| vila | you want --mine-only | 12:21 |
| Peng_ | I like hg's terms, "incoming" and "outgoing". I can never keep bzr's straight. | 12:26 |
| === mrevell is now known as mrevell-lunch | ||
| Peng_ | I finally added aliases for them. I don't think I've ever used them, though, heh. | 12:26 |
| fullermd | Really? Odd. --mine and --theirs always seemed obvious to me. | 12:27 |
| Peng_ | I might've learned hg's first. | 12:27 |
| Peng_ | fullermd: Hmm, you're right. I just get into something like: "Their revisions? Does that mean revisions missing from their end, or their extra revisions, or blwaewryhkfdfklhwa what was I thinking again?" | 12:28 |
| Peng_ | If you think about it from the right direction, it's obvious. If not, you can get lost. | 12:29 |
| vila | On the other hand, you generally get lost because you got wrong directions.... no ? | 12:32 |
| * vila really goes for food now | 12:35 | |
| Peng_ | Hmm, all I have is Cheerios, almonds and a banana. | 12:36 |
| * Peng_ eyes vila | 12:36 | |
| fullermd | I wouldn't, if I were you. He's really hard to pour over Cheerios. | 12:39 |
| * vila has no idea what Cheerios are, and is gone anyway | 12:41 | |
| Peng_ | vila: Cheerios are a heart-healthy, toasted whole grain oat breakfast cereal, made by the American General Mills company. | 12:42 |
| GaryvdM | Hi - I have a branch that checkouts fine on my computer, but when I try do a checkout on my clients computer, it allways has stuff left in limbo dirs. | 12:42 |
| fullermd | Also one of the few cereals robust enough to be able to handle the mornings when you're out of milk and have to pour beer on it instead. | 12:43 |
| Peng_ | Peng_ eats cereal dry. And usually out of the box. Cough. | 12:43 |
| fullermd | Well, out of the box works too. But that takes more beer ;) | 12:44 |
| GaryvdM | Here is a pastebin of the .bzr.log: http://pastebin.org/32557 | 12:44 |
| Peng_ | fullermd: Oh, god, that'd be awful. Hahaha. | 12:45 |
| Peng_ | Although pouring milk into the box would be even worse. | 12:46 |
| GaryvdM | bzr check says the branch is fine. | 12:46 |
| Peng_ | GaryvdM: Maybe it's a case-sensitivity issue? | 12:47 |
| bialix | hi GaryvdM | 12:47 |
| GaryvdM | Hi bialix | 12:48 |
| GaryvdM | Peng_: ok let me look at qbroswe. | 12:48 |
| bialix | GaryvdM: well, something wrong, but you should get error earlier | 12:49 |
| bialix | abentley is ,aster of limbo | 12:49 |
| bialix | abentley is master of limbo | 12:49 |
| bialix | does working tree is created 100%? | 12:50 |
| bialix | perhaps this is error masking in finally block somewhere? | 12:51 |
| bialix | I suppose it's a bzr.exe 2.0? | 12:51 |
| bialix | GaryvdM: ok, looking at the code I see the error raised in finally block. So most likely there is either case-sensitivy clash or inability to create symlinks | 12:53 |
| bialix | GarycdM: will you have a chance to update PPA at weekend? | 12:54 |
| bialix | GaryvdM: and I think you need to file a bug. It smells like regression | 12:54 |
| GaryvdM | bialix: I'l try - I have quite a busy weekend though. | 12:55 |
| bialix | if not -- I won't wait then and make announce | 12:56 |
| GaryvdM | Huh - It worked now, and all I have done in the mean time was to clear .bzr.log... | 12:57 |
| === mrevell-lunch is now known as mrevell | ||
| bialix | sounds like a racing condition | 12:59 |
| === beddi is now known as eLBati | ||
| vila | jam: ping | 14:36 |
| jam | morning vi | 14:54 |
| jam | vila: | 14:54 |
| vila | hello emacs | 14:55 |
| vila | jam: | 14:55 |
| vila | :D | 14:55 |
| jam | and how does this fine morning/afternoon find you, vila? | 14:56 |
| vila | good, wondering about has_changes() again because I'm fixing bug #438158 just because I thought it was a good way to do that | 14:56 |
| ubottu | Launchpad bug 438158 in bzr "dpush should behave identically to push" [High,Confirmed] https://launchpad.net/bugs/438158 | 14:56 |
| vila | and I found a case where we don't want to unconditionally check the pending merges but still use has_changes | 14:57 |
| vila | we use it in merge.py two times, and I'm running the test suite to see, but my feeling is that we shouldn't mess with pending merges there | 14:58 |
| jam | vila: so I would think we would want a helper that helps the 90% cases first, and let the 10% of cases that need customization do it on their own | 14:59 |
| jam | or add a flag | 14:59 |
| vila | jam: 4 failures | 14:59 |
| jam | if it really matters | 14:59 |
| jam | vila: could be the tests fault :) | 14:59 |
| vila | hehe, no way there, see:http://paste.ubuntu.com/283860/ | 15:00 |
| vila | I can add a has_commitable_changes() instead and use that in commands, leaving has_changes with a mandatory tree parameter and leaving merge case alone | 15:01 |
| vila | jam: will that suit you ? | 15:02 |
| jam | vila: + if from_tree is None: + if len(self.get_parent_ids()) > 1: + return True + from_tree = self.basis_tree() | 15:04 |
| jam | sorry about the formatting | 15:04 |
| jam | line 59 of your proposal | 15:04 |
| jam | you don't handle the case where from_tree is None *and* there are no parents | 15:04 |
| vila | done twice ? Don't wory | 15:04 |
| jam | this is the initial commit case | 15:04 |
| vila | oh | 15:04 |
| jam | and the basis_tree should be the null tree then | 15:04 |
| jam | hm... maybe not | 15:05 |
| jam | I might have read it wrong | 15:05 |
| jam | vila: yeah, I misread the 'if /return' line | 15:05 |
| jam | however, I'd like to see the failing tests | 15:05 |
| jam | to understand what is going on with merge | 15:06 |
| vila | ok, not pretty anyway it was for a quick and dirty tests | 15:06 |
| vila | do you see the call sites in merge ? That's what matter I think, it's not relevant there if there are pending merges or not, we could be running under --force anyway | 15:07 |
| jam | vila: if we are running under --force, then we shouldn't be checking has_changes() | 15:09 |
| jam | but let me look | 15:09 |
| vila | oh, good point :) | 15:09 |
| vila | err, no, not at all, different has_changes() usage | 15:09 |
| jam | so, line 292 is clearly this_tree vs its basis_tree | 15:10 |
| vila | but pending merges are irrelevant | 15:11 |
| jam | though there is something funny about the compariosn | 15:11 |
| jam | if this_tree has pending merges then it != basis | 15:11 |
| jam | that code path looks like an optimization | 15:12 |
| jam | where it wants to see if it can grab stuff directly from the working tree | 15:12 |
| jam | rather than having to read the basis tree | 15:12 |
| jam | (for example the 'file_revisions()' function) | 15:12 |
| vila | yet, the 4 failures are from it | 15:13 |
| jam | however, I can't find any code that actually *calls* file_revisions() in the bzrlib code base | 15:14 |
| jam | $ grep -rnI "\<file_revisions\>" bzrlib/ | 15:14 |
| jam | gives some 'version-info' tests, which has a similar attribute | 15:14 |
| jam | so how is it causing the failures? | 15:14 |
| jam | as I don't 1) see it tested, 2) see any other code calling it | 15:15 |
| vila | http://paste.ubuntu.com/283876/ | 15:15 |
| jam | similarly, 'ensure_revision_trees' is only called by file_revisions() and I don't see it anywhere else | 15:15 |
| vila | meh 5 errors but selftest reports 4 8-/ | 15:15 |
| jam | all of those are in 'check_basis' | 15:16 |
| jam | I think you should check with Aaron what the point of "file_revisions" is, as it should be slated for deprecation | 15:17 |
| jam | if nothing calls it, and it is completely untested | 15:17 |
| jam | that is code worth cutting | 15:17 |
| jam | abentley: ping | 15:17 |
| vila | check_basis *is* called | 15:17 |
| jam | vila: sure, but of the call sites | 15:17 |
| jam | it is clear that one of them doesn't matter *at all* | 15:17 |
| jam | and as for 'check_basis' *that* function certainly says to me that it *should have* been checking for pending merges | 15:18 |
| jam | considering that IIRC that used to be the choke point for 'bzr merge --no-force' | 15:18 |
| jam | vila: so "test_uncommit. test_uncommit_octopus_merge" | 15:19 |
| jam | is doing: | 15:19 |
| jam | wt.merge_from_branch(tree2.branch) | 15:19 |
| jam | wt.merge_from_branch(tree3.branch) | 15:19 |
| jam | and was allowed to do so | 15:19 |
| jam | but shouldn't | 15:19 |
| jam | the second should require 'force' | 15:19 |
| jam | so that is 1 test bogus | 15:19 |
| vila | wow | 15:19 |
| vila | that change will never land.... | 15:20 |
| jam | test_commit_template_pending_merges | 15:20 |
| vila | at least I can't make it part of fixing bug #438158 | 15:20 |
| jam | also does the same action | 15:20 |
| ubottu | Launchpad bug 438158 in bzr "dpush should behave identically to push" [High,Confirmed] https://launchpad.net/bugs/438158 | 15:20 |
| jam | and shouldn't | 15:20 |
| jam | same for test_multiple_pending | 15:21 |
| jam | and test_multiple_pending_verbose | 15:21 |
| jam | and test_uncommit_octopus_merge is repeated | 15:21 |
| vila | wrong copy/paste | 15:22 |
| jam | vila: IIRC wt.merge_from_branch is a test helper, and isn't used in 'production' code. | 15:22 |
| jam | it needs a 'check_clean = False' to allow these octopus merges | 15:22 |
| jam | but since it was supposedly check_clean=True | 15:22 |
| jam | it shows that check_clean wasn't doing what we thought it did | 15:22 |
| jam | which is... prevent from merging when there is pending uncommitted state | 15:22 |
| abentley | jam: pong-ish | 15:23 |
| jam | we just happened to rely on that behavior in a couple places in the test suite | 15:23 |
| jam | abentley: We're trying to find the point of Merger.file_revisions() | 15:23 |
| jam | it isn't called within bzrlib code anywhere | 15:23 |
| jam | not even by the test suite | 15:23 |
| jam | Are you using it externally somehow? | 15:23 |
| jam | (bzrlib.merge.Merger.file_revisions()) | 15:24 |
| abentley | jam: I don't think I am using it externally. | 15:24 |
| abentley | jam: looks like it was added to support weave merge. | 15:25 |
| vila | abentley: and ensure_revision_trees() ? | 15:25 |
| abentley | vila: Same commit, actually. | 15:26 |
| vila | abentley: yeah, sorry, fired qblame just after typing my question:-/ | 15:26 |
| abentley | vila: Intitially, we couldn't do weave merge on working trees-- it was an all-repository operation. So we needed to ensure that the working tree was equivalent to a revision tree and then use the revision tree. | 15:27 |
| jam | vila: so as I said in the beginning... :) all of your test failures are because of broken tests | 15:42 |
| vila | jam: right, I'm finishing my submission and will file a new bug for that | 15:42 |
| vila | lol, good one... | 15:43 |
| vila | ERROR: per_intertree.test_compare.TestIterChanges.test_file_becomes_unversionable_bug_438569(InterDirStateTree(C)) | 15:43 |
| vila | Exception: unknown kind fifo | 15:43 |
| vila | huh? | 15:43 |
| vila | ooooh I merged trunk and didn't run make.... | 15:43 |
| vila | hurrah, we found a new way to catch people that don't recompile their extensions :D | 15:44 |
| vila | Too bad, it requires running the full test suite... | 15:44 |
| vila | beuno: if you're responsible for adding the small reminder of project >> bugs >> bugs # on all lp pages, be blessed ;-) | 15:45 |
| beuno | vila, I am :) | 15:46 |
| beuno | I have a version 2 in the pipeline that will make it even better | 15:46 |
| vila | beuno: smack on both cheeks :-P | 15:46 |
| beuno | :) | 15:47 |
| vila | beuno: I use that multiple times every day | 15:49 |
| vila | on the other hand, it seems we lost the bug history link... | 15:49 |
| eLBati | # bzr push | 15:50 |
| eLBati | Using saved push location: bzr+ssh://bazaar.launchpad.net/~openerp-community/openobject-doc/doc/ | 15:50 |
| eLBati | bzr: ERROR: These branches have diverged. See "bzr help diverged-branches" for more information. | 15:50 |
| eLBati | # bzr merge | 15:50 |
| eLBati | Merging from remembered parent location /home/ubuntu/workspace/openerp/doc/openobject-doc | 15:50 |
| eLBati | Nothing to do. | 15:50 |
| beuno | vila, I'm very glad to year that | 15:50 |
| eLBati | now ? :P | 15:50 |
| beuno | as for bug history, it will come back, interleaved with the comments, like the rest | 15:50 |
| vila | beuno: ha, I thought so more or less but it wasn't clear | 15:51 |
| vila | eLBati: so what ? you don't merge from the same branch you're trying to push to it seems | 15:51 |
| jam | eLBati: you are using different locations | 15:51 |
| jam | dang, vila beat me by 1 s | 15:52 |
| jam | eLBati: try 'bzr merge :push' | 15:52 |
| beuno | vila, file bugs for the specific items you want so they get prioritized | 15:52 |
| vila | jam: and with a longer sentence yeahhhhhhhh | 15:52 |
| eLBati | yesterday I pushed | 15:52 |
| vila | beuno: ok, I don't remember the specifics, I had a vague strange feeling and fullermd spotted the missing link | 15:53 |
| vila | eLBati: most probably you use a local mirror which was uptodate yesterday | 15:53 |
| beuno | vila, don't think about a missing link, think about missing data you need. File a bug for it, and I will make that information available to you | 15:53 |
| vila | beuno: sure, I understand, just giving you context of the original remarks | 15:54 |
| vila | beuno: by the way, any news for UDS | 15:55 |
| vila | ? | 15:55 |
| beuno | vila, I forgot, will ask now, one sec | 15:55 |
| beuno | vila, lets do it | 15:56 |
| beuno | edit the wiki | 15:56 |
| vila | beuno: done | 15:57 |
| eLBati | jam, what's the meaning of merge :push? | 15:57 |
| beuno | vila, awesome | 15:58 |
| jam | eLBati: merge from the location that I push to | 15:58 |
| vila | beuno: finally we may find some time to discuss a bit :D | 15:58 |
| beuno | vila, I will have my copy of bzr-uplaod up to date | 16:00 |
| vila | hehe | 16:00 |
| === Noldorin_ is now known as Noldorin | ||
| vila | jam: just checking, it's ok to remove methods deprecated in 1.13 when targeting 2.1b1 right ? | 17:03 |
| jam | vila: from the discussion with poolie, it is okay to remove anything that is marked deprecated in 2.0* in the 2.1* branch | 17:04 |
| jam | put another way | 17:04 |
| jam | you can remove anything from trunk which is marked deprecated in stable | 17:04 |
| jam | double check HACKING.txt, but that was my understanding | 17:04 |
| jam | as the 6-months stability is given by the stable branch | 17:04 |
| vila | makes sense | 17:05 |
| jam | I *think* that means we can land a 'deprecation' for 2.0.1, and just delete it from trunk | 17:05 |
| jam | but that may be a bit too hasty | 17:05 |
| jam | but certainly anything deprecated in 2.0.0 can go | 17:05 |
| vila | indeed, but 1.13 if far older | 17:05 |
| jam | and poolie has been doing that very thing :) | 17:05 |
| vila | And are such modifications considered trivial ? | 17:08 |
| vila | jam: ^ | 17:08 |
| jam | vila: I would probably put it up for review, at a minimum put it up for post-merge review | 17:10 |
| jam | but I do that for most trivial things | 17:10 |
| jam | I may submit it, but I still send it in so people know about it | 17:10 |
| macflag | if contributor ("C") has a separate copy of a central repo (which doesn't use bazaar yet, it has no versioning yet) and modifies and uploads the repo (without using bazaar) *after* the central repo started to use bazaar (and then suffered some changes itself), does bazaar know how to distinguish between differences caused by C contribution and differences caused by C'S original repo "not being up-to-date anymore"? | 17:11 |
| vila | post-merge review ? You mean you send the diff to the ML ? | 17:11 |
| vila | DO yo umean I should stop merging my trivial test cleanups ? | 17:11 |
| macflag | vila: are you talking to me? | 17:12 |
| jam | macflag: talking to me | 17:12 |
| jam | vila: If it is trivial enough to just merge, I would send a merge proposal, and then submit it to pqm without waiting | 17:13 |
| vila | wow, I never noticed you did that... | 17:13 |
| jam | I would use an mp, because that is the standard "review area" | 17:13 |
| jam | vila: I did it with bundle buggy | 17:13 |
| vila | haa | 17:13 |
| jam | I haven't had a trivial merge since we switched over | 17:13 |
| jam | vila: I generally marked it as (trivial) in the subject line, to make it clear I was landing this. | 17:14 |
| jam | I realize I can do post-merge reviews via bazaar-commits, but I prefer to keep things where people expect them. | 17:14 |
| vila | jam: Yeah, I *always* add (trivial) when I send them to pqm | 17:15 |
| jam | macflag: I'm not sure that I fully understand your set up. | 17:15 |
| jam | With "copy of a central repo with no versioning" | 17:15 |
| jam | I think 'repo' is confusing here, because you don't have a repository if you have no version control | 17:15 |
| jam | Let me see if I can rephrase what you asked | 17:15 |
| jam | and you tell me if it is correct | 17:15 |
| macflag | jam: there was no bazaar and no versioning before C made a copy | 17:16 |
| jam | macflag: If contributor "C" has a copy of my source code, and uploads a copy of that source code to a central location | 17:16 |
| jam | while at the same time, we started to version that central location using bazaar | 17:16 |
| jam | and someone made some changes and pushed them | 17:17 |
| jam | at that point, the central location considers the working copy "out of date" because of the push | 17:17 |
| macflag | yes ... | 17:17 |
| jam | but there are also local modifications to the source code | 17:17 |
| jam | because of contributor C | 17:17 |
| macflag | yes | 17:17 |
| jam | macflag: at that point, doing "bzr update" in the central location will apply the changes that were pushed | 17:17 |
| jam | and leave the local uncommitted changes around | 17:18 |
| macflag | and contributor C didn't use bazaar | 17:18 |
| jam | so that you can "bzr commit" them if you chose | 17:18 |
| jam | it will also generate appropriate conflicts, etc | 17:18 |
| jam | if the changes from C have issues with the changes that were pushed | 17:18 |
| jam | (so I'm pretty sure the answer you want is 'yes') | 17:18 |
| der| | hi, how do I remove all the conflicting files in a tree ? clean-tree --detritus is not removing the OTHER and THIS files | 17:19 |
| macflag | jam: will "bzr update" be based on the modification time of the files in the uploaded (unversioned) repository? | 17:21 |
| jam | vila: you have 2 spaces in the NEWS entry | 17:26 |
| jam | + (Vincent Ladeuil, #438158) | 17:26 |
| jam | macflag: bzr update will bring the lastest changes that were pushed into the working tree | 17:27 |
| jam | regardless the stat values of any file | 17:27 |
| vila | I don't believe for one second that you found that with your eyes only 8-) | 17:27 |
| jam | vila: I saw it looked wrong, and then highlighted it to make sure | 17:28 |
| jam | I use fixed-width fonts in my email | 17:28 |
| jam | so it is pretty obvious | 17:28 |
| jam | I'm surprised it wasn't obvious for you in emacs | 17:28 |
| vila | oh it is now that you mention it... | 17:28 |
| === Noldorin__ is now known as Noldorin | ||
| macflag | jam: what i mean is some files in C's uploaded copy will be different because they are not up-to-date, while others will look different because they are C's contribution. will bazaar be smart enough not to show me diffs/conflicts due to the former reason? | 17:30 |
| jam | macflag: we don't know the basis for C's changes | 17:31 |
| jam | so if a given file said "foo" in C's original copy, and then was updated in the central location to say "bar" by another users | 17:31 |
| jam | when C uploads his copy, it will look like a normal change reverting back to "foo" | 17:32 |
| jam | and 'bzr update' won't touch the file | 17:32 |
| jam | you can use things like "bzr status -r -5" to see the difference between the working tree and an older version of the tree | 17:32 |
| macflag | yeah, that makes sense | 17:32 |
| jam | but you pretty much have to "guess" to figure out what the basis of C's changes were | 17:32 |
| jam | if you can guess that well | 17:32 |
| jam | then your resolution probably becomes easier | 17:32 |
| macflag | jam: what if C also happens to possess and upload the basis (the original copy of the source). would this help? | 17:34 |
| jam | macflag: so if C posses the basis, what I would do is | 17:34 |
| jam | cd $central_reop | 17:34 |
| jam | cd $central_repo | 17:34 |
| jam | bzr up | 17:34 |
| jam | bzr revert # get rid of all of C's changed | 17:34 |
| jam | cd C; diff -u C-basis C-current > a.patch | 17:35 |
| jam | cd $central_repo | 17:35 |
| jam | bzr patch a.patch | 17:35 |
| jam | macflag: in other words, throw away all of C's changes on the central repo, and get him to give you a diff instead | 17:35 |
| jam | there are other possibilities | 17:36 |
| jam | but that is going to be the easiest on "macflag" :) | 17:36 |
| macflag | :) | 17:36 |
| jam | if you know the approximate date of the modifications | 17:37 |
| jam | you could do some checking of 'bzr log' to see what an expected basis is | 17:37 |
| jam | and then do some of the 'create a diff' work yourself | 17:38 |
| === Noldorin__ is now known as Noldorin | ||
| macflag | i think your first solution is the safest | 17:39 |
| macflag | or does it have some disadvantages that you think i may not see? i'm new to versioning stuff. | 17:39 |
| jam | macflag: #1 problem is that it depends on user C to do the right thing | 17:40 |
| jam | and C is *not* using version control | 17:40 |
| jam | is it likely/unlikely that the basis for C was versioned? | 17:40 |
| macflag | jam: isn't keeping the basis saved and uploading it together with the current version "the right thing"? | 17:41 |
| jam | macflag: so "keeping the basis saved" is something you have to trust that user C did | 17:41 |
| jam | many people wouldn't | 17:41 |
| jam | this user might have | 17:41 |
| macflag | unlikely, but the basis is certainly one of the previous versions in the bazaar repo | 17:41 |
| macflag | jam: but if they did it, it would be absolutely enough, right? | 17:42 |
| jam | macflag: if the user is ok using bazaar, I would tell them to do: | 17:42 |
| jam | bzr branch -r BASIS_REV $central_repo local | 17:42 |
| jam | cd local | 17:42 |
| jam | cp -ar ../C-current . | 17:42 |
| jam | bzr st | 17:42 |
| jam | bzr commit -m "Turn my changes in to a bzr revision" | 17:42 |
| jam | and then give that to you | 17:42 |
| jam | possibly via | 17:42 |
| jam | bzr send -o ../my-changes.patch $central-repo | 17:42 |
| jam | macflag: if you take the difference from a known basis to the current version, that is "enough information". | 17:43 |
| macflag | jam: what if they simply upload the repo? | 17:43 |
| jam | macflag: that is fine, too | 17:43 |
| macflag | so it seems bazaar is pretty powerful | 17:43 |
| jam | macflag: we try :) | 17:47 |
| macflag | :) | 17:47 |
| macflag | is "bzr branch" necessary when using totally independent/isolated repositories? | 17:48 |
| jam | macflag: versus what other command would you use? | 17:48 |
| jam | anyway, i'll be back in 30 min or so, time to get food | 17:48 |
| macflag | jam: well, versus simply copying the repo :) | 17:49 |
| verterok | howdy | 17:53 |
| james_w | hi verterok | 17:54 |
| verterok | james_w: hi | 17:54 |
| verterok | any mac user willing to test the shiny (and expmperimental) bzr.app standalone bundle? | 17:55 |
| verterok | *experimental too | 17:56 |
| arkanes | verterok: sure | 18:23 |
| arkanes | verterok: do I need to do blow away my working bzr first? | 18:23 |
| macflag | i want to create independent branches which are totally "amnesic" (except for what it's basis-version was, of course!). does what i'm saying make sense (as i said, i'm new to this stuff)? and is it possible? | 18:27 |
| macflag | it's=its* | 18:28 |
| macflag | and its=their* :) | 18:28 |
| jam | macflag: generally no. Though you can do stuff like "bzr log -r ancestor:trunk..-1" | 18:37 |
| macflag | jam: generally no, "it doesn't make sense" or "it isn't possible"? :) | 18:39 |
| jam | macflag: a branch is a pointer to a complete history of revisions, it is not a 'set' of revisions outside of that | 18:40 |
| jam | so while you can do stuff to compare two branches and see what is different | 18:40 |
| jam | all branches will point to their full history | 18:40 |
| jam | note that if you are using merging, the 'common basis' changes over time | 18:40 |
| jam | and you can have N branches and ask each one what is common versus the other | 18:40 |
| idnar | is there an easy way to figure out (programmatically) if a pull command pulled any revisions or not? | 18:41 |
| idnar | I suppose I could add some kind of hook, but that seems like more effort than it's worth | 18:41 |
| macflag | jam: then i guess i want something like a "snapshot" that only knows what version it is based on, right? | 18:43 |
| jam | macflag: well, you could just never commit.... | 18:46 |
| jam | not very useful | 18:46 |
| jam | idnar: 'pull -v' ? | 18:46 |
| Meths | idnar: Can't you parse the output for "No revisions to pull"? | 18:46 |
| jam | check the return code? (That may not give info, I'm not clear on pull's retcodes) | 18:46 |
| Meths | you have to watch bzr's output though as some info goes to stderr rather than stdout | 18:47 |
| jam | macflag: what is the *advantage* of only knowing the original version? | 18:48 |
| === Noldorin__ is now known as Noldorin | ||
| jam | you might like something like "bzr branch --stacked" but it really depends on what you are trying to get out of the system | 18:49 |
| macflag | jam: here's my use case: once in a while i want to email a "minimal" version of my repo to a friend that helps me with some correction and patching, and by "minimal" i mean i want my friend to know as little as possible (nothing, if possible) about the previous versions of my code (but the repo includes the full current version). then my friend will email it back to me and that will be "readopted" by my bzr. | 18:51 |
| Meths | Just use tar then | 18:52 |
| jam | macflag: bzr co --lightweight repo working_tree; tar cvjf working_tree.tar.bz2 working_tree | 18:52 |
| macflag | Meths: not including the versioning info? | 18:52 |
| jam | macflag: that will give you a working tree with pointers about what version it was at | 18:53 |
| macflag | jam: oh, so --lightweight does just that? | 18:53 |
| Meths | macflag: yeah, just leave out .bzr - looks like jam has a complete solution though | 18:53 |
| macflag | jam: and that's totally usable in my friend's bazaar and then totally remergeable in mine? | 18:53 |
| jam | macflag: the bit of confusion is that it isn't really a branch or a repository (by our terminology) | 18:53 |
| jam | macflag: well, he can't commit in it, because it will point to a branch he doesn't have | 18:53 |
| jam | but if you just want him to do his work... | 18:54 |
| jam | including 'bzr commit' | 18:54 |
| jam | then we need to think a bit more. | 18:54 |
| macflag | jam: but then how do i receive his changes? | 18:54 |
| jam | macflag: he tarballs it up and sends it back to you | 18:54 |
| jam | that is the 0-history model | 18:54 |
| jam | we are working on an idea called 'shallow branches' which would have some history but not much. (say 1 revision worth) | 18:55 |
| jam | but that hasn't been implemented yet | 18:55 |
| macflag | jam: i see, but will he be able to do his own versioning, totally mergeable into mine? | 18:55 |
| jam | macflag: generally he won't do versioning | 18:55 |
| jam | but when he sends it back to you, you can "bzr commit -m "his stuff" and merge that | 18:55 |
| macflag | jam: i see. that sounds good enough. | 18:55 |
| macflag | jam: um, actually it sounds perfect. or am i missing something? | 18:56 |
| jam | macflag: just if he wants to be able to "Bzr commit" | 18:56 |
| jam | otherwise a lightweight checkout is just what you want | 18:56 |
| jam | since you said "I want him to have 0 history" that seems to fit | 18:56 |
| macflag | jam: why would he want to be able to commit? | 18:56 |
| macflag | jam: yes, this is what i want | 18:56 |
| jam | macflag: to do his "own versioning" | 18:57 |
| macflag | jam: oh, well, i meant apart from that :) | 18:57 |
| jam | macflag: (I don't develop without a VCS anymore, myself) | 18:57 |
| jam | sort of like using an editor without an undo button | 18:57 |
| macflag | i know what you mean :) | 18:57 |
| macflag | does bzr use meld by default? | 18:58 |
| jam | I don't believe so | 18:59 |
| LarstiQ | pfft, undo! | 18:59 |
| jam | but I think we have built-in support for it | 18:59 |
| jam | bzr diff --using meld | 18:59 |
| jam | I think works | 18:59 |
| jam | etc | 18:59 |
| LarstiQ | including undo in Blender was the biggest mistake in it's development! *cough* | 18:59 |
| macflag | what does it use by default instead? | 18:59 |
| jam | macflag: to do what? | 19:00 |
| macflag | LarstiQ: are there any people that hate undo? | 19:00 |
| macflag | jam: dif | 19:00 |
| macflag | jam: diff | 19:00 |
| jam | macflag: 'bzr diff' just does an internal diff algorithm that compares lines and shows you the changes as a "unified diff" | 19:00 |
| jam | there is also "bzr qdiff" which makes that pretty for display | 19:00 |
| jam | in a GUI | 19:00 |
| LarstiQ | macflag: hmm, not that strong I think. But the argument is that artists who know how to work without undo are better in some respects. | 19:01 |
| macflag | i guess meld is preferable | 19:01 |
| LarstiQ | macflag: thinking more of what their desired outcome is | 19:01 |
| LarstiQ | macflag: knowing the tool better | 19:01 |
| macflag | LarstiQ: maybe | 19:01 |
| LarstiQ | macflag: talking specifically about Blender here | 19:01 |
| LarstiQ | I myself am glad the undo is there :) | 19:02 |
| macflag | i don't see how any of these reasons can be blender-specific. | 19:02 |
| LarstiQ | they're not, but for a very long time Blender did have an undo feature | 19:04 |
| LarstiQ | did _not_ | 19:04 |
| LarstiQ | and some people complained about that, and others didn't need it | 19:04 |
| LarstiQ | after spending enough time with blender that they could work without | 19:05 |
| jam | LarstiQ: have you ever read Penny Arcade (comic strip)? | 19:05 |
| jam | he occasionally posts videos of him doing the drawings | 19:05 |
| jam | generally with a Wacom Tablet | 19:05 |
| macflag | undo is easy *not* to use, so now blender is ok for everybody | 19:05 |
| jam | pretty amazing (for me) to watch | 19:05 |
| LarstiQ | jam: not followed, but on occassion | 19:05 |
| jam | and he uses undo fairly often | 19:05 |
| jam | Painters generally use pencil and then ink/paint over that | 19:06 |
| LarstiQ | macflag: that's not strictly true about crutches | 19:06 |
| LarstiQ | jam: right | 19:06 |
| LarstiQ | jam: yeah, it certainly is a liberating feature over analog | 19:06 |
| jam | I would guess that a Wacom tablet is almost enough to ease the rest of the transition | 19:07 |
| jam | since you get some pressure sensitivity, etc. | 19:07 |
| jam | certainly keyboard + mouse is awful for painting :) | 19:07 |
| jam | and a lot of online cartoonists still work in pencil, then scan and ink using photoshop | 19:08 |
| LarstiQ | tablet is way nicer, but even without people can be amazing | 19:08 |
| LarstiQ | jam: right | 19:08 |
| macflag | LarstiQ: what are "crutches"? | 19:11 |
| jam | macflag: http://en.wikipedia.org/wiki/Crutch | 19:11 |
| macflag | jam: in blender :) | 19:11 |
| jam | macflag: undo is a crutch | 19:11 |
| jam | you don't *need* it | 19:11 |
| macflag | oh :) | 19:11 |
| jam | macflag: arguably a VCS is a crutch | 19:12 |
| jam | you can do everything it does without it | 19:12 |
| jam | you just have to be very careful in what you do | 19:12 |
| LarstiQ | sure | 19:12 |
| LarstiQ | wether something is a crutch depends on how heavily you lean on it, or could do the same without | 19:12 |
| jam | I personally view it as more of a jet-pack :) | 19:12 |
| LarstiQ | hehe :) | 19:13 |
| * LarstiQ is with jam on that one | 19:13 | |
| macflag | then i was misunderstood, by "undo is easy *not* to use, so the new blender is ok for everybody" i meant "nobody can be forced to use it, so the anti-undoers have no reason to be discontent with its addition" | 19:13 |
| flutherben | Ha all. Anyone know how can I set up a smart server that restricts access? I'm trying to use bzr --serve | 19:13 |
| LarstiQ | macflag: I don't agree with that, but nevermind. I think having undo is a good idea, and some of the best blender artists I know use it. | 19:14 |
| macflag | LarstiQ: i think having undo is a very good idea, too. i was just saying that nobody can be upset with its presence: if they don't want to use it, they are free to ignore it. | 19:15 |
| jam | flutherben: 'bzr serve' has no access control built in. We recommend using either 'bzr+ssh' or 'bzr+http' and doing the access control in the ssh/http layers | 19:15 |
| jam | macflag: artists are often not as rational as programmers | 19:15 |
| jam | at least the argument LarstiQ brought up earlier was that undo allows people to do 'good enough' work, without learning enough to do *better* work | 19:16 |
| flutherben | jam: how does performance compare with bzr+http? (I'm trying to setup a server so my other hosts can download during a deploy and not need a password) | 19:16 |
| macflag | jam: yeah. i guess keeping themselves in good shape and spontaneous (and probably improvisational) is an important consideration/value for them. | 19:17 |
| jam | flutherben: so you want auth with no password? | 19:17 |
| jam | bzr:// should be approximately the same as bzr+http:// == ~ bzr+ssh:// | 19:17 |
| jam | the main issues with bzr+ssh is the ssh handshake overhead | 19:17 |
| jam | and possibly the encryption overhead | 19:18 |
| flutherben | jam: yeah... :) previously we were using apache2 to check domains as access | 19:18 |
| jam | depending on your cpu overhead, etc. | 19:18 |
| macflag | jam: or rather "forcing themselves to stick to an "irreversibilistic" approach ..." | 19:18 |
| jam | in the end | 19:18 |
| jam | it should be a small handful of round-trips and a lot of bulk data transfer | 19:18 |
| jam | which is pretty independent between bzr:// and bzr+http:// | 19:18 |
| flutherben | yeah, we were just using http before with apache, and I want to try a smart server | 19:18 |
| flutherben | but I'm having trouble finding a lot of explaination | 19:19 |
| jam | macflag: there is a saying I've heard in theater. Movies make you money, TV makes you popular, and Theater makes you good... :) | 19:19 |
| jam | flutherben: bzr+http:// should generally perform significantly better than http:// | 19:19 |
| flutherben | I suppose the other method would be to use bzr+ssh, and add all my servers to the auth_keys, but that is less appealing | 19:19 |
| jam | primarily because of the "number of requests" aspect | 19:19 |
| macflag | LarstiQ: can you agree to what i said? | 19:20 |
| flutherben | jam: great, thanks. Let me see if I can find out more about how to set it up | 19:20 |
| LarstiQ | macflag: no :) I get your stance that individuals can decide not to use it for themselves and that others can make a choice to use it without directly impacting the non-using ones. | 19:20 |
| LarstiQ | macflag: but if you care about how the rest of your community develops, it's not just about wether you yourself use it or not | 19:21 |
| jam | flutherben: http://doc.bazaar-vcs.org/latest/en/user-guide/http_smart_server.html | 19:21 |
| LarstiQ | macflag: it's a bit more of a hardliner than an all-inclusive lookout | 19:21 |
| jam | might be a little out of date | 19:22 |
| macflag | LarstiQ: that's why i was implying that adding undo would benefit both categories, thus being the more rational choice | 19:22 |
| flutherben | jam: thanks... looks like I might try mod_wsgi | 19:23 |
| LarstiQ | macflag: undo would be detriment to ensuring everyone is trained to not use it | 19:23 |
| LarstiQ | macflag: but this discussion is all very abstract and moot | 19:23 |
| macflag | LarstiQ: that's a little too picky, i think | 19:23 |
| jam | flutherben: that would be the general recommendation | 19:23 |
| macflag | LarstiQ: do you use bazaar with blender? | 19:24 |
| LarstiQ | macflag: mu? | 19:24 |
| flutherben | jam: oops.. the mod_wsgi link in broken | 19:24 |
| LarstiQ | macflag: I don't use blender | 19:24 |
| LarstiQ | macflag: way way back I did some work on the blender code, back then the project was in cvs | 19:25 |
| LarstiQ | macflag: more recent, I have done sysadmin work for the Blender foundation | 19:25 |
| jam | flutherben: perhaps this is the right one? http://code.google.com/p/modwsgi/ | 19:25 |
| macflag | i see | 19:25 |
| flutherben | jam: yeah, I'll try that | 19:25 |
| LarstiQ | macflag: the introduction of 'undo' was from somewhere begin of the opensource period iirc | 19:25 |
| jam | flutherben: I know there are some people using bzr+http, but it has been quite a while since I tried | 19:26 |
| jam | if you get any tips/tricks I'm sure we'd be happy to get updates to the docs | 19:26 |
| jam | (doc/en/user-guide/http_smart_server.txt) | 19:26 |
| macflag | LarstiQ: what did you mean by "mu"? | 19:26 |
| flutherben | jam: okay... I'll let you know | 19:26 |
| LarstiQ | macflag: so is your question wether people use bazaar to version .blends, or use bazaar for the Blender project versioning? | 19:26 |
| LarstiQ | macflag: "I can't anser your question because it is the wrong question" | 19:27 |
| macflag | LarstiQ: to version .blends | 19:27 |
| macflag | :) | 19:27 |
| LarstiQ | macflag: http://en.wikipedia.org/wiki/Mu_(negative) | 19:27 |
| LarstiQ | macflag: I know people who version .blends with bazaar, and I would too | 19:27 |
| macflag | LarstiQ: i'm interested in versioning databases too, i know it's difficult | 19:28 |
| === Noldorin__ is now known as Noldorin | ||
| LarstiQ | macflag: any specifics on that? Things like VisTrails? | 19:31 |
| jam | flutherben: there is also this open bug #348308 | 19:32 |
| jam | which has a workaround in the bug posting | 19:32 |
| ubottu | Launchpad bug 348308 in bzr "Smart server jail breaks bzr+http with shared repos" [High,Triaged] https://launchpad.net/bugs/348308 | 19:32 |
| jam | but seems to need an actual fix in bzr | 19:32 |
| macflag | LarstiQ: can i use vistrails with bazaar? | 19:33 |
| LarstiQ | macflag: they don't interact meaningful right now | 19:34 |
| LarstiQ | macflag: VisTrails keeps track of it's own versioning information, and stores that in an rdbms or in an xml file (zipped or not) | 19:34 |
| flutherben | jam: hrm. I pretty sure we use a shared repo, which makes me think this won't work | 19:35 |
| jam | flutherben: as mentioned, you can add some stuff in your wsgi file to make it work | 19:35 |
| jam | though you shouldn't *have* to. | 19:35 |
| jam | well, in python wsgi adapter you have to configure you can also poke at the jail configuration | 19:35 |
| flutherben | hmmm, okay, might give that a try... | 19:36 |
| Vittor | juego de boxeo online http://www.kobox.org/kobox-fande-Nourine.html | 19:47 |
| * mneptok blinks | 20:04 | |
| === Noldorin__ is now known as Noldorin | ||
| === Noldorin__ is now known as Noldorin | ||
| === Noldorin__ is now known as Noldorin | ||
| mereandor | how do I get the diff for the last commit that was made? bzr help revisionspec does not show how to get the current version... | 20:51 |
| mereandor | nevermind I worked it out | 20:58 |
| mereandor | -2 not -1 | 20:58 |
| === Noldorin__ is now known as Noldorin | ||
| awmcclain | Hrm. I merged in a branch and forgot to check in the merge -- I made some changes to one of the files and then reverted -- which deleted the file. Is there a way to restore the orignal file from the merge without checking in first? | 21:40 |
| awmcclain | sorry, i only reverted the one file. | 21:40 |
| === khmarbaise__ is now known as khmarbaise | ||
| === james_w` is now known as james_w | ||
| === rockstar` is now known as rockstar | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
