[00:03] <bob2> pfanelli: might have more luck on the mailing list
[00:11] <pfanelli> bob2: thx. I got this channel off of the bzr web site. I also checked for answers on LP.  Do you know how to subscribe to the mailing list? (this is probably a stupid ? :) ). Also, I was gonna' ask a question on LP. Do you think i should also do this?
[00:12] <bob2> pfanelli: https://lists.ubuntu.com/mailman/listinfo/bazaar - dunno about lp
[00:13] <pfanelli> bob2:  heh, i just looked up the mailing list on the bzr site (duh - my bad, lol)  thanks!
[00:14] <bob2> pfanelli: no worries
[00:24]  * igc offline for an hour or so while travelling
[01:12] <spiv> I've just submitted 3 of Robert's approved patches to PQM, given that he's offline today.
[01:14] <jelmer> is there any chance of the 30+ patches currently in BB landing before 1.13?
[01:47] <jfroy> jelmer: I just got a "Could not determine revno for ... because its ancestry shows a ghost at ..." error, thoughts?
[01:47] <jfroy> while trying to commit to a svn branch
[01:47] <spiv> jelmer: of all of them landing?  I'd estimate that at near 0.
[01:48] <spiv> jelmer: there's a good chance that some of them will, though...
[01:48] <spiv> Perhaps even most?
[02:03] <phinze> is there a location alias for the "checkout of" branch?
[02:07] <lifeless> spiv: thanks
[02:22] <tallen> anyone seen any integration with Visual Studio and Bazaar?
[02:24] <tallen> I see this https://launchpad.net/bzr-visualstudio but it doesnt seen active
[02:40]  * igc is back online
[02:48] <igc> jam, if you're still around, the groupcompress tests are failing
[02:49] <igc> I think I know the fix but I'm not sure ...
[02:49] <igc> add "start = entry.start" around line 236 in groupcompress.py?
[02:58] <lifeless> spiv: ping
[03:00] <poolie> hi lifeless
[03:05] <jelmer> jfroy, please file a bug
[03:05] <jfroy> will do if I see it again
[03:05] <jelmer> spiv, most would be nice
[03:06] <jfroy> I wiped the cache and tried the operation again (a commit), and it worked
[03:06] <jelmer> jfroy, it's not reproducible?
[03:06] <jfroy> (well, also made a clean checkout)
[03:06] <jfroy> I haven't seen the same error again yet
[03:06] <lifeless> poolie: hi
[03:06] <jfroy> I always try a "wipe cache, get a clean checkout" while tracking bzr-svn top of tree.
[03:07] <jfroy> It's not unreasonable for changes to invalidate existing branches or the cache
[03:07] <jelmer> jfroy, unless there is a bug that's been fixed no changes should be invalidating existing branches/cache
[03:08] <jelmer> jfroy, was this the same branch we fixed a bug in yesterday?
[03:10] <jfroy> yes I believe so
[03:10] <jfroy> actually no
[03:10] <jfroy> well, yes and no :p
[03:10] <jfroy> same subversion branch
[03:11] <jfroy> but much older local branch (my actual daily work branch)
[03:13] <spiv> lifeless: pong
[03:19] <lifeless> spiv: about to send in a tags fix
[03:19] <spiv> lifeless: hooray.  ratchet improvement? :)
[03:19] <lifeless> spiv: surprisingly, not yet. 4 verbs in and still equilibrium
[03:20] <spiv> lifeless: I'd love a review of my fetch with search patch (http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20090306005950.GD7819%40steerpike.home.puzzling.org%3E)
[03:20] <spiv> lifeless: huh, odd.  What's the current culprit?
[03:21] <lifeless> spiv: tags
[03:21] <lifeless> so get_parent_ was equilibrium
[03:21] <lifeless> ten tags - first _should_merge,
[03:21] <lifeless> but .tags needed real
[03:22] <lifeless> then branch._transport needed real
[03:22] <lifeless> which is what I'm working on at the moment
[03:22] <lifeless> oh, open_branchV2 is in there too, to get the format
[03:32] <lifeless> spiv: also there is an oddity on decod of responses
[03:32] <lifeless> spiv: '' -> ()
[03:33] <jam> igc: something like that. I think I fixed it in a different branch by using 'entry.start' in place of 'start', but either should be fine
[03:33] <lifeless> spiv: or more clearly, ('',)
[03:33] <lifeless> spiv: and, ratchet -> 11
[03:38] <hackedhead> i'm about to travel, and i have a small class projec that i'm using bzr to track on my deskop, i'm the only 'developer' and it's not public anywhere. i'd like to move the working tree to my laptop while i travel... can i simply copy the directory over? or is there better way?
[03:38] <poolie> sure just
[03:38] <poolie> on your laptop,
[03:38] <poolie> bzr branch bzr+ssh://desktop/~/what/ever
[03:38] <poolie> oh, and make a repo in the right place on your laptop first
[03:38] <igc> jam: yeah, it looked like start was being set in the if branch but not the else branch
[03:39] <hackedhead> 'make a repo' meaning a directory for it to live in, i assume
[03:40] <spiv> lifeless: I fixed some bugs in your get_parent branch to be able to land it, btw
[03:40] <lifeless> spiv: ok, I'll pull now
[03:40] <spiv> lifeless: where you were passing 'foo' rather than ('foo',) as a response
[03:40] <igc> jam: the unclear bit was knowing what start ought to be set to - and entry.start looked a likely option :-)
[03:41] <poolie> hackedhead: i mean, in your home directory, do
[03:41] <poolie> bzr init-repo myproject
[03:41] <spiv> lifeless: you had some tests and code that had (x) rather than (x,), happily other tests noticed :)
[03:41] <jam> igc: yeah, inside that if, entry.start is set to start
[03:41] <poolie> or whatever name you want to use
[03:41] <lifeless> spiv: yes, I've just been cleaning that up here too
[03:41] <poolie> this will make a directory to hold all your branches
[03:41] <jam> it is outside the if that already has it
[03:42] <igc> jam: another minor quibble, the groupcompress branch had a heap of bzr tags in it referencing missing revisions
[03:42] <igc> jam: I'm not sure if they're gone know but my concern was how they got there
[03:42] <lifeless> igc: root cause: pull not propogating tags
[03:43] <hackedhead> poolie: okay, and when i get back i can do a merge from the desktop, using ssh again, in the other direction?
[03:43] <poolie> yes, or just push to the desktop
[03:43] <hackedhead> oh, right, okay
[03:43] <poolie> presumably no other work will have happened there while you're away
[03:43] <poolie> so just a push will do
[03:43] <hackedhead> yes. =]
[03:43] <poolie> hth
[03:43] <hackedhead> yeah,much, ty
[03:43] <igc> lifeless: I'm not sure I understand - why would a 'bzr-0.15' tag exist in the groupcompress repo at all?
[03:43] <poolie> you're welcome
[03:44] <lifeless> igc: oh, that? blame jam :P
[03:44] <hackedhead> o/
[03:44] <igc> maybe the orginal branch shared a repo with bzr.dev or something?
[03:45] <jam> funny, I don't remember ever trying to merge my jam-integration branch into groupcompress
[03:45] <jam> I honestly don't have any idea why the tags would have spread to GC
[03:46] <jam> maybe I did a 'bzr merge' with a bad path once?
[03:46] <jam> igc: It shares a repo, but it shouldn't have shared a branch
[03:52] <lifeless> spiv:
[03:52] <lifeless> [BzrDir.open, BzrDir.open_branchV2, BzrDir.find_repositoryV3, Branch.get_stacked_on_url, Branch.last_revision_info, BzrDir.cloning_metadir, Repository.get_parent_map, Repository.get_stream, Branch.get_parent, Branch.get_tags_bytes, Branch.get_tags_bytes]
[03:52] <lifeless> spiv: clear as day now.
[03:53] <lifeless> spiv: also note: VFS-free!
[03:53] <lifeless> spiv: I'm going to ignore the duplicate call [for now]
[03:53] <lifeless> spiv: as caching coherency requires a little care, and this is already somewhat better
[03:55] <poolie> lifeless, jam, this branch was originally going to set the format to 1.9-rich-root
[03:55] <poolie> to get it over with
[03:55] <lifeless> poolie: which branch
[03:55] <poolie> to set the default format for 1.13 to 1.9
[03:56] <poolie> i'm inclined now to stick with plain 1.9
[03:56] <lifeless> works for me
[03:57] <lifeless> spiv: reviewing your patch about fetch paramaters
[04:02] <spiv> lifeless: nice
[04:03] <lifeless> spiv: so, I want to combine the first three calls
[04:04] <lifeless> spiv: with a lock_read() we could optimistically ask for the next two or even three
[04:04] <spiv> lifeless: a lock_read on which object?
[04:04] <lifeless> spiv: Branch
[04:05] <spiv> Hmm.  If we opened branches read-locked, then get_stacked_on_url and last_revision_info are obvious things to fetch.
[04:05] <lifeless> yes
[04:05] <lifeless> but api clarity does still matter :)
[04:06] <spiv> Right.
[04:06] <lifeless> Branch.open().unlock().lock_write() blows
[04:06] <spiv> There is definitely some friction with the current API here.
[04:06] <jam> poolie: I wouldn't do rr
[04:06] <jam> given the 5-hour conversion times
[04:06] <lifeless> I could buy into Branch.open_read_locked()
[04:06] <spiv> lifeless: me too
[04:07] <poolie> me three
[04:07] <poolie> jam, ok
[04:07] <jam> wait for something like CHK, which gives a real benefit
[04:11] <lifeless> spiv: reviewed
[04:12] <lifeless> spiv: in short; some smoke tests for the new capabilities; and some naming changes
[04:12] <lifeless> spiv: also please review my tags patch :)
[04:12] <poolie> lifeless/spiv: changing the default format to 1.9 bumps test_branch_from_trivial_branch_streaming_acceptance to 18
[04:12] <lifeless> poolie: tsk!
[04:12] <poolie> putting just a number there makes it hard to see what actually was added
[04:13] <lifeless> poolie: yes, thats true. OTOH its very easy to work with for us
[04:13] <lifeless> poolie: when some of the ratches are still > 100
[04:13] <poolie> yes that's the tradeoff
[04:13] <poolie> i know i know
[04:13] <lifeless> :)
[04:13] <poolie> been there too
[04:15] <lifeless> spiv: oh bah, ignore the self.debug() call I left in
[04:16] <spiv> lifeless: was already reviewing :)
[04:16] <lifeless> poolie: it stays at 11 for me
[04:17] <lifeless> spiv: K, I'll wait for your feedback and remove the debug call at the same time
[04:18] <lifeless> poolie: I see:
[04:18] <lifeless> [BzrDir.open, BzrDir.open_branchV2, BzrDir.find_repositoryV3, Branch.get_stacked_on_url, Branch.last_revision_info, BzrDir.cloning_metadir, Repository.get_parent_map, Repository.get_stream, Branch.get_parent, Branch.get_tags_bytes, Branch.get_tags_bytes]
[04:18] <lifeless> poolie: however, I do see an increase in blackbox.test_branch.TestSmartServerBranching.test_branch_from_trivial_branch_to_same_server_branch_acceptance, which is from 65 to 66
[04:21] <poolie> lifeless: http://pastebin.ubuntu.com/127042/
[04:22] <spiv> lifeless: reviewed
[04:23] <lifeless> poolie: yeah, most of those will be tags
[04:23] <lifeless> poolie: print self.hpss_calls[8].stack
[04:23] <poolie> i guess it's also reading the stacking control file
[04:23] <lifeless> poolie: will show you the cause
[04:25] <poolie> that's nice
[04:25] <poolie> well it's http://pastebin.ubuntu.com/127042/
[04:25] <poolie> meh
[04:25] <poolie>     format_string = transport.get(".bzr/branch-format").read()
[04:26] <lifeless> poolie: right, but look higher :)
[04:27] <lifeless> poolie: _ensure_real is generally a symptom
[04:27] <lifeless> you'll find something like merge_tags_if_needed
[04:27] <poolie> sure, of get_parent
[04:27] <lifeless> or get_parent :)
[04:27] <lifeless> get_parent as landed though
[04:28] <poolie> just recently?
[04:28] <lifeless> today
[04:28] <spiv> Yes, a couple of hours ago.
[04:28] <poolie> so maybe that didn't reduce the rpc count, but it did eliminate vfs access here?
[04:29] <spiv> Right.
[04:29] <lifeless> yes get_parent_map was no improvements in round trips, but one less cause of vfs
[04:29] <lifeless> the next patch removes the last cause
[04:29] <spiv> lifeless: s/get_parent_map/get_parent/ :)
[04:29] <lifeless> bah yes
[04:30] <spiv> Perhaps it should be called get_parent_location to reduce confusion?  Not that the wire API is the same as bzrlib's API...
[04:30] <lifeless> spiv: see thursday's chat:)
[04:30] <lifeless> spiv: _run_with.. should show the transform
[04:30] <poolie> ?
[04:30] <poolie> on staying on the main game?
[04:30] <poolie> at a guess
[04:31] <lifeless> poolie: no, about verb names
[04:31] <spiv> lifeless: oh, _run_with... was self-explanatory to me :)
[04:31] <lifeless> spiv: I can't tell if  I need a lambda or not
[04:31] <lifeless> spiv: for instance
[04:32] <spiv> lifeless: please feel free to extend the docstring; the transform for the given example is just "return _run_with_write_locked_target(callable, *args, **kwargs)"
[04:32] <lifeless> (what if _transport is only defined in the lock_written state? for instance)
[04:32] <spiv> Typically if a function takes *args/**kwargs then lambdas are unneccessary.
[04:34] <poolie> ok so that one's still failing after merging bzr.dev...
[04:35] <poolie> because now tags() is forcing a real repository...
[04:37] <spiv> poolie: so the problem is that _ensure_real of a BzrBranch7 is one VFS call more expensive than of Branch6?
[04:37] <lifeless> spiv: your cloning_metadir looks odd
[04:37] <lifeless> spiv: sometimes you return a tuple
[04:37] <poolie> i think so
[04:37] <lifeless> spiv: sometimes you return a string, for branch_name
[04:37] <lifeless> spiv: is this deliberate?
[04:37] <spiv> lifeless: do I?  Hmm.
[04:37] <poolie> that would be consistent with it having to read its stacking url over the vfs
[04:37] <spiv> lifeless: IIRC I meant to always return a tuple.
[04:38] <spiv> lifeless: ugh, so I do.
[04:38] <lifeless> spiv: adjusting
[04:38] <poolie> therefore i think it's correct for that count to go up by 1 given the level of technology in this branch
[04:38] <spiv> lifeless: thanks.
[04:38] <lifeless> spiv: and letting pqm handle the fallout
[04:39] <spiv> poolie: what's odd to me is that 1.6 has stacking URLs too...
[04:39] <lifeless> spiv: current default is 0.92
[04:39] <spiv> Oh, ok.
[04:39] <spiv> In that case, it all makes perfect sense :)
[04:40] <lifeless> poolie: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C1236311834.10834.1.camel%40lifeless-64%3E
[04:40] <spiv> poolie: given that lifeless is about to land get_tags_bytes, which should get rid of the VFS from that case, a temporary +1 bump sounds ok to me.
[04:40] <lifeless> poolie: ^ is about to land
[04:40] <lifeless> poolie: and it will conflict on that line
[04:40] <spiv> poolie: but as lifeless says maybe just merging in that branch will be easier?
[04:42] <poolie> k, i'll look at some other failures first
[04:45] <lifeless> poolie: so the other acceptance test in test_branch.py *will* go up for 1.9 as default, with my branch
[04:45] <lifeless> poolie: and thats fine
[04:54] <lifeless> (65->66 for me - you have +1 on that change)
[05:05] <poolie> i wish, again, we printed stack traces as soon as they occurred...
[05:08] <seb_kuzminsky> is it bad if "bzr check" says "2 inconsistent parents"?
[05:08] <seb_kuzminsky> on the repo where it says that, i can't push changes in
[05:08] <seb_kuzminsky> i made that repo with "git-fast-export | bzr fast-import", and it seems to work fine locally, but not in branches i've made off it...
[05:09] <poolie> seb_kuzminsky: it may be a bzr-fastimport bug then
[05:09] <poolie> seb_kuzminsky: ideally someone would run bzr reconcile on that repo
[05:10]  * seb_kuzminsky reads about reconcile
[05:10] <poolie> lifeless or spiv, one of you might want http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Ce01316480903052104k63c85898t88ed90dcccdc7715%40mail.gmail.com%3E
[05:10] <poolie> also  spiv is http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20090126072506.GA30864%40steerpike.home.puzzling.org%3E now obsolete?
[05:11] <seb_kuzminsky> "Reconciliation complete."
[05:11] <seb_kuzminsky> bzr check is clean now :-)
[05:13] <seb_kuzminsky> but it still doesnt work :-(
[05:14] <spiv> poolie: not obsolete, but it does need another look to figure out how it should interact with vila's http network activity
[05:14] <seb_kuzminsky> i removed ran reconcile on the "master" repo, removed the remote branch, re-branched to the remote machine, committed on the remote machine, and tried to push
[05:14] <seb_kuzminsky> bzr: ERROR: Revision {set([('null:',)])} not present in "KnitVersionedFiles(_KnitGraphIndex(CombinedGraphIndex(<bzrlib.btree_index.BTreeGraphIndex object at 0x18a5a90>, <bzrlib.btree_index.BTreeGraphIndex object at 0x16518d0>)), <bzrlib.knit._DirectPackAccess object at 0x16033d0>)".
[05:14] <seb_kuzminsky> both repos are 1.9-rich-root, in case that matters
[05:14] <seb_kuzminsky> both 'check' clean
[05:15] <spiv> seb_kuzminsky: which version of bzr?  I think this bug was fixed in bzr.dev about a week ago.
[05:15] <seb_kuzminsky> "1.13dev" on the remote machine
[05:15] <seb_kuzminsky> "1.12" on the master server
[05:15] <seb_kuzminsky> upgrade the server?
[05:16] <seb_kuzminsky> remote is on the bzr intrepid ppa
[05:16] <spiv> seb_kuzminsky: upgrade the 1.12 to bzr.dev if you can, IIRC
[05:16] <seb_kuzminsky> server is intrepid's 1.12-1~bazaar1~intrepid1
[05:20] <seb_kuzminsky> spiv: do i need the nightly ppa?  or is beta good enough?
[05:20] <seb_kuzminsky> looks like i need beta
[05:20] <seb_kuzminsky> s/beta/nightly/
[05:20] <spiv> seb_kuzminsky: nightly, I think.
[05:21] <spiv> seb_kuzminsky: https://launchpad.net/bugs/317654 is the bug, btw
[05:22] <spiv> seb_kuzminsky: also, you may be able to workaround it by using sftp:// rather than bzr+ssh://
[05:22] <seb_kuzminsky> hmm
[05:23] <seb_kuzminsky> yes, sftp:// pushed successfully
[05:23] <seb_kuzminsky> but it didnt run the hooks (bzr-email, bzrbuildbot)
[05:23] <spiv> Yeah.
[05:23] <seb_kuzminsky> those only run with ssh, right?
[05:23] <spiv> That's right.
[05:24] <seb_kuzminsky> ok
[05:24]  * seb_kuzminsky adds bzr-nightly-ppa to sources.list.d/bzr.list
[05:25] <lifeless> spiv: I've just forwarded you a pqm failure
[05:25] <spiv> lifeless: ok
[05:25] <lifeless> spiv: I'd like to ask a favour
[05:26] <lifeless> spiv: land my http://people.ubuntu.com/~robertc/baz2.0/integration branch
[05:26] <spiv> lifeless: ok
[05:26] <lifeless> spiv: its likely that ^^^^[log from bzrlib.tests.branch_implementations.test_hooks.TestOpen.test_open(RemoteBranchFormat-default)] is one of several failures with hooks
[05:27]  * spiv nods
[05:27] <lifeless> so running hooks.* RemoteBranchFormat should flush them out
[05:28] <lifeless> I *think* at a glace that the branch is being opened remotely in more cases
[05:28] <lifeless> so trivially adjusting may be sufficient
[05:29] <seb_kuzminsky> server is on 4083 (latest in bzr.dev), remote machine is on 4058
[05:29] <seb_kuzminsky> remote still can't push, same error
[05:30] <seb_kuzminsky> upgrading remote to 4083 now
[05:30] <spiv> seb_kuzminsky: remote needs to be at least 4061
[05:31] <spiv> seb_kuzminsky: "missed it by *that* much" ;)
[05:31] <seb_kuzminsky> heh
[05:31] <seb_kuzminsky> that's what i get for hopping off of the nightlies and down to the boring old stuff in the "release" ppa  ;-)
[05:32] <spiv> seb_kuzminsky: also, the network protocol is in a fair bit of flux in bzr.dev atm.  So until 1.13rc1 is out, you may need to keep client and server on the same version of bzr.dev to avoid weird smart server failures.
[05:32] <seb_kuzminsky> ok thanks for the heads up
[05:32] <spiv> (but on the plus side it ought to be noticeably faster)
[05:33] <seb_kuzminsky> ooh, thanks!
[05:33] <spiv> seb_kuzminsky: if you *do* get weird failures though, please let us know :)
[05:33] <seb_kuzminsky> oh you'll know
[05:34] <seb_kuzminsky> ;-)
[05:34] <spiv> :)
[05:35] <seb_kuzminsky> looks like it worked
[05:35] <spiv> seb_kuzminsky: great
[05:35] <seb_kuzminsky> aw yea
[05:35] <seb_kuzminsky> thanks spiv!
[05:36] <seb_kuzminsky> yeah that's all working just fine :-)
[05:36] <seb_kuzminsky> yay, thanks again!
[05:36] <seb_kuzminsky> ok i'll be back when it breaks next time ;-)
[05:37] <spiv> seb_kuzminsky: good :)
[05:42] <spiv> lifeless: the three calls are [server] open_branchV2, [client] open, [server] get_stacked_on_url
[05:42] <lifeless> spiv: right,
[05:42] <lifeless> open_branch didn't open the branch
[05:43] <spiv> Right.
[06:11] <lifeless> spiv: I need to go
[06:11] <lifeless> spiv: good luck with the branch
[06:11] <spiv> lifeless: not a problem
[06:11] <spiv> lifeless: happy travels
[06:15] <poolie> yes bye lifeless
[06:25] <poolie> spiv, i have a failure now in test_clone_unstackable_branch_preserves_stackable_repo_format
[06:26] <poolie> because RemoteBranchFormat, at least in the version of trunk that i've merged, claims not to support stacking
[06:26] <poolie> whereas with this change it will
[06:26] <poolie> does this ring any bells?
[06:28] <spiv> poolie: hmm
[06:30] <spiv> poolie: that does ring some bells, in that a recent landing touched that code.
[06:30] <poolie> i think in general robert was going to make tags be handled by making teh format depend on the particular branch
[06:30] <poolie> not sure that's a great idea
[06:30] <poolie> at the moment it says it always supports tags
[06:30] <poolie> so i'm going to make it consistent with that and hope :)
[06:30] <spiv> poolie: but IIRC the change was that it was going to rely on the underlying format to decide
[06:31] <spiv> Right, that's what Robert's patch for tags does.
[06:31] <spiv> (make the format of the branch handle it)
[06:31] <spiv> Not sure what the overlap with tags and stacking is here though?
[06:37] <poolie> well, they're both capabilities that are determined by the real on disk format
[08:01] <Peng_> So now that the 'authors' revision property has been added, 'author' is no longer written, right? Isn't that bad for backwards compatibility with older clients?
[08:01] <Peng_> I mean, it's not a big deal, but still.
[08:05]  * igc dinner
[08:06] <poolie> i thought that we changed it to write out only the additonal authors?
[08:06] <poolie> but you should raise that on the list?
[08:13] <Peng_> jelmer: You mean LP's email notifications? I don't know. I know they work for lp:~jelmer/bzr-svn/0.5-mirrored.
[08:15] <spiv> poolie: regarding the repository acquisition policies, yes, it is a bit weird.
[08:16] <poolie> spiv, i'm going to try to move it
[08:16] <spiv> poolie: lifeless lands some changes to allow Branch.clone and others to accept a repository_policy kwarg
[08:16] <spiv> For similar reasons.
[08:22] <poolie> hm i remember seeing that but i can't find the mail
[08:28] <poolie> ah ok
[08:28] <poolie> so, i'd like to clean it up but it's not all that bad
[08:29] <poolie> we always create a bzrdir there before we think about stacking
[08:29] <Peng_> poolie: You thought it was changed to what?
[08:30] <poolie> but it doesn't really matter because there's only one relevant bzrdir format, and we can choose to make a different branch format before the branch is created
[08:30] <poolie> i'd say it's not great though
[08:30] <Peng_> Oh, it only uses 'authors' when multiple authors were passed. That's not so bad, then.
[08:30] <poolie> Peng_, i thought the issue had been taken into account
[08:31] <Peng_> Wait, never mind.
[08:31] <Peng_> poolie: ISTM commit only sets 'authors' now.
[08:41] <Peng_> beuno: Will Loggerhead try to perform syntax highlighting on gigantic files? IIRC, Mercurial limited it to smallish files.
[08:56] <poolie> spiv if you're still here
[08:56] <poolie> or anyone really
[08:56] <poolie> these likes look backward to me
[08:56] <poolie> 233  	                require_stacking = True
[08:56] <poolie> 234  	                result._format.require_stacking()
[08:56] <poolie> uups
[08:57] <poolie> 232  	            if not require_stacking and repository_policy._require_stacking:
[08:57] <poolie> 233  	                require_stacking = True
[08:57] <poolie> 234  	                result._format.require_stacking()
[08:57] <poolie> oh i see
[09:20] <Peng_> poolie: Mailing list message sent, fwiw.
[09:38] <Mez> hey, anyone have any idea why all of a sudden, I can do a bzr up but not a bzr st (permission denied)
[09:38] <poolie> what's in the traceback in ~/.bzr.log?
[09:39] <Mez> one sec
[09:42] <Mez> poolie: nothing sinister
[09:42] <Mez> http://rafb.net/p/EMHVs538.html
[09:42] <Mez> and an strace sees it trying to find files, but getting ENOENTs back
[09:42] <poolie> but it says permission denied?
[09:42] <Mez> yep
[09:42] <poolie> how strange
[09:42] <poolie> how about bzr -Derror st
[09:43] <Mez> running selftest .
[09:43] <poolie> huh?
[09:43] <Mez> one sec
[09:45] <Mez> poolie: http://rafb.net/p/qMF0NF83.html
[09:47] <poolie> ok
[09:47] <poolie> this is probably because there's a directory in your working tree that you can't read
[09:48] <poolie> try just ls -laR
[09:48] <Mez> ah, gnupg
[09:48] <Mez> http://rafb.net/p/6yTDaq68.html
[09:49] <poolie> yep
[09:50] <Mez> o_O
[09:50] <poolie> also, bug 338653
[09:50] <Mez> the permissions are set to the user though
[09:50] <Mez> ah, no execute on the directory
[09:51] <Mez> ok, now getting "no handlers found for logger "bzr"
[09:51] <poolie> with which version?
[09:51] <Mez> 1.12
[09:51] <Mez> (on intrepid)
[09:54] <Mez> thanks for the help mpool
[10:20] <igc> vila: do you have some time to give CHKInventory some test love?
[10:21] <igc> I think we need tests across both Inventory & CHKInventory for *all* the read-only APIs
[10:21] <igc> the mutation APIs need to be tested separately of course
[10:23] <igc> we then need to test all of the above for each of the serializer combinations, e.g. chk16, chk255
[10:23] <AfC> Damn mutants! They're everywhere! Oh, wait...
[10:24] <igc> vila: what do you think?
[11:03] <awilkins>  Blimey, DVCS 4tw
[11:03] <awilkins>  svn working copy of 4 branches : 713 MB on disk
[11:03] <awilkins>  bzr checkouts, plus the full history of the entire project : 484 MB total
[11:54] <Peng_> awilkins: Eh. svn's lack of working copy compression FTL. They could do better than 484 MB if they wanted to.
[11:59] <awilkins> Yeah, and the 17,840 files vs 5,864 isn't too hot either
[12:32] <awilkins> Gnnnnargh my frickin mother-in-law has put all the cardboard in the recycling bin even though there is a fricking sign on the lid that says not to
[12:32] <awilkins> Now I'll have to empty the fricking thing out or get fined or something
[12:32]  * awilkins is sorry for the noise
[12:33] <Toksyuryel> I thought cardboard was recyclable o.O
[12:34] <Toksyuryel> are you sure the sign says not to put that in there?
[12:34] <awilkins> Yes, there is a separate pickup for cardboard/paper
[12:34] <Toksyuryel> ah
[12:34] <awilkins> This is the plastic/cans bin
[12:34] <Toksyuryel> ahhhh, I get it
[12:35]  * Toksyuryel 's place just has one bin for all the recycling, heh
[12:35]  * awilkins wonders if they take organic waste, like dismembered^W old meat.
[12:41] <Toksyuryel> nah, those go to the soylent green facility :P
[12:54] <workthrick> hiya
[12:57] <workthrick> so, has anyone thought about getting something like darcs's patch algebra for bzr? Darcs is absolutely neat in that branches sort of magically fall out of related changes, and that you can freely change past patches in non-conflicting ways, but the UI they add to it that tries to pass for a VCS is unbelievably shitty
[12:59] <luks> hard to do something like that in bzr where each revision has it's parents (the history forms a graph), so the order can't be changed
[12:59] <workthrick> I guess, that was also a question of "how very hard would it be to do?"
[13:00] <workthrick> because the patch algebra has some really cool consequences (at least as long as you don't get into exponential time corner cases :)
[13:00] <luks> by hard I meant impossible :)
[13:01] <workthrick> like the fact that darcs is the only VCS that gets merges right where a series of patches reverts changes textually, but not semantically
[13:01] <luks> the patch theory is based on the fact that you can manupulate the order of patches, which in bzr you can't
[13:02] <workthrick> I know, so bzr would have to be hacked quite badly. I supposed as much. But would it really be completely impossible to allow reordering them?
[13:03] <luks> using the DAG model bzr uses, yes
[13:03] <workthrick> darcs has ordering too. It just has rules for generating a new order from the old one
[13:04] <luks> history in the DAG model is immutable, every state (=revision) strictly depends on everything that happened before
[13:04] <luks> if you change one piece, everything breaks
[13:04] <workthrick> so what is the model darcs uses? As far as I understand things, it's DAG + algebra for generating new, semantically equivalent DAGs
[13:05] <luks> the main difference is that it's main object are patches
[13:05] <workthrick> oh
[13:05] <luks> in bzr it's states (revisions)
[13:06] <luks> the fact that data are delta compressed is just implementation detail
[13:06] <workthrick> hmm
[13:06] <luks> you can see it as if you had one full directory of files for each revision
[13:07] <workthrick> yeah, I get that
[13:14] <davidoc> Another question: is it possible to discard old revisions before a specified revision? I split a tree and I want to get rid of the revisions before the split.
[13:17] <luks> just a few lines above I explained that something like that is not possible :)
[13:18] <workthrick> hehe
[13:18] <luks> you can make a new branch, without the revisions
[13:18] <luks> but the revisions you want to keep will not be identical, they will just look similar
[13:18] <davidoc> oops!
[13:19] <davidoc> So how would I do that?
[13:20] <luks> I don't know of any straightforward way, unfornatunatelly
[13:21] <pigmej> is there any way to get from python api revisions where single file was changed ?
[13:21] <davidoc> Oh well. I suppose I can manually create a new repo with the files as they were at the time of the split.
[13:22] <Tak> pigmej: yes
[13:23] <Tak> log.find_touching_revisions()
[13:24] <pigmej> Tak: hmmm
[13:24] <luks> I wouldn't use log for that, but on the other hand I don't know what's the currently used API for that
[13:24] <pigmej> log is for whole branch ?
[13:24] <Tak> I'm sure it can be done by walking the revision tree if you prefer
[13:25] <Tak> pigmej: it also accepts a file id
[13:25] <luks> Tak: it can be done without walking the whole tree, every file has it's own tree stored
[13:26] <luks> I just don't know the current API
[13:26] <Peng_> What the? My Loggerhead instance is freaking out. "built revision graph cache: 3762.8832850456238 secs", and it's out of idle workers.
[13:26] <Peng_> It's good to know that condition doesn't melt my VPS. :)
[13:26] <pigmej> becouse i'm afraid that checking whole tree will be wrong idea ( becouse of performance )
[13:27] <Peng_> It doesn't want to shut down, either, but that hardly makes it worse... :P
[13:29] <DrHalan> hey, i want to check out a PPA in launchpad with olive. What url do i have to use for "branch"?
[13:30] <luks> lp:bzr-gtk
[13:30] <luks> oh wait, PPA?
[13:30] <luks> do you want to install olive from PPA or get the developmnent branch of olive?
[13:31] <DrHalan> no i want to modify a package in an PPA using olive. Isn't that possible?
[13:31] <luks> not sure if I understand, sorry
[13:32] <luks> PPA is a way to build ubuntu packages, it has nothing to do with olive
[13:32] <pigmej> Hmm in docs I find only logs method...
[13:33] <DrHalan> ah okay thanks luks
[13:44] <pigmej> the fastest way to get revision message ( commit message )
[13:44] <pigmej> revtree=repo.revision_tree(rev_id)
[13:44] <pigmej> revision=revtree.inventory
[13:44] <pigmej> revision.message ?
[13:49] <luks> repo.get_revision(rev_id).message
[13:49] <luks> or get_revisions if you need more of them
[13:50] <luks> calling get_revision multiple times is way slower than get_revisions
[13:53] <Peng_> D'oh, I think I killed Loggerhead at the exact time when it started killing the hung threads itself.
[13:58] <pigmej> luks: thanks
[13:58] <pigmej> i need to call it more than one time
[14:23] <mattions> jelmer: I've upgraded bzr to the latest released and also the bzr-svn
[14:23] <mattions> but still my svn password is not cached
[14:23] <mattions> I checkout the repository directly with bzr, not svn
[14:23] <jelmer> mattions: Did you force svn to cache the password?
[14:23] <mattions> can be that the problem?
[14:24] <mattions> I run svn ls <url>
[14:24] <mattions> but it doesn't ask for the password
[14:24] <mattions> is it correct?
[14:24] <jelmer> mattions, ah, you only need passwords for committing?
[14:25] <mattions> yeah
[14:25] <jelmer> mattions: So I guess you would have to do a commit with svn first
[14:26] <mattions> but the problem is the directory is not a working copy of svn
[14:26] <jelmer> mattions: That's a workaround unfortunately
[14:26] <mattions> ok, so you suggest
[14:26] <mattions> wipe out everything
[14:26] <jelmer> mattions: There's a bug in bzr itself that makes it doesn't support password caching
[14:26] <mattions> checkout with svn
[14:26] <jelmer> mattions, no, just make a temporary checkout with svn and do a commit therre
[14:27] <jelmer> mattions, then remove that temporary svn checkout
[14:27] <jelmer> and everything should work
[14:27] <mattions> or right, I'll give a go
[14:29] <mattions> no, it doesn't work
[14:29] <mattions> it is normal that ask the password 4 times?
[14:43] <msoulot> Hi, I try to download with this command "bzr branch lp:bpierre-config-vim .vim" and I get this error message "You have not informed bzr of your launchpad login. If you are attempting a
[14:43] <msoulot> write operation and it fails, run "bzr launchpad-login YOUR_ID" and try again.
[14:43] <msoulot> bzr: ERROR: Target directory ".vim" already exists."
[14:44] <msoulot> someone can explain me what does it mean, please ?
[14:44] <jpds> msoulot: Try backing up your current vim configuration: mv .vim .vim-backup
[14:46] <msoulot> ok thanks but what this sentence means "You have not informed bzr of your launchpad login. If you are attempting a write operation and it fails, run "bzr launchpad-login YOUR_ID" and try again."
[14:46] <jpds> msoulot: If you have a Launchpad ID, you have register it with bzr doing: bzr launchpad-login <lp-id>
[14:47] <jpds> It probably comes up because you're branching from lp:
[14:48] <jelmer> mattions, sorry
[14:48] <jelmer> mattions, doing a "svn commit" in a svn working copy didn't work?
[14:48] <jelmer> Or it didn't cache the password?
[14:49] <msoulot> I got an account on launchpad and i tried "bzr launchpad-login msoulot@gmail.com" and i got this error message "bzr: ERROR: The user name msoulot@gmail.com is not registered on Launchpad."
[14:49] <Tak> do more recent versions of bzr-svn support externs?
[14:49] <jelmer> Tak: no - it technically can't
[14:49] <jelmer> Tak, since bzr doesn't support externs
[14:50] <Tak> ever?
[14:50] <mattions> jelmer: it didn't cache the password
[14:50] <mattions> it worked
[14:50] <jelmer> mattions, do you maybe have you svn set up to not cache passwords?
[14:52] <mattions> well, how I can discover that?
[14:52] <jelmer> ~/.subversion/config IIRC
[14:52] <mattions> with gnoem svn the password is cached
[14:52] <jelmer> ah
[14:52] <jelmer> we may not be loading that yet for bzr-svn
[14:53] <mattions> default is yes
[14:54] <mattions> so yes is able to cache that
[14:54] <mattions> actually bzr ask me the password 4 times when I do a commit
[14:54] <mattions> 2 times when I do an update
[14:55] <jelmer> so I should fix subvertpy/bzr-svn to also use the gnome keyring svn auth provider
[14:55] <mattions> but here I am using another subversion
[14:56] <mattions> not GNOME related
[14:56] <mattions> I never tried to use bzr with GNOME svn
[14:56] <jelmer> you're using svn 1.6?
[14:58] <jelmer> mattions, so bzr asks for a password when updating and svn does not?
[14:58] <mattions> yes
[14:58] <mattions> svn 1.5.1
[15:00] <jelmer> mattions: Can you access the root of the svn repository without a password?
[15:01] <mattions> no, I need to authenticate to access the svn
[15:01] <mattions> is not public
[15:03] <jelmer> hmm, so the password *is* cached by svn but not found by bzr?
[15:06] <mattions> exactly
[15:07] <mattions> another interg ont eh temporary checkout if I use bzr to update or commit
[15:07] <mattions> the password is not requested
[15:09] <SamB> hey ... does anyone know of an (unofficial) debian package for baz-import ?
[15:10] <luks> isn't baz-import in bzrtools?
[15:10] <SamB> seems to be omitted :-(
[15:11] <luks> are you sure? because I see it in http://packages.debian.org/sid/all/bzrtools/filelist
[15:11] <mattions> ops, I've seen the sentence I wrote before is a little bit mispelled
[15:11] <Peng_> msoulot: Use your LP username (like in https://launchpad.net/~username), not your email address.
[15:11] <mattions> I wanted to say that from the temp checkout the password is not requested for the update or the commit
[15:13] <SamB> huh ... I guess that's what I get for using experimental :-(
[15:14] <SamB> ... but pybaz is apparantly not available anymore anyway?
[15:14]  * SamB doesn't use experimental for much, just a package here and there
[15:14] <jelmer> mattions, can you check where the password is cached?
[15:15] <jelmer> luks, SamDB: It's no longer in bzrtools
[15:15] <jelmer> was removed recently
[15:15] <luks> well, it is in 1.5 :)
[15:15] <jelmer> luks, yes, aaron split it out
[15:15] <luks> and (sane) debian has 1.5
[15:15] <jelmer> squeeze won't
[15:16] <jelmer> mattions, I would expect ~/.subversion/auth
[15:16] <mattions> yes is there
[15:17] <jelmer> mattions, what version of subvertpy are you using?
[15:18] <mattions> (0, 6, 1)
[15:22] <mattions> jelmer: on synaptic the package (python-subversion) shows up as 1.5.1dsfg1-1ubuntu
[15:22] <jelmer> mattions, python-subversion is not used by bzr-svn
[15:22] <jelmer> and not the same thing as subertpy
[15:22] <SamB> try looking at the bzr-svn package in synaptic?
[15:22] <SamB> then go from there?
[15:23] <mattions> I installed bzr from the PPa
[15:24] <mattions> but if I search for the subvertpy I can't find the package
[15:24] <joem86> hello everyone.
[15:24] <SamB> hmm, bzr-svn used to depend on python-subersion
[15:24] <jelmer> mattions, python-subvertpy
[15:24] <jelmer> SamB, no longer as of 0.4.10
[15:24] <joem86> I installed bzr-gtk on ubuntu 8.10 from the default repository. Do I need to logoff and login to use nautilus-bzr?
[15:24] <SamB> jelmer: that's odd
[15:24] <SamB> 0.4.10-2 seems to ...
[15:25] <jelmer> SamB, maybe 0.4.11
[15:27] <mattions> jelmer: 0.6.1-1~ppa1~intrepid1
[15:28] <jelmer> mattions, Hmm, no idea then sorry
[15:28] <jelmer> gtg
[15:28] <mattions> k, no probl
[15:32] <SamB> jelmer: it looks like the BzrTools wiki page needs to be updated to point at the new home of baz-import
[15:33] <SamB> (since a number of other pages link there in connection with baz-import)
[15:34] <SamB> hmm, what I'd *really* like is support for foreign tla/baz branches
[15:34] <SamB> I actually want to look at emacs' history including merges without having to use tla *shudder*
[16:27] <SamB> is there a nice way to do git-style branch-switching ?
[16:27] <awilkins> SamB: There's the switch command
[16:28] <awilkins> Works best in a checkout of a branch in a no-trees repository
[16:28] <awilkins> (lightweight for preference)
[16:28] <SamB> huh.
[16:28] <awilkins> It will locate siblings so you can do
[16:28] <awilkins> bzr switch foo  # my repo contains foo and bar and I am in a checkout of bar
[16:29] <awilkins> It doesn't have the "branches hidden inside your clone" thing
[16:29] <awilkins> This is a point of contention for some.
[16:29] <awilkins> I myself don't mind it but think it would silence many critics if there was a way of supporting either method
[16:31] <SamB> is there a howto somewhere?
[16:36] <awilkins> Off the top of my head, I can't recall. It goes.... i) make a no trees repo (with bzr init-repo) ii) branch something you are interested in into it iii) make a branch for a feature iv) use bzr co --lightweight to grab a working tree of it v) switch that at will
[16:46] <gnomefreak> what bzr app includes bzr-handle-patch? I'm guessing what ever one it is causes my context menu to have "open" on top(nothing ever opens and than have "open with"(is all i want to use open for)
[16:47] <gnomefreak> ah bzr-gtk
[17:01] <SamB> peculiar! the wiki is making empty <span class="anchor" id=...> elements instead of using <a id=...> or <a name=...> ...
[17:09] <jpds> Goes anyone know where the error at http://paste.ubuntu.com/127303/ could be from?
[17:10] <awilkins> A proxy? The web server?
[17:35] <SamB> awilkins: I made a wikipage at http://bazaar-vcs.org/GitStyleBranches -- I wonder if the HOWTO I desire will magically appear ?
[18:13] <gnomefreak> here is the command and output. it should not try to grab upstream tarball since i already have it. looked in changelog nad it is how it should be. http://pastebin.mozilla.org/631007
[18:13] <ignas> hi
[18:14] <ignas> can I make a stacked branch  when branching from a branch stored in a shared repository?
[18:15] <Peng_> ignas: Sure?
[18:16] <ignas> Peng_: then why am I getting
[18:16] <ignas> Source format does not support stacking, using format: '1.6'
[18:16] <ignas>   Packs 5 (adds stacking support, requires bzr 1.6)
[18:16] <ignas> while on the server i am getting: bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format.
[18:16] <Peng_> Does it still work?
[18:16] <Peng_> And when are you getting that error? When you try to "bzr upgrade"? That's because the default format is pack-0.92. 1.6 is newer.
[18:17] <Peng_> I don't know about stacking, so I can't help much. Does the source repository have to support it?
[18:17] <ignas> oh, so if I want the newer format I must upgrade to the newer format explicitly?
[18:18] <ignas> something is weird, both the stacked branching and lightweight checkout (i am doing it through http) are trying to download the full repository
[18:18] <ignas> and i don't really want to have to do that (it's 70 megabytes)
[18:21] <Peng_> I doubt it will download the entire repository, but it will have to download quite a bit of it to pull out all of the data it needs.
[18:29] <ignas> Peng_: kind of annoying, as that bit is like 20 megabytes, but it's downloading it at 30 kb/s, while checking out does 70mb at 200kb/s so I kind of don
[18:30] <ignas> don't know what I am gaining ;)
[18:48] <ignas> ok, seriously, bzr co --lightweight took 6 minutes and takes up 18 mb, bzr co took 5 minutes and takes up 51 mb (got 200kb max download speed)
[18:49] <ignas> seems like lightweight checkouts are of any use only if you are very very bandwith constrained, and will do only 1 checkout ever
[18:50] <ignas> if you want to get a branch of the same project too - shared repository will be both more space and bandwith and time efficient than 2 lightweight checkouts...
[18:51] <Peng_> What about "bzr branch --stacked"?
[18:52] <Peng_> 1.) Like I said, I don't know much about lightweight checkouts or stacking. 2.) This really sounds atypical. What version of bzr are you using? It's probably been improved (especially in the release coming up next).
[18:52] <ignas> it is doing at least as much work as lightweight, but I don't want to spend the 6 minutes to find out for sure
[18:52] <ignas> bzr 1.12
[18:52] <ignas> and my project has a looong history
[18:52] <Peng_> Huh.
[18:53] <Peng_> Well, I'm surprised, but I don't have anything else to add.
[18:53] <ignas> it's quite sad, but I am not surprised
[18:53] <Peng_> Erm, how did you count how much bandwidth was used?
[18:53] <ignas> bzr has a progress bar that shows how much was downloaded
[18:54] <ignas> also du -sh matches that number
[18:54] <ignas> for a lightweight checkout at least
[18:54] <ignas> mostly matches ;)
[19:31] <ericvw> To any developers available, will Bazaar be participating in Google Summer of Code?
[20:25] <BasicOSX> Any bazaar developer launchpad team members online? I volunteered to be  the manager for 1.13 and I need a developer to push the changes into PQM
[20:31] <jfroy> whoa, there seems to be some issue with adding large files in bzr.dev
[20:31] <jfroy> I just added a 166 MB file to a branch, and Python shot upward of 1 GB of real memory before completing
[21:26] <jam> morning igc
[21:26] <poolie> hello
[21:28] <jam> hi poolie
[21:29] <jam> I'm a bit surprised to see you around on your weekend
[21:29] <jam> trying to get the 1.9 patch finished?
[21:29] <igc> hi jam, poolie
[21:29] <poolie> and to help bob tanner
[21:29] <poolie> i have to go out so i don't know if i can finish it today :/
[21:29] <jam> igc: I responded to a couple of your bbc patches
[21:29] <igc> jam: thanks very much for working on the chk-map bug. I'm testing it now
[21:30] <poolie> i was kinda hoping someone would look at the traceback and say "oh, obviously you just need x" :-)
[21:30] <jam> I also have a proposed patch which might help your performance
[21:30] <jam> as InventoryDirectory.children() didn't seem to be using _entries_cache properly.
[21:30] <jam> poolie: well I did see you return unconditionally true for Remote*
[21:30] <jam> which seemed a bit fishy to me
[21:31] <poolie> it was previously unconditionally false :/
[21:31] <poolie> since that class inherited the default
[21:31] <poolie> that seems so strange though
[21:31] <jam> judging by the test name
[21:32] <jam> it looks like we should be using an old-format
[21:32] <jam> and have it not try to stack *at all*
[21:32] <jam> and it is checking, and naturally failing
[21:32] <jam> did we get rid of a 'clone_on_transport' implementation?
[21:34] <igc> jam: so I got two patches with the same name - one at 7.20 and one at 7.23 (it's 7.34 now)
[21:34] <jam> igc: one is against bzr.dev
[21:34] <jam> the other against brisbane-core
[21:35] <igc> jam: do I just apply the last one then?
[21:35] <jam> mailman thoughtfully noticed that the first patch was 800k+
[21:35] <jam> igc: yeah
[21:35] <igc> to brisbane-core?
[21:35] <jam> they are the same content
[21:35] <igc> ok
[21:35] <jam> (bazaar@ rejected my first post as being too big)
[21:40] <poolie> jam, yep, in trunk RemoteBranch definitely always says it doesn't stack
[21:42] <jam> poolie: So _ensure_real() seems the right trick, but in the end, I think that would require doing "bzr branch lp:XX lp:YY" for it to ever come into play
[21:43] <poolie> i think this test is actually branching one remote branch to another
[21:43] <poolie> hm
[21:43] <poolie> i guess it would be better to avoid ensure_real and to use the network name, if we know it, to find the equivalent local format object and then ask that
[21:44] <jam> poolie: isn't that what _custom_format is about?
[21:44] <jam> Anyway, to get things *landed* I would go with _ensure_real()
[21:44] <jam> rather than spending a lot of time, the day of an RC
[21:44] <jam> Or set it back to False if that doesn't cause other problems
[21:45] <jam> poolie: ah you know what... that sort of makes sense. We are testing that if the source format is too old, we don't try to stack.
[21:45] <jam> And then it is layering RemoteBranch on top of that
[21:45] <jam> and by changing False => True
[21:45] <jam> it is now trying to stack, even though the real format doesn't support it
[21:45] <jam> and thus the test is failing
[21:51] <poolie> you're talking about test_clone_ignores_policy_for_unsupported_formats?
[21:51] <jam> poolie: that is the test you showed was failing, yet
[21:51] <jam> yes
[21:52] <fta> anyone working on a fix for the md5/sha Deprecation Warnings /w python 2.6 in jaunty?
[21:53] <jam> fta: I thought vila had a fix for that a while back
[21:54] <jam> fta: specifically, I see code like:http://paste.ubuntu.com/127469/
[21:54] <jam> It may just be that the version in Jaunty is older than that patch
[21:54] <jam> fta: what version is there?
[21:54] <jam> (It could also be that there is other code that is importing md5/sha1 that we missed)
[21:54] <fta> !info bzr jaunty
[21:54] <jam> bzr --version
[21:55] <jam> I would have thought 1.12 had that... :(
[21:55] <poolie> there are a couple of them with similar failures
[21:55] <poolie> but all i think to do with the intersection of policy with old formats
[21:55] <poolie> hm, i should have checked what that test does in trunk
[21:55] <poolie> maybe it just skips
[21:55] <poolie> ah ok, i see now what you meant about ensure_real
[21:55] <poolie> possibly it should fall back to ensure_real if it doesn't know the custom_format
[21:55] <jam> fta: though I also saw some discussion about things like bzr-pqm causing the problem
[21:55] <poolie> but the thing is this is called on the format, not the branch
[21:55] <jam> and that just required another jaunty update
[21:55] <jam> because it was an old python package
[21:56] <jam> poolie: so punt and just continue to return False
[21:56] <poolie> fta, i have a bug about it in python-crypto
[21:56] <jam> RC is *today* anyway :)
[21:56] <poolie> jam, i'll try it
[21:56] <poolie> if it actually works its fine but i think i had more failures that way
[21:58] <igc> jam: your patches have improved things a lot thanks
[21:58] <jam> igc: /cheer
[21:58] <jam> If the directory cache helps
[21:58] <jam> go ahead and land it
[21:58] <jam> I just wanted someone to actually run the code before I did
[21:59] <igc> jam: *but* we're still slow - 1m6s vs 40s for gc-chk255  vs 1.9 over 1k revision in wordpress
[21:59] <jam> igc: If you are having to call iter_entries()
[21:59] <jam> then you are going to probably be slower
[21:59] <jam> why do you need to read the whole inventory?
[21:59] <igc> that's with all your patches ad my iter_non_root_entries() which is still a big win
[21:59] <jam> (That kind of code is what got us into trouble in the first place)
[22:00] <igc> well, the inventory layer is now ok
[22:00] <igc> The time is evenly spread around chkmap.apply_delta
[22:01] <jam> igc: If you want, you can try setting _FAST = True in groupcompress.py
[22:01] <jam> And see how much that effects things
[22:01] <igc> jam: tell me about parent_id_basename_to_file_id is a good idea
[22:01] <igc> jam: I see you're planning to make it non-optional
[22:02] <jam> igc: it is already non optional
[22:02] <jam> all formats have it
[22:02] <jam> --dev3 was the only one that didn't
[22:02] <jam> and robert and I agreed it could just go
[22:02] <igc> thinking out loud, do we really need it for 1000s of historical revisions or could we generate it the first time it was required?
[22:02] <jam> igc: it changes only when you have a rename/add/delete
[22:02] <jam> so for 1000s of revisions, you get 10 changes
[22:02] <jam> not a lot of overhead
[22:03] <igc> jam: well every revision has one of those doesn't it?
[22:03] <jam> igc: every revision has one, but they are all the *same*
[22:03] <igc> jam: how does it speed lookups?
[22:03] <jam> the root chk pointer doesn't change
[22:03] <jam> unless the tree shape changes
[22:03] <jam> (rename/add/delete)
[22:04] <jam> igc: for a specific example, the python 40k revisions, has about 300k entries in id_to_entry, but only 12,000 in parent_id...
[22:05] <jam> igc: it speeds up mapping "path" => file_id
[22:05] <jam> id_to_entry is purely file_id => entry
[22:05] <jam> so you have to find an entry
[22:05] <jam> then load its parent
[22:05] <poolie> jam, ok, changing it back to return false from supports_stacking seems to be making things pass
[22:05] <poolie> fingers crossed
[22:05] <jam> etc
[22:05] <poolie> probably by just not running those tests :/
[22:05] <jam> More importantly, to go from a parent to its children
[22:06] <jam> you have to iterate the *whole* inventory
[22:06] <jam> poolie: no, it says "clone ignores stacking"
[22:06] <jam> and it passes
[22:06] <jam> poolie: because you said it doesn't support stacking
[22:06] <jam> thus we ignore the stacking policy
[22:06] <igc> jam: path2id for CHKInventory is currently a copy of the code in Inventory?
[22:06] <poolie> ok so not literally TestSkipped
[22:06] <poolie> but it's not testing the real case which is that the remote branch may in fact be stacked
[22:07] <jam> igc: The issue is *specifically* InventoryDirectory.children()
[22:07] <jam> if you look at the code path I "removed"
[22:07] <jam> it walked the whole inventory
[22:07] <jam> looking for "entry.parent_id == self.file_id"
[22:07] <jam> because we don't have that info stored any other way
[22:07] <jam> without the parent_id_basename_to_file_id map
[22:08] <jam> poolie: I don't know what other tests you are looking at, but the one you posted as failing
[22:08] <jam> isn't doing that
[22:08] <jam> I'm sure there are others that probably fit what you describe
[22:08] <jam> and I think it would be great to address them in 1.14 :)
[22:09] <igc> jam: ok  - children lookup certainly needs to be fast
[22:09] <igc> jam: I'll land your chkinventory-children patch now
[22:21] <jam> igc: I keep forgetting to ask... How's the weather in brisbane?
[22:22] <Turl> hi
[22:22] <Turl> I'm getting some warnings about md5 and sha python modules, I thought you would like to know
[22:23] <igc> jam: absolutely beautiful right now
[22:23] <Turl> that modules are deprecated (the warning says that) and you should use 'hashlib' now
[22:23] <jam> poolie: I just tried to update the BrisbaneCore page with some ideas about "major blockers". I don't know that I got everything, and it probably isn't fully polished. But that is what I've thought of so far
[22:24] <jam> Turl: there seem to be some issues with the python-crypto package in Jaunty
[22:24] <jam> which we depend on
[22:24] <jam> hopefully that will get resolved soon
[22:24] <jam> igc: What's the temp? (So I know what clothes to pack)
[22:25] <igc> jam: looks like there's some rain on the way but otherwise nice: http://www.bom.gov.au/products/IDQ10095.shtml
[22:25] <Turl> ok jam, I thought I would let you know about this :)
[22:25] <jam> igc: I should also mention that jelmer found brisbane-core to be *vastly* faster for bzr-svn converting OOo. Something like 30hrs to do a full conversion, versus 30hrs for the first 10k revisions.
[22:26] <jam> Turl: thanks. It is a known issue, though I haven't personally followed closely.
[22:26] <poolie> great
[22:27] <Turl> np jam
[22:27] <poolie> that was bug 337073
[22:27] <igc> am: I saw that result from jelmer - it's very promising
[22:27] <igc> jam: ^^^
[22:27] <jam> igc, poolie: have a good day. I'm done for now. I may sign on later tonight just to do a quick review before I leave tomorrow, but no guarantees
[22:27] <jam> igc: so that brings back the question of why you ever have to deal with the whole inventory.
[22:28] <jam> igc: I should also mention that "time bzr fast-export" of my mysql-525 stuff was down around 1 minute. which is == git fast-export on the same data
[22:28] <jam> igc: that said, "time bzr repository-details" which extracts everything to fultexts, and analyzes chk pages
[22:28] <jam> is 15s
[22:28] <jam> so there is still some room
[22:28] <jam> (just extracting the texts, with no sha sums, etc, is around 6s)
[22:28] <igc> jam: yes, fast-export seems pretty good and I've done zero profiling/tuning on it
[22:28] <abadger1999> Is there someway to turn off ensure_config_dir() ?
[22:28] <abadger1999> ensure_config_dir_exists()
[22:29] <igc> jam: I'm only dealing with the whole inventory when loading texts. I'll see what the latest repo code does there
[22:29] <poolie> jam, ok, have a good night
[22:29] <poolie> i have to go and run some errands
[22:30] <poolie> that test is still failing
[22:30] <poolie>  i may poke at it later but it may miss at least rc1 as i expect bob will do that soon
[22:31] <abadger1999> we're working on a server that submits to a bazaar repo.  It runs as apache.
[22:31] <abadger1999> When we run this: work_tree.smart_add([self.path]) It tries to create a .bazaar directory in apache's home dir.
[22:31] <igc> jam: _install_revision still walks the whole inventory via iter_entries()
[22:32] <igc> jam: fast-import uses a parameterized version of that code
[22:32] <jam> igc: consider how InterDifferingSerializer does it
[22:32] <jam> which is able to use _make_delta etc and not need full inventories
[22:32] <jam> I don't know what you need, I just know that if you have to walk the whole inventory
[22:32] <jam> things will be slow
[22:32] <jam> so we need to think if there is a way around it
[22:34] <igc> jam: right. I'm not sure whether jelmer was going via repo.install_revisions() or not
[22:35] <igc> if he was, he would have hit the iter_entries() speed issue that existed until just now?
[22:37] <jelmer> igc: no, I'm not using repo.install_revisions()
[22:38] <jelmer> igc, I'm using add_revision(), create_by_apply_delta() and directly accessing the texts VFs
[22:42] <igc> jelmer: so IIUIC, install_revisions() is walking the inventory to build the per-file-graph? Are you doing that some smarter way?
[22:43] <jelmer> igc: bzr-svn stores the per-file graph
[22:43] <jelmer> and for non-round-tripped revisions, subversion provides the necessary data
[22:44] <igc> so the OOo conversion to development5 only works if bzr-svn is used?
[22:48] <jelmer> igc: Not sure I understand
[22:49] <rocky> jelmer: ping
[22:49] <jelmer> igc: The conversion doesn't require round-tripped-revisions or anything, it works with a vanilla OOo SVN repo
[22:49] <jelmer> rocky, pong
[22:50] <rocky> jelmer: i decided in an effort to force myself to understand things more i would rewrite get_history() for BzrFileNode in TracBzr (ti's currently what's breaking on bzr 1.12 anyways) ... and i've getting a better understanding such that i can populate the log view properly...
[22:51] <rocky> but my revision identifiers are nasty ... they are branchpath,fileid
[22:51] <rocky> and in the trac log view that looks horrible
[22:51] <jelmer> rocky, branchpath,revid?
[22:51] <rocky> sorry yes
[22:51] <rocky> the branch path is fairly long, and the revision_id is huge
[22:52] <rocky> so it really messes up the log view display
[22:52] <rocky> is there a more sane way to reference a rev?
[22:54] <igc> jelmer: I'm trying to work out how you converted the OOo repo so quickly to development5-subtree format
[22:55] <igc> jelmer: fast-export is currently slower on the new formats
[22:55] <igc> s/export/import/
[22:55] <jelmer> igc, ah
[22:55] <jelmer> igc, yes, bzr-svn would be required for the improved performance
[22:55] <jelmer> rocky, path,revno?
[22:56] <rocky> what's the diff between a revno and a revision_id ?
[22:56] <jelmer> igc, I was also using an improved version of brisbane-core, with another patch
[22:56] <jelmer> rocky, a revno is smoething like "2"
[22:56] <jelmer> rocky, a revision id is something like "jelmer@samba-org-20083424782362386-0fjksdhgfkjsdh"
[22:58] <rocky> jelmer: right, i understand that they look different but what i mean is what limits one versus the other... why have a revno and a revid ?
[22:59] <jelmer> rocky, revno is more human readable
[22:59] <jelmer> rocky, it's only unique to a particular branch though
[22:59] <jelmer> revid is used internally in Bazaar and globally unique
[23:00] <jelmer> also, revno's are sortable
[23:00] <jelmer> so revno 42 is always older than revno 43
[23:00] <rocky> so revid's are meant to be actual uuid's ?
[23:01] <jelmer> rocky, they are globally unique but not like RFC4122
[23:01] <rocky> define "global" :)\
[23:02] <jelmer> rocky, e.g. bzr-svn uses the UUID of the svn repository and the revision number of the subversion commit for the bzr revid
[23:02] <jelmer> rocky, global as in the same revid is supposed to always point at the same revision
[23:02] <jelmer> independent of what branch or repository it is in
[23:03] <jelmer> rocky, e.g. try running "bzr log --show-ids" in one of your branches
[23:03] <rocky> ah cool
[23:13] <rocky> jelmer: ok, in any event, the log view works now and doing diff between revs on log view works and clicking on a rev link works... bt clicking on a changeset link doesn't yet work
[23:14] <jelmer> cool
[23:15] <rocky> jelmer: here's a question... in a branch, does revno *have* to start with 1 and is it guaranteed not to skip revno's ?
[23:15] <jelmer> rocky, there are functions in bzr for looking up the revno
[23:15] <jelmer> rocky, ideally you should be using those rather than calculating them yourself
[23:16] <jelmer> that would also do caching when it's available
[23:16] <rocky> i'm only asking because i found code inside bzrlib that is adding up it's revno's by itself ;)
[23:16] <rocky> in bzrlib.log
[23:16] <jelmer> they can also get quite complex if they're not on the mainline
[23:17] <rocky> the whole dotted revno thing right?
[23:17] <jelmer> yeah
[23:45] <jelmer> igc: This is all the more reason to move this logic into a Importer object in bzrlib :-)
[23:50] <igc> jelmer: Agreed! Once I get this version working fast, I'll do that. Next week's sprint will be a good time to talk to lifeless and jam about it