[00:07] * maxb crosses fingers, declares a possible solution to dh_python2 backports, and waits for the build farm to get on with it [00:10] * spiv wonders what's up with https://bugs.launchpad.net/bzr/+bug/745664 [00:10] Ubuntu bug 745664 in Bazaar "Incremental push to stacked branch on LP walks all of history" [Critical,Confirmed] [00:16] maxb: what's your solution? [00:21] jelmer: pretty much what I was outlining this morning [00:21] shim packages that lead to dh_pysupport/central being invoked [00:22] maxb: ah, right [00:22] I hadn't expected you to actually've implemented it since then :) [00:23] hmm, the web UI no longer permits copying packages to jaunty [00:24] does anybody still care about jaunty ? :) [00:26] I think it might be time to officially drop ~bzr/ppa support [00:32] maxb: in favor of up to date distro packages and the daily builds? [00:32] maxb: I think that's sensible, though perhaps we should check with the people currently using it [00:36] oh, I meant drop ~bzr/ppa support for Jaunty [00:36] :-) [00:38] 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:39] gcc errors compiling pyrex .c files [00:46] * maxb has a look at loggerhead recipe conflict [00:51] maxb: r5731 changed that code [00:52] maxb: but the change seems to work on my maverick system [00:53] maxb: although, huh [00:54] maxb: I don't see the *_pyx.c files being regenerated in that buildlog [00:55] maxb: shouldn't pyrex be run at some point? [00:58] maybe [00:58] but, puzzling why it should work on natty [00:58] maxb: http://bazaar.launchpad.net/~debian-bazaar/bzr/unstable-2.4/files/head:/bzrlib/ appears to have stale .c files [00:59] jelmer: Do you know why dulwich-daily is set to exclude karmic? [00:59] 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 [01:00] maxb: it seems weird to me that we don't run pyrex at build time [01:00] maxb: python-pyrex is even listed as a build-depends [01:18] The bzr/daily PPA is doing quite a thorough job of saturating the PPA/i386 buildds right now :-) [01:19] :) [01:30] maxb, wow [01:30] where is that shown? === poolie__ is now known as poolie [01:32] poolie: https://launchpad.net/builders I guess [04:12] where is a good channel to ask about the ‘testtools’ package? [04:13] here, #subunit #testtools [04:13] erm, the last is fiction [04:13] also #python-testing or whatever its called [04:16] lifeless: okay, meet you there? :-) [04:17] bignose: ping me from whatever channel you choose ;) [06:07] hi jam [06:09] last week I started storing my dotfiles in bzr [06:09] now I'd like one dotfile to different between my desktop/laptop [06:10] (different font size in the terminal emulator) [06:10] how can I do that? [06:10] 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:11] lather, rinse, repeat [06:12] * danielsh hopes his explanation is clear enough... [06:13] morning poolie [06:15] hi danielsh [06:16] poolie: morning [06:16] there's a few options [06:16] one would be to make that file a symlink into a machine-specific directorie [06:16] hi jam [06:16] * danielsh (oh, forgot to say, I checked with the latest stable version before I /joined here.) [06:19] unfortunately the file is a plain .ini file, there's no easy way to do 'source `hostname`/foo.conf' or similar [06:20] as to storing all the different versions in the history everywhere, [06:20] that doesn't seem nice, I'm not sure where to start, [06:21] it offloads the problem of diverging changes to me, rather than to the tool, [06:21] I'm not sure that it scales well (think N machines), [06:22] how would you like it to work? [06:23] on laptop: edit file. commit. on desktop: merge that commit while making an edit that the laptop won't try to pull. [06:23] end result: laptop has font size 11, desktop has font size 12, [06:23] 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:24] and I can keep bzr push/pull between them [06:24] (and yes I may run into conflicts sometimes) [06:24] In bzr terms these would all be separate branches [06:24] so you want to make a "don't merge this" commit? [06:24] yes, you could have a separate branch for stuff that is meant to be common [06:24] poolie: I'm not sure what is the bzr term for what I want. [06:24] And when you update the master you'd then merge that into the local branches, but typically not merge the other way. [06:25] 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] so in that case I'd have on each box two branches: [06:25] * the master branch (shared, identical everywhere) [06:25] * a local branch (only pulls from master, never pushes) [06:25] ? [06:26] You wouldn't have to have a copy of master on each box, but it may be convenient to do so. [06:26] correct [06:26] merges from master [06:26] But basically, yes. [06:26] Okay, I see. [06:27] I'd have to propagate changes from ~/.foorc to ~/master.bzr/foorc manually, though [06:27] jam i wonder if i can just do without or give an option to do without it [06:27] i agree it is a bit ugly [06:27] (or cherry-pick them..) [06:28] spiv, poolie: thanks for discussion, I've learnt something :-) [06:29] 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] sure :) [06:29] i was a bit surprised to see you [06:35] jam: I'm sorry if you feel unhappy about my backing out the lp-runs-loggerhead tests [06:36] jam: I hope I've explained well enough on the bug, but if not I'm happy to discuss further here [06:45] jam, it turns out it is happy without the blankline markers [07:26] hi all ! [09:00] hi vila [09:00] 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] right now, I have to finish moving out of the apartment, though [09:01] So maybe late tonight (early your morning, I think) [09:01] hey jam ! [09:01] jam: please do take up that push regression, that'd be great [09:01] jam: good luck with your move, don't break too many things ;) [09:01] jam: and enjoy your new place ! [09:02] * spiv → afk [09:04] thanks vila [09:04] have a good evening spiv [09:04] vila: I would enjoy it more if we had furniture [09:05] 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] so they want to charge us as though we are bringing it to sell, or something. [09:05] jam: naaah, give a try to a more zen-like attitude, just sell your stuff ! [09:05] and by default, online statements only go back 12 months from today [09:05] which doesn't go back to Jan, 2010 [09:05] vila: right. Of course, sleeping on hardwood floors is the real Zen challenge [09:06] jam: welcome to Europe :D [09:06] jam: ugh [09:06] . o O (Keeping the balance between sarcasm and true compassion is hard) [09:06] hiya vila, jam [09:06] poolie: heya ! [09:06] jam: sure, can chat whever [09:07] We could get a hotel room, but extended hotel room stays and 3-year olds don't go very well together. [09:08] 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] hey poolie [09:09] :) [09:09] 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:11] 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:12] the cars were pretty big [09:12] oh and the guns [09:12] and the food [09:12] poolie: but not particularly bigger than elsewhere in the US [09:12] we have the statement *in the US* that "Everything is bigger in Texas" [09:12] I guess the Hats are usually bigger [09:12] yeah, and Queensland is bigger than Texas :) [09:15] vila, i may be just missing the point, but the config stuff seems eminently split-able [09:15] poolie: except for the deployment part... [09:15] may be *I'm* missing the point :) [09:15] for instance we can add a better api without changing anything much else [09:16] the sore point is BranchConfig and its relationship with remote configs [09:16] so may be I should just start with GlobalConfig... [09:18] why is it sore? [09:20] 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:21] and the various classes involved starting from BranchConfig and including TreeConfig, TransportConfig BzrDirConfig [09:24] 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] one option is to use *new* file names, but this means updating the docs and our user brains (the later being far harder ;) [09:25] but neither being cheap [09:25] so I feel more comfortable landing the new features well tested but not used and *then* focus on the migration [09:26] my last failed attempt has been to address bug #491196 :-/ [09:26] Launchpad bug 491196 in Bazaar "want a way to set configuration options from the command line" [Medium,Confirmed] https://launchpad.net/bugs/491196 [09:27] the proposed design makes it trivial, but only after deploying the new design... [09:28] hm [09:28] 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] but i guess the proof is in actually trying to do it [09:29] yeah, I share*d* the feeling :-/ [09:34] Have a look at ConfigStack in iconfig.py in lp:udd: I needed a ugly hack to get usable ConfigStack [09:36] 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] s/if I fear/I fear/ [09:37] if hasattr(c, 'get_user_option') and not hasattr(c, 'get'): [09:37] c.get = types.MethodType(compatible_get, c, c.__class__) [09:37] i saw that [09:37] is the ugly hack I'm referring to: it injects a bound method [09:38] what's the main motivation for expansions? [09:38] may be it's a useful technique to handle compatibility if we can find clearer helpers to use it, but... [09:39] push_location = lp:~{launchpad_unsername}/{project}/{nick} [09:40] bzr.xxx.action = {script} with {script} being 'ask' for interactive use and True/False otherwise [09:40] more generally sharing more default values [09:40] by allowing references [09:41] and where does that get set? [09:41] it just seems strange to add it before doing the other refactorings [09:42] expand you mean ? I'm already using 'bzr push `bzr config mypush`/`bzr nick`' quite often [09:42] yeah, i meant internal expansion [09:42] i'm not complaining [09:42] it may sound like i am :) [09:42] well, more than quite often in fact, almost always [09:42] i just cared more about -Ofoo [09:42] no no [09:43] hehe, mee too :D [09:43] oh, and expand is good for command templates or log templates as seen recently on the ml [09:44] the main limitation actually is the single config scope [09:44] which can't be addressed without ConfigStack [09:45] I'm pretty sure we also have as-yet un-triggered bugs when remote configs are involved [09:45] like: what if I define a bazaar.conf and a locations.conf on a server [09:46] do we have the same behavior between smart and dumb servers ? [09:46] I suspect nobody tried to fiddle with that so far ;) [09:47] and I'm in no hurry to open the can of worms ;) [09:48] but abentley raised 'control.conf' used by launchpad and.... that's another can of worms... [09:51] 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] ok [09:52] but trying to address them *now* and finding the minimal path to get one them fixed... I failed [09:53] so I finally concluded that this was too hard and that I should try a different approach, hence the proposal [09:54] 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:55] on the other hand, I don't want to end up with a massive >2000 proposal either [09:56] 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] yeah [09:56] i think this will fix things [09:56] fix many bugs [09:56] oh, and I forgot about resolve default actions too for udd [09:56] i am just desirous of smallers proposals along the way [09:57] +1 [09:57] the plan is to propose the various classes, well tested, one by one [09:57] preparing the deployment as best as I can doing that [09:58] another sore point has been the infamously long review of doxxx regarding mergetools (which was also a motivating factor for expand) [09:59] as was abentley appendir proposal [09:59] (and still is since he's still blocked because we don't provide a solution for his need) [10:00] 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:02] 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:04] I don't think I invented too many new concepts there and I tried to think hard about trivial basis implementations [10:04] now I need some code to verify that the design is sound or I may as well keep thinking about it for years [10:05] 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:06] vila: Windows works just fine with env vars "set foo=bar" [10:06] however, it is a bit hard to get to from Guis [10:06] jam: tell that to my mom... [10:07] I mean, for most users the workflow just never involves being able to 'set foo=bar' [10:07] they want something in a file [10:07] even 'bzr -Ofoo-bar xxx ...' won't work for them [10:07] mm [10:08] we should just define options that have an environment variable as a way to set them, but also a regular name [10:08] anyhow, that's enough for me for today [10:08] jam, thanks for the reviews [10:08] i might add tests for some of them tomorrow [10:08] i may be being a bit lazy [10:08] poolie: right, but what's the point of having both 'foo=bar bzr ...' *and* 'bzr -Ofoo=bar ...' ? [10:09] things like 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] vila, if we could handle everything through the second case i think the first would be unnecessary in almost all cases [10:09] poolie: +1, not worth the trouble to add a test [10:09] it does have one advantage which is that it inherits [10:09] oh, good point [10:09] ie you can set the plugin path in your .bash_env [10:10] may be -O should propagate to subprocesses ;D [10:10] plugin_path is trickier (as are some other options) [10:11] vila: other than being able to do "export BZR_FOO=bar" and have it valid for the lifetime of your session [10:11] i mean you can set it in the shell and it will pass through emacs down to bzr [10:11] for instance [10:11] I'm contemplating a [__init__] section in bazaar.conf :D [10:11] -Ofoo=bar doesn't persist [10:12] jam: sure, but that still doesn't work for windows newbies [10:12] i.e. the ones that don't know how to setup env vars for their session [10:12] 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] anyhow [10:12] jam: indeed, but they still want to set some default values [10:12] let's try to get there [10:13] i'll try to comment on your api examples tomorrow [10:13] 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] ok [10:13] *my* point is just that "no env vars" isn't somewhere we actually want to be [10:13] we might want fewer [10:13] but I don't think that value is 0 [10:13] poolie: have a good evening [10:13] we want a way to have per-process settings that don't use the environment [10:14] 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] that's the main reason people would add them today [10:14] agree with that [10:14] (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] vila: which is what I was rebutting. It sounds like we agree [10:14] jam: yeah, re-read it with ... yeah [10:14] badly phrased [10:15] err, is 'phrased' english ? formulated ? expressed ? [10:15] vila: phrased or expressed [10:15] "we don't want to require users to use env vars" [10:16] would be a better way [10:16] vila: stuff like default plugin path, etc, certainly belongs in a config. Though being able to override it easily gets tricky [10:17] 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:18] 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] jam: and until then, I won't delete BZR_PLUGIN_PATH, BZR_DISABLE_PLUGINS and BZR_PLUGINS_AT :D [10:19] but these aren't the most pressing bugs either [10:20] 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:21] lifeless: funnily enough, all of the mentioned areas will benefit from that by making changes easier to implement [10:29] 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] lifeless: and you're damn right there [10:30] 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] lifeless: bzr config foo=bar ? [10:30] yeah [10:30] lifeless: try bzr/2.3 [10:31] with a bunch of limitations so far [10:31] what I mean [10:31] is I don't see the connection from that to e.g. the importer [10:31] bug #719888 and the hurdles to test locally [10:31] 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:32] or a better way to specify options for imports on a package, series, pocket basis [10:33] or the ability to specify post-merge resolve actions on a dir/file basis in a persistent way [10:33] uhm [10:33] these still don't seem connected [10:34] to config foo=bar [10:34] I'm not saying they aren't nice [10:34] I just don't understand the relevance [10:34] for instance [10:34] LP has configuurable log dirs [10:34] and doesn't have a tool to set config variables [10:35] we aim at making all options be specified either in a config file or from the command line [10:35] config files providing various ways to set default values for various contexts [10:35] you're describing a design [10:36] what problem are you solving [10:36] so either you set the option in a config file or you specify it from the command line [10:36] and how is that problem relevant to the importer [10:36] the losa want a way to decide where the log files are stored, the importer should respect that [10:36] [meta: I don't mean to criticise :- but I don't understand the links, and I suspect other observers also won't.] [10:37] the log dir was a hard-coded constant [10:37] vila: could they not just edit ~/.bazaar/bazaar.conf [10:37] lifeless: only if the code even try to look there [10:37] which it wasn't [10:38] ok, so perhaps if I now draw a comparison: [10:38] A: implement a system to do arbitrary config option setting [10:38] 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] maxb: those bzr-git test failures are due to an old dulwich [10:38] B: Fix the packaging importer code to ask global config for theoption [10:38] vila: ~/.bazaar/bazaar.conf doesn't need to be in said branch, does it ? [10:39] jelmer: Ah, hi. I wanted to ask you what you thought about migrating from cdbs to dh7 for dulwich and subvertpy [10:39] lifeless: if you keep a default value in the scripts, no [10:39] 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] vila: I don't understand why a default value would be needed [10:40] maxb: Hmm, I thought I already did that [10:40] as in, config = GlobalConfig(); logfir = config.get_user_config('pkg importer log dir') [10:40] lifeless: to keep track of what options need to be defined [10:41] vila: you've just switched problem statements I think. [10:41] vila: you said 'the losa want a way to decide where the log files are stored, the importer should respect that' [10:42] jelmer: Not for those two, apparently (dh_python2 yes, dh7 no) [10:42] maxb: ah, just not pushed [10:42] jelmer: I love it when fixes are that easy :-) [10:43] 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] lifeless: going there incrementally without a perfect knowledge of the scripts (which I haven't) requires some care [10:44] vila: let me ask a different way [10:44] how many constants did you want to change in the package importer [10:44] and/or how many constants did you see? [10:44] 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] lifeless: roughly 20 say [10:45] really? [10:45] yeah [10:45] 20 *different unrelated log dirs* ? [10:45] nooo [10:46] there was one log dir that also contained the files served with apache [10:46] we now have to different base dirs for that [10:46] ok [10:47] so thats 2 [10:47] how does that connect to 'config foo=bar' [10:47] lifeless: http://paste.ubuntu.com/587731/ [10:47] part of icommon.py imported by all scripts [10:48] oh wait, let me add some lines there: http://paste.ubuntu.com/587733/ [10:48] so, yes, the dirs are created unconditionally [10:49] but the log dir itself now contain two more dirs 'driver' and 'packages' which are create more lazily [10:49] create*d* [10:49] ok, but again [10:49] how does this connect to a command line tool to write config files to disk [10:50] it seems to me that: [10:50] - using global config [10:50] err, modify a config file you mean ? [10:50] - reading 2 or 3 values from there [10:50] - and then putting them in as the relevant base dirs while you split things apart [10:50] right, that's the final plan [10:50] would meet the losa constraint [10:51] an incremental step has been to introduce pkgimporter.conf: http://paste.ubuntu.com/587734/ [10:51] I feel like I'm not connecting on this [10:51] it must be frustrating you [10:52] no, no, go ahead, I appreciate [10:52] so I'll put it directly [10:52] it seems like a 2-3 hour direct and simple change [10:52] became a large scale software engineering problem [10:52] aka [10:52] overengineering [10:53] I can understand that [10:53] thats *perception* [10:53] but I didn't spent as much time in it as it may seem [10:53] I've been *thinking* about that for a long time, but I don't account my in-bed-thinking as work time ;) [10:54] 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] vila: the thing that is confusing [10:55] is that you say 'bzr config foo=bar' is connected to improving the importer [10:55] and I don't understand that at all [10:56] oh, sorry, no I was replying to 'can we set that from the command line' [10:57] 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] hand [10:57] vila: ok; so why is that more complex than 'read the options from bazaar.conf' [10:57] and using bazaar.conf wasn't adequate [10:57] ha, [10:58] because I didn't want the definition and the (unclear yet) dependencies to disappear from the branch [10:59] so maybe it's overcautious rather than overengineering ;) But maybe both... [11:00] vila: so rather than leave the old value commented #was foo=bar\nfoo=config.get_user_option('pkg_importer_foo') [11:00] lifeless: keep in mind that I *learned* about which files were served over http while addressing the log issue... [11:00] you built a bunch of infrastructure [11:00] hi [11:00] which one ? [11:00] vila: well, the bzr config foo=bar that you mentioned [11:00] evelyette: hi [11:01] does bazaar have a plugin which scans for file modifications in certain folder and updates the tree automatically [11:01] kindda like inotify in linux [11:01] lifeless: oh no, that was already built, I didn't built it for the importer [11:02] evelyette: I think someone built something to do that (using inotify) [11:03] lifeless, I would very much like to use that: can you tell me more, maybe provide a link ? [11:03] 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] evelyette: sorry no, google can tell you all I can [11:03] evelyette: Its just a vague memory [11:05] vila: so to backtrack; you say that the package importer will be easier to write with the config overhaul; whats the connection ? [11:05] :) [11:07] http://paste.ubuntu.com/587734/ [11:07] and then tester just have to override pkgimport.base_dir [11:08] 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:10] I can see it being useful [11:10] 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:12] 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:13] vila: fwiw I would just have kept the relative defn's relative and defined two variables in configs [11:13] 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] ok just git then [11:13] svn is crap :) [11:13] vila: by preference I mean - I find overly parameterisable code gets harder to maintain and permits config bugs [11:13] lifeless: yeah, and use makedirs instead of mkdir, but there is still the risk to create dirs in the wrong place etc [11:14] lifeless: indeed ! [11:14] lifeless: which means the true and perfect solution is to re-design the importer scripts which I don't want to do ;) [11:15] 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] vila: well, you can treat the current structure as being only configurable to the extent you add it [11:15]