| lifeless | mtaylor: it may simply be that that is the size of your tree | 00:00 |
|---|---|---|
| lifeless | mtaylor: how big is a drizzle tarball (gz) | 00:00 |
| mtaylor | lifeless: 7M | 00:01 |
| poolie | hi all | 00:01 |
| lifeless | mtaylor: so before its 178 and after its 164 | 00:02 |
| lifeless | mtaylor: did you perhaps start with all of mysql and *then* delete huge chunks ? | 00:02 |
| mtaylor | lifeless: yes. | 00:02 |
| lifeless | thats it then | 00:02 |
| mtaylor | (not history of course, but yet) | 00:02 |
| mtaylor | yes | 00:02 |
| lifeless | we can't compress changes to the deleted files, cause they aren't changing :) | 00:02 |
| mtaylor | ah, fair enough | 00:03 |
| mtaylor | was there ever a plan to do partial branches - like a full branch except perhaps going back only 100 revisions or so? | 00:03 |
| lifeless | kindof | 00:04 |
| lifeless | we have ~ 1/2 of it done - stacked branches | 00:05 |
| lifeless | the other half is disconnecting them and allowing user controlled connect/disconnect | 00:05 |
| mtaylor | so that I just just pull the stacked branch without pulling the stacked on branch? | 00:06 |
| lifeless | yes. handwaves furiously. | 00:06 |
| mtaylor | indeed | 00:06 |
| lifeless | how big was a mysql tarball (gz) | 00:06 |
| lifeless | mtaylor: ^ | 00:08 |
| chaosbit | Hi, is there a ticket management system recommended for bazaar? | 00:11 |
| lifeless | bzr can integrate with quite a few - we allow you to configure that. However we ship with built in configuration for launchpad | 00:12 |
| lifeless | and launchpad knows how to read the data back out of bzr pretty well | 00:12 |
| mtaylor | lifeless: 19M | 00:13 |
| lifeless | mtaylor: urggle. Ok we should investigate | 00:13 |
| lifeless | mtaylor: 1.18 will convert ok. don't convert with 2.0 or bzr.dev at this time. Brrrroken | 00:14 |
| lifeless | silently too sometimes. | 00:14 |
| mtaylor | lifeless: lovely | 00:14 |
| lifeless | yeah | 00:14 |
| lifeless | aliases variable | 00:15 |
| lifeless | alised | 00:15 |
| lifeless | bah. spellink iz broken. | 00:15 |
| lifeless | 'aliased' | 00:15 |
| === kiko is now known as kiko-afk | ||
| lifeless | spiv: ping | 00:23 |
| lifeless | beuno: what bzr did you use to upgrade lh ? | 00:25 |
| lifeless | beuno: if you used 2.0 or bzr.dev you should redo it with 1.18 | 00:26 |
| beuno | lifeless, 2.0rc1 :( | 00:26 |
| lifeless | bug 422849 | 00:27 |
| ubottu | Launchpad bug 422849 in bzr "InterDifferingSerializer generates InconsistentDelta error upgrading drizzle repo to 2a - adds a file already versioned" [Critical,In progress] https://launchpad.net/bugs/422849 | 00:27 |
| beuno | lifeless, and by redo, you mean...? | 00:27 |
| lifeless | back out, restore the backup, convert again. | 00:28 |
| lifeless | theres a high chance it wrote arbitrary data into your history | 00:28 |
| lifeless | and I don't have stats on what % of the time it will catch the error with the inconsistent delta warning. | 00:29 |
| beuno | ok, sill do it | 00:29 |
| beuno | thanks lifeless | 00:29 |
| beuno | dinner now, fix later | 00:30 |
| lifeless | beuno: if you converted over the network its ok | 00:31 |
| lifeless | beuno: its only if you converted locally that its fail | 00:31 |
| poolie | jelmer: hi, still here? | 00:31 |
| lvh | hi | 00:31 |
| poolie | emmajane: still here? | 00:31 |
| beuno | lifeless, ah, I did. | 00:31 |
| lifeless | more detail coming up on the list soon. | 00:32 |
| emmajane | poolie, barely :) | 00:32 |
| poolie | ok :) | 00:32 |
| poolie | don't need to hang around on my accoutn | 00:32 |
| poolie | if you didn't already do it (i haven't read all my mail) i'm going to forward some screenshots to the list | 00:32 |
| poolie | i'd like to continue the discussion there | 00:32 |
| emmajane | poolie, I'm making slides explaining square dancing as an analogy for PHP. you're welcome to distract me. :) | 00:33 |
| poolie | heh :) | 00:33 |
| emmajane | poolie, Oh. the screenshots went to the list this morning. there's been about 10 replies? | 00:33 |
| lvh | i dont understand the difference between bzr branch -r -5 . ../next; bzr pull . --overwrite -r -5 and bzr branch -r -5 . ../next; bzr uncommit -r -5 # could anyone please explain? | 00:33 |
| lvh | maybe it's just because i havent slept in 24 hours :-D | 00:34 |
| poolie | are those two alternative sequences? | 00:34 |
| lifeless | lvh: the uncommit leaves the tree changes in your current directory | 00:34 |
| emmajane | poolie, the two that I sent? one has the carousel and one is closer to the wireframe. | 00:34 |
| lvh | lifeless: Ah, whereas the former will properly pretend I never changed anything? | 00:35 |
| poolie | you'll discard your working tree changes as well as the revisions | 00:35 |
| lvh | as long as 'discard' means 'move into the new branch' thats what I want :-) | 00:36 |
| lvh | but im guessing thats what the bzr branch -r -5 does | 00:36 |
| lifeless | lvh: heres a better recipe | 00:37 |
| lifeless | bzr branch . ../next | 00:37 |
| lifeless | bzr pull . --overwrite -r -5 | 00:37 |
| lifeless | I have you a buggy recipe before | 00:37 |
| lvh | okay | 00:38 |
| lvh | thanks :-) | 00:38 |
| poolie | lifeless: i wonder if we should remove the downloads for 2.0rc1? | 00:39 |
| poolie | well done btw | 00:39 |
| lifeless | poolie: that would be a good precautio | 00:40 |
| lifeless | n | 00:40 |
| lifeless | master: Exporting thorough delta revision 93606/133780 with 140/822/110 added/changed/removed files | 00:50 |
| lifeless | still going... | 00:50 |
| emmajane | poolie, the wifi keeps dropping me and i'm going to call it a night. please do eemail if I've missed anything. | 00:57 |
| spiv | lifeless: pong | 01:00 |
| poolie | hello spiv | 01:06 |
| poolie | lifeless, tangentially https://bugs.edge.launchpad.net/launchpad-registry/+bug/422902 | 01:06 |
| ubottu | Launchpad bug 422902 in launchpad-registry "want a way to lock/embargo releases and downloads" [Undecided,New] | 01:06 |
| lifeless | spiv: hi; see the list, and my question about tests :) | 01:06 |
| thumper | rockstar: how to you create a new pipe and take the uncommitted changes? | 01:08 |
| * spiv looks | 01:08 | |
| spiv | oh, the question about tests is in scrollback, not on the list? | 01:12 |
| lifeless | yes | 01:12 |
| spiv | Something in per_interrepository I think. | 01:14 |
| spiv | I think .test_fetch.test_fetch_parent_inventories_at_stacking_boundary (and similarly test_fetch_parent_inventories_at_stacking_boundary_smart) | 01:15 |
| poolie | igc, +1 to you trying to improve the installer | 01:21 |
| jelmer | poolie: yep, somewhat | 01:21 |
| igc | poolie: I'll be off irc for a while, learning InnoSetup & reviewing how the current installer hangs together | 01:21 |
| poolie | it's probably redundant to tell you so but please document or script it so we can reproduce it | 01:21 |
| igc | poolie: call me re the content filtering stuff when you want | 01:21 |
| poolie | i think a big problem here is that this is complex and manual, and requires building up state on a particular machine | 01:21 |
| poolie | unless lifeless wants help with 2a bugs i'm going to do that today | 01:22 |
| poolie | ok i will | 01:22 |
| poolie | s/that/content filterign | 01:22 |
| poolie | spiv, ^^ that's what i had to say | 01:22 |
| poolie | how about you? | 01:22 |
| igc | poolie: there's 2 patches related to content filtering submitted yesterday for review so starting with those might be good | 01:22 |
| igc | poolie: sure, I'll write things up | 01:23 |
| igc | bbl | 01:23 |
| poolie | kk | 01:23 |
| poolie | igc there is a wiki page about it | 01:24 |
| poolie | and john said he sent mail to canonical-bazaar recently | 01:24 |
| lifeless | poolie: I have an errand to run in crows nest (my memory); leaving for that shortly. | 01:24 |
| poolie | k | 01:25 |
| poolie | we can do lunch if you want | 01:25 |
| poolie | igc, also, i'll leave it up to you where you want to experiment | 01:25 |
| poolie | but at some point we need all the dependencies on an ec2 machine | 01:25 |
| poolie | so, maybe it would save time to do it now... | 01:26 |
| poolie | otoh if you need to experiment it may be easier to do it locally | 01:26 |
| poolie | i'll send you the rdesktop command anyhow | 01:26 |
| igc | poolie: I just want to make it work locally first | 01:26 |
| igc | poolie: I saw the doc re ec2 | 01:26 |
| poolie | k | 01:27 |
| poolie | i have some changes locally | 01:27 |
| spiv | poolie: about to ask for reviews for the chk roots-only commit_write_group check; | 01:27 |
| poolie | as far as using just a single account etc | 01:27 |
| spiv | I'm then going to unshelve the changes I have for testing for all relevant chk keys and work on that, the prototype appears to function. | 01:28 |
| poolie | lifeless: is there anything i should do on 2a? | 01:28 |
| poolie | i guess primarily, do you think all those failures have the same cause? | 01:29 |
| lifeless | poolie: try my patch | 01:29 |
| lifeless | poolie: see if it addresses the error you had] | 01:29 |
| poolie | good idea :) | 01:29 |
| mtaylor | lifeless: wow. I _really_ love silent mode in automake 1.11 | 01:31 |
| lifeless | mtaylor: :) | 01:31 |
| lifeless | poolie: checking it is on my todo but its easy to parallise on | 01:31 |
| lifeless | https://code.edge.launchpad.net/~lifeless/bzr/bug-422849/+merge/11023 | 01:31 |
| poolie | sure, that's just the kind of thing i was looking for | 01:31 |
| rockstar | thumper, I shelve the changes, add-pipe, and then unshelve. | 01:46 |
| thumper | rockstar: ok | 02:08 |
| thumper | anyone know why we get UnexpectedStderr: Unexpected standard error from subprocess: warnings.warn("%r was gc'd while locked" % self.repr) ?? | 02:26 |
| thumper | I think the UnexpectedStderr may be ours (LPs) but I'm not sure | 02:27 |
| poolie | hi | 02:39 |
| poolie | thumper: i've never heard of UnexpectedStderr | 02:39 |
| poolie | but the warning is ours | 02:39 |
| poolie | um | 02:39 |
| poolie | i thought we got rid of them | 02:39 |
| thumper | poolie: the UnexpectedStderr are probably our checking of the bzr process for pulling | 02:39 |
| poolie | if it's your code calling into bzrlib you're probably missing a try/finally: thing.unlock() | 02:39 |
| mwhudson | thumper: generally those warnings are associated with other branches that failed to pull | 02:40 |
| thumper | poolie: we aren't getting it all the time, just a few times | 02:40 |
| poolie | mm | 02:41 |
| mwhudson | for a while, all loom branches did that, but i think that's fixed | 02:41 |
| poolie | so i'd speculate that either in the puller code or bzr | 02:41 |
| poolie | something is unlocked normally but not after an exception | 02:41 |
| lifeless | poolie: did it fix your issue | 02:47 |
| lifeless | ? | 02:47 |
| lifeless | <gone/> | 02:48 |
| poolie | lifeless: that seems to have fixed it | 02:55 |
| spm | poolie: recognising this is a bit of a "how long is a piece of string?", are we expecting to try again on the bzr upgrade to 2a today? Is cool either way, just wanting to get an idea on timing etc. | 02:55 |
| poolie | spiv, what do you think of http://sourcefrog.net/tmp/20090901-341535-eintr.diff | 02:55 |
| poolie | spm, if lifeless's patch, which i'm testing now, lands | 02:55 |
| poolie | and it's the top priority | 02:55 |
| poolie | that should unblock us redoing the upgrade | 02:55 |
| spm | excellent! | 02:55 |
| poolie | to find the next bug :) | 02:56 |
| poolie | or not | 02:56 |
| spm | ha | 02:56 |
| spiv | poolie: wow, that seems a bit extreme somehow. But it's probably correct. | 03:02 |
| spiv | Assuming it does actually work when you test it manually :) | 03:02 |
| poolie | it does | 03:02 |
| poolie | see https://bugs.edge.launchpad.net/bzr/+bug/341535 | 03:02 |
| ubottu | Launchpad bug 341535 in bzr "hpss SmartMedium doesn't handle eintr" [Medium,In progress] | 03:02 |
| poolie | where i also say i'm on the verge of making a decorator object that wraps these methods | 03:03 |
| poolie | do you know of one? | 03:03 |
| poolie | that would also make it more testable, though | 03:03 |
| poolie | :/ it's one of those things where unit testing it does not give great assurance that it actually works | 03:03 |
| poolie | spiv, what do you think? | 03:05 |
| poolie | if i make a class i just need to make sure it's used everywhere | 03:05 |
| poolie | i guess it can be stuck into the constructors fairly easily | 03:06 |
| ricardo_br | hi people! I'm using version 1.6.1, is there any command that I can see the files that changed between the revisons x..y? | 03:08 |
| spiv | Hmm, I'm torn. | 03:08 |
| spiv | Decorating the socket/pipe/etc object is probably cleaner, but on the other hand your patch is nice and straightforward. | 03:09 |
| bob2 | ricardo_br: bzr diff -r x..y | diffstat? | 03:10 |
| poolie | or 'bzr status -r x..y' | 03:10 |
| bob2 | oh, neat | 03:10 |
| poolie | spiv, if i thought there would be more cases then i'd do the object | 03:10 |
| poolie | ricardo_br: you might like to upgrade though, that's a bit old now | 03:10 |
| poolie | is that the package in a distro? | 03:10 |
| spiv | If the underlying objects weren't private to the SmartMedium classes, that would be a pretty strong case for decorating. | 03:10 |
| spiv | poolie: right. | 03:11 |
| poolie | it's true it's more than 3 cases, strictly speaking | 03:11 |
| poolie | maybe i'll propose just this for now | 03:11 |
| spiv | poolie: So, I'm happy with the patch as is. If you feel like writing the decorator I'm happy to look at that page too :) | 03:11 |
| spiv | But it's not a big deal to postpone that refactoring indefinitely. | 03:11 |
| ricardo_br | poolie: I think I've installed it through ubuntu apt-get install | 03:13 |
| ricardo_br | I've changed one file in the rev 61 and another file in the rev 62, when I run "bzr diff -r61..62" I can see only the changes in the file in rev 62 | 03:16 |
| poolie | ricardo_br: you'll need -r61..63 then | 03:17 |
| poolie | sorry | 03:17 |
| poolie | -r 60..62 | 03:17 |
| poolie | the previous one is "the changes from 61 to 62" | 03:17 |
| poolie | spiv, <https://code.edge.launchpad.net/~mbp/bzr/341535-eintr/+merge/11029> but it's not urgent | 03:19 |
| ricardo_br | poolie: thanks! it worked. Just another question, can I see only the file names? | 03:20 |
| === cprov is now known as cprov-zzz | ||
| poolie | rather than what happened to them? | 03:23 |
| poolie | um | 03:23 |
| poolie | not super easily, but you could use a shell script | 03:23 |
| poolie | btw newer versions for ubuntu are in https://launchpad.net/~bzr/+archive | 03:23 |
| poolie | spm btw the patch i referred to above is https://code.edge.launchpad.net/~lifeless/bzr/bug-422849/+merge/11023 and bug 422849 | 03:25 |
| ubottu | Launchpad bug 422849 in bzr "Incorrect conversions in 2.0rc1 and bzr.dev" [Critical,In progress] https://launchpad.net/bugs/422849 | 03:25 |
| ricardo_br | thanks for the tips poolie and bob2, I'll checkout the new versions | 03:26 |
| poolie | just fyi; we'll ping you when we get closer | 03:26 |
| spm | poolie: did you mean me? or andrew? I assume the latter. | 03:26 |
| poolie | no, you | 03:26 |
| poolie | that's the one that's blocking the upgrade | 03:26 |
| poolie | you don't need to do anything with it | 03:26 |
| poolie | just in case you were wondering | 03:26 |
| spm | ah, right. wit hthe plot now. | 03:27 |
| johnf1 | What is the mailing list and bundle-buggy still the best for patches or merge request in launchpad? | 04:14 |
| === johnf1 is now known as johnf | ||
| jam | johnf: best is merge request | 04:57 |
| johnf | jam: and a separate branch per feature/bug fix? | 04:58 |
| jam | johnf: generally | 04:58 |
| jml | hey | 04:59 |
| jam | hey jml | 05:00 |
| jml | if I wanted to do a patch _right now_ to stop Bazaar from treating directory removal as a conflict when the directory contains pyc files, how should I go about it? | 05:00 |
| jam | anyway, off to bed for me | 05:00 |
| jml | jam: g'night | 05:00 |
| AfC1 | jml: doesn't .bzringore *.pyc mean that that problem goes away? | 05:14 |
| AfC1 | bah | 05:14 |
| === AfC1 is now known as AfC | ||
| jml | hmm. does it? | 05:15 |
| * jml tries science | 05:15 | |
| mwhudson | AfC: no | 05:15 |
| mwhudson | it's the old "junk vs deliberately unversioned" chestnut | 05:15 |
| AfC | jml: I think fondly of science. Especially mixing the chemicals together and making them go phoof! | 05:17 |
| jml | but it's irritating me enough to do something about it. | 05:17 |
| jml | there, I just empirically verified that mwhudson is right. | 05:18 |
| jml | AfC, well, in these enlightened times chemicals are entitled to do whatever they want in the privacy of their own home. | 05:19 |
| === thumper is now known as thumper-afk | ||
| jml | ok, so git really is quite fast. | 06:15 |
| johnf | is there a way to create a branch of bzr inside launchpad without having to branch to my laptop and then push? | 06:25 |
| spiv | Well, you could do "bzr branch lp:bzr lp:~johnf/bzr/foo", but that still goes via your laptop... | 06:27 |
| spiv | If you already have bzr on your laptop, it shouldn't be very expensive to do that push, though, because the branch will be stacked on lp:bzr. | 06:28 |
| johnf | spiv as in 200MB traffic needs to go both ways or does everything happen on the server end? | 06:28 |
| johnf | ahh it's the stacking that I don't have | 06:29 |
| spiv | (and even in the lp:bzr -> lp:~johnf/bzr/foo it should still stack, although I can imagine it would fall a fair way short of being full efficient as that case hasn't been tested much) | 06:29 |
| spiv | You don't? Stacking should be automatic when you push to Launchpad, unless your local copy of bzr is in an old format? | 06:29 |
| johnf | yeah just realised my bzr.dev wasn't off launchad | 06:30 |
| johnf | fixing that now | 06:30 |
| johnf | so if I branch from lp. then branch again on disk and then push to lp will everything remain stacked? | 06:31 |
| vila | hi all | 07:04 |
| spm | hey vila | 07:09 |
| poolie | hi spm, vila | 07:22 |
| poolie | spm, it looks like that patch will work but other stuff came up and we're not likely to attempt the upgrade today | 07:23 |
| poolie | we'll probably merge it and may try it tomorrow | 07:23 |
| spm | fair enough, shame in a way :-/ | 07:23 |
| poolie | jml, still around? | 07:23 |
| jml | poolie, yep | 07:23 |
| poolie | quick call? | 07:24 |
| jml | poolie, sure. | 07:25 |
| jml | skype or pots is fine by me | 07:25 |
| poolie | let's see if skype will play | 07:25 |
| lifeless | bug 422849 is in pqm for 2.0 | 08:13 |
| ubottu | Launchpad bug 422849 in bzr "Incorrect conversions in 2.0rc1 and bzr.dev" [Critical,In progress] https://launchpad.net/bugs/422849 | 08:13 |
| vila | lifeless: trivial enough to land without review ? I ask because I read the related mails first thing this morning (before hitting enter on 'bzr upgrade', pfew, lucky me) and couldn't find the merge proposal... | 08:20 |
| vila | and didn't notice the linked branch until now :-/ | 08:22 |
| vila | lifeless: right, so the patch is indeed trivial and was in the bug comments, good | 08:23 |
| vila | lifeless: yet.... fixing a critical bug without adding test[s]... :-/ | 08:25 |
| lifeless | vila: it was reviewed :) | 08:25 |
| vila | ok | 08:25 |
| lifeless | vila: I want tests; I'm not done on the bug. If you felt like writing some test during your day that would rock; otherwise I hope to get something that triggers it cleanly etc tomorrow. | 08:26 |
| vila | Ha great | 08:26 |
| lifeless | vila: missing tests shouldn't prevent us fixing a problem! | 08:26 |
| vila | sure | 08:26 |
| vila | obviously I missed some discussion, no worries, just catching up | 08:27 |
| vila | happy to see we agree on all fronts :) | 08:27 |
| vila | and above all thanks for fixing it since, well, I *was* about to upgrade locally :) | 08:27 |
| lifeless | my pleasure :) | 08:28 |
| vila | that close: '' | 08:28 |
| lifeless | poolie: spm: I think we should wait for bzr.dev nightlies to have this fix before executing on 2a for bzr.dev | 08:28 |
| lifeless | Doing otherwise will make it harder for people to be sure they can upgrade cleanly themselves. | 08:28 |
| lifeless | vila: your test spike looked interesting | 08:30 |
| vila | lifeless, spm: exactly why I asked to keep notes about what version was used to upgrade. (And I don't pretend my crystal ball warned me, it was just,,, well, prophylactic acting) | 08:31 |
| lifeless | vila: I look forward to seeing it in action. | 08:31 |
| vila | shell-like you mean > | 08:31 |
| vila | shell-like you mean ? | 08:31 |
| lifeless | vila: I'm hoping that it will be able to be totally simulated in memory :) | 08:31 |
| lifeless | yes | 08:31 |
| vila | Many threads are converging in the right direction I think, I like jam ideas about MemoryTree and branch builder, I really think we should upgrade them | 08:32 |
| lifeless | so do I | 08:32 |
| lifeless | I think we should build our testing safety net safety net first | 08:32 |
| vila | I mean, add the missing features to MemoryTree and branch builder so they can be used more broadly | 08:32 |
| lifeless | I see the most important things being some additional glue and reporting | 08:33 |
| lifeless | so we can answer questions like 'how important is this test', or 'these tests' | 08:33 |
| lifeless | 'if I delete this test, what coverage do I remove' | 08:33 |
| vila | oh yes... | 08:33 |
| lifeless | and 'what tests add no coverage today? | 08:33 |
| lifeless | ' | 08:33 |
| vila | an important milestone to reach is to know that all code is covered (even if only once), I have no idea where we are today | 08:34 |
| lifeless | now, we'll need to think about the answers to those questions, but I think you'll agree that they are very interesting questions | 08:34 |
| vila | ooooh yes | 08:34 |
| lifeless | andrew wrote a coverage plugin | 08:35 |
| lifeless | and there are some coverage analysis tools in the python testing community | 08:35 |
| lifeless | At the risk of sidetracking you :) | 08:35 |
| vila | we have a --coverage option, I need to use it more :) | 08:35 |
| vila | well, not only me :) | 08:36 |
| lifeless | --coverage is the plugin | 08:36 |
| lifeless | I think | 08:36 |
| vila | nah, bzr help global-options | 08:37 |
| vila | available in every good bzr :) | 08:37 |
| lifeless | ah no | 08:37 |
| lifeless | needs to be per test | 08:37 |
| lifeless | or you can't answer those questions | 08:38 |
| lifeless | figleaf sections can do it | 08:38 |
| lifeless | or per test decorators | 08:38 |
| lifeless | with only a moderate failure mode for tests of lsprof | 08:38 |
| vila | so, to run test in isolation I use selftest-by-n.py: http://paste.ubuntu.com/263626/ | 08:43 |
| vila | ./bzr selftest --list >all-tests | 08:43 |
| vila | selftest-by-n.py --starting-with --in-tmp --number 1 all-tests | 08:43 |
| vila | I didn't play with it for months but ran it again last time we discussed about that, I need to analyse a bit more, but I already have some leaks identified (the meacs-bzr-send.xxx.el in /tmp for one) | 08:44 |
| vila | s/meacs/emacs/ | 08:45 |
| vila | and the bzr-limbo ones ! | 08:45 |
| lifeless | pastebin.com/f600ce040 | 08:45 |
| lifeless | thats much/most of my sketch | 08:46 |
| lifeless | enjoy | 08:46 |
| vila | :-D | 08:46 |
| lifeless | It needs: | 08:46 |
| spiv | Yeah, the existing --coverage is pretty basic. | 08:46 |
| lifeless | better data mode | 08:46 |
| lifeless | and thats about it | 08:47 |
| spiv | per-test collection/reporting would be neat. | 08:47 |
| lifeless | the better model I think would be best to try next is: | 08:47 |
| vila | lifeless, spiv: My gut feeling is that trying to de-tangle coverage data is... NP-complete, I'd rather generate coverage data for each test in isolation and work hard to avoid redoing it uselessly | 08:49 |
| lifeless | file_line:file_line_id file_line_id:testid_id testid_id | 08:49 |
| lifeless | vila: I agree; thats what my plugin does | 08:49 |
| vila | oh | 08:50 |
| vila | but then you don't need to go down to lines, you can just keep 'test -> modules+' | 08:51 |
| lifeless | spiv: --lsprof-tests gives you stome per test stuff today; no consistent reporting | 08:55 |
| vila | stome ? | 08:57 |
| lifeless | some | 08:58 |
| vila | ha. | 08:58 |
| NEBAP|work | can someone point em to technical information about the default file format that is used by bazaar? I just want to create a little reader application .. | 09:01 |
| NEBAP|work | s/em/me | 09:01 |
| poolie | look at the developer notes in doc.bazaar-vcs.org | 09:01 |
| poolie | vila, i might sign off soon | 09:04 |
| lifeless | vila: per line gives you per function when combined with diff | 09:04 |
| poolie | is there anything you want to talk about? | 09:04 |
| lifeless | vila: which gives you 'run the tests for this change' | 09:04 |
| vila | lifeless: If it works, great ! My fear is that it's trickier to get right than just: run these tests because one of their associated module has changed | 09:05 |
| vila | poolie: nothing in particular, I think I've got enough feedback on shell-like tests to make a more concrete proposal (without putting too much features yet anyway, mostly doc, look at doctest matching and some polish) | 09:06 |
| vila | Overall, the intent is to have something that you can copu/paste your shell session, lightly edit it and a get a runnable test | 09:07 |
| lifeless | vila: the function matching code is done and working | 09:07 |
| vila | s/copu/copy/ | 09:07 |
| lifeless | vila: its just an efficient index that is needed | 09:08 |
| vila | lifeless: That's how I understood it | 09:08 |
| vila | lifeless: err wrong context :) | 09:08 |
| vila | I thought you were talking about doctests :) | 09:08 |
| lifeless | nooo | 09:08 |
| lifeless | 31K revisions of netbeans to go | 09:09 |
| poolie | vila, cool, i was happy to see that posted | 09:09 |
| igc | poolie: vila: well done on your progress on the 'shell test' stuff | 09:09 |
| vila | poolie: I thought so :-) The trigger was when you said: 'could be used for merge resolution tests' to which I nearly replied 'Will you stop reading my mind ! ' | 09:10 |
| igc | vila: I'm yet to look at it but it's very much along the lines of what I've been dreaming of | 09:10 |
| vila | igc: not for you ! You're testing at far too high levels already :-P | 09:11 |
| igc | vila: I'm sure when it's ready it will help casual contributors write more tests more easily | 09:11 |
| poolie | igc, something nontechnical came up today so i didn't do anything on filtering :-( | 09:12 |
| poolie | sorry | 09:12 |
| poolie | maybe tomorrow | 09:12 |
| igc | vila: :-) | 09:12 |
| igc | poolie: np | 09:12 |
| * igc dinner | 09:12 | |
| poolie | good idea | 09:12 |
| vila | igc: yup, casual contributors is definitely the target | 09:12 |
| NEBAP|work | only thing I found is http://doc.bazaar-vcs.org/latest/developers/packrepo.html which didn´t help enough .. | 09:13 |
| NEBAP|work | are there no more detailed docs about the file system? | 09:15 |
| NEBAP|work | or is there already a php script that is able to read bazaar branches? | 09:16 |
| lifeless | NEBAP|work: I believe folk have written php code to call out to bzr | 09:22 |
| lifeless | NEBAP|work: I wouldn't recommend reimplementing the disk format: there is a chunk of code and logic there, its neither small nor simple | 09:23 |
| NEBAP|work | lifeless: yeah | 09:23 |
| NEBAP|work | lifeless: I just want to enable my page to read the format to easily implement some "open source" code viewing .. | 09:24 |
| NEBAP|work | and I didn´t find any implementations in php | 09:25 |
| lifeless | bug fix -> bzr.dev | 09:34 |
| vila | lifeless: you may want to review the patch I'm preparing about the leaks to see why you didn't catch these ones (that's for tomorrow) | 09:34 |
| lifeless | vila: I haven't written code to catch os calls yet | 09:36 |
| vila | lifeless: at least I *think* you didn't catch them, but since your related patch hasn't landed yet( | 09:36 |
| lifeless | vila: like subprocess :P | 09:36 |
| lifeless | vila: I haven't had time to progress that spike for a few days | 09:36 |
| lifeless | vila: feel free! | 09:36 |
| vila | :-) | 09:36 |
| vila | not sure the ones I'm catching are in the scope, so far that's tmp files created explicitly but not cleaned up | 09:37 |
| lifeless | seriously though, I think the next step is more protection and or coverage | 09:37 |
| lifeless | after that run-changed-code | 09:37 |
| lifeless | then back to isolation | 09:37 |
| lifeless | vila: my plan there is: hook into file() and open() and unlink() | 09:38 |
| lifeless | + rename | 09:38 |
| lifeless | a create file attempt outside TEST_ROOT and /tmp is an error | 09:38 |
| lifeless | ditto read | 09:38 |
| lifeless | a create file / dir in /tmp that isn't later cleaned up is an error | 09:38 |
| vila | TMPDIR not /tmp, just in case :) | 09:39 |
| lifeless | clean up can be mv into TEST_ROOT | 09:39 |
| lifeless | or mv and delete within TMPDIR | 09:39 |
| vila | "isn't later cleaned up" is the tricky one since you can't trap it early, you can only whine at tearDown time | 09:40 |
| vila | lifeless: but that should work and be quite pleasant, I wonder if I should leave these leaks to server as easy preys... | 09:41 |
| vila | s/server/serve/ | 09:41 |
| vila | well, they are there already, they can be fixed but not merged where they are needed. | 09:42 |
| NEBAP|work | there is no php script that is able to read a bazaar branch, the only thing I found is one that executes some shell calls to bazaar, which won´t work on most servers .. | 09:53 |
| NEBAP|work | but I found out that some other guys also are searching for a php script to read their branches ^^ | 09:56 |
| NEBAP|work | so | 09:57 |
| lifeless | NEBAP|work: I would estimate 3-4 weeks solid work to reliably read the data format, including race conditions etc. | 09:58 |
| NEBAP|work | ^^ | 09:58 |
| lifeless | NEBAP|work: If you are up for that, well great. | 09:58 |
| NEBAP|work | hmm | 09:58 |
| NEBAP|work | otherwise maybe no one will start | 09:59 |
| lifeless | Start a project; study the bzr code, and when the code is ambiguous, we can provide more insight. | 09:59 |
| NEBAP|work | ok | 09:59 |
| lifeless | But! I think its much better off using e.g. bzr's xmlrpc server | 09:59 |
| lifeless | or shelling out | 09:59 |
| lifeless | than reimplementing. | 09:59 |
| NEBAP|work | hmm | 09:59 |
| NEBAP|work | the problem is that most php server doesn´t allow system calls | 09:59 |
| NEBAP|work | s/server/servers | 10:00 |
| NEBAP|work | so | 10:00 |
| lifeless | NEBAP|work: you'll need C to read the file content anyway | 10:00 |
| NEBAP|work | really? | 10:00 |
| NEBAP|work | why? | 10:00 |
| lifeless | compression logic is slow in high level languages | 10:00 |
| lifeless | and bzr data is very very tightly compressed | 10:00 |
| NEBAP|work | hmm | 10:00 |
| NEBAP|work | that might be a problem | 10:00 |
| NEBAP|work | for me it will only work if I just use php | 10:01 |
| NEBAP|work | so | 10:02 |
| lifeless | can you just export the files you want from bzr | 10:02 |
| lifeless | e.g. using bzr uplaod | 10:02 |
| NEBAP|work | there is no detailed documentation of the file format? | 10:02 |
| NEBAP|work | yes | 10:02 |
| NEBAP|work | thought of that | 10:02 |
| NEBAP|work | but uploading some php files (sources) will end up with problems maybe | 10:03 |
| NEBAP|work | and it would be really cool to push a new rev and be able to read the branch using php | 10:03 |
| lifeless | there are detailed docs of various layers, many of which are part of the source | 10:03 |
| lifeless | e.g. pydoc bzrlib.bzrdir | 10:03 |
| lifeless | will tell you about the bootstrap files | 10:03 |
| lifeless | there isn't an 'implementors guide' | 10:04 |
| NEBAP|work | k | 10:04 |
| NEBAP|work | so | 10:04 |
| lifeless | you *will* have to read through and understand the code in bzrdir, repository, repofmt/*{or the formats you want to understand}, branch, versionedfiles, tree, revisiontree | 10:04 |
| NEBAP|work | I´ll start by checking the bazaar sources | 10:04 |
| lifeless | inventory | 10:04 |
| lifeless | and maybe more | 10:04 |
| NEBAP|work | thanks | 10:05 |
| NEBAP|work | that will give me a starting point :) | 10:05 |
| lifeless | good luck | 10:05 |
| NEBAP|work | thank you :) | 10:05 |
| jelmer | james_w: hi! | 10:13 |
| james_w | hey jelmer | 10:13 |
| james_w | how's it going? | 10:13 |
| vila | hey james_w jelmer :) | 10:13 |
| vila | jelmer: welcome back ! | 10:13 |
| james_w | hey vila | 10:13 |
| jelmer | Hi Vincent! | 10:14 |
| jelmer | james_w: I saw you committed bzr 1.18 in the bzr branch - did you find somebody to sponsor for Debian yet? | 10:15 |
| james_w | I didn't | 10:15 |
| jelmer | james_w: Ok, I'll have a look at uploading then | 10:15 |
| james_w | I need to fix bzrtools | 10:16 |
| james_w | and you may want to confirm what I did with bzr-svn | 10:16 |
| vila | jelmer: I built packages for bzr-gtk but I didn't know how you proceed for debian, keep me in the loop when/if you need to update the related branches | 10:16 |
| james_w | there's bzr-gtk and loggerhead as well, but I don't think they are version locked | 10:16 |
| * jelmer nods | 10:17 | |
| vila | james_w: bzr-gtk is version "locked" on the bzrlib API, so it's ok for bzr-2.0 | 10:17 |
| vila | since the API didn't change | 10:17 |
| === cprov-zzz is now known as cprov | ||
| NEBAP|work | lifeless: which is the default format? knitrepo or pack_repo? | 10:19 |
| vila | NEBAP|work: groupcompress_repo | 10:20 |
| vila | NEBAP|work: at least it will as soon as 2.0 is out | 10:20 |
| NEBAP|work | ah ok | 10:21 |
| jelmer | what's the plan for 2.0 exactly? Just those two blocker bugs? | 10:21 |
| NEBAP|work | how long will that take? I´ve seen there is much traffic in the 2.0 branch ^^ | 10:21 |
| vila | AIUI 2.0rc2 should be a couple of days away | 10:22 |
| NEBAP|work | cool | 10:22 |
| vila | lifeless: fix landed in 4.666, that was really an evil bug :-D | 10:24 |
| === thumper-afk is now known as thumper | ||
| lifeless | yes | 10:28 |
| lifeless | aliasing | 10:28 |
| lifeless | it would be nice if python had a 'final' facility. | 10:29 |
| lifeless | like C/C++ const | java final | most any functional language | 10:29 |
| bob2 | or a pyflakes check | 10:29 |
| lifeless | bob2: can't catch all the evil I can do | 10:30 |
| bob2 | nothing can | 10:30 |
| lifeless | bob2: but yes it could help | 10:30 |
| lifeless | SA isn't a common python idiom though | 10:31 |
| lifeless | so it would need to be brought in gradually. | 10:31 |
| lifeless | james_w: ping | 11:33 |
| james_w | hi lifeless | 11:33 |
| lifeless | did you see my WARNING mail to bazaar@ | 11:33 |
| lifeless | if not, go read it :P | 11:33 |
| lifeless | I'd like to ensure that the bzr nightly builds have that patch in them, asap. | 11:34 |
| lifeless | IIRC you coordinate those? | 11:34 |
| james_w | yeah | 11:34 |
| james_w | when was the bug introduced? | 11:34 |
| lifeless | 24th or so, IIRC | 11:34 |
| james_w | and the easiest way to do that is to get it in to trunk | 11:34 |
| lifeless | the patch is in trunk | 11:34 |
| james_w | the nightlies aren't affected then | 11:34 |
| james_w | then the nightlies pick it up | 11:35 |
| james_w | or is that "run them now please"? | 11:35 |
| lifeless | james_w: you haven't been building for a week? | 11:35 |
| lifeless | james_w: its 'run them now please, and shepard them through' | 11:35 |
| james_w | no | 11:35 |
| james_w | ok | 11:35 |
| lifeless | I'm sure they would build normally anyhow | 11:35 |
| lifeless | just want personal assurance that it succeeds, as this is a blocker for doing the bzr upgrade to 2a | 11:36 |
| james_w | sure | 11:36 |
| lifeless | thanks hugely | 11:36 |
| lifeless | if there is a problem, can you mail poolie and I | 11:37 |
| james_w | they are not fully automated yet | 11:37 |
| james_w | sure | 11:37 |
| lifeless | and I'll fix my tomorrow am, hopefully in time to catch you or [can anyone fix things if it breaks] ? | 11:37 |
| james_w | I don't want to automate them on my end without making the tools to do so available to everyone | 11:37 |
| james_w | anyone can upload to the nightly ppa that is a memeber of the team | 11:38 |
| james_w | I forget who that is now | 11:38 |
| james_w | you, John, Martin | 11:38 |
| lifeless | ok cool | 11:38 |
| lifeless | anyhow, it passed PQM | 11:38 |
| james_w | they are running now fwiw | 11:39 |
| lifeless | I'm sure there will be no difficulty | 11:39 |
| lifeless | thanks! | 11:39 |
| lifeless | I'm past EOD myself, so I'm now going to forget about this until after-sleep | 11:39 |
| james_w | sure | 11:39 |
| james_w | go sleep | 11:39 |
| james_w | jelmer: bzrtools fixed on bzr.debian.org so available when you want to upload 1.18 | 11:43 |
| james_w | hmm, not in bzr.dev yet | 11:54 |
| james_w | ah, not on LP yet | 11:54 |
| CameronP_ | Hi there i was wondering if I could get some advice on repository layouts.. | 12:23 |
| lifeless | jelmer: so you use doap? | 12:34 |
| jelmer | james_w: thanks! | 12:37 |
| jelmer | lifeless: yeah, occasionally | 12:37 |
| jelmer | lifeless: I try to keep my doap files up to date, but I don't always use doap yet where I want to. | 12:37 |
| lifeless | jelmer: you might like to reply to my doap-interest post | 12:38 |
| jelmer | mainly because the tools are incomplete | 12:38 |
| jelmer | lifeless: I'll have a look | 12:38 |
| lifeless | without dependencies its hard to write useful tools beyond toys IMO | 12:38 |
| lifeless | its relationships make foaf useful | 12:38 |
| jelmer | lifeless: it depends on what you want to use it for I guess | 12:40 |
| jelmer | if you want to use DOAP to help with packaging, I agree dependencies are a need | 12:40 |
| lifeless | jelmer: relationships let you build a package spiderer | 12:41 |
| lifeless | without that its just another way to write a readme and news file :) | 12:41 |
| jelmer | lifeless: true, though a parseable one | 12:48 |
| CameronP_ | Do you guys help out newbs to baazar? | 13:05 |
| spiv | CameronP_: yes, although sometimes the channel is just quiet. | 13:08 |
| spiv | CameronP_: a more specific question might attract more answers | 13:08 |
| CameronP_ | Yeah sorry after that I just worked it out myself! | 13:14 |
| CameronP_ | I was just having issues creating shared repositories | 13:14 |
| spiv | CameronP_: Heh, ok :) | 13:19 |
| CameronP_ | spiv, If I want to get the latest version of a branch, but dont want any history (eg for publishing to web server) is the bets way via the --lightcheckout ? | 13:47 |
| CameronP_ | --lightweight i mean | 13:47 |
| lifeless | CameronP_: to publish to a webserver, use bzr upload | 13:50 |
| lifeless | its a plugin | 13:50 |
| lifeless | and designed for web publishing | 13:50 |
| awilkins | Does that just do a "straight" upload each time or does it rsync or do incremental updates? | 13:51 |
| CameronP_ | oh ic... | 13:53 |
| CameronP_ | spiv: Thanks I'll take a look | 13:53 |
| spiv | awilkins: incremental, I believe. | 14:00 |
| spiv | awilkins: see http://bazaar.launchpad.net/~bzr-upload-devs/bzr-upload/trunk/annotate/head%3A/README | 14:02 |
| garyvdm | Hi - I'm haveing to push some branches (in 2a format) via a slow ftp connection. It keeps on repacking the remote repo. This is realy irritating. Is there any way to disable this, and what would the effects of that be? | 14:16 |
| spiv | jam: around? I want to check which email address is good for you atm, as the usual one seems to be bouncing. | 14:17 |
| CameronP_ | spiv: What is meant by JUst the working tree for upload | 14:17 |
| CameronP_ | eg say I've create a shared repostiory repository | 14:17 |
| CameronP_ | and then ive created a project called xyz | 14:17 |
| CameronP_ | and i only want to "upload" via the plugin just the project xyz | 14:18 |
| spiv | garyvdm: if do a manual pack, it'll fully pack the whole repo which will have the side effect of delaying large autopacks for quite a while. | 14:18 |
| spiv | garyvdm: there's no option for disabling autopacks entirely that I know of | 14:18 |
| spiv | garyvdm: the effects however would be a steady slowdown in read speed when accessing the repo, especially over a network. | 14:19 |
| garyvdm | spiv: I don't really understand what pack does, but maybe the autopack policy needs to be different for dumb remote to local, and smart remote. | 14:20 |
| spiv | CameronP_: if you want to just upload the files, no history, to a webserver, then the bzr-upload plugin is probably the best tool. | 14:20 |
| spiv | CameronP_: whether or not you have a shared repo doesn't affect that. | 14:21 |
| CameronP_ | yeah im confused i think | 14:21 |
| CameronP_ | the problem is that the central repo is the same server the website is on | 14:21 |
| CameronP_ | so my understanding isnt fitting if you know what i mean | 14:22 |
| CameronP_ | I havent worked out how to install it yet :( | 14:22 |
| spiv | garyvdm: it combines many small pack files into a single pack file, which is already beneficial in itself... for 2a there's the added benefit that having more content in one file gives better compression. | 14:22 |
| spiv | garyvdm: autopacking generally triggers ~10 writes to a repository (a single push would count as one write in this context, assuming there was something to push, as would a single commit). | 14:23 |
| spiv | garyvdm: crudely, autopacking means that by the time you've committed hundreds or thousands of times you'll still only have a few (say <20, and often <10) pack files, rather than hundreds or thousands. | 14:25 |
| spiv | So it's small, regular doses of pain now to avoid worse pain later :) | 14:25 |
| garyvdm | spiv: I see. I'm going to take a look code to see if I can hack it to make it repack less often for dumb remote transports. | 14:26 |
| luks | well, 1000 => 10000 is not very regular | 14:26 |
| spiv | CameronP_: Well, you could "bzr upload" to a local directory just as easily as to a network local. | 14:26 |
| spiv | garyvdm: that won't really help | 14:26 |
| spiv | garyvdm: in that when it finally does trigger, it'll just be much much worse. | 14:26 |
| spiv | Because it'll have more to do. | 14:26 |
| garyvdm | spiv: I push to these branch often, and then work on them on the machine that I'm pushing to locally. It can repack when I'm on that machine... | 14:27 |
| garyvdm | CameronP_: Have you come right with installing bzr-upload. Maybe I can help you. | 14:28 |
| spiv | CameronP_: you can probably install that plugin simply by doing "bzr branch lp:bzr-upload ~/.bazaar/plugins/upload", although you may need to make the ~/.bazaar/plugins dir first. | 14:28 |
| CameronP_ | yeah what i did was go into usr/lib/python2.4/site-packages/bzrlib/plugins/ | 14:29 |
| CameronP_ | and did a bzr branch https://launchpad.net/bzr-upload | 14:29 |
| CameronP_ | which made an upload dir in the plugins dir | 14:30 |
| spiv | CameronP_: you may need to make sure its 'upload', not 'bzr-upload' in that plugins dir. | 14:30 |
| CameronP_ | spiv: thanks that fixed it | 14:31 |
| CameronP_ | well it got the command working | 14:32 |
| CameronP_ | so now, this is where i get confused | 14:32 |
| CameronP_ | im sitting in my public_html dir where i want to download to | 14:33 |
| CameronP_ | and issuing the command bzr upload /home/xyz/repository/courses | 14:33 |
| spiv | I think you have the usage backwards :) | 14:33 |
| CameronP_ | Yep | 14:33 |
| CameronP_ | i think your right... | 14:33 |
| CameronP_ | heh | 14:33 |
| CameronP_ | so how does it know where to download the files to? | 14:34 |
| spiv | Judging from the README, you want to be in /home/xyz/repository/courses and do "bzr upload ..../public_html" | 14:34 |
| CameronP_ | AHHHH | 14:34 |
| CameronP_ | noob mistake, thanks a lot | 14:34 |
| spiv | It would probably be harder to make that mistake if the target was a network location :) | 14:34 |
| spiv | As most systems don't let you "cd sftp://somehost/foo" ;) | 14:35 |
| CameronP_ | yay it worked ;) Thanks spiv | 14:35 |
| CameronP_ | now it has that cool option of auto updating... that will be great | 14:37 |
| garyvdm | CameronP_: bzr upload --auto :-) | 14:38 |
| moldy | hi | 14:52 |
| CameronP_ | ah dang :( | 14:55 |
| CameronP_ | now upload has caused an error | 14:55 |
| CameronP_ | i found a patchfor it, but it should have already been fixed in that version i downloaded yeah? | 14:55 |
| CameronP_ | https://bugs.launchpad.net/bzr-upload/+bug/312686 | 14:55 |
| ubottu | Launchpad bug 312686 in bzr-upload "Error "you cannot specify None for the display encoding" on commit" [Undecided,New] | 14:55 |
| CameronP_ | he has a diff file, there is, that the same as a patch file? | 14:57 |
| CameronP_ | so can i use like patch -p0 < xyz.diff | 14:57 |
| === SamB_XP_ is now known as SamB_XP | ||
| moldy | what's the recommendation for migrating an svn repo that uses svn:externals? | 15:04 |
| jelmer | moldy: there isn't a really good solution | 15:07 |
| jelmer | moldy: nested trees will provide similar functionality | 15:07 |
| jelmer | until then you can work around the missing functionality by using config-manager of scmproj | 15:08 |
| CameronP_ | Well I patched it, but now getting another error, basically it looks like its returning text back to tortoisebzr | 15:08 |
| CameronP_ | so tortoisebzr is throwing an error | 15:08 |
| moldy | jelmer: well, basically i just want the data and the history, the externals can become normal directories | 15:09 |
| jelmer | moldy: in that case, you can just convert the containing tree to bzr | 15:10 |
| jelmer | and then use "bzr join" to import the external branches | 15:10 |
| moldy | jelmer: i'm trying :) struggling with bzr-svn right now | 15:10 |
| moldy | jelmer: which tool do you recommend? | 15:10 |
| jelmer | moldy: To import from svn ? bzr-svn | 15:11 |
| jelmer | moldy: Should work just the way you would use bzr itself | 15:11 |
| moldy | from bzrlib.plugins.svn import format | 15:13 |
| moldy | ImportError: cannot import name format | 15:13 |
| moldy | hmmmm | 15:13 |
| jelmer | moldy: what version of bzr-svn are you using? | 15:15 |
| moldy | jelmer: 0.6.4 | 15:15 |
| moldy | jelmer: with bzr 1.15.1 | 15:15 |
| bebraw | how can i revert a branch to the state of the trunk? | 15:19 |
| jelmer | moldy: hmm, that's odd | 15:20 |
| moldy | 0.6.1 seems to work better, now i just need to install subvertpy | 15:20 |
| jelmer | moldy: 0.6.4 also needs subvertpy | 15:20 |
| jelmer | that could explain the other error | 15:21 |
| moldy | jelmer: hm, maybe | 15:21 |
| moldy | i don't think so, though | 15:21 |
| moldy | my bzrtools seems to be lacking something that 0.6.4 requries | 15:21 |
| jelmer | bzr-svn doesn't depend on bzrtools | 15:21 |
| jelmer | in any way or form | 15:21 |
| moldy | wait, let me check again | 15:22 |
| moldy | ah right, i mean bzrlib | 15:22 |
| moldy | from bzrlib.plugins.svn import format | 15:22 |
| moldy | my bzrlib.plugins has no "svn" module | 15:22 |
| jelmer | that's a red herring, there's something else that's failing | 15:23 |
| jelmer | such as subvertpy not being loadable, that's causing the svn plugin to be unloadable and thus be "msising" | 15:23 |
| moldy | it isn't there, i looked at it | 15:23 |
| moldy | find /usr/lib/python2.6/site-packages/bzrlib/ -name "*svn*" --> nothing | 15:24 |
| jelmer | moldy: that's not the only location searched | 15:25 |
| jelmer | moldy: ~/.bazaar/plugins is included as well, for example | 15:25 |
| moldy | huh? how does it pull that trick | 15:26 |
| moldy | bzrlib.plugins.__file__ is __init__.py in the above directory, and it doesn't import anything | 15:26 |
| bebraw | nm. bzr branch to rescue :) | 15:27 |
| moldy | 0.6.1 works when subvertpy is installed, 0.6.4 shows the same error as before | 15:28 |
| CameronP_ | does anyone know how i can get hte upload plugin to "forget" a directory in uploaded to , its saved location is wrong | 15:29 |
| vila | CameronP_: --remember | 15:34 |
| CameronP_ | thanks vila, yeah auto unfortuantely breaks it :( what a shame | 15:35 |
| CameronP_ | tortoise bzr that is | 15:35 |
| vila | ? | 15:36 |
| CameronP_ | when you have --auto on, and then you do a comit remotely, it fails as it returns stoutput back to tortise about it doing an auto update | 15:36 |
| CameronP_ | so then it all gets broken | 15:36 |
| vila | CameronP_: file a bug, I don't use tbzr myself and I'm not sure I understand what you're describing, but it sounds like something that needs to be fixed | 15:39 |
| CameronP_ | Yeah, there is a bug open, and a guy posted a patch but it doesnt quite fix it | 15:40 |
| CameronP_ | https://bugs.launchpad.net/bzr-upload/+bug/312686 | 15:40 |
| ubottu | Launchpad bug 312686 in bzr-upload "Error "you cannot specify None for the display encoding" on commit" [Undecided,New] | 15:40 |
| phinze | hey #bzr, trying to write a small plugin this morning... two questions: is there a nice searchable API somewhere for bzrlib or does everyone just use the HTML version | 15:43 |
| SamB_XP | phinze: well, ideally the HTML version would *be* searchable ;-) | 15:44 |
| phinze | number two, i'm trying to see if a given path has changed given a ChangeBranchTipParams... can anyone point me in the right direction as to where to look in the API | 15:44 |
| moldy | jelmer: ok, thank you, bzr-svn seems to work fine now... now i just need to wrap my head around bzr join :) | 15:44 |
| SamB_XP | I actually tend to grep the bzr source a lot, personally ... | 15:44 |
| phinze | SamB_XP: true... just inquiring as to what the active folks use for their reference | 15:44 |
| phinze | SamB_XP: i'm not averse to that :) | 15:45 |
| SamB_XP | anyway, I was thinking maybe it wouldn't be that hard to rig some javascript up to search the docs? | 15:46 |
| phinze | unfortunately i'm still such a newb to the base API that sometimes the source is not the fastest way | 15:46 |
| === deryck_ is now known as deryck | ||
| phinze | SamB_XP: true... a la rubybrain or something similar | 15:46 |
| CameronP_ | does anyone know where bzr puts itself on install? | 15:53 |
| phinze | so anyways i'm making my way through Repository and such, and i think i need to first generate some sort of delta given new_revid and old_revid | 15:53 |
| awilkins | CameronP_: Which OS :-) | 15:53 |
| CameronP_ | centos (rhel) | 15:53 |
| awilkins | CameronP_: I think bzrlib goes in the relevant site-packages | 15:54 |
| awilkins | CameronP_: I have a centos box under my clutches but I installed it from sources | 15:54 |
| CameronP_ | same | 15:54 |
| CameronP_ | i wondered where it went once installed | 15:55 |
| awilkins | Do a | 15:55 |
| awilkins | cd / | 15:55 |
| awilkins | find -name bzrlib # :0 | 15:55 |
| vila | 'bzr version ' should tell you | 15:55 |
| CameronP_ | bzrlib | 15:55 |
| CameronP_ | ah ic im doing a locate on bzr | 15:55 |
| awilkins | "bzr" is a small script that calls into bzrlib | 15:55 |
| CameronP_ | yeah thats what im looking for | 15:55 |
| awilkins | It'll be inside your python stuff somewhere | 15:55 |
| CameronP_ | so i can run it from a script | 15:56 |
| CameronP_ | yeh...thanks | 15:56 |
| vila | CameronP_: 'which bzr' should tell you and then 'bzr version' will tell you all the details, also, try 'bzr plugins -v' to see what plugins are installed and where | 15:57 |
| phinze | ah get_revision_delta in Branch | 15:57 |
| phinze | there we go | 15:57 |
| === kiko-afk is now known as kiko | ||
| CameronP_ | thanks vila | 15:58 |
| phinze | hmm what's confusing me now is in the pre_change_branch_tip state, the new_revid does not exist in the branch i have reference to | 16:06 |
| LarstiQ | phinze: branch or repository? | 16:06 |
| phinze | which in a way makes sense, since it's *pre*, but i don't know how i can get a revision delta | 16:06 |
| phinze | ooo good call | 16:06 |
| phinze | doesn't exist in branch, might in repository? | 16:06 |
| LarstiQ | yeah | 16:07 |
| phinze | cool; will look in that direction, thx | 16:07 |
| phinze | beautiful, now we're cookin with gas ;) | 16:08 |
| moldy | jelmer: i succesfully converted the containing repository to bzr now. can you give me a hint on how to use bzr join to join the former svn externals? i get errors about missing working trees | 16:11 |
| jelmer | moldy: clone the external URLs at the places where they need to be in the tree | 16:12 |
| jelmer | and then run "bzr join <path>" | 16:12 |
| moldy | jelmer: thanks, trying that | 16:12 |
| moldy | jelmer: seems to work, nice. thank you (i also had to add a "bzr co" on the cloned path) | 16:14 |
| jelmer | moldy: if you had a treeless repo, that might indeed be necessary | 16:16 |
| moldy | seems to be the default for svn-import | 16:17 |
| jelmer | moldy: ah, yeah - that's correct | 16:23 |
| jelmer | moldy: newer versions will tell you though that you need to run "bzr co" | 16:23 |
| === beuno is now known as beuno-lunch | ||
| moldy | i see | 16:24 |
| jelmer | (the trees aren't automatically created since they can take up a lot of space if you have a lot of branches) | 16:26 |
| moldy | jelmer: can i safely delete those .bzr.retired.0 files that are created by the joins? | 16:26 |
| jelmer | moldy: yeah | 16:27 |
| moldy | ok, thanks for your help | 16:28 |
| tbradshaw_ | Hello there, as a quick question, are "push" and "pull" symmetric? Is it safe to use them interchangeably, or is there more to a push than there is a pull? | 16:59 |
| vila | tbradshaw_: they are symmetric | 17:03 |
| tbradshaw_ | ah, that's great. Thanks, vila. :) | 17:03 |
| vila | given that you switch your source and target branches when using them I mean | 17:03 |
| CameronP_ | gnight all.. | 17:05 |
| vila | tbradshaw_: the only edge cases where you can observe differences is regarding updating the working tree, but bzr does a good job of warning you when that occurs | 17:05 |
| vila | CameronP_: night | 17:05 |
| tbradshaw_ | heh, yup, I just ran into that | 17:05 |
| tbradshaw_ | and the documentation provide was solid | 17:05 |
| tbradshaw_ | s/provide/provided | 17:05 |
| vila | CameronP_: did you file a bug regarding tbzr/upload interactions ? | 17:05 |
| vila | .... | 17:06 |
| === tbradshaw_ is now known as tbradshaw | ||
| moldy | how do i give a branch that uses a shared repo its own repo? | 17:08 |
| tbradshaw | I ran into a bug in bzr 1.5 (the current version in debian stable) that prevents me from pulling | 17:08 |
| tbradshaw | and so I had hoped to "cheat" but using the other side to push instead, where I'm using a newer version | 17:09 |
| moldy | ah, got it | 17:12 |
| moldy | hmm, no :) | 17:13 |
| tbradshaw | I'm up against this bug: https://bugs.launchpad.net/bzr/+bug/307091 | 17:14 |
| ubottu | Launchpad bug 307091 in bzr "Too many concurrent requests (dup-of: 246233)" [Undecided,New] | 17:15 |
| ubottu | Launchpad bug 246233 in bzr "TooManyConcurrentRequests error when ssh connection fails (bzr crashes when pulling)" [High,Fix released] | 17:15 |
| tbradshaw | is there a workaround? Could I generate one of those merge files, scp over, that directive file | 17:15 |
| tbradshaw | and then do it that way | 17:15 |
| tbradshaw | also, I had no idea I was going to trigger that bot | 17:15 |
| fullermd | moldy: There's an option to 'reconfigure' to do that. | 17:15 |
| moldy | fullermd: i can also just branch from it, right? | 17:15 |
| fullermd | Well, if you branch in the repo, the new branch will be using the repo too... | 17:16 |
| moldy | fullermd: ok, but branching from outside will work? | 17:17 |
| fullermd | From doesn't matter; it's to that does. | 17:17 |
| moldy | ok, i see | 17:18 |
| fullermd | I get the feeling that at least one of us is confused over what you're trying to accomplish, though. | 17:18 |
| moldy | fullermd: the big picture is that i am converting an svn repo, then re-organizing it | 17:18 |
| fullermd | What would that clal for switching a branch to using an internal repo? | 17:19 |
| moldy | fullermd: i want the former svn branches to turn into standalone branches now | 17:20 |
| fullermd | 'k, but why? | 17:20 |
| moldy | i don't really have any special reasons | 17:21 |
| moldy | disk space is not an issue, and it seems easier, less to worry about | 17:21 |
| === beuno-lunch is now known as beuno | ||
| fullermd | It saves IO as well as disk space, since various actions no longer need to copy stuff around. | 17:23 |
| fullermd | About the only thing being standalone gains you in the general case is being able to mv it arbitrarily around the filesystem. | 17:24 |
| moldy | which is nice, for the moment | 17:24 |
| moldy | i am juggling with several svn/bzr repos/branches, it's easy to get confused at the moment :) i can always setup a shared repo later if i want to | 17:25 |
| jelmer | moldy: try bzr reconfigure --standalone in the branches | 17:27 |
| === deryck is now known as deryck[lunch] | ||
| moldy | jelmer: thanks | 17:33 |
| mthaddon | jelmer: not sure if you're aware, but there's a request from lifeless for us to upgrade PQM for bzr, but there's a new python-subunit dependency and we'd really like that in karmic before anything else (so we can backport to our repo) | 17:51 |
| mthaddon | jelmer: is that something you could help with? | 17:51 |
| jelmer | mthaddon: I can request a sync I guess, that way we'll end up with subunit in karmic | 17:52 |
| jelmer | That might require a freeze exception at this point though | 17:52 |
| jelmer | james_w: ping | 17:52 |
| james_w | hi jelmer | 17:53 |
| james_w | mthaddon: you need bzr68? | 17:56 |
| mthaddon | james_w: I'm not really sure what that means... :( | 17:57 |
| fullermd | bzr written in ALGOL 68? | 17:57 |
| james_w | mthaddon: you need a specific revision of python-subunit? | 17:58 |
| james_w | pqm depends on something in subunit revisions 67 or 68? | 17:58 |
| mthaddon | james_w: lifeless says in the RT that it depends on lp:~subunit/ubuntu/karmic/subunit/snapshots | 17:59 |
| jelmer | mthaddon: ah | 18:00 |
| jelmer | mthaddon: in that case you'd probably need a completely new package in Karmic since the one in Debian would be too old | 18:00 |
| mthaddon | jelmer: that's possible, yeah | 18:01 |
| james_w | jelmer: but debian is only one revision behind lp:subunit isn't it? | 18:01 |
| jelmer | james_w: no, 11 | 18:04 |
| jelmer | lp:subunit is at revision 79 | 18:04 |
| * james_w fails at subtraction | 18:04 | |
| jelmer | base 10 ? | 18:05 |
| james_w | mthaddon: but yeah, we can do it but it will require a freeze exception | 18:06 |
| mthaddon | james_w: cool, thx | 18:07 |
| james_w | mthaddon: you don't want to rely on me for this though | 18:08 |
| mthaddon | k | 18:09 |
| lamont | james_w: it's universe, no? | 18:14 |
| james_w | it is | 18:15 |
| lamont | lalalalalala what freeze? | 18:15 |
| lamont | :-) | 18:15 |
| james_w | heh | 18:15 |
| james_w | they are free with exceptions at this point in the cycle | 18:15 |
| james_w | just needs someone to explain why they want it and that they have done some testing | 18:16 |
| lamont | I mean, I can go make sure that -release doesn't care... I assume it has a relatively short build time? (like prolly minutes or less on i386/amd64)? | 18:16 |
| james_w | probably | 18:16 |
| lamont | 4 minutes on ia64 | 18:16 |
| lamont | so... you've tested it and you're happy with it? | 18:16 |
| james_w | I haven't looked at it | 18:17 |
| lamont | ah. well, I expect _someone_ of the gang has, since it's a dep of sutff they're using all the time,... | 18:18 |
| * lamont goes to prod the right people | 18:18 | |
| lamont | james_w: since lifeless is the one asking for it, I'm gonna assert that either it's good, or he's gonna fix it. if you'll package it, I'd be happy to give it a quick blessing and upload it, or you can... ok? | 18:21 |
| james_w | I can upload | 18:21 |
| james_w | he's packaged it | 18:22 |
| james_w | it looks like, at least | 18:22 |
| lamont | thanks. feel free to just do so. RM slangasek said he won't kill me for shoving it that way | 18:22 |
| james_w | I'm just busy with other things right now, so don't want to get pulled in to this | 18:22 |
| lamont | ah. so it's already packaged? | 18:22 |
| lamont | and if we just bzr branch from the snapshot, it should be shiny? | 18:22 |
| james_w | well, the branch referenced in the RT is package branch | 18:22 |
| lamont | \o/ | 18:23 |
| lamont | mthaddon: you wanna play with the packaging and then I'll upload it? | 18:23 |
| mthaddon | erm, will give it a go | 18:24 |
| phinze | hmm so i'm trying to iterate on all new revisions in a pre_change_branch_tip hook | 19:00 |
| phinze | i've got my logic down but then realized it was only running on the last revision being pushed | 19:00 |
| phinze | so i was trying to do something with range(params.old_revno + 1, params.new_revno) | 19:00 |
| phinze | but i can't figure out how to convert each revno into a revid ... i ask the branch and it says "nope i don't have that revno just yet" | 19:01 |
| phinze | need revids so i can get trees/deltas | 19:01 |
| phinze | from the repository | 19:01 |
| phinze | any help much appreciated... brb for a quick mtg :) | 19:02 |
| beuno | Peng_, I've *just* realized that your tshirt never got shipped | 19:17 |
| beuno | and, doing the process again, the world-wide shop doesn't let me ship to the US | 19:17 |
| beuno | and the US shop doesn't have LP tshirts | 19:17 |
| beuno | grrrrrrrrrrrrrrrrrrrrrrrrrr | 19:17 |
| phinze | so i'm still working on detecting whether a given path is changed in a pre_change_branch_tip | 19:55 |
| phinze | i'm trying to figure out whether what i need be figuring out is how to iterate over each revision in the branch change | 19:55 |
| phinze | or if i need to be figuring out how to get a delta that covers the entire span of the tip change | 19:56 |
| phinze | i've been learning a lot from the API docs, but it's taking me a lot longer at this juncture since i don't know which direction to look in | 19:57 |
| Milo- | hey, I have a project that has its versions controlled with bzr, I just did few uncommit operations, and I would like to lighten my repository slightly.. | 20:15 |
| Milo- | is there a way of removing those old packs? | 20:15 |
| Milo- | without breaking anything | 20:15 |
| Milo- | heh google was faster | 20:16 |
| Milo- | or not | 20:16 |
| phinze | Milo-: a little quiet in here today | 20:18 |
| phinze | check out https://bugs.launchpad.net/bzr/+bug/43753 | 20:18 |
| Milo- | yup it is | 20:18 |
| ubottu | Launchpad bug 43753 in bzr "uncommit option to remove revision data from repository" [Medium,Confirmed] | 20:18 |
| phinze | looks like there's still no support as yet built in, but there's aplugin linked there | 20:19 |
| Milo- | I see | 20:19 |
| Milo- | nice, a plugin without readme :) | 20:23 |
| phinze | i believe the correct term is "self documenting" ;D | 20:23 |
| Milo- | no idea how to use that ... | 20:24 |
| * phinze will pull it and take a quick look | 20:24 | |
| Milo- | it just has one __init__.py file | 20:24 |
| Milo- | and reading it gives me no hint at all. | 20:25 |
| phinze | ah, you just drop the directory into ~/.bazaar/plugins/PLUGIN_NAME/__init__.py file | 20:25 |
| phinze | so it looks like that path format ^^ | 20:25 |
| phinze | assuming you're on some sort of unix variant | 20:25 |
| phinze | if you put it in the correct place, bazaar automatically loads it | 20:26 |
| phinze | and you'll get "bzr remove_revision" looks like | 20:27 |
| phinze | http://bazaar-vcs.org/BzrPlugins <-- for more info on bzr plugins | 20:28 |
| LarstiQ | phinze, Milo-: plugins are usually installed by `bzr branch plugin/url ~/.bazaar/plugins/pluginname` | 20:31 |
| Milo- | yes I see | 20:31 |
| LarstiQ | where pluginname is a valid python identifier, ie, strip the leading 'bzr-' | 20:31 |
| phinze | wahey - there's even a convention ;) | 20:31 |
| Milo- | gah, it's bzr remove-revision :) not the way phinze said it :) | 20:31 |
| * phinze blushes, tries in vain to cover up large NEWB letters flashing above his head :) | 20:32 | |
| Milo- | I get error when I run that command | 20:33 |
| Milo- | well, can I just rm obsolete packs? | 20:36 |
| beuno | yes | 20:37 |
| beuno | I do all the time | 20:37 |
| twohey | I was wondering if someone here knew how to setup email notifications for pushes / commits to a master branch. | 20:49 |
| twohey | i'm pretty sure this is possible given https://lists.ubuntu.com/archives/bazaar-commits/ | 20:49 |
| twohey | but my googling failed to find documentation on how to fix this | 20:50 |
| jam | Milo-: don't delete the directory, but you can delete the *content* of obsolete_packs | 21:01 |
| lifeless | moimoin | 21:01 |
| Goosey | bzr 1.17, "bzr help commands' encounters internal error. Fresh install. Anything I should look at? | 21:02 |
| lifeless | Goosey: windows? | 21:03 |
| Goosey | lifeless, ah yes. Windows XP | 21:05 |
| Goosey | installed with the standalone installer | 21:05 |
| jam | Goosey: upgrade to 1.17.1 | 21:08 |
| jam | there was a bug in the packaged version of one of the plugins | 21:08 |
| jam | nothing serious | 21:08 |
| jam | just caused 'bzr help commands' to fail | 21:08 |
| jam | (and nothing else, IIRC0 | 21:08 |
| Goosey | jam, sure enough. thanks | 21:18 |
| lifeless | twohey: hi | 21:25 |
| lifeless | twohey: the stuff on bazaar-commits is just done by devs installing bzr-email | 21:25 |
| lifeless | twohey: if you're using bzr+ssh you can do the same on a server by installing and configuing bzr-email on the server | 21:26 |
| twohey | lifeless: thanks. | 21:27 |
| twohey | is there documentation for bzr-email? I can't seem to find anything on how to set it up | 21:28 |
| lifeless | its a plugin, so that part is generic | 21:28 |
| lifeless | then bzr help email | 21:28 |
| twohey | should have known, thanks | 21:28 |
| lifeless | jam: bug 402652 | 21:31 |
| ubottu | Launchpad bug 402652 in bzr "smart fetch for --2a does not opportunistically combine groups" [Critical,Fix committed] https://launchpad.net/bugs/402652 | 21:31 |
| jam | lifeless: do you have a question? | 21:33 |
| lifeless | jam: IIRC I reviewed it | 21:34 |
| lifeless | jam: was there more to do before landing? | 21:35 |
| jam | lifeless: is that the groupcompress sort order portion? | 21:35 |
| jam | That has landed in 2.0 and trunk | 21:35 |
| lifeless | ah. the robert is awake but confused event | 21:35 |
| lifeless | cool, I'm glad that that has landed | 21:35 |
| lifeless | ok, reviews for 2.0 done | 21:49 |
| lifeless | I thnk | 21:49 |
| lifeless | hi jam | 21:58 |
| jam | hey | 21:58 |
| lifeless | so, I've reviewed ians patch | 21:58 |
| lifeless | andrew is doing insert stream | 21:58 |
| lifeless | you and I were bouncing group combining around | 21:59 |
| lifeless | are you still looking at group combining, or should I pull your progress and continue? Alternatively I could do the tests for the conversion bug that I deferred | 21:59 |
| lifeless | or pick up the content filtering patch and work on that | 21:59 |
| jam | I'm still working on the group combining | 22:00 |
| jam | I think I have a decent heuristic | 22:00 |
| jam | I just need to | 22:00 |
| jam | 1) add tests and tie it into insert_record_stream | 22:00 |
| jam | 2) Check that we don't end up with issues with Remote streams | 22:00 |
| jam | since I think I determined that they will call insert_record_stream() 1/group | 22:00 |
| jam | which negates the benefit of what I'm doing | 22:00 |
| lifeless | I'll look at 2 for you now | 22:00 |
| jam | So either we need to persist a group between groups | 22:01 |
| jam | or combine the stream into a bigger stream | 22:01 |
| jam | I favor the latter | 22:01 |
| jam | um.... | 22:05 |
| lifeless | jam: I'll have it done in about 10 minutes I think | 22:05 |
| jam | lifeless: running "bzr selftest -s bt.test_repository.Test2a.test_autopack_unchanged_chk_nodes" is taking 5.3s for me | 22:05 |
| jam | but if I do "--lsprof-tests" it drops to 1.3s | 22:05 |
| lifeless | ! | 22:05 |
| jam | sorry, 1.8s | 22:05 |
| lifeless | wow | 22:05 |
| jam | yeah | 22:05 |
| lifeless | lsprof makes our code go faster. | 22:05 |
| lifeless | [kidding] | 22:05 |
| jam | lifeless: same results if I do '--lsprof-file ,,foo.txt' | 22:06 |
| lifeless | thats not something I saw coming | 22:06 |
| jam | I guess I just dropped to 3.8s, and now 1.7s | 22:06 |
| jam | very weird | 22:06 |
| jam | anyway, still 'tree.commit()' 20 times shouldn't really take that long... | 22:07 |
| lifeless | hmm, actually this may be trickier | 22:07 |
| lifeless | jam: locking is slow - are you on windows? | 22:07 |
| jam | yeah | 22:07 |
| jam | still way too long, IMO | 22:07 |
| lifeless | I agree; not sure how to fix it. That test does want separate packs | 22:07 |
| lifeless | uhm perhaps suspend_write_group+resume_write_group | 22:08 |
| lifeless | or | 22:08 |
| lifeless | memorytransport | 22:08 |
| lifeless | the latter I think would be better | 22:08 |
| jam | tree = self.make_branch_and_memory_tree('tree', format='2a') | 22:08 |
| jam | 1325ms | 22:08 |
| jam | unless a memory tree is still backed by the real disk repo | 22:09 |
| lifeless | it is | 22:09 |
| lifeless | you need | 22:09 |
| lifeless | self.vfs_transport_factory = MemoryServer | 22:09 |
| lifeless | and then that | 22:09 |
| jam | 421ms | 22:10 |
| jam | a decent improvement | 22:10 |
| lifeless | better indeed | 22:10 |
| jam | and that includes test-suite setup overhead | 22:10 |
| jam | 312ms if it isn't the first test being run | 22:11 |
| jam | still fairly surprising given what it should actually be doing... but at least it isn't terrible now | 22:11 |
| lifeless | changing to TestCaseWithMemoryTransport would reduce some overhead too | 22:12 |
| lifeless | and further still when I fix bzrlib.config to not write to disk, and bzrlib.bzrdir.clone to not search unconditionally for repository policies (which is a reason we have to have the fake containing dir on disk) | 22:13 |
| lifeless | netbeans export at 118K/133K | 22:14 |
| lifeless | 103G | 22:14 |
| jam | ouch | 22:15 |
| lifeless | it will be _very_ interesting to see what bzr makes of this tree | 22:15 |
| lifeless | I'm hoping it will be an eat-their-lunch event | 22:16 |
| lifeless | either way we'll learn something | 22:16 |
| lifeless | hmm, this needs an object. | 22:16 |
| lifeless | refactorating | 22:16 |
| lifeless | ok: for remote streams | 22:17 |
| lifeless | I'm on it. | 22:17 |
| lifeless | no direct tests, and its going to need them now; I'm going to write one small test for this specific case, refactor, and push a branch for you to merge into your work. | 22:18 |
| lifeless | First though, I need a drink, bit dehydrated | 22:18 |
| === beuno is now known as beuno-on-vacatio | ||
| jam | k | 22:18 |
| lvh | hi! | 23:05 |
| lvh | I'm wondering what the canonical (no pun intended ;-)) way of doing this in bzr is. Suppose I have a branch of a project, with commits A -> B -> X -> Y, up to B is pushed to launchpad | 23:06 |
| lvh | someone did a code review of B, and X, Y is the start of a bunch of new functionality | 23:06 |
| lvh | so, I guess moving X, Y into a new branch would make sense | 23:06 |
| lvh | lifeless helped with this, this command: bzr branch . ../positioning-gpsd; bzr pull . --overwrite -r -6 | 23:07 |
| lvh | now, once I fix the things the review hinted at in the main branch I would like to have these changes also be done in the new functionality branch, of course | 23:07 |
| lvh | in git, i would do this with rebase | 23:07 |
| lvh | how do i do this in bzr? | 23:07 |
| lifeless | cd new branch | 23:07 |
| lifeless | bzr merge old branch | 23:07 |
| lifeless | [review] | 23:07 |
| lifeless | bzr commit | 23:08 |
| fullermd | That sounds like a pretty roundabout way of doing bzr branch -r-6 . ../p-g | 23:08 |
| lifeless | fullermd: no, its kindof the reverse | 23:08 |
| === kiko is now known as kiko-afk | ||
| lvh | lifeless: wait, merge the old branch from the new branch? | 23:09 |
| fullermd | It huh? | 23:09 |
| lvh | I do actually do this, right: bzr branch . ../positioning-gpsd; bzr pull . --overwrite -r -6 | 23:09 |
| fullermd | It's the same thing, just directly expressing what's being done instead of backing and filling.. | 23:09 |
| lifeless | lvh: you want the reviewed changed from the older branch in the newer branch ? | 23:09 |
| lvh | lifeless: Ah, I was thinking of not having two separate branches anymore, but yeah I gues sthat makes sense too | 23:10 |
| lvh | eg have the branch just be a temporary container for commits | 23:10 |
| lvh | but your way makes more sense, never mind :-) | 23:10 |
| lvh | lifeless: thanks again! | 23:10 |
| lifeless | fullermd: it is, except that the branch dirs are reversed the other way, which, when you're thiking abuot a problem a specific way is confusing. | 23:10 |
| fullermd | lvh: Well, once you merge, you _do_ just have one branch :) | 23:11 |
| lifeless | fullermd: Feeling philospohical today? | 23:11 |
| fullermd | lifeless: Oh, I overread the 'cd' in the middle. | 23:11 |
| lvh | fullermd: the old branch disappears? | 23:11 |
| poolie | hello all | 23:11 |
| lifeless | lvh: no, it doesn't. | 23:11 |
| lvh | or two directories in the same state | 23:11 |
| lvh | plus or minus a few branch specific commits | 23:12 |
| fullermd | It _can_, since you have all its revs. Unless you need to keep it aroudn for somethign else. | 23:12 |
| lifeless | lvh: the old branch is untouched. the new branch has the changes you made in old merged into it, | 23:12 |
| lifeless | lvh: so the old branch isn't needed at that point, thats all that fullermd is saying, I think. | 23:12 |
| lifeless | hi poolie | 23:12 |
| lvh | oh, right | 23:13 |
| fullermd | I'm always feeling philosophically. It's just usually not very cogent or meaningful :p | 23:13 |
| lvh | thats okay, I have a quickly learning heuristic filter | 23:13 |
| lvh | (if lifeless: pay attention else: ignore) | 23:13 |
| fullermd | Excellent. We always need more quick learners 8-} | 23:14 |
| lifeless | jam: done | 23:26 |
| lifeless | mm | 23:29 |
| poolie | hello jam | 23:29 |
| lifeless | bzr push ../foo with uncommitted changes in . pushed those changes to ../foo as uncommitted there >< | 23:29 |
| lifeless | surprising | 23:29 |
| lifeless | jam: lp:~lifeless/bzr/adjacent-streams - merge that | 23:30 |
| lifeless | poolie: james_w rebuilt the debs last night. | 23:30 |
| lifeless | poolie: I haven't manually confirmed they are green yet, but they should be. | 23:30 |
| poolie | that's great | 23:34 |
| bialix | vila: are you still here? | 23:34 |
| vila | no :) | 23:35 |
| vila | bialix: Won't stay long, but I'm listening to you | 23:35 |
| bialix | config.py AuthenticationConfig | 23:36 |
| bialix | get_user and get_password | 23:36 |
| bialix | which transport can trigger them? | 23:36 |
| vila | all | 23:36 |
| bialix | we have bug in qbzr, re bzr-svn | 23:36 |
| bialix | jelmer insist bzr-svn uses these methods | 23:37 |
| vila | ach, bzr-svn :-/ | 23:37 |
| bialix | I'd like to test my bug fix w/o svn | 23:37 |
| bialix | so, bzr+ssh? | 23:37 |
| bialix | or sftp? | 23:37 |
| vila | what do you mean by 'jelmer insist' ? | 23:37 |
| bialix | wait a sec, I'll show bug number to ubottu | 23:38 |
| vila | all transports can potentially make use of auth.conf, that's less useful for ssh because there are better solutions there (ssh agents and .ssh/config) | 23:38 |
| bialix | https://bugs.launchpad.net/qbzr/+bug/418252 | 23:38 |
| ubottu | Launchpad bug 418252 in qbzr "attempt to check out SVN repo never gets anywhere" [High,Confirmed] | 23:38 |
| * bialix waves to emmajane | 23:39 | |
| * emmajane waves to bialix | 23:39 | |
| bialix | I like design #2, but I've already wrote this | 23:40 |
| bialix | vila: paramiko as ssh agent can use auth.conf | 23:40 |
| bialix | err | 23:41 |
| bialix | vila: paramiko as ssh client | 23:41 |
| vila | yes | 23:41 |
| * vila reading the bug report | 23:41 | |
| bialix | so, which transport will trigget get_user? | 23:41 |
| vila | any transport can | 23:41 |
| emmajane | bialix, excellent :) | 23:42 |
| vila | so you can test with whatever is easier for you | 23:42 |
| bialix | vila: for local testing I'd prefer stick to sftp/ssh | 23:43 |
| vila | there shouldn't be any difference from bzr-svn if I read jelmer comments correctly | 23:43 |
| vila | so, if you can get get_user/get_password called from the command line, the same should occur from tbzr | 23:44 |
| bialix | vila: I have fuzzy feeling that sftp/ssh transport deduce user name somehow | 23:44 |
| bialix | vila: this is my question actually: how can I force get_user ask | 23:44 |
| vila | things have changed in this area... but I can't point to when exactly | 23:44 |
| bialix | I can use ftp | 23:45 |
| vila | you can force get_pasword by connecting to a host where your key is not authorized or temporarily rename your key to force a password check... | 23:45 |
| vila | ftp is simpler :-) | 23:45 |
| bialix | get_password is not problem | 23:45 |
| bialix | qbzr lacks get_user implementation | 23:46 |
| bialix | I don;t remember I ever seen prompt for user name with bzr CLI | 23:46 |
| vila | bialix: just look at the bzrlib tests then ! get_user is tested almost like get_password | 23:46 |
| vila | bialix: We didn't have get_user for a very long time because it's very rarely used, I think we first need it for an http server | 23:47 |
| poolie | lifeless: jam says he's finished working for the day, so if you want to take over that would be good | 23:50 |
| poolie | don't wait to hear back from him | 23:50 |
| lifeless | heh, chinese whispers | 23:50 |
| lifeless | ok | 23:50 |
| lifeless | he says its just tests and glue | 23:50 |
| lifeless | I'll start with glue. | 23:50 |
| bialix | vila: test_config tests very low level API | 23:51 |
| bialix | vila: I can't test with http, heh, have to find some open svn repo to test this | 23:52 |
| vila | bialix: test_ui not test_config | 23:53 |
| bialix | test_ui? | 23:54 |
| vila | bzrlib/tests/test_ui.py contains test for get_username | 23:55 |
| bialix | yes, but it's low level too | 23:56 |
| bialix | ok, vila, perhaps we both need to go offline till tomorrow | 23:57 |
| vila | what's wrong with low level tests ? You want low level tests for your qbzr implementation right ? | 23:57 |
| vila | bialix: yeah, good idea :) | 23:57 |
| bialix | no, I want high level | 23:57 |
| bialix | manual test with real access to real branch | 23:57 |
| bialix | heh | 23:58 |
| bialix | gnight vila | 23:58 |
| bialix | :-) | 23:58 |
| vila | bialix: let's talk about that tomorrow then :) The problem with manual tests is that... you pay in blood every time you run them :) | 23:58 |
| * bialix waves | 23:58 | |
| bialix | tomorrow | 23:58 |
| bialix | pay in blood? scary | 23:59 |
| * bialix finally disappear | 23:59 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!