| dOxxx | evening... | 00:01 |
|---|---|---|
| dOxxx | Would it be acceptable to modify start_bzr_subprocess and finish_bzr_subprocess to not raise TestSkipped if python 2.6's Popen.send_signal method is available? | 00:29 |
| lifeless | dOxxx: I don't follow | 00:51 |
| * igc bbiab | 01:06 | |
| === abentley1 is now known as abentley | ||
| dOxxx | lifeless: start_bzr_subprocess raises TestSkipped if os.kill isn't available, as on win32. However, with ptyon 2.6, the subprocess.Popen class has a send_signal method which maps SIGTERM to the TerminateProcess Win32 function. | 01:24 |
| dOxxx | lifeless: to make more tests run on win32, I was wondering if it would be acceptable to add an alternate codepath that used Popen.send_signal if it was available | 01:25 |
| lifeless | yes | 01:28 |
| lifeless | thats makes sense | 01:28 |
| lifeless | simply not raising TestSkipped did not make sense. | 01:28 |
| === abentley1 is now known as abentley | ||
| === retupmoca` is now known as retupmoca | ||
| ricardo_br | Is there any command in bazaar to remove those backup files? ex:database.php.~1~ | 01:50 |
| mwhudson | ricardo_br: it's a bit more than you're asking for but bzr clean-tree --ignored will kill them | 01:51 |
| === jamesh_ is now known as jamesh | ||
| ricardo_br | mwhudson : it's almost it, but I have some ignored folders that I don't want to delete (some project folders), is there any linux command that I can use? | 01:57 |
| mwhudson | ricardo_br: well 'find . -name \*~ -print0 | xargs -0 rm' will do it i guess | 01:57 |
| ricardo_br | mwhudson: wow, I really need to study these shell commands, it worked, thanks | 02:02 |
| mwhudson | ricardo_br: find | xargs is both very handy and somewhat crazy :-) | 02:03 |
| === abentley1 is now known as abentley | ||
| ricardo_br | well, I read the first part of the xargs' man page and it really scared me (xargs - build and execute command lines from standard input), A few time ago I was using windows I must admit | 02:07 |
| mwhudson | ricardo_br: you know the saying "unix *is* user friendly, it's just picky about who its friends are" ? | 02:08 |
| Peng | Oh wow! My original "bzr pull" isn't entirely dead. | 02:09 |
| * igc lunch | 02:10 | |
| === abentley1 is now known as abentley | ||
| === abentley1 is now known as abentley | ||
| === abentley1 is now known as abentley | ||
| ricardo_br | mwhudson: no I don't know this one, probably I'm that slow second cousin | 02:17 |
| mkanat | ricardo_br: I think you want bzr clean-tree --detritus by the way. | 02:23 |
| ricardo_br | mkanat: thank you! It's exactly what I'm looking for, I don't have to be friend with unix anymore | 02:30 |
| mkanat | :-) | 02:30 |
| mwhudson | oh right | 02:39 |
| mkanat | mwhudson: Did you see my long email? | 02:44 |
| mwhudson | mkanat: yes, it's been on my "to reply" list for about 7 hours now :) | 02:44 |
| mkanat | mwhudson: Hahaha, okay. :-) | 02:45 |
| === abentley1 is now known as abentley | ||
| mwhudson | mkanat: another team in launchpad trying spawning | 03:03 |
| mwhudson | mkanat: the scars are ugly and fresh | 03:03 |
| mkanat | mwhudson: For loggerhead? | 03:03 |
| mwhudson | no, for some u1 related thing | 03:03 |
| mwhudson | mkanat: they went back to using paste | 03:03 |
| mkanat | Okay. | 03:03 |
| mkanat | Well, Spawning does say it's still a beta. | 03:03 |
| mwhudson | ehh, i guess i should reply to the mail | 03:04 |
| mwhudson | then have a conversation | 03:04 |
| mwhudson | not the other way around :-) | 03:04 |
| mkanat | mwhudson: Okay. :-) | 03:04 |
| mkanat | mwhudson: Spawning was, of course, just a random idea without any research yet. :-) | 03:04 |
| mkanat | mwhudson: The more general idea being "scale better". :-) | 03:04 |
| mwhudson | mkanat: yes, i think that's basically the best idea | 03:05 |
| mwhudson | lifeless: can you remember the problems with spawning? | 03:08 |
| mwhudson | i have this vague recollection was that it wasn't very specific, it just didn't work very well | 03:08 |
| mwhudson | and was too magical | 03:08 |
| lifeless | yes | 03:11 |
| lifeless | it died inthe ass for u1 | 03:11 |
| lifeless | it does things like monitor for module changes and reload() when a foo.py changes (just thing what apt-get install will do to it :P) | 03:11 |
| lifeless | s/thing /think / | 03:11 |
| lifeless | my suggestion if you want cpu concurrency for loggerhead is haproxy | 03:12 |
| lifeless | or squid | 03:12 |
| lifeless | just add another backend service and tell the frontend stuff to send to both. | 03:12 |
| lifeless | simple, easy to admin, no code changes needed. | 03:12 |
| mwhudson | yeppers | 03:13 |
| mkanat | lifeless: That was my idea as well. | 03:20 |
| mkanat | We just need a way to share the revision cache between processes and then we're set. | 03:20 |
| mkanat | That scales across cores and machines as well. | 03:20 |
| dOxxx | holy cow, it's an utter mission compiling python extensions for x64 on windows | 03:21 |
| AfC | Once upon a time there was someone doing distributed bugs (with bzr, I think, but no matter) | 03:21 |
| AfC | does anyone have a suggestion for listing bugs _in tree_ of a project (ie not in a distributed bug database, but in a project tree) so that commits to code are done along with commits to {TODO, BUGS, bugs/filename.txt, ?} | 03:22 |
| mkanat | AfC: Not particularly. (Somebody else might.) It has always seemed to me that one of the major purposes of bug-tracking was central coordination, whereas development and branching really should be distributed. | 03:24 |
| mwhudson | AfC: "bugseveryehwere" | 03:24 |
| mwhudson | AfC: http://bugseverywhere.org/be/show/HomePage | 03:24 |
| rubbs | Ok, so I've submitted a patch last night on a documentation bug, and got some feedback. I made changes according to the suggestions, and pushed up the results. I then made a comment, but taged it with the "resubmit" vote. I've just now realized that it wasn't a tag but a review vote. | 03:28 |
| rubbs | what do I do now? | 03:28 |
| rubbs | is there anyway to delete that comment with the "resubmit" vote? | 03:30 |
| AfC | mwhudson: that was what I was thinking of | 03:31 |
| mwhudson | AfC: all abentley's fault iirc | 03:31 |
| AfC | mwhudson: right | 03:31 |
| AfC | mkanat: well, not really. What good is a centralized [only] bug database if you're not on the internet? | 03:31 |
| AfC | If you take distributed == disconnected you empower a lot more than just branches. | 03:32 |
| mkanat | AfC: Yeah, to some degree. I think it depends on the project. | 03:32 |
| AfC | mwhudson: do you know if Aaron is [still] using bugseverywhere? | 03:33 |
| mwhudson | AfC: not much, i think | 03:33 |
| mwhudson | AfC: but here he is, you can ask him :-) | 03:34 |
| AfC | mkanat: again, not really. If you the coder are frequently off the global network, then a bug database not locally accessible isn't any help to your development efforts | 03:34 |
| AfC | abentley: mwhudson mentioned a project of yours you once worked on, "bugseverywhere"; I was curious what your current opinion of it is? | 03:35 |
| mkanat | AfC: Sure, but that's a separate issue, I think. | 03:35 |
| AfC | mkanat: that's the issue I'm trying to redress | 03:35 |
| mkanat | AfC: Though not totally. | 03:35 |
| mkanat | AfC: Fair enough. :-) | 03:35 |
| mkanat | AfC: There are desktop clients for some trackers that will do offline work. | 03:35 |
| fullermd | Doesn't whatsitsname include bug stuff... | 03:35 |
| AfC | mkanat: no web hosted centralized only bug database is any use to me as an open source developer, because both I and my collaborators are only intermittently on the internet | 03:36 |
| abentley | AfC: I think it's still a useful idea, but the tool could use some work to become more forgiving. | 03:36 |
| fullermd | Fossil, that's it. The thing the SQLite guy did. | 03:36 |
| mkanat | AfC: That's a situation I haven't thought of much, I have to admit. | 03:36 |
| mkanat | AfC: Where I am, it's almost impossible to get away from the Internet. :-) | 03:36 |
| fullermd | http://www.fossil-scm.org/index.html/doc/tip/www/bugtheory.wiki | 03:36 |
| abentley | AfC: Chris Ball maintains it now, and there's a small community around it, which is better than I ever did. | 03:37 |
| AfC | abentley: fair enough | 03:37 |
| lifeless | theres another distributed bug db | 03:38 |
| fullermd | (note that I haven't done more than read about it, so I don't know how or how well it works in practice) | 03:38 |
| * AfC pulls the plug on his wireless internet connection to conserve battery | 03:38 | |
| AfC | mkanat: [see? :)] | 03:38 |
| AfC | lifeless: oh? | 03:38 |
| lifeless | AfC: I'll mail you | 03:39 |
| lifeless | some web3 thing - the sharecropper argument, they made a distributed db and wrote a bug tracker on it | 03:39 |
| === abentley1 is now known as abentley | ||
| AfC | lifeless: you have an idea of a google phrase to hunt for? | 03:40 |
| mkanat | mwhudson: Anyhow, an email response would probably be good since that's how we arrange the go-ahead for me to do further work. | 03:41 |
| mwhudson | mkanat: my email is a bit of a ramble tbh so far | 03:41 |
| mwhudson | oh well | 03:41 |
| mkanat | mwhudson: Honestly, I'd almost just love to help you out in my free time, except that that doesn't exist, and when it does, I don't use it to code. :-D | 03:41 |
| mkanat | mwhudson: That's OK. :-) | 03:41 |
| AfC | lifeless: ok, thanks! | 03:41 |
| lifeless | http://www.stackfoundry.com/dbug/ could be interesting too | 03:41 |
| * AfC ends essentially off topic conversation | 03:41 | |
| mkanat | AfC: I have to admit I found it interesting, since I'm one of the primary developers of a bug-tracking system. | 03:42 |
| mkanat | I haven't yet seen a pressing *broad* need for distribution in bug-tracking, but that doesn't mean it isn't necessary, useful, or going to become one of those two things. | 03:42 |
| mkanat | AfC: So if you find any of those to be particularly useful or interesting, I'd be interested to know. | 03:43 |
| lifeless | AfC: http://code.bestpractical.com/project/Prophet | 03:43 |
| lifeless | http://syncwith.us/sd/bugs | 03:44 |
| AfC | lifeless: thanks Robert. Will look. | 03:44 |
| lifeless | I make no assertions | 03:44 |
| lifeless | it crossed my radar a while back and seemed interesting | 03:44 |
| lifeless | though it looks like they use git now for the bts, rather than prophet, which doesn't fit my memory | 03:44 |
| AfC | lifeless: NO WARRANTIES :) | 03:44 |
| AfC | lifeless: k | 03:45 |
| * AfC hibernates [or, reboots and fscks assuming the thing crashes again] | 03:45 | |
| mwhudson | mkanat: mail sent | 03:50 |
| mkanat | mwhudson: Thank you. :-) | 03:50 |
| * mwhudson tries to remember why the backend server for codebrowse takes path based urls, not id based ones | 03:58 | |
| mwhudson | oh, maybe because we tie access control up with the translation from name -> id | 03:58 |
| mwhudson | man | 03:58 |
| RenatoSilva | verterok_: hi | 03:58 |
| RenatoSilva | dOxxx: hi | 03:58 |
| mwhudson | we need a much smarter frontend :( | 03:59 |
| dOxxx | RenatoSilva: heya | 03:59 |
| lifeless | mkanat: I wouldn't share the caches | 04:00 |
| lifeless | mkanat: tell the front end how much of the path to hash to the same backends on | 04:00 |
| RenatoSilva | dOxxx: hi, thanks for fixing that test bug. Even formely deactivated AVG was still working. I ended up uninstalling AVG, now the tests pass fine :) | 04:00 |
| mkanat | lifeless: That would be OK, too. | 04:01 |
| mwhudson | hm, the frontend we already have could do that | 04:01 |
| mkanat | lifeless: We're also discussing the possibility of just removing the cache entirely. | 04:01 |
| mwhudson | seeing as it has the branch id to hand | 04:01 |
| abentley | mwhudson: Are you using your router from the sprint? I'm using my eee as a router again! | 04:01 |
| mwhudson | well | 04:01 |
| mwhudson | yes | 04:01 |
| mwhudson | abentley: yes, finally | 04:01 |
| mwhudson | abentley: argh | 04:01 |
| mwhudson | abentley: because of the xx:45 disconnects? | 04:01 |
| lifeless | mkanat: I've suggested that that is a good idea :) | 04:01 |
| RenatoSilva | what's the arg for bzr selftest <plugin> that makes it faster? | 04:02 |
| lifeless | RenatoSilva: -s bp.pluginname | 04:02 |
| abentley | mwhudson: That, and increasingly-agonizing internet connectivity in general. | 04:02 |
| lifeless | RenatoSilva: note that this prefix is buggy | 04:02 |
| mwhudson | abentley: what did you have before? | 04:02 |
| lifeless | RenatoSilva: because it excludes interface conformance tests (which may not apply to you). But if they do apply to you using that doesn't test the whole plugin. | 04:02 |
| abentley | mwhudson: wrt54g | 04:03 |
| mkanat | mwhudson: I replied, but if the list is moderated, you'll have to clear my reply, since I'm not on the list. | 04:03 |
| mwhudson | abentley: huh, i thought they were ok | 04:03 |
| mwhudson | mkanat: i think it is | 04:03 |
| RenatoSilva | lifeless: interface conformance tests? | 04:03 |
| abentley | mwhudson: I've used this one for years. Maybe the love is gone. | 04:03 |
| mkanat | My WRT-54G is pretty much OK, though I have DD-WRT on it. | 04:04 |
| mwhudson | abentley: or maybe your ire needs to be sent further upstream | 04:04 |
| RenatoSilva | lifeless: can't find any info about "bp" in bzr help selftest | 04:04 |
| abentley | mwhudson: I tried that, but elmo wasn't having it. | 04:04 |
| mwhudson | but i guess changing router is a good first thing to try | 04:04 |
| mwhudson | abentley: maybe not that far :-) | 04:04 |
| * rubbs does a little dance. His first patch ever was just accepted | 04:05 | |
| abentley | mwhudson: I went to the vanguard on #is, but elmo joined the conversation. | 04:05 |
| mwhudson | abentley: i meant your isp | 04:05 |
| abentley | mwhudson: mtr showed packet loss at the entry point to canonical, so I went to #is. elmo explained that this doesn't really prove a problem, because routers will often discard ICMP datagrams. | 04:07 |
| mwhudson | abentley: oh right | 04:07 |
| mkanat | rubbs: 'Grats! | 04:11 |
| rubbs | mkanat: thanks! | 04:12 |
| RenatoSilva | anyone else getting this error? http://img69.imageshack.us/img69/9431/qterror.png | 04:16 |
| spm | mkanat: fyi; we were arrrgggghhh!ing yesterday over the pager in gdb? rtfm reveals: (gdb) set pagination off :-) | 04:42 |
| mkanat | spm: Ahhh. :-) | 04:42 |
| spm | doncha hate it when the solution is the obvious one! | 04:43 |
| mkanat | :-) | 04:43 |
| mwhudson | spm: set height 0 also does that i think | 04:45 |
| spm | mwhudson: so it does.! ta! "The number of lines GDB thinks are in a page. Use 0 to keep GDB from pausing." | 04:48 |
| * mwhudson stops for the day | 04:50 | |
| spm | night mwhudson, have a great w/e! | 04:51 |
| mwhudson | spm: well i'm working tomorrow :) | 04:51 |
| mwhudson | swap day for a couple of weeks | 04:51 |
| spm | ahhh. fair enough. that'll learn you for having a honeymoon :-P | 04:52 |
| mwhudson | yeah | 04:54 |
| === keithy_ is now known as keithy | ||
| === keithy_ is now known as keithy | ||
| dOxxx | what version of pycrypto and paramiko does bzr use? | 05:34 |
| lifeless | whatever you have installed | 05:39 |
| lifeless | [was that what you meant to ask?] | 05:39 |
| dOxxx | lifeless: sorry, it's late and I'm not thinking straight. what version of pycrypto and paramiko does the windows installer bundle? | 05:49 |
| lifeless | no idea; I thought pycrypto was built in now, and its likely latest released paramiko | 05:51 |
| dOxxx | lifeless: The problem I'm having is that in order to use ssh while running bzr from source, I need to have paramiko and pycrypto installed for the version of python I'm using. However, I'm getting deprecation warnings about the sha and md5 modules. | 05:55 |
| dOxxx | lifeless: Is it because I'm using python 2.6? | 05:55 |
| dOxxx | hmm bzr from windows installer bundles python 2.5, that's probably why I don't see the warnings when I'm using that | 05:56 |
| lifeless | dOxxx: I'm pretty sure we fixed all our deprecated warnings | 05:56 |
| lifeless | what bzr are you using? | 05:56 |
| dOxxx | lifeless: latest from bzr.dev. these deprecation warnings are coming from pycrypto v2.0.1. if I try pycrypto v2.1.0b1, I get different deprecation warnings about RandomPool | 05:58 |
| lifeless | oh | 05:59 |
| lifeless | :( | 06:00 |
| dOxxx | they're only warnings, stuff still works, it just irks me when I'm running selftest every couple of minutes to test a change and I have to mentally filter out these warnings | 06:00 |
| lifeless | yeah | 06:04 |
| lifeless | you could fix it :) | 06:04 |
| dOxxx | bleh | 06:04 |
| dOxxx | :) | 06:04 |
| dOxxx | not at 1am ;) | 06:04 |
| dOxxx | good night! | 06:41 |
| fullermd | Yes, stock pyrcrpto has warnings with py2.6. | 06:42 |
| dOxxx | ah | 06:42 |
| * fullermd khan speel... | 06:42 | |
| fullermd | There are patches floating around. I know there's one on LP somewhere for Ubuntu. The FreeBSD port has one. | 06:42 |
| dOxxx | hmm maybe I'll scrounge around tomorrow | 06:42 |
| dOxxx | thanks for the info | 06:42 |
| fullermd | (neither being platform-specific; it's pure py) | 06:42 |
| dOxxx | good night :) | 06:43 |
| === abentley1 is now known as abentley | ||
| MvG | LarstiQ: When you find the time, can you try whether lp:~gagern/trac-bzr/quoting works on trac 0.10? I fear it won't... | 07:33 |
| * igc dinner | 08:01 | |
| eMerzh | hi ... i have pbm to access a repository behind a proxy... what should i look to? | 08:55 |
| eMerzh | i've well my http_proxy variable defined | 08:55 |
| bialix | jam: when you'll have a couple of free minutes -- I have a question | 11:59 |
| Garagoth | Hello. | 12:15 |
| Garagoth | I wanted to try Bazaar, but once I installed it, it fails... 'bzr version' gives me a traceback with message: 'UnboundLocalError: local variable 'version' referenced before assignment' | 12:16 |
| Garagoth | Could anyone help me with that? | 12:17 |
| LarstiQ | that sounds rather broken | 12:17 |
| LarstiQ | Garagoth: could you pastebin the full traceback? | 12:17 |
| Peng | Garagoth: Pastebin the traceback. | 12:17 |
| Peng | D'oh~ | 12:17 |
| LarstiQ | MvG: hmm, I'm getting TracError: Unsupported version control system "bzr" | 12:17 |
| LarstiQ | MvG: but unsure why | 12:18 |
| igc | night all | 12:18 |
| LarstiQ | night igc! | 12:18 |
| Peng | igc: Good night. :) | 12:18 |
| Garagoth | pastebin ? | 12:18 |
| Peng | Garagoth: Paste it on http://paste.ubuntu.com/ or a similar site and give us the URL. | 12:18 |
| LarstiQ | ubottu: paste? | 12:18 |
| ubottu | Sorry, I don't know anything about paste? | 12:18 |
| LarstiQ | hmm | 12:18 |
| igc | Hi LarstiQ! Nice to hear from you | 12:18 |
| igc | Thanks Peng | 12:18 |
| LarstiQ | igc: likewise :) | 12:18 |
| MvG | LarstiQ: Never mind, I'm just about to set up a dedicated apache config on my desktop in order to test trac-bzr, I'll set up one with 0.10 as well. | 12:19 |
| Garagoth | http://paste.ubuntu.com/323262/ | 12:19 |
| LarstiQ | MvG: oh, ok | 12:19 |
| LarstiQ | Garagoth: ehm, your python install seems to be broken | 12:19 |
| Garagoth | LarstiQ: Ok, what is wrong with it? | 12:20 |
| Peng | Garagoth: What distro are you on? | 12:21 |
| Garagoth | Archlinux | 12:21 |
| Peng | Garagoth: Or, um, OS in general? | 12:21 |
| Peng | Oh. | 12:21 |
| LarstiQ | j~.~.~. | 12:22 |
| LarstiQ | gah | 12:22 |
| Peng | Garagoth: 1.) There's a bug in Python's platform module, 2.) You have a weird /etc/*release or /etc/*version file; otherwise the bug wouldn't be exposed. | 12:22 |
| Peng | Garagoth: To be more specific, it's empty. | 12:23 |
| Garagoth | Peng: Both release and version are empty. | 12:23 |
| Peng | Garagoth: Yes, well, that would be your problem. | 12:23 |
| Garagoth | Ok. version now works. | 12:25 |
| Peng | Note to self: File Python bug: platform._parse_release_file UnboundLocalError if the file is empty. | 12:25 |
| Peng | (Or if the first line is.) | 12:25 |
| Garagoth | release is still empty... but I had a test version file not from my distro ;-) | 12:25 |
| Peng | Anyway, I was eating pizza and/or watching TV. See ya. | 12:26 |
| Garagoth | Thanks for info. | 12:26 |
| Garagoth | and help/ | 12:26 |
| Garagoth | Now I have another issue... http://paste.ubuntu.com/323273/ | 12:29 |
| bialix | LarstiQ: hi | 12:34 |
| bialix | LarstiQ: I have some experience with trac-bzr, so I might help maybe | 12:38 |
| Garagoth | Anyone with fast-import experience? http://paste.ubuntu.com/323273/ | 12:46 |
| bialix | Garagoth: are you using the latest version of fast-impor from trunk? | 12:49 |
| Garagoth | revision-id: ian.clatworthy@canonical.com-20091106080627-0n409tg6rrj2hhb0 | 12:50 |
| Garagoth | date: 2009-11-06 18:06:27 +1000 | 12:50 |
| Garagoth | build-date: 2009-11-20 13:50:32 +0100 | 12:50 |
| Garagoth | revno: 260 | 12:50 |
| Garagoth | branch-nick: bzr-fastimport | 12:50 |
| bialix | I don't know what is build-date | 12:51 |
| bialix | anyway this is most likely bug in the plugin | 12:51 |
| Garagoth | Looks like date when i branched this repository | 12:51 |
| bialix | fast-import author is igc, he said goodnight half hour ago | 12:52 |
| bialix | you may want to file a bug | 12:52 |
| bialix | or try to use more recent/older revision | 12:52 |
| bialix | sorry, can't say more | 12:52 |
| Garagoth | Mm. Thanks. | 12:53 |
| Garagoth | plugin version is 0.9.0dev | 12:55 |
| bialix | 0.9.0dev means unreleased-yet version | 12:56 |
| bialix | it can has bugs inside | 12:56 |
| bialix | your traceback is cleanly bug | 12:56 |
| bialix | revno 260 -- is the latest version in trunk | 12:57 |
| bialix | Garagoth: you really need to file a bug report | 12:57 |
| Garagoth | Ok, I will. | 12:59 |
| === verterok_ is now known as verterok | ||
| jam | morning bialix, what's your question? | 14:17 |
| bialix | hi jam | 14:17 |
| bialix | jam: https://code.launchpad.net/~jameinel/qbzr/bug_430232_early_qapp_trunk | 14:17 |
| bialix | this branch seems is not needed anymore? | 14:18 |
| bialix | we have your fix in the trunk, I'm not sure what the purpose of this branch | 14:18 |
| bialix | if it really no needed, can you mark it as merged or abandoned? | 14:18 |
| bialix | jam ^ | 14:19 |
| jam | bialix: Sure, though I would have thought the fix would have been merged from there | 14:19 |
| jam | anyway, I can mark it merged | 14:19 |
| bialix | jam: it strange but trunk has different your revision with slightly different commit message | 14:19 |
| jam | I might have done it 2 times or something | 14:19 |
| bialix | and with the same revno | 14:19 |
| jam | no big deal | 14:19 |
| bialix | thanks jam! | 14:19 |
| jam | or maybe did an uncommit? | 14:20 |
| jam | anyway | 14:20 |
| jam | done | 14:20 |
| bialix | thanks | 14:20 |
| bialix | jam: and while I've got a bit of your attention, can I point on Bug 485771? | 14:20 |
| ubottu | Launchpad bug 485771 in bzr "[win32][2.1.0b3] windows command-line parser replace \ with /" [Undecided,Confirmed] https://launchpad.net/bugs/485771 | 14:20 |
| bialix | I can imagine why it works as it works now, but I have reasons to think it's not right | 14:21 |
| jam | bialix: so... I think there is a "has_glob" function in 'glob', that you can use to tell if we need to try and expand a command line param | 14:23 |
| jam | however note that if you do "bzr commit -m "foo\bar" it will 'just work' | 14:23 |
| jam | also note that with the proposed patch, "bzr commit -m foo\bar" is going to warn/prompt you... | 14:24 |
| jam | anyway, I forget the specific function, but certainly we could only try to expand things that have ? or * in them. | 14:24 |
| bialix | hmmm | 14:24 |
| bialix | I think I want to write a patch to disable glob with env variable | 14:24 |
| bialix | jam: BZR_GLOB=0 will be OK for you? | 14:25 |
| jam | so caveat the discussion about it breaking scripts, etc | 14:25 |
| jam | it seems ok | 14:26 |
| jam | I might put "BZR_WIN32_GLOB=0" | 14:26 |
| jam | or... BZR_WIN32_NOGLOB=1 | 14:26 |
| bialix | so many choices | 14:26 |
| bialix | flkip a coin? | 14:26 |
| jam | anyway, I'll let you work out the details | 14:26 |
| jam | yeah | 14:26 |
| bialix | BZR_WIN32_NOGLOB and any non-empty value | 14:26 |
| bialix | that sounds sane for me | 14:27 |
| bialix | something like there is done for NO_PROXY? | 14:27 |
| bialix | thx for suggestion, I'll try to make a patch this weekend | 14:27 |
| bialix | jam: is there planned b4? | 14:28 |
| jam | bialix: yeah, I'm pretty sure, and certainly at least an rc1 | 14:28 |
| jam | so rc1 => 2.1.0 final won't have many changes, but current => rc1 can | 14:28 |
| bialix | I just need to have some gap to make sure NOGLOB patch will be landed for 2.1 | 14:28 |
| jam | basically at rc1 it goes 'stable' | 14:29 |
| jam | you've got ~2 months | 14:29 |
| bialix | more than enough :-) | 14:29 |
| jam | bialix: I think not globbing when there isn't a glob character is also a worthwhile fix, on-top of a _NOGLOB variable. | 14:48 |
| bialix | on-top? | 14:49 |
| jam | bialix: do both, not just noglob | 14:50 |
| bialix | ah, understand | 14:50 |
| jam | noglob is useful, but it is a big hammer that people have to think about to turn on | 14:51 |
| jam | rather than have things "just work" most of the time | 14:51 |
| bialix | jam: ok, I understand, but noglob is simpler to write right now, do what I mean needs some thinking | 14:52 |
| bialix | jam: another your branch @ qbzr: https://code.launchpad.net/~jameinel/qbzr/progress | 14:52 |
| bialix | do you recall what is it off hands? | 14:52 |
| jam | bialix: I think qannotate just showed "loading" and that patch adds a progress bar | 14:57 |
| jam | so that you could see how close it was to done | 14:58 |
| jam | the progress bar was commented out in the code | 14:58 |
| jam | I just uncommented it, etc. | 14:58 |
| jam | I don't know where that widget is used, etc. | 14:59 |
| jam | I haven't focused on it in a while | 14:59 |
| jam | but it was nicer at the time | 14:59 |
| bialix | jam: ok thanks, I'll try to get a closer look on your changes, a bit later | 15:00 |
| Garagoth | Hmm. I'm trying to fast-export an svn repository (to import it to Bazaar later), but exporting fails with: Can't create a character converter from 'UTF-8' to native encoding | 15:02 |
| bialix | Garagoth: svn-import does not work for you? | 15:03 |
| Garagoth | Not tried that yet. | 15:04 |
| Garagoth | Is it part of bzr-svn ? | 15:05 |
| bialix | yep, it's from bzr-svn | 15:05 |
| Garagoth | Ok.. let me build that... | 15:05 |
| konnertz | hi, i do a bzr st in my child branch and get | 15:16 |
| konnertz | pending merges: | 15:16 |
| konnertz | Peter Smith 2009-11-11 More stuff for ... | 15:17 |
| konnertz | This info is available only in my parent branch , right? | 15:17 |
| konnertz | so why is it shown to me? | 15:18 |
| Lo-lan-do | You merged it but didn't commit it? | 15:18 |
| konnertz | i should add, Peter is somebody else with his own branch and he is the main person reviewing the changes i bzr send to the main repo | 15:20 |
| konnertz | so imo either he has merged all his changes to central repo or not | 15:21 |
| konnertz | and if not, i dont need to see them!? | 15:21 |
| Garagoth | bialix: bzr svn-import seems to work. | 15:23 |
| Garagoth | Thanks. | 15:23 |
| konnertz | is it understandable what i mean? | 15:25 |
| konnertz | I cant do anything to clear the status | 15:25 |
| Garagoth | bialix: I spoke too early... 'bzr: ERROR: Must end write group before releasing write lock on CHKInventoryRepository('file:///warlock/Bazaar/mudlib/mudlib/.bzr/repository/') | 15:28 |
| bialix | Garagoth: something weird with your bzr | 15:28 |
| bialix | Garagoth: what version of bzr you are using? | 15:29 |
| Garagoth | 2.0.2 | 15:29 |
| Tak | when I do `bzr annotate` , I get a lot of revisions like "41.2.30" - is there any way to go from that to a "normal" revspec? (i.e. the ones shown in `bzr log`) | 15:29 |
| bialix | Garagoth: and bzr-svn? 1.0.1? | 15:31 |
| Garagoth | yes. | 15:31 |
| Lo-lan-do | Tak: 41.2.30 is a normal revspec | 15:32 |
| Lo-lan-do | Tak: It's just a revision that was committed as part of a merge | 15:32 |
| bialix | Garagoth: something weird, but I have no idea what exactly. | 15:32 |
| Lo-lan-do | Tak: You can see it if you "bzr log -n 2" | 15:32 |
| Tak | hmm | 15:32 |
| Garagoth | bialix: http://paste.ubuntu.com/323424/ | 15:35 |
| Garagoth | trace from that error, from .bzr.log | 15:35 |
| bialix | Garagoth: it lloks like bzr-svn incorrectly working with bzr internals | 15:36 |
| bialix | Garagoth: it seems it's not your day today :-/ | 15:36 |
| Garagoth | bialix: Should I post a bug report about this? | 15:36 |
| bialix | yes, pleasd | 15:36 |
| bialix | yes, please | 15:36 |
| Garagoth | that would be third today... first day of bzr, and... | 15:36 |
| bialix | Garagoth: don't give up! | 15:37 |
| bialix | Garagoth: does there is something non-stadard in your system? filesystem? | 15:37 |
| Garagoth | Ha. I have 219 svn revisions to import, each of about 80MB when targzipped... | 15:37 |
| bialix | *non-standard | 15:38 |
| Garagoth | filesystem is ext3 | 15:38 |
| Garagoth | on raid5 | 15:38 |
| Garagoth | and lvm on top of it | 15:38 |
| bialix | Garagoth: does you svn repo have many branches? | 15:38 |
| Garagoth | not a single one. | 15:38 |
| bialix | can you try then just simple: bzr branch URL/to/svn | 15:38 |
| bialix | what is lvm? | 15:39 |
| Garagoth | logical volume manager | 15:39 |
| smagoun | Is there a way to revert/uncommit a specific revision? Say my current tree is at r100, I want to revert r98. The catch is that r98 includes binary files, so I can't just do 'bzr diff -r97..98 > foo.patch && patch -R < foo.patch' or so. | 15:39 |
| Garagoth | it is used to make 'partitions' on disks... | 15:40 |
| Garagoth | bialix: bzr branch started similarly as svn-import (it scanned all revisions), and now it hangs on copying revision 0 | 15:43 |
| Garagoth | and svn repo starts from revision 1 ... | 15:43 |
| bialix | Garagoth: my bad, use URL/to/svn/trunk | 15:43 |
| bialix | smagoun: bzr merge -rN..N-1 | 15:44 |
| Garagoth | ah, no, there is revision 0, sorry. It is empty. | 15:44 |
| smagoun | bialix: nifty, I'll try that. Thanks | 15:44 |
| Garagoth | bialix: You mean URL to working copy or what...? | 15:44 |
| bialix | Garagoth: no, I mean svn repo | 15:45 |
| bialix | using your traceback from paste it should be like this: file:///repository/svn/mudlib/trunk | 15:45 |
| Garagoth | bialix: There is no such thing. | 15:46 |
| bialix | Garagoth: file:///repository/svn/mudlib/ <-- is it correct URL to your svn repo you want to convert? | 15:46 |
| Garagoth | in repository/svn/mudlib I have: | 15:46 |
| Garagoth | conf dav db format hooks locks | 15:46 |
| bialix | Garagoth: that's ok | 15:46 |
| bialix | svn has inside virtual fs | 15:47 |
| smagoun | bialix: so that didn't work - it tried to merge from a remote branch which I had previously merged into r50 or so of my current branch). "Merging from remembered submit location bzr:ssh://bazaar.launchpad.net/blahblah" | 15:47 |
| jam | konnertz: doesn't "bzr revert" clear the status? | 15:47 |
| bialix | smagoun: use . as merge source | 15:47 |
| Tak | Lo-lan-do: cool, that helps - thanks! ( http://img265.imageshack.us/img265/5346/bzrannotatemerge.png ) | 15:47 |
| Garagoth | bialix: bzr: ERROR: Not a branch: "/repository/svn/mudlib/trunk". | 15:47 |
| smagoun | bialix: seems to have done the trick - thank you | 15:48 |
| smagoun | ! | 15:48 |
| bialix | Garagoth: I'm not very good in svn, but what URL you may use to run svn co ... ? | 15:48 |
| Garagoth | Hmm... I was using it by svnserve... and I belive it was just: mudlib | 15:49 |
| Garagoth | bialix: as svnserve was running from /repository/svn | 15:49 |
| Garagoth | bialix: Yup. URL I was using was: svn://127.0.0.1/mudlib | 15:50 |
| bialix | ok | 15:51 |
| bialix | so run: bzr branch svn://127.0.0.1/mudlib | 15:51 |
| Garagoth | Ahm. First I have to run svnserve. | 15:51 |
| Garagoth | argh. Just a moment, I will set it up... | 15:52 |
| Peng | What's the point of using svn://localhost? Why not just file://? | 15:52 |
| * Peng sees backlog. Oh. | 15:52 | |
| * bialix not very good in svn | 15:52 | |
| bialix | Peng: can you suggest something? I'm almost out of ideas how to help Garagoth | 15:53 |
| Garagoth | Peng: That is why I was trying with file://repository/svn/mudlib/ ... | 15:53 |
| Tak | does svn+file://... work? | 15:53 |
| Garagoth | Tak: in which command? | 15:54 |
| Tak | bzr branch | 15:55 |
| bialix | Garagoth: bzr branch svn+file | 15:55 |
| Garagoth | bzr: ERROR: Invalid url supplied to transport: "svn+file:/repository/svn/mudlib" | 15:56 |
| gdoubleu | I was trying to use svn+file yesterday when testing a checkout of a svn repo, but got the same error | 15:56 |
| gdoubleu | https://bugs.launchpad.net/bzr-svn/+bug/485496 | 15:56 |
| ubottu | Launchpad bug 485496 in bzr-svn "checkout using svn+file protocol fails with invalid url error" [Undecided,New] | 15:56 |
| Garagoth | but with file:/// | 15:56 |
| Garagoth | it started, but just hung at revision 0 | 15:56 |
| Garagoth | hang? | 15:57 |
| Peng | Garagoth: Hung? How long? Was it really hung or was it still working? | 15:57 |
| Peng | Garagoth: Is this a small repo or not? | 15:58 |
| Garagoth | Peng: revision 0 is empty. Revision 1 has some data. It was copying revision 0 for 5 minutes or so, then I interrupted it. | 15:58 |
| Garagoth | svn-import went thru rev 0 in less then second, completed rev 1, 2, and failed on rev 3 | 15:59 |
| konnertz | jam, ok yes it does. But there is a change in parent branch, i fetch with bzr merge | 15:59 |
| konnertz | raising a criss-cross merge msg | 16:00 |
| jam | konnertz: if you "bzr merge" you have to "bzr commit" that before it is recorded locally | 16:00 |
| konnertz | i resolve the conflict manually | 16:00 |
| konnertz | and the bzr st shows me the pending merge | 16:00 |
| jam | criss-cross warning isn't harmfull, though doing "bzr merge --weave" will likely result in fewer conflicts in that situation | 16:00 |
| jam | konnertz: you haven't committed the merge yet | 16:00 |
| jam | so it will continue to tell you about it until you do | 16:00 |
| konnertz | i see , moment | 16:01 |
| konnertz | ok, bzr st is clear and bzr merge nothing to do, | 16:02 |
| Lo-lan-do | jam: I was under the impression that --lca was more recommended than --weave, did I miss something? | 16:02 |
| jam | Lo-lan-do: --weave was badly broken ~ 1 year ago, I've fixed it | 16:02 |
| konnertz | now there's a bla.xy~1~ file | 16:02 |
| jam | *I* prefer --weave to --lca | 16:02 |
| jam | abentley probably would say the opposite | 16:02 |
| Lo-lan-do | Heh | 16:03 |
| jam | they have slightly different characteristics | 16:03 |
| Lo-lan-do | Okay, I'll remember to try it next time I get criss-cross conflicts. | 16:03 |
| jam | edge case handling, etc | 16:03 |
| konnertz | ok same content as current file, i deleted | 16:03 |
| abentley | Lo-lan-do: When two sides have resolved a merge differently, weave arbitrarily picks one side, lca conflicts. | 16:04 |
| konnertz | i see, i'll check the other merge alg. next time | 16:04 |
| Lo-lan-do | abentley: I see. | 16:05 |
| Lo-lan-do | abentley: Which side is picked, if you remember offhand? | 16:05 |
| abentley | Lo-lan-do: I don't remember which side is picked. jam is likely to. | 16:06 |
| jam | Lo-lan-do: things tend to depend on the order things were inserted into the weave. so merging a=>b may give a different result than b=>a. | 16:11 |
| jam | However, IIRC there are also differences when you have 'multi-layered' crisscross issues | 16:11 |
| jam | where weave takes into account more history than lca | 16:11 |
| jam | which only looks at the immediate lca ancestors | 16:11 |
| Lo-lan-do | That's way above my level of understanding of the innards of merges, but thanks anyway :-) | 16:12 |
| jam | Lo-lan-do: as a short point: http://paste.ubuntu.com/323450/ | 16:13 |
| jam | D supersedes both B & C, so if there is a conflict between D & E | 16:14 |
| jam | but the line in E clearly comes from B or C | 16:14 |
| jam | then D should win | 16:14 |
| jam | "clearly" I think is at least partially up for debate | 16:14 |
| Lo-lan-do | Sounds reasonable. | 16:14 |
| jam | --lca only looks at D & E, so it can't directly tell | 16:15 |
| jam | However, Aaron's comment is that if D picks B and E picks C | 16:15 |
| jam | then weave may not conflict | 16:15 |
| jam | and just "pick B" or something | 16:15 |
| jam | if you look at: http://revctrl.org/CrissCrossMerge#orderingambiguities%3Aordering | 16:16 |
| Lo-lan-do | Hmm. | 16:16 |
| jam | under "Simple Weave Merge" it describes one of the "accidentally clean" failures of weave merging | 16:17 |
| Garagoth | bialix, Peng: FYI, svn-import svn://127.0.0.1/mudlib failed with same error on revision 3 | 16:17 |
| jam | I'm not positive if "bzr merge --weave" suffers from this, but it probably does | 16:17 |
| bialix | Garagoth: jelmer is the author of bzr-svn and main wizard of it. | 16:18 |
| bialix | I'd ask him about your problem | 16:19 |
| Garagoth | bialix: And where can I find him...? | 16:19 |
| Peng | I want to push 2 (unstacked) copies of the same branch to LP. Any way to do it without having to upload everything twice? | 16:19 |
| bialix | Garagoth: usually he appears on this channel very often, but rightn now IIUC he's on UDS | 16:20 |
| Peng | Hmm. Does LP mind if I stack on something other than the development focus branch? | 16:20 |
| bialix | try to send mail to main bzr ML | 16:20 |
| Garagoth | bialix: I am im middle of reporting a bug in bzr-svn, shall I continue? | 16:21 |
| bialix | yes, he will receive that too | 16:21 |
| Garagoth | ok | 16:21 |
| bialix | Garagoth: jelmer just entered the building! magic! | 16:26 |
| bialix | hi jelmer, we waiting you :-) | 16:26 |
| Garagoth | Hmmm.... now svn-import (another try) hangs in revision 0... uses 96% of cpu, some io... | 16:26 |
| Garagoth | jelmer: Hi. Could you please have a look at: http://paste.ubuntu.com/323424/ | 16:27 |
| jelmer | bialix: uhm.. hi :-) | 16:27 |
| bialix | :-D | 16:27 |
| jelmer | Garagoth, is this using the latest version of bzr-svn? | 16:28 |
| Garagoth | 1.0.1 | 16:28 |
| jelmer | Garagoth, is the repository you're trying to import public? | 16:28 |
| Garagoth | No. | 16:29 |
| jelmer | Garagoth: The error you are seeing is masking the actual error | 16:29 |
| jelmer | Garagoth: in fetch.py:1290 please put "pass" rather than self.target.unlock() and try again | 16:29 |
| Peng | FYI: The answer is no, it does not mind. Probably; I haven't fully tested it. That makes sense, since the development focus branch can be changed, and IIRC old stacked branches will not be updated. | 16:30 |
| jelmer | jam: hi | 16:30 |
| jam | hey jelmer | 16:30 |
| jelmer | jam: Is there a particular reason why bzr only supports stacking on the source branch from the UI? | 16:31 |
| jelmer | jam: Preventing users from shooting themselves in the foot? | 16:31 |
| jam | no clearly defined way of specifying something else? | 16:32 |
| jam | not really sure | 16:32 |
| * Peng has steel boots on to prevent that. :) | 16:32 | |
| jam | jelmer: 'bzr push --stacked-on ..." allows you to specify a location | 16:32 |
| jam | I assume you could do something similar for 'bzr branch' | 16:32 |
| jam | however, I think the goal is to limit stacking a bit | 16:33 |
| jam | since the branch must always be available ,etc. | 16:33 |
| Garagoth | jelmer: Ok, will try in a moment... I lifted memory limits and executed it again, now it is thinking very hard on revision 3... | 16:34 |
| Garagoth | Hm, went to 4th rev | 16:34 |
| jelmer | jam: Thanks | 16:34 |
| Garagoth | jelmer: Maybe it run out of memory (had 512MB limit), not it allocated 930 MB and is still working. | 16:35 |
| Garagoth | jelmer: Is that possible? | 16:35 |
| jelmer | could be - how much data is in that repo? | 16:36 |
| Garagoth | jelmer: rev1 is 57MB, rev2 is 5MB, rev3 is 2MB | 16:37 |
| bialix | Garagoth: so what was non-standard in your system! memory limiter | 16:37 |
| bialix | I feel this | 16:37 |
| bialix | too much very strange errors here and there | 16:37 |
| bialix | Garagoth: maybe without hard limits you can manage fast-import to work too | 16:38 |
| Garagoth | bialix: Well, that is why I increased it to 1GB | 16:38 |
| Garagoth | But anyway, error is VERY misleading | 16:39 |
| jelmer | Garagoth, odd, it shouldn't be using that much memory in that case | 16:40 |
| bialix | because you have out of memory and error reporter failed to create right leading message :-) | 16:40 |
| Garagoth | jelmer: Well, stands still at 750MB virtual mem and 200MB res | 16:41 |
| Garagoth | maybe not that still. 762MB now. | 16:42 |
| jam | bialix: lp:///~jameinel/bzr/2.1.0b4-485771-win32-nostar-noglob | 16:42 |
| jam | once it finishes pushing | 16:42 |
| Garagoth | Hm, just finished with rev 4, started copying rev 5 | 16:43 |
| Garagoth | jelmer: Do you want that error from paste.ubuntu filed as a bug report? | 16:43 |
| bialix | jam: cool, thanks! | 16:44 |
| Peng | What makes a branch stacked? Presence of stacked_on_location in branch.conf? | 16:44 |
| Peng | Anything else? | 16:44 |
| jelmer | Garagoth, what was the actual error you got when you replaced that line? | 16:44 |
| Garagoth | jelmer: What do you mean: replaced that line? | 16:45 |
| jam | bialix: looking at the code, it was clearly wrong | 16:46 |
| jam | as it would replace all '\' with '/' even in quoted messages, etc. | 16:46 |
| bialix | ouch! | 16:46 |
| jam | https://code.edge.launchpad.net/~jameinel/bzr/2.1.0b4-485771-win32-nostar-noglob/+merge/15094 | 16:46 |
| Garagoth | jelmer: I pasted what I found in .bzr.log, on console I only got last message (BzrError: Must end write group before releasing write lock ...) | 16:47 |
| Peng | I think my stacking experiment failed. | 16:48 |
| jelmer | Garagoth: see my comment earlier | 16:48 |
| bialix | jam: bb:approve :-) | 16:48 |
| jelmer | <jelmer> Garagoth: The error you are seeing is masking the actual error | 16:48 |
| jelmer | Garagoth: in fetch.py:1290 please put "pass" rather than self.target.unlock() and try again | 16:48 |
| MvG | "pydoc -p", the python documentation http server, fails to serve documentation for e.g. bzrlib.branch. Is it just me, is pydoc broken, or is bzr doing something particularly fishy? | 16:49 |
| Garagoth | jelmer: Ahm. Just a sec, I will lower memory limit back to 512MB and try again. Can I simply edit file in /usr/lib/python... ? | 16:50 |
| Peng | Never mind. "bzr check" is just confusing: It gives the local repository URL even when checking revisions in the stacked-on repo. | 16:50 |
| Peng | fallback repo. Whatever. | 16:50 |
| jelmer | Garagoth: Yeah | 16:51 |
| bialix | MvG: I'd say bzrlib | 16:53 |
| MvG | OK, probably not worth fixing, so I'll stick to ascii pydoc. | 16:54 |
| Garagoth | jelmer: Ok. Thais might take a while, I'm waiting for current process to interrupt (it does not end immediately on Ctrl-C) and the run again, revs 1 and 2 take about 5 minutes to import... | 16:54 |
| Garagoth | jelmer: And it allocated 850 virt, 200 res at this moment... | 16:54 |
| Garagoth | jelmer: in MB | 16:54 |
| bialix | MvG: you may find useful http://starship.python.net/crew/mwh/bzrlibapi/ | 16:55 |
| bialix | MvG: IIRC there is problems with lazy_imports which used pretty heavily inside bzrlib | 16:56 |
| MvG | bialix: That link indeed looks useful, thanks! | 16:56 |
| bialix | :-) | 16:56 |
| * bialix hopes to look at new trac-bzr soon | 16:56 | |
| MvG | bialix: just trying to fix "view changeset by revis, without naming a branch" behaviour... | 16:57 |
| Garagoth | jelmer: Why it is spending so much time on copying revisio 0? It is empty... | 16:58 |
| bialix | MvG: I just need to get some free time to upgrade our trac install at work, my remark just "sigh" | 16:58 |
| MvG | As of an hour ago, I've got a working apache setup running on my local machine and serving both trac 0.10 and trac 0.11... And in CGI mode, which will make development faster than with the fcgi I used before, where I had to restart apache after every modification. | 16:59 |
| jelmer | Garagoth, it should be fairly quick processing rev0 | 17:00 |
| Garagoth | jelmer: strange. First try I ever made was fast. Each of next ones takes forever. | 17:01 |
| bialix | MvG: so I can try to hope that 0.10 will be supported more or less well? | 17:01 |
| bialix | cool | 17:02 |
| Garagoth | jelmer: And it allocated 478MB already | 17:02 |
| Garagoth | still at rev 0 | 17:02 |
| Garagoth | Aha! | 17:02 |
| Garagoth | jelmer: Failed with: MemoryError | 17:02 |
| jelmer | Garagoth: Still at rev0 ? | 17:03 |
| jelmer | Garagoth, There is something going very wrong there.... | 17:03 |
| MvG | bialix: YOu at least have a chance that all improvements I do that will work for 0.10 are incorporated into a 0.10 branch, and that I won't commit stuff to that branch that doesn't work for 0.10. At least in cases where "works" is easy to see. | 17:03 |
| Garagoth | jelmer: Ok, what can I show to you then? | 17:04 |
| bialix | MvG: cool, thank you! | 17:05 |
| Garagoth | jelmer: http://paste.ubuntu.com/323495/ | 17:06 |
| jelmer | Garagoth, that doesn't help much unfortunately | 17:06 |
| jelmer | Garagoth, what distro are you using? | 17:08 |
| Garagoth | Archlinix | 17:09 |
| Garagoth | Archlinux* | 17:09 |
| jelmer | Garagoth: does "bzr selftest bzrlib.plugins.svn" work? | 17:10 |
| Garagoth | jelmer: executing... | 17:11 |
| Garagoth | 240 tests done, 84MB allocated... | 17:12 |
| jelmer | vila: ping | 17:15 |
| Garagoth | jelmer: Ran 1288 tests in 200.115s, OK (known_failures=2), 46 tests skipped, tests passed. | 17:15 |
| CoffeeIV | I am moving a working directory (checked out) and the branch it was checked out from, to a new directory. Is the .bzr/branch/branch.conf the only file I have to edit to point the working directory to the new branch ? | 17:40 |
| maxb | I think so | 17:41 |
| CoffeeIV | ok . . . I made backups so I guess I will try it and find out | 17:43 |
| abentley | jam: I'm pretty sure weave merge does suffer from it. I'm pretty sure mysql wanted that. | 17:54 |
| jam | abentley: so the specific cases I debugged were cases where there was a double-criss-cross and the fallback had a clear resolution on one side | 18:00 |
| jam | but yes, that could also be true | 18:00 |
| abentley | jam: Oh, I thought that each side of the criss-cross kept resolving the conflicts in their favour, and they wanted a merge that would do that automatically. | 18:02 |
| echos | How do I remove a symbolic link from commit tree? | 19:03 |
| echos | I'm using bzr remove but it doesn't seem to be working at all | 19:07 |
| echos | I'm getting ERROR: * is not in the same branch as * | 19:07 |
| maxb | That's a really weird error | 19:31 |
| maxb | Oh | 19:32 |
| maxb | Are you removing part of the error and replacing it with * for IRC? | 19:32 |
| maxb | Please don't | 19:32 |
| === keithy_ is now known as keithy | ||
| === abentley1 is now known as abentley | ||
| jam | echos: rm symlink ; bzr rm | 20:20 |
| jam | 'bzr rm' should remove any file that was versioned but is no longer present | 20:20 |
| === sidnei_ is now known as sidnei | ||
| Saktoth | Hey folks. Any idea what this means? Im totally clueless: | 20:35 |
| Saktoth | C:\Program Files\2awr>bzr up | 20:35 |
| Saktoth | Unable to load plugin u'rebase'. It requested API version (2, 0, 0) of module <m | 20:35 |
| Saktoth | odule 'bzrlib' from 'C:\Program Files\Bazaar\lib\library.zip\bzrlib\__init__.pyo | 20:35 |
| Saktoth | '> but the minimum exported version is (2, 1, 0), and the maximum is (2, 1, 0) | 20:35 |
| Saktoth | bzr: ERROR: No WorkingTree exists for "file:///C:/Program%20Files/2awr/.bzr/chec | 20:35 |
| Saktoth | kout/". | 20:35 |
| lifeless | it means you need a newer bzr-rebase plugin. Its called bzr-rewrite now. | 20:38 |
| === keithy_ is now known as keithy | ||
| Saktoth | How do i get that? Get the test release? Latest stable? or do i need to download the plugin seperately? | 20:48 |
| joaopinto | hello | 21:32 |
| jml | hey | 21:54 |
| jml | we're writing useful Python code snippets into a gobby session | 21:54 |
| jml | at desktop-code-snip-party | 21:56 |
| === abentley1 is now known as abentley | ||
| === gioele_ is now known as gioele | ||
| === keithy_ is now known as keithy | ||
| === keithy_ is now known as keithy | ||
| ub3rst4r | hi, i was wondering what the difference between update and merge is, and why i have to do merge instead update when i go to work on the code | 23:49 |
| fullermd | Update updates your working tree to match its branch. Merge brings changes over from another branch. | 23:50 |
| ub3rst4r | k | 23:51 |
| ub3rst4r | so why do i need to use merge? | 23:51 |
| mwhudson | hm! | 23:51 |
| mwhudson | abentley: are you still here? | 23:51 |
| fullermd | I... don't know. That's like asking "why do I have to drive downtown?" If you have to go downtown, then you have to because you have to; if you don't, you don't... | 23:53 |
| ub3rst4r | i thought there was a way on launchpad to change how to manage the code when working with multiple accounts | 23:54 |
| mwhudson | if you have people doing development in parallel you're likely to have to merge at some point | 23:55 |
| mwhudson | unless you all use checkouts | 23:55 |
| ub3rst4r | i sort of dont understand it | 23:56 |
| ub3rst4r | do u need to run the merge command everytime u go to work on the code? | 23:56 |
| fullermd | Well, merge/update/etc don't really have anything to do with LP... 's all about what branches you have where. | 23:57 |
| mwhudson | ub3rst4r: i work in the 'feature branches' model | 23:57 |
| mwhudson | so all commits to trunk are merges | 23:57 |
| ub3rst4r | ? | 23:58 |
| mwhudson | ub3rst4r: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/organizing_your_workspace.html#feature-branches | 23:58 |
| mwhudson | ub3rst4r: reading this whole page may do you a lot of good, i'd guess | 23:58 |
| fullermd | You may want to look over http://bazaar-vcs.org/MatthewFuller/AboutPushPullMerge as well; it sounds like you're not really clear on which pieces you're putting where. | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
