[00:11] <Ng> is it possible to copy a file from one place in a branch to another and retain its history? not move, copy
[00:32] <james_w> Ng: not currently
[00:32] <Ng> james_w: ok, ta
[00:32] <james_w> Ng: history of a file means tracking a file id across versions
[00:33] <james_w> duplicate file id in a singled revision => ARRGHH!
[00:33]  * Ng nods
[00:33] <james_w> there are some suggestions for how to extend the model to allow splitting and joining file ids though
[00:33] <james_w> so maybe one day
[01:50] <fbond> Hm, bzr branch --no-tree would be useful.
[01:51] <fbond> Am I missing something obvious?
[01:54] <mwhudson> it would be useful
[01:58] <spiv> fbond, mwhudson: that's probably why it exists in bzr.dev...
[02:00] <mwhudson> spiv: hooray time machines
[02:01]  * spiv -> food
[02:05] <fbond> spiv: Ah, neat.
[02:10] <lifeless> igc: ping
[02:10] <lifeless> poolie: you're dreaming, but I want to write one
[02:15] <igc> hi lifeless
[02:17] <lifeless> igc: I have 356 seconds of internet left
[02:20] <igc> lifeless: fyi, I went digging into what log -v was doing yesterday afternoon
[02:20] <igc> the chk_map.iter_changes() code was loading some nodes twice - about 20% in my test
[02:21] <lifeless> igc: 180sec left :P we may need a phone call or something. I'maround until 1345 sydney time
[02:21] <igc> I put a simpe cache in to stop that but it made next to no difference in overall time
[02:21] <lifeless> igc: ok
[02:21] <lifeless> igc: I think a useful thing to do would be to calculate/report in a brute force way the actual common/left-only/right-only node for two trees
[02:21] <lifeless> igc: we could use that to say 'we should be doing X work'
[02:22] <lifeless> igc: and it would also be useful to jam in evaluating the flavours
[02:22] <lifeless> I don't think he's got such a tool yet [I may be wrong]. repositorydetails would be a good place to put it
[02:22] <igc> ok, I'll download repodetails and see what's it doing now
[02:23] <igc> I'm still digesting chk_map's code fwiw
[02:49] <poolie> lifeless: do you still want your .../rob directory on orcadas?
[02:49] <poolie> i'm going to tar it up
[02:49] <poolie> that machine's almost out of disk
=== UdontKnow is now known as \0
[03:09] <igc> poolie: lifeless is offline for 2 hours - flying
[03:09]  * igc lunch
=== \0 is now known as UdontKnow
[03:18] <thumper> spiv: is http://bazaar-vcs.org/SmartPushAnalysis1.13 up to date?
[03:23] <spiv> thumper: no, the current numbers are a bit better
[03:24] <spiv> lifeless and I have been improving things too rapidly to make keeping the page up to date worthwhile :)
[03:28] <poolie> igc, thanks, np
[03:43] <bignose> jelmer: upgraded ‘bzr-loom’ on Debian squeeze
[03:44] <bignose> now I get: Unable to load plugin 'loom' from '/usr/lib/python2.5/site-packages/bzrlib/plugins'
[03:44] <bignose> the plugin is still there (a ‘/usr/lib/python2.5/site-packages/bzrlib/plugins/loom/’ directory with Python modules)
[03:45] <mwhudson> bignose: if you run bzr -Derror rocks you should get a better error message
[03:47] <bignose> $ bzr -Derror rocks
[03:47] <bignose> Unable to load plugin 'loom' from '/usr/lib/python2.5/site-packages/bzrlib/plugins'
[03:47] <bignose> It sure does!
[03:48] <mwhudson> bignose: what version of bzr?
[03:49] <bignose> $ bzr --version
[03:49] <bignose> Bazaar (bzr) 1.5
[03:50] <bignose> all as per Debian ‘squeeze’
[03:55] <mwhudson> oh, that's fairly old
[03:55] <mwhudson> ~/.bzr.log might have something about loom's failure to load
[03:56] <bignose> nevertheless, both it and ‘bzr-loom’ are as in Debian ‘squeeze’, with no dependency issues.
[03:56] <mwhudson> hm
[03:57] <bignose> yes, the log does have something
[03:57] <bignose> warning: paste bomb
[03:57] <bignose> [19317] 2009-03-04 14:53:47.719 WARNING: Unable to load plugin 'loom' from '/usr/lib/python2.5/site-packages/bzrlib/plugins'
[03:57] <bignose> 0.239  Traceback (most recent call last):
[03:57] <bignose>   File "/usr/lib/python2.5/site-packages/bzrlib/plugin.py", line 208, in load_from_dir
[03:57] <bignose>     exec "import bzrlib.plugins.%s" % name in {}
[03:57] <bignose>   File "<string>", line 1, in <module>
[03:57] <bignose>   File "/usr/lib/python2.5/site-packages/bzrlib/plugins/loom/__init__.py", line 61, in <module>
[03:57] <bignose>     import branch
[03:57] <bignose>   File "/usr/lib/python2.5/site-packages/bzrlib/plugins/loom/branch.py", line 767, in <module>
[03:57] <bignose>     class LoomBranch7(LoomSupport, bzrlib.branch.BzrBranch7):
[03:57] <bignose> AttributeError: 'module' object has no attribute 'BzrBranch7'
[03:58] <mwhudson> yeah, the bzr is too old for the bzr-loom
[03:58] <bignose> am I right in thinking that means this version of ‘bzr-loom’ should depend on a newer version of ‘bzr’?
[03:58] <mwhudson> sounds like a packaging bug
[03:58] <bignose> okay. I'll file a Debian bug for this.
[03:58] <mwhudson> good idea :)
[03:58] <mwhudson> bzr 1.6 will make that error at least go away
[03:59] <bignose> mwhudson: thanks for the troubleshooting
[03:59] <mwhudson> np
[05:14] <bob2> isn't pycurl still optional?
[05:15] <bob2> (for accessing http:// urls)
[05:15] <bignose> accessing them fails entirely for me, unless I install it.
[05:16] <bignose> bob2: I presume we're talking about Debian bug#518098 ?
[05:16] <bob2> bignose: yeah
[06:31] <poolie> vila: are you up? see  ^^ about pycurl
[06:33] <vila> poolie: not yet but soon :)
[06:36] <vila> bob2: pycurl is optional but is/was the default for http and is still the default for https, what bzr version/os are you using ?
[06:38] <bob2> vila: bigtone was having problems on debian with http with bzr 1.5
[06:39] <vila> hmm, debian bug#518098 seems to refer to bzr-1.5
[06:39] <bob2> yeah
[06:39] <vila> :-) I'm pretty sure many (or at least several :)  bugs have been fixed in that area
[06:40] <vila> bob2: do you have an url to access that bug, google only gives mailing lists hits
[06:40] <vila> bignose == ben finney ?
[06:40] <bob2> bugs.debian.org/518098, yes
[06:42] <vila> He's right about the recommends (at least today, don't clearly remember for 1.5) also, one should not take DependencyNotPresent regarding pycurl too seriously since we may as well not show it, the other http implementation being selected in that case anyway
[06:43] <vila> bob2: thanks for the url
[06:43] <bob2> so it has nothing to do with pycurl, and something else is going on?
[06:45] <vila> bob2: ok, so after reading the bug report, I think ben is wrong about pycurl being mandatory, I may need to check what has changed since 1.5 but I don't have cases where pycurl works and urllib doesn't (except for https certificate verification, but that doesn't apply here)
[06:46] <vila> bob2: I may also need the relevant pycurl version too...
[06:46] <bob2> vila: the version of pycurl he doesn't have installed? ;p
[06:47] <vila> bob2: oh well, in the end, if it works with pycurl and until bzr is upgraded to a more recent version, the simplest is certainly to just install pycurl
[06:47] <vila> bob2: :-)
[06:48] <vila> bob2: Sorry, I'm not yet fully awake, so, one last try at explaining it clearly:
[06:49] <vila> bob2: there are two http client implementations for bzr: one is pycurl based the other is urllib2 based
[06:50] <vila> bob2: they are roughly equivalent these days except for the https certificate verification that only pycurl implements
[06:50] <vila> bob2: no https involved here, so it should be a bug in urllib that has been fixed *after* bzr-1.5
[06:51] <vila> bob2:  installing pycurl (which makes it the default http client used) fixes the problem
[06:51] <vila> bob2: ergo, for bzr-.15, install and use pycurl is the way to go
[06:51] <vila> bob2: ergo, for bzr-1.5, install and use pycurl is the way to go
[07:07] <poolie> good night all
[08:04]  * igc dinner
=== montywi|zzz is now known as montywi
[10:18] <vila> bob2, bignose: sorry for the delay, but I'm pretty sure debian bug #518098 has been fixed as bug #230223 on lp (fix released in 1.6)
[10:18] <ubottu> Debian bug 518098 in bzr-loom "bzr-loom: can't use Bazaar =?utf-8?Q?with_?=" [Normal,Open] http://bugs.debian.org/518098
[10:18] <ubottu> Launchpad bug 230223 in bzr "smart server probing in 1.4 breaks check outs of short bus http repositories [regression]" [High,Fix released] https://launchpad.net/bugs/230223
[10:18] <vila> sorry, ubottu, that was a debian bug I was talking about, not a bzr-loom one at all :)
[10:30] <Kamping_Kaiser> hehe.
[10:43] <ROza27> hi
[10:45] <james_w> vila: it has, but that package is just in experimental currently
[10:47] <ROza27> has anyone used trac with bazaar?
[11:01] <vila> james_w: ? You mean bzr is packaged in experimental with a more recent version ? Which one ?
[11:02] <james_w>        bzr |    1.5-1.1 |      unstable | source, alpha, amd64, arm, armel, hppa, hurd-i386, i386, ia64, mips, mipsel, powerpc, s390, sparc
[11:02] <james_w>        bzr |     1.12-1 |  experimental | source, alpha, amd64, armel, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc
[11:02] <vila> james_w: ok, great
[11:03] <james_w> it can get moved to unstable now, I just don't have the poert
[11:03] <james_w> power
=== montywi is now known as montywi|meeting
[11:53] <james_w> rockstar: awesome news, thanks
=== Kamping_Kaiser is now known as VK5FOSS
=== VK5FOSS is now known as Kamping_Kaiser
[14:34] <vila> good morning jam
[14:55] <jam> morning vila, sorry about the delayed response :)
[14:56] <vila> :-)
=== verterok is now known as verterok|lunch
=== cprov is now known as cprov-lunch
=== verterok|lunch is now known as verterok
[17:09] <bac> hi.  i'm trying to help someone who needs to break a lock on a repo on LP.  do i remember correctly that using sftp instead of bzr+ssh is helpful in breaking stubborn locks?
[17:09] <beuno> bac, stubborn in what way?
[17:10] <bac> beuno: in the way that it won't break...
[17:10] <beuno> bac, error message?
[17:10] <bac> nope
[17:10] <bac> https://answers.edge.launchpad.net/launchpad/+question/62700
[17:11]  * beuno looks
[17:12] <bac> beuno: shouldn't you be sprinting or something?
[17:12] <beuno> bac, shhhhhhhh
[17:13] <beuno> bac, I'd suggest deleting the branch and pushing again
[17:13] <beuno> considering it's empty
[17:15] <bac> ah, ok.  i just seem to recall when i was in asia trying to push to devpad i used to get a bunch of held locks and spiv suggested breaking the lock using sftp.  i could be on crack, though.
[17:15] <beuno> yeah, although I think it's different in LP
[17:16] <bac> beuno:  in rockstar's suggestion he mentions ":push" -- what exactly is that?
[17:17] <beuno> bac, that's the push location
[17:18] <bac> beuno:  so can you use :pull and :parent, etc anywhere a location is needed?
[17:18] <beuno> bac, yeap
[17:18] <bac> is that documented anywhere?
[17:19] <beuno> I expect that 'bzr help revisionspec' would
[17:19]  * bac notes "bzr revno :parent" doesn't work as expected
[17:19] <bac> nope, they aren't really revisionspecs
[17:20] <beuno> well, you know parents...
[17:21] <LarstiQ> they're not revisionspecs
[17:22] <RainCT> Hi
[17:22] <LarstiQ> bac: hmm, I can't find it in the bzr topics atm
[17:22] <LarstiQ> bac: but yes, :submit etc is very useful
[17:22] <bac> LarstiQ: no, me neither.  i'm looking in directory_service.py.
[17:23] <bac> they really are handy and should be documented somewhere
[17:23] <RainCT> bzr isn't working here on Jaunty.. It says that I need dulwich, but there is no "python-dulwich" package nor anything like that
[17:23] <RainCT> ah wait, seems like it's a plugin that gives the error, nevermind
[17:24] <LarstiQ> RainCT: dulwich would be bzr-git
[17:24] <LarstiQ> (requiring it)
[17:25] <LarstiQ> bac: oh, I didn't know about :this
[17:25] <RainCT> LarstiQ: right, just figured that out.. I'm too fast to complain :)
=== cprov-lunch is now known as cprov
[18:34] <phinze> is there any way to get bzr to spit out the location of its parent branch?
[18:34] <phinze> looking for shorthand way of doing bzr up $PARENT_BRANCH; bzr merge $PARENT_BRANCH .
[18:35] <phinze> where "its" is "the current branch's"
[18:36] <james_w> ":parent"
[18:36] <phinze> james_w: perfect, thanks
[18:37] <phinze> where would i have found that in bzr help?
[18:37] <phinze> (just curious)
[18:37] <james_w> nowhere :-)
[18:38] <james_w> someone *just* opened a bug saying that it should be documented
[18:38] <phinze> ah ha, well that makes me feel better :)
[18:40] <Mez> and the conversion is complete. Work now uses bzr. I wonder how that happened <evil-laugh />
[18:42] <LarstiQ> Mez: that still needs work here, hmm
[18:42] <Mez> LarstiQ: poor you :d
[18:54] <jelmer> jfroy, ping
[18:55] <jfroy> pong
=== mark1 is now known as markh
[19:24] <jfroy> jelmer: ping?
[19:26] <jelmer> jfroy, pong
[19:27] <jfroy> eh, I was just wondering why you pinged me and then went silent :p
[19:27] <jelmer> jfroy, I was wondering if you could still reproduce bug 332364
[19:27] <ubottu> Launchpad bug 332364 in bzr-svn "NoSuchRevision error while branching remote repository" [Medium,Triaged] https://launchpad.net/bugs/332364
[19:27] <jfroy> I'll give it a go
[19:27] <jfroy> I didn't since the bug status didn't change
[19:27] <jfroy> (test it again, that is)
[19:32] <jelmer> jfroy, thanks
[19:34] <jfroy> it failed again
[19:41] <sabdfl> jelmer: ping
[19:41] <jelmer> sabdfl, pong
[19:41] <jelmer> jfroy, thanks, can you pastebin the exact traceback?
[19:42] <jelmer> jfroy: Since the error has hopefully changed :-)
[19:42] <sabdfl> jelmer: i submitted a branch for merging on bzr-gtk, do you review those?
[19:42] <jfroy> it has not
[19:42] <jfroy> at least not much
[19:42] <sabdfl> the branch removes the actions from the notifications bzr-notify emits
[19:43] <sabdfl> actions turn notifications into alerts (i.e, dialogs with cancel buttons that stick around forever) on jaunty
[19:43] <beuno> sabdfl, I reviewed and merged it a few days ago
[19:43] <sabdfl> ah, thanks beuno
[19:43] <sabdfl> would it be possible to put an updated package together?
[19:43] <sabdfl> for 9.04?
[19:44] <beuno> jelmer, you do the packaging for Ubuntu, right?
[19:44] <sabdfl> also, beuno, do you know the status of bzr and loggerhead packages in jaunty?
[19:44] <jelmer> sabdfl: I think a tweaked version of it has been merged based on your patch, which only disables it if the notify daemon (is that the right name) doesn't support actions
[19:44] <jelmer> beuno, Yeah, for Debian/Ubuntu
[19:44] <sabdfl> jelmer: that's better than my patch, i just used a hacksaw :-)
[19:44] <jelmer> sabdfl, I uploaded a fixed package to experimental, james_w was going to request a sync for that for jaunty
[19:45] <beuno> sabdfl, loggerhead is in 1.10, which is the latest release. bzr is in 1.12, which the latest release as well.
[19:46] <beuno> we could do a release of LH, trunk has advanced quite a bit since then
[19:46] <beuno> I'll talk to mwhudson about it
[19:46] <sabdfl> beuno: that would be a good idea, yes
[19:47] <sabdfl> when is bzr 1.13 due?
[19:47] <jelmer> sabdfl: IIRC According to the original schedule a RC1 would be due in a couple of days
[19:47] <beuno> sabdfl, I think after the brisbane sprint next week
[19:47]  * jfroy pasted http://pastie.textmate.org/private/fpkj1uc5yvyqrehvopq8ow
[19:47] <jfroy> jelmer:
[19:48] <beuno> jelmer, hasn't that been pushed back due to the sprint?
[19:48] <sabdfl> i believe 1.13 adds good work on the network performance front, so would encourage a plan to release it *and* get packages into 9.04
[19:48] <jelmer> beuno: Ah, I wasn't aware of that
[19:48] <beuno> jelmer, if I do a release of LH, can you do an upload to debian so we can sync?
[19:48] <jelmer> beuno, My information dates back a month
[19:48] <jelmer> beuno, yeah, np
[19:48] <jelmer> beuno, just ping me when it's out :-)
[19:48] <jelmer> jfroy, thanks
[19:48] <jfroy> np
[19:49] <beuno> jelmer, awesome, thanks. I'll work on it today/tomorrow evening
[19:50] <beuno> sabdfl, I'll email the list about it. When's the jaunty deadline?
[19:51] <sabdfl> beuno: we're already into UI freeze exception territory: https://wiki.canonical.com/DesktopExperienceTeam/JauntyUIFExceptions
=== nevans1 is now known as nevans
[19:53] <beuno> sabdfl, ah, so it's pretty urgent to get these out then  :)    I'll poke people about this
[19:54] <sabdfl> thanks beuno
=== beuno_ is now known as beuno
[20:54] <jpds> How can I resolve a conflicting tag?
[20:54] <rockstar> kfogel, so, it looks like your discussion about PQM is a little different than what PQM really is.
[20:56] <kfogel> rockstar: oh?
[20:56] <kfogel> where did we go off track?
[20:56] <rockstar> Basically, it's similar to Tarmac, only that it gets it's merge requests from email.
[20:56] <rockstar> It's still "client side" in the same way Tarmac is.
[20:56] <kfogel> hmmmm
[20:56] <kfogel> rockstar: so should they be merged?
[20:56] <rockstar> kfogel, absolutely not.
[20:57] <rockstar> PQM is pretty terrible in general, and is heavy, and a pain to install.
[20:57] <kfogel> rockstar: might be good to write a section on how they differ, since they're similar...
[20:57] <kfogel> oh
[20:57] <kfogel> rockstar: well, don't write that :-)
[20:57] <kfogel> rockstar: is Tarmac meant to eventually replace PQM?
[20:57] <rockstar> So I wanted something lightweight, and something that was closely connected to Launchpad.
[21:00] <jfroy> vila: ping
[21:00] <jfroy> +
[21:03] <kfogel> rockstar: *nod*
[21:03] <kfogel> rockstar: is the lightweight-ness or heavyweight-ness noticeable to the user anyway, though?
[21:05] <rockstar> kfogel, yes.  I tried setting up PQM for another project three times.  Each time, I got nominally closer than the previous time, but eventually gave up because of difficulties.
[21:05] <rockstar> kfogel, ask thumper what he thinks of PQM's codebase.  :)
[21:05] <thumper> *cough*
[21:06] <kfogel> rockstar: heh.  Okay, so it's not  that it's heavy in terms of code size or internal complexity, it's that it's heavy in terms of user setup.
[21:07] <rockstar> kfogel, all of the above.
[21:08] <kfogel> whew
[21:08] <kfogel> rockstar: PQM is not Canonical code?
[21:08] <kfogel> rockstar: (I haven't interacted with it much, mostly what I know is hearsay)
[21:09] <rockstar> kfogel, I believe it is now, but it's pretty old and crufty, and I wouldn't say there is active development going on.
[21:10] <LarstiQ> kfogel: it's a pre-bzr codebase
[21:10] <kfogel> LarstiQ: ah
[21:11] <jseutter> question: anyone know how I can get the bzr sources to build bzr on my system?  I need something that can talk branch format 7 to check out bzr.
[21:12] <jseutter> (and yes, all I have done is go to the bzr homepage and try to follow the instructions there.)
[21:12] <jelmer> rockstar, are there any plans to have tarmac work for non-lp?
[21:13] <LarstiQ> jseutter: I'd try the latest release.
[21:13] <rockstar> jelmer, not currently.  I mean, it figures out which branches to merge through the Launchpad API.
[21:13] <rockstar> I guess it could grow that though.  Patches welcome.
[21:14] <jelmer> rockstar, Cool, I might look into that then
[21:14] <rockstar> jelmer, it would be much appreciated.
[21:15] <rockstar> jelmer, I thought it might be good to grow some email features.
[21:15] <jelmer> rockstar, yeah, that's the bit I'm interested in
[21:17] <rockstar> jelmer, also, we've talked about a pluggable branch landing system, so it may be that tarmac could become that, with a LP plugin, and an email plugin.
[21:36] <jseutter> LarstiQ, sorry, I could have been more clear.  To check out bzr it is telling me that I need bzr 1.6 or newer.  The binaries listed on the bzr homepage are all older than that.
[21:36] <jseutter> I can't get the source to build a new version of bzr to get the source.
[21:36] <jseutter> ugh.  My brain is fried.  At any rate, I have a chicken and egg problem.
[21:37] <jseutter> I checked the Ubuntu packages and the Epel repo, and they're both older than 1.6.
[21:38] <jseutter> oh wait, there's a slackware link on the homepage that is 1.6.1.  I'll try building that
=== montywi|meeting is now known as montywi
[21:45] <jseutter> oh fark.  1.12 > 1.5
[21:46] <jseutter> sorry about that.
[22:02] <lifeless> poolie: hi
[22:02] <lifeless> I've gatecrashed Tim's
[22:02] <poolie> hi lifeless
[22:02] <poolie> congrats
[22:15] <bob2> vila: thanks!
=== Spaz is now known as Kittens
[22:27] <spiv> lifeless: d'oh, my less test skips patch failed because of your bzrdir network name changes...
[22:31] <jfroy> vila: when you get around, I need to discuss a few items concerning credential providers
[22:32] <lifeless> spiv: sorry :)
[22:42] <poolie> jfroy: he's probably not back for 8h now
[22:42] <jfroy> poolie: nothing urgent
[22:42] <jfroy> *it's nothing urgent
[22:47] <jelmer> jfroy, see privmsg
[22:51] <poolie> lifeless: progress messages are less important than making sure there are no showstoppers in the version in jaunty
[22:51] <lifeless> poolie: right. So let me cap the high features for you
[22:51] <lifeless> spiv: please add any I miss ;)
[22:52] <lifeless> poolie: we do network streaming push to stacked and non-stacked branches
[22:52] <lifeless> poolie: we do network streaming pull from non-stacked branches, and for stacked ones now use the generic versioned-files based fetch rather than pack-optimised [a slight regression for that specific case]
[22:53] <lifeless> poolie: the streaming requires both client and server to have the format for both source and target in common; that is pushing from a svn checkout to a bzr branch requires the server to have bzr-svn installed
[22:53] <lifeless> we have a bunch of new verbs for creating objects over the wire and getting more data about them when we open them
[22:54] <lifeless> we may find glitches during the beta cycle, but we'll fix them without more wire changes I expect
[22:54] <lifeless> we're happy with the general structure of the data on the wire, so I don't expect we'll need to drop the new verbs at all, or at least not for a long time
[22:55] <lifeless> so we can support the jaunty versions happily
[22:55] <poolie> have you tested all these cases manually, as well as in selftest?
[22:55] <lifeless> not explicitly, and I don't think thats a particularly good use of time until rc1 is out.
[22:55] <lifeless> I'm dogfooding though, and so is spiv
[22:56] <lifeless> so are the folk using bzr nightlies, though they will be nearly universally dogfooding the backwards compatibility behaviour not the new code
[22:56] <spiv> So far I've had no nasty surprises from dogfooding.
[22:56] <jelmer> fwiw I'm dogfooding too
[22:56] <igc> morning lifeless, spiv, jelmer
[22:56] <jelmer> hi Ian
[22:57] <poolie> ok
[22:57] <poolie> so, regardless, i'd like you to please test those cases manually today
[22:58] <poolie> historically this is the kind of change that has caused knock on effects and i'd ilke to reduce the chance in this release
[22:58] <lifeless> poolie: thats going to be basically the whole day
[22:58] <lifeless> poolie: there are a _lot_ of permutations
[23:00] <poolie> is it better to spend that day next week during the sprint?  i think that's even worse.
[23:00] <poolie> and if the other alternative is to do this release in to jaunty without integration testing, i like that even less.
[23:00] <lifeless> poolie: whats the due date for jaunty? Can we not do a days full-permutation testing after the sprint?
[23:01] <lifeless> poolie: and do a point release if we find any issues?
[23:03] <poolie> so that would give us more networking improvements in 1.13, but more chance that there are bugs in the ones we do have?
[23:04] <poolie> wiki.u.c is down and i don't have the dates written down here
[23:04] <poolie> ui freeze is today, beta freeze is march 19
[23:05] <lifeless> thursday after the sprint
[23:05] <lifeless> If we're going to do this sort of manual testing, I'd much rather do it monday the 16th
[23:06] <poolie> because why?
[23:07] <lifeless> well, we have two days left. We might be able to get to streaming-from-stacked, or vfs-free branch-from-non-stacked if we keep the momentum up
[23:08] <lifeless> as soon as we stop, the protocol is frozen for those verbs until the release in the absence of serious issues.
[23:13] <spiv> lifeless: I'm a bit unsure what the right fix for the less-skips + network_name failure is.  The server-side is failing on control_format.get_branch_format().network_name() in sprout_bzrdir_branch_ref tests.
[23:14] <lifeless> spiv: is there a network name for BranchReferenceFormat?
[23:15] <spiv> No, there isn't.  The error is AttributeError: 'RemoteBranchFormat' object has no attribute '_network_name', btw.
[23:16] <poolie> spiv, what do you think?
[23:17] <spiv> poolie: as lifeless says, we are tantalisingly close to some milestones.
[23:18] <poolie> ok
[23:18] <poolie> i will hold you two responsible if there are showstoppers in this release
[23:18] <spiv> So it's even harder than normal to be enthusiastic about manually testing ;)
[23:19] <poolie> but i wish you luck
[23:19] <poolie> sure, i can sympathize with that
[23:22] <lifeless> spiv: *serverside* is using a RemoteBranchFormat?
[23:22] <spiv> lifeless: right!
[23:22] <spiv> lifeless: it's a RemoteBzrDirFormat test.
[23:22] <lifeless> spiv: those two nouns should never be in a single sentence unless it is '*serverside does not use RemoteBranchFormat objects*'
[23:22] <spiv> Or rather, a bzrdir_implementations test.
[23:23] <spiv> Heh.
[23:25] <spiv> lifeless: ok, I can tweak bzrdir_implementations/test_bzrdir to explicitly use get_vfs_only_url or something.
[23:28] <lifeless> spiv: there may betwo issues; the test asking the server to do something bong; the server not preventing third-party-requests.
[23:28] <lifeless> spiv: we know the second exists
[23:29] <spiv> Well, the test was creating a branch reference (on a server), and then sprouting it (to a new url on the same server)
[23:30] <spiv> All three failing tests were following that pattern.
[23:31]  * igc breakfast - bbl
[23:31] <spiv> If I change it to create the branch reference locally, then sprout to a server, it works.
[23:32] <spiv> If I change it to create a remote branch reference, and sprout it to local, it still fails.
[23:32] <lifeless> spiv: so its reasonable to say to the server 'create a branch reference to url XXX'
[23:32] <lifeless> spiv: its not reasonable for the server to assume it can read it
[23:33] <spiv> Right.
[23:40] <lifeless> upo	el	thanks
[23:40] <Jerub> what's the best way to transition from svn to bzr? I tried using bzr-svn but it didn't work for me.
=== montywi is now known as montywi|zzz
[23:42] <lifeless> Jerub: in what way didn't it work
[23:42] <spiv> Jerub: bzr-svn 0.5 has been working very well on the couple of projects I've tried it on.
[23:44] <Jerub> it was a few weeks ago i did it, I don't actually remember what the failure was.
[23:44] <lifeless> poolie: so qa wise I'm much more concerned that we're going to DOS the lp smart server
[23:44] <lifeless> than tat we'll have the client fail to work as desired
[23:45] <lifeless> poolie: theres plenty of adhoc testing that occurs as we just use the client, as we test stuff for the python guys and so on
[23:46]  * Jerub runs it again