[00:00] <lifeless> mtaylor: it may simply be that that is the size of your tree
[00:00] <lifeless> mtaylor: how big is a drizzle tarball (gz)
[00:01] <mtaylor> lifeless: 7M
[00:01] <poolie> hi all
[00:02] <lifeless> mtaylor: so before its 178 and after its 164
[00:02] <lifeless> mtaylor: did you perhaps start with all of mysql and *then* delete huge chunks ?
[00:02] <mtaylor> lifeless: yes.
[00:02] <lifeless> thats it then
[00:02] <mtaylor> (not history of course, but yet)
[00:02] <mtaylor> yes
[00:02] <lifeless> we can't compress changes to the deleted files, cause they aren't changing :)
[00:03] <mtaylor> ah, fair enough
[00:03] <mtaylor> was there ever a plan to do partial branches - like a full branch except perhaps going back only 100 revisions or so?
[00:04] <lifeless> kindof
[00:05] <lifeless> we have ~ 1/2 of it done - stacked branches
[00:05] <lifeless> the other half is disconnecting them and allowing user controlled connect/disconnect
[00:06] <mtaylor> so that I just just pull the stacked branch without pulling the stacked on branch?
[00:06] <lifeless> yes. handwaves furiously.
[00:06] <mtaylor> indeed
[00:06] <lifeless> how big was a mysql tarball (gz)
[00:08] <lifeless> mtaylor: ^
[00:11] <chaosbit> Hi, is there a ticket management system recommended for bazaar?
[00:12] <lifeless> bzr can integrate with quite a few - we allow you to configure that. However we ship with built in configuration for launchpad
[00:12] <lifeless> and launchpad knows how to read the data back out of bzr pretty well
[00:13] <mtaylor> lifeless: 19M
[00:13] <lifeless> mtaylor: urggle. Ok we should investigate
[00:14] <lifeless> mtaylor: 1.18 will convert ok. don't convert with 2.0 or bzr.dev at this time. Brrrroken
[00:14] <lifeless> silently too sometimes.
[00:14] <mtaylor> lifeless: lovely
[00:14] <lifeless> yeah
[00:15] <lifeless> aliases variable
[00:15] <lifeless> alised
[00:15] <lifeless> bah. spellink iz broken.
[00:15] <lifeless> 'aliased'
[00:23] <lifeless> spiv: ping
[00:25] <lifeless> beuno: what bzr did you use to upgrade lh ?
[00:26] <lifeless> beuno: if you used 2.0 or bzr.dev you should redo it with 1.18
[00:26] <beuno> lifeless, 2.0rc1  :(
[00:27] <lifeless> bug 422849
[00:27] <beuno> lifeless, and by redo, you mean...?
[00:28] <lifeless> back out, restore the backup, convert again.
[00:28] <lifeless> theres a high chance it wrote arbitrary data into your history
[00:29] <lifeless> and I don't have stats on what % of the time it will catch the error with the inconsistent delta warning.
[00:29] <beuno> ok, sill do it
[00:29] <beuno> thanks lifeless
[00:30] <beuno> dinner now, fix later
[00:31] <lifeless> beuno: if you converted over the network its ok
[00:31] <lifeless> beuno: its only if you converted locally that its fail
[00:31] <poolie> jelmer: hi, still here?
[00:31] <lvh> hi
[00:31] <poolie> emmajane: still here?
[00:31] <beuno> lifeless, ah, I did.
[00:32] <lifeless> more detail coming up on the list soon.
[00:32] <emmajane> poolie, barely :)
[00:32] <poolie> ok :)
[00:32] <poolie> don't need to hang around on my accoutn
[00:32] <poolie> if you didn't already do it (i haven't read all my mail) i'm going to forward some screenshots to the list
[00:32] <poolie> i'd like to continue the discussion there
[00:33] <emmajane> poolie, I'm making slides explaining square dancing as an analogy for PHP. you're welcome to distract me. :)
[00:33] <poolie> heh :)
[00:33] <emmajane> poolie, Oh. the screenshots went to the list this morning. there's been about 10 replies?
[00:33] <lvh> i dont understand the difference between bzr branch -r -5 . ../next; bzr pull . --overwrite -r -5 and bzr branch -r -5 . ../next; bzr uncommit -r -5 # could anyone please explain?
[00:34] <lvh> maybe it's just because i havent slept in 24 hours :-D
[00:34] <poolie> are those two alternative sequences?
[00:34] <lifeless> lvh: the uncommit leaves the tree changes in your current directory
[00:34] <emmajane> poolie, the two that I sent? one has the carousel and one is closer to the wireframe.
[00:35] <lvh> lifeless: Ah, whereas the former will properly pretend I never changed anything?
[00:35] <poolie> you'll discard your working tree changes as well as the revisions
[00:36] <lvh> as long as 'discard' means 'move into the new branch' thats what I want :-)
[00:36] <lvh> but im guessing thats what the bzr branch -r -5 does
[00:37] <lifeless> lvh: heres a better recipe
[00:37] <lifeless> bzr branch . ../next
[00:37] <lifeless> bzr pull . --overwrite -r -5
[00:37] <lifeless> I have you a buggy recipe before
[00:38] <lvh> okay
[00:38] <lvh> thanks :-)
[00:39] <poolie> lifeless: i wonder if we should remove the downloads for 2.0rc1?
[00:39] <poolie> well done btw
[00:40] <lifeless> poolie: that would be a good precautio
[00:40] <lifeless> n
[00:50] <lifeless> master: Exporting thorough delta revision 93606/133780 with 140/822/110 added/changed/removed files
[00:50] <lifeless> still going...
[00:57] <emmajane> poolie, the wifi keeps dropping me and i'm going to call it a night. please do eemail if I've missed anything.
[01:00] <spiv> lifeless: pong
[01:06] <poolie> hello spiv
[01:06] <poolie> lifeless, tangentially https://bugs.edge.launchpad.net/launchpad-registry/+bug/422902
[01:06] <lifeless> spiv: hi; see the list, and my question about tests :)
[01:08] <thumper> rockstar: how to you create a new pipe and take the uncommitted changes?
[01:08]  * spiv looks
[01:12] <spiv> oh, the question about tests is in scrollback, not on the list?
[01:12] <lifeless> yes
[01:14] <spiv> Something in per_interrepository I think.
[01:15] <spiv> I think .test_fetch.test_fetch_parent_inventories_at_stacking_boundary (and similarly test_fetch_parent_inventories_at_stacking_boundary_smart)
[01:21] <poolie> igc, +1 to you trying to improve the installer
[01:21] <jelmer> poolie: yep, somewhat
[01:21] <igc> poolie: I'll be off irc for a while, learning InnoSetup & reviewing how the current installer hangs together
[01:21] <poolie> it's probably redundant to tell you so but please document or script it so we can reproduce it
[01:21] <igc> poolie: call me re the content filtering stuff when you want
[01:21] <poolie> i think a big problem here is that this is complex and manual, and requires building up state on a particular machine
[01:22] <poolie> unless lifeless wants help with 2a bugs i'm going to do that today
[01:22] <poolie> ok i will
[01:22] <poolie> s/that/content filterign
[01:22] <poolie> spiv, ^^ that's what i had to say
[01:22] <poolie> how about you?
[01:22] <igc> poolie: there's 2 patches related to content filtering submitted yesterday for review so starting with those might be good
[01:23] <igc> poolie: sure, I'll write things up
[01:23] <igc> bbl
[01:23] <poolie> kk
[01:24] <poolie> igc there is a wiki page about it
[01:24] <poolie> and john said he sent mail to canonical-bazaar recently
[01:24] <lifeless> poolie: I have an errand to run in crows nest (my memory); leaving for that shortly.
[01:25] <poolie> k
[01:25] <poolie> we can do lunch if you want
[01:25] <poolie> igc, also, i'll leave it up to you where you want to experiment
[01:25] <poolie> but at some point we need all the dependencies on an ec2 machine
[01:26] <poolie> so, maybe it would save time to do it now...
[01:26] <poolie> otoh if you need to experiment it may be easier to do it locally
[01:26] <poolie> i'll send you the rdesktop command anyhow
[01:26] <igc> poolie: I just want to make it work locally first
[01:26] <igc> poolie: I saw the doc re ec2
[01:27] <poolie> k
[01:27] <poolie> i have some changes locally
[01:27] <spiv> poolie: about to ask for reviews for the chk roots-only commit_write_group check;
[01:27] <poolie> as far as using just a single account etc
[01:28] <spiv> I'm then going to unshelve the changes I have for testing for all relevant chk keys and work on that, the prototype appears to function.
[01:28] <poolie> lifeless: is there anything i should do on 2a?
[01:29] <poolie> i guess primarily, do you think all those failures have the same cause?
[01:29] <lifeless> poolie: try my patch
[01:29] <lifeless> poolie: see if it addresses the error you had]
[01:29] <poolie> good idea :)
[01:31] <mtaylor> lifeless: wow. I _really_ love silent mode in automake 1.11
[01:31] <lifeless> mtaylor: :)
[01:31] <lifeless> poolie: checking it is on my todo but its easy to parallise on
[01:31] <lifeless> https://code.edge.launchpad.net/~lifeless/bzr/bug-422849/+merge/11023
[01:31] <poolie> sure, that's just the kind of thing i was looking for
[01:46] <rockstar> thumper, I shelve the changes, add-pipe, and then unshelve.
[02:08] <thumper> rockstar: ok
[02:26] <thumper> anyone know why we get UnexpectedStderr: Unexpected standard error from subprocess: warnings.warn("%r was gc'd while locked" % self.repr) ??
[02:27] <thumper> I think the UnexpectedStderr may be ours (LPs) but I'm not sure
[02:39] <poolie> hi
[02:39] <poolie> thumper: i've never heard of UnexpectedStderr
[02:39] <poolie> but the warning is ours
[02:39] <poolie> um
[02:39] <poolie> i thought we got rid of them
[02:39] <thumper> poolie: the UnexpectedStderr are probably our checking of the bzr process for pulling
[02:39] <poolie> if it's your code calling into bzrlib you're probably missing a try/finally: thing.unlock()
[02:40] <mwhudson> thumper: generally those warnings are associated with other branches that failed to pull
[02:40] <thumper> poolie: we aren't getting it all the time, just a few times
[02:41] <poolie> mm
[02:41] <mwhudson> for a while, all loom branches did that, but i think that's fixed
[02:41] <poolie> so i'd speculate that either in the puller code or bzr
[02:41] <poolie> something is unlocked normally but not after an exception
[02:47] <lifeless> poolie: did it fix your issue
[02:47] <lifeless> ?

