[00:01] <jelmer> Noldorin: how is it failing exactly?
[00:01] <glyph> jelmer: was my earlier summary accurate
[00:02] <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:03] <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:04] <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:05] <jelmer> glyph: yes, it's post-1.1.1
[00:06] <Noldorin> jelmer, okay just a sec
[00:10] <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:11] <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:33] <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:34] <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:35] <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:36] <jelmer> jo-erlend: http://people.canonical.com/~mwh/bzrlibapi/bzrlib.workingtree.WorkingTree.html
[00:43] <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:44] <jelmer> jo-erlend: the fragment I pasted earlier should give you a boolean that indicates whether anything has changed
[00:52] <jo-erlend> oh. That was easier than it looked. :)
[00:52] <jo-erlend> thanks. :)
[01:00] <Noldorin> jelmer, yeah just testing
[01:00] <jo-erlend> jelmer, that feature isn't documented, though?
[01:03] <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:04] <Noldorin> jelmer, what's an easy way to check if bzr-git has loaded correctly?
[01:06] <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:07] <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:08] <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:09] <Noldorin> jelmer, that displays fine even if dependent modules didn't load though
[01:11] <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:12] <jelmer> Noldorin: any sort of operation involving a git repository should load dulwich
[01:13] <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:14] <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:15] <Noldorin> got it
[01:15] <Noldorin> jelmer, http://pastebin.com/cXdaVkpL
[01:16] <jelmer> hmm, that's masking the actual error
[01:16] <Noldorin> jelmer,yeah...
[01:17] <jelmer> Noldorin: can you try adding "import dulwich" to bzr-git's __init__.py ?
[01:18] <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:19] <jelmer> Noldorin: right, python's import doesn't find dulwich
[01:20] <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:22] <jelmer> Noldorin: it seems happy with symlinks on Unix, perhaps it's different on Windows?
[01:23] <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:24] <Noldorin> ciao
[01:25] <jelmer> Noldorin: sorry, I'll leave that up to the Python folks
[01:26] <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
[06:31] <poolie> hi vila?
[07:51] <vila> poolie: hey !
[08:12] <jam> morning all
[08:15] <poolie> hi jam
[08:22] <jam> hi poolie
[08:22] <jam> you've been quite active on email after being gone :)
[08:26] <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:31] <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
[09:02] <jelmer> 'morning
[09:21] <mgz> morning all
[09:25] <poolie> hi mgz, jelmer
[10:23] <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:24] <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:25] <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:39] <jo-erlend> oh, ok. I'll need to consider my personal comments, then :)
[10:40] <mgz> that's good general advice :)
[11:10] <mgz> weird failures ;_;
[11:14] <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:44] <vila> mgz :-/
[11:58] <mgz> vila: just posted summary in bug 842223 mp
[11:59] <mgz> maybe just something went wrong with the building of extensions on babune?
[12:00] <mgz> I don't think I caused them at any rate, so this branch can probably still land
[12:01] <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:03] <vila> so, summary, this should land and I should check the extensions build on babune right ?
[12:03] <mgz> I think so.
[12:04] <mgz> this was using /debug/ not /Windows/
[12:04] <mgz> and we've not touched debug in a while.
[12:06] <vila> right, but the /debug/ job rebuilt some extensions, nothing suspicious there
[12:06] <vila> or is it ?
[12:16] <vila> mgz: ^ ?
[12:18] <mgz> the rebuild in itself isn't suspicious, I started at an older revision, so there were pyrex source updates in between
[12:19]  * mgz downloads the log to have a look too
[12:19] <vila> which are indirectly reflected by the compilations
[12:23] <mgz> there's an error from make saying format incorrect de paramétre
[12:23] <mgz> probably not relevent
[12:24] <vila> yeah, bogus mount, spurious AFAICT
[12:24]  * mgz notes for future reference, altgr+; e
[12:25] <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:26] <mgz> and the mystery of the vanishing bug 842233 failures is resolved
[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:27] <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:28] <mgz> and "stuff went seriously wrong"
[12:28] <vila> shouldn't subunit handle that ? 'lost connection' comes from there no ?
[12:29] <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:34] <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:35] <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:41] <poolie> :)
[12:41] <poolie> i like the cømpose key
[12:42] <vila> right, that the one I should use :)
[13:13] <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:16] <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:17] <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:18] <mgz> using the structured stuff for commit like --fixes and --author is better than munging those into the message
[13:19] <mgz> if you're writing "patch from X fixing bug N" then you're doing something wrong in my view :)
[13:20] <jo-erlend> is fixes just a label, or is it linked to a bug tracker?
[13:22] <mgz> it's stored as aURL
[13:32] <jo-erlend> oh, ok.
[13:33] <jo-erlend> but I guess it has better understanding for bugs stored in launchpad?
[13:36] <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:38] <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:40] <mgz> eheh, jam's comment on pylzma is funny
[13:41] <vila> mgz: I've seen cases where tests were *enforcing* a bug
[13:45] <jam> mgz: well, you've submitted 3+ times now I think, and nobody gets a failure message :)
[14:17] <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:46] <jelmer> mgz: I've updated switch-colocated to include tests for unicode colocated and other branches
[14:47] <jelmer> that also involved using "real" branch names rather than url encoding for the "sibling" branch support in switch
[14:49] <jelmer> vila: any plans for Branch._get_store() ? :)
[14:49] <vila> huh ? Shouldn't be needed, what's the use case ?
[14:51] <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:53] <vila> right, there is already a RemoteBranchStack
[14:53] <vila> jelmer: do you encounter a issues with it ?
[14:54] <jelmer> I'm seeing VFS access over HPSS from BranchStore
[14:54] <jelmer> vila: RemoteBranch.get_config_stack() returns _mod_config.BranchStack(self)
[14:55] <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:56] <vila> if you use the old config scheme you also trigger VFS calls
[14:57] <vila> this should be better once http://pad.lv/832042 is fixed
[14:58] <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
[15:01] <jelmer> ah, thanks
[15:01] <jelmer> vila: btw, that bug is in progress but not assigned?
[15:01] <vila> hehe, I was angry :)
[15:03] <vila> jelmer: fixed (or rather assigned ;)
[15:04] <jelmer> vila: :)
[15:05] <vila> not sure yet if I should finish migration options before or after fixing it
[15:05] <vila> s/migration/migrating/
[15:07] <jelmer> vila: after, IMO. we shouldn't really be adding more VFS calls
[15:08] <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:09] <vila> locking should be ok
[15:10] <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:11] <jelmer> vila: plus the overhead of enabling VFS mode
[15:11] <vila> oh, that, right
[15:13] <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:14] <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:15] <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:16] <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:18] <vila> premature design, the needed calls will be fully defined when all the options are migrated
[15:19] <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:20] <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:21] <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:22] <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:23] <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:24] <jelmer> vila: it's not tied to the underlying file format
[15:25] <jelmer> vila: wouldn't the config be read each time the branch is read locked?
[15:26] <vila> jelmer: it depends on whether the config file is always read when a branch is read locked :)
[15:27] <vila> but it may be a win anyway if it avoids a roundtrip in most cases
[15:28] <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:30] <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:31] <jelmer> vila: I think we should fix bug 832042 before using config stacks/stores in anger, because it probably will impact API users
[15:32] <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:33] <jelmer> vila: I think we should fix it *in config stacks/stores* before we start switching options over
[15:34] <vila> jelmer: wrong idea, that would multiply the potential issues
[15:35] <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:37] <vila> chicken-and-egg
[15:38] <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:39] <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:40] <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:41] <vila> today: during the call, tomorrow: when you release the branch write lock
[15:42] <jelmer> vila: it would be nice ot state that in bug 832042 at least
[15:42] <jelmer> at the moment it's very vague about that
[15:43] <vila> devnotes/configuration.txt has a more precise definition and refers to bug #832042
[15:44] <vila> but still a bit hand-wavy
[15:44] <jelmer> vila: I don't see any references to 832042 in configuration.txt
[15:45] <jelmer> is this your private notes?
[15:45] <vila> grr doc.bazaar.canonical.com is down ??
[15:48] <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:50] <jelmer> vila: doc/developers/configuration.txt in lp:bzr ?
[15:52] <vila> no, http://bazaar.launchpad.net/~bzr-core/bzr/devnotes/view/head:/configuration.txt
[15:53] <vila> no, http://bazaar.launchpad.net/~bzr-core/bzr/devnotes/view/head:/configuration.txt#L760 even
[15:55] <jelmer> ah, ok
[15:55] <jelmer> vila: thanks
[15:55] <jelmer> I'll paste the relevant bits into the bug
[15:59] <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
[16:00] <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:05] <jelmer> vila: I've landed several specs there before they were implemented, plans.txt was created specifically for that purpose
[16:06] <vila> really ?
[16:07] <vila> there is no plans.txt right now though
[16:07] <jelmer> vila: there is, doc/developers/plans.txt in lp:bzr
[16:08]  * vila blinks
[16:10] <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:11] <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:14] <vila> jelmer: if you want more read on config, enjoy https://code.launchpad.net/~vila/bzr/config-command/+merge/82421 ;)
[16:16] <jelmer> vila: sure, I'll have a look
[16:26] <jelmer> vila: https://code.launchpad.net/~vila/bzr/config-command/+merge/82421 now includes aliases too, is that intentional?
[16:27] <jelmer> vila: http://pastebin.ubuntu.com/740351/
[16:27] <vila> wow, nice catch, no it's not
[16:27] <vila> or is it...
[16:28] <vila> errr
[16:28] <vila> no not intentional
[16:28] <vila> but is it such a bad idea ? Yes, probably
[17:19] <vila> jelmer: fix pushed and comment added to the mp explaining the root issue
[17:21]  * jelmer looks
[17:23] <jelmer> vila: wouldn't this break "bzr config" for people who currently don't have a [DEFAULT] header set?
[17:25] <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:26] <vila> the old code is pretty blurry around this specific issue
[17:35] <jelmer> yeah
[17:45] <mgz> jelmer: reviewed some of your updated branches, just a few little things
[17:46] <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:49] <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:50] <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:51] <vila> jelmer: I had to re-think our discussion backwards, but I've connected the dots :-)
[17:54] <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
[18:06] <mgz> hpss still scares me...
[18:15] <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:30] <jelmer> vila: FWIW, "bzr config -d lp:..." is 11 HPSS calls before your change, 25 after (13 VFS)
[19:11] <vila> jelmer: (not here) can you paste that with a full (reproducing) url as a comment in the mp ?
[19:16] <glyph> If I want to run a command after a particular branch gets a new HEAD revision, where do I put that hook?
[19:18] <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:20] <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:22] <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
[20:15] <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:17] <jelmer> GRiD: hi
[20:18] <jelmer> GRiD: no idea, sorry - it happened on my bzr and samba repositories, both of which are pretty big
[20:19] <GRiD> right ok. is there a way to generate a test repo during a blackbox test with that kind of data, or no?
[20:20] <GRiD> even if there was, i assume it would be slow.
[20:21] <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:24] <GRiD> jelmer, ok thanks. i'll play with it.
[20:27] <GRiD> well i've duplicated it on a repack of bzr at least.
[21:23] <poolie> hi all
[21:23] <poolie> hi grid, jelmer,
[21:26] <jelmer> hi poolie
[21:34] <GRiD> hi poolie
[21:34] <Noldorin> hi hi
[22:13] <peitschie> mornin everyone :)