| jelmer | Noldorin: how is it failing exactly? | 00:01 |
|---|---|---|
| glyph | jelmer: was my earlier summary accurate | 00:01 |
| Noldorin | jelmer, it doesn't import the module from site-packages | 00:02 |
| jelmer | glyph: yes, although I should note that only newer twisted revisions were imported with newer versions of bzr-svn on launchpad | 00:02 |
| jelmer | Noldorin: what module is it failing to import? | 00:03 |
| jelmer | Noldorin: and how is it doing that, do you have a traceback? | 00:03 |
| glyph | jelmer: hrm | 00:03 |
| jelmer | glyph: so perhaps it's better to be safe than sorry and redo the launchpad imports | 00:03 |
| glyph | jelmer: is there a way to explicitly refresh that? | 00:03 |
| glyph | and is launchpad on bzr-svn 1.1.1 yet? | 00:03 |
| Noldorin | jelmer, nothing. just says "cannot importy module" | 00:04 |
| Noldorin | no traceback sorry | 00:04 |
| jelmer | Noldorin: .bzr.log should have a traceback | 00:04 |
| jelmer | glyph: yes, it's post-1.1.1 | 00:05 |
| Noldorin | jelmer, okay just a sec | 00:06 |
| glyph | jelmer: I guess the way to fix it is just to do the re-import somewhere else, then 'bzr push --overwrite lp:twisted'? | 00:10 |
| spiv | jelmer: +1 to getting launchpad to redo that import | 00:11 |
| jelmer | glyph: we'll have to do it via Launchpad, as import branches are only writable by the importds | 00:11 |
| jelmer | glyph: I can look into getting that done | 00:11 |
| glyph | jelmer: so there's no button for me to press, then | 00:11 |
| jelmer | Noldorin: any luck? | 00:33 |
| jo-erlend | in my Python script, I'd like to check the status of a given folder, such as if there are uncommitted changes, unknown files, etc. What is the best way to do that? | 00:33 |
| jo-erlend | I've been told there are bzr tools for Python, and that sounds nice. If anyone has a link to docs, I'd appreciate it. | 00:34 |
| jelmer | jo-erlend: you probably want to use the working tree | 00:34 |
| jo-erlend | jelmer, I don't understand what you mean by that. | 00:34 |
| jelmer | jo-erlend: from bzrlib.workingtree import WorkingTree; w = WorkingTree.open("."); print bool(wt.changes_from(wt.basis_tree())) | 00:35 |
| jo-erlend | sounds nice. Any docs for it? | 00:35 |
| jelmer | jo-erlend: http://people.canonical.com/~mwh/bzrlibapi/bzrlib.workingtree.WorkingTree.html | 00:36 |
| jo-erlend | I guess I'll just run bzr st and check the status myself. I don't even understand how to begin using that stuff, and the only thing I need is to see if a folder has any changes. I don't need to do anything about it. | 00:43 |
| jelmer | jo-erlend: the fragment I pasted earlier should give you a boolean that indicates whether anything has changed | 00:44 |
| jo-erlend | oh. That was easier than it looked. :) | 00:52 |
| jo-erlend | thanks. :) | 00:52 |
| Noldorin | jelmer, yeah just testing | 01:00 |
| jo-erlend | jelmer, that feature isn't documented, though? | 01:00 |
| jo-erlend | I can do w.unknowns to get unversioned files, but I don't understand how I can see if files are modified. I also can't figure out how to find out what WorkingTree.changes_from does. | 01:03 |
| Noldorin | jelmer, what's an easy way to check if bzr-git has loaded correctly? | 01:04 |
| jelmer | jo-erlend: the fragment I posted should tell you if there are any modifications since the last commit | 01:06 |
| Darxus | "bzr: ERROR: No module named apt_pkg" - https://launchpadlibrarian.net/85223456/buildlog.txt.gz | 01:06 |
| Darxus | From https://code.launchpad.net/~spamassassin/+recipe/spamassassin-daily | 01:07 |
| Darxus | Bulding is failing again.... | 01:07 |
| jo-erlend | jelmer, yes, I understand that. I'm having difficulty finding out how to see if I already know that a file is unversioned or not, for instance. | 01:07 |
| jelmer | Darxus: there is work going on to fix that | 01:07 |
| Darxus | jelmer: Thanks. | 01:07 |
| jelmer | jo-erlend: it will only return versioned files, so only files that are not in .unknowns() | 01:07 |
| Noldorin | jelmer, ? | 01:08 |
| jo-erlend | oh, I see. Thanks. | 01:08 |
| jelmer | jo-erlend: See Tree.changes_from() for the documentation ("pydoc bzrlib.tree.Tree.changes_from") | 01:08 |
| jelmer | Noldorin: "bzr plugins" | 01:08 |
| Noldorin | jelmer, that displays fine even if dependent modules didn't load though | 01:09 |
| jelmer | Noldorin: it means the basic bits of bzr-git have loaded though | 01:11 |
| jelmer | Noldorin: if you want to make sure *all* of bzr-git works, run the bzr-git testsuite | 01:11 |
| Noldorin | jelmer, yes but it won't tell me if dulwich loaded | 01:11 |
| Noldorin | jelmer, which is what i want to find out | 01:11 |
| Noldorin | very simply | 01:11 |
| jelmer | Noldorin: any sort of operation involving a git repository should load dulwich | 01:12 |
| Noldorin | got it | 01:13 |
| Noldorin | jelmer, here's the error: | 01:13 |
| Noldorin | bzr: ERROR: Unsupported protocol for url "git://": Unable to import library "dulwich": bzr-git: Plea | 01:13 |
| Noldorin | se install dulwich, https://launchpad.net/dulwich | 01:13 |
| Noldorin | jelmer, when dulwich is a symlinkd rather than real dir in site-packages/ | 01:14 |
| Noldorin | that happens | 01:14 |
| jelmer | Noldorin: right, but what about the traceback (in ~/.bzr.log) ? | 01:14 |
| jelmer | Noldorin: we just use "import" from python to load dulwich, so that's all inside of Python itself | 01:14 |
| Noldorin | oooh | 01:14 |
| Noldorin | i see | 01:14 |
| Noldorin | got it | 01:15 |
| Noldorin | jelmer, http://pastebin.com/cXdaVkpL | 01:15 |
| jelmer | hmm, that's masking the actual error | 01:16 |
| Noldorin | jelmer,yeah... | 01:16 |
| jelmer | Noldorin: can you try adding "import dulwich" to bzr-git's __init__.py ? | 01:17 |
| Noldorin | jelmer, same | 01:18 |
| jelmer | Noldorin: the traceback in ~/.bzr.log should be different | 01:18 |
| Noldorin | oh yes | 01:18 |
| Noldorin | jelmer, http://pastie.org/2870011 | 01:18 |
| jelmer | Noldorin: right, python's import doesn't find dulwich | 01:19 |
| Noldorin | yeah | 01:20 |
| Noldorin | so python's import doesn't like symlink dirs basically? | 01:20 |
| Noldorin | because it finds it fine when it's a normal dir | 01:20 |
| jelmer | Noldorin: it seems happy with symlinks on Unix, perhaps it's different on Windows? | 01:22 |
| Noldorin | jelmer, perhaps | 01:23 |
| Noldorin | i've updated the python bug i submitted about it | 01:23 |
| Noldorin | originally i was confused about what i tested | 01:23 |
| Noldorin | http://bugs.python.org/issue13412?@ok_message=msg%20147744%20created%3Cbr%3Eissue%2013412%20message_count%2C%20messages%20edited%20ok&@template=item | 01:23 |
| Noldorin | jelmer, ^ | 01:23 |
| Noldorin | jelmer, i'm off now, but feel free to investigate it more and ping me later :-) | 01:23 |
| Noldorin | ciao | 01:24 |
| jelmer | Noldorin: sorry, I'll leave that up to the Python folks | 01:25 |
| Noldorin | jelmer, that's fine. i only said that in case you thought it might be something specific about bzr :-P | 01:26 |
| Noldorin | jelmer, if you think it's a generic issue, my bug should take care of it | 01:26 |
| Noldorin | ta ta | 01:26 |
| poolie | hi vila? | 06:31 |
| vila | poolie: hey ! | 07:51 |
| jam | morning all | 08:12 |
| poolie | hi jam | 08:15 |
| jam | hi poolie | 08:22 |
| jam | you've been quite active on email after being gone :) | 08:22 |
| poolie | oh, really? | 08:26 |
| poolie | i was only gone for a day | 08:26 |
| poolie | i do feel like i've been having a good few weeks though | 08:26 |
| poolie | jam anyhow i battled with buildds and ec2 today | 08:31 |
| poolie | and i haven't actually touched memory usage :/ | 08:31 |
| poolie | so i don't have much to say | 08:31 |
| poolie | other than that i'm glad i was heading in the direction you described | 08:31 |
| jelmer | 'morning | 09:02 |
| mgz | morning all | 09:21 |
| poolie | hi mgz, jelmer | 09:25 |
| jo-erlend | when I branch from some place, work on my new branch and commit to it before merging with the branch I branched from ... Will the details of the commits to my branch be visible in the other one, or will it be treated as a single commit? | 10:23 |
| bob2 | yes and no, though bzr log will by default only show the merge | 10:24 |
| mgz | you get the best of both worlds :) | 10:24 |
| jo-erlend | what exactly does that mean? | 10:24 |
| bob2 | yes the data of every commit ever is visible | 10:25 |
| mgz | the information is kept, but the default view only shows the 'mainline' | 10:25 |
| bob2 | no by default 'bzr log' will not show the branch merged in, just the merge commit | 10:25 |
| jo-erlend | oh, ok. I'll need to consider my personal comments, then :) | 10:39 |
| mgz | that's good general advice :) | 10:40 |
| mgz | weird failures ;_; | 11:10 |
| mgz | the problem with the windows bot being red for so long is I have no idea which of these are due to path escaping changes | 11:14 |
| vila | mgz :-/ | 11:44 |
| mgz | vila: just posted summary in bug 842223 mp | 11:58 |
| ubot5 | Launchpad bug 842223 in Bazaar "Change to tilde escaping causes test failures" [High,In progress] https://launchpad.net/bugs/842223 | 11:59 |
| mgz | maybe just something went wrong with the building of extensions on babune? | 11:59 |
| mgz | I don't think I caused them at any rate, so this branch can probably still land | 12:00 |
| mgz | and the last main windows babune build got through without bailing trying to remove a shell script, which is great | 12:01 |
| * vila reads | 12:01 | |
| vila | so, summary, this should land and I should check the extensions build on babune right ? | 12:03 |
| mgz | I think so. | 12:03 |
| mgz | this was using /debug/ not /Windows/ | 12:04 |
| mgz | and we've not touched debug in a while. | 12:04 |
| vila | right, but the /debug/ job rebuilt some extensions, nothing suspicious there | 12:06 |
| vila | or is it ? | 12:06 |
| vila | mgz: ^ ? | 12:16 |
| mgz | the rebuild in itself isn't suspicious, I started at an older revision, so there were pyrex source updates in between | 12:18 |
| * mgz downloads the log to have a look too | 12:19 | |
| vila | which are indirectly reflected by the compilations | 12:19 |
| mgz | there's an error from make saying format incorrect de paramétre | 12:23 |
| mgz | probably not relevent | 12:23 |
| vila | yeah, bogus mount, spurious AFAICT | 12:24 |
| * mgz notes for future reference, altgr+; e | 12:24 | |
| vila | hehe, no, that's an agrave accent not an acute one ;) | 12:25 |
| mgz | dammit, I had that first | 12:25 |
| mgz | altgr+#, e -> è then | 12:25 |
| vila | yup | 12:25 |
| mgz | and the mystery of the vanishing bug 842233 failures is resolved | 12:26 |
| ubot5 | Launchpad bug 842233 in Bazaar "InvalidURL from tests for local_path_from_url on windows" [Medium,Confirmed] https://launchpad.net/bugs/842233 | 12:26 |
| mgz | the end of the log is "lost connection" | 12:26 |
| vila | I've lost altgr on my keyboard long ago anyway so feel free to not type accents ;) | 12:26 |
| mgz | so they weren't run | 12:27 |
| vila | ha | 12:27 |
| vila | good ? :D | 12:27 |
| mgz | would be nice if babune clearly distinguished between "all tests run, some failed" | 12:27 |
| mgz | and "stuff went seriously wrong" | 12:28 |
| vila | shouldn't subunit handle that ? 'lost connection' comes from there no ? | 12:28 |
| mgz | I never remember to look at the test count, and it's not immediately obvious | 12:29 |
| mgz | well, subunit doesn't help, certainly. | 12:29 |
| mgz | ææßßððAaaseaphews | 12:34 |
| mgz | I see why you removed altgr now | 12:34 |
| mgz | I just got stuck in an alternate land where my input made only funky characters | 12:34 |
| vila | hehe, I *lost* it and since I use it very rarely I didn't notice ;) | 12:35 |
| vila | it seems to be bound to alt now | 12:35 |
| poolie | :) | 12:41 |
| poolie | i like the cømpose key | 12:41 |
| vila | right, that the one I should use :) | 12:42 |
| jo-erlend | are commit messages used for anything other than telling other humans about a project? I've noticed that some people seem to use a very formal commit "format", whereas I just write the stuff I've done. | 13:13 |
| vila | jo-erlend: some humans use conventions to communicate ;) But really they are just conventions. Unless a project use higher level tools to process these commit messages, they are just strings as far as bzr is concerned | 13:16 |
| mgz | jo-erlend: it's a social issue, generally you want to fit in with what the project you're contributing to does, or if its your own project make up the rules | 13:16 |
| mgz | for instance, in bzr itself, | 13:16 |
| mgz | people do commit messages in feature branches however they want, | 13:16 |
| mgz | but then when our automated lander merges the feature to the main branch it adds the committer and proposer to the commit message which by convention is a one sentence overview | 13:17 |
| mgz | using the structured stuff for commit like --fixes and --author is better than munging those into the message | 13:18 |
| mgz | if you're writing "patch from X fixing bug N" then you're doing something wrong in my view :) | 13:19 |
| jo-erlend | is fixes just a label, or is it linked to a bug tracker? | 13:20 |
| mgz | it's stored as aURL | 13:22 |
| jo-erlend | oh, ok. | 13:32 |
| jo-erlend | but I guess it has better understanding for bugs stored in launchpad? | 13:33 |
| jelmer | mgz: hi | 13:36 |
| jelmer | mgz: just looking at your recent comment | 13:36 |
| jelmer | mgz: the new behaviour seems right to me | 13:36 |
| mgz | jelmer: yeah, but does show that I didn't succeed in getting the exact tilde handling as before | 13:38 |
| mgz | only having to change one test isn't too bad, I just fear other fallout | 13:38 |
| mgz | jo-erlend: launchpad itself has some special integration, and I think some other bug tracker software has some too | 13:38 |
| mgz | eheh, jam's comment on pylzma is funny | 13:40 |
| vila | mgz: I've seen cases where tests were *enforcing* a bug | 13:41 |
| jam | mgz: well, you've submitted 3+ times now I think, and nobody gets a failure message :) | 13:45 |
| mgz | I seem to have accidentally broken the access restrictions on my home bzr+http server | 14:17 |
| mgz | not a bad thing right now, as I wanted to test against a remote http repo | 14:17 |
| === aj00200_ is now known as aj00200 | ||
| jelmer | mgz: I've updated switch-colocated to include tests for unicode colocated and other branches | 14:46 |
| jelmer | that also involved using "real" branch names rather than url encoding for the "sibling" branch support in switch | 14:47 |
| jelmer | vila: any plans for Branch._get_store() ? :) | 14:49 |
| vila | huh ? Shouldn't be needed, what's the use case ? | 14:49 |
| jelmer | vila: ah, hmm. I guess Branch._get_config_stack() then? | 14:51 |
| jelmer | or Branch.get_config_stack() | 14:51 |
| vila | we already landed that no ? :) | 14:51 |
| jelmer | right :) | 14:51 |
| jelmer | I guess we'll just need a custom RemoteBranch.get_config_stack() implementation which uses RemoteBranchStore or something similar | 14:51 |
| vila | right, there is already a RemoteBranchStack | 14:53 |
| vila | jelmer: do you encounter a issues with it ? | 14:53 |
| jelmer | I'm seeing VFS access over HPSS from BranchStore | 14:54 |
| jelmer | vila: RemoteBranch.get_config_stack() returns _mod_config.BranchStack(self) | 14:54 |
| vila | right, RemoteBranchStack is a bit hackish, let me find the relevant comment | 14:55 |
| jelmer | vila: also, RemoteBranchStack still uses BranchStore so presumably will involve VFS calls too | 14:55 |
| vila | if you use the old config scheme you also trigger VFS calls | 14:56 |
| vila | this should be better once http://pad.lv/832042 is fixed | 14:57 |
| ubot5 | Launchpad bug 832042 in Bazaar "config files are read for each option" [High,In progress] | 14:57 |
| vila | +# Needed for 'stacked_on_location' *only* which use a hack that could be | 14:58 |
| vila | +# removed when each config file is read only once. This stack is not yet used | 14:58 |
| vila | +# in branch.py -- vila 2011-09-06 | 14:58 |
| jelmer | ah, thanks | 15:01 |
| jelmer | vila: btw, that bug is in progress but not assigned? | 15:01 |
| vila | hehe, I was angry :) | 15:01 |
| vila | jelmer: fixed (or rather assigned ;) | 15:03 |
| jelmer | vila: :) | 15:04 |
| vila | not sure yet if I should finish migration options before or after fixing it | 15:05 |
| vila | s/migration/migrating/ | 15:05 |
| jelmer | vila: after, IMO. we shouldn't really be adding more VFS calls | 15:07 |
| vila | I don't think we added some so far ? | 15:08 |
| jelmer | vila: Branch.get_config() doesn't use VFS calls AFAIK, but Branch.get_config_stack() does | 15:08 |
| vila | but the remote config stuff is one of the most confusing so I may have miss a case | 15:08 |
| jelmer | vila: also, it's nice to have the design (including lokcing, etc) of the config stacks finished before we start using it in anger | 15:08 |
| vila | locking should be ok | 15:09 |
| vila | ha, looking at remote.py, right, not a VFS but still a request so in the end, it will be a single VFS instead of at least one request per option | 15:10 |
| jelmer | vila: I mean locking in combination with not reading/writing config files for every option touched | 15:10 |
| jelmer | vila: plus the overhead of enabling VFS mode | 15:11 |
| vila | oh, that, right | 15:11 |
| vila | if I'm not mistaken, the actual behavior for remote objects is to query the config for each option (without caching it) so doing a single VFS call will be a win | 15:13 |
| vila | as for locking, we are already under a branch lock so we reuse it | 15:13 |
| vila | i.e. at worst, even today, we do one VFS call instead of a query and in the end, we'll get rid of the queries | 15:14 |
| jelmer | vila: but we should be moving away from VFS calls, not introducing new ones | 15:15 |
| vila | one step at a time :) | 15:15 |
| vila | once we know which VFS calls are still needed, we can turn them into queries | 15:15 |
| jelmer | vila: sure; I'm just saying I don't think we should be switching to config stacks while they're introducing more VFS calls | 15:16 |
| vila | or reuse the existing ones (but that sounded too hairy last time I looked) | 15:16 |
| vila | jelmer: what do you propose then ? | 15:16 |
| jelmer | vila: adding a HPSS call for branch stores | 15:16 |
| vila | premature design, the needed calls will be fully defined when all the options are migrated | 15:18 |
| vila | and *requiring* HPSS calls will break backward compatibility with older servers | 15:19 |
| jelmer | vila: that means introducing more VFS calls until all options are migrated, I really think that's a bad idea. | 15:19 |
| jelmer | vila: I didn't say anything about requiring HPSS calls. Just about not relying on VFS calls. | 15:19 |
| vila | *one* VFS call by store instead of one query by option | 15:20 |
| jelmer | vila: who says we can't have a VFS call for retrieving the stack contents? | 15:20 |
| jelmer | s/VFS/HPSS/ | 15:20 |
| vila | the point is to reduce the queries, VFS or not | 15:20 |
| vila | backward compatibility for older servers | 15:20 |
| vila | you can't switch to stacks using HPSS calls *only* | 15:21 |
| jelmer | sure, either way we'll still support falling back to VFS if the serve doesn't support newer calls like we do with all HPSS calls | 15:21 |
| jelmer | *server | 15:21 |
| vila | HPSS calls are worth only if they replace *several* VFS calls, it doesn't matter here | 15:22 |
| jelmer | vila: eventually we want to get to a VFS-free HPSS server | 15:22 |
| vila | sure | 15:22 |
| vila | but I'd rather to an HPSS call that also returns the branch store when opening the branch then... | 15:23 |
| vila | s/rather/rather add/ | 15:23 |
| vila | in that case that would mean one less roundtrip | 15:23 |
| vila | but just adding an HPSS call to replace a single VFS call ? What's the gain ? | 15:23 |
| jelmer | vila: it's not tied to the underlying file format | 15:24 |
| jelmer | vila: wouldn't the config be read each time the branch is read locked? | 15:25 |
| vila | jelmer: it depends on whether the config file is always read when a branch is read locked :) | 15:26 |
| vila | but it may be a win anyway if it avoids a roundtrip in most cases | 15:27 |
| jelmer | vila: anyway, my point really was about fixing when we read and write config files first | 15:28 |
| jelmer | so that we have a stable config stack/store API to rely on | 15:28 |
| jelmer | vila: I think the HPSS thing matters too, but that should be a lot easier to fix (and not have any impact on callers) | 15:30 |
| vila | you totally lost me | 15:30 |
| jelmer | vila: I think we should fix bug 832042 before using config stacks/stores in anger, because it probably will impact API users | 15:31 |
| ubot5 | Launchpad bug 832042 in Bazaar "config files are read for each option" [High,In progress] https://launchpad.net/bugs/832042 | 15:31 |
| vila | jelmer: if you find a way to fix it without a new config scheme, please go ahead, I bang head for a long time before reaching the conclusion that the new design was the best way to achieve that :) | 15:32 |
| jelmer | vila: I think we should fix it *in config stacks/stores* before we start switching options over | 15:33 |
| vila | jelmer: wrong idea, that would multiply the potential issues | 15:34 |
| jelmer | vila: if we don't then I think we probably will have to fix callers of the stack/store API when bug 832042 gets fixed. | 15:35 |
| ubot5 | Launchpad bug 832042 in Bazaar "config files are read for each option" [High,In progress] https://launchpad.net/bugs/832042 | 15:35 |
| vila | chicken-and-egg | 15:37 |
| vila | I did propose a stack registry to make sure stack/store acquisition could be controlled | 15:38 |
| vila | this was pushed because there was no clear need | 15:38 |
| vila | I'm now working to make the needs clearer | 15:39 |
| jelmer | Sorry, but I don't see how a stack registry is relevant here. | 15:39 |
| vila | I know :) | 15:39 |
| jelmer | as a caller, I want to know when my changes get written to disk if I do: Branch.get_config_stack().set("foo", "bar") | 15:40 |
| vila | today: during the call, tomorrow: when you release the branch write lock | 15:41 |
| jelmer | vila: it would be nice ot state that in bug 832042 at least | 15:42 |
| ubot5 | Launchpad bug 832042 in Bazaar "config files are read for each option" [High,In progress] https://launchpad.net/bugs/832042 | 15:42 |
| jelmer | at the moment it's very vague about that | 15:42 |
| vila | devnotes/configuration.txt has a more precise definition and refers to bug #832042 | 15:43 |
| vila | but still a bit hand-wavy | 15:44 |
| jelmer | vila: I don't see any references to 832042 in configuration.txt | 15:44 |
| jelmer | is this your private notes? | 15:45 |
| vila | grr doc.bazaar.canonical.com is down ?? | 15:45 |
| vila | ha right, the bug reference is a local edit, I was referring to the last section 'Why and when locking config files matter' | 15:48 |
| jelmer | vila: doc/developers/configuration.txt in lp:bzr ? | 15:50 |
| vila | no, http://bazaar.launchpad.net/~bzr-core/bzr/devnotes/view/head:/configuration.txt | 15:52 |
| vila | no, http://bazaar.launchpad.net/~bzr-core/bzr/devnotes/view/head:/configuration.txt#L760 even | 15:53 |
| jelmer | ah, ok | 15:55 |
| jelmer | vila: thanks | 15:55 |
| jelmer | I'll paste the relevant bits into the bug | 15:55 |
| jelmer | (it's really confusing to have two documents about this btw, I don't really see the point of lp:bzr/devnotes) | 15:59 |
| vila | not implemented yet stuff | 15:59 |
| jelmer | right, but that's true for doc/developers in lp:bzr too | 16:00 |
| vila | err, no, the later is targeted at developers and refers to internals as they work today (at least that's my understanding) | 16:00 |
| jelmer | vila: I've landed several specs there before they were implemented, plans.txt was created specifically for that purpose | 16:05 |
| vila | really ? | 16:06 |
| vila | there is no plans.txt right now though | 16:07 |
| jelmer | vila: there is, doc/developers/plans.txt in lp:bzr | 16:07 |
| * vila blinks | 16:08 | |
| jelmer | my understanding of devnotes was that it was just a place to stow random notes from sprints, I don't think I've looked at it since Barcelona | 16:10 |
| jelmer | anyway, the configuration.txt in there is a good read | 16:10 |
| vila | the devnotes one you mean ? | 16:10 |
| jelmer | I think you sent me a copy of it earlier, I didn't realize it was in there | 16:11 |
| jelmer | vila: yeah | 16:11 |
| vila | Ha, you read it at least once, I was scared for a second :) | 16:11 |
| vila | jelmer: if you want more read on config, enjoy https://code.launchpad.net/~vila/bzr/config-command/+merge/82421 ;) | 16:14 |
| jelmer | vila: sure, I'll have a look | 16:16 |
| jelmer | vila: https://code.launchpad.net/~vila/bzr/config-command/+merge/82421 now includes aliases too, is that intentional? | 16:26 |
| jelmer | vila: http://pastebin.ubuntu.com/740351/ | 16:27 |
| vila | wow, nice catch, no it's not | 16:27 |
| vila | or is it... | 16:27 |
| vila | errr | 16:28 |
| vila | no not intentional | 16:28 |
| vila | but is it such a bad idea ? Yes, probably | 16:28 |
| === zyga is now known as zyga-afk | ||
| vila | jelmer: fix pushed and comment added to the mp explaining the root issue | 17:19 |
| * jelmer looks | 17:21 | |
| jelmer | vila: wouldn't this break "bzr config" for people who currently don't have a [DEFAULT] header set? | 17:23 |
| vila | I don't think we really support having a no-name section in bazaar.conf, some tests were relying on this assumption but IIRC bazaar.conf is created with the DEFAULT section (and documented as such) | 17:25 |
| jelmer | ok | 17:25 |
| vila | the old code is pretty blurry around this specific issue | 17:26 |
| === beuno is now known as beuno-lunch | ||
| jelmer | yeah | 17:35 |
| mgz | jelmer: reviewed some of your updated branches, just a few little things | 17:45 |
| jelmer | mgz: thanks | 17:46 |
| jelmer | vila: it looks a bit odd that list option values are in quotes | 17:46 |
| jelmer | vila: I know why, but still | 17:46 |
| jelmer | anyway, MP looks good otherwise | 17:46 |
| vila | jelmer: yup, the issue is that we don't rely on the store to automaGically interpolate lists, we *can* do either (depending on option registration), we default to not. | 17:49 |
| vila | jelmer: regarding the HPSS call, I agree it can and should be done, | 17:49 |
| vila | jelmer: but it doesn't have to be done before or after $this, it can be done in parallel | 17:50 |
| vila | jelmer: and indeed, some _get_store is needed ;) | 17:50 |
| vila | jelmer: I had to re-think our discussion backwards, but I've connected the dots :-) | 17:51 |
| jelmer | vila: ah, ok | 17:54 |
| jelmer | vila: I'm still working on Andrew's HPSS branch, I might have a stab at the config store one too | 17:54 |
| mgz | hpss still scares me... | 18:06 |
| jelmer | mgz: it scared me too, but I found it quite reasonable once I dug into it. The main thing that makes it hard to work with is that the code is so scattered across different bits of bzrlib. | 18:15 |
| mgz | yeah, finding which bits are actually still live can be a bit of a challenge, and understanding the naming | 18:15 |
| === beuno-lunch is now known as beuno | ||
| jelmer | vila: FWIW, "bzr config -d lp:..." is 11 HPSS calls before your change, 25 after (13 VFS) | 18:30 |
| vila | jelmer: (not here) can you paste that with a full (reproducing) url as a comment in the mp ? | 19:11 |
| glyph | If I want to run a command after a particular branch gets a new HEAD revision, where do I put that hook? | 19:16 |
| jelmer | vila: done | 19:18 |
| jelmer | glyph: a bzr plugin which installs a post_tip_change hook. I believe we have examples somewhere, hang on.. | 19:18 |
| glyph | jelmer: actually maybe I'm saying this wrong | 19:20 |
| glyph | I want to install this on the server side of things | 19:20 |
| glyph | the branch that gets pushed to | 19:20 |
| jelmer | glyph: in both cases, the pre_change_branch_tip / post_change_branch_tip hooks should work | 19:22 |
| jelmer | glyph: see lp:bzr-testrunner for an example of a plugin which uses the pre_change_branch_tip hook | 19:22 |
| GRiD | jelmer, i'm trying to make a blackbox test to reproduce bug 889872. since the simple tests in test_pack don't fail, i assume there needs to be a certain amount of data available. any idea how much that might be, based on the failures you saw? | 20:15 |
| ubot5 | Launchpad bug 889872 in Bazaar "not a valid key error" [Critical,Confirmed] https://launchpad.net/bugs/889872 | 20:15 |
| jelmer | GRiD: hi | 20:17 |
| jelmer | GRiD: no idea, sorry - it happened on my bzr and samba repositories, both of which are pretty big | 20:18 |
| GRiD | right ok. is there a way to generate a test repo during a blackbox test with that kind of data, or no? | 20:19 |
| GRiD | even if there was, i assume it would be slow. | 20:20 |
| jelmer | GRiD: perhaps there are other parameters you can tweak to make it happen earlier? | 20:21 |
| jelmer | GRiD: I'm not really familiar with the index code unfortunately | 20:21 |
| GRiD | jelmer, ok thanks. i'll play with it. | 20:24 |
| GRiD | well i've duplicated it on a repack of bzr at least. | 20:27 |
| === abentley_ is now known as abentley | ||
| poolie | hi all | 21:23 |
| poolie | hi grid, jelmer, | 21:23 |
| jelmer | hi poolie | 21:26 |
| GRiD | hi poolie | 21:34 |
| Noldorin | hi hi | 21:34 |
| peitschie | mornin everyone :) | 22:13 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!