[02:55] <poolie> lifeless: that seems to have fixed it
[02:55] <spm> poolie: recognising this is a bit of a "how long is a piece of string?", are we expecting to try again on the bzr upgrade to 2a today? Is cool either way, just wanting to get an idea on timing etc.
[02:55] <poolie> spiv, what do you think of http://sourcefrog.net/tmp/20090901-341535-eintr.diff
[02:55] <poolie> spm, if lifeless's patch, which i'm testing now, lands
[02:55] <poolie> and it's the top priority
[02:55] <poolie> that should unblock us redoing the upgrade
[02:55] <spm> excellent!
[02:56] <poolie> to find the next bug :)
[02:56] <poolie> or not
[02:56] <spm> ha
[03:02] <spiv> poolie: wow, that seems a bit extreme somehow.  But it's probably correct.
[03:02] <spiv> Assuming it does actually work when you test it manually :)
[03:02] <poolie> it does
[03:02] <poolie> see https://bugs.edge.launchpad.net/bzr/+bug/341535
[03:03] <poolie> where i also say i'm on the verge of making a decorator object that wraps these methods
[03:03] <poolie> do you know of one?
[03:03] <poolie> that would also make it more testable, though
[03:03] <poolie> :/ it's one of those things where unit testing it does not give great assurance that it actually works
[03:05] <poolie> spiv, what do you think?
[03:05] <poolie> if i make a class i just need to make sure it's used everywhere
[03:06] <poolie> i guess it can be stuck into the constructors fairly easily
[03:08] <ricardo_br> hi people! I'm using version 1.6.1, is there any command that I can see the files that changed between the revisons x..y?
[03:08] <spiv> Hmm, I'm torn.
[03:09] <spiv> Decorating the socket/pipe/etc object is probably cleaner, but on the other hand your patch is nice and straightforward.
[03:10] <bob2> ricardo_br: bzr diff -r x..y | diffstat?
[03:10] <poolie> or 'bzr status -r x..y'
[03:10] <bob2> oh, neat
[03:10] <poolie> spiv, if i thought there would be more cases then i'd do the object
[03:10] <poolie> ricardo_br: you might like to upgrade though, that's a bit old now
[03:10] <poolie> is that the package in a distro?
[03:10] <spiv> If the underlying objects weren't private to the SmartMedium classes, that would be a pretty strong case for decorating.
[03:11] <spiv> poolie: right.
[03:11] <poolie> it's true it's more than 3 cases, strictly speaking
[03:11] <poolie> maybe i'll propose just this for now
[03:11] <spiv> poolie: So, I'm happy with the patch as is.  If you feel like writing the decorator I'm happy to look at that page too :)
[03:11] <spiv> But it's not a big deal to postpone that refactoring indefinitely.
[03:13] <ricardo_br> poolie: I think I've installed it through ubuntu apt-get install
[03:16] <ricardo_br> I've changed one file in the rev 61 and another file in the rev 62, when I run "bzr diff -r61..62" I can see only the changes in the file in rev 62
[03:17] <poolie> ricardo_br: you'll need -r61..63 then
[03:17] <poolie> sorry
[03:17] <poolie> -r 60..62
[03:17] <poolie> the previous one is "the changes from 61 to 62"
[03:19] <poolie> spiv, <https://code.edge.launchpad.net/~mbp/bzr/341535-eintr/+merge/11029> but it's not urgent
[03:20] <ricardo_br> poolie: thanks! it worked. Just another question, can I see only the file names?
[03:23] <poolie> rather than what happened to them?
[03:23] <poolie> um
[03:23] <poolie> not super easily, but you could use a shell script
[03:23] <poolie> btw newer versions for ubuntu are in https://launchpad.net/~bzr/+archive
[03:25] <poolie> spm btw the patch i referred to above is https://code.edge.launchpad.net/~lifeless/bzr/bug-422849/+merge/11023 and bug 422849
[03:26] <ricardo_br> thanks for the tips poolie and bob2, I'll checkout the new versions
[03:26] <poolie> just fyi; we'll ping you when we get closer
[03:26] <spm> poolie: did you mean me? or andrew? I assume the latter.
[03:26] <poolie> no, you
[03:26] <poolie> that's the one that's blocking the upgrade
[03:26] <poolie> you don't need to do anything with it
[03:26] <poolie> just in case you were wondering
[03:27] <spm> ah, right. wit hthe plot now.
[04:14] <johnf1> What is the mailing list and bundle-buggy still the best for patches or merge request in launchpad?
[04:57] <jam> johnf: best is merge request
[04:58] <johnf> jam: and a separate branch per feature/bug fix?
[04:58] <jam> johnf: generally
[04:59] <jml> hey
[05:00] <jam> hey jml
[05:00] <jml> if I wanted to do a patch _right now_ to stop Bazaar from treating directory removal as a conflict when the directory contains pyc files, how should I go about it?
[05:00] <jam> anyway, off to bed for me
[05:00] <jml> jam: g'night
[05:14] <AfC1> jml: doesn't .bzringore *.pyc mean that that problem goes away?
[05:14] <AfC1> bah
[05:15] <jml> hmm. does it?
[05:15]  * jml tries science
[05:15] <mwhudson> AfC: no
[05:15] <mwhudson> it's the old "junk vs deliberately unversioned" chestnut
[05:17] <AfC> jml: I think fondly of science. Especially mixing the chemicals together and making them go phoof!
[05:17] <jml> but it's irritating me enough to do something about it.
[05:18] <jml> there, I just empirically verified that mwhudson is right.
[05:19] <jml> AfC, well, in these enlightened times chemicals are entitled to do whatever they want in the privacy of their own home.
[06:15] <jml> ok, so git really is quite fast.
[06:25] <johnf> is there a way to create a branch of bzr inside launchpad without having to branch to my laptop and then push?
[06:27] <spiv> Well, you could do "bzr branch lp:bzr lp:~johnf/bzr/foo", but that still goes via your laptop...
[06:28] <spiv> If you already have bzr on your laptop, it shouldn't be very expensive to do that push, though, because the branch will be stacked on lp:bzr.
[06:28] <johnf> spiv  as in 200MB traffic needs to go both ways or does everything happen on the server end?
[06:29] <johnf> ahh it's the stacking that I don't have
[06:29] <spiv> (and even in the lp:bzr -> lp:~johnf/bzr/foo it should still stack, although I can imagine it would fall a fair way short of being full efficient as that case hasn't been tested much)
[06:29] <spiv> You don't?  Stacking should be automatic when you push to Launchpad, unless your local copy of bzr is in an old format?
[06:30] <johnf> yeah just realised my bzr.dev wasn't off launchad
[06:30] <johnf> fixing that now
[06:31] <johnf> so if I branch from lp. then branch again on disk and then push to lp will everything remain stacked?
[07:04] <vila> hi all
[07:09] <spm> hey vila
[07:22] <poolie> hi spm, vila
[07:23] <poolie> spm, it looks like that patch will work but other stuff came up and we're not likely to attempt the upgrade today
[07:23] <poolie> we'll probably merge it and may try it tomorrow
[07:23] <spm> fair enough, shame in a way :-/
[07:23] <poolie> jml, still around?
[07:23] <jml> poolie, yep
[07:24] <poolie> quick call?
[07:25] <jml> poolie, sure.
[07:25] <jml> skype or pots is fine by me
[07:25] <poolie> let's see if skype will play
[08:13] <lifeless> bug 422849 is in pqm for 2.0
[08:20] <vila> lifeless: trivial enough to land without review ? I ask because I read the related mails first thing this morning (before hitting enter on 'bzr upgrade', pfew, lucky me) and couldn't find the merge proposal...
[08:22] <vila> and didn't notice the linked branch until now :-/
[08:23] <vila> lifeless: right, so the patch is indeed trivial and was in the bug comments, good
[08:25] <vila> lifeless: yet.... fixing a critical bug without adding test[s]... :-/
[08:25] <lifeless> vila: it was reviewed :)
[08:25] <vila> ok
[08:26] <lifeless> vila: I want tests; I'm not done on the bug. If you felt like writing some test during your day that would rock; otherwise I hope to get something that triggers it cleanly etc tomorrow.
[08:26] <vila> Ha great
[08:26] <lifeless> vila: missing tests shouldn't prevent us fixing a problem!
[08:26] <vila> sure
[08:27] <vila> obviously I missed some discussion, no worries, just catching up
[08:27] <vila> happy to see we agree on all fronts :)
[08:27] <vila> and above all thanks for fixing it since, well, I *was* about to upgrade locally :)
[08:28] <lifeless> my pleasure :)
[08:28] <vila> that close: ''
[08:28] <lifeless> poolie: spm: I think we should wait for bzr.dev nightlies to have this fix before executing on 2a for bzr.dev
[08:28] <lifeless> Doing otherwise will make it harder for people to be sure they can upgrade cleanly themselves.
[08:30] <lifeless> vila: your test spike looked interesting
[08:31] <vila> lifeless, spm: exactly why I asked to keep notes about what version was used to upgrade. (And I don't pretend my crystal ball warned me, it was just,,, well, prophylactic acting)
[08:31] <lifeless> vila: I look forward to seeing it in action.
[08:31] <vila> shell-like you mean >
[08:31] <vila> shell-like you mean ?
[08:31] <lifeless> vila: I'm hoping that it will be able to be totally simulated in memory :)
[08:31] <lifeless> yes
[08:32] <vila> Many threads are converging in the right direction I think, I like jam ideas about MemoryTree and branch builder, I really think we should upgrade them
[08:32] <lifeless> so do I
[08:32] <lifeless> I think we should build our testing safety net safety net first
[08:32] <vila> I mean, add the missing features to MemoryTree and branch builder so they can be used more broadly
[08:33] <lifeless> I see the most important things being some additional glue and reporting
[08:33] <lifeless> so we can answer questions like 'how important is this test', or 'these tests'
[08:33] <lifeless> 'if I delete this test, what coverage do I remove'
[08:33] <vila> oh yes...
[08:33] <lifeless> and 'what tests add no coverage today?
[08:33] <lifeless> '
[08:34] <vila> an important milestone to reach is to know that all code is covered (even if only once), I have no idea where we are today
[08:34] <lifeless> now, we'll need to think about the answers to those questions, but I think you'll agree that they are very interesting questions
[08:34] <vila> ooooh yes
[08:35] <lifeless> andrew wrote a coverage plugin
[08:35] <lifeless> and there are some coverage analysis tools in the python testing community
[08:35] <lifeless> At the risk of sidetracking you :)
[08:35] <vila> we have a --coverage option, I need to use it more :)
[08:36] <vila> well, not only me :)
[08:36] <lifeless> --coverage is the plugin
[08:36] <lifeless> I think
[08:37] <vila> nah, bzr help global-options
[08:37] <vila> available in every good bzr :)
[08:37] <lifeless> ah no
[08:37] <lifeless> needs to be per test
[08:38] <lifeless> or you can't answer those questions
[08:38] <lifeless> figleaf sections can do it
[08:38] <lifeless> or per test decorators
[08:38] <lifeless> with only a moderate failure mode for tests of lsprof
[08:43] <vila> so, to run test in isolation I use selftest-by-n.py: http://paste.ubuntu.com/263626/
[08:43] <vila> ./bzr selftest --list >all-tests
[08:43] <vila> selftest-by-n.py --starting-with --in-tmp --number 1 all-tests
[08:44] <vila> I didn't play with it for months but ran it again last time we discussed about that, I need to analyse a bit more, but I already have some leaks identified (the meacs-bzr-send.xxx.el in /tmp for one)
[08:45] <vila> s/meacs/emacs/
[08:45] <vila> and the bzr-limbo ones !
[08:45] <lifeless> pastebin.com/f600ce040
[08:46] <lifeless> thats much/most of my sketch
[08:46] <lifeless> enjoy
[08:46] <vila> :-D
[08:46] <lifeless> It needs:
[08:46] <spiv> Yeah, the existing --coverage is pretty basic.
[08:46] <lifeless> better data mode
[08:47] <lifeless> and thats about it
[08:47] <spiv> per-test collection/reporting would be neat.
[08:47] <lifeless> the better model I think would be best to try next is:
[08:49] <vila> lifeless, spiv: My gut feeling is that trying to de-tangle coverage data is... NP-complete, I'd rather generate coverage data for each test in isolation and work hard to avoid redoing it uselessly
[08:49] <lifeless> file_line:file_line_id  file_line_id:testid_id  testid_id
[08:49] <lifeless> vila: I agree; thats what my plugin does
[08:50] <vila> oh
[08:51] <vila> but then you don't need to go down to lines, you can just keep 'test -> modules+'
[08:55] <lifeless> spiv: --lsprof-tests gives you stome per test stuff today; no consistent reporting
[08:57] <vila> stome ?
[08:58] <lifeless> some
[08:58] <vila> ha.
[09:01] <NEBAP|work> can someone point em to technical information about the default file format that is used by bazaar? I just want to create a little reader application ..
[09:01] <NEBAP|work> s/em/me
[09:01] <poolie> look at the developer notes in doc.bazaar-vcs.org
[09:04] <poolie> vila, i might sign off soon
[09:04] <lifeless> vila: per line gives you per function when combined with diff
[09:04] <poolie> is there anything you want to talk about?
[09:04] <lifeless> vila: which gives you 'run the tests for this change'
[09:05] <vila> lifeless: If it works, great ! My fear is that it's trickier to get right than just: run these tests because one of their associated module has changed
[09:06] <vila> poolie: nothing in particular, I think I've got enough feedback on shell-like tests to make a more concrete proposal (without putting too much features yet anyway, mostly doc, look at doctest matching and some polish)
[09:07] <vila> Overall, the intent is to have something that you can copu/paste your shell session, lightly edit it and a get a runnable test
[09:07] <lifeless> vila: the function matching code is done and working
[09:07] <vila> s/copu/copy/
[09:08] <lifeless> vila: its just an efficient index that is needed
[09:08] <vila> lifeless: That's how I understood it
[09:08] <vila> lifeless: err wrong context :)
[09:08] <vila> I thought you were talking about doctests :)
[09:08] <lifeless> nooo
[09:09] <lifeless> 31K revisions of netbeans to go
[09:09] <poolie> vila, cool, i was happy to see that posted
[09:09] <igc> poolie: vila: well done on your progress on the 'shell test' stuff
[09:10] <vila> poolie: I thought so :-) The trigger was when you said: 'could be used for merge resolution tests' to which I nearly replied 'Will you stop reading my mind ! '
[09:10] <igc> vila: I'm yet to look at it but it's very much along the lines of what I've been dreaming of
[09:11] <vila> igc: not for you ! You're testing at far too high levels already :-P
[09:11] <igc> vila: I'm sure when it's ready it will help casual contributors write more tests more easily
[09:12] <poolie> igc, something nontechnical came up today so i didn't do anything on filtering :-(
[09:12] <poolie> sorry
[09:12] <poolie> maybe tomorrow
[09:12] <igc> vila: :-)
[09:12] <igc> poolie: np
[09:12]  * igc dinner
[09:12] <poolie> good idea
[09:12] <vila> igc: yup, casual contributors is definitely the target
[09:13] <NEBAP|work> only thing I found is http://doc.bazaar-vcs.org/latest/developers/packrepo.html which didn´t help enough ..
[09:15] <NEBAP|work> are there no more detailed docs about the file system?
[09:16] <NEBAP|work> or is there already a php script that is able to read bazaar branches?
[09:22] <lifeless> NEBAP|work: I believe folk have written php code to call out to bzr
[09:23] <lifeless> NEBAP|work: I wouldn't recommend reimplementing the disk format: there is a chunk of code and logic there, its neither small nor simple
[09:23] <NEBAP|work> lifeless: yeah
[09:24] <NEBAP|work> lifeless: I just want to enable my page to read the format to easily implement some "open source" code viewing ..
[09:25] <NEBAP|work> and I didn´t find any implementations in php
[09:34] <lifeless> bug fix -> bzr.dev
[09:34] <vila> lifeless: you may want to review the patch I'm preparing about the leaks to see why you didn't catch these ones (that's for tomorrow)
[09:36] <lifeless> vila: I haven't written code to catch os calls yet
[09:36] <vila> lifeless: at least I *think* you didn't catch them, but since your related patch hasn't landed yet(
[09:36] <lifeless> vila: like subprocess :P
[09:36] <lifeless> vila: I haven't had time to progress that spike for a few days
[09:36] <lifeless> vila: feel free!
[09:36] <vila> :-)
[09:37] <vila> not sure the ones I'm catching are in the scope, so far that's tmp files created explicitly but not cleaned up
[09:37] <lifeless> seriously though, I think the next step is more protection and or coverage
[09:37] <lifeless> after that run-changed-code
[09:37] <lifeless> then back to isolation
[09:38] <lifeless> vila: my plan there is: hook into file() and open() and unlink()
[09:38] <lifeless> + rename
[09:38] <lifeless> a create file attempt outside TEST_ROOT and /tmp is an error
[09:38] <lifeless> ditto read
[09:38] <lifeless> a create file / dir in /tmp that isn't later cleaned up is an error
[09:39] <vila> TMPDIR not /tmp, just in case :)
[09:39] <lifeless> clean up can be mv into TEST_ROOT
[09:39] <lifeless> or mv and delete within TMPDIR
[09:40] <vila> "isn't later cleaned up" is the tricky one since you can't trap it early, you can only whine at tearDown time
[09:41] <vila> lifeless: but that should work and be quite pleasant, I wonder if I should leave these leaks to server as easy preys...
[09:41] <vila> s/server/serve/
[09:42] <vila> well, they are there already, they can be fixed but not merged where they are needed.
[09:53] <NEBAP|work> there is no php script that is able to read a bazaar branch, the only thing I found is one that executes some shell calls to bazaar, which won´t work on most servers ..
[09:56] <NEBAP|work> but I found out that some other guys also are searching for a php script to read their branches ^^
[09:57] <NEBAP|work> so
[09:58] <lifeless> NEBAP|work: I would estimate 3-4 weeks solid work to reliably read the data format, including race conditions etc.
[09:58] <NEBAP|work> ^^
[09:58] <lifeless> NEBAP|work: If you are up for that, well great.
[09:58] <NEBAP|work> hmm
[09:59] <NEBAP|work> otherwise maybe no one will start
[09:59] <lifeless> Start a project; study the bzr code, and when the code is ambiguous, we can provide more insight.
[09:59] <NEBAP|work> ok
[09:59] <lifeless> But! I think its much better off using e.g. bzr's xmlrpc server
[09:59] <lifeless> or shelling out
[09:59] <lifeless> than reimplementing.
[09:59] <NEBAP|work> hmm
[09:59] <NEBAP|work> the problem is that most php server doesn´t allow system calls
[10:00] <NEBAP|work> s/server/servers
[10:00] <NEBAP|work> so
[10:00] <lifeless> NEBAP|work: you'll need C to read the file content anyway
[10:00] <NEBAP|work> really?
[10:00] <NEBAP|work> why?
[10:00] <lifeless> compression logic is slow in high level languages
[10:00] <lifeless> and bzr data is very very tightly compressed
[10:00] <NEBAP|work> hmm
[10:00] <NEBAP|work> that might be a problem
[10:01] <NEBAP|work> for me it will only work if I just use php
[10:02] <NEBAP|work> so
[10:02] <lifeless> can you just export the files you want from bzr
[10:02] <lifeless> e.g. using bzr uplaod
[10:02] <NEBAP|work> there is no detailed documentation of the file format?
[10:02] <NEBAP|work> yes
[10:02] <NEBAP|work> thought of that
[10:03] <NEBAP|work> but uploading some php files (sources) will end up with problems maybe
[10:03] <NEBAP|work> and it would be really cool to push a new rev and be able to read the branch using php
[10:03] <lifeless> there are detailed docs of various layers, many of which are part of the source
[10:03] <lifeless> e.g. pydoc bzrlib.bzrdir
[10:03] <lifeless> will tell you about the bootstrap files
[10:04] <lifeless> there isn't an 'implementors guide'
[10:04] <NEBAP|work> k
[10:04] <NEBAP|work> so
[10:04] <lifeless> you *will* have to read through and understand the code in bzrdir, repository, repofmt/*{or the formats you want to understand}, branch, versionedfiles, tree, revisiontree
[10:04] <NEBAP|work> I´ll start by checking the bazaar sources
[10:04] <lifeless> inventory
[10:04] <lifeless> and maybe more
[10:05] <NEBAP|work> thanks
[10:05] <NEBAP|work> that will give me a starting point :)
[10:05] <lifeless> good luck
[10:05] <NEBAP|work> thank you :)
[10:13] <jelmer> james_w: hi!
[10:13] <james_w> hey jelmer
[10:13] <james_w> how's it going?
[10:13] <vila> hey james_w jelmer  :)
[10:13] <vila> jelmer: welcome back !
[10:13] <james_w> hey vila
[10:14] <jelmer> Hi Vincent!
[10:15] <jelmer> james_w: I saw you committed bzr 1.18 in the bzr branch - did you find somebody to sponsor for Debian yet?
[10:15] <james_w> I didn't
[10:15] <jelmer> james_w: Ok, I'll have a look at uploading then
[10:16] <james_w> I need to fix bzrtools
[10:16] <james_w> and you may want to confirm what I did with bzr-svn
[10:16] <vila> jelmer: I built packages for bzr-gtk but I didn't know how you proceed for debian, keep me in the loop when/if you need to update the related branches
[10:16] <james_w> there's bzr-gtk and loggerhead as well, but I don't think they are version locked
[10:17]  * jelmer nods
[10:17] <vila> james_w: bzr-gtk is version "locked" on the bzrlib API, so it's ok for bzr-2.0
[10:17] <vila> since the API didn't change
[10:19] <NEBAP|work> lifeless: which is the default format? knitrepo or pack_repo?
[10:20] <vila> NEBAP|work: groupcompress_repo
[10:20] <vila> NEBAP|work: at least it will as soon as 2.0 is out
[10:21] <NEBAP|work> ah ok
[10:21] <jelmer> what's the plan for 2.0 exactly? Just those two blocker bugs?
[10:21] <NEBAP|work> how long will that take? I´ve seen there is much traffic in the 2.0 branch ^^
[10:22] <vila> AIUI 2.0rc2 should be a couple of days away
[10:22] <NEBAP|work> cool
[10:24] <vila> lifeless: fix landed in 4.666, that was really an evil bug :-D
[10:28] <lifeless> yes
[10:28] <lifeless> aliasing
[10:29] <lifeless> it would be nice if python had a 'final' facility.
[10:29] <lifeless> like C/C++ const | java final | most any functional language
[10:29] <bob2> or a pyflakes check
[10:30] <lifeless> bob2: can't catch all the evil I can do
[10:30] <bob2> nothing can
[10:30] <lifeless> bob2: but yes it could help
[10:31] <lifeless> SA isn't a common python idiom though
[10:31] <lifeless> so it would need to be brought in gradually.
[11:33] <lifeless> james_w: ping
[11:33] <james_w> hi lifeless
[11:33] <lifeless> did you see my WARNING mail to bazaar@
[11:33] <lifeless> if not, go read it :P
[11:34] <lifeless> I'd like to ensure that the bzr nightly builds have that patch in them, asap.
[11:34] <lifeless> IIRC you coordinate those?
[11:34] <james_w> yeah
[11:34] <james_w> when was the bug introduced?
[11:34] <lifeless> 24th or so, IIRC
[11:34] <james_w> and the easiest way to do that is to get it in to trunk
[11:34] <lifeless> the patch is in trunk
[11:34] <james_w> the nightlies aren't affected then
[11:35] <james_w> then the nightlies pick it up
[11:35] <james_w> or is that "run them now please"?
[11:35] <lifeless> james_w: you haven't been building for a week?
[11:35] <lifeless> james_w: its 'run them now please, and shepard them through'
[11:35] <james_w> no
[11:35] <james_w> ok
[11:35] <lifeless> I'm sure they would build normally anyhow
[11:36] <lifeless> just want personal assurance that it succeeds, as this is a blocker for doing the bzr upgrade to 2a
[11:36] <james_w> sure
[11:36] <lifeless> thanks hugely
[11:37] <lifeless> if there is a problem, can you mail poolie and I
[11:37] <james_w> they are not fully automated yet
[11:37] <james_w> sure
[11:37] <lifeless> and I'll fix my tomorrow am, hopefully in time to catch you or [can anyone fix things if it breaks] ?
[11:37] <james_w> I don't want to automate them on my end without making the tools to do so available to everyone
[11:38] <james_w> anyone can upload to the nightly ppa that is a memeber of the team
[11:38] <james_w> I forget who that is now
[11:38] <james_w> you, John, Martin
[11:38] <lifeless> ok cool
[11:38] <lifeless> anyhow, it passed PQM
[11:39] <james_w> they are running now fwiw
[11:39] <lifeless> I'm sure there will be no difficulty
[11:39] <lifeless> thanks!
[11:39] <lifeless> I'm past EOD myself, so I'm now going to forget about this until after-sleep
[11:39] <james_w> sure
[11:39] <james_w> go sleep
[11:43] <james_w> jelmer: bzrtools fixed on bzr.debian.org so available when you want to upload 1.18
[11:54] <james_w> hmm, not in bzr.dev yet
[11:54] <james_w> ah, not on LP yet
[12:23] <CameronP_> Hi there i was wondering if I could get some advice on repository layouts..
[12:34] <lifeless> jelmer: so you use doap?
[12:37] <jelmer> james_w: thanks!
[12:37] <jelmer> lifeless: yeah, occasionally
[12:37] <jelmer> lifeless: I try to keep my doap files up to date, but I don't always use doap yet where I want to.
[12:38] <lifeless> jelmer: you might like to reply to my doap-interest post
[12:38] <jelmer> mainly because the tools are incomplete
[12:38] <jelmer> lifeless: I'll have a look
[12:38] <lifeless> without dependencies its hard to write useful tools beyond toys IMO
[12:38] <lifeless> its relationships make foaf useful
[12:40] <jelmer> lifeless: it depends on what you want to use it for I guess
[12:40] <jelmer> if you want to use DOAP to help with packaging, I agree dependencies are a need
[12:41] <lifeless> jelmer: relationships let you build a package spiderer
[12:41] <lifeless> without that its just another way to write a readme and news file :)
[12:48] <jelmer> lifeless: true, though a parseable one
[13:05] <CameronP_> Do you guys help out newbs to baazar?
[13:08] <spiv> CameronP_: yes, although sometimes the channel is just quiet.
[13:08] <spiv> CameronP_: a more specific question might attract more answers
[13:14] <CameronP_> Yeah sorry after that I just worked it out myself!
[13:14] <CameronP_> I was just having issues creating shared repositories
[13:19] <spiv> CameronP_: Heh, ok :)
[13:47] <CameronP_> spiv, If I want to get the latest version of a branch, but dont want any history (eg for publishing to web server) is the bets way via the --lightcheckout ?
[13:47] <CameronP_> --lightweight i mean
[13:50] <lifeless> CameronP_: to publish to a webserver, use bzr upload
[13:50] <lifeless> its a plugin
[13:50] <lifeless> and designed for web publishing
[13:51] <awilkins> Does that just do a "straight" upload each time or does it rsync or do incremental updates?
[13:53] <CameronP_> oh ic...
[13:53] <CameronP_> spiv: Thanks I'll take a look
[14:00] <spiv> awilkins: incremental, I believe.
[14:02] <spiv> awilkins: see http://bazaar.launchpad.net/~bzr-upload-devs/bzr-upload/trunk/annotate/head%3A/README
[14:16] <garyvdm> Hi - I'm haveing to push some branches (in 2a format) via a slow ftp connection. It keeps on repacking the remote repo. This is realy irritating. Is there any way to disable this, and what would the effects of that be?
[14:17] <spiv> jam: around?  I want to check which email address is good for you atm, as the usual one seems to be bouncing.
[14:17] <CameronP_> spiv: What is meant by JUst the working tree for upload
[14:17] <CameronP_> eg say I've create a shared repostiory repository
[14:17] <CameronP_> and then ive created a project called xyz
[14:18] <CameronP_> and i only want to "upload" via the plugin just the project xyz
[14:18] <spiv> garyvdm: if do a manual pack, it'll fully pack the whole repo which will have the side effect of delaying large autopacks for quite a while.
[14:18] <spiv> garyvdm: there's no option for disabling autopacks entirely that I know of
[14:19] <spiv> garyvdm: the effects however would be a steady slowdown in read speed when accessing the repo, especially over a network.
[14:20] <garyvdm> spiv: I don't really understand what pack does, but maybe the autopack policy needs to be different for dumb remote to local, and smart remote.
[14:20] <spiv> CameronP_: if you want to just upload the files, no history, to a webserver, then the bzr-upload plugin is probably the best tool.
[14:21] <spiv> CameronP_: whether or not you have a shared repo doesn't affect that.
[14:21] <CameronP_> yeah im confused i think
[14:21] <CameronP_> the problem is that the central repo is the same server the website is on
[14:22] <CameronP_> so my understanding isnt fitting if you know what i mean
[14:22] <CameronP_> I havent worked out how to install it yet :(
[14:22] <spiv> garyvdm: it combines many small pack files into a single pack file, which is already beneficial in itself... for 2a there's the added benefit that having more content in one file gives better compression.
[14:23] <spiv> garyvdm: autopacking generally triggers ~10 writes to a repository (a single push would count as one write in this context, assuming there was something to push, as would a single commit).
[14:25] <spiv> garyvdm: crudely, autopacking means that by the time you've committed hundreds or thousands of times you'll still only have a few (say <20, and often <10) pack files, rather than hundreds or thousands.
[14:25] <spiv> So it's small, regular doses of pain now to avoid worse pain later :)
[14:26] <garyvdm> spiv: I see. I'm going to take a look code to see if I can hack it to make it repack less often for dumb remote transports.
[14:26] <luks> well, 1000 => 10000 is not very regular
[14:26] <spiv> CameronP_: Well, you could "bzr upload" to a local directory just as easily as to a network local.
[14:26] <spiv> garyvdm: that won't really help
[14:26] <spiv> garyvdm: in that when it finally does trigger, it'll just be much much worse.
[14:26] <spiv> Because it'll have more to do.
[14:27] <garyvdm> spiv: I push to these branch often, and then work on them on the machine that I'm pushing to locally.  It can repack when I'm on that machine...
[14:28] <garyvdm> CameronP_: Have you come right with installing bzr-upload. Maybe I can help you.
[14:28] <spiv> CameronP_: you can probably install that plugin simply by doing "bzr branch lp:bzr-upload ~/.bazaar/plugins/upload", although you may need to make the ~/.bazaar/plugins dir first.
[14:29] <CameronP_> yeah what i did was go into usr/lib/python2.4/site-packages/bzrlib/plugins/
[14:29] <CameronP_> and did a bzr branch https://launchpad.net/bzr-upload
[14:30] <CameronP_> which made an upload dir in the plugins dir
[14:30] <spiv> CameronP_: you may need to make sure its 'upload', not 'bzr-upload' in that plugins dir.
[14:31] <CameronP_> spiv: thanks that fixed it
[14:32] <CameronP_> well it got the command working
[14:32] <CameronP_> so now, this is where i get confused
[14:33] <CameronP_> im sitting in my public_html dir where i want to download to
[14:33] <CameronP_> and issuing the command bzr upload /home/xyz/repository/courses
[14:33] <spiv> I think you have the usage backwards :)
[14:33] <CameronP_> Yep
[14:33] <CameronP_> i think your right...
[14:33] <CameronP_> heh
[14:34] <CameronP_> so how does it know where to download the files to?
[14:34] <spiv> Judging from the README, you want to be in /home/xyz/repository/courses and do "bzr upload ..../public_html"
[14:34] <CameronP_> AHHHH
[14:34] <CameronP_> noob mistake, thanks a lot
[14:34] <spiv> It would probably be harder to make that mistake if the target was a network location :)
[14:35] <spiv> As most systems don't let you "cd sftp://somehost/foo" ;)
[14:35] <CameronP_> yay it worked ;) Thanks spiv
[14:37] <CameronP_> now it has that cool option of auto updating... that will be great
[14:38] <garyvdm> CameronP_: bzr upload --auto :-)
[14:52] <moldy> hi
[14:55] <CameronP_> ah dang :(
[14:55] <CameronP_> now upload has caused an error
[14:55] <CameronP_> i found a patchfor it, but it should have already been fixed in that version i downloaded yeah?
[14:55] <CameronP_> https://bugs.launchpad.net/bzr-upload/+bug/312686
[14:57] <CameronP_> he has a diff file, there is, that the same as a patch file?
[14:57] <CameronP_> so can i use like patch -p0 < xyz.diff
[15:04] <moldy> what's the recommendation for migrating an svn repo that uses svn:externals?
[15:07] <jelmer> moldy: there isn't a really good solution
[15:07] <jelmer> moldy: nested trees will provide similar functionality
[15:08] <jelmer> until then you can work around the missing functionality by using config-manager of scmproj
[15:08] <CameronP_> Well I patched it, but now getting another error, basically it looks like its returning text back to tortoisebzr
[15:08] <CameronP_> so  tortoisebzr is throwing an error
[15:09] <moldy> jelmer: well, basically i just want the data and the history, the externals can become normal directories
[15:10] <jelmer> moldy: in that case, you can just convert the containing tree to bzr
[15:10] <jelmer> and then use "bzr join" to import the external branches
[15:10] <moldy> jelmer: i'm trying :) struggling with bzr-svn right now
[15:10] <moldy> jelmer: which tool do you recommend?
[15:11] <jelmer> moldy: To import from svn ? bzr-svn
[15:11] <jelmer> moldy: Should work just the way you would use bzr itself
[15:13] <moldy>     from bzrlib.plugins.svn import format
[15:13] <moldy> ImportError: cannot import name format
[15:13] <moldy> hmmmm
[15:15] <jelmer> moldy: what version of bzr-svn are you using?
[15:15] <moldy> jelmer: 0.6.4
[15:15] <moldy> jelmer: with bzr 1.15.1
[15:19] <bebraw> how can i revert a branch to the state of the trunk?
[15:20] <jelmer> moldy: hmm, that's odd
[15:20] <moldy> 0.6.1 seems to work better, now i just need to install subvertpy
[15:20] <jelmer> moldy: 0.6.4 also needs subvertpy
[15:21] <jelmer> that could explain the other error
[15:21] <moldy> jelmer: hm, maybe
[15:21] <moldy> i don't think so, though
[15:21] <moldy> my bzrtools seems to be lacking something that 0.6.4 requries
[15:21] <jelmer> bzr-svn doesn't depend on bzrtools
[15:21] <jelmer> in any way or form
[15:22] <moldy> wait, let me check again
[15:22] <moldy> ah right, i mean bzrlib
[15:22] <moldy> from bzrlib.plugins.svn import format
[15:22] <moldy> my bzrlib.plugins has no "svn" module
[15:23] <jelmer> that's a red herring, there's something else that's failing
[15:23] <jelmer> such as subvertpy not being loadable, that's causing the svn plugin to be unloadable and thus be "msising"
[15:23] <moldy> it isn't there, i looked at it
[15:24] <moldy> find /usr/lib/python2.6/site-packages/bzrlib/ -name "*svn*" --> nothing
[15:25] <jelmer> moldy: that's not the only location searched
[15:25] <jelmer> moldy: ~/.bazaar/plugins is included as well, for example
[15:26] <moldy> huh? how does it pull that trick
[15:26] <moldy> bzrlib.plugins.__file__ is __init__.py in the above directory, and it doesn't import anything
[15:27] <bebraw> nm. bzr branch to rescue :)
[15:28] <moldy> 0.6.1 works when subvertpy is installed, 0.6.4 shows the same error as before
[15:29] <CameronP_> does anyone know how i  can get hte upload plugin to "forget" a directory in uploaded to , its saved  location is wrong
[15:34] <vila> CameronP_: --remember
[15:35] <CameronP_> thanks vila, yeah auto unfortuantely breaks it :( what a shame
[15:35] <CameronP_> tortoise bzr that is
[15:36] <vila> ?
[15:36] <CameronP_> when you have --auto on, and then you do a comit remotely, it fails as it returns stoutput back to tortise about it doing an auto update
[15:36] <CameronP_> so then it all gets broken
[15:39] <vila> CameronP_: file a bug, I don't use tbzr myself and I'm not sure I understand what you're describing, but it sounds like something that needs to be fixed
[15:40] <CameronP_> Yeah, there is a  bug open, and a guy posted a patch but it doesnt quite fix it
[15:40] <CameronP_>  https://bugs.launchpad.net/bzr-upload/+bug/312686
[15:43] <phinze> hey #bzr, trying to write a small plugin this morning... two questions: is there a nice searchable API somewhere for bzrlib or does everyone just use the HTML version
[15:44] <SamB_XP> phinze: well, ideally the HTML version would *be* searchable ;-)
[15:44] <phinze> number two, i'm trying to see if a given path has changed given a ChangeBranchTipParams... can anyone point me in the right direction as to where to look in the API
[15:44] <moldy> jelmer: ok, thank you, bzr-svn seems to work fine now... now i just need to wrap my head around bzr join :)
[15:44] <SamB_XP> I actually tend to grep the bzr source a lot, personally ...
[15:44] <phinze> SamB_XP: true... just inquiring as to what the active folks use for their reference
[15:45] <phinze> SamB_XP: i'm not averse to that :)
[15:46] <SamB_XP> anyway, I was thinking maybe it wouldn't be that hard to rig some javascript up to search the docs?
[15:46] <phinze> unfortunately i'm still such a newb to the base API that sometimes the source is not the fastest way
[15:46] <phinze> SamB_XP: true... a la rubybrain or something similar
[15:53] <CameronP_> does anyone know where bzr puts itself on install?
[15:53] <phinze> so anyways i'm making my way through Repository and such, and i think i need to first generate some sort of delta given new_revid and old_revid
[15:53] <awilkins> CameronP_: Which OS :-)
[15:53] <CameronP_> centos (rhel)
[15:54] <awilkins> CameronP_: I think bzrlib goes in the relevant site-packages
[15:54] <awilkins> CameronP_: I have a centos box under my clutches but I installed it from sources
[15:54] <CameronP_> same
[15:55] <CameronP_> i wondered where it went once installed
[15:55] <awilkins> Do a
[15:55] <awilkins> cd /
[15:55] <awilkins> find -name bzrlib    # :0
[15:55] <vila> 'bzr version ' should tell you
[15:55] <CameronP_> bzrlib
[15:55] <CameronP_> ah ic im doing a locate on bzr
[15:55] <awilkins> "bzr" is a small script that calls into bzrlib
[15:55] <CameronP_> yeah thats what im looking for
[15:55] <awilkins> It'll be inside your python stuff somewhere
[15:56] <CameronP_> so i can run it from a script
[15:56] <CameronP_> yeh...thanks
[15:57] <vila> CameronP_: 'which bzr' should tell you and then 'bzr version' will tell you all the details, also, try 'bzr plugins -v' to see what plugins are installed and where
[15:57] <phinze> ah get_revision_delta in Branch
[15:57] <phinze> there we go
[15:58] <CameronP_> thanks vila
[16:06] <phinze> hmm what's confusing me now is in the pre_change_branch_tip state, the new_revid does not exist in the branch i have reference to
[16:06] <LarstiQ> phinze: branch or repository?
[16:06] <phinze> which in a way makes sense, since it's *pre*, but i don't know how i can get a revision delta
[16:06] <phinze> ooo good call
[16:06] <phinze> doesn't exist in branch, might in repository?
[16:07] <LarstiQ> yeah
[16:07] <phinze> cool; will look in that direction, thx
[16:08] <phinze> beautiful, now we're cookin with gas ;)
[16:11] <moldy> jelmer: i succesfully converted the containing repository to bzr now. can you give me a hint on how to use bzr join to join the former svn externals? i get errors about missing working trees
[16:12] <jelmer> moldy: clone the external URLs at the places where they need to be in the tree
[16:12] <jelmer> and then run "bzr join <path>"
[16:12] <moldy> jelmer: thanks, trying that
[16:14] <moldy> jelmer: seems to work, nice. thank you (i also had to add a "bzr co" on the cloned path)
[16:16] <jelmer> moldy: if you had a treeless repo, that might indeed be necessary
[16:17] <moldy> seems to be the default for svn-import
[16:23] <jelmer> moldy: ah, yeah - that's correct
[16:23] <jelmer> moldy: newer versions will tell you though that you need to run "bzr co"
[16:24] <moldy> i see
[16:26] <jelmer> (the trees aren't automatically created since they can take up a lot of space if you have a lot of branches)
[16:26] <moldy> jelmer: can i safely delete those .bzr.retired.0 files that are created by the joins?
[16:27] <jelmer> moldy: yeah
[16:28] <moldy> ok, thanks for your help
[16:59] <tbradshaw_> Hello there, as a quick question, are "push" and "pull" symmetric?  Is it safe to use them interchangeably, or is there more to a push than there is a pull?
[17:03] <vila> tbradshaw_: they are symmetric
[17:03] <tbradshaw_> ah, that's great.  Thanks, vila. :)
[17:03] <vila> given that you switch your source and target branches when using them I mean
[17:05] <CameronP_> gnight all..
[17:05] <vila> tbradshaw_: the only edge cases where you can observe differences is regarding updating the working tree, but bzr does a good job of warning you when that occurs
[17:05] <vila> CameronP_: night
[17:05] <tbradshaw_> heh, yup, I just ran into that
[17:05] <tbradshaw_> and the documentation provide was solid
[17:05] <tbradshaw_> s/provide/provided
[17:05] <vila> CameronP_: did you file a bug regarding tbzr/upload interactions ?
[17:06] <vila> ....
[17:08] <moldy> how do i give a branch that uses a shared repo its own repo?
[17:08] <tbradshaw> I ran into a bug in bzr 1.5 (the current version in debian stable) that prevents me from pulling
[17:09] <tbradshaw> and so I had hoped to "cheat" but using the other side to push instead, where I'm using a newer version
[17:12] <moldy> ah, got it
[17:13] <moldy> hmm, no :)
[17:14] <tbradshaw> I'm up against this bug: https://bugs.launchpad.net/bzr/+bug/307091
[17:15] <tbradshaw> is there a workaround?  Could I generate one of those merge files, scp over, that directive file
[17:15] <tbradshaw> and then do it that way
[17:15] <tbradshaw> also, I had no idea I was going to trigger that bot
[17:15] <fullermd> moldy: There's an option to 'reconfigure' to do that.
[17:15] <moldy> fullermd: i can also just branch from it, right?
[17:16] <fullermd> Well, if you branch in the repo, the new branch will be using the repo too...
[17:17] <moldy> fullermd: ok, but branching from outside will work?
[17:17] <fullermd> From doesn't matter; it's to that does.
[17:18] <moldy> ok, i see
[17:18] <fullermd> I get the feeling that at least one of us is confused over what you're trying to accomplish, though.
[17:18] <moldy> fullermd: the big picture is that i am converting an svn repo, then re-organizing it
[17:19] <fullermd> What would that clal for switching a branch to using an internal repo?
[17:20] <moldy> fullermd: i want the former svn branches to turn into standalone branches now
[17:20] <fullermd> 'k, but why?
[17:21] <moldy> i don't really have any special reasons
[17:21] <moldy> disk space is not an issue, and it seems easier, less to worry about
[17:23] <fullermd> It saves IO as well as disk space, since various actions no longer need to copy stuff around.
[17:24] <fullermd> About the only thing being standalone gains you in the general case is being able to mv it arbitrarily around the filesystem.
[17:24] <moldy> which is nice, for the moment
[17:25] <moldy> i am juggling with several svn/bzr repos/branches, it's easy to get confused at the moment :) i can always setup a shared repo later if i want to
[17:27] <jelmer> moldy: try bzr reconfigure --standalone in the branches
[17:33] <moldy> jelmer: thanks
[17:51] <mthaddon> jelmer: not sure if you're aware, but there's a request from lifeless for us to upgrade PQM for bzr, but there's a new python-subunit dependency and we'd really like that in karmic before anything else (so we can backport to our repo)
[17:51] <mthaddon> jelmer: is that something you could help with?
[17:52] <jelmer> mthaddon: I can request a sync I guess, that way we'll end up with subunit in karmic
[17:52] <jelmer> That might require a freeze exception at this point though
[17:52] <jelmer> james_w: ping
[17:53] <james_w> hi jelmer
[17:56] <james_w> mthaddon: you need bzr68?
[17:57] <mthaddon> james_w: I'm not really sure what that means... :(
[17:57] <fullermd> bzr written in ALGOL 68?
[17:58] <james_w> mthaddon: you need a specific revision of python-subunit?
[17:58] <james_w> pqm depends on something in subunit revisions 67 or 68?
[17:59] <mthaddon> james_w: lifeless says in the RT that it depends on lp:~subunit/ubuntu/karmic/subunit/snapshots
[18:00] <jelmer> mthaddon: ah
[18:00] <jelmer> mthaddon: in that case you'd probably need a completely new package in Karmic since the one in Debian would be too old
[18:01] <mthaddon> jelmer: that's possible, yeah
[18:01] <james_w> jelmer: but debian is only one revision behind lp:subunit isn't it?
[18:04] <jelmer> james_w: no, 11
[18:04] <jelmer> lp:subunit is at revision 79
[18:04]  * james_w fails at subtraction
[18:05] <jelmer> base 10 ?
[18:06] <james_w> mthaddon: but yeah, we can do it but it will require a freeze exception
[18:07] <mthaddon> james_w: cool, thx
[18:08] <james_w> mthaddon: you don't want to rely on me for this though
[18:09] <mthaddon> k
[18:14] <lamont> james_w: it's universe, no?
[18:15] <james_w> it is
[18:15] <lamont> lalalalalala what freeze?
[18:15] <lamont> :-)
[18:15] <james_w> heh
[18:15] <james_w> they are free with exceptions at this point in the cycle
[18:16] <james_w> just needs someone to explain why they want it and that they have done some testing
[18:16] <lamont> I mean,  I can go make sure that -release doesn't care... I assume it has a relatively short build time?  (like prolly minutes or less on i386/amd64)?
[18:16] <james_w> probably
[18:16] <lamont> 4 minutes on ia64
[18:16] <lamont> so... you've tested it and you're happy with it?
[18:17] <james_w> I haven't looked at it
[18:18] <lamont> ah.  well, I expect _someone_ of the gang has, since it's a dep of sutff they're using all the time,...
[18:18]  * lamont goes to prod the right people
[18:21] <lamont> james_w: since lifeless is the one asking for it, I'm gonna assert that either it's good, or he's gonna fix it.  if you'll package it, I'd be happy to give it a quick blessing and upload it, or you can... ok?
[18:21] <james_w> I can upload
[18:22] <james_w> he's packaged it
[18:22] <james_w> it looks like, at least
[18:22] <lamont> thanks.  feel free to just do so.  RM slangasek said he won't kill me for shoving it that way
[18:22] <james_w> I'm just busy with other things right now, so don't want to get pulled in to this
[18:22] <lamont> ah.  so it's already packaged?
[18:22] <lamont> and if we just bzr branch from the snapshot, it should be shiny?
[18:22] <james_w> well, the branch referenced in the RT is package branch
[18:23] <lamont> \o/
[18:23] <lamont> mthaddon: you wanna play with the packaging and then I'll upload it?
[18:24] <mthaddon> erm, will give it a go
[19:00] <phinze> hmm so i'm trying to iterate on all new revisions in a pre_change_branch_tip hook
[19:00] <phinze> i've got my logic down but then realized it was only running on the last revision being pushed
[19:00] <phinze> so i was trying to do something with range(params.old_revno + 1, params.new_revno)
[19:01] <phinze> but i can't figure out how to convert each revno into a revid ... i ask the branch and it says "nope i don't have that revno just yet"
[19:01] <phinze> need revids so i can get trees/deltas
[19:01] <phinze> from the repository
[19:02] <phinze> any help much appreciated... brb for a quick mtg :)
[19:17] <beuno> Peng_, I've *just* realized that your tshirt never got shipped
[19:17] <beuno> and, doing the process again, the world-wide shop doesn't let me ship to the US
[19:17] <beuno> and the US shop doesn't have LP tshirts
[19:17] <beuno> grrrrrrrrrrrrrrrrrrrrrrrrrr
[19:55] <phinze> so i'm still working on detecting whether a given path is changed in a pre_change_branch_tip
[19:55] <phinze> i'm trying to figure out whether what i need be figuring out is how to iterate over each revision in the branch change
[19:56] <phinze> or if i need to be figuring out how to get a delta that covers the entire span of the tip change
[19:57] <phinze> i've been learning a lot from the API docs, but it's taking me a lot longer at this juncture since i don't know which direction to look in
[20:15] <Milo-> hey, I have a project that has its versions controlled with bzr, I just did few uncommit operations, and I would like to lighten my repository slightly..
[20:15] <Milo-> is there a way of removing those old packs?
[20:15] <Milo-> without breaking anything
[20:16] <Milo-> heh google was faster
[20:16] <Milo-> or not
[20:18] <phinze> Milo-: a little quiet in here today
[20:18] <phinze> check out https://bugs.launchpad.net/bzr/+bug/43753
[20:18] <Milo-> yup it is
[20:19] <phinze> looks like there's still no support as yet built in, but there's aplugin linked there
[20:19] <Milo-> I see
[20:23] <Milo-> nice, a plugin without readme :)
[20:23] <phinze> i believe the correct term is "self documenting" ;D
[20:24] <Milo-> no idea how to use that ...
[20:24]  * phinze will pull it and take a quick look
[20:24] <Milo-> it just has one __init__.py file
[20:25] <Milo-> and reading it gives me no hint at all.
[20:25] <phinze> ah, you just drop the directory into ~/.bazaar/plugins/PLUGIN_NAME/__init__.py file
[20:25] <phinze> so it looks like that path format ^^
[20:25] <phinze> assuming you're on some sort of unix variant
[20:26] <phinze> if you put it in the correct place, bazaar automatically loads it
[20:27] <phinze> and you'll get "bzr remove_revision" looks like
[20:28] <phinze> http://bazaar-vcs.org/BzrPlugins <-- for more info on bzr plugins
[20:31] <LarstiQ> phinze, Milo-: plugins are usually installed by `bzr branch plugin/url ~/.bazaar/plugins/pluginname`
[20:31] <Milo-> yes I see
[20:31] <LarstiQ> where pluginname is a valid python identifier, ie, strip the leading 'bzr-'
[20:31] <phinze> wahey - there's even a convention ;)
[20:31] <Milo-> gah, it's bzr remove-revision :) not the way phinze said it :)
[20:32]  * phinze blushes, tries in vain to cover up large NEWB letters flashing above his head :)
[20:33] <Milo-> I get error when I run that command
[20:36] <Milo-> well, can I just rm obsolete packs?
[20:37] <beuno> yes
[20:37] <beuno> I do all the time
[20:49] <twohey> I was wondering if someone here knew how to setup email notifications for pushes / commits to a master branch.
[20:49] <twohey> i'm pretty sure this is possible given https://lists.ubuntu.com/archives/bazaar-commits/
[20:50] <twohey> but my googling failed to find documentation on how to fix this
[21:01] <jam> Milo-: don't delete the directory, but you can delete the *content* of obsolete_packs
[21:01] <lifeless> moimoin
[21:02] <Goosey> bzr 1.17, "bzr help commands' encounters internal error. Fresh install. Anything I should look at?
[21:03] <lifeless> Goosey: windows?
[21:05] <Goosey> lifeless, ah yes. Windows XP
[21:05] <Goosey> installed with the standalone installer
[21:08] <jam> Goosey: upgrade to 1.17.1
[21:08] <jam> there was a bug in the packaged version of one of the plugins
[21:08] <jam> nothing serious
[21:08] <jam> just caused 'bzr help commands' to fail
[21:08] <jam> (and nothing else, IIRC0
[21:18] <Goosey> jam, sure enough. thanks
[21:25] <lifeless> twohey: hi
[21:25] <lifeless> twohey: the stuff on bazaar-commits is just done by devs installing bzr-email
[21:26] <lifeless> twohey: if you're using bzr+ssh you can do the same on a server by installing and configuing bzr-email on the server
[21:27] <twohey> lifeless: thanks.
[21:28] <twohey> is there documentation for bzr-email? I can't seem to find anything on how to set it up
[21:28] <lifeless> its a plugin, so that part is generic
[21:28] <lifeless> then bzr help email
[21:28] <twohey> should have known, thanks
[21:31] <lifeless> jam: bug 402652
[21:33] <jam> lifeless: do you have a question?
[21:34] <lifeless> jam: IIRC I reviewed it
[21:35] <lifeless> jam: was there more to do before landing?
[21:35] <jam> lifeless: is that the groupcompress sort order portion?
[21:35] <jam> That has landed in 2.0 and trunk
[21:35] <lifeless> ah. the robert is awake but confused event
[21:35] <lifeless> cool, I'm glad that that has landed
[21:49] <lifeless> ok, reviews for 2.0 done
[21:49] <lifeless> I thnk
[21:58] <lifeless> hi jam
[21:58] <jam> hey
[21:58] <lifeless> so, I've reviewed ians patch
[21:58] <lifeless> andrew is doing insert stream
[21:59] <lifeless> you and I were bouncing group combining around
[21:59] <lifeless> are you still looking at group combining, or should I pull your progress and continue? Alternatively I could do the tests for the conversion bug that I deferred
[21:59] <lifeless> or pick up the content filtering patch and work on that
[22:00] <jam> I'm still working on the group combining
[22:00] <jam> I think I have a decent heuristic
[22:00] <jam> I just need to
[22:00] <jam> 1) add tests and tie it into insert_record_stream
[22:00] <jam> 2) Check that we don't end up with issues with Remote streams
[22:00] <jam> since I think I determined that they will call insert_record_stream() 1/group
[22:00] <jam> which negates the benefit of what I'm doing
[22:00] <lifeless> I'll look at 2 for you now
[22:01] <jam> So either we need to persist a group between groups
[22:01] <jam> or combine the stream into a bigger stream
[22:01] <jam> I favor the latter
[22:05] <jam> um....
[22:05] <lifeless> jam: I'll have it done in about 10 minutes I think
[22:05] <jam> lifeless: running "bzr selftest -s bt.test_repository.Test2a.test_autopack_unchanged_chk_nodes" is taking 5.3s for me
[22:05] <jam> but if I do "--lsprof-tests" it drops to 1.3s
[22:05] <lifeless> !
[22:05] <jam> sorry, 1.8s
[22:05] <lifeless> wow
[22:05] <jam> yeah
[22:05] <lifeless> lsprof makes our code go faster.
[22:05] <lifeless> [kidding]
[22:06] <jam> lifeless: same results if I do '--lsprof-file ,,foo.txt'
[22:06] <lifeless> thats not something I saw coming
[22:06] <jam> I guess I just dropped to 3.8s, and now 1.7s
[22:06] <jam> very weird
[22:07] <jam> anyway, still 'tree.commit()' 20 times shouldn't really take that long...
[22:07] <lifeless> hmm, actually this may be trickier
[22:07] <lifeless> jam: locking is slow - are you on windows?
[22:07] <jam> yeah
[22:07] <jam> still way too long, IMO
[22:07] <lifeless> I agree; not sure how to fix it. That test does want separate packs
[22:08] <lifeless> uhm perhaps suspend_write_group+resume_write_group
[22:08] <lifeless> or
[22:08] <lifeless> memorytransport
[22:08] <lifeless> the latter I think would be better
[22:08] <jam>         tree = self.make_branch_and_memory_tree('tree', format='2a')
[22:08] <jam> 1325ms
[22:09] <jam> unless a memory tree is still backed by the real disk repo
[22:09] <lifeless> it is
[22:09] <lifeless> you need
[22:09] <lifeless> self.vfs_transport_factory = MemoryServer
[22:09] <lifeless> and then that
[22:10] <jam> 421ms
[22:10] <jam> a decent improvement
[22:10] <lifeless> better indeed
[22:10] <jam> and that includes test-suite setup overhead
[22:11] <jam> 312ms if it isn't the first test being run
[22:11] <jam> still fairly surprising given what it should actually be doing... but at least it isn't terrible now
[22:12] <lifeless> changing to TestCaseWithMemoryTransport would reduce some overhead too
[22:13] <lifeless> and further still when I fix bzrlib.config to not write to disk, and bzrlib.bzrdir.clone to not search unconditionally for repository policies (which is a reason we have to have the fake containing dir on disk)
[22:14] <lifeless> netbeans export at 118K/133K
[22:14] <lifeless> 103G
[22:15] <jam> ouch
[22:15] <lifeless> it will be _very_ interesting to see what bzr makes of this tree
[22:16] <lifeless> I'm hoping it will be an eat-their-lunch event
[22:16] <lifeless> either way we'll learn something
[22:16] <lifeless> hmm, this needs an object.
[22:16] <lifeless> refactorating
[22:17] <lifeless> ok: for remote streams
[22:17] <lifeless> I'm on it.
[22:18] <lifeless> no direct tests, and its going to need them now; I'm going to write one small test for this specific case, refactor, and push a branch for you to merge into your work.
[22:18] <lifeless> First though, I need a drink, bit dehydrated
[22:18] <jam> k
[23:05] <lvh> hi!
[23:06] <lvh> I'm wondering what the canonical (no pun intended ;-)) way of doing this in bzr is. Suppose I have a branch of a project, with commits A -> B -> X -> Y, up to B is pushed to launchpad
[23:06] <lvh> someone did a code review of B, and X, Y is the start of a bunch of new functionality
[23:06] <lvh> so, I guess moving X, Y into a new branch would make sense
[23:07] <lvh> lifeless helped with this, this command: bzr branch . ../positioning-gpsd; bzr pull . --overwrite -r -6
[23:07] <lvh> now, once I fix the things the review hinted at in the main branch I would like to have these changes also be done in the new functionality branch, of course
[23:07] <lvh> in git, i would do this with rebase
[23:07] <lvh> how do i do this in bzr?
[23:07] <lifeless> cd new branch
[23:07] <lifeless> bzr merge old branch
[23:07] <lifeless> [review]
[23:08] <lifeless> bzr commit
[23:08] <fullermd> That sounds like a pretty roundabout way of doing bzr branch -r-6 . ../p-g
[23:08] <lifeless> fullermd: no, its kindof the reverse
[23:09] <lvh> lifeless: wait, merge the old branch from the new branch?
[23:09] <fullermd> It huh?
[23:09] <lvh> I do actually do this, right: bzr branch . ../positioning-gpsd; bzr pull . --overwrite -r -6
[23:09] <fullermd> It's the same thing, just directly expressing what's being done instead of backing and filling..
[23:09] <lifeless> lvh: you want the reviewed changed from the older branch in the newer branch ?
[23:10] <lvh> lifeless: Ah, I was thinking of not having two separate branches anymore, but yeah I gues sthat makes sense too
[23:10] <lvh> eg have the branch just be a temporary container for commits
[23:10] <lvh> but your way makes more sense, never mind :-)
[23:10] <lvh> lifeless: thanks again!
[23:10] <lifeless> fullermd: it is, except that the branch dirs are reversed the other way, which, when you're thiking abuot a problem a specific way is confusing.
[23:11] <fullermd> lvh: Well, once you merge, you _do_ just have one branch  :)
[23:11] <lifeless> fullermd: Feeling philospohical today?
[23:11] <fullermd> lifeless: Oh, I overread the 'cd' in the middle.
[23:11] <lvh> fullermd: the old branch disappears?
[23:11] <poolie> hello all
[23:11] <lifeless> lvh: no, it doesn't.
[23:11] <lvh> or two directories in the same state
[23:12] <lvh> plus or minus a few branch specific commits
[23:12] <fullermd> It _can_, since you have all its revs.  Unless you need to keep it aroudn for somethign else.
[23:12] <lifeless> lvh: the old branch is untouched. the new branch has the changes you made in old merged into it,
[23:12] <lifeless> lvh: so the old branch isn't needed at that point, thats all that fullermd is saying, I think.
[23:12] <lifeless> hi poolie
[23:13] <lvh> oh, right
[23:13] <fullermd> I'm always feeling philosophically.  It's just usually not very cogent or meaningful  :p
[23:13] <lvh> thats okay, I have a quickly learning heuristic filter
[23:13] <lvh> (if lifeless: pay attention else: ignore)
[23:14] <fullermd> Excellent.  We always need more quick learners   8-}
[23:26] <lifeless> jam: done
[23:29] <lifeless> mm
[23:29] <poolie> hello jam
[23:29] <lifeless> bzr push ../foo with uncommitted changes in . pushed those changes to ../foo as uncommitted there ><
[23:29] <lifeless> surprising
[23:30] <lifeless> jam: lp:~lifeless/bzr/adjacent-streams - merge that
[23:30] <lifeless> poolie: james_w rebuilt the debs last night.
[23:30] <lifeless> poolie: I haven't manually confirmed they are green yet, but they should be.
[23:34] <poolie> that's great
[23:34] <bialix> vila: are you still here?
[23:35] <vila> no :)
[23:35] <vila> bialix: Won't stay long, but I'm listening to you
[23:36] <bialix> config.py AuthenticationConfig
[23:36] <bialix> get_user and get_password
[23:36] <bialix> which transport can trigger them?
[23:36] <vila> all
[23:36] <bialix> we have bug in qbzr, re bzr-svn
[23:37] <bialix> jelmer insist bzr-svn uses these methods
[23:37] <vila> ach, bzr-svn :-/
[23:37] <bialix> I'd like to test my bug fix w/o svn
[23:37] <bialix> so, bzr+ssh?
[23:37] <bialix> or sftp?
[23:37] <vila> what do you mean by 'jelmer insist' ?
[23:38] <bialix> wait a sec, I'll show bug number to ubottu
[23:38] <vila> all transports can potentially make use of auth.conf, that's less useful for ssh because there are better solutions there (ssh agents and .ssh/config)
[23:38] <bialix> https://bugs.launchpad.net/qbzr/+bug/418252
[23:39]  * bialix waves to emmajane
[23:39]  * emmajane waves to bialix 
[23:40] <bialix> I like design #2, but I've already wrote this
[23:40] <bialix> vila: paramiko as ssh agent can use auth.conf
[23:41] <bialix> err
[23:41] <bialix> vila: paramiko as ssh client
[23:41] <vila> yes
[23:41]  * vila reading the bug report
[23:41] <bialix> so, which transport will trigget get_user?
[23:41] <vila> any transport can
[23:42] <emmajane> bialix, excellent :)
[23:42] <vila> so you can test with whatever is easier for you
[23:43] <bialix> vila: for local testing I'd prefer stick to sftp/ssh
[23:43] <vila> there shouldn't be any difference from bzr-svn if I read jelmer comments correctly
[23:44] <vila> so, if you can get get_user/get_password called from the command line, the same should occur from tbzr
[23:44] <bialix> vila: I have fuzzy feeling that sftp/ssh transport deduce user name somehow
[23:44] <bialix> vila: this is my question actually: how can I force get_user ask
[23:44] <vila> things have changed in this area... but I can't point to when exactly
[23:45] <bialix> I can use ftp
[23:45] <vila> you can force get_pasword by connecting to a host where your key is not authorized or temporarily rename your key to force a password check...
[23:45] <vila> ftp is simpler :-)
[23:45] <bialix> get_password is not problem
[23:46] <bialix> qbzr lacks get_user implementation
[23:46] <bialix> I don;t remember I ever seen prompt for user name with bzr CLI
[23:46] <vila> bialix: just look at the bzrlib tests then ! get_user is tested almost like get_password
[23:47] <vila> bialix: We didn't have get_user for a very long time because it's very rarely used, I think we first need it for an http server
[23:50] <poolie> lifeless: jam says he's finished working for the day, so if you want to take over that would be good
[23:50] <poolie> don't wait to hear back from him
[23:50] <lifeless> heh, chinese whispers
[23:50] <lifeless> ok
[23:50] <lifeless> he says its just tests and glue
[23:50] <lifeless> I'll start with glue.
[23:51] <bialix> vila: test_config tests very low level API
[23:52] <bialix> vila: I can't test with http, heh, have to find some open svn repo to test this
[23:53] <vila> bialix: test_ui not test_config
[23:54] <bialix> test_ui?
[23:55] <vila> bzrlib/tests/test_ui.py contains test for get_username
[23:56] <bialix> yes, but it's low level too
[23:57] <bialix> ok, vila, perhaps we both need to go offline till tomorrow
[23:57] <vila> what's wrong with low level tests ? You want low level tests for your qbzr implementation right ?
[23:57] <vila> bialix: yeah, good idea :)
[23:57] <bialix> no, I want high level
[23:57] <bialix> manual test with real access to real branch
[23:58] <bialix> heh
[23:58] <bialix> gnight vila
[23:58] <bialix> :-)
[23:58] <vila> bialix: let's talk about that tomorrow then :) The problem with manual tests is that... you pay in blood every time you run them :)
[23:58]  * bialix waves
[23:58] <bialix> tomorrow
[23:59] <bialix> pay in blood? scary
[23:59]  * bialix finally disappear