[00:11] 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] Yeah, I think RemoteRepository wants to be a subclass too. [00:18] poolie: I've popped up for air; its going really well. [00:18] great [00:20] poolie: if you want a call; now is a good time for me. [00:21] sure [00:21] and to the crowd in general, review sought on [MERGE] New development format (unchanged) and alias support for format [00:21] poolie: I'll call in a sec [01:36] lifeless, did you say something the other day about the feisty bzr repo being out of date [01:36] (as in https://answers.launchpad.net/bzr/+question/21602) [01:47] 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] core-ix, yes, you can do access control either through the 'bzraccess' hook, or by OS permissions on the repo [01:48] and you can use either bzr+ssh, sftp, or https for encrypted access [01:49] ok, thanks poolie ... i'm choosing new VCS for several projects and i need those features i mentioned before [01:49] poolie: yes, on my todo [01:49] poolie: I should get to it today I hope; I figure its not life or death right now [07:47] hiall [07:47] hi all [07:55] in loggerhead, i want the Log, Inventory, RSS,Repository under the branch itself , means, how can I do it? [07:55] just similar to http://goffredo-baroncelli.homelinux.net/bazaar-dev === bitmonk is now known as bitmonk|sharp [08:04] how can i improve my loggerhead look similar to http://goffredo-baroncelli.homelinux.net/bazaar-dev [08:04] mwhudson, can you help me in this please === bitmonk|sharp is now known as bitmonk === bitmonk is now known as bitmonk|sharp [08:48] Do I need to use redirect option of apache for this ? [08:51] mwhudson, are you there [08:51] anyone please tell me where can I get help in loggerhead, [09:00] indu, from mwhudson, [09:00] or i suggest you use the list or http://answers.launchpad.net/bzr [09:01] poolie, he is in leave till feb 4th itseems [09:01] indu, i'm not sure but i think that page is actually running the webserve plugin [09:01] which is different to loggerhead [09:11] New bug: #180969 in bzr "export to a non-existing directory failed" [Undecided,New] https://launchpad.net/bugs/180969 [10:07] 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] TFKyle, that is strange, could you please file a bug on http://launchpad.net/bzr ? [11:25] 'bzr get lp:bzr' takes about 5 minutes. is this 'normal'? [11:25] feels quite slow [12:35] abentley: BB down since more than 12 hours now [12:38] vila: Thanks. Restarted. [12:50] New bug: #180996 in bzr "bzr checkout fails with 'No buffer space available'" [Undecided,New] https://launchpad.net/bugs/180996 [12:52] anyonw here again now, who has idea about loggerehad configurations === mrevell is now known as mrevell-lunch === mrevell is now known as mrevell-lunch [12:55] could some one give me the path for webserve, download [12:59] is there a way of receiving a mail when someone uploads some source into my repo [13:06] abentley: thanks to you ;-) [13:06] np [13:09] 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] but I *never* saw the email ??? [13:10] Yeah, it's a problem because I changed my email, but BB wants to use the wrong one. [13:11] Which Mailmain no longer recognizes as a subscriber. [13:12] abentley: ok ok [13:12] So for now, I can only vote by mail, which I didn't realize then. [13:13] http://paste.pocoo.org/show/19892/ <-- Any thoughts on how to resolve that? [13:20] works again [13:20] magic [13:30] dennda: Perhaps you had another bzr process running? [13:32] maybe === mrevell-lunch is now known as mrevell [13:51] indu: perhaps ask on list [13:51] indu: I suspect people are not understanding the question. [13:51] ngiht all === bigdo1 is now known as bigdog_ === cprov is now known as cprov-lunch === cprov-lunch is now known as cprov === mw|travel is now known as mw [16:02] 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] 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] Yeah, it prints paths relative to the root. [16:12] God knows who made that choice and why. [16:12] There's at least thought of changing it. [16:12] I think I vaguely remember a discussion about this, maybe on the mailing list [16:12] today it bit me, and I wanted to ask here before filing a bug report [16:26] Yeah, mailing list. [16:28] do you perchance have a url/date + subject? [16:28] Nopers. [16:36] 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] asac: yes [16:49] 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] hey there [18:29] is there any easy way to find the latest N revisions which touched a given file? [18:30] bzr log path/to/file --limit N [18:31] that easy!? [18:35] thanks luks. I hadn't notice I could use 'log' on a file/dir [18:35] well, log on a dir will probably not do exactly what you expect [18:35] but on a file it should work fine === salgado is now known as salgado-afk === salgado-afk is now known as salgado === cprov is now known as cprov-out [20:45] Re my earlier issue with bzr bind hanging where bzr push works fine: bzr tags -d also hangs. Ideas for what to look for welcome. [20:54] dlee: have a look at $HOME/.bzr.log, then you can also try -Dhpss [20:59] Doing... [21:01] moin [21:08] Results: Stall after "ok" result from repository.get_revision_graph; sending SIGINT gives a traceback in the log. [21:19] dlee: file a bug please [21:22] Will do [21:28] 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] dlee, asking for help and before filing a bug is just fine [21:29] it's a bzr-in-general channel [21:29] dlee: (your line broke up at "the day I fil") [21:30] Arg... my client shows it all. :P thanks for the catch [21:30] filed the cvsps-import_under_Cygwin bug have drawn no comment) [21:30] 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] on IRC people will often not respond if they have no clue [21:31] so if what you're asking is not obvious you may get no commit ;) [21:32] 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] are there any bug tracking applications that work with bzr? [21:36] heard of the trac module but haven't gotten it to work [21:36] Well, there's Launchpad. [21:36] and trac [21:37] and cart [21:37] and bugs everywhere [21:37] 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] launchpad is pretty cool [21:38] but it isn't for closed source projects [21:40] never heard of cart and bugs everywhere [21:40] 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] zeasier: you should talk to 'statik' [21:47] just found the cart thread in lists.ubuntu.com [21:47] looks interesting [21:47] Rinchen: you can set a gpg signing command [21:47] Rinchen: possibly there are other gpg options; have you looked in the manual ? [21:48] lifeless, I've been scanning through it now [21:48] so far, no luck [21:52] 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] abentley: course at the start of a new delta chain it would be all new :( [21:54] Rinchen: probably the wrong way, but I'd start with gpg_signing_command = gpg --id FOO (or whatever gpg takes as options) [21:54] Rinchen: I think that that will work [22:05] New bug: #181115 in bzr "bind and tags hang where push does not" [Undecided,New] https://launchpad.net/bugs/181115 [22:18] 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] woo [22:33] 2 tests failing only (but inter foo is entirely absent) [22:38] Oooh, I forgot that 'bzr branch' uses the branch format of the branch being branched from, not the repo. [22:41] Seems I did have some older branches. [22:41] New bug: #181123 in bzr-cvsps-import "Tags import as branch tips, not tags" [Undecided,New] https://launchpad.net/bugs/181123 [22:45] New bug: #181124 in bzr "short options for bzr ls" [Wishlist,Confirmed] https://launchpad.net/bugs/181124 [23:00] 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] I'll need to read up on lca merge [23:02] 24605 mtaylor 18 0 1205m 976m 7928 D 19 32.5 9:06.60 bzr [23:03] damn that's a lot of memory [23:03] what is it doing ? [23:04] lifeless: One way to look at it is 3-way, extended to handle multiple bases. [23:04] If it's really painless, then by all means, include annotation. [23:05] lifeless: Bugs Everywhere and Cart are unfortunately abandoned now. [23:06] jelmer: svn-import [23:06] jelmer: copying revision 3341/6851 [23:06] :) [23:06] ah [23:06] mtaylor: you did see the link to the python-subversion memory leak fix? [23:07] oh, no... is that what that is? [23:07] I think so [23:07] ahhhhh. that would make sense [23:07] http://subversion.tigris.org/issues/show_bug.cgi?id=3052 [23:08] or the matching Debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=428755 [23:08] Debian bug 428755 in python-subversion "bzr-svn: 'bzr push' consumes memory" [Important,Open] [23:13] abentley: oh, ok :( [23:14] abentley: I think InterRepository._same_model is the reason you can pull subtrees into rich roots [23:15] Hrm. [23:15] it only looks at one of the two parameters [23:15] I'm wondering whether our InterRepository approach is too much LBYL. [23:16] If you look at what we did with diff, for example. [23:16] abentley: LBYL? [23:16] well it was intended to be simply a multimethod; the model stuff that has crept in adds confusion I think [23:16] look before you leap [23:17] 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] That way, we would have enough data to determine whether a fetch from 'subtrees' into 'rich-root' could succeed. [23:18] ah, I see [23:18] so nuke is compatible [23:18] and do a loop [23:19] Right. [23:19] 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] so one interrepository can do all rich-root variations that use the same inventory serialisation API [23:20] when do you start with Canonical ? [23:20] A fetch from subtrees into rich-root could look for subtrees in the inventories it was fetching. [23:21] lifeless: I start next week. And I'll be in Sydney the week after. Too bad I'll miss you. [23:21] 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] Mmm. Not sure. [23:22] so a InterSubTree parametereised with either "lambda x: raise NotSupported " or "queue a revision id to copy" [23:22] I think that's right. [23:22] The problem of fetching dependencies was one I had put off. [23:23] 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] injounralled->journalled ? [23:24] in (journalled->journalled) [23:24] right. [23:24] a journalled inventory repository has inventory deltas rather than xml deltas [23:25] cool [23:25] Are you doing unidirectional or bidirectional deltas? [23:25] minimal unidirectional with full entry contents included [23:26] Also, you were asking about why we're including revision-ids in inventories. [23:26] 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] jam could answer that better, but I believe it was a performance win. [23:26] I was having a brain-fart morning; [23:26] I'm pretty sure it was for the working tree basis cache [23:27] so that we didn't have to reserialise the XML [23:27] 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] Sounds plausible. [23:28] so, I don't think this journal contents is necessarily optimal; I only claim its better than the xml delta style [23:28] in fact I may change it to only have the basename of the path [23:29] because the case where the exact pathname is interesting is insufficient to do things log like PATH or 'find PATH in history' [23:29] 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] lifeless: Or to be really minimal, you could just include the paths of parents once. [23:31] Since we have the parent-id already. [23:31] not quite sure what you mean there; how is that different from just the basename of the path ? [23:32] I assume if you have three children of 'foo/bar', you would include 'foo/bar' three times. Correct? [23:32] currently yes; it was moddelled on the python inv delta object [23:32] Future: no? [23:33] Well like I say above I'm considerring dropping it back to just the basename [23:33] so foo/bar/baz and foo/bar/quux -> 'baz' and 'quux' [23:33] The example I gave had just the basename [23:33] I think we're probably in violent agreement. [23:33] * lifeless is confused [23:34] No, my bad. [23:34] I was thinking dirname, not basename. [23:34] ah! [23:34] Not enough sleep. [23:34] So if the dirname was considered useful at all, a future format could include it only once. [23:35] e.g. on the dir itself [23:35] Sorta mtree-style-ish. [23:35] but that then prevents grep style matching [23:35] The dir itself might be unchanged? [23:35] Therfore not included in the delta. [23:35] well, I need to keep the stuff I'm working on paged in [23:36] Okay, nm. [23:36] so I'm going to not chase this just now [23:36] but yes - iteration on the basic concept++ [23:37] What you've got already sounds quite useful. I look forward to applying it to iter_changes. [23:37] cool [23:38] 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] I think you can also do log -v well from it with some care [23:39] Yes. bidi is what will give us the ability to avoid the full inventory. [23:43] abentley: I think we need more than journalling to achieve that [23:44] abentley: but I may be wrong. I'm htinking about operations on children of renamed dirs. [23:45] Well, path reconstitution is not actually needed for iter_changes. [23:45] though it would be for generating an inventory delta. [23:46] But we can sort it out later. [23:48] yah [23:49] I wonder if its time to write the 'tree at a time copier' again [23:50] Likely. [23:50] It's as old as the hills. [23:51] I thought we didn't have one [23:51] it got lost in the -> weave transition [23:54] InterDifferingSerializers is a tree-at-a-time fetcher, if that's what you mean. [23:55] oh sweet [23:55] cause I need to fix: [23:55] BzrError: Corrupt repository, final inventory validator mismatch for robertc@robertcollins.net-20051005095108-6065fbd8e7d8617e, '0db02bfb8702b10a0df52ecc6ba89bb5aefd61c6' != '1132d23eb4e5ce1c73470259de6c84789a32adff' [23:55] (this format checks the sha1 on every inventory access) [23:56] Ah. Perhaps something is matching that shouldn't. [23:57] yah [23:57] :) [23:57] at least thats my current theory [23:59] erm no [23:59] there's a bug in that fetcher :) [23:59] it installs the inventory [23:59] but it doesn't capture the inventories sha1