[00:11] <lifeless> spiv: FWIW I think RemoteRepository really wants to be a Repository subclass; but lots of Repository stuff wants to be on other subclasses
[00:11] <spiv> Yeah, I think RemoteRepository wants to be a subclass too.
[00:18] <lifeless> poolie: I've popped up for air; its going really well.
[00:18] <poolie> great
[00:20] <lifeless> poolie: if you want a call; now is a good time for me.
[00:21] <poolie> sure
[00:21] <lifeless> and to the crowd in general, review sought on [MERGE] New development format (unchanged) and alias support for format
[00:21] <lifeless> poolie: I'll call in a sec
[01:36] <poolie> lifeless, did you say something the other day about the feisty bzr repo being out of date
[01:36] <poolie> (as in https://answers.launchpad.net/bzr/+question/21602)
[01:47] <core-ix> i have a question about bazaar vcs: does it support user rights (access to branches like read/write) and secure communication over the internet (i.e. SSL/TLS) ?
[01:47] <poolie> core-ix, yes, you can do access control either through the 'bzraccess' hook, or by OS permissions on the repo
[01:48] <poolie> and you can use either bzr+ssh, sftp, or https for encrypted access
[01:49] <core-ix> ok, thanks poolie ... i'm choosing new VCS for several projects and i need those features i mentioned before
[01:49] <lifeless> poolie: yes, on my todo
[01:49] <lifeless> poolie: I should get to it today I hope; I figure its not life or death right now
[07:47] <indu> hiall
[07:47] <indu> hi all
[07:55] <indu> in loggerhead, i want the Log, Inventory, RSS,Repository under the branch itself , means, how can I  do it?
[07:55] <indu> just similar to http://goffredo-baroncelli.homelinux.net/bazaar-dev
[08:04] <indu> how can i improve my loggerhead look similar to http://goffredo-baroncelli.homelinux.net/bazaar-dev
[08:04] <indu> mwhudson, can you help me in this please
[08:48] <indu> Do I need to use redirect option of apache for this ?
[08:51] <indu> mwhudson, are you there
[08:51] <indu> anyone please tell me where can I get help in loggerhead,
[09:00] <poolie> indu, from mwhudson,
[09:00] <poolie> or i suggest you use the list or http://answers.launchpad.net/bzr
[09:01] <indu> poolie, he is in leave till feb 4th itseems
[09:01] <poolie> indu, i'm not sure but i think that page is actually running the webserve plugin
[09:01] <poolie> which is different to loggerhead
[09:11] <ubotu> New bug: #180969 in bzr "export to a non-existing directory failed" [Undecided,New] https://launchpad.net/bugs/180969
[10:07] <TFKyle> hmm, for some reason bzr pull lp:someproject doesn't work here (tries to use a local dir /cur/path/lp:someproject/) even though bzr ls lp:someproject does, is there a reason for that? (bzr 1.0 and 1.1rc1)
[10:35] <poolie> TFKyle, that is strange, could you please file a bug on http://launchpad.net/bzr ?
[11:25] <siretart> 'bzr get lp:bzr' takes about 5 minutes. is this 'normal'?
[11:25] <siretart> feels quite slow
[12:35] <vila> abentley: BB down since more than 12 hours now
[12:38] <abentley> vila: Thanks.  Restarted.
[12:50] <ubotu> New bug: #180996 in bzr "bzr checkout fails with 'No buffer space available'" [Undecided,New] https://launchpad.net/bugs/180996
[12:52] <indu> anyonw here again now, who has idea about loggerehad configurations
[12:55] <indu> could some one give me the path for webserve, download
[12:59] <indu> is there a way of receiving a mail when someone uploads some source into my repo
[13:06] <vila> abentley: thanks to you ;-)
[13:06] <abentley> np
[13:09] <vila> abentley: now, that I can access it again, I notice you voted tweak on http://bundlebuggy.aaronbentley.com/request/%3Cm2fxxl1yzv.fsf@free.fr%3E
[13:10] <vila> but I *never* saw the email ???
[13:10] <abentley> Yeah, it's a problem because I changed my email, but BB wants to use the wrong one.
[13:11] <abentley> Which Mailmain no longer recognizes as a subscriber.
[13:12] <vila> abentley: ok ok
[13:12] <abentley> So for now, I can only vote by mail, which I didn't realize then.
[13:13] <dennda> http://paste.pocoo.org/show/19892/ <-- Any thoughts on how to resolve that?
[13:20] <dennda> works again
[13:20] <dennda> magic
[13:30] <Peng> dennda: Perhaps you had another bzr process running?
[13:32] <dennda> maybe
[13:51] <lifeless> indu: perhaps ask on list
[13:51] <lifeless> indu: I suspect people are not understanding the question.
[13:51] <lifeless> ngiht all
[16:02] <mgedmin> I don't suppose there's a vcscommand vim plugin for bzr?
[16:04]  * mgedmin settles for bzr get lp:bzr-vimdiff ~/.bazaar/plugins/vimdiff
[16:09] <mgedmin> why does 'bzr st' print paths that aren't valid in the current directory, when you're not in the root of a working dir?
[16:11] <Peng> Yeah, it prints paths relative to the root.
[16:12] <Peng> God knows who made that choice and why.
[16:12] <Peng> There's at least thought of changing it.
[16:12] <mgedmin> I think I vaguely remember a discussion about this, maybe on the mailing list
[16:12] <mgedmin> today it bit me, and I wanted to ask here before filing a bug report
[16:26] <Peng> Yeah, mailing list.
[16:28] <mgedmin> do you perchance have a url/date + subject?
[16:28] <Peng> Nopers.
[16:36] <asac> lifeless: is bzr init without any repo format option what i should use for large projects/max speed nowadays (latest 1.1.0.dev.0)?
[16:43] <vila> asac: yes
[16:49] <dlee> Got a bzr bind that stalls seemingly forever (until I kill it), but a bzr push to the same repo works fast.  The repo is a bzr:// one where the marchine name maps to a VPN-accessible subnet.  Since bzr push works, I figure it's not a connectivity problem though.  Bzr 1.0.
[18:29] <salgado> hey there
[18:29] <salgado> is there any easy way to find the latest N revisions which touched a given file?
[18:30] <luks> bzr log path/to/file --limit N
[18:31] <salgado> that easy!?
[18:35] <salgado> thanks luks. I hadn't notice I could use 'log' on a file/dir
[18:35] <luks> well, log on a dir will probably not do exactly what you expect
[18:35] <luks> but on a file it should work fine
[20:45] <dlee> Re my earlier issue with bzr bind hanging where bzr push works fine:  bzr tags -d <same_repo> also hangs.  Ideas for what to look for welcome.
[20:54] <vila> dlee: have a look at $HOME/.bzr.log, then you can also try -Dhpss
[20:59] <dlee> Doing...
[21:01] <lifeless> moin
[21:08] <dlee> Results: Stall after "ok" result from repository.get_revision_graph; sending SIGINT gives a traceback in the log.
[21:19] <lifeless> dlee: file a bug please
[21:22] <dlee> Will do
[21:28] <dlee> Etiquette questions btw: Is it best to check here before filing a bug, or just to go file and ask later?  Also, I park here to ask and (when I actually know enough) answer questions.  I'm not a Bazaar developer though (if I learn a bit of Python this may change...).  Please let me know if there's a better way before I unwittingly become a pest. :)  (I say all this because, for whatever reason, many questions I've asked since the day I fil
[21:28] <beuno> dlee, asking for help and before filing a bug is just fine
[21:29] <beuno> it's a bzr-in-general channel
[21:29] <dato> dlee: (your line broke up at "the day I fil")
[21:30] <dlee> Arg... my client shows it all. :P thanks for the catch
[21:30] <dlee>   filed the cvsps-import_under_Cygwin bug have drawn no comment)
[21:30] <lifeless> dlee: I'd rather you file a bug than the issue go unknown by folk who are coding; asking here first is good but if its inconclusive please do file a bug
[21:31] <lifeless> on IRC people will often not respond if they have no clue
[21:31] <lifeless> so if what you're asking is not obvious you may get no commit ;)
[21:32] <dlee> Lifeless: ok thanks.  I figured silence meant uncertainty, but after a week or so of the same luck, I thought, "I'm too new to find so much new stuff already!" :)
[21:35] <zeasier> are there any bug tracking applications that work with bzr?
[21:36] <zeasier> heard of the trac module but haven't gotten it to work
[21:36] <Peng> Well, there's Launchpad.
[21:36] <lifeless> and trac
[21:37] <lifeless> and cart
[21:37] <lifeless> and bugs everywhere
[21:37] <lifeless> and I think there's a buzilla module for bzr, so you can write a script to interrogate a bzr repo and use that to modify bugzilla
[21:37] <zeasier> launchpad is pretty cool
[21:38] <zeasier> but it isn't for closed source projects
[21:40] <zeasier> never heard of cart and bugs everywhere
[21:40] <Rinchen> Hi folks.  I have a quick question.  When I do a bzr whoami, I get my correct email address (verified in bazaar.conf) but when I do a bzr commit  it uses a different gpg key (from another email address in the ring).  Ideas on how I can fix that?
[21:46] <lifeless> zeasier: you should talk to 'statik'
[21:47] <zeasier> just found the cart thread in lists.ubuntu.com
[21:47] <zeasier> looks interesting
[21:47] <lifeless> Rinchen: you can set a gpg signing command
[21:47] <lifeless> Rinchen: possibly there are other gpg options; have you looked in the manual ?
[21:48] <Rinchen> lifeless, I've been scanning through it now
[21:48] <Rinchen> so far, no luck
[21:52] <lifeless> abentley: still thinking about annotating inventory changes? I'm thinking that this format can generate revision markers for execute bit/sha/name/parent etc quite easily during composition
[21:52] <lifeless> abentley: course at the start of a new delta chain it would be all new :(
[21:54] <lifeless> Rinchen: probably the wrong way, but I'd start with gpg_signing_command = gpg --id FOO (or whatever gpg takes as options)
[21:54] <lifeless> Rinchen: I think that that will work
[22:05] <ubotu> New bug: #181115 in bzr "bind and tags hang where push does not" [Undecided,New] https://launchpad.net/bugs/181115
[22:18] <Rinchen> so lifeless, it seems that it was a gpg thing as you suspected.  Looks like seahorse does not actually include the "default-key" option in gpg.conf when you select it (bug maybe) so I had to manually specify that. By default it seems gpg uses the oldest private key to sign with (per a pipermail archive)
[22:33] <lifeless> woo
[22:33] <lifeless> 2 tests failing only (but inter foo is entirely absent)
[22:38] <Peng> Oooh, I forgot that 'bzr branch' uses the branch format of the branch being branched from, not the repo.
[22:41] <Peng> Seems I did have some older branches.
[22:41] <ubotu> New bug: #181123 in bzr-cvsps-import "Tags import as branch tips, not tags" [Undecided,New] https://launchpad.net/bugs/181123
[22:45] <ubotu> New bug: #181124 in bzr "short options for bzr ls" [Wishlist,Confirmed] https://launchpad.net/bugs/181124
[23:00] <abentley> lifeless: No, I'm not actively planning to handle criss-cross inventory merging.  It strikes me that we could apply LCA merge, though.
[23:00] <lifeless> I'll need to read up on lca merge
[23:02] <mtaylor> 24605 mtaylor   18   0 1205m 976m 7928 D   19 32.5   9:06.60 bzr
[23:03] <mtaylor> damn that's a lot of memory
[23:03] <jelmer> what is it doing ?
[23:04] <abentley> lifeless: One way to look at it is 3-way, extended to handle multiple bases.
[23:04] <abentley> If it's really painless, then by all means, include annotation.
[23:05] <abentley> lifeless: Bugs Everywhere and Cart are unfortunately abandoned now.
[23:06] <mtaylor> jelmer: svn-import
[23:06] <mtaylor> jelmer: copying revision 3341/6851
[23:06] <mtaylor> :)
[23:06] <jelmer> ah
[23:06] <jelmer> mtaylor: you did see the link to the python-subversion memory leak fix?
[23:07] <mtaylor> oh, no... is that what that is?
[23:07] <jelmer> I think so
[23:07] <mtaylor> ahhhhh. that would make sense
[23:07] <jelmer> http://subversion.tigris.org/issues/show_bug.cgi?id=3052
[23:08] <jelmer> or the matching Debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=428755
[23:08] <ubotu> Debian bug 428755 in python-subversion "bzr-svn: 'bzr push' consumes memory" [Important,Open]
[23:13] <lifeless> abentley: oh, ok :(
[23:14] <lifeless> abentley: I think InterRepository._same_model is the reason you can pull subtrees into rich roots
[23:15] <abentley> Hrm.
[23:15] <lifeless> it only looks at one of the two parameters
[23:15] <abentley> I'm wondering whether our InterRepository approach is too much LBYL.
[23:16] <abentley> If you look at what we did with diff, for example.
[23:16] <jelmer> abentley: LBYL?
[23:16] <lifeless> well it was intended to be simply a multimethod; the model stuff that has crept in adds confusion I think
[23:16] <lifeless> look before you leap
[23:17] <abentley> lifeless: But perhaps it would be nicer if it you just called interrepo.fetch() on all registered interrepos until it succeeded or you ran out.
[23:18] <abentley> That way, we would have enough data to determine whether a fetch from 'subtrees' into 'rich-root' could succeed.
[23:18] <lifeless> ah, I see
[23:18] <lifeless> so nuke is compatible
[23:18] <lifeless> and do a loop
[23:19] <abentley> Right.
[23:19] <lifeless> I don't think it would make a difference in this case; we need something that knows 'subtrees allowed/not allowed' and raises when it sees them
[23:20] <lifeless> so one interrepository can do all rich-root variations that use the same inventory serialisation API
[23:20] <lifeless> when do you start with Canonical ?
[23:20] <abentley> A fetch from subtrees into rich-root could look for subtrees in the inventories it was fetching.
[23:21] <abentley> lifeless: I start next week.  And I'll be in Sydney the week after.  Too bad I'll miss you.
[23:21] <lifeless> right, and a fetch from subtrees into subtrees needs to look for subtrees in the inventories as well to fetch dependent data doesn't it ?
[23:21] <abentley> Mmm.  Not sure.
[23:22] <lifeless> so a InterSubTree parametereised with either "lambda x: raise NotSupported " or "queue a revision id to copy"
[23:22] <abentley> I think that's right.
[23:22] <abentley> The problem of fetching dependencies was one I had put off.
[23:23] <lifeless> anyhow, I only noticed that as I refreshed my head on InterRepository to do this journalled inventory logic - I need to make sure that all the delta elements are fetched correctly injounralled->journalled, and that revisions are reserialised in journalled<->non-journalled
[23:24] <abentley> injounralled->journalled ?
[23:24] <lifeless> in (journalled->journalled)
[23:24] <abentley> right.
[23:24] <lifeless> a journalled inventory repository has inventory deltas rather than xml deltas
[23:25] <lifeless> cool
[23:25] <abentley> Are you doing unidirectional or bidirectional deltas?
[23:25] <lifeless> minimal unidirectional with full entry contents included
[23:26] <abentley> Also, you were asking about why we're including revision-ids in inventories.
[23:26] <lifeless> that is we write out a new entry and nothing about the old state, and we also write out a line when a delete occurs
[23:26] <abentley> jam could answer that better, but I believe it was a performance win.
[23:26] <lifeless> I was having a brain-fart morning;
[23:26] <lifeless> I'm pretty sure it was for the working tree basis cache
[23:27] <lifeless> so that we didn't have to reserialise the XML
[23:27] <lifeless> which is a bit bogus when you think about it (you can just prefix the repository xml with a revision id). But it doesn't matter anyhow, because I already had a version: field for the journal entry
[23:27] <abentley> Sounds plausible.
[23:28] <lifeless> so, I don't think this journal contents is necessarily optimal; I only claim its better than the xml delta style
[23:28] <lifeless> in fact I may change it to only have the basename of the path
[23:29] <lifeless> because the case where the exact pathname is interesting is insufficient to do things log like PATH or 'find PATH in history'
[23:29] <lifeless> so it doesn't seem like a useful optimisation and it costs quite some duplicate text for the dirname of the path to be included.
[23:31] <abentley> lifeless: Or to be really minimal, you could just include the paths of parents once.
[23:31] <abentley> Since we have the parent-id already.
[23:31] <lifeless> not quite sure what you mean there; how is that different from just the basename of the path ?
[23:32] <abentley> I assume if you have three children of 'foo/bar', you would include 'foo/bar' three times.  Correct?
[23:32] <lifeless> currently yes; it was moddelled on the python inv delta object
[23:32] <abentley> Future: no?
[23:33] <lifeless> Well like I say above I'm considerring dropping it back to just the basename
[23:33] <lifeless> so foo/bar/baz and foo/bar/quux -> 'baz' and 'quux'
[23:33] <abentley> The example I gave had just the basename
[23:33] <abentley> I think we're probably in violent agreement.
[23:33]  * lifeless is confused
[23:34] <abentley> No, my bad.
[23:34] <abentley> I was thinking dirname, not basename.
[23:34] <lifeless> ah!
[23:34] <abentley> Not enough sleep.
[23:34] <abentley> So if the dirname was considered useful at all, a future format could include it only once.
[23:35] <lifeless> e.g. on the dir itself
[23:35] <fullermd> Sorta mtree-style-ish.
[23:35] <lifeless> but that then prevents grep style matching
[23:35] <abentley> The dir itself might be unchanged?
[23:35] <abentley> Therfore not included in the delta.
[23:35] <lifeless> well, I need to keep the stuff I'm working on paged in
[23:36] <abentley> Okay, nm.
[23:36] <lifeless> so I'm going to not chase this just now
[23:36] <lifeless> but yes - iteration on the basic concept++
[23:37] <abentley> What you've got already sounds quite useful.  I look forward to applying it to iter_changes.
[23:37] <lifeless> cool
[23:38] <lifeless> I don't think it will save 'load the full inventory' but it should drop it from loading 2 to loading 1 and using the delta
[23:38] <lifeless> I think you can also do log -v well from it with some care
[23:39] <abentley> Yes.  bidi is what will give us the ability to avoid the full inventory.
[23:43] <lifeless> abentley: I think we need more than journalling to achieve that
[23:44] <lifeless> abentley: but I may be wrong. I'm htinking about operations on children of renamed dirs.
[23:45] <abentley> Well, path reconstitution is not actually needed for iter_changes.
[23:45] <abentley> though it would be for generating an inventory delta.
[23:46] <abentley> But we can sort it out later.
[23:48] <lifeless> yah
[23:49] <lifeless> I wonder if its time to write the 'tree at a time copier' again
[23:50] <abentley> Likely.
[23:50] <abentley> It's as old as the hills.
[23:51] <lifeless> I thought we didn't have one
[23:51] <lifeless> it got lost in the -> weave transition
[23:54] <abentley> InterDifferingSerializers is a tree-at-a-time fetcher, if that's what you mean.
[23:55] <lifeless> oh sweet
[23:55] <lifeless> cause I need to fix:
[23:55] <lifeless> BzrError: Corrupt repository, final inventory validator mismatch for robertc@robertcollins.net-20051005095108-6065fbd8e7d8617e, '0db02bfb8702b10a0df52ecc6ba89bb5aefd61c6' != '1132d23eb4e5ce1c73470259de6c84789a32adff'
[23:55] <lifeless> (this format checks the sha1 on every inventory access)
[23:56] <abentley> Ah.  Perhaps something is matching that shouldn't.
[23:57] <lifeless> yah
[23:57] <lifeless> :)
[23:57] <lifeless> at least thats my current theory
[23:59] <lifeless> erm no
[23:59] <lifeless> there's a bug in that fetcher :)
[23:59] <lifeless> it installs the inventory
[23:59] <lifeless> but it doesn't capture the inventories sha1