| === Ursinha is now known as Ursinha-afk | ||
| glyph | is there a 'bzr st --no-ignore' or equivalent? | 02:16 |
|---|---|---|
| beuno | glyph, maybe bzr ls --ignored? | 02:26 |
| spiv | glyph: there's the separate 'bzr ignored', but I guess you're after what bzr thinks of all files in a given directory? | 02:26 |
| spiv | (if so, 'bzr ls' with various flags is probably the way to go) | 02:28 |
| spiv | glyph: Also, '--no-ignore' is pretty much what bzr st already does: show no ignored files ;) | 02:29 |
| glyph | spiv: "no ignores" not "no ignored" :) | 02:31 |
| glyph | spiv: I want a complete enumeration of all files, with none of them ignored, to do something programmatic (in a shell script) to a bzr working tree. | 02:31 |
| spiv | glyph: bzr ls -iVuR, perhaps with added -v | 02:32 |
| spiv | And -0 | 02:32 |
| spiv | What's the something, out of interest? | 02:33 |
| glyph | huh. What's 'V' mean in that output? | 02:33 |
| glyph | spiv: revert for reals | 02:33 |
| glyph | spiv: an operation which, curiously, no version control system implements | 02:34 |
| spiv | glyph: 'bzr revert && bzr clean-tree --detritus'? | 02:37 |
| glyph | spiv: <3 | 02:37 |
| spiv | :) | 02:38 |
| glyph | nope, still doesn't quite work | 02:38 |
| glyph | it doesn't delete '.moved' directories, apparently. | 02:38 |
| glyph | oh wait, no, it works | 02:38 |
| glyph | I just wanted 'bzr clean-tree --unknown --detritus --force' | 02:38 |
| spiv | (FWIW, the 'V' in that output means 'versioned', I think) | 02:39 |
| spiv | (not that you care now :) | 02:39 |
| glyph | wait no... 'bzr clean-tree --ignored --unknown --detritus --force' | 02:39 |
| glyph | why isn't that the default | 02:39 |
| glyph | you could make the default behavior be invoked via 'bzr clean-tree --not-really' | 02:39 |
| spiv | By default it deletes unknowns. | 02:40 |
| spiv | While leaving potentially valuable ignored files. | 02:40 |
| spiv | Arch had a sometimes useful distinction between 'junk' (always safe to delete) and 'precious' (not versioned, but don't delete automatically) | 02:41 |
| spiv | I occasionally wish we'd kept that, although I think probably that level of complexity probably does users more harm than good. | 02:42 |
| spiv | And of course no categorisation is ever perfect: sure .pyc files are almost always junk or explicitly versioned, but maybe you don't want your vcs to randomly delete .o files that are expensive to rebuild. | 02:44 |
| spiv | Except when you do... | 02:44 |
| spiv | Anyway, I'm glad I've saved you from some shell scripting :) | 02:45 |
| * spiv -> lunch | 02:45 | |
| glyph | hrm | 02:45 |
| glyph | you may have saved me even more than you thought | 02:45 |
| glyph | does this work for svn too? | 02:45 |
| spiv | Probably! | 02:46 |
| glyph | Haha it does | 02:46 |
| glyph | _rad_ | 02:46 |
| glyph | oh crud, except there _are_ like 2 dotfiles I want to not delete | 02:48 |
| spiv | glyph: easy! | 02:55 |
| spiv | Just copy those files to /tmp and back :P | 02:56 |
| spiv | glyph: actually, if you want to be slightly cunning, | 03:04 |
| spiv | glyph: 'bzr revert; bzr add .dotfile1 .dotfile2; bzr clean-tree --yadda-yadda; bzr rm --keep .dotfile1 .dotfile2' | 03:04 |
| glyph | spiv: Cute. | 03:05 |
| spiv | There's no point doing the add before the revert, of course :) | 03:05 |
| glyph | spiv: I already implemented the other thing, but I might switch to that. | 03:05 |
| spiv | (The --keep is redundant in this case too, but explicitness and paranoia doesn't hurt) | 03:06 |
| glyph | spiv: you forgot the last 'bzr revert', too ;) | 03:10 |
| spundun | hi all... quick question | 03:28 |
| spundun | if I do bzr checkout URL | 03:28 |
| spundun | or I do bzr branch URL wd; cd wd; bzr bind URL | 03:29 |
| spundun | it seems to have the same effect | 03:29 |
| spundun | am I understanding that right? | 03:29 |
| spundun | change the first version to bzr checkout URL wd | 03:29 |
| glyph | spundun: Yes. | 03:36 |
| glyph | spundun: 'bzr checkout' is an alias for creating a bound branch to make it easier on people who are familiar only with svn. | 03:36 |
| glyph | If you just s/bzr/svn in your commandlines, everything basically works if you don't think too hard about it :) | 03:37 |
| spundun | ah, ok | 03:37 |
| spundun | I find the concept weird that I create a branch using bzr branch URL, and then within that branch I can just do bzr push URL, then I'm not reall a branch anymore, I'm the trunk :/ | 03:39 |
| spundun | by I, I mean my branch | 03:40 |
| glyph | spundun: But it is a branch: if you commit to it, it won't get committed to trunk. You could push it somewhere else on the server, if you didn't want to push those revisions to trunk. | 03:40 |
| spundun | yes, I get that. But somehow in my mind, I shouldn't be able to push my branch back to the trunk, I should have to merge it or something... | 03:41 |
| glyph | spundun: consider: bzr get ...:.../trunk; cd trunk; hack hack hack; cd ../; mv trunk my-feature-branch; bzr get ...:.../trunk; cd trunk; bzr merge ../my-feature-branch | 03:41 |
| spundun | ok | 03:42 |
| spundun | I guess the more I think about it, the more I'll get used to the idea | 03:42 |
| spundun | or something like that | 03:42 |
| spundun | thanks glyph | 03:44 |
| glyph | spundun: another way to think of it is that initially, a branch is a perfect copy of the thing it's a branch of. you can push/pull between them to re-synchronize them, assuming they haven't diverged. A merge is only necessary to resolve the conflict that occurs when two branches go in two different directions. | 03:45 |
| glyph | trunk isn't "special", it's just a branch in a particular place that you've socially agreed is important to a project. | 03:45 |
| spundun | right, ok | 03:46 |
| === jdobrien_ is now known as webm0nk3y | ||
| jam | morning all | 08:08 |
| vila | oops, morning jam et all ;) | 08:08 |
| jam | I thought it was "et al" | 08:09 |
| vila | jam: do you know how doc.bazaar.canonical.com scripts are handled ? | 08:09 |
| vila | argh, yes, it *is* et al | 08:09 |
| vila | thinko between english, french and latin ;) | 08:09 |
| fullermd | Just blame it on a typo. We'll all believe you :p | 08:09 |
| vila | hehe | 08:10 |
| vila | are 'al' and 'all' pronounced the same in english ? | 08:10 |
| bob2 | no, latter is more like awl | 08:10 |
| fullermd | Not out of my mouth.. | 08:10 |
| fullermd | But 'al' isn't English, so it's a trick question, really... | 08:11 |
| bob2 | it's a (short) name ; | 08:11 |
| bob2 | ) | 08:11 |
| jam | bob2: I've always pronounced "et al" as in "pet" "all" | 08:11 |
| jam | And I agree more like "awl" | 08:11 |
| jam | doesn't mean I pronounce it correctly | 08:11 |
| bob2 | hm, I say et al(lan) | 08:11 |
| bob2 | possibly people are too polite to correct me ;p | 08:12 |
| jam | http://www.thefreedictionary.com/et+al. | 08:12 |
| jam | says it is supposed to be "et alii" | 08:12 |
| jam | or et alia | 08:12 |
| vila | let's add some confusion: 'etal', in french, is where butler cut the meat ;) | 08:12 |
| bob2 | I have even less idea how to pronounce et alli! | 08:12 |
| vila | bob2: probably like Italy ;) | 08:13 |
| bob2 | haha | 08:13 |
| === weigon_ is now known as weigon | ||
| vila | mass_import.py up to 812M resident memory, "something" is leaking or python is *really* bad to manage its heap | 09:05 |
| lifeless | 'manage'. lol. | 09:05 |
| jam | vila: 812MB for the driving script seems pretty excessive | 09:05 |
| vila | in other news nexuiz-data is still happily running at 100% CPU without producing any data in its log :-/ | 09:05 |
| vila | jam: right, even 100M would seem excessive... | 09:05 |
| vila | lifeless: was the joke targeted at python or at my poor english (I guess the former but just checking) ? | 09:06 |
| jam | vila: python, as I understood it | 09:06 |
| jam | /wave lifeless | 09:06 |
| lifeless | python | 09:06 |
| lifeless | hai :) | 09:07 |
| vila | I can't remember if mass_import was already consuming that much memory when running for weeks before my driver changes... | 09:07 |
| vila | jam: any idea about poking at a running python script with meliae ? | 09:08 |
| jam | vila: if you can get a pdb console, you can get in with meliae | 09:09 |
| jam | I think there are some gdb tricks you can pull ,but none that I really know | 09:09 |
| vila | k, thanks | 09:09 |
| jam | I think Andrew mentioned using gdb to interrupt, then set trap at the trace function | 09:09 |
| jam | and then install pdb at that point | 09:10 |
| jam | that way you know you aren't interrupting the middle of a python OP code, etc. | 09:10 |
| vila | I think we should just kill this import then and try to reproduce the issue locally | 09:10 |
| jam | spiv^^? | 09:10 |
| jam | vila: you mean nexuis? | 09:10 |
| vila | yup | 09:10 |
| jam | if you had console access, bzr already installes SIGQUIT => pdb | 09:10 |
| jam | but I don't think you have console access to the builder process | 09:10 |
| vila | given it has been spawned from a cron script, I doubt I can get console access yes | 09:11 |
| vila | the disturbing fact is that the log file hints that we are in the middle of a bzr operation | 09:12 |
| vila | a commit | 09:14 |
| jam | vila: We've talked about a SIGUSR1 or SIGHUP handler that would just dump "traceback.format_tb()" into .bzr.log. | 09:15 |
| vila | 10 days to process a commit is probably considered excessive too :) | 09:15 |
| jam | It wouldn't be hard to create if you think it would be helpful | 09:15 |
| jam | vila: we may be inefficient, but 10 days is a little rediculuous | 09:15 |
| jam | I would say 1 hr is max, even for nexuis-data | 09:16 |
| vila | oh, sorry, I've been slightly exaggerating, it's 99% CPU not 100 | 09:16 |
| fullermd | Oh, shucks, you made a new release... | 09:25 |
| jam | vila: well in that case, it is clearly not blocked :) | 09:26 |
| vila | jam: :) | 09:29 |
| vila | fullermd: yeah, by the way, any hint about why bzr-duilder is packaged for FreeBSD ? | 09:29 |
| fullermd | 'cuz C-S packaged it. | 09:30 |
| * fullermd glances at logs. | 09:30 | |
| fullermd | http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/149891 | 09:30 |
| * vila has no idea who Control-Super is... | 09:30 | |
| jam | Better than Meta-Super, that guy is a jerk | 09:31 |
| vila | I'm pretty sure it requires some debian dependencies... | 09:31 |
| vila | if not Ubuntu dependencies for that matter | 09:32 |
| LeoNerd | jam: He recently escaped | 09:32 |
| vila | LeoNerd: ha ha | 09:32 |
| vila | using an alternate exit ? | 09:32 |
| vila | . o O (Slowly but inexorably emacs progresses on all fronts ;) | 09:33 |
| fullermd | If you're all through bucking around... | 09:33 |
| vila | Sawhorse Saw"horse`, n. | 09:34 |
| vila | A kind of rack, shaped like a double St. Andrew's cross, on | 09:34 |
| vila | which sticks of wood are laid for sawing by hand; -- called | 09:34 |
| vila | also buck, and sawbuck. | 09:34 |
| vila | [1913 Webster] | 09:34 |
| vila | I'm so much informed now :( | 09:34 |
| vila | no idea about what a *single* St Andrew's cross is... | 09:34 |
| fullermd | It's half of a double St. Andrew's cross. | 09:35 |
| vila | interesting google images results... http://www.google.com/search?client=ubuntu&channel=fs&q=St.+Andrew%27s+cross&ie=utf-8&oe=utf-8 | 09:36 |
| vila | I meant the union jack flag origin of course.. | 09:38 |
| vila | adding double to the search terms amazingly returns images with... two crosses... how smart... NOT ! | 09:40 |
| * fullermd declines to enquire into where vila's mind wanders... | 09:40 | |
| lifeless | 'double rainbow' | 09:41 |
| vila | what with the old mails spam from lists.ubuntu.com ? | 10:06 |
| catphish | morning | 10:27 |
| vila | _o/ | 10:35 |
| catphish | _o/ high five | 10:39 |
| catphish | you'll be relieved to know that i don't need any help today, everything is working nicely :) | 10:40 |
| vila | yeah ! | 10:40 |
| catphish | hopefully i'm finished with being a pain for now | 10:40 |
| vila | hehe, you're not a pain, this channel is here to provide help ;D | 10:41 |
| catphish | and very helpful it is :) | 10:41 |
| catphish | by the way, my implementation is for http://www.codebasehq.com/ | 10:42 |
| vila | why doesn't it mention bzr then :-p | 10:43 |
| catphish | because it's not ready yet | 10:43 |
| vila | good, better than the opposite :) | 10:43 |
| catphish | we're making a bunch of changes, some of which are announced | 10:43 |
| catphish | bzr support is not announced, just going to surprise people with it | 10:44 |
| catphish | plus i wanted to be sure it was going to work | 10:44 |
| jml | jelmer_: I saw your email to ubuntu-devel about showing authors | 11:07 |
| jelmer_ | jml: I've heard the same concern Dave come up a couple of times before. What do you think? | 11:08 |
| jml | jelmer_: It reminded me of things I've wanted to do with bzr-stats | 11:09 |
| jml | jelmer_: get # of landings rather than # of commits. | 11:09 |
| jml | jelmer_: and it would make 'bzr log' way more useful for PQM-managed projects | 11:10 |
| jelmer_ | jml: Yeah, indeed | 11:10 |
| jml | hmm. | 11:11 |
| jml | I wonder how interesting it would be to do it in a plugin | 11:11 |
| jml | jelmer_: fwiw, I'd propose this output: http://paste.ubuntu.com/578777/ | 11:12 |
| jelmer_ | jml: I think we should have all the magic in place to do it in a plugin | 11:13 |
| jelmer_ | "bzr log --format=boo" | 11:13 |
| jelmer_ | that would be an interesting experiment | 11:14 |
| jelmer_ | maxb: Do you have any thoughts on how we should deal with the dh_python2 transition ? | 11:16 |
| jelmer_ | maxb: I guess we could either create separate recipes for the older distro series, or patch all of them to avoid dh_python2. | 11:16 |
| jelmer_ | maxb: I'd prefer doing the first, otherwise we'll end up doing the patching forever. | 11:17 |
| vila | jml, jelmer: Are you talking about adding authors at commit time or extracting them at log time ? | 11:17 |
| jml | vila: extracting at log time | 11:17 |
| vila | as jelmer mentioned there are perfs issues (so far) and in the context of pqm, I think adding the authors at commit time would make far more sense no ? | 11:18 |
| jelmer_ | vila: I think that would use up precious space in the revision text for some projects, and it wouldn't help with historical and foreign data | 11:19 |
| jelmer_ | if it's too much of an issue I think a cache would be the best approach | 11:20 |
| vila | hmm | 11:21 |
| vila | jelmer_: I was talking about *always* adding authors, only for projects that want it (and I was thinking plugin there, not core) | 11:23 |
| vila | s/was/*wasn't*/ | 11:24 |
| vila | ! | 11:24 |
| jam | vila: if you have -n0, then you have the information easily available | 11:24 |
| vila | sure, I thought the issue was to *not* use -n0 nor the implied perf penalty | 11:25 |
| jam | vila: without it, perf is going to suck quite a bit more, in semi-common cases | 11:25 |
| vila | and ISTR that adding author in pqm context was mentioned in the past too | 11:25 |
| jam | determining non-common ancestors is pretty hard | 11:26 |
| jam | and doing it over-and-over again for each rev is pretty bad | 11:26 |
| vila | yeah but one day we'll have to fix that once and for all | 11:26 |
| jam | vila: could you do that tomorrow? | 11:29 |
| vila | it's on my TODO list, but pretty much at the bottom unfortunately | 11:30 |
| vila | I just find it annoying that we keep spending time on workarounds :( | 11:31 |
| maxb | jelmer_: I've not thought about it - I'm planning to study the situation and form an opinion over the weekend | 11:33 |
| jelmer_ | maxb: ok, I'll hold off for a bit then | 11:33 |
| jelmer_ | jam: Did you see my followup to https://code.launchpad.net/~jelmer/bzr-email/drop-pre-0.15/+merge/49628 ? | 11:53 |
| jam | jelmer_: approved | 11:53 |
| jelmer_ | jam: Thanks | 11:54 |
| jam | I did see it, but just didn't have anything else to add. "approve of the rest" covered my feelings, though it wasn't explicit | 11:54 |
| awilkins | Do people think that branching a working tree at a given revision should branch from that revision even if it's not the tip of the branch for that working tree? | 11:56 |
| jelmer_ | jam: ah, ok | 11:56 |
| jelmer_ | awilkins: That's a tricky one | 11:57 |
| awilkins | e.g. bzr update -r N # where N is less than P which is tip revision ; bzr switch -b newbranch ; bzr revno # emits P not N | 11:57 |
| jelmer_ | awilkins: It would be useful to warn the user in that situation. | 11:57 |
| jelmer_ | awilinks: That said, I think it might require opening the dirstate file to figure out the revno of the working tree | 11:58 |
| awilkins | jelmer_, A valid story would be - I bisected to find a bug, now I want to branch the revision that introduced it to fix it ala DaggyFixes | 11:58 |
| awilkins | jelmer_, Probably, I know that qlog does something to work out the current revision because it marks it in the log | 11:59 |
| awilkins | jelmer_, For switch -b it must be doing it anyway because it merges the new branch (at HEAD) to the one you have so you end up with a working tree of HEAD | 12:00 |
| jelmer_ | awilkins: Yeah, but not for e.g. "bzr branch <remote-location>" | 12:01 |
| awilkins | jelmer_, No, I don't think that is intuitive | 12:02 |
| jelmer_ | awilkins: So, I think it makes sense to warn the user if they try to branch from a location where there are both a working tree and a branch with the tip out of sync | 12:02 |
| awilkins | jelmer_, I think I'm really only thinking about local branches and lightweight checkouts | 12:02 |
| jelmer_ | awilkins: I don't think we should be inconsistent in the way we treat local and remote branches | 12:03 |
| awilkins | jelmer_, I agree that's a useful warning ; I found the idea that once I had updated my lw checkout to a particular revision that switch -b would branch that revision to be intuitive and the result (branching the HEAD of the branch bound to the checkout) to be understandable but disappointing | 12:04 |
| jelmer_ | awilkins: Is there a particular reason why you're only switching your working tree rather than your working tree *and* your branch tip ? | 12:05 |
| awilkins | The -b implies that I'm creating a branch tip and switching to it | 12:05 |
| awilkins | Or are we driving at different things? My work setup is typically lightweight checkouts | 12:07 |
| jelmer_ | yes, but why do you use "bzr up -r" ? It causes the working tree tip and the branch tip to be different | 12:07 |
| awilkins | In this case, I am bisecting somewhat manually | 12:07 |
| awilkins | I have located the revision with the bug in it and wish to start a new branch with this revision at it's tip so I can fix it | 12:08 |
| jelmer_ | ah, hmm | 12:08 |
| jelmer_ | so perhaps we should allow you to do something like "bzr switch -b newbranch -rtree:" | 12:09 |
| awilkins | I was just going to suggest bzr switch -b newbranch -r `bzr revision-info` ; but apparently revision-info does not respect dirstate | 12:10 |
| jelmer_ | awilkins: it has a --tree option | 12:10 |
| awilkins | jelmer_, Aha, that's nice | 12:11 |
| maxb | A dirstate-based revspec would be lovely though | 12:12 |
| maxb | especially for access to pending merge tips | 12:12 |
| jelmer_ | yeah | 12:12 |
| * jelmer_ files teh bug | 12:12 | |
| awilkins | Ah, and switch -b -r does not behave as you'd want | 12:14 |
| jelmer_ | yeah, please file a bug about that | 12:14 |
| awilkins | $ bzr switch -b -r 201 fix-update # Tree is up to date at revision 233. | 12:14 |
| jelmer_ | well, you'd want an argument to -b | 12:15 |
| jelmer_ | ah, you have - sorry | 12:15 |
| awilkins | Ack | 12:15 |
| awilkins | Ah, yes, not an arg to be, arg to command | 12:15 |
| awilkins | It doesn't respect the revision argument for either case, branching or non-branching | 12:17 |
| mgz | <jam> vila: We've talked about a SIGUSR1 or SIGHUP handler that would just dump "traceback.format_tb()" into .bzr.log. <- there's still a good chance this would kill the ongoing operation, given how dodgy signals are | 12:22 |
| vila | mgz: true and hi ! | 12:23 |
| mgz | and SIGTERM already dumps the current stack as it exits, right? | 12:23 |
| * mgz waves at vila | 12:23 | |
| vila | hmm, that would at least gives us a hint... | 12:24 |
| vila | fullermd: I'd like to install sphinx for some tests, but it seems it's available only for py27 :-/ | 12:36 |
| vila | fullermd: I don't want to play around with 2 different versions of python on my babune slave, so, is bzr packaged for 2.7 and if not when/why/what ? | 12:36 |
| vila | ha, finally the true jelmer is back... | 12:44 |
| jelmer | heh | 12:46 |
| jelmer | I had a nouveau freeze :-/ | 12:46 |
| vila | hmpf | 12:46 |
| awilkins | Are the docs on the website in the main source tree? I've spotted a bug asking for some clarification in the Visual Sourcesafe docs I wrote but I can't remember where the doc sources are .... | 12:49 |
| maxb | doc/... :-) | 12:50 |
| jelmer | awilkins: most of the docs live under doc/en in lp:bzr | 12:50 |
| vila | awilkins: it depends, but doc.bazaar.c.c are mostly in... too slow for jelmer :) | 12:50 |
| jelmer | vila: and for maxb :) | 12:50 |
| vila | errk, didn't even saw this one ;D | 12:50 |
| vila | on the other hand, the shortest answers came first :) | 12:51 |
| awilkins | Yeah, can't find http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-vss-users.html there though. | 12:51 |
| awilkins | I should know, I wrote it | 12:52 |
| awilkins | Gah | 12:52 |
| jelmer | heh | 12:53 |
| vila | parent branch: http://bazaar.launchpad.net/~bzr/bzr-migration-docs/trunk/ | 12:53 |
| awilkins | Aha | 12:53 |
| vila | jelmer: thanks for the review ! | 14:06 |
| jelmer | vila: np | 14:29 |
| * jelmer resubmits his lazy-bzrdir branch | 14:32 | |
| jelmer | maxb: Hmm, weren't all the issues with running the bzr-dbus testsuite on a buildd fixed now? | 14:35 |
| * jelmer is still getting failures building for sid | 14:35 | |
| maxb | Well, the recipe build seems happy | 14:44 |
| maxb | Got a link to the sid buildlog? | 14:44 |
| jelmer | there isn't one - I'm building locally | 14:45 |
| jelmer | I'll pastebin | 14:45 |
| jelmer | maxb: http://pastebin.ubuntu.com/578852/ | 14:49 |
| maxb | ah, I remember that test, that's the one which tries to connect to a dbus session bus running outside the context of the build | 14:50 |
| maxb | http://bazaar.launchpad.net/~bzr/bzr-dbus/trunk/revision/47 was my attempt to skip it when appropriate | 14:51 |
| maxb | I guess my "when appropriate" check isn't working out quite right for you | 14:51 |
| jelmer | actually, I see what's happening | 14:52 |
| briandealwis | spiv: I've been seeing if I could duplicate that strange locking problem. Doesn't work on a cooked up example. But it always happens with a particular branch. -Dlock doesn't show anything out of the ordinary (to me). Are there any other debug switches I could try? | 15:01 |
| jelmer | briandealwis: I bet spiv's asleep | 15:02 |
| jelmer | briandealwis: if this is a bzr+ssh:// issue you were trying to debug -Dhpss might help | 15:02 |
| briandealwis | ah, he's showing green | 15:02 |
| briandealwis | It's a local issue. | 15:02 |
| briandealwis | I have two branches, p1 and p2 that have a common ancestor. Trying to push from p1 to p2 results in a strange self-locking problem | 15:03 |
| jelmer | maxb: fixed it by starting a temporary dbus session | 15:03 |
| briandealwis | I wasn't having this problem in 2.2.x; maybe I'll try some bisecting. | 15:04 |
| mgz | briandealwis: what's the bug number? | 15:08 |
| briandealwis | mgz: haven't filed a bug yet, sorry. | 15:09 |
| briandealwis | mgz: will do that next | 15:09 |
| briandealwis | mgz: finally filed as bug 733350 | 16:17 |
| ubot5 | Launchpad bug 733350 in Bazaar "LockContention error when pushing to a bound branch" [Undecided,New] https://launchpad.net/bugs/733350 | 16:17 |
| jelmer | vila: Thanks for the review, I'll add some docstrings. | 16:23 |
| jelmer | vila: it's not just bzr-svn that adds itself to the beginning of the server prober list, bzr-hg and bzr-git do as well | 16:23 |
| vila | jelmer: thanks for your persistence there ;) | 16:23 |
| vila | jelmer: one more reason to discuss a saner scheme, the issue has existed for far too long | 16:24 |
| vila | jelmer: and even if your work allows more lazy loading, ISTM that bzr-svn users still pay a penalty when they work with bzr branches only right ? | 16:25 |
| jelmer | vila: they do an extra OPTIONS request when talking over http, but that's all at this point | 16:25 |
| jelmer | I added some hacks to do that OPTIONS request over the existing HTTP connection, rather than building up a new connection. | 16:26 |
| vila | jelmer: and you manage to not load any modules that won't be needed if the probe fail ? | 16:26 |
| vila | . o O (I'm tired, I'm sure this could expressed in a simpler way :-/) | 16:27 |
| jelmer | vila: yes, that's the point of the probers. the prober implementations live inside the plugin __init__ and only load the actual stuff when they find something | 16:28 |
| vila | ha ok, so the lazy loading addresses the remaining issues then | 16:29 |
| vila | jelmer: about the OPTIONS stuff, wibni (once you land you hacks in core ;) the smart server was adding its own option too ? | 16:31 |
| jelmer | vila: what's wibni ? | 16:32 |
| vila | Wouldn't It Be Nice If ? or did I mangled that ? | 16:32 |
| === beuno is now known as beuno-lunch | ||
| mgz | briandealwis: is that info at the bottom for the trunk branch? if so, the push branch value is odd, try editing .bzr/branch/branch.conf to remove it | 16:33 |
| jelmer | vila: no, you didn't... just an acronym I didn't know yet :) | 16:33 |
| briandealwis | mgz: you're right, I made a mistake: it's from the workspace branch | 16:33 |
| jelmer | vila: Yeah, it'd be nice to add an OPTIONS entry for the bzr smart server.. though we should probably still support the POST request in case the user is e.g. using a cgi script | 16:33 |
| briandealwis | mgz: I've been able to reproduce the issue from a synthetic branch — it hinges on tags | 16:34 |
| vila | . o O (There you are, people are so used to your tyops that they see tyops even when you type correctly) | 16:34 |
| mgz | okay, in which case the odd thing is is *also* thinks it a checkout of backup? | 16:34 |
| mgz | that's not intended surely | 16:34 |
| vila | jelmer: sure and for older clients too, but still | 16:34 |
| mgz | tags being what's broken seems likely, spiv added some new behaviour there. | 16:35 |
| briandealwis | mgz: I bind "trunk" to "backup", where "backup" exists on a different drive. So pushes to "trunk" are backed up | 16:35 |
| mgz | but the fix for you should probably just be editing a conf file. | 16:35 |
| mgz | briandealwis: but what is 'workspace'? A normal branch? a checkout? | 16:35 |
| briandealwis | mgz: a normal branch | 16:36 |
| mgz | the info posted is of a checkout. | 16:36 |
| briandealwis | mgz: now I'm confused :) | 16:37 |
| mgz | `bzr info` on workspace should say it's parent branch is trunk, and have no checkout bits | 16:37 |
| mgz | `bzr info` on trunk should have no parent branch, and say it's a checkout of backup. | 16:38 |
| mgz | `bzr info` on backup should just say it's a normal branch. | 16:38 |
| briandealwis | mgz: I was right originally: it was from "trunk"; that was info carried when branching from my original branches | 16:38 |
| briandealwis | mh | 16:38 |
| briandealwis | mgz: I removed the stray info, and it makes no difference | 16:39 |
| briandealwis | mgz: I'll add a synthetic example that demonstrates the bug in a sec | 16:39 |
| mgz | ah, you've got one now? | 16:39 |
| briandealwis | mgz: yeah — it's all about pushing with tags | 16:40 |
| briandealwis | mgz: I used bisect to identify the problematic commit. if you look at it, it adds some locking. | 16:40 |
| mgz | yup, I can repo too with that. | 16:41 |
| vila | jelmer: I'm very tempted to give you the green light to land all the weave-in-a-plugin stuff | 16:45 |
| jelmer | vila: \o/ Did you see the intermediate branch, bzrdir-weave ? | 16:45 |
| vila | jelmer: since you raise an error if the old_register_format is used, the worst that can happen is that people running trunk will have to revert if they encounter issues | 16:46 |
| vila | jelmer: did you see my reviews ;) | 16:46 |
| jelmer | clearly I haven't :) | 16:46 |
| vila | jelmer: and I'm sure you will be motivated to fix any bugs if that's the case | 16:46 |
| jelmer | yeah, of course | 16:47 |
| briandealwis | mgz: I tacked on the example | 16:47 |
| mgz | yup, that's similar to what I got to fail. | 16:48 |
| vila | jelmer: with 2.4b1 close to freeze, I tend to prefer landing now than wait for a second review which will requires more effort from the reviewer than your own efforts to fix the hypothetical fallouts | 16:48 |
| vila | mgz: any progress on https://code.launchpad.net/~gz/bzr/create_delta_index_memoryerror_633336/+merge/52251 ? | 16:49 |
| jelmer | vila: sounds good to me - most of it is just moving code around now anyway | 16:49 |
| vila | mgz: I didn't review closely but I was wondering if your actual fix was already viable ? | 16:50 |
| mgz | yeah, I'm going to give in and rewrite those two functions to take **struct and return a code rather than *struct | 16:50 |
| mgz | it's a bigger change, but there's no point trying to keep a limited api when they need sensible error handling. | 16:51 |
| vila | mgz: ha ! Yeah, when you're tired to override, using distinct objects help express better semantics ;) | 16:52 |
| mgz | darnit, what's the trick for getting the mainline rev a dotted rev was merged in? I always forget it and give up and use qlog instead. | 17:03 |
| vila | mainline: ? | 17:05 |
| mgz | http://paste.ubuntu.com/578908/ <- and the number of times I do this as well, env-variables is particularly painful | 17:07 |
| vila | mgz: bzr help topics | 17:07 |
| mgz | yeah, but `bzr help topics | grep env` is just as annoying to type every time | 17:08 |
| vila | mgz: which is itself mentioned in 'bzr help' | 17:08 |
| vila | oh | 17:08 |
| mgz | so, I try and remember and get it wrong a few times. | 17:08 |
| mgz | why, for instance, is 'environmental' abbreviated, but 'variables' is not? | 17:09 |
| vila | yeah, this needs to be reworked, revisionspec is another bad example | 17:10 |
| maxb | It should probably be 'environment-variables' with an alias of 'envvars' | 17:11 |
| vila | or may be bzr-guess could be extended to handle help topics and merge in core | 17:12 |
| vila | merge*d | 17:12 |
| vila | I thought Parth worked on a bit on that at some point... | 17:12 |
| mgz | ^thanks, mainline works, presumably new in 2.2 or 2.3 though. | 17:13 |
| vila | yup, I'd say 2.3 | 17:13 |
| mgz | right, I need some food, then I'll write a little code. | 17:15 |
| === deryck is now known as deryck[lunch] | ||
| === beuno-lunch is now known as beuno | ||
| vila | mgz: mah, my memroy was bad, help topic guessing has been *disabled* in revno... 2 :-( | 17:57 |
| jelmer | vila: argh, test isolation failure :-( | 18:30 |
| vila | jelmer: caught by pqm ? | 18:31 |
| jelmer | vila: yep | 18:31 |
| vila | which branch ? | 18:32 |
| jelmer | vila: lazy-bzrdir | 18:32 |
| vila | k | 18:32 |
| jelmer | vila: bzrlib.tests.test_remote.TestBzrDirCloningMetaDir.test_current_server happens to fail because the returned control dir suddenly has its repository format set to 2a | 18:33 |
| jelmer | the cause seems to be the fact that we now run the per_controldir tests against RemoteBzrDirFormat | 18:33 |
| vila | ah | 18:33 |
| vila | why do you suspect an isolation issue ? | 18:34 |
| jelmer | vila: I can reproduce it locally. "./bzr selftest -s bt.test_remote" succeeds, "./bzr selftest -s bt.per_controldir -s bt.test_remote" fails | 18:34 |
| vila | arg | 18:34 |
| * jelmer wonders what the best approach is to debug this sort of thing | 18:35 | |
| vila | they are all painful | 18:35 |
| vila | :) | 18:35 |
| jelmer | is there any particular function that gets called after each test? | 18:35 |
| vila | probably, never tried that approach though | 18:36 |
| vila | what I generally do is establish a list of tests including the failure and bisect it | 18:37 |
| maxb | jelmer: Concerning bzr-rewrite packaging - is it correct to drop the "Replaces: bzr-rebase" whilst retaining the Conflicts? | 18:37 |
| vila | jelmer: as an aside, just trying to run bzr with my current trunk of bzr-hg crashes with NotImplementedError: <bound method type.known_formats of <class 'bzrlib.plugins.hg.HgProber'>> | 18:38 |
| vila | --no-plugins time is back :-/ | 18:38 |
| vila | seems to be in bzrlib.tests.per_controldir.test_push.TestPush | 18:43 |
| === deryck[lunch] is now known as deryck | ||
| jelmer | vila: Can you try again with trunk? | 18:45 |
| vila | try what with which trunk ? | 18:45 |
| vila | don't lose focus on the crash, different people will have different issues, we'll see later :) | 18:46 |
| vila | bzrlib.tests.per_controldir.test_push.TestPush.test_push_new_empty | 18:46 |
| vila | ./bzr selftest --no-plugins -s bzrlib.tests.per_controldir.test_push.TestPush.test_push_new_empty -s bzrlib.tests.test_remote.TestBzrDirCloningMetaDir.test_current_server | 18:47 |
| vila | is enough to reproduce | 18:47 |
| vila | puzzling | 18:53 |
| vila | as often with isolation issues... | 18:53 |
| jelmer | vila: I think I found the test isolation issue | 18:53 |
| vila | yes ? | 18:53 |
| jelmer | one of the fallback cases for RemoteBzrDirFormat modifies the RemoteBzrDirFormat in-place | 18:54 |
| jelmer | in some of the other cases we use .__class__() to create a new copy and modify that | 18:54 |
| vila | evil | 18:55 |
| jelmer | ./bzr selftest --no-plugins -s bzrlib.tests.per_controldir.test_push.TestPush.test_push_new_empty -s bzrlib.tests.test_remote.TestBzrDirCloningMetaDir.test_current_server passes in bzr.dev for me | 18:56 |
| jelmer | since you mentioned bzr-hg earlier, are you sure you mean with --no-plugins ? | 18:57 |
| vila | pass for bzr.dev here | 18:57 |
| vila | even without --no-plugins | 18:58 |
| vila | crash in the lazy-bzrdir without --no-plugins | 18:58 |
| vila | revo 401 for bzr-hg | 18:58 |
| vila | jelmer: gotta go, happy hunting :-} | 19:04 |
| fullermd | vila: *yawn* | 19:04 |
| fullermd | vila: py27 was actually switched to the default earlier this week... I haven't pulled the switch yet. | 19:05 |
| fullermd | vila: 'member you're _building_ via ports, so it's not a question of 'packaged against'; it builds against whatever you've got installed. So switching to 2.7, and rebuilding py* and bzr (maybe 1 or 2 other bits?) would do the job. | 19:07 |
| vila | fullermd: thanks ! My notes from the py26 upgrade says: http://paste.ubuntu.com/578954/ | 19:12 |
| vila | fullermd: so, IIUC, I should do the same, I may a bit for things to settle down in ports no ? | 19:12 |
| fullermd | Pretty much, just s/26/27/ and s/25/26/ all 'round. | 19:12 |
| vila | k | 19:13 |
| vila | I should really go now, gf is waiting ;) | 19:13 |
| fullermd | It should probably be OK, else they wouldn't have pulled the default switch. | 19:13 |
| vila | k, I'll do a vm backup first anyway | 19:13 |
| catphish | evening | 22:58 |
| catphish | does anyone know how i might go about converting a filtered-139770606741392:// url to a real path? | 22:59 |
| jelmer | hi catphish | 23:01 |
| catphish | hi jelmer | 23:02 |
| jelmer | catphish: I have no idea, where are you getting that URL from? | 23:02 |
| catphish | your code ;) | 23:03 |
| jelmer | I doubt it's *my* code :) | 23:03 |
| catphish | the (c) has your name in lol | 23:03 |
| catphish | anyway, its changeBranchTipParams.__dict__['branch'].base | 23:03 |
| catphish | in a hook | 23:03 |
| jelmer | catphish: hmm, which file is that? | 23:04 |
| catphish | shell-hooks | 23:04 |
| jelmer | oh, that's just coming in from an external source e.g. a smart server | 23:04 |
| catphish | correct | 23:04 |
| jelmer | it's unrelated to the shell hooks plugin | 23:04 |
| catphish | your original hook didnt support the changeBranchTipParams hook | 23:05 |
| catphish | so i don't suppose it ever came accross data from an external push | 23:05 |
| catphish | anyway it's branch.base | 23:05 |
| catphish | and it returns: filtered-139770606741392:///default/ | 23:05 |
| jelmer | I think it predates the changeBranchTipParams hook | 23:06 |
| catphish | makes sense | 23:06 |
| catphish | i assume it's a type of chroot | 23:06 |
| jelmer | yep | 23:06 |
| catphish | do you have any thoughts how i might map it to the real path? | 23:07 |
| jelmer | have a look at branch.root_transport | 23:07 |
| jelmer | it's probably some sort of special transport that wraps the actual transport | 23:07 |
| catphish | hmm, i don't see branch.root_transport | 23:10 |
| catphish | ah, its a PathFilteringTransport | 23:15 |
| maxb | I was looking at this stuff just recently | 23:26 |
| * maxb tries to remember things | 23:26 | |
| catphish | i'm a little confused by why instance methods accept self as the first parameter, i'm not a python developer but that seems odd | 23:27 |
| maxb | catphish: Unlike most languages, Python chooses to pass the instance reference as an explicit first parameter, which is conventionally called self | 23:27 |
| maxb | Rather than defining a special keyword for it | 23:28 |
| maxb | I suppose you could call it "this" instead of "self", but then anyone else reading your Python code would look at you very strangely | 23:28 |
| catphish | so it is normal to call: object.method(object) | 23:29 |
| catphish | ? | 23:29 |
| maxb | No, when you call it, magic happens, and the reference is provided implicitly | 23:30 |
| catphish | i understand :) | 23:30 |
| maxb | Or, to be slightly more truthful, when you reference object.method, what you get is not the raw method object, but is a *bound* method - a wrapper that inserts the object reference before passing on the call | 23:31 |
| catphish | ok | 23:32 |
| catphish | PathFilteringTransport seems reluctant to give up its absolute path | 23:33 |
| catphish | when asked, it raises filtered-140259821971344:///default/.bzr/branch is not a local path | 23:33 |
| maxb | I am investigating a possibility.... | 23:33 |
| catphish | thanks | 23:34 |
| catphish | ah, external_url perhaps | 23:34 |
| maxb | yes | 23:35 |
| catphish | awesome | 23:36 |
| catphish | external_url returns a raw file:// url | 23:36 |
| catphish | sexy | 23:36 |
| maxb | :q | 23:36 |
| maxb | oops | 23:36 |
| maxb | catphish: note that external_url() may return a readonly+file:// url if the server is running in readonly mode | 23:37 |
| catphish | good to know | 23:37 |
| catphish | though in my case that will never happen | 23:37 |
| catphish | since a read won't trigger my hook | 23:37 |
| catphish | but i might as well write the plugin to handle it | 23:37 |
| catphish | all working now, thanks | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!