| 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:11 |
| lifeless | poolie: I've popped up for air; its going really well. | 00:18 |
| poolie | great | 00:18 |
| lifeless | poolie: if you want a call; now is a good time for me. | 00:20 |
| 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 | 00:21 |
| 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:36 |
| 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:47 |
| poolie | and you can use either bzr+ssh, sftp, or https for encrypted access | 01:48 |
| 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 | 01:49 |
| indu | hiall | 07:47 |
| indu | hi all | 07:47 |
| 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 | 07:55 |
| === bitmonk is now known as bitmonk|sharp | ||
| 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:04 |
| === bitmonk|sharp is now known as bitmonk | ||
| === bitmonk is now known as bitmonk|sharp | ||
| indu | Do I need to use redirect option of apache for this ? | 08:48 |
| indu | mwhudson, are you there | 08:51 |
| indu | anyone please tell me where can I get help in loggerhead, | 08:51 |
| poolie | indu, from mwhudson, | 09:00 |
| poolie | or i suggest you use the list or http://answers.launchpad.net/bzr | 09:00 |
| 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:01 |
| ubotu | New bug: #180969 in bzr "export to a non-existing directory failed" [Undecided,New] https://launchpad.net/bugs/180969 | 09:11 |
| 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:07 |
| poolie | TFKyle, that is strange, could you please file a bug on http://launchpad.net/bzr ? | 10:35 |
| siretart | 'bzr get lp:bzr' takes about 5 minutes. is this 'normal'? | 11:25 |
| siretart | feels quite slow | 11:25 |
| vila | abentley: BB down since more than 12 hours now | 12:35 |
| abentley | vila: Thanks. Restarted. | 12:38 |
| ubotu | New bug: #180996 in bzr "bzr checkout fails with 'No buffer space available'" [Undecided,New] https://launchpad.net/bugs/180996 | 12:50 |
| indu | anyonw here again now, who has idea about loggerehad configurations | 12:52 |
| === mrevell is now known as mrevell-lunch | ||
| === mrevell is now known as mrevell-lunch | ||
| indu | could some one give me the path for webserve, download | 12:55 |
| indu | is there a way of receiving a mail when someone uploads some source into my repo | 12:59 |
| vila | abentley: thanks to you ;-) | 13:06 |
| abentley | np | 13:06 |
| 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:09 |
| 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:10 |
| abentley | Which Mailmain no longer recognizes as a subscriber. | 13:11 |
| vila | abentley: ok ok | 13:12 |
| abentley | So for now, I can only vote by mail, which I didn't realize then. | 13:12 |
| dennda | http://paste.pocoo.org/show/19892/ <-- Any thoughts on how to resolve that? | 13:13 |
| dennda | works again | 13:20 |
| dennda | magic | 13:20 |
| Peng | dennda: Perhaps you had another bzr process running? | 13:30 |
| dennda | maybe | 13:32 |
| === mrevell-lunch is now known as mrevell | ||
| lifeless | indu: perhaps ask on list | 13:51 |
| lifeless | indu: I suspect people are not understanding the question. | 13:51 |
| lifeless | ngiht all | 13:51 |
| === 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 | ||
| mgedmin | I don't suppose there's a vcscommand vim plugin for bzr? | 16:02 |
| * mgedmin settles for bzr get lp:bzr-vimdiff ~/.bazaar/plugins/vimdiff | 16:04 | |
| 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:09 |
| Peng | Yeah, it prints paths relative to the root. | 16:11 |
| 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:12 |
| Peng | Yeah, mailing list. | 16:26 |
| mgedmin | do you perchance have a url/date + subject? | 16:28 |
| Peng | Nopers. | 16:28 |
| 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:36 |
| vila | asac: yes | 16:43 |
| 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. | 16:49 |
| salgado | hey there | 18:29 |
| salgado | is there any easy way to find the latest N revisions which touched a given file? | 18:29 |
| luks | bzr log path/to/file --limit N | 18:30 |
| salgado | that easy!? | 18:31 |
| 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 | 18:35 |
| === salgado is now known as salgado-afk | ||
| === salgado-afk is now known as salgado | ||
| === cprov is now known as cprov-out | ||
| 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:45 |
| vila | dlee: have a look at $HOME/.bzr.log, then you can also try -Dhpss | 20:54 |
| dlee | Doing... | 20:59 |
| lifeless | moin | 21:01 |
| dlee | Results: Stall after "ok" result from repository.get_revision_graph; sending SIGINT gives a traceback in the log. | 21:08 |
| lifeless | dlee: file a bug please | 21:19 |
| dlee | Will do | 21:22 |
| 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:28 |
| beuno | it's a bzr-in-general channel | 21:29 |
| dato | dlee: (your line broke up at "the day I fil") | 21:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| zeasier | are there any bug tracking applications that work with bzr? | 21:35 |
| 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:36 |
| 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:37 |
| zeasier | but it isn't for closed source projects | 21:38 |
| 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:40 |
| lifeless | zeasier: you should talk to 'statik' | 21:46 |
| 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:47 |
| Rinchen | lifeless, I've been scanning through it now | 21:48 |
| Rinchen | so far, no luck | 21:48 |
| 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:52 |
| 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 | 21:54 |
| ubotu | New bug: #181115 in bzr "bind and tags hang where push does not" [Undecided,New] https://launchpad.net/bugs/181115 | 22:05 |
| 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:18 |
| lifeless | woo | 22:33 |
| lifeless | 2 tests failing only (but inter foo is entirely absent) | 22:33 |
| Peng | Oooh, I forgot that 'bzr branch' uses the branch format of the branch being branched from, not the repo. | 22:38 |
| 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:41 |
| ubotu | New bug: #181124 in bzr "short options for bzr ls" [Wishlist,Confirmed] https://launchpad.net/bugs/181124 | 22:45 |
| 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:00 |
| mtaylor | 24605 mtaylor 18 0 1205m 976m 7928 D 19 32.5 9:06.60 bzr | 23:02 |
| mtaylor | damn that's a lot of memory | 23:03 |
| jelmer | what is it doing ? | 23:03 |
| 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:04 |
| abentley | lifeless: Bugs Everywhere and Cart are unfortunately abandoned now. | 23:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| lifeless | abentley: oh, ok :( | 23:13 |
| lifeless | abentley: I think InterRepository._same_model is the reason you can pull subtrees into rich roots | 23:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| lifeless | cool | 23:25 |
| abentley | Are you doing unidirectional or bidirectional deltas? | 23:25 |
| lifeless | minimal unidirectional with full entry contents included | 23:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:31 |
| 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:32 |
| 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:33 | |
| 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:34 |
| 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:35 |
| 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:36 |
| abentley | What you've got already sounds quite useful. I look forward to applying it to iter_changes. | 23:37 |
| lifeless | cool | 23:37 |
| 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:38 |
| abentley | Yes. bidi is what will give us the ability to avoid the full inventory. | 23:39 |
| lifeless | abentley: I think we need more than journalling to achieve that | 23:43 |
| lifeless | abentley: but I may be wrong. I'm htinking about operations on children of renamed dirs. | 23:44 |
| abentley | Well, path reconstitution is not actually needed for iter_changes. | 23:45 |
| abentley | though it would be for generating an inventory delta. | 23:45 |
| abentley | But we can sort it out later. | 23:46 |
| lifeless | yah | 23:48 |
| lifeless | I wonder if its time to write the 'tree at a time copier' again | 23:49 |
| abentley | Likely. | 23:50 |
| abentley | It's as old as the hills. | 23:50 |
| lifeless | I thought we didn't have one | 23:51 |
| lifeless | it got lost in the -> weave transition | 23:51 |
| abentley | InterDifferingSerializers is a tree-at-a-time fetcher, if that's what you mean. | 23:54 |
| 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:55 |
| abentley | Ah. Perhaps something is matching that shouldn't. | 23:56 |
| lifeless | yah | 23:57 |
| lifeless | :) | 23:57 |
| lifeless | at least thats my current theory | 23:57 |
| 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 | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!