| * maxb crosses fingers, declares a possible solution to dh_python2 backports, and waits for the build farm to get on with it | 00:07 | |
| * spiv wonders what's up with https://bugs.launchpad.net/bzr/+bug/745664 | 00:10 | |
| ubot5 | Ubuntu bug 745664 in Bazaar "Incremental push to stacked branch on LP walks all of history" [Critical,Confirmed] | 00:10 |
|---|---|---|
| jelmer | maxb: what's your solution? | 00:16 |
| maxb | jelmer: pretty much what I was outlining this morning | 00:21 |
| maxb | shim packages that lead to dh_pysupport/central being invoked | 00:21 |
| jelmer | maxb: ah, right | 00:22 |
| jelmer | I hadn't expected you to actually've implemented it since then :) | 00:22 |
| maxb | hmm, the web UI no longer permits copying packages to jaunty | 00:23 |
| jelmer | does anybody still care about jaunty ? :) | 00:24 |
| maxb | I think it might be time to officially drop ~bzr/ppa support | 00:26 |
| jelmer | maxb: in favor of up to date distro packages and the daily builds? | 00:32 |
| jelmer | maxb: I think that's sensible, though perhaps we should check with the people currently using it | 00:32 |
| maxb | oh, I meant drop ~bzr/ppa support for Jaunty | 00:36 |
| maxb | :-) | 00:36 |
| maxb | err, what?! Really weird build failure from bzr-daily/maverick: https://launchpadlibrarian.net/67748861/buildlog_ubuntu-maverick-i386.bzr_2.4~bzr5744~ppa3921.3921~maverick1_FAILEDTOBUILD.txt.gz | 00:38 |
| maxb | gcc errors compiling pyrex .c files | 00:39 |
| * maxb has a look at loggerhead recipe conflict | 00:46 | |
| spiv | maxb: r5731 changed that code | 00:51 |
| spiv | maxb: but the change seems to work on my maverick system | 00:52 |
| spiv | maxb: although, huh | 00:53 |
| spiv | maxb: I don't see the *_pyx.c files being regenerated in that buildlog | 00:54 |
| spiv | maxb: shouldn't pyrex be run at some point? | 00:55 |
| maxb | maybe | 00:58 |
| maxb | but, puzzling why it should work on natty | 00:58 |
| spiv | maxb: http://bazaar.launchpad.net/~debian-bazaar/bzr/unstable-2.4/files/head:/bzrlib/ appears to have stale .c files | 00:58 |
| maxb | jelmer: Do you know why dulwich-daily is set to exclude karmic? | 00:59 |
| maxb | spiv: The packaging branches usually pick up .c files from the previously imported tarball. It's normally OK. I guess we've found a situation where it is not | 00:59 |
| spiv | maxb: it seems weird to me that we don't run pyrex at build time | 01:00 |
| spiv | maxb: python-pyrex is even listed as a build-depends | 01:00 |
| maxb | The bzr/daily PPA is doing quite a thorough job of saturating the PPA/i386 buildds right now :-) | 01:18 |
| spiv | :) | 01:19 |
| poolie__ | maxb, wow | 01:30 |
| poolie__ | where is that shown? | 01:30 |
| === poolie__ is now known as poolie | ||
| spiv | poolie: https://launchpad.net/builders I guess | 01:32 |
| bignose | where is a good channel to ask about the ‘testtools’ package? | 04:12 |
| lifeless | here, #subunit #testtools | 04:13 |
| lifeless | erm, the last is fiction | 04:13 |
| lifeless | also #python-testing or whatever its called | 04:13 |
| bignose | lifeless: okay, meet you there? :-) | 04:16 |
| lifeless | bignose: ping me from whatever channel you choose ;) | 04:17 |
| poolie | hi jam | 06:07 |
| danielsh | last week I started storing my dotfiles in bzr | 06:09 |
| danielsh | now I'd like one dotfile to different between my desktop/laptop | 06:09 |
| danielsh | (different font size in the terminal emulator) | 06:10 |
| danielsh | how can I do that? | 06:10 |
| danielsh | if I change the config file on the laptop, then I can't seem to ignore that change on the desktop, any pull/merge requires a commit which then the laptop wants to pull, | 06:10 |
| danielsh | lather, rinse, repeat | 06:11 |
| * danielsh hopes his explanation is clear enough... | 06:12 | |
| jam | morning poolie | 06:13 |
| poolie | hi danielsh | 06:15 |
| danielsh | poolie: morning | 06:16 |
| poolie | there's a few options | 06:16 |
| poolie | one would be to make that file a symlink into a machine-specific directorie | 06:16 |
| poolie | hi jam | 06:16 |
| * danielsh (oh, forgot to say, I checked with the latest stable version before I /joined here.) | 06:16 | |
| danielsh | unfortunately the file is a plain .ini file, there's no easy way to do 'source `hostname`/foo.conf' or similar | 06:19 |
| danielsh | as to storing all the different versions in the history everywhere, | 06:20 |
| danielsh | that doesn't seem nice, I'm not sure where to start, | 06:20 |
| danielsh | it offloads the problem of diverging changes to me, rather than to the tool, | 06:21 |
| danielsh | I'm not sure that it scales well (think N machines), | 06:21 |
| poolie | how would you like it to work? | 06:22 |
| danielsh | on laptop: edit file. commit. on desktop: merge that commit while making an edit that the laptop won't try to pull. | 06:23 |
| danielsh | end result: laptop has font size 11, desktop has font size 12, | 06:23 |
| spiv | I think "have one master template, and then N local variations, and when the master updates help merge those updates into the local variations" is something bzr doesn't really cater to directly, but you could build on top of bzr. | 06:23 |
| danielsh | and I can keep bzr push/pull between them | 06:24 |
| danielsh | (and yes I may run into conflicts sometimes) | 06:24 |
| spiv | In bzr terms these would all be separate branches | 06:24 |
| poolie | so you want to make a "don't merge this" commit? | 06:24 |
| poolie | yes, you could have a separate branch for stuff that is meant to be common | 06:24 |
| danielsh | poolie: I'm not sure what is the bzr term for what I want. | 06:24 |
| spiv | And when you update the master you'd then merge that into the local branches, but typically not merge the other way. | 06:24 |
| spiv | I know there are tools like etckeepr that can use bzr, but I don't know if they cater to this specific use case or not | 06:25 |
| danielsh | so in that case I'd have on each box two branches: | 06:25 |
| danielsh | * the master branch (shared, identical everywhere) | 06:25 |
| danielsh | * a local branch (only pulls from master, never pushes) | 06:25 |
| danielsh | ? | 06:25 |
| spiv | You wouldn't have to have a copy of master on each box, but it may be convenient to do so. | 06:26 |
| poolie | correct | 06:26 |
| poolie | merges from master | 06:26 |
| spiv | But basically, yes. | 06:26 |
| danielsh | Okay, I see. | 06:26 |
| danielsh | I'd have to propagate changes from ~/.foorc to ~/master.bzr/foorc manually, though | 06:27 |
| poolie | jam i wonder if i can just do without <BLANKLINE> or give an option to do without it | 06:27 |
| poolie | i agree it is a bit ugly | 06:27 |
| danielsh | (or cherry-pick them..) | 06:27 |
| danielsh | spiv, poolie: thanks for discussion, I've learnt something :-) | 06:28 |
| jam | poolie: yeah, something. I'm back to family time, now that everyone is waking up. Be back in about 2 hrs | 06:29 |
| * danielsh will check out etckeeper, too. | 06:29 | |
| poolie | sure :) | 06:29 |
| poolie | i was a bit surprised to see you | 06:29 |
| lifeless | jam: I'm sorry if you feel unhappy about my backing out the lp-runs-loggerhead tests | 06:35 |
| lifeless | jam: I hope I've explained well enough on the bug, but if not I'm happy to discuss further here | 06:36 |
| poolie | jam, it turns out it is happy without the blankline markers | 06:45 |
| vila | hi all ! | 07:26 |
| jam | hi vila | 09:00 |
| jam | lifeless: I'd be happy to discuss it with you. I can see some of your points, but I have some of my own | 09:00 |
| jam | right now, I have to finish moving out of the apartment, though | 09:00 |
| jam | So maybe late tonight (early your morning, I think) | 09:01 |
| vila | hey jam ! | 09:01 |
| spiv | jam: please do take up that push regression, that'd be great | 09:01 |
| vila | jam: good luck with your move, don't break too many things ;) | 09:01 |
| vila | jam: and enjoy your new place ! | 09:01 |
| * spiv → afk | 09:02 | |
| jam | thanks vila | 09:04 |
| jam | have a good evening spiv | 09:04 |
| jam | vila: I would enjoy it more if we had furniture | 09:04 |
| jam | Customs has delayed it for 1 month so far, and are currently saying "you don't have proof that you didn't live in EU for 12 months" | 09:05 |
| jam | so they want to charge us as though we are bringing it to sell, or something. | 09:05 |
| vila | jam: naaah, give a try to a more zen-like attitude, just sell your stuff ! | 09:05 |
| jam | and by default, online statements only go back 12 months from today | 09:05 |
| jam | which doesn't go back to Jan, 2010 | 09:05 |
| jam | vila: right. Of course, sleeping on hardwood floors is the real Zen challenge | 09:05 |
| vila | jam: welcome to Europe :D | 09:06 |
| lifeless | jam: ugh | 09:06 |
| vila | . o O (Keeping the balance between sarcasm and true compassion is hard) | 09:06 |
| poolie | hiya vila, jam | 09:06 |
| vila | poolie: heya ! | 09:06 |
| lifeless | jam: sure, can chat whever | 09:06 |
| jam | We could get a hotel room, but extended hotel room stays and 3-year olds don't go very well together. | 09:07 |
| jam | we bought some air mattresses, but the people on the box must be midgets. I clearly overhang the end by about 30cm, and I'm not all that tall. | 09:08 |
| jam | hey poolie | 09:08 |
| poolie | :) | 09:09 |
| vila | welcome to Eur... err already made that one, but there is a long tradition of jokes around here about US making bigger "things", looks like mattresses fit the category :D | 09:09 |
| jam | vila: yeah. "Everything is bigger in Texas". I was actually a bit disappointed that things in Dallas weren't bigger. They just seemed US-sized. :) | 09:11 |
| poolie | the cars were pretty big | 09:12 |
| poolie | oh and the guns | 09:12 |
| poolie | and the food | 09:12 |
| jam | poolie: but not particularly bigger than elsewhere in the US | 09:12 |
| jam | we have the statement *in the US* that "Everything is bigger in Texas" | 09:12 |
| jam | I guess the Hats are usually bigger | 09:12 |
| poolie | yeah, and Queensland is bigger than Texas :) | 09:12 |
| poolie | vila, i may be just missing the point, but the config stuff seems eminently split-able | 09:15 |
| vila | poolie: except for the deployment part... | 09:15 |
| vila | may be *I'm* missing the point :) | 09:15 |
| poolie | for instance we can add a better api without changing anything much else | 09:15 |
| vila | the sore point is BranchConfig and its relationship with remote configs | 09:16 |
| vila | so may be I should just start with GlobalConfig... | 09:16 |
| poolie | why is it sore? | 09:18 |
| vila | poolie: have a look at set_option (name, value, section=None) and _set_option(self, value, name default) and _set_option(self, section_name, option_name, value) | 09:20 |
| vila | and the various classes involved starting from BranchConfig and including TreeConfig, TransportConfig BzrDirConfig | 09:21 |
| vila | so while each of the proposed classes are easy to implement in isolation (that was the goal), using them requires to handle the transition path and while I know that it will be ok at the feature level, I fear some evil details when migrating from the existing files | 09:24 |
| vila | one option is to use *new* file names, but this means updating the docs and our user brains (the later being far harder ;) | 09:24 |
| vila | but neither being cheap | 09:25 |
| vila | so I feel more comfortable landing the new features well tested but not used and *then* focus on the migration | 09:25 |
| vila | my last failed attempt has been to address bug #491196 :-/ | 09:26 |
| ubot5 | Launchpad bug 491196 in Bazaar "want a way to set configuration options from the command line" [Medium,Confirmed] https://launchpad.net/bugs/491196 | 09:26 |
| vila | the proposed design makes it trivial, but only after deploying the new design... | 09:27 |
| poolie | hm | 09:28 |
| poolie | i do kind of feel like it should be possible to have an api that stacks just the dynamic config on what we have now | 09:28 |
| poolie | but i guess the proof is in actually trying to do it | 09:28 |
| vila | yeah, I share*d* the feeling :-/ | 09:29 |
| vila | Have a look at ConfigStack in iconfig.py in lp:udd: I needed a ugly hack to get usable ConfigStack | 09:34 |
| vila | same goes for expand_options, basically if I fear that going incremental will end up with a code full of hacks from the start when the goal is instead to get (hopefully) a clean implementation that will be easier to enhance | 09:36 |
| vila | s/if I fear/I fear/ | 09:36 |
| vila | if hasattr(c, 'get_user_option') and not hasattr(c, 'get'): | 09:37 |
| vila | c.get = types.MethodType(compatible_get, c, c.__class__) | 09:37 |
| poolie | i saw that | 09:37 |
| vila | is the ugly hack I'm referring to: it injects a bound method | 09:37 |
| poolie | what's the main motivation for expansions? | 09:38 |
| vila | may be it's a useful technique to handle compatibility if we can find clearer helpers to use it, but... | 09:38 |
| vila | push_location = lp:~{launchpad_unsername}/{project}/{nick} | 09:39 |
| vila | bzr.xxx.action = {script} with {script} being 'ask' for interactive use and True/False otherwise | 09:40 |
| vila | more generally sharing more default values | 09:40 |
| vila | by allowing references | 09:40 |
| poolie | and where does that get set? | 09:41 |
| poolie | it just seems strange to add it before doing the other refactorings | 09:41 |
| vila | expand you mean ? I'm already using 'bzr push `bzr config mypush`/`bzr nick`' quite often | 09:42 |
| poolie | yeah, i meant internal expansion | 09:42 |
| poolie | i'm not complaining | 09:42 |
| poolie | it may sound like i am :) | 09:42 |
| vila | well, more than quite often in fact, almost always | 09:42 |
| poolie | i just cared more about -Ofoo | 09:42 |
| vila | no no | 09:42 |
| vila | hehe, mee too :D | 09:43 |
| vila | oh, and expand is good for command templates or log templates as seen recently on the ml | 09:43 |
| vila | the main limitation actually is the single config scope | 09:44 |
| vila | which can't be addressed without ConfigStack | 09:44 |
| vila | I'm pretty sure we also have as-yet un-triggered bugs when remote configs are involved | 09:45 |
| vila | like: what if I define a bazaar.conf and a locations.conf on a server | 09:45 |
| vila | do we have the same behavior between smart and dumb servers ? | 09:46 |
| vila | I suspect nobody tried to fiddle with that so far ;) | 09:46 |
| vila | and I'm in no hurry to open the can of worms ;) | 09:47 |
| vila | but abentley raised 'control.conf' used by launchpad and.... that's another can of worms... | 09:48 |
| vila | now, if you look at https://bugs.launchpad.net/bzr/+bugs?field.tag=config , we have 26 bugs there, most of them will be easy to address... if we had this new design | 09:51 |
| poolie | ok | 09:51 |
| vila | but trying to address them *now* and finding the minimal path to get one them fixed... I failed | 09:52 |
| vila | so I finally concluded that this was too hard and that I should try a different approach, hence the proposal | 09:53 |
| vila | well, the 26 above does not include some more general ideas we've been talking about like getting rid of many constants in bzrlib, trying to handle bzr-colo in branch.conf instead of .bzr/branches, etc | 09:54 |
| vila | on the other hand, I don't want to end up with a massive >2000 proposal either | 09:55 |
| vila | so I tried to test-bed things in the package importer... only to realize that other issues were coming in the way there | 09:56 |
| poolie | yeah | 09:56 |
| poolie | i think this will fix things | 09:56 |
| poolie | fix many bugs | 09:56 |
| vila | oh, and I forgot about resolve default actions too for udd | 09:56 |
| poolie | i am just desirous of smallers proposals along the way | 09:56 |
| vila | +1 | 09:57 |
| vila | the plan is to propose the various classes, well tested, one by one | 09:57 |
| vila | preparing the deployment as best as I can doing that | 09:57 |
| vila | another sore point has been the infamously long review of doxxx regarding mergetools (which was also a motivating factor for expand) | 09:58 |
| vila | as was abentley appendir proposal | 09:59 |
| vila | (and still is since he's still blocked because we don't provide a solution for his need) | 09:59 |
| vila | I'm reasonably confident that the proposed design *can* support additions for all known needs (so far) even if things aren't clear enough yet | 10:00 |
| vila | The Store abstraction has enough constraints defined to propose tests reusable for daughter implementations, section selection should address various context definitions *without* forcing too much constraints (regexps, globs, path (relative or absolute)), Option definitions should provide an optional basis for online help | 10:02 |
| vila | I don't think I invented too many new concepts there and I tried to think hard about trivial basis implementations | 10:04 |
| vila | now I need some code to verify that the design is sound or I may as well keep thinking about it for years | 10:04 |
| vila | oh, and an hidden assumption is also that we should get rid of all env vars (if only because they can't be easily used on windows or for guis) | 10:05 |
| jam | vila: Windows works just fine with env vars "set foo=bar" | 10:06 |
| jam | however, it is a bit hard to get to from Guis | 10:06 |
| vila | jam: tell that to my mom... | 10:06 |
| vila | I mean, for most users the workflow just never involves being able to 'set foo=bar' | 10:07 |
| vila | they want something in a file | 10:07 |
| vila | even 'bzr -Ofoo-bar xxx ...' won't work for them | 10:07 |
| poolie | mm | 10:07 |
| poolie | we should just define options that have an environment variable as a way to set them, but also a regular name | 10:08 |
| poolie | anyhow, that's enough for me for today | 10:08 |
| poolie | jam, thanks for the reviews | 10:08 |
| poolie | i might add tests for some of them tomorrow | 10:08 |
| poolie | i may be being a bit lazy | 10:08 |
| vila | poolie: right, but what's the point of having both 'foo=bar bzr ...' *and* 'bzr -Ofoo=bar ...' ? | 10:08 |
| poolie | things like <https://code.launchpad.net/~mbp/bzr/733136-lock_url/+merge/55706> where in other languages a compiler error would pick it up, i'm not sure how much it's worth adding a test | 10:09 |
| poolie | vila, if we could handle everything through the second case i think the first would be unnecessary in almost all cases | 10:09 |
| vila | poolie: +1, not worth the trouble to add a test | 10:09 |
| poolie | it does have one advantage which is that it inherits | 10:09 |
| vila | oh, good point | 10:09 |
| poolie | ie you can set the plugin path in your .bash_env | 10:09 |
| vila | may be -O should propagate to subprocesses ;D | 10:10 |
| vila | plugin_path is trickier (as are some other options) | 10:10 |
| jam | vila: other than being able to do "export BZR_FOO=bar" and have it valid for the lifetime of your session | 10:11 |
| poolie | i mean you can set it in the shell and it will pass through emacs down to bzr | 10:11 |
| poolie | for instance | 10:11 |
| vila | I'm contemplating a [__init__] section in bazaar.conf :D | 10:11 |
| jam | -Ofoo=bar doesn't persist | 10:11 |
| vila | jam: sure, but that still doesn't work for windows newbies | 10:12 |
| vila | i.e. the ones that don't know how to setup env vars for their session | 10:12 |
| jam | vila: set works just fine, and if they are newbies they are (a) prob not on the command line, (b) not going to know about -Ofoo=bar either. | 10:12 |
| poolie | anyhow | 10:12 |
| vila | jam: indeed, but they still want to set some default values | 10:12 |
| poolie | let's try to get there | 10:12 |
| poolie | i'll try to comment on your api examples tomorrow | 10:13 |
| jam | vila: I would hesitate to expect that there is someone who doesn't know how to set their env vars who also *does* know how to set -Ofoo. | 10:13 |
| vila | ok | 10:13 |
| jam | *my* point is just that "no env vars" isn't somewhere we actually want to be | 10:13 |
| jam | we might want fewer | 10:13 |
| jam | but I don't think that value is 0 | 10:13 |
| jam | poolie: have a good evening | 10:13 |
| poolie | we want a way to have per-process settings that don't use the environment | 10:13 |
| vila | jam: I'm not saying we should *not* support them, I'm saying that if one feature is available thru env vars *only*, then some users won't be able to use it | 10:14 |
| poolie | that's the main reason people would add them today | 10:14 |
| poolie | agree with that | 10:14 |
| jam | (11:05:33 AM) vila: oh, and an hidden assumption is also that we should get rid of all env vars (if only because they can't be easily used on windows or for guis) | 10:14 |
| jam | vila: which is what I was rebutting. It sounds like we agree | 10:14 |
| vila | jam: yeah, re-read it with ... yeah | 10:14 |
| vila | badly phrased | 10:14 |
| vila | err, is 'phrased' english ? formulated ? expressed ? | 10:15 |
| jam | vila: phrased or expressed | 10:15 |
| jam | "we don't want to require users to use env vars" | 10:15 |
| jam | would be a better way | 10:16 |
| jam | vila: stuff like default plugin path, etc, certainly belongs in a config. Though being able to override it easily gets tricky | 10:16 |
| vila | jam, poolie : Thanks for the constructive feedback anyway, I don't want to sound to defensive on this proposal. Just trying to make sure the ideas behind it aren't lost because I didn't explain them well enough | 10:17 |
| vila | jam: yeah, I'm beginning to accept that even the plugin path and the config files should somehow be specified into a config file. But for bootstrap reasons, I'm inclined to restrict their use to bazaar.conf only (so far) | 10:18 |
| vila | jam: and until then, I won't delete BZR_PLUGIN_PATH, BZR_DISABLE_PLUGINS and BZR_PLUGINS_AT :D | 10:18 |
| vila | but these aren't the most pressing bugs either | 10:19 |
| lifeless | vila: FWIW, wearing my user hat, I'd be much more interested in package importer stuff, or colocated branches, or build form branch, than config changes | 10:20 |
| vila | lifeless: funnily enough, all of the mentioned areas will benefit from that by making changes easier to implement | 10:21 |
| lifeless | vila: I've learnt to be wary of budgeting work on that basis; you may be entirely right, or it may be less than break even | 10:29 |
| vila | lifeless: and you're damn right there | 10:29 |
| lifeless | vila: The only thing I took away that would be easier would be a command line tool to set options, which didn't seem particularly relevant to $aforementioned | 10:30 |
| vila | lifeless: bzr config foo=bar ? | 10:30 |
| lifeless | yeah | 10:30 |
| vila | lifeless: try bzr/2.3 | 10:30 |
| vila | with a bunch of limitations so far | 10:31 |
| lifeless | what I mean | 10:31 |
| lifeless | is I don't see the connection from that to e.g. the importer | 10:31 |
| vila | bug #719888 and the hurdles to test locally | 10:31 |
| ubot5 | Launchpad bug 719888 in Ubuntu Distributed Development "package import on jubany/pepo should write logs to a dedicated and configurable log directory" [Medium,Fix released] https://launchpad.net/bugs/719888 | 10:31 |
| vila | or a better way to specify options for imports on a package, series, pocket basis | 10:32 |
| vila | or the ability to specify post-merge resolve actions on a dir/file basis in a persistent way | 10:33 |
| lifeless | uhm | 10:33 |
| lifeless | these still don't seem connected | 10:33 |
| lifeless | to config foo=bar | 10:34 |
| lifeless | I'm not saying they aren't nice | 10:34 |
| lifeless | I just don't understand the relevance | 10:34 |
| lifeless | for instance | 10:34 |
| lifeless | LP has configuurable log dirs | 10:34 |
| lifeless | and doesn't have a tool to set config variables | 10:34 |
| vila | we aim at making all options be specified either in a config file or from the command line | 10:35 |
| vila | config files providing various ways to set default values for various contexts | 10:35 |
| lifeless | you're describing a design | 10:35 |
| lifeless | what problem are you solving | 10:36 |
| vila | so either you set the option in a config file or you specify it from the command line | 10:36 |
| lifeless | and how is that problem relevant to the importer | 10:36 |
| vila | the losa want a way to decide where the log files are stored, the importer should respect that | 10:36 |
| lifeless | [meta: I don't mean to criticise :- but I don't understand the links, and I suspect other observers also won't.] | 10:36 |
| vila | the log dir was a hard-coded constant | 10:37 |
| lifeless | vila: could they not just edit ~/.bazaar/bazaar.conf | 10:37 |
| vila | lifeless: only if the code even try to look there | 10:37 |
| vila | which it wasn't | 10:37 |
| lifeless | ok, so perhaps if I now draw a comparison: | 10:38 |
| lifeless | A: implement a system to do arbitrary config option setting | 10:38 |
| vila | and still don't because there is no way to keep bazaar.conf in the same branch as the importer scripts (so far) | 10:38 |
| jelmer | maxb: those bzr-git test failures are due to an old dulwich | 10:38 |
| lifeless | B: Fix the packaging importer code to ask global config for theoption | 10:38 |
| lifeless | vila: ~/.bazaar/bazaar.conf doesn't need to be in said branch, does it ? | 10:38 |
| maxb | jelmer: Ah, hi. I wanted to ask you what you thought about migrating from cdbs to dh7 for dulwich and subvertpy | 10:39 |
| vila | lifeless: if you keep a default value in the scripts, no | 10:39 |
| maxb | jelmer: The motivation is that the current Build-Depends on cdbs is on a version only available in natty, and I REALLY do not want to backport cdbs | 10:39 |
| lifeless | vila: I don't understand why a default value would be needed | 10:39 |
| jelmer | maxb: Hmm, I thought I already did that | 10:40 |
| lifeless | as in, config = GlobalConfig(); logfir = config.get_user_config('pkg importer log dir') | 10:40 |
| vila | lifeless: to keep track of what options need to be defined | 10:40 |
| lifeless | vila: you've just switched problem statements I think. | 10:41 |
| lifeless | vila: you said 'the losa want a way to decide where the log files are stored, the importer should respect that' | 10:41 |
| maxb | jelmer: Not for those two, apparently (dh_python2 yes, dh7 no) | 10:42 |
| jelmer | maxb: ah, just not pushed | 10:42 |
| maxb | jelmer: I love it when fixes are that easy :-) | 10:42 |
| vila | lifeless: well, we start with a python file where a bunch of dirs are built from a common base and we want to get to the point where the production site can override them and the testers can also override them | 10:43 |
| vila | lifeless: going there incrementally without a perfect knowledge of the scripts (which I haven't) requires some care | 10:43 |
| lifeless | vila: let me ask a different way | 10:44 |
| lifeless | how many constants did you want to change in the package importer | 10:44 |
| lifeless | and/or how many constants did you see? | 10:44 |
| vila | lifeless: so I didn't want to get rid of the relationships between these various dirs being entirely defined outside of the scripts | 10:44 |
| vila | lifeless: roughly 20 say | 10:44 |
| lifeless | really? | 10:45 |
| vila | yeah | 10:45 |
| lifeless | 20 *different unrelated log dirs* ? | 10:45 |
| vila | nooo | 10:45 |
| vila | there was one log dir that also contained the files served with apache | 10:46 |
| vila | we now have to different base dirs for that | 10:46 |
| lifeless | ok | 10:46 |
| lifeless | so thats 2 | 10:47 |
| lifeless | how does that connect to 'config foo=bar' | 10:47 |
| vila | lifeless: http://paste.ubuntu.com/587731/ | 10:47 |
| vila | part of icommon.py imported by all scripts | 10:47 |
| vila | oh wait, let me add some lines there: http://paste.ubuntu.com/587733/ | 10:48 |
| vila | so, yes, the dirs are created unconditionally | 10:48 |
| vila | but the log dir itself now contain two more dirs 'driver' and 'packages' which are create more lazily | 10:49 |
| vila | create*d* | 10:49 |
| lifeless | ok, but again | 10:49 |
| lifeless | how does this connect to a command line tool to write config files to disk | 10:49 |
| lifeless | it seems to me that: | 10:50 |
| lifeless | - using global config | 10:50 |
| vila | err, modify a config file you mean ? | 10:50 |
| lifeless | - reading 2 or 3 values from there | 10:50 |
| lifeless | - and then putting them in as the relevant base dirs while you split things apart | 10:50 |
| vila | right, that's the final plan | 10:50 |
| lifeless | would meet the losa constraint | 10:50 |
| vila | an incremental step has been to introduce pkgimporter.conf: http://paste.ubuntu.com/587734/ | 10:51 |
| lifeless | I feel like I'm not connecting on this | 10:51 |
| lifeless | it must be frustrating you | 10:51 |
| vila | no, no, go ahead, I appreciate | 10:52 |
| lifeless | so I'll put it directly | 10:52 |
| lifeless | it seems like a 2-3 hour direct and simple change | 10:52 |
| lifeless | became a large scale software engineering problem | 10:52 |
| lifeless | aka | 10:52 |
| lifeless | overengineering | 10:52 |
| vila | I can understand that | 10:53 |
| lifeless | thats *perception* | 10:53 |
| vila | but I didn't spent as much time in it as it may seem | 10:53 |
| vila | I've been *thinking* about that for a long time, but I don't account my in-bed-thinking as work time ;) | 10:53 |
| vila | now, for the package importer, the main issue is that I can't *test* properly such changes which means I need to be cautious when I introduce them | 10:54 |
| lifeless | vila: the thing that is confusing | 10:54 |
| lifeless | is that you say 'bzr config foo=bar' is connected to improving the importer | 10:55 |
| lifeless | and I don't understand that at all | 10:55 |
| vila | oh, sorry, no I was replying to 'can we set that from the command line' | 10:56 |
| vila | for the package importer the issue is to keep such config options under control while allowing losas/testers to do their work without modifying scripts by nahd | 10:57 |
| vila | hand | 10:57 |
| lifeless | vila: ok; so why is that more complex than 'read the options from bazaar.conf' | 10:57 |
| vila | and using bazaar.conf wasn't adequate | 10:57 |
| vila | ha, | 10:57 |
| vila | because I didn't want the definition and the (unclear yet) dependencies to disappear from the branch | 10:58 |
| vila | so maybe it's overcautious rather than overengineering ;) But maybe both... | 10:59 |
| lifeless | vila: so rather than leave the old value commented #was foo=bar\nfoo=config.get_user_option('pkg_importer_foo') | 11:00 |
| vila | lifeless: keep in mind that I *learned* about which files were served over http while addressing the log issue... | 11:00 |
| lifeless | you built a bunch of infrastructure | 11:00 |
| evelyette | hi | 11:00 |
| vila | which one ? | 11:00 |
| lifeless | vila: well, the bzr config foo=bar that you mentioned | 11:00 |
| lifeless | evelyette: hi | 11:00 |
| evelyette | does bazaar have a plugin which scans for file modifications in certain folder and updates the tree automatically | 11:01 |
| evelyette | kindda like inotify in linux | 11:01 |
| vila | lifeless: oh no, that was already built, I didn't built it for the importer | 11:01 |
| lifeless | evelyette: I think someone built something to do that (using inotify) | 11:02 |
| evelyette | lifeless, I would very much like to use that: can you tell me more, maybe provide a link ? | 11:03 |
| vila | lifeless: what I built for the importer is only iconfig.py (~80 lines) so locations.conf can be used to override pkgimporter.conf (which itself just build on top of config.IniBasedConfig | 11:03 |
| lifeless | evelyette: sorry no, google can tell you all I can | 11:03 |
| lifeless | evelyette: Its just a vague memory | 11:03 |
| lifeless | vila: so to backtrack; you say that the package importer will be easier to write with the config overhaul; whats the connection ? | 11:05 |
| lifeless | :) | 11:05 |
| vila | http://paste.ubuntu.com/587734/ | 11:07 |
| vila | and then tester just have to override pkgimport.base_dir | 11:07 |
| vila | and since I keep bumping into, damn why can't I just fu.. do it this way (in so many different places, the importer being the last one)... I thought the threshold was reached | 11:08 |
| lifeless | I can see it being useful | 11:10 |
| evelyette | btw: I just heard of bazaar and had to check it out. I've been using svn/git for now: so how is bazaar different from the svn/git, is it better? | 11:10 |
| vila | lifeless: so, yeah, I try to keep it light and I'd like it to be easy and fast to implement, but I'm tired of working around the lack of it ;D | 11:12 |
| lifeless | vila: fwiw I would just have kept the relative defn's relative and defined two variables in configs | 11:13 |
| vila | evelyette: that's a big vague to be properly answered, especially if you want an answer applying to both svn and git which are rather different ;D | 11:13 |
| evelyette | ok just git then | 11:13 |
| evelyette | svn is crap :) | 11:13 |
| lifeless | vila: by preference I mean - I find overly parameterisable code gets harder to maintain and permits config bugs | 11:13 |
| vila | lifeless: yeah, and use makedirs instead of mkdir, but there is still the risk to create dirs in the wrong place etc | 11:13 |
| vila | lifeless: indeed ! | 11:14 |
| vila | lifeless: which means the true and perfect solution is to re-design the importer scripts which I don't want to do ;) | 11:14 |
| vila | lifeless: or at least not upfront, I'd prefer to go incrementally there even if I can't find a way to do the same for the new config design (or at least not as far as landing simple feature that requires a bit of infrastructure) | 11:15 |
| lifeless | vila: well, you can treat the current structure as being only configurable to the extent you add it | 11:15 |
| lifeless | vila: avoiding both a redesign and overly-configurable code issues | 11:15 |
| lifeless | evelyette: git and bzr are similar in lots of ways | 11:16 |
| vila | lifeless: yup, I'm learning the scripts design as I go | 11:16 |
| lifeless | evelyette: key differences are: bzr tracks file identity, git tracks tree snapshots only; git has an index which is great for code review and confusing for everything else | 11:16 |
| vila | lifeless: (and also collect relevant files like the crontab, the apache config and so on, too) | 11:16 |
| lifeless | evelyette: bzr is written in C and python, git in C and perl | 11:17 |
| evelyette | thanks | 11:17 |
| evelyette | I've also installed bzg-gtk and qbzr but there's no gui anywhere ? | 11:17 |
| evelyette | I'm on gentoo btw | 11:17 |
| vila | bzr-explorer | 11:17 |
| vila | and try 'bzr qlog' in a branch | 11:18 |
| evelyette | there is no such command | 11:18 |
| evelyette | I don't have a branch | 11:18 |
| vila | bzr-explorer is a plugin, 'qlog' is a command from qbzr | 11:18 |
| evelyette | aha | 11:18 |
| evelyette | does that plugin have tray as well ? | 11:19 |
| evelyette | because that is what I really miss | 11:19 |
| evelyette | and the inotify stuff, so the client automatically updates its stuff | 11:19 |
| vila | well, qbzr provides a GUI for many operations on a branch, so you can't see it in action without a branch | 11:19 |
| evelyette | yes I got that :) | 11:19 |
| vila | bzr-explorer mostly relies on qbzr | 11:19 |
| vila | 'have tray' ? | 11:20 |
| evelyette | trayicon | 11:20 |
| vila | you mean an icon .. ok | 11:20 |
| vila | well, you alsmot always need to interact with some file on disk so a tray icon is not a high priority ;) | 11:20 |
| evelyette | ah :) | 11:21 |
| vila | when you say update, you mean update a working tree from a branch ? | 11:21 |
| evelyette | I mean commit the working directory to master bzr server | 11:22 |
| vila | hmpf | 11:22 |
| evelyette | and the other way around | 11:22 |
| vila | sorry | 11:22 |
| vila | I don't know about many cases where you want to commit automatically (automatic messages being meaningless most of the time) | 11:24 |
| evelyette | yes meaningless ... I don't need them | 11:25 |
| vila | but nothing (nor nobody) can stop you to call 'bzr commit -m "auto"' from an inotify hook | 11:25 |
| evelyette | I just want to sync | 11:25 |
| evelyette | yes that's what I want ... is it already written or will I have to write it by myself | 11:25 |
| vila | you probably need to write it, I don't know of an existing plugin to do that (bug google may know better ;) | 11:26 |
| evelyette | does bazaar have any API I can use instead of "bzr commit -m "test"" | 11:26 |
| vila | keep in mind though that rsync or other backup tools may be more appropriate if you don't care about the history of the changes | 11:27 |
| evelyette | yes I do care | 11:27 |
| evelyette | just don't care about the -m option :) | 11:27 |
| vila | bzrlib provides a python API but while this gives greater control this won't be as short as 'bzr commit -m "test"' | 11:28 |
| evelyette | how are the plugins written, in bzrlib ? | 11:28 |
| vila | on top of bzrlib, in python | 11:28 |
| evelyette | so if I write that module in python, can I submit it ... and you'll keep it in the next versions of bazarr | 11:29 |
| evelyette | because I would only like to write it once and have it available with bazaar installation, not by copying the .py files around | 11:29 |
| vila | you can write a plugin without it being part of bzr core | 11:29 |
| evelyette | yes that's what I mean | 11:29 |
| evelyette | are you in charge of keeping that in plugins dir or whatever | 11:30 |
| vila | the core carries only a few plugins, most of them are packaged independently for various platforms | 11:30 |
| vila | s/most of them/most of the existing plugins/ | 11:30 |
| evelyette | cool | 11:31 |
| evelyette | is there any good tutorial on bzrlib | 11:31 |
| vila | like qbzr, bzr-gtk, bzr-explorer | 11:31 |
| evelyette | http://doc.bazaar.canonical.com/plugins/en/plugin-development.html | 11:31 |
| vila | yup, certainly a good starting point, have a look as existing plugins too, there are a lot of good practices that aren't documented in the url above | 11:32 |
| jam | spiv: From what I can tell, bug #745664 is because your "fetch all tags" code also fetches all tagged revisions into a stacked branch. | 12:46 |
| ubot5 | Launchpad bug 745664 in Bazaar "Incremental push to stacked branch on LP walks all of history" [Critical,Confirmed] https://launchpad.net/bugs/745664 | 12:46 |
| maxb | I think it's likely to be what has caused my bzr-svn fetching of kdesupport to start taking aaaaages iterating tags too | 12:54 |
| jelmer | maxb: are you fetching into a stacked branch? | 13:13 |
| maxb | jelmer: no | 13:25 |
| jelmer | maxb: I'm not sure I understand how it's related in that case | 13:26 |
| maxb | abnormal amount of excessive work relating to tags, only occurring in bzr.dev, appearing at about the same time | 13:26 |
| jelmer | maxb: bzr-svn was recently changed to fetch all revisions referenced by tags, as was bzr.dev | 13:27 |
| spiv | jam: ah :/ | 13:51 |
| spiv | jam: and I think that bzr-svn import has some particularly bad tags | 13:51 |
| jelmer | spiv: which bzr-svn import ? | 13:52 |
| spiv | jelmer: twisted | 13:52 |
| spiv | Actually, not so sure about the tag | 13:52 |
| spiv | tags | 13:52 |
| jelmer | ah, I see | 13:52 |
| spiv | I know the set of branches was a bit confused (because they had some directories of branches inside branches/) | 13:53 |
| spiv | At a glance there's only one tag that looks obviously wrong, 'releases', again I think that's a subdirectory of more tags in the actual svn repo | 13:54 |
| spiv | But then, my local repo doesn't have the revision, neither I guess does the lp repo, so what are all the get_parent_maps about? | 13:56 |
| spiv | tags that are ghosts on both sides should cause one get_parent_map with no result and then give up. | 13:57 |
| spiv | So I wonder which revisions it is checking? | 13:58 |
| spiv | And it's also weird that it doesn't happen on the initial push | 13:58 |
| spiv | And the set of tags that aren't ghosts are the same in lp:twisted and locally | 14:00 |
| spiv | (just 3 of them) | 14:00 |
| spiv | jam: so, I'm still confused! :) | 14:01 |
| vila | jelmer: try 'bzr qblame bzrlib/config.py' around like 285 (which is how I discover the issue) | 14:27 |
| vila | jelmer: something seems wrong in the way you've done this merge :-/ | 14:27 |
| vila | jelmer: and yes, *I* am the one who forgot the pdb.set_trace() (though I doubt it can be triggered now) | 14:28 |
| jelmer | vila: that looks weird indeed, I don't recall ever touching that much in bzrlib.config :-/ | 14:28 |
| vila | jelmer: you didn't, look at the file graph (click the line 285) | 14:28 |
| vila | it's as if you cherry picked my changes | 14:29 |
| vila | jelmer: no big deal, I'm just curious about how you end up with this and where the bug is | 14:30 |
| vila | bzr ? wrong workflow ? In any case if *you* got tricked, many other can probably be to | 14:31 |
| jelmer | vila: I never meant to take credit for your changes.. | 14:31 |
| vila | uneless you did something really exotic | 14:31 |
| jelmer | I'm also not sure what's going wrong there | 14:31 |
| * jelmer tries to remember what sort of workflow he was using there | 14:31 | |
| vila | hehe, no worries, anybody looking at the history will understand that anyway, just one step away | 14:32 |
| vila | and my point is not about who to blame for a bug there ;) | 14:32 |
| jelmer | heh | 14:32 |
| jelmer | vila: I merged another branch which hadn't landed on mainline yet, perhaps that is related? | 14:33 |
| vila | but your commit message says: 'merge bzr.dev' oooh, you mean, you merged my branch while it was processed by pqm ? | 14:34 |
| vila | but then ... annotate is bogus ? | 14:34 |
| vila | urgh, ha, wrong tool, qblame shows a weird graph if the nodes are opened, qlog should know better | 14:35 |
| vila | jelmer: right, so revno 5676.1.4 revid:jelmer@samba.org-20110224160947-e7kqclxnjif28v5q says it merged bzr.dev but there is a single parent there | 14:38 |
| vila | jelmer: cherry-pick ? | 14:38 |
| vila | ovezealous cherry-pick ? ;D | 14:39 |
| jelmer | vila: I never cherrypick from bzr.dev, perhaps there was some other magic I did that went wrong | 14:39 |
| vila | jelmer: anyway, I've fixed the pdb | 14:39 |
| jelmer | don't you mean pb ? :-P | 14:40 |
| vila | jelmer: don't lose time on it, I was just curious | 14:40 |
| jelmer | I'm curious about it now, too :) | 14:40 |
| vila | lol, no, pdb as in 'import pdb; pdb.set_trace()' | 14:40 |
| vila | left-over while debugging a nasty bug | 14:40 |
| jelmer | Anyway, let's keep an eye on similar things in case it wasn't me screwing up a merge. | 14:41 |
| vila | yeah, but a merge with a single parent... my bet is on some switch or something, a forgotten commit, a revert --forget-merge (doubtly) | 14:42 |
| vila | http://babune.ladeuil.net:24842/job/selftest-osx-10.6/174/ and http://babune.ladeuil.net:24842/job/selftest-freebsd/ | 14:43 |
| vila | jelmer: what did you do ? Something bsd-hostile ? While resetting lazy hooks ? | 14:43 |
| vila | jelmer: don't search, the root cause was a transient lp connectivity failure :D | 14:44 |
| jelmer | vila: heh, ok | 14:44 |
| vila | but I had a wtf moment when only freebsd and osx failed with the same 3 tests :D | 14:44 |
| jelmer | vila: I guess that's what we get for connecting to lp from the testsuite >-) | 14:45 |
| vila | jelmer: indeed | 14:45 |
| jelmer | btw, if anybody has a chance to have a look at https://code.launchpad.net/~jelmer/bzr/more-lazy-hooks/+merge/55523 that'd be great; it would mean I can land / propose for merging several other branches | 14:48 |
| vila | jelmer: seems pretty mechanical, will feel better if tests pass on all platforms (running) | 14:54 |
| vila | jelmer: http://babune.ladeuil.net:24842/view/debug/job/selftest-subset-hardy/84/testReport/junit/bzrlib.tests.test_branch/TestHooks/test_constructor/ | 14:59 |
| jam | spiv: I'm still a bit confused myself. But it looks like the initial push pushes up something ~ correct. But then subsequent pushes see "you are missing basis inventories for these extra revisions you pushed" | 15:01 |
| evelyette | hi | 15:18 |
| evelyette | how can I start qbzr module ? | 15:18 |
| evelyette | btw: is these something in bazaar that enables me to have centralized overview on all of my bazaar's repositories ... I'll have more of them on the same computer (an overview over these would be great to have), but an overview over all of the repositories over all of my computers would be great | 15:30 |
| evelyette | it can be tunneled in ssh or something secure | 15:31 |
| evelyette | is that possible ? | 15:31 |
| evelyette | or a better question: does such a tool exist | 15:31 |
| vila | qlog accepts several branches as arguments, some of them can be remote | 15:33 |
| evelyette | well I need more than just a log ... | 15:35 |
| vila | I have no idea what you call an overview :D | 15:35 |
| evelyette | let's say: for now I would only like to know where the gits are located | 15:36 |
| evelyette | so I don't miss some repository when backing up | 15:36 |
| vila | gits ? Did you planned to ask the question in #git ? Anyway, if you need to find where you created branches, there is no such tool to find them for you (except for find(1)). Finding the branches you defined in a given repository is different, 'bzr branches' will tell you. | 15:39 |
| evelyette | sorry ... not gits | 15:40 |
| evelyette | bazaars | 15:40 |
| vila | http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief briefly defines the most often used words in bazaar (it often helps people coming from different backgrounds so we all refer to the same objects) | 15:42 |
| vila | but out of the blue, if you have no idea where your branches are (or need to check where they are), a '.bzr' directory is generally a good indication | 15:43 |
| vila | but I've never heard about a tool to give an overview of all branches (launchpad.net kind of answer the need but it's more than a tool) | 15:44 |
| vila | well, unless you count bzr-explorer which (AIUI) helps you keep track of your branches by defining bookmarks and even providing a view with all of them, but you still have to define them to start with | 15:45 |
| maxb | "All version control objects existing on this computer" does not feel like a useful categorization to me. Why do you care? | 15:45 |
| maxb | For the backup scenario, that's not what you want - there's little point backing up local copies of open source software | 15:46 |
| evelyette | it's not open source | 15:46 |
| evelyette | I would like to have let's say 3 bzr repositories on my computer ... | 15:47 |
| evelyette | but I have to keep track what are their locations | 15:47 |
| vila | repositories or branches and/or working trees ? | 15:47 |
| evelyette | I guess working trees | 15:48 |
| vila | why do you need to keep track of where they are ? | 15:48 |
| evelyette | if someone else joins the group I have to provide them with a link like ssh://bazaar/repo in order to checkout | 15:49 |
| evelyette | so I have to know the path on the remote system of where the bazaar working tree is | 15:50 |
| vila | http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief | 15:50 |
| evelyette | I just read that | 15:50 |
| vila | it's very rare to have working trees on servers | 15:50 |
| vila | especially when all people need to share are branches | 15:50 |
| vila | and you can have a working tree (wt) on a client and the branch on the server | 15:51 |
| evelyette | yes that's what I want | 15:52 |
| vila | depends on your workflow | 15:52 |
| evelyette | sorry for confusion | 15:52 |
| evelyette | so I have to know the location of a branch on the server | 15:52 |
| evelyette | that's what I want to keep track of | 15:52 |
| vila | hmmm, I'm still confused, I have hundreds of branches on my computers organized in several hierarchies and that's good enough to keep track of all of them, what are you searching for exactly ? | 15:54 |
| evelyette | how do you keep them organized | 15:55 |
| evelyette | let's say I have a repositories (branches - whatever) of a project A, B, C ... so they are totally different projects... | 15:55 |
| vila | ~/src/<project> and under that 'trunk' for.. the upstream trunk branch, and them subdirectories named bugs, reviews, experimental, integration, releases, packaging and branches below that or even more subdirectories | 15:56 |
| evelyette | and I create the branches on a remote server in locations /tmp/A, /tmp/B, /tmp/C, and then completely forget about hwo I've set them | 15:56 |
| evelyette | so then after a year I would like to checkthem out (pull from them or whatever), but since I forgot the paths where I've set them, I cannot | 15:56 |
| vila | hmpf | 15:57 |
| vila | bzr log <url> ; bzr info <url>; will give you some hints, but a tool can't replace organization ;) | 15:57 |
| evelyette | that's true | 15:58 |
| evelyette | I just want to check that I'm not doing something stupid, and overcomplicating things | 15:58 |
| evelyette | so the projects are fine the way I described them, I just have to remember the urls | 15:58 |
| evelyette | the paths to them | 15:59 |
| vila | well, use a well defined name space and make evolve with your needs, define one you can reuse with several projects | 15:59 |
| evelyette | I think I'm just gonna create a new folder and have all the bazaars branches in it | 15:59 |
| evelyette | for ALL of the projects | 15:59 |
| vila | host:/<project>/<zero or several meaningful dir names>/branch_name | 16:00 |
| vila | have a look at http://doc.bazaar.canonical.com/bzr.dev/en/tutorials/ | 16:01 |
| vila | or even http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/distributed_intro.html | 16:03 |
| evelyette | thanks | 16:05 |
| evelyette | can you also tell me how can I start bazaar explorer | 16:08 |
| vila | bzr explorer | 16:08 |
| evelyette | I tried, it gives me error | 16:09 |
| evelyette | s | 16:09 |
| vila | 'bzr help explorer' | 16:09 |
| evelyette | http://paste.pocoo.org/show/363233/ | 16:09 |
| vila | meh, file a bug against your distribution, something is borked there | 16:10 |
| vila | I don't use bzr-explorer myself so I don't know exactly which versions are compatible with which, but clearly there is a problem there | 16:12 |
| vila | bzr-explorer uses qbzr which itself relies on Qt and there is a version mismatch here | 16:12 |
| === deryck is now known as deryck[lunch] | ||
| jelmer | "time bzr ls" on a small bzr tree -> from 0.404 in 2.3 now down to 0.207 in bzr.dev | 16:39 |
| vila | \o/ | 16:40 |
| jelmer | mainly due to plugins being able to register their stuff more efficiently (this is with 35 plugins loaded) | 16:40 |
| vila | worth the tedious work ! | 16:41 |
| jelmer | (for the pedantic, those numbers are in seconds) | 16:41 |
| vila | elapsed times too then ;) | 16:41 |
| jelmer | :) | 16:42 |
| jelmer | the other two remaining heavy imports that we should be able to avoid on normal runs are the xml modules and knit repositories | 16:46 |
| vila | jelmer: what is your timing with 'bzr ls --no-plugins' ? | 16:48 |
| fullermd | 'knit' includes knitpack, I presume? | 16:48 |
| jelmer | vila: 0.185s | 16:48 |
| jelmer | fullermd: yes, that's how it gets imported (the 2a repository class is based on the knitpack repository class) | 16:49 |
| jelmer | vila: I get a similar number (0.003 or something like that more) for 2.3 | 16:50 |
| vila | jelmer: worth a small summary on the mailing list so plugin authors get an insight about what lazy loading is about (INHO) | 16:51 |
| vila | meh M | 16:51 |
| fullermd | pack-0.92 you mean? | 16:51 |
| jelmer | fullermd: pack-0.92 instead of which one? | 16:52 |
| fullermd | You said '2a' | 16:52 |
| jelmer | vila: good idea | 16:52 |
| jelmer | fullermd: Yes, I mean '2a' too :) | 16:52 |
| fullermd | So, ANY repo format (well, excluding weave :p) requires loading the knit stuff? | 16:52 |
| vila | for some value of stuff... | 16:53 |
| jelmer | fullermd: and for some value of requires | 16:53 |
| vila | C & C ! | 16:53 |
| vila | damn, never laugh while drinking, or rather drink and *then* read IRC | 16:54 |
| * fullermd falls over, battered and bruised from the tag-teaming. | 16:54 | |
| jelmer | :P | 16:54 |
| vila | :) | 16:54 |
| jelmer | fullermd: so, because of the way imports are structured at the moment any non-weave format ends up triggering the import of bzrlib.knit (and its dependencies) | 16:55 |
| === deryck[lunch] is now known as deryck | ||
| === hunger_ is now known as hunger | ||
| jelmer | lifeless, hi | 20:38 |
| lifeless | hi | 20:41 |
| jelmer | lifeless: did you see my last comment to lp:~jelmer/bzr-search/lazy-xml | 20:42 |
| jelmer | ? | 20:42 |
| lifeless | just been busy | 20:43 |
| lifeless | we've had a couple of very disrupted weeks in lp land | 20:43 |
| jelmer | lifeless: np, I'll ping again a bit later | 20:44 |
| jelmer | I'm not in a hurry :) | 20:44 |
| jelmer | lifeless, (also, kudos on the performance improvements... it's becoming a joy to use lp) | 20:46 |
| rodrigob | hello people in the IRC channel | 20:56 |
| lifeless | jelmer: cool; I can't take much credit - cast of thousands :) | 20:57 |
| rodrigob | the channel seems very silent, is it here where I can ask weird questions ? | 20:57 |
| lifeless | just ask:) | 20:59 |
| rodrigob | I am using bzr with cruisecontrol.rb for automated integration of a web application | 21:01 |
| rodrigob | I have discovered that cruisecontrol.rb has a bug | 21:01 |
| rodrigob | because it assumes that the bzr versions will only increase with each commit | 21:02 |
| rodrigob | but when merging branches | 21:02 |
| rodrigob | the version can increase or decrease | 21:02 |
| rodrigob | so the question is | 21:02 |
| rodrigob | is it there a way to make bzr always make the version number increase ? | 21:02 |
| rodrigob | or put in a different way | 21:02 |
| lifeless | there is an option you can set in the branch's branch.conf | 21:02 |
| rodrigob | ahh | 21:03 |
| lifeless | its in bzr help configuration | 21:03 |
| rodrigob | branch.conf ? | 21:03 |
| lifeless | .bzr/branch/branch.conf | 21:03 |
| jelmer | lifeless: aren't you supposed to be the architect ? ;-) | 21:03 |
| lifeless | jelmer: yes, which means I get to point and guide and take no credit :) | 21:03 |
| rodrigob | which option should it be ? | 21:05 |
| rodrigob | append_revisions_only ? | 21:05 |
| rodrigob | if I had revision 400 | 21:07 |
| rodrigob | and after merge I am at revision 350 | 21:07 |
| rodrigob | how can I get to revision 401 ? | 21:07 |
| rodrigob | (without loosing modifications, obviously) | 21:08 |
| lifeless | rodrigob: cd or switch to the trunk, merge the source branch commit | 21:08 |
| lifeless | merging into a branch never rewinds the revno | 21:09 |
| lifeless | its only when you push from another branch with different left-hand-path that that happens | 21:09 |
| lifeless | yes, append_revisions_only is the option | 21:09 |
| rodrigob | what is left-hand-path ? | 21:09 |
| lifeless | rodrigob: every commit has a list of parents - a merge has 2 (or more), regular commits have just one | 21:10 |
| lifeless | the left hand path is the path through the parents of each commit, following the left hand side only | 21:10 |
| rodrigob | ok I see | 21:11 |
| rodrigob | I do not get the | 21:12 |
| rodrigob | "rodrigob: cd or switch to the trunk, merge the source branch commit" | 21:12 |
| rodrigob | I am at the trunk | 21:12 |
| rodrigob | at revision 350 | 21:12 |
| rodrigob | and before it was 400 | 21:12 |
| rodrigob | when looking at | 21:13 |
| rodrigob | bzr log -l15 -n0 | 21:13 |
| rodrigob | I see multiple merges in the last versions | 21:13 |
| rodrigob | what can I do | 21:15 |
| rodrigob | to get to 401 | 21:15 |
| rodrigob | instead of 351 ? | 21:15 |
| rodrigob | I know my problem is weird | 21:17 |
| lifeless | its straight forward | 21:17 |
| rodrigob | but I am kinda lost with this | 21:17 |
| lifeless | I need to run though - sorry! | 21:17 |
| lifeless | perhaps jelmer is still around and can help out | 21:17 |
| * jelmer wakes up | 21:17 | |
| jelmer | lifeless: thanks for not pointing the lp devs in the wrong direction >-) | 21:18 |
| jelmer | ttyl | 21:18 |
| rodrigob | ttyl ? | 21:19 |
| jelmer | talk to you later | 21:19 |
| * jelmer reads up on rodrigob's question | 21:19 | |
| jelmer | rodrigob, hi | 21:41 |
| jelmer | rodrigob: you'd like to redo the merge so it will be r401 rather than r351? | 21:42 |
| rodrigob | yep | 21:48 |
| rodrigob | how could I do such re-merge ? | 21:48 |
| vila | amazing, I never saw the guy asking the question bringing the one would will answer in his disconnection... | 22:09 |
| vila | . o O (Where are they gone ?) | 22:09 |
| poolie | hi all | 23:29 |
| mr-russ-work | morning. | 23:31 |
| * maxb ponders hardy backport of debhelper | 23:47 | |
| spiv | Hi all | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!