[00:00] <spm> Oh THAT one. right. /me recalls the pain. oh the pain. shared pain at that.
[00:03] <jkakar> lifeless: I should package autolp if the upgrade-branch-format command is something you're recommending to others.
[00:04] <Peng> Having lots of RAM to throw at Loggerhead is fun.
[00:04] <jkakar> Though, if it's only something spm can usefully use, maybe it's not a big deal yet.  It only has that feature right now, so not terribly useful to package it yet.
[00:06] <lifeless> jkakar: I'm pointing people at spm :)
[00:06] <lifeless> spm: anyhow, that the most likely cause for the failed branches; reconcile won't fix it.
[00:07] <jkakar> lifeless: Excellent. :)
[00:07] <lifeless> jkakar: running the fix script the bug has attached to it when a missing rev error happens would be nice (or even just do it to all stacked branches before starting the upgrades)
[00:07] <jkakar> lifeless: Would it be worth making the script catch missing revision exceptions and continue on, or should it blow up and stop?
[00:07] <jkakar> lifeless: Ah ha, okay.  I'll look at doing that.
[00:08] <lifeless> the fix script is 10 lines of python or so
[00:08] <jkakar> Cool.
[00:08] <lifeless> so for branch in branches: if branch.get_stacked_url(): fixmenow;
[00:08] <lifeless> for branch in branches: upgrade...
[00:10] <Peng> I think it's "get_stacked_on_url". :P
[00:14] <maxb> Are there any rebase users around? I'm seeking someone to discuss my "bzr rebase: Change behaviour to be as if --always-rebase-mergesspecified, remove outright the current default mode" email with
[00:17] <lifeless> maxb: discarding merges can be very useful
[00:17] <lifeless> we support that in bzr core; I'm not sure why you'd want to remove it from rebase (also are you aware its now 'bzr-rewrite')
[00:17] <SWAT> q: is it adviseable to use the 'smart-server' in a high-volume production environment? The advantage of bzr+ssh = speed/encryption and the advantage of bzr+http(s) = encryption/flexible user management, correct? I'm thinking about setting up bzr+http (ro) and bzr+https (rw) and connect apache to a small db (test) or ldap (production) instead of using bzr+ssh and just would like a small piece of advice _before_ I start setting it up.
[00:17] <lifeless> SWAT: the smart server can work over http
[00:18] <lifeless> SWAT: so you've presented a false dichotomy ;)
[00:18] <maxb> lifeless: The problem with the feature as currently implemented is that it discards revisions solely based on ancestry. What it should/could do, to be correct, is discard revisions only if a merge results in there being no changes to commit.
[00:18] <lifeless> maxb: perhaps
[00:19] <lifeless> maxb: though I don't think I agree
[00:20] <maxb> You don't think that it's wrong that rebase is lossy by default?
[00:20] <lifeless> rebase is by definition lossy
[00:20] <lifeless> its its raison d'etre
[00:22] <maxb> Well... far more lossy than the basic concept of rebasing inherently includes
[00:23] <lifeless> anyhow, a merge that includes something from the branch being rebased *on* should be discarded.
[00:23] <lifeless> whether or not there are textual changes is perhaps a case for a warning.
[00:23] <maxb> Yes.... but only if there aren't relevant textual changes remaining on merging it
[00:24] <lifeless> maybe
[00:24] <lifeless> I think it really depends on the exact change
[00:24] <lifeless> and what it means semantically.
[00:24] <SWAT> lifeless: ah, right, thanks. Let me put it differently: is it adviseable to use bzr+http(s) instead of bzr+ssh or is it all neglectable?
[00:25] <lifeless> maxb: it probably needs to be put way down at the bottom of the rebase in fact, for the case of a merge already in the base.
[00:25] <lifeless> maxb: OTOH a merge from a branch not merged to base, should be kept.
[00:25] <lifeless> SWAT: shouldn't be any significant differences in performance.
[00:25] <lifeless> SWAT: if there are, they are bugs
[00:26] <SWAT> lifeless: thanks a lot. I'll leave you to your other discussion(s). Cheers
[00:26] <maxb> I don't think it makes sense to try to replay merges out-of-order if that's what you're suggesting - the merge is on top of other changes on your branch being rebased, and is likely to have textual dependencies on them
[00:27] <lifeless> maxb: I'm not sure I was totally clear about the case being discussed
[00:29] <maxb> Well, I'm approaching this from the PoV of "It's never OK to discard a merge revision purely based on ancestry, you have to see if there are relevant textual changes" - because the act of resolving conflicts when the merge was done may include making valuable changes.
[00:30] <maxb> By way of a specific example: we had a Launchpad branch for a newer python version. When a new script was added on trunk, the shebang had to be changed as part of merging the addition to the branch.
[00:30] <maxb> A purely ancestry-based approach would silently lose that sort of change
[00:33] <lifeless> maxb: but thats my example
[00:33] <maxb> ?
[00:33] <lifeless> maxb: if you have the rev merged earlier you need the shebang earlier too
[00:35] <maxb> hmm. The idea of reordering changesets instead of just replaying the graph maintaining its shape is scary
[00:35] <lifeless> maxb: rebasing anything where revisions merged higher up that are already in the new base is non trivial.
[00:36] <lifeless> maxb: (consider the typical loom usecase)
[00:36] <lifeless> maxb: where what you are rebasing is just a non-linear but still discrete subgraph, its easy.
[00:36] <lifeless> this is one of the problems with merges and rebase.
[00:59] <lifeless> spiv: can I beg you to fix pqm-submit today? It would save me reinventing yoour changes.
[00:59] <spiv> lifeless: ok
[01:00] <spiv> lifeless: although I would hope you'd choose to build on my changes, rather than reinvent them...
[01:00] <lifeless> spiv: So would I.
[01:01] <eric_f> lifeless: thanks for the tip on: for dir in `ls $1`; I got it working, but can't get it to work as a Bash alias. Any ideas?
[01:06] <lifeless> eric_f: I'd make a small bash script
[01:07] <lifeless> you might also look at 'bzr-removable', it might fit your needs (if I'm guessing right)
[01:08] <Peng> Wow. "bzr check" on a 1.14 copy of MySQL is using more than 4 gigs of RAM.
[01:09] <eric_f> lifeless: I'm doing this:
[01:09] <eric_f> for dir in `ls $1`; do if [ -e ${dir}/.bzr ]; then echo ${dir}; echo --------------------; bzr status ${dir}; echo; fi done;
[01:09] <spiv> Peng: it checks your RAM *and* your branch!
[01:09] <eric_f> i want to alias that so I don't have to type it all the time
[01:10] <lifeless> eric_f: put it in a script in your path
[01:10] <lifeless> then you don't have to type it all the time
[01:11] <Peng> spiv: It's checking my swap, too.
[01:11] <lifeless> mem
[01:11] <lifeless> disk
[01:11] <lifeless> content
[01:11] <lifeless> \o/
[01:11] <lifeless> profit
[01:13] <Peng> But I don't want to pay for more RAM.
[01:14] <Peng> This is really amazing, though. On a 32-bit machine with a 2a repo, checking MySQL isn't a big deal. Maybe 500-600 MB of RAM.
[01:14] <Peng> 2a rocks.
[01:14] <Peng> How did we ever live with the pre-2a formats? :P
[01:20] <Linkadmin> is there any way in a central repository setup to have the repository automatically update its tree on commit? the push-and-update plugin looks like a local hook, and the automirror plugin seems to only want to push to a second repo
[01:23] <Peng> Currently RAM+swap is approaching 7 GB.
[01:24] <fullermd> Peng: Machines get more memory all the time.  If we don't keep up with that increase, how will we ever compete with Windows?
[01:26] <Peng> Can Canonical send me $70 so I can buy enough RAM to check this repo? :D
[01:26] <Peng> Actually, only $50. I have a little money in my wallet. :P
[01:27] <fullermd> Shoulda bought memory back in June like I did, before it shot back up in price   :p
[01:31] <lifeless> Linkadmin: not really.
[01:31] <lifeless> Linkadmin: generally that suggests you are trying to do something in an unusual way
[01:31] <Linkadmin> i just want the working tree to be updated when i do a commit...
[01:39] <Peng> Linkadmin: Why does the central repo need a tree at all?
[01:42] <Linkadmin> Peng: sorry, i meant the branch needs a working copy
[01:42] <Linkadmin> not the repo
[01:42] <Peng> Linkadmin: Why does the central branch need a tree?
[01:43] <Linkadmin> Peng: because i'd like to set up a webserver to point to the docs I'm keeping in version control
[01:44] <Linkadmin> so if i do i.e., bzr init-repo repo ; bzr init repo/branch and then remotely commit to repo/branch, i don't seem to see my updated docs in repo/branches on the server
[01:45] <Peng> Oooh.
[01:46] <Linkadmin> and when I do bzr push, it tells me something about the remote tree not being updated  :S
[01:49] <spiv> Linkadmin: working trees are designed for local use, bzr can't update them over remote connections like sftp
[01:49] <spiv> Linkadmin: you may be interested in the bzr-upload or bzr-push-and-update plugins
[01:50] <Linkadmin> spiv: yeah i was looking at that, but those seem to be local hooks, not run on the central repository
[01:50] <spiv> Right.
[01:50] <Linkadmin> which means that the plugins need to be installed on every collaborator's computer, and they all need to use the plugins' commands
[01:51] <spiv> Well, push-and-update hooks into regular bzr push, but yes.
[01:51] <spiv> The simplest solution is to put a cron job on the server that runs "bzr update" every 10 minutes or so.
[01:52] <Linkadmin> i think i'll probably set up a second branch and have automirror push to that branch. Since automirror is post_commit, that means it's run from the central repo, right?
[01:52] <spiv> If the central branch is only written to via a smart server (e.g. bzr+ssh), then in principle you could write a simple plugin to hook the Branch.post_branch_tip_change event and then run "bzr update" from that.
[01:53] <spiv> But I wouldn't be surprised if there are a bunch of annoying details that make that harder than it should be...
[01:53] <Linkadmin> i was thinking about doing that too yeah
[01:53] <spiv> I'd be happy to help if you want to do that, though.
[01:53] <Linkadmin> but it sounds like automirror would be a safer choice if it can run on commit on the repo, and not on individual systems
[01:54] <spiv> post_commit is run where the commit happens -- i.e. the computer where 'bzr commit' is running, not on the repo.
[01:54] <Linkadmin> oh man
[01:55] <spiv> The right server-side hook is Branch.post_change_branch_tip
[01:55] <Linkadmin> but wait...
[01:55] <Linkadmin> https://bugs.launchpad.net/bzr-email/+bug/307988
[01:55] <Linkadmin> this runs from the central server
[01:55] <Linkadmin> oh i see
[01:55] <Linkadmin> different hooks, ok
[01:56] <spiv> Yes, bzr-email uses that hook
[01:56] <Linkadmin> do you know if automirror does? I'll go look for the code, brb
[01:56] <spiv> (Although it will fallback to post_commit for ancient bzr versions)
[01:57] <spiv> It appears not, but it's probably not hard to update it.
[01:58] <spiv> Linkadmin: give me 10 minutes, I'll whip up a patch, this looks pretty straightforward
[01:58] <Linkadmin> w00t w00t
[02:11] <spiv> Linkadmin: lp:~spiv/bzr-automirror/use-new-hook
[02:12] <Linkadmin> i was just looking at that  :)
[02:12] <Linkadmin> i'll try it out right now
[02:13] <Linkadmin> just to recap my plan, i'll bzr init-repo repo ; bzr init repo/branch1 ; bzr init repo/branch2, then in branch1/.bzr/branch/branch.conf i'll tell it to post_commit_update (or whatever the setting is) to branch2, and when I commit over bzr+ssh remotely, that hook will run properly?
[02:13] <lifeless> sure. Dunno why you need a second branch thouh.
[02:14] <Linkadmin> well because i don't think automirror will properly push the branch into its own working copy without problems, right?
[02:15] <lifeless> uh
[02:15] <lifeless> so I would just call tree.update() from the post tip change hook on the server
[02:16] <spiv> lifeless: the "just" there hides a few details, but sure :)
[02:16] <spiv> I guess params.branch.bzrdir.open_workingtree().update() would probably work.
[02:17] <Linkadmin> then why doesn't bzr do that by default? It does it for local branches but won't do it on remotes...
[02:17] <lifeless> with try: except errors.NoWorkingTree:pass
[02:17] <lifeless> Linkadmin: because in the general case it won't work.
[02:17] <lifeless> Linkadmin: if you have conflicts, or the tree is locally edited, there is no UI for the person pushing to fix issues with it.
[02:18] <Linkadmin> gotcha
[02:18] <spiv> And we'd need to define the network protocol for reporting those issues, etc.
[02:18] <Linkadmin> makes sense
[02:18] <Linkadmin> so it will probably come at some point i guess
[02:18] <spiv> In your case, you're always expecting tree.update() to work because there should never be any local changes.
[02:18] <lifeless> Linkadmin: I doubt it.
[02:19] <lifeless> Linkadmin: its not on anyones todo list, and I know of plenty of cases where doing it would be very much the wrong think.
[02:19] <Linkadmin> is there a roadmap for features for future development?
[02:19] <lifeless> s/think/thing/
[02:24] <poolie> lifeless: as part of patch piloting, please chase up contributor agreements where needed
[02:24] <poolie> and add them to that team
[02:24] <mwhudson> http://pastebin.ubuntu.com/326532/ <- is that ok for NEWS entry?
[02:24] <Linkadmin> thx a ton for the help guys. Gonna try out that hook spiv.
[02:24] <lifeless> poolie: I know
[02:24] <poolie> i know you may already know this
[02:24] <poolie> mwhudson: itym UNICODE(tm)
[02:24] <poolie> :-)
[02:24] <mwhudson> heh
[02:24] <lifeless> mwhudson: looks fine to me
[02:25] <poolie> but seriously, good, except that I'd drop the final . from the url
[02:25] <mwhudson> putting the tm mark in would have a certain irony
[02:25] <poolie> to stop lp spazzing out
[02:25] <spiv> Or wrap the URL in <>
[02:26] <poolie> yes
[02:26] <mwhudson> what should i set public_location and submit_to to?
[02:27] <lifeless> http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev
[02:27] <lifeless> submit branch
[02:27] <lifeless> public_location should be something like:
[02:28] <lifeless> actually
[02:28] <lifeless> it should default to push_location
[02:28] <lifeless> which is fine
[02:28] <lifeless> if it doesn't
[02:28] <lifeless> public_branch = lp:~mwhudson/bzr
[02:28] <mwhudson> oh sorry
[02:28] <lifeless> public_branch:policy = appendpath
[02:28] <mwhudson> i meant the email address
[02:28] <lifeless> pqm@bazaar-vcs.org
[02:29] <mwhudson> thanks
[02:33] <mwhudson> that didn't work
[02:33] <mwhudson> All lines of log output:Sender not authorised to commit to branch bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/
[02:33] <mwhudson> oh
[02:33] <mwhudson> trailing slash ftl
[02:34] <mwhudson> nope
[02:34] <mwhudson> All lines of log output:Sender not authorised to commit to branch bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev
[02:34] <poolie> igc: do you have a specific definition of "gateway pattern"?
[02:34] <mwhudson> spm: halp
[02:34] <spm> mwhudson: yo
[02:35] <spm> oh right. I see. hrm.
[02:35] <mwhudson> spm: i can't seem to commit to bzr
[02:35] <lifeless> mwhudson: do a dry run and pastebin it
[02:35] <spiv> mwhudson: http://, not bzr+ssh:// ?
[02:36] <mwhudson> http://pastebin.ubuntu.com/326540/
[02:36] <poolie> lifeless: i suspect that until lp has a concept of mp assignee
[02:36] <poolie> it will be easier not to have pilots carry over responsibility for things they started on
[02:36] <mwhudson> spiv: ah, seems happier
[02:37] <lifeless> poolie: I think we should try it and see.
[02:37] <lifeless> poolie: handoffs are expensive and will likely fragement discussions
[02:37] <spiv> mwhudson: I also use http for my branch in the pqm submission too, because pqm keeps having trouble with it.  I honestly can't remember if that's been sorted or not.
[02:38] <mwhudson> spiv: mine seems to be getting somewhere
[02:38] <spiv> mwhudson: that good :)
[02:41] <igc> hi poolie
[02:41] <igc> poolie: I need to get lunch right now (with my sick daughter) but I'll bbiab
[02:42]  * igc lunch
[03:32] <mwhudson> woot, my patch landed in bzr
[03:58] <brmassa> guys, how could i create a plugin that automatically format the commit messages in a given way? is there a easy tutorial to create plugins?
[04:03] <mwhudson> it's certainly possible but i don't know how
[04:04] <brmassa> mwhudson: thanks. but now i need to know the "how" part :P
[04:05] <spiv> brmassa: there are some docs
[04:05] <mwhudson> yes, i was aware i was't being very helpful
[04:06]  * spiv tries to dig them up
[04:08] <spiv> brmassa: http://bazaar-vcs.org/WritingPlugins seems to be the most helpful link, but I'm sure there's more somewhere, but I'm having trouble finding it :/
[04:08] <spiv> Well, there's http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/writing_a_plugin.html, but it's pretty short.
[04:09] <brmassa> spiv: hmmm thanks! i ll take a better look. i will report back if i get something...
[04:12] <spiv> Ah, there's http://doc.bazaar-vcs.org/developers/plugin-api.html, but it doesn't seem to be linked from anywhere.
[04:12] <spiv> Oh, via Specifications, I see.
[04:13] <spiv> Hmm, the way the docs try to be both sphinx and not-sphinx is a bit confusing.
[04:14] <lifeless> poolie: https://code.edge.launchpad.net/~mbp/bzr-usertest/trivial/+merge/7532 - just push :)
[04:15] <poolie> k
[04:35] <poolie> lifeless: i'm going to ask for an sru for all of 2.0.2 into karmic etc
[04:35] <poolie> to get some practice, and to get those fixes in
[04:36] <lifeless> cool
[04:36] <poolie> do you want to talk about it first?
[04:36] <lifeless> if you like
[04:37] <poolie> not especially
[04:37] <poolie> i thought i'd just file it and then people can comment if they want
[04:37] <poolie> it's been discussed a few time before
[04:37] <poolie> the big question is whether they'll be ok with one sru taking multiple fixes
[04:37] <poolie> and also i guess whether it's sufficiently conservative
[04:37] <lifeless> the key thing is 'auditable'
[04:38] <lifeless> someone will read the diff
[04:46] <spiv> Hmm, 2.0.0 -> 2.0.2 diffstat: 54 files changed, 1562 insertions(+), 487 deletions(-)
[04:47] <spiv> But about half of that is in bzrlib/tests/
[04:48] <lifeless> poolie: can I borrow the LEAN book when you've finished it ?
[04:56] <poolie> yes
[04:58] <poolie> lifeless/igc: how about upgrading bzr-usertest to 2a? any objections?
[04:58] <igc> poolie: sure
[04:58] <igc> poolie: I've done it locally last week iirc
[04:59] <igc> poolie: maybe I didn't finish doing the lp dance at that end
[04:59] <poolie> oh maybe not
[04:59] <fullermd> 2a comes with lap dances?!
[04:59] <lifeless> poolie: JFDI
[05:00] <lifeless> our community is all dependent on 2a anyway to get bzr itself
[05:02] <poolie> igc, oh, maybe you wanted to make https://code.edge.launchpad.net/~ian-clatworthy/bzr-usertest/trunk the new trunk?
[05:02] <poolie> suggest you reassign ownership too
[05:02] <igc> poolie: I'll take a look
[05:05] <poolie> thanks
[05:09] <poolie> igc, ping me when you're done and i'll do that merge for robert
[05:09] <igc> poolie: ok
[05:22] <igc> poolie: new trunk pushed but I don't think it went smoothly
[05:22] <igc> poolie: the old branch disappeared? Did you rename it?
[05:22] <igc> poolie: maybe lp eat it while I was changing the development focus
[05:23] <igc> ate
[05:25] <igc> poolie: ah. It's still there under trunk-old and things look ok now
[05:26]  * lifeless really prefers in place upgrades
[05:26] <lifeless> they seem smoother to me
[05:39] <poolie> igc: i haven't looked at the releases yet; there's meant to be one this week, but with john sick and on holidays maybe someone else should do it
[05:43] <igc> poolie: did you want to do our weekly call today?
[05:43] <poolie> sure
[05:43] <poolie> in 2m is good for me
[05:44] <igc> poolie: how does 10 minutes sound?
[05:46] <MTecknology> So... bzr-fastimport
[05:46] <MTecknology> how do I go about using this?
[05:47] <poolie> igc, cup of tea loaded, call when ready :)
[05:47] <igc> poolie: now is fine :-)
[06:00] <MTecknology> I guess I'll need to play with fastimport tomorrow - it looks like it won't be fun
[06:03] <poolie> igc, no, not mine i guess
[06:03] <igc> done
[06:04] <igc> poolie: ^
[06:04] <poolie> k
[07:22] <bialix> igc: are you still here?
[07:25] <bialix> it seems not, I'll send a mail then
[07:32] <lifeless> spiv: and where is your pqm-submit work?
[07:35] <spiv> lifeless: a happy coincidence, just pushing an update now that adds tests
[07:37] <lifeless> spiv: just land it then. /me rs's the tests.
[07:37] <spiv> lifeless: ok, will do.  Thanks!
[07:37] <lifeless> spiv: how do you use it though
[07:38] <spiv> lifeless: set pqm_email in locations.conf for the public_location
[07:38] <igc> hi bialix
[07:39] <lifeless> spiv: oh! so I need to edit locations.conf to send in gordon's merge remotely?
[07:39] <spiv> lifeless: then use --ignore-local and specify the submit branch and public branch explicitly via the relevant options.
[07:39] <spiv> (or you can put the pqm_email in your global config...)
[07:39] <lifeless> spiv: what do you think of looking up pqm_email on the target branch location ?
[07:40] <spiv> lifeless: I have this in my locations.conf:
[07:40] <spiv> [lp:~*/bzr/]
[07:40] <spiv> pqm_email = Canonical PQM <pqm@bazaar-vcs.org>
[07:40] <spiv> lifeless: that sounds reasonable on the face of it.
[07:40] <lifeless> ok, that will do. I'll file a bug for the other point.
[07:40] <spiv> lifeless: I can't really remember why I did it this way, to be honest.
[07:41]  * igc dinner
[07:41] <spiv> lifeless: enjoy!  and file bugs, of course :)
[07:41]  * spiv -> off the evening.
[07:41] <lifeless> spiv: thanks
[07:51] <Peng> OK, let's try "bzr check" again with 8 GB of RAM. And I'm not going any higher.
[07:52] <lifeless> poolie: did you land that usertest branch? because of the branch dance lp won't say
[08:14] <vila> hi all !
[08:16] <lifeless> vila: hihi
[08:16] <lifeless> vila: --no-strict! :)
[08:16] <vila> :)
[08:17] <lifeless> (as in, I'm hoping you can fix that bug today :P)
[08:17] <bialix> hello vila! you're back!
[08:18] <vila> lifeless: yeah. got that. No promise, babune is almost red even in its reduced config...
[08:19] <vila> bialix: hi :) Still fighting jetlag, but getting there, hopefully I'll be able to stay awake today :)
[08:19]  * bialix hopes you fly from warm sea and good rest ;-)
[08:20] <bialix> vila: I won't ping you today, I promise; just glad you're back
[08:20] <vila> :)
[08:23]  * bialix wonders why igc don't use lazy_register for explorer commands
[09:59] <OldAl> igc: Hi!
[10:02] <OldAl> bialix: Hello! What time is it now in Kiiv?
[10:03] <bialix> OldAl: hi, there is noon now, we're live in +2 timezone
[10:03] <bialix> igc is not here right now
[10:04] <OldAl> bialix: Well, left a "hi" for igc, but no reply.
[10:07] <OldAl> bialix: OK, 1200 where you live; 2100 in Canberra   1200 +900 = 2100.  What part of Ukraine are you at? What is the nearest city?
[10:10] <OldAl> bialix: So you are near the Black Sea?
[10:19] <igc> hi bialix, OldAl
[10:19] <bialix> evening igc
[10:20] <MvG> What is a revision key? I found that term looking at the bzr source code...
[10:20] <OldAl> igc: Hi, igc
[10:21] <bialix> igc: I'd like to land my patch for lazy-commands in explorer. I found some use cases for it. I'll wait till weekend if you find the time for review.
[10:21] <OldAl> igc: Just had a chat with bialix.
[10:21] <bialix> MvG: revision key? maybe revision-id?
[10:22] <MvG> bialix: No. The one-element tuple (revid,) seems to be /one/ possible form of a revision key, but I assume not the only one.
[10:22]  * MvG is reading Repository.get_parent_map
[10:22] <bialix> where isone-item tuple, there is possible multiple-items tuples
[10:23] <MvG> yes, but with what meaning?
[10:23] <bialix> direct meaning
[10:23] <bialix> get several revisions from repo
[10:23] <bialix> in a batch
[10:24] <OldAl> igc: I've downloaded the docs about bzr-plugins from your lp +/junk address, did  make html, got the result in _html directory (I think).  Lots of complaints from Sphinx about missing parts.
[10:24] <MvG> I doubt it's treated as a list, because get_parent_map even deals with lists of revision keys.
[10:24] <OldAl> igc: Do you expect the documenters to know Sphinx?  Or how much you think we should attempt to learn Sphinx?
[10:24] <bialix> can't say off-hand
[10:25] <igc> bialix: that patches looks good and I've just approved it
[10:25] <igc> bialix: are you happy to land it?
[10:25] <bialix> igc: thanks
[10:25] <bialix> yes, I am
[10:25] <bialix> igc: should I write some special NEWS item?
[10:26] <igc> OldAl: you need to know ReST. Sphinx adds a small amount over that
[10:26] <igc> bialix: it's mostly internal isn't it?
[10:26] <igc> bialix: add a NEWS item is there's an external impact
[10:27] <bialix> igc: yes, it's internal thing
[10:27] <OldAl> igc: OK, I go to my home moinmoin (desktop version I use to keep records) and will change lots of pages to reST.  I thought that moinmoin uses flat file system.  Is that not so?
[10:28] <igc> OldAl: flat file system?
[10:28] <igc> moin supports it's own markup language and ReST
[10:29] <lifeless> igc: moinmoin is plugable these days. We do use the flat file backend, but its not exposed on the web.
[10:29] <lifeless> OldAl: ^
[10:29] <OldAl> igc: Most wikis are "flat file system"; They look structured, but internally they are flat file (all in one huge b. directory..).
[10:29] <OldAl> igc: moinmoin may be smarter - have not looked in detail.
[10:30] <OldAl> igc: Should be able to find out RSN, but thought you might know off hand.
[10:34] <OldAl> lifeless: what does ^ mean in irc lango?
[10:34] <lifeless> OldAl: that the line above also was addressed to you
[10:36] <OldAl> lifeless: Oh, I see that - so my desktop moinmoin is probably flat file system, but not visible on launchpad version?
[10:36] <OldAl> lifeless: It's ability of plugins is great for things like reST, listing of Python code, etc.
[10:38] <OldAl> lifeless: My moinmoin desktop is kind of scratch pad.  It is great for a guy with failing memory for record keeping...
[10:52] <OldAl> lifeless: I get this message each time I connect: freenode-connect: Received CTCP 'VERSION' (to oldal) from freenode-connect.  What does CTCP mean and what does the message say?
[10:58] <jelmer> lifeless, ping
[10:58] <lifeless> pong
[10:59] <jelmer> lifeless: One of the sprint notes said you were working on uploading a bzr-rewrite package to Debian/Ubuntu
[10:59] <lifeless> jelmer: its been uploaded to the bzr beta ppa I think
[11:00] <jelmer> lifeless: Is that still true, any news in that regard?
[11:00] <lifeless> I need to pull, audit and push to debian
[11:00] <lifeless> packaging branch will be on lp:ubuntu/karmic/bzr-rewrite/*
[11:00] <jelmer> lifeless: Ah, thanks
[11:00] <lifeless> jelmer: if you want to do that,  I won't say no :)
[11:01] <jelmer> Maybe :-) I have some long-overdue sponsoring of qbzr and bzr-explorer packages to do first.
[11:02] <lifeless> gnight
[11:11] <jelmer> 'night
[12:06] <bialix> what is correct way to check if file actually ignored?
[12:07] <bialix> tree.is_ignored(path) does not check versionning info
[12:07] <bialix> so if the file in the tree is versioned but match ignored pattern?
[13:01] <ryanhaigh> hi all, i have an existing project from when i first tried bzr and it contains a few revisions with a significant number of large binary files that aren't really related. in later revs i ignored them but they are still in the rev history and so checkout/branch take a LONG time and uses a lot of space. what is the best way (if its possible) to remove those files from the revision history?
[13:07] <igc> night
[13:14] <bialix> ryanhaigh: rewriting the history makes new and old branches incompatible. if you're OK with this you can use either rebase (rewrite plugin) or fast-import-filter
[13:15] <bialix> hi GaryvdM
[13:15] <GaryvdM> Hi bialix
[13:16] <bialix> thx for fast review
[13:16] <bialix> GaryvdM: do you have any ideas how to debug and fix Bug 487115?
[13:17] <GaryvdM> Pleasure. I thought that we behave the same as cli commit, but we were different.
[13:17] <GaryvdM> bialix: re 487115 - Not sure off hand, but I will take a look
[13:18] <bialix> GaryvdM: actually it seems tree.is_ignored() is misleading API
[13:19] <bialix> I think this function should be named as is_match_ignore_pattern()
[13:19] <bialix> interesting, the patch with such change will be rejecting in first 15 min or so?
[13:19] <GaryvdM> bialix: I've been working on https://code.launchpad.net/~garyvdm/qbzr/better_text_display
[13:19] <bialix> that's nice
[13:20] <bialix> GaryvdM: if you have any opinion on qshelve, I'd like to hear
[13:20] <bialix> (recent discussion with john szkameister)
[13:21] <GaryvdM> bialix: Yes - the stuff that I'm working on is very related. I'm busy reading your mail carefully, and then I'm going to reply
[13:21] <bialix> I did not write my mail
[13:21] <bialix> actually I think we can and maybe should create line-based side-by-side editor for shelve
[13:21] <bialix> something like qannotate now
[13:22] <bialix> when every line easily identified
[13:22] <GaryvdM> Yes - That is my plan
[13:22] <GaryvdM> bialix: Your mail from this morning
[13:23] <bialix> yes, I did not finish it in morning -- have to run to work
[13:23] <GaryvdM> Well - There is a mail in my inbox from you re qshelve. May be you sent if by mistake
[13:23] <GaryvdM> *uit
[13:23] <GaryvdM> *it
[13:23] <bialix> no, I've sent it debilerately
[13:24] <bialix> I've write second part tonight, about editor'
[13:24] <GaryvdM> ok
[13:24] <bialix> *I'll write, sorry
[13:25] <bialix> GaryvdM: we have many good user-visible improvements in this release, I like it. Right for new year :-)
[13:25] <GaryvdM> Thats cool
[13:25] <bialix> yeah
[13:25] <bialix> I've starting working on change of code layout
[13:26] <bialix> I hope to finish it and land after 0.17
[13:46] <bialix> GaryvdM: I want to blog about new encoding selector in qbzr
[13:47] <bialix> I remember in the past you've published some of qbzr screenshots in main bzr blog?
[13:47] <GaryvdM> Yes - poolie made me a author on there. Send Him a mail, and I'm sure he will do the same for you.
[13:50] <GaryvdM> bialix: One of the things I want to do with qdiif, is make it possible to set the encoding per file.
[13:51] <bialix> GaryvdM: me too, did you saw the thread in bzr ML about versioned preperties?
[13:51] <GaryvdM> Sorry - No
[13:51]  * GaryvdM reads the mailing list selectively
[14:04] <asabil> hi all
[14:05] <jelmer> hey asabil
[14:05] <asabil> is there any way to get a prettier output in bzr qlog when viewing the launchpad code ?
[14:05] <asabil> I mean I want to filter out the [r=...][...][...] tags in the commit message
[14:06] <asabil> hey jelmer
[14:06] <GaryvdM> asabil: you can hide the bottom plane, by draging it smaller.
[14:06] <asabil> GaryvdM, that's not what I meant
[14:06] <asabil> I mean in the log tree
[14:07] <GaryvdM> asabil: The latest trunk version has some self-improvement to the display of
[14:07] <GaryvdM> opps - pressed enter by mistake - that should read
[14:07] <GaryvdM> asabil: The latest trunk version has some improvements to the display of parents and children in the message box
[14:07] <asabil> I am running trunk
[14:08] <GaryvdM> asabil - So you want to hide bugs and tags in the log tree?
[14:08] <asabil> GaryvdM, the problem is that the launchpad history is polluted with some PQM specific tags I think
[14:09] <asabil> all the commit messages are prefixed with some gibberish
[14:09]  * GaryvdM goes to look at the launchpad history
[14:10] <bialix> asabil: screenshot?
[14:10] <bialix> asabil: there is custom replace feature for qlog messages
[14:11] <bialix> qlog_replace see README.txt
[14:11] <asabil> bialix, http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel/changes
[14:11] <asabil> oh ok thanks, I will check that
[14:12] <GaryvdM> bialix: I forgot about that.
[14:12] <asabil> wow that's a cool feature !
[14:12] <GaryvdM> funny - I've never used it.
[14:12] <bialix> qlog_replace does not help for main window
[14:12] <bialix> I guess, Gary may know better
[14:13] <bialix> GaryvdM: I've never used it too, just read about it
[14:14] <GaryvdM> asabil: Please let us know if there are any bugs with it. I don't think many people use it, and there are no tests for it, so I'm worried that it might be broken.
[14:19] <asabil> GaryvdM, it doesn't seem to work for me
[14:26] <MvG> bialix: the other day you pointed me at http://starship.python.net/crew/mwh/bzrlibapi/ . Now I find it's lacking documentation of members. Do you perhaps know of a documentation that does include members besides functions?
[14:27] <MvG> Does bzrlib.inventory.InventoryDirectory.parent_id behave differently depending on the absence or presence of a rich root?
[14:27] <GaryvdM> asabil: Ok - I'll take a look. Please could you log a bug so that it does not slip through the cracks.
[14:27] <asabil> GaryvdM, yeah sure, I will do that later
[14:27] <asabil> thanks for your help
[14:28] <bialix> MvG: what do you mean?
[14:28] <GaryvdM> Pleasure
[14:28] <MvG> bialix: http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.inventory.InventoryDirectory.html e.g. doesn't list "parent_id", the one I mentioned in my question above. pydoc does.
[14:28] <bialix> MvG: I'm sure mwhudson is master of that doc
[14:29] <bialix> MvG: ah, hmm, there is used custom tool for building these docs, called pydoctor IIRC
[14:30] <MvG> I see.
[14:30] <MvG> thx.
[14:30] <MvG> Don't feel like filing a feature request for such tools just now.
[14:30] <bialix> the doc generated automatically, so if there is nothing than most likely either original sources lacking it or bug in pydoctor
[14:30] <bialix> you may want ask mwhudson
[14:30] <MvG> The members are undocumented.
[14:31] <bialix> that's bad, sorry, I can't help here
[14:31] <MvG> His name has been mentioned often enough, I guess if he's available and feels like answering, he will.
[14:32] <bialix> he's from land of kiwi IIRC, so right now he's sleeping
[14:32] <MvG> Maybe will read logs...
[15:51]  * jelmer hugs jam
[15:51] <jelmer> meliae ftw
[15:54] <jelmer> oh, also
[15:54]  * jelmer hugs mwhudson
[16:27] <MvG> mzz: Do you wish to review https://code.launchpad.net/~gagern/trac-bzr/bug484983/+merge/15199 regarding the removal of the get_previous method we talked about the other day?
[16:36] <mzz> MvG: did you check that the generated history for the root node is at least as sensible compared to the history for a subdirectory as it was before?
[16:36] <MvG> jelmer: as you write such an encouraging comment about having bzrlib deal with dotted revnos, would you have a look at https://code.launchpad.net/~gagern/trac-bzr/bug487529/+merge/15201 and comment?
[16:36] <MvG> mzz: Yes.
[16:37] <MvG> mzz: Root of the branch you mean, right?
[16:37] <MvG> It's way more sensible now.
[16:37] <MvG> At least in the cases I encountered.
[16:37] <mzz> MvG: yes (which was supposed to be returning all ancestry unconditionally both now and before)
[16:37] <mzz> I'm just a little worried about there being off by ones in one if you're fixing them in the other
[16:38] <mzz> but if you've tested them that's definitely good enough for me.,
[16:38] <MvG> mzz: All ancestry up top the current rev. It returned all ancestry up to the tip of the branch before.
[16:38] <jelmer> MvG, you probably want to catch ValueError as well in revid_from_dotted
[16:38] <jelmer> MvG: and return None
[16:38] <MvG> jelmer: Would happen if the tuple has an invalid number of elements?
[16:39] <jelmer> MvG: if there are non-integers in the string
[16:40] <MvG> jelmer: The caller ensures that for now. If it doesn't, I guess I'd rather consider that an error on the part of the caller.
[16:40] <MvG> Of course, I could as well drop the check for the caller...
[16:42] <jelmer> MvG: ah, never mind then
[16:42] <jelmer> also, any particular reason for assigning a variable and returning that rather than returning directly?
[16:42] <jelmer> seems fine otherwise
[16:43] <MvG> jelmer: Easier to insert a debug statement in between, or some further processing step.
[16:47] <MvG> mzz: Thanks for the review!
[16:47] <mzz> sure, but it really doesn't mean much since I really have not looked at this code in ages
[16:48] <mzz> this is more like me getting the impression you know at least as much about what's going on than I did when I wrote all this than me understanding the changes
[16:48] <Morbus> i don't suppose anyone uses trac-bzr in here?
[16:49] <MvG> mzz: and that I made no obvious flaws, or recreated errors you did back then and still remember.
[16:49] <jelmer> Morbus: we were just talking about it :-)
[16:49] <MvG> :-D
[16:49] <Morbus> oh great. i have a newb support question! ;)
[16:49] <Morbus> heh, heh
[16:49] <MvG> Let's hear it.
[16:49] <jelmer> mvg: Anyway, the changes seem fine in general
[16:49] <Morbus> just grabbed the latest lp main, made an egg of it, installed it into local Trac, and made the changes per the README directory.
[16:50] <Morbus> my repo directory is set to [11:42]  <Morbus> repository_dir = /ebs/repositories/bzr
[16:50] <Morbus> which contains a single branch - but eventually with more.
[16:50] <Morbus> when i head to trac/browser, i receive:
[16:50] <Morbus> NoRepositoryPresent: No repository present: "file:///ebs/repositories/bzr/examiner-d7/"
[16:50] <Morbus> so, it's seeing the (only) branch there, but not getting much further.
[16:50] <MvG> jelmer: I'm just debugging a strange incident where a dotted revno won't get accepted as a revision. Requires my fix for bug 274609 as well, otherwise you won't even get that far.
[16:51] <Morbus> i have a traceback too, if you'd like it.
[16:51] <MvG> Morbus: Never did a single-branch setup yet, but wait a few minutes, and I'll try to reproduce.
[16:51] <MvG> Morbus: Yes, please pastebin the traceback.
[16:51] <Morbus> well, i have a need for a second branch already, so maybe i should just make one of those first.
[16:52] <Morbus> lemme do that first, then i'll paste.
[16:52] <Morbus> *pastebin
[16:52] <MvG> Morbus: I'd like the pastebin in any case, even if you don't need a fix,.
[16:52] <Morbus> sure.
[16:52] <Morbus> MvG: http://pastebin.com/m5ca7dcfe
[16:54] <mzz> Morbus: what's the "bzr info" output from inside that branch?
[16:55] <Morbus> bzr: ERROR: No repository present: "file:///ebs/repositories/bzr/examiner-d7/"
[16:55] <Morbus> i blame chx.
[16:55] <Morbus> lemme move this outta the way and test with the brand new repo i just made.
[16:55] <mzz> I don't see off the top of my head how you'd get that in trac-bzr unless there really is no repository (you did something weird like manually copying a branch out of a shared repository?)
[16:55]  * Morbus sighs.
[16:55] <chx> um
[16:56] <jldupont> Anyone using the Bazaar plugin under Eclipse?  How can I "ignore" a file from a directory under revision control ?
[16:56] <jldupont> I keep getting an "*" and it is annoying.
[16:57] <Morbus> mzz/MvG: well, so far, so "good". moved the examiner-d7 outta the way, made a new repo per the tutorial, and now:
[16:58] <Morbus> AttributeError: 'Revision' object has no attribute 'get_apparent_authors'
[16:58] <Morbus> which is likely as i did not whoami, perhaps?
[16:58] <MvG> Morbus: Use newer version of bzr.
[16:58] <mzz> yeah
[16:58] <mzz> I don't know which bzrlib version added that, but that definitely sounds like bzr being too old
[16:58] <Morbus> i'm using the install docs from the site - annoyingly, centos 5/rhel extras only has 1.3. crazy.
[16:59] <MvG> bzr has changed a lot since then, you want to update manually if there are no newer packages for your distro.
[16:59] <mzz> Morbus: your assumption that the version requirement in README is up to date may be overly optimistic
[16:59] <Morbus> well, for bzr in general, not just trac-bzr ;)
[16:59] <MvG> note to self: update README one fine day...
[16:59] <jldupont> anyone with some help?
[16:59] <mzz> jldupont: not for Eclipse, sorry.
[17:00] <mzz> jldupont: manually adding the path to .bzrignore might work, of course.
[17:00]  * MvG doesn't use Eclipse.
[17:00] <GaryvdM> chx: I think Morbus was talking about chx records, not you. :-)
[17:00] <chx> GaryvdM: def me
[17:00] <jldupont> @mzz: and this .bzignore is relative to the project directory?
[17:00] <chx> GaryvdM: I am workin with him
[17:00] <mzz> jldupont: relative to the branch root
[17:00] <GaryvdM> oh
[17:00] <jldupont> @mzz: oh yes, of course... thanks!
[17:01] <mzz> (I'm guessing those are the same thing, but hey, I really don't speak eclipse)
[17:02] <jldupont> mzz: so I put a .bzignore in the .bzr folder?
[17:03] <mzz> jldupont: no, in the same directory .bzr is in
[17:03] <jldupont> mzz: thanks for the help!
[17:03] <mzz> np
[17:05] <jldupont> .bzrignore works like a charm!  Eclipse stops showing annoying "*" all over the place!  Thanks @mzz!
[17:06] <mzz> jldupont: eclipse may well have a friendly click-and-point way of adding paths to that file
[17:06] <mzz> I just don't know what that is
[17:06] <jldupont> mzz: I did look around **a lot**
[17:06] <chx> Morbus: oyu moved the branch outside of the repository, i wash my hands
[17:06] <jldupont> mzz: but of course, I am infallible
[17:07] <jldupont> I mean not infallible !
[17:07] <Morbus> chx: i told you in the other channel i had moved it outta the way *after* it was determined, above, that it "wasn't a repo" according to bzr info.
[17:07] <chx> Morbus: the repository is a holder of branches nothing is visible for most commands its just saving save for simialr branches
[17:08] <mzz> chx, Morbus: I suspect you copied over a branch using cp -r while you wanted bzr push
[17:08] <mzz> err, or branch
[17:08] <chx> mzz: nevermind
[17:09] <mzz> the bzr commands can deal with shared repos, manual filesystem ops won't
[17:14] <Morbus> heh. curse you compile from source!
[17:14]  * Morbus googles.
[17:19] <Morbus> mzz, MvG: well, i've got the latest bzr installed now. and the error is AttributeError: 'module' object has no attribute 'FormatRegistry'
[17:19]  * mzz frowns
[17:19] <mzz> Morbus: what's giving you that? I don't see tracbzr using that
[17:20] <Morbus>  /trac/browser
[17:20] <mzz> Morbus: traceback?
[17:20] <Morbus> http://pastebin.com/m1aa9997b
[17:21]  * MvG is off for dinner.
[17:22] <Morbus> enjoy!
[17:22] <MvG> I probably won't be back today. If any trac-bzr bugs arise and can't be fixed, file bug reports.
[17:30] <Morbus> mzz: any ideas?
[17:30] <mzz> sorry, missed your link, reading...
[17:31] <mzz> Morbus: which bzr is that?
[17:31] <Morbus> 2.0.2
[17:32] <Morbus> tracbzr main as of an hour ago
[17:32] <mzz> I have to wonder if something glitched when installing bzr itself. Sec.
[17:34] <mzz> Morbus: your line numbers don't match the bzr 2.0.2 source tarball
[17:34] <Morbus> o_O.
[17:34] <Morbus> how do i make clean for python? i'll do it again.
[17:34] <mzz> Morbus: how did you install? If this was a manual install consider killing off the existing bzrlib in site-packages completely before running "setup.py install"
[17:34] <Morbus> oh, nevermind. i already deleted source
[17:35] <Morbus> wget http://launchpad.net/bzr/2.0/2.0.2/+download/bzr-2.0.2.tar.gz
[17:35] <mzz> no, hold
[17:35] <mzz> I think I misread something
[17:35]  * mzz forgot about demandload
[17:36] <Morbus> mzz: well, you know...
[17:36] <mzz> still can't explain the traceback though.
[17:36] <Morbus> i actually did just reinstall bzr 2.0.2 fresh, and restarted apache (i run trac through it).
[17:36] <Morbus> now i'm geting an entirely different error
[17:36] <Morbus> fun!
[17:36] <Morbus> NoSuchRevision: CHKInventoryRepository('file:///ebs/repositories/bzr/examiner-d7/.bzr/repository/') has no revision ('vcs-imports@canonical.com-20091124053541-iw4cu21x2aa935fs',)
[17:37] <mzz> that doesn't sound trac-bzr-related either. Does "bzr log" in that examiner-d7 branch work?
[17:37] <Morbus> ok. gimme a few minutes.
[17:37] <Morbus> examiner-d7 is a lp branch, which we're currently upgrading. waiting for it to finish.
[17:38] <Morbus> sorry. two people working on it at same time.
[17:39] <mgedmin> I'm trying to shelve some unrelated changes, sadly, some of them are too close to related changes and bzr joins the two patch hunks together into one big hunk with two unmodified lines of context in the middle
[17:39] <mgedmin> any way to split that?
[17:40] <jelmer> mgedmin, not afaik
[17:40] <mgedmin> is shelve part of the core, or does it come from bzrtools?
[17:41] <mzz> mgedmin: yes.
[17:41] <mgedmin> dpkg -L bzr|grep shelve tells me it's core
[17:41] <mzz> mgedmin: (there's one in each)
[17:41] <mgedmin> oh, fun!
[17:42]  * MvG is back for a very short while
[17:43] <MvG> Is there a way to merge several (i.e. >2) branches into a single working tree without committing anything?
[17:43] <MvG> I want to experiment with the interaction between different fixes but not clobber my repo with throw-away merge revisions.
[17:45] <Morbus> mzz: fyi, after the bzr upgrade, everything's working dandily. so at this point, there's nothing wrong with trac-bzr. it was all dependency problems.
[17:46] <Morbus> MvG ^^
[17:46] <mzz> ok!
[17:46] <MvG> Glad to know.
[17:46] <chx> is it possible to change  a branch to --no-tree
[17:46] <MvG> Will merge two fixes into lp:trac-bzr in a few minutes...
[17:47] <MvG> chx: bzr reconfigure --branch
[19:21] <jfroy|work> Good morning.
[19:21] <jfroy|work> bzrlib API question: is there a recommended API for getting the diff of a commit in a post-commit hook?
[20:10] <bialix> morning igc
[20:11] <bialix> not yet
[20:11] <bialix> anybody here? need help in English
[20:11] <zsquareplusc> i have a BZR repo at sf.net enabled and something fishy is going on there... their loggerhead gives me an error about a revision that was never in one of my branches.
[20:12] <zsquareplusc> is something knwon about the bzr installation there? loggerhead bug? maybe related to the fact that i never ran an init-repo but stored multiple branches?
[20:12] <bialix> igc has used slogan for bzr-explorer: Version Control for Human Beings
[20:12] <zsquareplusc> bialix: i'm here but my guess is i can't help you ;-)
[20:12] <bialix> I need help in translate this
[20:13] <bialix> zsquareplusc: so I need somebody else :-)
[20:13] <bialix> zsquareplusc: what's the error?
[20:13] <zsquareplusc> bialix: well, you could just try and ask anyway maybe someone is willing to help. (or maybe you did and i did not see it as i just joined)
[20:14] <zsquareplusc> bialix: see http://mspgcc.bzr.sourceforge.net/bzr/mspgcc/changes  it just says error / KeyError
[20:14] <bialix> zsquareplusc: thanks. I know how this channel works
[20:14] <zsquareplusc> a search with google shoes the same error for many other repos too
[20:15] <zsquareplusc> s/shoes/shows :-)
[20:16] <zsquareplusc> bialix: ah you want to translate igc's slogan? from english to an other language?
[20:18] <Peng> zsquareplusc: Right now that page says "no revisions".
[20:20] <zsquareplusc> Peng: interesting i saw that also from time to time... but most of the time i get a KeyError. ok after reloading i get that no revisions now too.
[20:20] <zsquareplusc> but there were about 10 branches...
[20:26] <bialix> my connection was interrupted
[20:26] <bialix> zsquareplusc: I don't see error
[20:27] <bialix> zsquareplusc: there is message: No revisions!
[20:28] <bialix> fullermd: hi
[20:29] <zsquareplusc> bialix: yes i get that too now. it happens to change from time to time :/   however there should be about 10 branches...
[20:29] <bialix> that's bad
[20:30] <zsquareplusc> init-repo doesn't work when there is already a .bzr . there seems to be no --force option, so i need to have local filesystem access on the repo?
[20:30] <zsquareplusc> i think i'll start over with the server an upload the branches again
[20:31] <bialix> zsquareplusc: you should have ssh access, no?
[20:32] <zsquareplusc> yes, complicated. searching the docs on their site..
[20:33] <bialix> try hitchhicker
[20:34] <zsquareplusc> what's that?
[20:35] <bialix> launchpad.net/hitchhicker
[20:37] <bialix> I have a question about "for Human beings": is it closer to say just "for Humans" or better use "for mere mortals"? If you can answer please do, I'll read logs tomorrow
[20:41] <zsquareplusc> <- not native english speaking. maybe a bit of both. i guess it goes mostly in the direction, "easy to use" also for non programmers or "you don't have to be a geek/nerd"
[20:43] <bialix> maybe "plain humans" or "ordinary people"?
[20:44] <bialix> the latter sounds fine for me in Russian
[20:44] <GaryvdM> bialix: Hi  - Yes - I think "ordinary people" synonym.
[20:44] <GaryvdM> * is a good synonym
[20:44] <bialix> good
[20:45] <GaryvdM> jfroy|work: I'm not sure if someone has answered your question re diff in post-commit hook.
[20:45] <bialix> because current translation is just "for Humans" -- it does not sound so cool as in English
[20:45] <bob2> it's more like "mere mortals", but "ordinary people" would work too
[20:46] <jfroy|work> GaryvdM: I pulled some code out of bzr-email that seems to work fine
[20:46] <GaryvdM> jfroy|work: Ok - cool
[20:46] <bialix> bob2: mere mortals is stable idiom in my language, thanks for tip
[20:47] <GaryvdM> bialix: I think Bug 487115 may be a win32 or qt version specific bug.
[20:47] <jfroy|work> But actually I could use a quick code review, see if I'm doing something stupid.
[20:48] <bialix> GaryvdM: hmm
[20:48]  * jfroy|work pasted http://pastie.textmate.org/713396
[20:51] <hsn> is somewhere bzr.dev tree available via bzr protocol? http seems to be pretty slow
[20:52] <beuno>  hsn on Launchpad?
[20:52] <beuno> lp:bzr?
[20:52] <beuno> if you have your launchpad username specified, it should use bzr+ssh
[20:56] <hsn> hmm, i cant login to lp, ssl cert error from curl. is there way to ignore certs?
[20:56] <Peng> hsn: On Ubuntu, it should work if you install ca-certificates. Probably.
[20:56] <Peng> hsn: Or stop using curl.
[20:57] <bialix> pycurl
[20:57] <hsn> its on windows
[20:59] <bialix> download ca-perm from Mozilla if you need pycurl
[21:00] <bialix> but better just uninstall it
[21:03] <hsn> https://bugs.launchpad.net/bzr/+bug/82086 its seems to be known bug with pycurl
[21:44] <zsquareplusc> poolie: i'm fighting with one of your old programs... gnu keyring on the palm...
[21:44] <poolie> :)
[21:46] <zsquareplusc> it worked well but as i don't really use the palm any more i wanted to export the database. but no success so far. and the app keeps deleting the DB starting over with an empty one :/
[21:48] <zsquareplusc> and a bzr related question. i just uploaded a branch that's obsolete to a shared repo. should i just delete the folder in the repo? is there a "cleanup" command to get rid of the unused change sets?
[21:48] <poolie> just delete the branch folder
[21:50] <hsn> my bzr segfauls at AppName: python.exe	 AppVer: 0.0.0.0	 ModName: _groupcompress_pyx.pyd ModVer: 0.0.0.0	 Offset: 00005cfb
[21:51] <Peng> zsquareplusc: There is no cleanup command. If you really really wanted to (like if you committed an ISO), you could create a new repository and branch all of your current branches into it, but it's usually not worth bothering.
[21:52] <zsquareplusc> well i'm now uploading the branch that merged the other two so in fact there should not be many "floating" change sets left. OK
[21:53] <zsquareplusc> poolie: you don't happen to have a export tool for gnu keyring for the old 1.0 database format?
[21:54] <poolie> zsquareplusc: not on me; i think there may be one though
[21:54] <poolie> i haven't worked on that for about 7 years
[21:54] <poolie> check on the site or ask on the list
[21:56] <zsquareplusc> poolie: yes i saw someone else took over later. but i was stuck on the version from 2000 anyway ;-) i tried the two java tools from the site, both give errors ("null"?? and "negativearrayindex") the 3rd site is unavailable.. oh well i'll probably end up exporting each one separately to a note and copying those..
[21:58] <lifeless> hsn: please file a bug
[22:11] <zsquareplusc> is there an "ls" for shared repos (listing the branches)? qlog can do it but i'd prefer a console only solution w/o history :/
[22:13] <Peng> zsquareplusc: The bzrtools plugin provides a "branches" command.
[22:13] <Peng> zsquareplusc: You can even run it on URLs, but it might be horrifically slow.
[22:14] <maxb> Is there any way to make bzr diff purely based on filename, ignoring file-ids?
[22:14] <Peng> maxb: Ehh. Why would you need that?
[22:15] <maxb> Dealing with less-than-perfect imports from svn, etc.
[22:18] <zsquareplusc> Peng: thanks that works. i'm using it with bzr:// and it is SLOW. but at least it shows whats requested
[22:20] <Peng> zsquareplusc: Running with --no-plugins /might/ make it faster, but I dunno.
[22:20] <Peng> zsquareplusc: (if you have any plugins like bzr-svn installed, anyway)
[22:31] <lifeless> poolie: where, when for lunch?
[22:34] <chrispitzer> i'm getting a fun rich-root error...
[22:34] <chrispitzer> (pasting 3 lines)
[22:35] <chrispitzer> chris@geordi:~/dev$ bzr push
[22:35] <chrispitzer> Using saved push location: bzr+ssh://bar.com/srv/foobar/www/
[22:35] <chrispitzer> bzr: ERROR: RemoteRepository(bzr+ssh://bar.com/srv/foobar/www/.bzr/)
[22:35] <chrispitzer> is not compatible with
[22:35] <chrispitzer> CHKInventoryRepository('file:///home/chris/src/dev/.bzr/repository/')
[22:35] <chrispitzer> different rich-root support
[22:35] <lifeless> you need to upgrade foobar/www
[22:35] <chrispitzer> the repo?  or the bazaar instance?
[22:36] <lifeless> the repo
[22:37] <chrispitzer> chris@zim:/srv/bar/www$ bzr upgrade
[22:37] <chrispitzer> bzr: ERROR: The branch format Meta directory format 1 is already at the most recent format.
[22:37] <chrispitzer> is that the upgrade method you're talkign about?
[22:37] <lifeless> sounds like you need to upgrade that bzr install as well
[22:38] <lifeless> to 2.0 or newer (thats what you have on @geordi, and why you are getting this error)
[22:39] <chrispitzer> i just ran apt-get upgrade bzr ... but that didn't seem to do it... is that correct?
[22:40] <lifeless> well, what OS are you using?
[22:40] <zsquareplusc> Peng: i do have some plugins like bzr-svn but --no-plugins also disables bzr tools itself :/
[22:41] <lifeless> if its a release of ubuntu or debian you can use our PPA. If you are using a development version of Ubuntu or Debian you should have 2.0 already (but may need to apt-get update first to make it visible)
[22:55] <poolie> hi jam
[23:26] <Peng> zsquareplusc: Haha, good point. Sorry.
[23:28] <zsquareplusc> Peng: there should be an additional option to selectively allow some plugins :-) (don't know if there is already)
[23:29] <Peng> zsquareplusc: Yeah, that'd be nice.
[23:48] <jam> hey poolie
[23:48] <jam> I'm only around a bit, finally caught a bit of a break
[23:49] <poolie> just wanted to say hi
[23:49] <poolie> and that we're scheduled to do 2.1b3 i think this week
[23:49] <poolie> maybe someone else could do it
[23:49] <jam> poolie: 2.1.0b3 is cut
[23:49] <jam> "gone gold"
[23:49] <jam> win32 installers are built
[23:50] <jam> just needs ... anouncment?
[23:50] <jam> I was probably going to announce yesterday, but didn't even open my laptop
[23:50] <jam> and now, I'm probably going to be done in about 10 min