[00:01] <abentley> Odd_Bloke: It stands for "finish".
[00:07] <Odd_Bloke> abentley: 'finish' implies "I'm done shelving things now, everything else should remain unshelved", whereas it seems to mean "shelve the rest" (which I would equate with a 'yes to (a)ll' option).
[00:11] <Odd_Bloke> abentley: I would like to modify '(f)inish' to be 'yes to (a)ll' and create a '(d)one' which means no to all.  Thoughts?
[00:12] <lifeless> Odd_Bloke: what about 'n(o) to all'
[00:12] <lifeless> Odd_Bloke: its odd to have one side abbrev and one fully expressed
[00:13] <Odd_Bloke> lifeless: I'm not sure that the meaning is symmetric.  That is to say, I don't expect 'yes to all' to change previous responses, but some part of my mind says that 'no to all' might change previous responses.
[00:14] <lifeless> Odd_Bloke: yes to remaining, no to remaining
[00:15] <Odd_Bloke> How about: '(y)es, (N)o, (s)helve remaining, (d)on't shelve remaining, (q)uit'?
[00:16] <Odd_Bloke> For some context, I'm looking at bug #327429, so am adding a help option to the prompt (with these longer strings).
[00:18] <lifeless> does lp mark bugs as fixed when commits land?
[00:18] <lifeless> mwhudson: ^
[00:18] <mwhudson> nope
[00:18] <mwhudson> we've been told to fix that soon, i understand
[00:22] <abentley> Odd_Bloke: I don't want that.
[00:22] <abentley> Odd_Bloke: I want it to behave the way shelf1 did.
[00:22] <abentley> Odd_Bloke: Which is that it applies the current default to everything.
[00:23] <abentley> Odd_Bloke: I especially don't want to use "d", because I want that to mean "diff".
[00:23] <Odd_Bloke> abentley: 'the current default'?
[00:23] <abentley> Odd_Bloke: That's why I changed it from "d", which is what shelf1 used.
[00:23] <abentley> Odd_Bloke: Yes.  Shelf1 had a current default, either yes or no.
[00:24] <abentley> Odd_Bloke: If you pressed enter, you got the default.
[00:24] <abentley> If you pressed "f", it applied the default to everything.
[00:24] <abentley> sorry, "d" for shelf1.
[00:24] <Odd_Bloke> What determined that default?
[00:24] <abentley> Odd_Bloke: The "i" key.
[00:25] <abentley> Odd_Bloke: It was a toggle.
[00:25] <Odd_Bloke> So if I get a '[yN..]' prompt, 'i' would change it to '[Yn..]' and 'd/f' would apply whichever the default was to the remainder?
[00:26] <abentley> Yes.
[00:27] <Odd_Bloke> Interesting.
[00:28] <lifeless> that seems more complex, is it really more useful than y/n/Y-remaining/N-remaining/toggle-all/diff ?
[00:28] <lifeless> s/useful/suable/
[00:28] <abentley> lifeless: what's toggle-all?
[00:29] <lifeless> invert-selection or whatever it was called
[00:29] <lifeless> didn't shelve1 let you switch all the current selected hunks
[00:29] <lifeless> not sure that that is needed even, to be honest
[00:29] <abentley> lifeless: I don't think so.
[00:29] <abentley> I'm pretty sure "i" just changed the default.
[00:30] <lifeless> oh
[00:31] <abentley> lifeless: Are you suggesting using capital letters for the "do-it-to-the-remainder" commands?
[00:31] <lifeless> abentley: yes, in my sketch there
[00:31] <spiv> "toggle-all" in shelve1 was "shelve --all; unshelve", and then the meanings of "y" and "n" were inverted :)
[00:31] <Odd_Bloke> Using caps for options makes indicating the default harder.
[00:32] <abentley> lifeless: I guess we could eliminate the "default" concept.
[00:33] <abentley> lifeless: I'm less keen on using capitals to represent "do-it-to-the-remainder".
[00:34] <abentley> I guess "a" and "v" have sometimes been used for Always and NeVer.
[00:34] <lifeless> abentley: a and v would work too
[00:37] <Odd_Bloke> I prefer the always/never option to the toggle-default option.
[00:37] <abentley> Odd_Bloke: Yeah, I probably do, too.
[00:40] <Odd_Bloke> OK, so go for: '(y)es, (N)o, (a)lways shelve remaining, ne(v)er shelve remaining, (q)uit'?  With a '(d)iff' option to come later.
[00:49] <lifeless> I prefer different letters to caps on consideration
[00:50] <igc> poolie: I think http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20090130002957.52fd7d09%40gibibit.com%3E ought to go into 1.12rc as well
[00:51] <igc> it's a small patch that I'll land later today if no-one else gets around to reviewing it
[00:56] <Odd_Bloke> abentley, lifeless: Are you happy with the options I suggested at :40?
[00:59] <lifeless> 11:37 < Odd_Bloke> OK, so go for: '(y)es, (N)o, (a)lways shelve remaining, ne(v)er shelve remaining, (q)uit'?  With a '(d)iff' option to come later.
[00:59] <lifeless> ?
[00:59] <abentley> Odd_Bloke: Yes.
[01:00] <lifeless> I think quit should be '(c)ancel'
[01:00] <lifeless> quit isn't clearly 'quit-and-do' or 'quit-and-abort'
[01:03] <jelmer> so, ohloh finally has Bazaar support (-:
[01:17] <mwhudson> beuno: hello?
[01:27] <mwhudson> LarstiQ: you here/awake?
[01:50] <beuno> mwhudson, hi
[01:52] <mwhudson> beuno: have a look at this http://pastebin.ubuntu.com/116271/
[01:52] <mwhudson> it's a template and some code
[01:53] <mwhudson> i'm trying to think of ways of using bzrlib objects in templates, but still having nice spellings of things that are important to us
[01:55] <beuno> mwhudson, looks good, although I don't think I understand very well why you have revinfo and revision
[01:56] <mwhudson> revision is a bzrlib revision
[01:56] <mwhudson> revinfo is a way of getting extra information about it
[01:56] <mwhudson> maybe it would be better to wrap the bzrlib revision in some other object
[01:57] <beuno> yeah, I kinda like accesing the revision in only one way
[01:59] <mwhudson> is that a voted for a wrapped revision?
[01:59]  * beuno thinks
[02:00] <beuno> I think so. Is there something bad about it I'm missing?
[02:05] <lifeless> mwhudson: what extra info?
[02:20] <beuno> lifeless, I think it's more like branch info
[02:22] <beuno> anyway, that's it from me today
[02:22] <beuno> mwhudson, I'll read the backlog and reply tomorrow. Have fun  :)
[02:24] <mwhudson> lifeless: revision number, formatted date
[02:25] <mwhudson> nothing very deep, but i dislike having too much python in my templates
[02:37] <lifeless> mwhudson: ok, so its RevisionInBranch not Revision
[02:37] <lifeless> formatted date -> patch bzrlib please
[02:37] <mwhudson> yes, i guess that makes sense
[02:41] <mwhudson> bzrlib already has a RevisionInfo-that-is-really-RevisionInBranch
[02:44] <Lag117> hello
[02:45] <Odd_Bloke> Lag117: Hi.
[02:45] <Lag117> anyone else get "bzr: ERROR: No module named PyQt4" when running "bzr help commands" in bzr 1.11?
[02:45] <Lag117> used to work, not sure when it broke though
[02:46] <Lag117> by work, I mean a list commands and brief desc was output in plaintext, not Qt GUI or anything
[02:46] <Lag117> should I just try install PyQt4 manually? i.e. from http://www.riverbankcomputing.co.uk/software/pyqt/download
[02:47] <igc> Odd_Bloke: I'd like to land your --no-tree patch but it's failing tests ...
[02:47] <igc> test_sprout_branch_no_tree() for BzrDirFormat5 and BzrDirFormat6
[02:47] <igc> Odd_Bloke: do you have a moment to tweak that?
[02:48] <Odd_Bloke> igc: Sure, I'll look at it in a moment.
[02:49] <igc> Odd_Bloke: thanks.
[02:55]  * igc lunch
[02:56] <spiv> Lag117: sounds like a bug in the qbzr plugin, maybe?
[02:56] <Lag117> to list help?
[02:56] <lifeless> Lag117: yes
[02:56] <Lag117> spiv: just trying to run "bzr help commands" -- is qbzr plugin part of that?
[02:56] <lifeless> Lag117: plugins can add commands
[02:56] <Lag117> oh GREAT
[02:56] <lifeless> Lag117: 'bzr --no-plugins help commands' will list commands without plugins
[02:57] <Lag117> lifeless: that works
[02:57] <Lag117> is there a verbose or something else to see more clearly where it fails?
[02:57] <lifeless> -Derror will cause a traceback to be shown, I think
[02:57] <lifeless> if not, then your ~/.bzr.log will have the import error traceback
[02:58] <Lag117> sweet, `tail -f ~/.bzr.log` and then running `bzr help commands` shows the errors
[02:58] <Lag117> should I paste it somewhere / file a bug?
[02:59] <lifeless> Lag117: well, if its that pyqt4 isn't installed, I'd install it :)
[02:59] <lifeless> if it stopped working, I'd chat to some of the qbzr guys, they do hang out here
[02:59] <Lag117> lifeless: I tried, but getting errors trying to compile it
[02:59] <lifeless> but they aren't on at the moment
[03:00] <lifeless> perhaps ask a question at http://answers.launchpad.net/qbzr
[03:00] <Lag117> I'll do that, great idea
[03:00] <Lag117> another question, is it possible to kill a built-in plugin?
[03:01] <Lag117> i.e. so I wouldn't have to add --no-plugins every time?
[03:06] <Lag117> haha, I can't get PyQt installed from source or using MacPorts.  I'm a failure.
[03:13] <poolie> spiv: hello?
[03:13] <poolie> Lag117: just remove the directory
[03:13] <poolie> which one?
[03:13] <Lag117> poolie: "which one?" -> for spiv?
[03:13] <poolie> for you
[03:14] <Lag117> poolie: sudo port install py25-pyqt4
[03:14] <Lag117> although it looks like maybe py-pyqt4 will work?
[03:14] <Lag117> (trying it now)
[03:14] <jdong> have fun building qt4 if you haven't :)
[03:14]  * jdong inserts 80,000 leap seconds or so to pass the time
[03:15] <jdong> would it be unreasonable for me to whine to the qbzr folks that setup.py should not build and/or install if it can't import pyqt4?
[03:16] <Lag117> I am all for having a working bzr install, so no, not unreasonable
[03:16] <Lag117> either make it work, or don't include it in base install
[03:16] <lifeless> poolie: spiv is here hacking with me
[03:16] <poolie> > Lag117: another question, is it possible to kill a built-in plugin?
[03:16] <jdong> Lag117: oh it came with the default without bundling an qt4?
[03:16] <poolie> which plugin do you want to kill?
[03:16] <Lag117> poolie: qbzr
[03:16] <jdong> poolie: the qbzr
[03:17] <jdong> assumes on OSX  you have pyqt4 bindings
[03:17] <Lag117> poolie: I can move /Library/Python/2.5/site-packages/bzrlib/plugins/qbzr/ ?
[03:17] <poolie> lifeless: thumper and i have scheduled a meta-development call
[03:17] <jdong> Lag117: yeah you can just remove that directory
[03:17] <poolie> i don't know if maybe it's better to just let you two get on with actual development?
[03:17] <jdong> though That's A Bug (tm) if the OS X version installs that by default
[03:17] <jdong> where Bug = 99.9%-false assumption ;-)
[03:18] <lifeless> poolie: my 2c would be that you two can have a meta-development call, and spiv and I will get streaming push pushed forward :P
[03:18] <Lag117> jdong: are you saying it's just a problem with the OS X binary installer? that makes some sense
[03:19] <jdong> Lag117: I know for sure the Windows installer properly bundles the QT libs needed for an out-of-box install
[03:19] <jdong> Lag117: perhaps the OS X installer attempts to do so but fails
[03:19] <jdong> I've never installed bzr from the OS X installer before; I've always used Macports for that
[03:19] <Odd_Bloke> What's meta-development (and is this question meta-meta-development)?
[03:20] <jdong> Odd_Bloke: I suppose that's where you hash out a working plan for what to work on :)
[03:20] <jdong> and lifeless is conducting meta-meta-development.
[03:20] <jdong> which I'll coin (meta^n)development for some integer n
[03:22] <Lag117> PROBLEM RESOLVED, THANKS: cd /Library/Python/2.5/site-packages/bzrlib/plugins; sudo tar -cf qbzr.tar qbzr; sudo rm -rf qbzr
[03:22] <jdong> while you're having fun, would you like to file/search for a bug on this?
[03:22] <jdong> just so the people who do the OS X installer are aware
[03:22] <Lag117> where is the proper place to file OS X installer bug?
[03:22] <jdong> they probably are that 0.1% who lug around a 500MB or whatever QT4 install and never know that the bug exists ;-)
[03:23] <Lag117> point me I'll happily file a bug
[03:23] <mwhudson> anyone want to look at a loggerhead branch?
[03:24] <jdong> Lag117: since it's a bzr installer issue I'd file it against launchpad.net/bzr unless the devs here tell you otherwise
[03:24] <Lag117> jdong: will do, thanks again!
[03:25] <jdong> sure thing, but thank YOU :)
[03:28] <Odd_Bloke> igc: Just sent you (and the ML) a mail with an updated --no-tree patch.
[03:28] <Odd_Bloke> We now error on old formats, and the test tests for this.
[03:28] <Odd_Bloke> I don't know if you want to merge that without another BB vote, though. :)
[03:29] <Odd_Bloke> Right, as I have to leave for work in just over 4 hours I should probably go to bed. :p
[03:30] <Odd_Bloke> NN.
[03:32] <Lag117> bug for my OS X installer issue: https://bugs.launchpad.net/bzr/+bug/327487
[03:33] <Lag117> hmm, auto-bot?
[03:49] <igc> thanks Odd_Bloke
[03:50]  * igc offline for an hour or so
[04:05] <mwhudson> mmm
[04:06]  * mwhudson fails to see an easy way to get the most recent change for a path from a revision tree
[04:06] <mwhudson> i.e. "inventory_entry.revision"
[04:53] <Peng_> Is a copy of bzr.dev supposed to have 2 ghosts?
[04:56] <lifeless> yes
[04:57] <lifeless> mwhudson: tree.inventory[tree.path2id(PATH)].revision
[04:58] <Peng_> lifeless: Thanks?
[04:58] <Peng_> Hmm, am I going to bother to reconcile the inconsistent parent?
[04:58] <lifeless> Peng_: up to you :)
[05:02] <Peng_> I normally would, but I'm not sure this machine has the RAM to do it, so I rsynced it down, and really don't want to rsync a different version back up again.
[05:19] <Kobaz> or at rackslice
[05:19] <Kobaz> er
[05:26] <igc> back
[05:28] <mwhudson> man
[05:28] <mwhudson> there's "not designed for testability"
[05:28] <mwhudson> and then there's loggerhead
[05:28] <Peng_> Oh good, I do have the RAM for reconcile.
[05:34] <lifeless> poolie1: http://paste.ubuntu.com/116333/
[05:34] <lifeless> igc: ^
[05:34] <lifeless> pop quiz, which one is packs, and which is gc?
[05:34] <lifeless> (they are both the first 2K revs of bzr.dev)
[05:34] <Lag117> spiv: lifeless: poolie1: jdong: THANKS, YOU ARE GREAT HELP! Keep up awesome work :)
[05:36] <igc> lifeless: gc is the latter?
[05:37] <lifeless> yes :)
[05:38] <igc> lifeless: so I always expected gc to be smaller. How's the speed in your tests?
[05:38] <lifeless> ~ the same
[05:38] <igc> sweet
[05:39] <lifeless> random access ops need a large page cache
[05:39] <igc> lifeless: I did run some gc-plain benchmarks last Friday but I'm yet to check them
[05:39] <lifeless> and I want more instrumentation about where things are going on
[05:39] <igc> (have been visiting Mum & Dad until a few minutes ago)
[05:40] <lifeless> cool
[05:41] <lifeless> igc: repo-details has support for gc now; it needs a bzr.dev, rather than a bbc branch when you invoke it, because of api changes in bbc
[05:42] <lifeless> but the same repo-details code can also analyse a bbc branch if run from a bbc bzr :P
[05:49] <poolie1> lifeless: nice
[05:50] <davidstrauss> How experimental is "bzr join"?
[05:53] <poolie1> fairly
[05:53] <davidstrauss> What's the best vendor branching strategy at the moment, then?
[05:53] <davidstrauss> ConfigManager looks ancient and unmaintained.
[05:53] <poolie1> i would say probably using the scmproj plugin
[05:54] <davidstrauss> Isn't that alpha code?
[05:54] <poolie1> yes, but simple and actively maintained
[05:54] <poolie1> lifeless: can you please make a 1.12 branch before you sign off?
[05:54] <poolie1> now is fine
[05:55] <davidstrauss> Is it release time?
[05:57] <Sup3rkiddo> hi all, i am beginning to use bzrlib. and I am stuck at the type which 'source' belongs to when I call the pull method of the Branch class
[06:09] <mthaddon> poolie1, lifeless: the looping PQM failure you saw a while back was that I'd added a script to "clean up" the chroot before each run, but it was failing on 4 temp files that were owned by root - these have been removed, so you okay for me to re-enable?
[06:10] <poolie1> mthaddon: not today please, i'm about to do a release
[06:10] <poolie1> now+24h would be ok
[06:10] <poolie1> hm
[06:10] <mthaddon> poolie1: ok, fair enough - will look at it again tomorrow (will check with you first)
[06:10] <poolie1> do you know how root-owned files got in there?
[06:11] <poolie1> our make check doesn't run as root (afaik)
[06:11] <mthaddon> poolie they were from May 22nd of last year, so not recent in any way
[06:14] <lifeless> poolie1: done
[06:15] <poolie1> mthaddon: i don't suppose you noticed what they were?
[06:16] <mthaddon> poolie1: empty files
[06:23] <jeddy3> hmm, does bzr-svn warn about upgrading to subversion 1.5 always? seems like i have newest version, still it hints :|
[06:30] <lifeless> jeddy3: you have svn 1.5 on the server?
[06:30] <jeddy3> lifeless: yes, afaict
[06:30] <lifeless> jeddy3: I'm not sure then - perhaps ask a question on https://answers.launchpad.net/bzr-svn
[06:31] <jeddy3> lifeless: svn --version:
[06:31] <jeddy3> svn, version 1.5.2 (r32768)
[06:31] <lifeless> jeddy3: thats your client isn't it?
[06:31] <jeddy3> svnserve --version:
[06:31] <jeddy3> svnserve, version 1.5.2 (r32768)
[06:31] <jeddy3> svnadmin: the same
[06:31] <lifeless> jeddy3: thats still on your machine - I'm saying you need to ssh into the server or something (unless you've done that alread)
[06:31] <jeddy3> lifeless: that is on the server, yes
[06:32] <lifeless> jeddy3: ok, definitely don't know the answer then sorry :(
[06:32] <lifeless> jeddy3: though I believe you have to do a dump-load on the repo to upgrade it
[06:33] <jeddy3> lifeless: hmmmmm, the repo was svnsynced from a old repo, that might have something to do with it?
[06:33] <jeddy3> lifeless: then it still might be a old repo i guess
[06:40] <mthaddon> lifeless: any idea what's going on here - https://pastebin.canonical.com/13652/ ?
[06:41] <lifeless> mthaddon: I think you're pasting text to me
[06:41] <jeddy3> :D
[06:41] <lifeless> poolie1: oh. 1.12 forgot the config, one sec
[06:42] <poolie1> lifeless:  i forgot, i should have asked spm for the practice
[06:42] <lifeless> poolie1: its ok :)
[06:42] <lifeless> done
[06:42] <mthaddon> lifeless: I am, yes - would you prefer me to paste it in channel?
[06:43] <lifeless> mthaddon: just teasing :P
[06:43] <lifeless> mthaddon: as it says, old format, can't lock over the wire
[06:43] <mthaddon> oh, I'm a little slow - must be the jetlag...
[06:43] <mthaddon> lifeless: should I ask stub to update the branch and that should fix it?
[06:43] <lifeless> yes
[06:44] <mthaddon> thx
[06:44] <lifeless> that format apparently can't be used over bzr+ssh at all
[06:44] <lifeless> I would file a bug on that, but don't expect it to get radical action
[06:45] <poolie1> ah
[06:45] <poolie1> that was me
[06:45] <poolie> i think it was still a good idea though
[06:45] <poolie> mthaddon: you must have been getting that warning for the last several months
[06:45] <vila> hi all (still shaving so not quite still there)
[06:45] <poolie> otoh you can't upgrade it yourself
[06:46] <poolie> be careful, vila! :)
[06:46] <vila> poolie: :-)
[06:46] <mthaddon> poolie: yeah, I have only just tried to do this now - haven't tried to branch from this one before
[06:47] <vila> I just replied to the standup mail where you said my https was complex, is there anything I can explain which could help ? (I didn't mean to make it complex, I even tried to avoid going too far there :-/)
[06:47] <vila> s/my https/my https fix/
[06:51] <poolie> hm
[06:52] <poolie> i think i was transcribing john saying that
[06:52] <poolie> i had not read it at that time
[06:52] <poolie> mthaddon: either ask stub or file an lp ticket asking for an upgrade
[06:52] <poolie> or are you a losa yourself?
[06:52] <mthaddon> :)
[06:53] <vila> poolie: ha, then may be he referred to the fact that I found nasty bugs in tests on the way...
[07:12] <poolie> mthaddon: pqm seems to be neither accepting or rejecting my merges
[07:12] <poolie> ie i sent one and i got neither mail nor anything in the web ui
[07:12] <mthaddon> poolie: let me check the logs
[07:12] <poolie> thanks
[07:14] <mthaddon> poolie: when did you send it?
[07:15] <poolie> a few minutes ago
[07:15]  * poolie checks
[07:15] <mthaddon> nothing in the logs...
[07:15] <poolie> sorry, problem here
[07:15] <mthaddon> ok, np
[07:41]  * igc dinner
[07:58] <poolie> vila, i get a failure in test_http with your patch
[07:58] <poolie> about the deprecation
[07:58] <poolie> it should be easy
[08:13] <davidstrauss> .join #nexenta
[08:13] <davidstrauss> oops
[09:20] <poolie> vila, hi
[09:20] <vila> poolie: Hello :)
[09:35] <igc> poolie: I've sent that commit template patch off to pqm now. If it misses the RC, it would be nice to include it in 1.12 final.
[09:37] <poolie> igc, thanks, i already branched
[09:37] <poolie> seems ok for final though
[09:38] <igc> poolie: I expected as much. np.
[09:46] <poolie> woo
[09:48] <Peng_> Congrats :)
[09:49] <Kinnison> poolie: ace.
[09:49] <poolie> hello kinniwinnie!
[09:50] <poolie> reading the news for this release it's just ian ian ian :)
[09:51] <Kinnison> Heh
[09:54] <Peng_> poolie: Maybe that should be the codename. :D
[09:54] <poolie> maybe it should have been
[09:55] <Youssef> hi
[09:55] <poolie> ok i think that's enough for me
[09:55] <Youssef> Lo-lan-do: are you threre?
[09:55] <poolie> have a good day or night as appropriate
[09:56] <Youssef> lol
[09:56] <Youssef> a good day for me
[09:56] <Lo-lan-do> Yes
[10:03] <Mez> hey, is there a way with bzr to make sure that all branches are automatically binded upstream. Pretty much so it works like svn, but so you can also --local or similar (bzr seems to work better with merging)
[10:05] <Mez> I'd say something like binding a repo, rather than a branch
[10:06] <Lo-lan-do> Mez: Use locations.conf
[10:07] <Youssef> okay Lo-lan-do see the error i get after a commit under windows
[10:07] <Lo-lan-do> bound_location = bzr+ssh://...
[10:07] <Lo-lan-do> bound_location_policy = appendpath
[10:07] <Lo-lan-do> bound = True
[10:07] <Lo-lan-do> ...all that in a [/path/to/local/repo] block
[10:09] <Mez> that should work
[10:09] <Youssef> Lo-lan-do: see http://rafb.net/p/fjwkwU75.html
[10:10] <Youssef> and?
[10:12] <bialix> it's a know bug. poke spiv about it
[10:12] <bialix> I'd say it harmless
[10:15] <Youssef> but one thing! the checkout works well
[10:15] <Youssef> but i have this error log
[10:16] <Youssef> bialix: can you give me the adress to this reported bug please?
[10:17] <bialix> please, looking for in the bzr bugtracker. I'm sure I've filed this bug in the past
[10:17] <bialix> perhaps it's tagged with "win32"
[10:20] <Youssef> bug tracker?
[10:20] <Youssef> where is it?
[10:21] <Youssef> sorry if I disturb you man
[10:21] <Youssef> hihi ^^;
[10:24] <bialix> @launchpad.net/bzr
[10:26] <Youssef> thanks
[10:57] <Youssef> https://bugs.launchpad.net/bzr/+bug/327558
[10:57] <Youssef> my bug
[10:59] <Youssef> any comment?
[11:03] <Lo-lan-do> Did you find the previous bug?
[11:10] <Youssef> wich?
[11:16] <Lo-lan-do> The one filed by bialix
[11:21] <Youssef> the only one from bialix is https://bugs.launchpad.net/bzr/+bug/307270
[11:22] <Youssef> they are not alike
[11:22] <Youssef> hihi ^^;
[11:22] <ronny> moin
[11:23] <Youssef> ronny ?
[11:23] <Youssef> what are you saying?
[11:23] <ronny> jelmer: can bzr's internal db be extended to additional object types?
[11:24] <bialix> ronny: hi
[11:24] <bialix> ronny: you're the author of anyvc, right?
[11:24] <ronny> yeah
[11:25] <bialix> I've looked at your project a bit
[11:25] <bialix> seems interesting
[11:25] <ronny> thanks :)
[11:25] <bialix> and perhaps could be useful for scmproj
[11:26] <bialix> where its development happens? it has ML? irc channel?
[11:26] <ronny> i developed it as part of the pida ide
[11:26] <ronny> so pidas irc channel/google group is the right place to take a look
[11:26] <bialix> so you're the author the pida ide as well?
[11:27] <ronny> im one of the core devs, the orginal author is ali afshar
[11:27] <bialix> the code seems a bit coupled to the pida itself, it's not generic enough, does it?
[11:28] <ronny> anyvc is fully extracted and not coupled
[11:28] <ronny> needs nothing of pida
[11:28] <bialix> I mean at design ideas
[11:28] <bialix> level
[11:28] <ronny> nothing there, too
[11:28] <bialix> well, then it was wrong impression
[11:29] <ronny> the usage from pida is rather simple - invoke anyvc in another thread
[11:29] <bialix> I'd like to clarify my interest: I'm working in scmproj -- it's a vcs-agnostic emulation of nested trees/repos/submodules etc.
[11:30] <bialix> so your lib will be in help to support mixed projects
[11:30] <bialix> where there are components checked out from different vcs
[11:31] <bialix> I need to finish some other things in scmproj, then I'l ltry to look at your lib closer
[11:31] <ronny> so single branch management would come in handy
[11:31] <ronny> cause thats one of the things i need to get done rather soon
[11:31] <bialix> single branch?
[11:31] <ronny> basically get me "rev x from repo/branch y into this dir"
[11:32] <bialix> yes, agreed
[11:32] <ronny> however it might tricky to get that working with stuff like darcs
[11:32] <bialix> I can help from bzr point of view
[11:32] <bialix> yeah, darcs is special there
[11:32] <ronny> bzr should be the most easy there
[11:32] <ronny> just a branch
[11:33] <bialix> ronny: am I understand correctly you mostly familiar with hg?
[11:33] <ronny> yeah
[11:33] <bialix> bzr branch model a bit different from hg/git
[11:33] <ronny> yeah
[11:33] <bialix> so maybe we need to cooperate on this
[11:36] <ronny> bialix: http://ronny.uberhost.de/2009/1/12/reasonable-abstractions-of-vcs-history-and-branching <- this is my basic highlevel idea, the bits  about the relations might need some changes
[11:37] <bialix> ok, I'll read it
[11:37] <ronny> bialix: i took quite some time to figure this first iteration, its not quite right, but a reasonable starting point
[11:38] <bialix> ok, anyway I'm tabula rasa today. Maybe I'll can suggest something reasonable. will see
[11:39] <ronny> tabula rasa?
[11:40] <bialix> empty mind
[11:40] <bialix> http://en.wikipedia.org/wiki/Tabula_rasa
[11:42] <bialix> i.e. I'm not ready tosay anything smart yet
[11:42] <ronny> hmm
[11:43] <ronny> btw, personaly i belive git-style content addressed databases are the way to go, just git isnt
[11:53] <beuno> mwhudson, FYI, I did upload LH to the bzr PPA when I released
[13:02] <vila> verterok: hi
[13:02] <verterok> vila: hi!
[13:03] <vila> 1.12rc1 is out, do you think you can do an OSX-10.4 dmg for it ?
[13:04] <verterok> vila: yes. but not until friday :( (I'm not at my home, and don't have my ibook with me)
[13:04] <beuno> vila, I'll let you in on a little secret, verterok now has a newer mac, so he can actually build for both versions!
[13:04]  * beuno runs
[13:04] <vila> ha rats
[13:04] <vila> hehe, which one ?
[13:05] <beuno> the new and shiny mackbooks
[13:05] <verterok> vila: the aluminum
[13:05] <vila> unibody ? 15" ? 17" ?
[13:05] <vila> they are gorgeous...
[13:06] <vila> verterok: jokes apart, will you be able to build for both 10.4 and 10.5 ?
[13:06] <verterok> vila: unibody 13'
[13:07] <verterok> vila: I'll try to talk with somebody at home, and try to plug my ibook to the net, if I can get that building the dmg its just a matter of ssh :)
[13:07] <vila> verterok: that would be awesome !
[13:08] <verterok> vila: I'll need to create the installer for 10.5, or talk to phanatic to get his installer sources
[13:08] <verterok> vila: once that donem I can build the dmg
[13:08] <vila> verterok: it would be good if you can notes doing that, I'd like to be able to a be backup for building them
[13:09] <vila> s/can notes/can take notes/
[13:10] <verterok> vila: the best case, is that phanatic has the 10.5 installed source pushed to some public location :)
[13:10] <verterok> vila: cool
[13:16] <verterok> beuno: are you back in .ar? would you mind to go to my home and plug my ibook? :p
[13:16] <verterok> ;)
[13:20] <beuno> verterok, I am!   hahah
[13:20] <beuno> I could...
[13:21] <verterok> beuno: welcome back!
[13:21] <beuno> verterok, thanks  :)
[13:21] <verterok> beuno: for the moment isn't neccesary, I think my parents should handle the task. i'll let you know otherwise.
[13:21] <beuno> although I leave on Sat again
[13:22] <beuno> Berlin
[13:22] <vila> verterok: beuno said: "runs" minutes ago, I think he's on his way to your home
[13:22] <beuno> so if you're around here before that, we can have some lunch or dinner  :)
[13:22] <beuno> vila, it's too hot to run. I probably meant "gets on a taxi"  :)
[13:23] <vila> rats, you happy guys, there is a storm here with rain and wind going up to 140km/h (they said, but 95km/h has been observed this morning)
[13:25] <vila> fullermd: ping, what was the funny option you used with 'date' and '1234567890' ?
[13:25] <awilkins> What's the recommended Python version for bzr? 2.5 or 2.6?
[13:37] <verterok> awilkins: I keep using 2.5 for bzr
[13:45] <vila> awilkins: 2.5
[13:46] <vila> pqm runs 2.4, almost everybody else runs 2.5
[13:52] <Odd_Bloke> Why do we still support 2.4?
[13:55] <Lo-lan-do> Odd_Bloke: Etch and Dapper?
[13:55] <Lo-lan-do> Bah, scrap Etch, 2.5 is available there too.
[13:56] <Lo-lan-do> Maybe other distros :-)
[13:57] <Odd_Bloke> Lo-lan-do: But can you run recent versions of bzr on Dapper anyway?
[13:57] <Odd_Bloke> And the RPM distros won't have it because they don't seem to support multiple versions of Python.
[13:57] <Lo-lan-do> Don't look at me, I don't think I installed Dapper even once.
[13:58] <Odd_Bloke> Fair enough.
[13:59] <Lo-lan-do> I still have quite a few Etches, but they'll migrate to Lenny pretty soon after the release (unless all my potential clients demand to become actual clients *right now*).
[14:02] <nevans> ugg... just encountered a nasty bug with "bzr svn-push".  reporting it now, then I'll see if I can reliably replicate it.
[14:02] <Odd_Bloke> My one server is tracking lenny ATM.
[14:11] <nevans> hmm... never mind.  it would appear to be a bug in trac, not a bug in bzr-svn.  :-)
[14:12] <nevans> trac was reporting the changeset incorrectly.  "svn log -v" shows everything is okay.
[14:24] <jam> jelmer: I'm working on the 1.12rc1 win32 installers, should I be using bzr-svn 0.5, or still 0.4.17?
[14:35] <verterok> yay! ohloh.net just added Bazaar support!
[14:35] <jelmer> jam, 0.5.0
[14:38] <jam> jelmer: did we get clear "upgrading bzr-svn" notes written?
[14:39] <jelmer> jam, see UPGRADING in the source tarball
[14:39] <jelmer> They're quite short though
[14:50] <Lo-lan-do> verterok: Yay indeed :-)
[14:51] <jam> abentley: if you get a chance, can you release bzrtools 1.12? I'm trying to put together the win32 installers
[16:11] <LarstiQ> mwhudson: I'm alive again now.
[16:22] <yee> does someone knows how to update a remote working tree using bzrlib??
[16:22] <abentley> jam: sure
[16:22] <LarstiQ> oh hey 1.12
[16:24] <Lo-lan-do> yee: There's a plugin for that.
[16:27] <LarstiQ> yee: the bzr-upload and push-and-update plugins do work in that area.
[16:30] <NfNitLoop> the web site claims that "A candidate for the 1.11 release is also available, released on the 10th of February."
[16:30] <NfNitLoop> typo?  ;)
[16:31]  * NfNitLoop reads up on the changelog. 
[16:31] <yee> the thing is I'm building a webapp wich needs to push local changes to a remote branch, and I'm using bzrlib to open the branches and push from one to the other
[16:31] <yee> but the working tree doesn't get updated
[16:31] <NfNitLoop> yee: that's by design.
[16:31] <NfNitLoop> 1) bzr push doesn't require that bzr be installed on the remote location.
[16:31] <NfNitLoop> (which is nice)
[16:32] <NfNitLoop> 2) because of that, recontructing a working tree would require re-pushing things as plain files, uncompressed.
[16:32] <NfNitLoop> which would be slow.
[16:32] <NfNitLoop> so, it doesn't happen.
[16:32] <NfNitLoop> If you need to reconstruct a working tree, you should connect to the server and do a pull.
[16:33] <NfNitLoop> Or, if you don't mind 2 steps, you could push, then log in to the server and update.
[16:33] <yee> and there's nothing in bzrlib that can allow me to update the remote tree?
[16:34] <NfNitLoop> You know, I see that complaint so often, maybe an option to recontruct the working tree would be nice...
[16:34] <NfNitLoop> but I don't know that it exists yet.
[16:34] <NfNitLoop> yee: how are you pushing?  over ssh?
[16:35] <LarstiQ> NfNitLoop, yee: more importantly, updating the working tree involves dealing with conflicts
[16:35] <NfNitLoop> LarstiQ: aah, good point.
[16:35] <LarstiQ> yee: 1) are you sure you actually need the working tree 2) you can call plugin code via bzrlib too
[16:35] <yee> I'm creating a Branch object and use the push method
[16:35] <yee> it would be a fast forward
[16:36] <yee> but I can't login with ssh beacuse I need to set the password and this needs to be done by the webapp
[16:38] <LarstiQ> yee: ssh keys instead of passwords might be a good idea, but anyway
[16:38] <LarstiQ> yee: could you explain more of what the webapp does, why is it pushing a branch, what does it need to do?
[16:39] <LarstiQ> yee: say, why do you need both a bzr branch and a working tree present?
[16:40] <lucypher> Hi, I can't undestand how ingore works
[16:40] <yee> its like a frontend for the repository, the files get edited on the web, or by uploading them, and then the changes need to propagate to the production servers
[16:40] <NfNitLoop> lucypher: Which part are you having trouble with?
[16:40] <lucypher> I'm trying tpo ignore an entire folder
[16:40] <LarstiQ> yee: ah, I see.
[16:40] <lucypher> I did bzr ignore app/tmp
[16:41] <LarstiQ> yee: can you guarantee no local changes on the remote working tree?
[16:41] <yee> yes
[16:41] <LarstiQ> yee: good, that's the easy case :)
[16:41] <NfNitLoop> lucypher: had you already `bzr add`ed things in that directory?
[16:41] <lucypher> NfNitLoop : yes
[16:41] <LarstiQ> yee: I think I'd look at the bzr-upload code if I were you.
[16:42] <NfNitLoop> lucypher: that's your problem.   Ignore only ignores files that you haven't specifically versioned.
[16:42] <NfNitLoop> lucypher: anything you add manually will still be versioned.
[16:42] <LarstiQ> yee: combining that with the push on Branch you're already doing should cover your needs afaics
[16:42] <lucypher> how do i remove these files?
[16:42] <NfNitLoop> bzr remove --keep  path-to-dir
[16:42] <NfNitLoop> (assuming you want to keep the files, but just remove them from bzr)
[16:43] <yee> LarstiQ: ok, i would look into that
[16:43] <LarstiQ> yee: if you're feeling ambitious, rework it into bzr core as a --yes-i-know-no-local-changes or somesuch option to push
[16:44] <LarstiQ> mwhudson: I'm going offline for a bit again, if you didn't transiently need me, please contentfully ping again :)
[16:45] <Goundy> yope :)
[16:46] <Goundy> How to delete a branch forgot ^^
[16:46] <lucypher> NfNitLoop : thanks, so the next time I have to set ignores before the first bzr add .
[16:47] <NfNitLoop> lucypher: Yep. it's a good idea.
[16:47] <NfNitLoop> Just make sure to skim the changelog to your initial `bzr add .` and see if there's anything you didn't want to go in there. :)
[16:48] <NfNitLoop> then you can go "oops"  `bzr revert .`  `bzr ignore xyz`   `bzr add .`
[16:49] <NfNitLoop> Goundy: are you asking how to delete a branch?
[16:49] <Goundy> NfNitLoop indeed.. Sorry for the weird sentence !
[16:49] <NfNitLoop> Goundy: Just delete the directory that it's in. :)
[16:50] <Goundy> NfNitLoop oh? nice ^^ thank you
[16:50] <Goundy> NfNitLoop but wait I want it to disapear from my launchpad repo
[16:50] <NfNitLoop> OH.  Sorry.  I'm not sure about that.
[16:50] <Goundy> hmm
[16:51] <Goundy> NfNitLoop well the question is: How to delete a branch from a repository :-)
[16:51] <NfNitLoop> so if you have /repo/branchXYZ
[16:51] <NfNitLoop> you just rm -r /repo/branchXYZ
[16:52] <Goundy> NfNitLoop I don't have ssh access on launchpad ;)
[16:53] <NfNitLoop> ah, *on launchpad*.
[16:53] <Goundy> NfNitLoop bzr branch -delete
[16:53] <Goundy> :-)
[16:53] <Goundy> it doesn't work >_<
[16:53] <Goundy> wrong ingo
[16:53] <Goundy> info
[16:55] <santagada> Goundy: doesn't launchpad have some UI for this on the website?
[16:55] <Goundy> santagada it does was just asking how to do it through bazaar so I know for future use ;)
[16:57] <santagada> Goundy: you need to have access to the repo to do on the server side... that's why it uses an web ui on launchpad
[16:57] <Goundy> ah i get it
[16:57] <Goundy> thank you
[16:58] <santagada> Goundy: this is just speculation on my side... but I read the bazaar docs and it had nothing about removing it with a remote command
[16:58] <santagada> s/it/a branch
[16:59] <Goundy> santagada k :)
[17:53] <Odd_Bloke> Is BB down for anyone else?
[17:53] <LeoNerd> BB?
[17:54] <Odd_Bloke> BundleBuggy.
[18:14] <abentley> Odd_Bloke: Fixed.
[18:15] <abentley> jam: released.
[18:27] <santagada> I wash seeing the Linus Torvalds google talk about git and he talks about annotating and knowing the history of a function
[18:27] <santagada> like something that got moved from one file to another
[18:27] <santagada> is this possible with bzr?
[18:36] <BasicOSX> Did the bzrtools.dev repo move? I see Aaron's announcement about 1.12.0 but a 'bzr update' doesn't update and
[18:36] <BasicOSX> 'bzr plugins' shows 1.11.0
[18:36] <BasicOSX>  http://bazaar.launchpad.net/%7Eabentley/bzrtools/bzrtools.dev/
[18:55] <jbermudes> hello!
[18:56] <jbermudes> What does it mean when one tries to push and an error is returned "Cannot lock lockDir...Transport operation not possible. HTTP does not support mkdir()" ?
[18:59] <Lo-lan-do> jbermudes: You're trying to push to a branch through HTTP, which isn't possible as far as I know.
[18:59] <Lo-lan-do> HTTP branches are read-only.
[18:59] <jbermudes> so saying bzr push lp:blahblah uses HTTP?
[19:00] <jelmer> abentley, Where is the main bzrtools branch these days?
[19:00] <Jc2k> jbermudes: unless you tell it your launchpad login, then it uses bzr+ssh afaik
[19:00] <jelmer> hi Lo-lan-do
[19:01] <Lo-lan-do> jbermudes: Not sure about lp.  It may do the right thing if you are registered with Launchpad.
[19:01] <Lo-lan-do> Hi jelmer.  Did you recover? :-)
[19:01] <jbermudes> Lo-lan-do, so to be safe, I should just specify the full URL using sftp?
[19:01] <abentley> jelmer: http://bazaar.launchpad.net/%7Eabentley/bzrtools/bzrtools.dev/
[19:01] <jelmer> Lo-lan-do: Somewhat :-)
[19:01] <jelmer> Lo-lan-do, how was the rest of FOSDEM for you?
[19:02] <Lo-lan-do> jbermudes: I'm clueless about lp.  I suggest reading bzr help plugins/lp
[19:02] <jbermudes> Lo-lan-do, sorry! Thanks though for helping me get on the right track. :-)
[19:02] <Lo-lan-do> jelmer: It was my first time there, and I'm not sure I liked it.  Too many people for me, I think.
[19:02] <Lo-lan-do> Interesting talks, though.
[19:03] <Jc2k> Lo-lan-do: same for me. not really too many people, just that the halls were too congested
[19:03] <jelmer> Yeah, they should really find a bigger location :-/
[19:04] <Jc2k> its too short, i didnt even get to see the jhbuild/buildbot guys in gnome
[19:28] <wally> can bazaar be stored on a samba share?
[19:28] <Kobaz> i wouldn't see why not
[19:29] <Tak> I'm doing that
[19:29] <wally> i don't see why not either, need to know for sure though
[19:29] <wally> cool
[19:29] <wally> thanks.
[19:29] <Tak> in fact, I'm using a samba share as a bridge between a locked-down svn server and my local bzr branches
[19:34] <Lo-lan-do> jelmer: You told me you figured out how to fix the bzr-svn slowness, but that meant just understanding, right?
[19:34] <Lo-lan-do> (If not, I regret to have to mention it still happens with current r2529)
[19:37] <alefteris> I get the following with bzr status, any ideas?
[19:37] <alefteris> Conflict adding file sites/all/themes/zenubuntu/images/gr/ubuntu-gr-developers-1.png.  Moved existing file to sites/all/themes/zenubuntu/images/gr/ubuntu-gr-developers-1.png.moved.
[19:38] <alefteris> I have deleted the .moved file
[19:43] <fullermd> vila: date -r1234567890
[19:50] <alefteris> nevermind
[20:01] <lifeless> jam: so, http://paste.ubuntu.com/116333/ 2000 revs of bzr.dev, 1.9 and gc-plain
[20:01] <wally> is there any case where mercurial is better than bzr?
[20:02] <jam> 25MB => 9.4MB is pretty nice.
[20:02] <lifeless> wally: I don't think so :P
[20:02] <lifeless> wally: but I'm an author of bzr, so can't claim an unbiased opinion
[20:04] <Lo-lan-do> Isn't mercurial still mostly faster than bzr?
[20:04] <Lo-lan-do> Like for startup times?
[20:05] <lifeless> Lo-lan-do: yes, its starts up faster
[20:05] <lifeless> but hot cache bzr starts up in ~200ms
[20:05] <lifeless> and its a python issue so not trivial tojustfix
[20:06] <lifeless> and thats fast enough not to be an issue for most use cases
[20:06] <Lo-lan-do> Yeah, I understand it's hard to fix and mostly good enough for now.
[20:07] <Lo-lan-do> There's still one use case where it gets annoying: when you "grep -rl something . | xargs emacs" and Emacs runs bzr on each file.
[20:08] <Lo-lan-do> Presumably to check if it's up-to-date, I didn't check.
[20:08] <lifeless> argh
[20:08] <Lo-lan-do> When you have several files in the set, you can wait for a minute or two before being able to do anything in the editor.
[20:08] <lifeless> yes that will blow
[20:08] <lifeless> emacs should just 'bzr st'
[20:09] <lifeless> at least, if you have under 5K files its basically the same time as 'bzr st FILE'
[20:09] <lifeless> so if there are > 5K files, then do 'bzr st FILES'
[20:09] <Lo-lan-do> I'm not sure it's even aware of its own behaviour.  I believe the hook is called when opening a file.
[20:10] <Lo-lan-do> [pid 21600] execve("/usr/bin/bzr", ["/usr/bin/bzr", "status", "Makefile"], [/* 42 vars */]) = 0
[20:11] <Lo-lan-do> Argh.  It even runs bzr status *twice* on each file.
[20:12] <Lo-lan-do> http://pastebin.com/d7f9f6dca
[20:13]  * Lo-lan-do reports that as a bug
[20:25] <jam> lifeless: I just submitted http://bzr.arbash-meinel.com/branches/bzr/jam-integration which clearly has tags
[20:25] <jam> and the merge was accepted
[20:25] <jam> but there are still no tags in "http://bazaar-vcs.org/bzr/bzr.dev"
[20:26] <lifeless> possibly an old branch format instance lurking somewhere I guess
[20:26] <lifeless> though I am pretty sure trunk is all upgraded
[20:27] <mwhudson> good morning
[20:27] <jam> The http branch itself in 1.9 as expected
[20:27] <jam> So it only leaves the "hidden" pqm branch
[20:27] <jam> morning mwhudson
[20:31] <lifeless> jam: $ bzr info
[20:31] <lifeless> Repository branch (format: 1.12-preview or 1.9)
[20:35] <jam> lifeless: can you do "bzr tags" on that branch, just to see if they are getting that far, and just not propagating out?
[20:37] <lifeless> jam: it does not have the tags
[20:44] <bialix> fullermd: what is topic of the day?
[20:45] <fullermd> Furbys: Are they really out for your blood, or is it just a clever disguise?
[20:46]  * jelmer tries to remember what Furbys were
[20:47] <Lo-lan-do> Animated plush toys.
[20:48] <fullermd> Evil.  They're pure distilled evil.
[20:50] <wally> trying to do bzr init on a samba share:  bzr: ERROR: Transport error: [Errno 95] Operation not supported: '/home/ryan/.gvfs/goldfields on redbull.rec.ri.cmu.edu/Software/bzrtest/.bzr' [Errno 95] Operation not supported: '/home/ryan/.gvfs/goldfields on redbull.rec.ri.cmu.edu/Software/bzrtest/.bzr'
[20:54] <Tak> do you have it mounted, or are you using a smb:// url?
[20:54] <wally> i am using smb:// url
[20:55] <Tak> ah - I'm using a mounted share
[21:00] <wally> it works with mounted share
[21:00] <wally> but that only runs as root right now, tr ying to fix.
[21:00] <wally> any quick fixes?
[21:06] <Tak> I don't know of any; others may
[21:08] <jelmer> jam, subvertpy will also need to be included in the windows installer
[21:09] <lifeless> wally: hmm, I wonder what operation is failing; possibly oslock()
[21:09] <jam> jelmer: it isn't installed as part of "setup.py install" for bzr-svn?
[21:09] <jelmer> jam, no, it's a separate package
[21:09] <wally> i think so lifeless
[21:10] <jam> jelmer: any chance you could send a diff of 'build_release.py' to build it?
[21:11] <jam> is it an entirely separate package?
[21:11] <jam> (as in I need to 'bzr branch' from launchpad?)
[21:12] <jelmer> jam: yeah, I should be able to (though I don't have Windows around here atm)
[21:12] <jelmer> jam, yeah, it's completely separate
[21:14] <wally> fixed by using CIFS in usermode via /etc/fstab
[21:16] <jelmer> jam, what do we do to install paramiko atm?
[21:16] <jam> just have it on the machine
[21:17] <jam> py2exe picks it up
[21:17] <jelmer> jam, so it doesn't come with the bzr installer?
[21:17] <jam> it should
[21:17] <mwhudson> beuno: hey, review this http://pastebin.ubuntu.com/116598/
[21:18] <jam> I'm saying we don't do anything specially to package it
[21:18] <jam> having it installed in the machine that is building the installer is enough
[21:18] <beuno> mwhudson, looking
[21:18] <jelmer> jam, Ah¸ ok
[21:18] <jelmer> jam, I would expect it to work similarly for subvertpy
[21:19] <jam> well, we have to specially handle the other plugins
[21:19] <jam> and 'bzrlib' never imports subvertpy
[21:19] <jam> like paramiko
[21:19] <kfogel> mwhudson: just some context: sylvain beucler is (somewhat) essential to the emacs->bzr switchover.  Not that you have to treat him with kid gloves, but just be aware that we (well, I) will be having repeated interactions with him for some time :-).
[21:20] <beuno> mwhudson, looks good. Want to add in the simpletal version as well in?
[21:20] <mwhudson> kfogel: i've gathered
[21:20] <mwhudson> beuno: i guess that makes sense
[21:21] <lifeless> jam: is 4 seconds per hundred about right for knit->chk conversion of bzr.dev?
[21:21] <jelmer> kfogel, congrats on getting your first bzr patch in btw :-)
[21:21] <lifeless> now, how about bzr svn-serve?
[21:21] <kfogel> jelmer: thanks!  (Did that happen?  I haven't opened up that folder yet today.)
[21:21] <jelmer> jam, ah..
[21:21] <jam> lifeless: I've never done the conversion outside of my "hacks" branch, which cheats to be a lot faster
[21:22] <lifeless> jam: kk
[21:22] <lifeless> $ time ~/source/baz/repository/bzr branch ../bzr.dev chk-gc/t -r 2000
[21:22] <lifeless> bzr: ERROR: Unknown record type: '\x89'
[21:22] <lifeless> hmmm
[21:22] <jelmer> kfogel: yep, Ian merged it
[21:22] <lifeless> back shortly
[21:23] <kfogel> jelmer: Yay!  I wish it were a more important bug, but at least it was one I could do something about :-).
[21:28] <lifeless> jam: ah, pack() is broken in gc
[21:28] <mwhudson> beuno: i don't think there's been a simpletal release in three years
[21:29] <keithy> hi I just upgraded from 1.3 to 1.11 on windows box and something isnt happy
[21:29] <mwhudson> and it doesn't seem to be installed in such a way that pkg_resources can find it
[21:29] <keithy> is there a self test
[21:29] <mwhudson> keithy: bzr selftest
[21:30] <wally> awesome, thanks for the help
[21:30] <wally> got everything working
[21:30] <beuno> mwhudson, fair enough. And we haven't gotten any bugs about it either.
[21:31] <mwhudson> right
[21:32] <mwhudson> kfogel: does beuc IRC?
[21:34] <lifeless> jam: ping
[21:35] <kfogel> mwhudson: he seems to say not
[21:35] <kfogel> in an email he posted to emacs-devel, he sai:
[21:35] <kfogel> said:
[21:35] <kfogel> It's not the first time savannah-hackers is carbon-copied in the
[21:35] <kfogel> middle of a conversation. If you have a request, follow
[21:35] <kfogel> http://savannah.gnu.org/contact.php and explain things clearly.
[21:35] <kfogel> For reference, the IRC channel is not a support channel but an admin
[21:35] <kfogel> coordination channel, and #savannah-hackers isn't the right name.
[21:35] <jam> lifeless: pong
[21:36] <lifeless> jam: I'm just pushing to my bzr-groupcompress preliminary support for chk-gc
[21:36] <mwhudson> kfogel: ok, thanks
[21:36] <lifeless> jam: but there are two problems; something in bzr.dev broke pack()
[21:36] <lifeless> jam: so it can't fetch more than 10 batches
[21:36] <lifeless> jam: and for some reason, it is ending up with a xml inventory in the store
[21:37] <jam> weird
[21:37] <jam> is this in your gc plugin?
[21:37] <lifeless> yes
[21:37] <lifeless> revno 25
[21:38] <lifeless> $ ~/source/baz/repository/bzr repository-details chk-gc/
[21:38] <lifeless> bzr: ERROR: exceptions.ValueError: not a serialised CHKInventory: '<inventory format="5" rev
[21:38] <lifeless> I also taught repository-details how to handle gc VFs objects correctly
[21:38] <lifeless> fetching -r800 into --gc-plain-chk worked
[21:39] <lifeless> of bzr.dev
[21:39] <lifeless> by 'worked' I mean, I got a tree :)
[21:39] <lifeless> and I can run log -v
[21:42] <mwhudson> beuno: ok to merge that then?
[21:42] <beuno> mwhudson, yeap
[21:42] <mwhudson> ta
[21:43] <lifeless> jam: found the issue I think
[21:45] <jam> ??
[21:46] <lifeless> the monkey patch to compatible
[21:46] <lifeless> I hope :P
[21:46] <lifeless> probably several things in fact
[21:46] <jam> InterPackRepo.is_compatible = staticmethod(pack_incompatible)
[21:46] <jam> that one?
[21:47] <igc> morning
[21:47] <jam> you need to include a "chk_support" in that code
[21:48] <jam> at least looking at it, RepositoryFormatPackGCPlainCHK is defined but not part of the "incompatible" check
[21:48] <lifeless> yes, also I need to cubclass CHKInventoryRepository
[21:48] <jam> morning igc
[21:48] <jelmer> am I right to think that upgrades to brisbane-core will require rewriting of the revision XML as well, since the inventory sha changes?
[21:48] <jelmer> If so, any chance we can fix the XML escaping too?
[21:48] <jam> jelmer: probably, though that is pretty cheap versus rewriting the inventory
[21:48] <jam> jelmer: what escaping?
[21:49] <jelmer> jam, right now some characters are escaped at commit-time because they can't be used in XML
[21:49] <jelmer> jam, except the escape character is not escaped
[21:49] <jelmer> which makes it impossible to do proper unescaping
[21:50] <jelmer> and which requires plugins like bzr-svn to do escaping of XML-invalid characters in their commit messages during pull
[21:50] <lifeless> jelmer: Its not part of the focus for brisbane core
[21:50] <lifeless> jelmer: patches appreciated :P
[21:51] <igc> hi jam
[21:52] <jelmer> lifeless, I wish I got a dollar for every time you said that :-P
[21:53] <lifeless> jelmer: I wish I got patch for every time I say it !
[21:53] <lifeless> jelmer: btw have you had a look at why your text reconstruction is slow?
[21:54] <jelmer> lifeless, me being dulwich?
[21:55] <jelmer> I'm quite sure why it is so slow, just haven't gotten round to fixing it yet. We need to LRU cache delta bases as well as not do as much string copies during delta apply
[21:57] <jam> jelmer: would bzr-svn 0.4.17 still work with 1.12?
[21:57] <jam> As near as I can tell, getting subvertpy bundled is going to be non-trivial
[21:58] <jelmer> jam, it's not just a matter of running install similarly to what we do for modules?
[21:59] <jam> jelmer: best I can say is "maybe"
[21:59] <poolie> hello all
[21:59] <jam> getting it built into the package
[21:59] <jam> seems like it requires a different path
[21:59] <jam> hi poolie
[21:59] <jam> more like updating "setup.py" to know it needs to be included
[21:59] <jam> jelmer: subvertpy doesn't sit in bzrlib/plugins, right?
[22:00] <jelmer> jam, no, in the python path
[22:00] <jelmer> jam, what about qbzr's dependencies?
[22:00] <jam> jelmer: pyqt et all are custom handled in setup.pfy
[22:00] <jam> setup.py
[22:01] <keithy> I installed bazaar 1.11 on tiger using pacports is that a tested combo
[22:01] <keithy> macports*
[22:01] <jelmer> jam: theirs or ours?
[22:01] <keithy> its not working properly
[22:01] <jam> jelmer: bzr's setup.py has code to bring in the PyQT libs if we are running py2exe, IIRC
[22:01] <lifeless> jeyes
[22:01] <lifeless> jelmer: yes
[22:02] <keithy> ah, sftp works, but bzr+ssh doesnt!
[22:03] <bob2> keithy: ssh remotehost bzr rocks
[22:03] <lifeless> jam: pushing a better groupcompress
[22:05] <jam> lifeless: I don't think you wanted this:
[22:05] <jam> +    if chk_support:
[22:05] <jam> +        formats = formats = (RepositoryFormatPackGCPlain,)
[22:05] <jam> pretty sure you wanted "+"
[22:07] <keithy> bob2 I dont understand
[22:07] <lifeless> jam: yeah
[22:08] <keithy> ok, bzr log sftp://name@host/dir/branch works
[22:08] <keithy> ok, bzr update sftp://name@host/dir/branch doesnt
[22:08] <bob2> keithy: run that command
[22:09] <bob2> keithy: a common reason for bzr+ssh not working is bzr not being in PATH on the remote side
[22:09] <keithy> ah that might be it
[22:09] <eleftherios> what's the best way to setup a secure bazaar repository on my server without giving an ssh account to contributors?
[22:10] <jelmer> jam, I would think this should take care of it: http://samba.org/~jelmer/tmp/setup.py-svn.diff
[22:13] <jam> jelmer: for subvertpy-0.6.1, for some reason it is trying to copy "libapr.dll" into bzrlib\plugins\svn
[22:13] <jam> shouldn't 'py setup.py install' for subvertpy not know anything about bzrlib and bzr-svn?
[22:14] <jelmer> jam, yeah, that's a bug - it was fixed in r2014
[22:14] <keithy> ok "It sure Does!"
[22:14] <jam> jelmer: so... can't use a tag for subvertpy?
[22:14] <jelmer> jam, you can, if you give me a second to release :-)
[22:16] <jelmer> jam, try subvertpy-0.6.2
[22:16] <keithy> ok now I am getting error not a branch
[22:18] <jam> jelmer: what revno?
[22:18] <jelmer> jam, 2021
[22:19] <jam> just waiting for things to propagate
[22:19] <jelmer> (tag:subvertpy-0.6.2)
[22:19] <keithy> checkout lightweight seems to work
[22:19] <jam> sure, http://bazaar. only has 2020
[22:23] <jelmer> it would be nice if launchpad had a "Mirror now" button for bazaar branches, just like it has for foreign imports
[22:23] <mwhudson> yes it would
[22:23] <keithy> so I am getting "not a branch errors when it is a branch
[22:23]  * jelmer fears the day Launchpad becomes Open Source
[22:23] <mwhudson> you can do it through the api
[22:24] <poolie> jelmer, why?
[22:24] <mwhudson> jelmer: because we'll just say "patches welcome" to everything?
[22:24] <jelmer> mwhudson, yes, it would make it harder to complain about stuff
[22:24] <poolie> hopefully when it's released we'll get patches merged and running quickly
[22:24] <poolie> if they languish it will suck
[22:25] <beuno> sssssh, don't rat us out  ;)
[22:25] <keithy> I'll try a fresh check out
[22:25] <poolie> beuno: i heard you're not coming to brisbane after all?
[22:25] <keithy> is editing the location file a bad idea?
[22:25] <beuno> poolie, no  :(  I suck
[22:26] <beuno> poolie, you know how priorities are handled sometimes, especially considering the location of the other one....
[22:26] <jelmer> poolie, yeah, I'd be curious to see how that works out. There don't seem to be a lot of other centralized projects FOSS projects
[22:28]  * beuno -> home
[22:28] <beuno> bbiab
[22:31] <jam> jelmer: are you sure 2021 is uploaded? I still haven't seen it yet on http://
[22:32] <jelmer> jam, It's a mirrorred branch
[22:32] <jelmer> jam, the original is on http://people.samba.org/bzr/jelmer/subvertpy/trunk
[22:32] <jam> ah, so that is hours to trigger ...
[22:32] <jelmer> this is why it would be nice to have a "Mirror now"  branch on LP like there is for vcs-imports
[22:34] <lifeless> jam: can you think of any reason pack() shouldn't use get_record_stream now ?
[22:35] <jam> lifeless: rather than Packer?
[22:36] <lifeless> in packer
[22:36] <lifeless> gc packis broken
[22:36] <lifeless> because it reimplements get_record_stream basically
[22:38] <lifeless> http://paste.ubuntu.com/116614/
[22:39] <lifeless> jam: ^ some stats
[22:40] <lifeless> spiv: so, how are we getting together
[22:41] <spiv> lifeless: the weather is cool... feel like a change of scene, i.e. Hornsby?
[22:41] <lifeless> sure, I can pop up
[22:41] <jam> lifeless: kind of a shame to have copying 1/2 the data take 10x longer...
[22:42] <spiv> lifeless: ok.  See you soonish.
[22:42] <lifeless> jam: indeed; and its going to be in your hands shortly
[22:43] <lifeless> spiv: probably get the 10:30, be rushing for the 10 sharp
[22:43] <spiv> lifeless: ok
[22:43] <lifeless> jam: thats the conversion though, its 17 seconds to copy native chk-gc
[22:43] <lifeless> jam: but the chk nodes aren't compressing at all well
[22:44] <lifeless> jam: haven't looked into why yet; I suspect its 'many record streams' or some such
[22:45] <jam> jelmer: I just confirmed... just adding "subvertpy" as another "setup.py install --install-lib=XXX" doesn't work
[22:45] <jam> because it installs it *next* to bzrlib
[22:45] <jam> and so it isn't auto-detected by the rest of the code
[22:45] <jam> (I didn't actually install anything, but it isn't in the directory where I expected to find it)
[22:46] <jam> lifeless: well, if you are using original format, they are still "one long line" format
[22:46] <jam> so if the leaf nodes are only an entry or two, there isn't much to compress
[22:46] <jam> when one changes
[22:46] <jelmer> jam, did you see the patch I put up for setup.py ?
[22:47] <jelmer> that tries to include it in a similar way to qbzr's dependencies
[22:47] <jam> jelmer: I have not seen one
[22:47] <jelmer> http://samba.org/~jelmer/tmp/setup.py-subvertpy.diff IIRC
[22:47] <jelmer> sorry, http://samba.org/~jelmer/tmp/setup.py-svn.diff
[22:47] <jam> I have a bundle-buggy post, but no recent mails from you
[22:48] <jelmer> I only mentioned it here on the channel about half an hour ago or so
[22:48] <lifeless> jam: thats part of it; also I think there are too many record streams, which drives the group count up
[22:49] <jam> lifeless: you mean a separate stream for "inventory" versus "chk" or that chk itself has lots of streams because of the layering?
[22:49] <jam> I assume the latter
[22:49] <jam> note, hash prefixes does help here
[22:49] <jam> though I'm not sure why it would *have* to start a new GC group
[22:49] <lifeless> the latter
[22:49] <lifeless> each call to insert_record_stream starts a group at the moment
[22:49] <jam> gotcha
[22:49] <lifeless> simplest, to fit with other assumptions
[22:49] <lifeless> 804
[22:50] <lifeless> record streams
[22:50] <lifeless> so 804 groups at minimum
[22:50] <jam> lifeless: couldn't you tie it to commit_write_group()?
[22:50] <jam> 804 seems severe
[22:50] <jam> I would have thought 18 or so
[22:50] <jam> that at least sounds like 1 per chk
[22:50] <jam> rather than 1 per level
[22:50] <lifeless> for record in inv_stream:
[22:51] <lifeless> ...
[22:51] <lifeless>     to.insert_record_stream(...)
[22:51] <lifeless> its one per inventory
[22:51] <lifeless> this is fixable at least :P
[22:51] <jam> well, one per inv * one per level
[22:51] <jam> I would guess
[22:52] <lifeless> no
[22:52] <lifeless> its one per inv + 1 for revs, sigs, texts, chk_nodes
[22:52] <lifeless> 804
[22:54] <lifeless> fixed, pushing to bbc
[22:54] <eleftherios> is there a tutorial about putting a repository on a server and pushing/pulling over HTTPS or SSH even?
[22:58] <lifeless> jam: I've pushed to brisbane core
[22:58] <jam> lifeless: yeah, I saw it
[22:58] <lifeless> eleftherios: its in the docs
[22:59] <jam> I'll just mention that I don't think the final inventory bits will compress well
[22:59] <lifeless> jam: so if you grab bbc, bzr-gc, bzr-repodetails
[22:59] <jam> as it is mostly revision ids
[22:59] <jam> and sha hashes
[22:59] <lifeless> jam: yeah
[22:59] <lifeless> it makes little difference
[22:59] <lifeless> but you've got toys for playing with this
[22:59] <lifeless> I've just been gluing bits together
[23:00] <jam> yeah, I've gotten all your updates (for now :)
[23:00] <spiv> Who builds the Mac OS X installer?  There's a bug about it: https://bugs.edge.launchpad.net/bzr/+bug/327487
[23:00] <jam> interestingly, if you rename "groupcompress" "groupcompress-trunk" then Pyrex breaks
[23:00] <jam> because it tries to create variables with "-" in them
[23:00] <lifeless> jam: fun
[23:01] <jam> jelmer: your patch looks like it might work, I'll try to play around with it tomorrow
[23:01] <lifeless> jam: so I'll see about 'i' doing byte ranges
[23:01] <lifeless> jam: on the way to spivs
[23:01] <jam> lifeless: sounds good
[23:01] <lifeless> jam: then at least the format can handle trying byte-sequence matching
[23:02] <jam> I also think changing the serialized chk pages to allow '\n' in them may still be the fastest win for better compression
[23:02] <jelmer> jam, cool
[23:02] <jam> but that is stuff to play with
[23:02] <lifeless> jam: well you have the code to do that :P
[23:02] <lifeless> jam: so you could try it now if you like :)
[23:03] <jam> anyway, I've got to go pick up my son. Have a good night everyone
[23:03] <lifeless> good night
[23:12] <lifeless> jam: if you read this before your next morning: where is your \n line breaking branch
[23:20] <lifeless> vila: bug 327487 is an installer bug in bzr
[23:21] <vila> lifeless: I don't think so, I encounter it on OSX when running selftest for example because I don't have qt there
[23:21] <lifeless> vila: use case 'install bzr via the installer, and it works'
[23:21] <vila> and I seem to remember that I tracked it one day to the point where an exception is violently raised
[23:21] <lifeless> vila: -> installer bug
[23:21] <lifeless> the installer should include or depend on qt if we're bundling qbzr in that installer
[23:22] <vila> right
[23:22] <lifeless> seperately, qbzr probably needs to be better, yes. But *that bug* is about the installer, please put it back :)
[23:22] <vila> but qbzr shouldn't abort like that either
[23:22] <lifeless> vila: thats true, but that is a seperate bug
[23:22] <lifeless> even if qbzr was better the use case won't be fixed without fixing the installer
[23:23] <vila> lifeless: I see your point
[23:24] <lifeless> cool ;)
[23:24] <lifeless> hmm, I need to hammer on evo's sync code more
[23:24] <lifeless> but its not low hanging anymore
[23:26] <Odd_Bloke> abentley: Thanks. :)
[23:26] <jml> what's the recommended way to make bzr and emacs play together these days?
[23:26] <lifeless> hammer n tongs?
[23:28] <bob2> vc-bzr in emacs cvs matches whatever is on lp, and seems to work well
[23:28] <bob2> for what it does
[23:28] <igc> hi vila
[23:28] <vila> hi Ian !
[23:29] <igc> can't sleep? :-)
[23:29] <vila> hehe, I was passing around *before* going to sleep, bad idea ;)
[23:29] <jml> bob2: thanks.
[23:30] <jml> istr the last time I tried a vc mode, it had problems with breaking hardlinks
[23:37] <thumper> jml: I think it still does
[23:37] <thumper> jml: check with kfogel
[23:37] <thumper> jml: it works fine as long as you don't use hardlinks
[23:39] <lifeless> ok, 30 minutes to sync mail== bad
[23:39] <lifeless> -> train
[23:46] <kfogel> jml: I gave up on VC mode in Emacs long ago, I just run cvs/svn/bzr on the command-line in a shell-mode buffer now.
[23:46] <jml> :\
[23:46] <jml> I used to find having a keybinding for 'bzr diff' quite useful
[23:47] <jml> (and thence to 'commit')
[23:50] <vila> kfogel: ever tried dvc ?
[23:51] <vila> kfogel: or M-x shell-command-on-region RET bzr diff -rsubmit: ?
[23:52] <vila> kfogel: diff-mode the resulting buffer and you got some interesting C-c C-c or C-c C-a ....
[23:55]  * jml really needs to publish branch-todo