[00:09] <spiv> igc: want to take a second look at https://code.edge.launchpad.net/~patrick-regan/bzr/lp-quicktutorial/+merge/15073?  I think it looks good now.
[00:12] <igc> spiv: done
[00:16] <spiv> igc: thanks!
[00:33] <lifeless> spiv: I have a suggestion for pqm-submit
[00:33] <lifeless> spiv: let it take a lp merge request url.
[00:35] <spiv> lifeless: +1
[01:37] <poolie> lifeless: any comments on bug 488544
[01:49] <lifeless> poolie: yes, commented.
[01:49] <poolie> heh
[01:50] <poolie> expected you to say "yes, that bug has comments" :-)
[01:50] <lifeless> I'm not quite that harsh:)
[03:21]  * igc lunch
[03:45] <Peng> Heh, I made push default to --no-strict, and it just bit me. :D
[03:57] <mwhudson> bzr alias oops='merge --uncommitted ../trunk'
[03:58] <mwhudson> getting bzr revert ../trunk in there would also be good
[04:03] <lifeless> mwhudson: this is another reason to use a single checkout :)
[04:04] <mwhudson> yes, i guess that's true
[04:04] <mwhudson> lifeless: do you prefer merge proposals to already have NEWS in them, or is best to add that at the last minute, given the potential for conflicts?
[04:06] <lifeless> the former
[04:11]  * mwhudson proposes a merge
[04:15] <lifeless> poolie: I have a suggestion for your lp scripts
[04:15] <poolie> mwhudson: you can always resolve it later
[04:15] <poolie> ok
[04:15] <lifeless> poolie: 'add an approve for folk in the bzr team'
[04:15] <lifeless> so that e.g. your proposals show up with 1 approval by default, once the script runs.
[04:15] <poolie> non-canonical people in ~bzr?
[04:16] <poolie> hm, i might be confused
[04:16] <poolie> which script?
[04:16] <lifeless> well you're writing lpapi scripts to help bzr get more out of lp, right?
[04:16] <poolie> ok, this is a new but similar script?
[04:16] <lifeless> yes
[04:16] <poolie> interesting
[04:16] <lifeless> thats the policy we still have that LP doesn't know about.
[04:17] <poolie> alternatively the robot could just complain about things that have had N reviews but not changed status
[04:17] <lifeless> thats also interesting to do, and different.
[04:17] <lifeless> so I wouldn't say its an alternative.
[04:18] <poolie> would just adding those votes really add value?
[04:19] <lifeless> poolie: I think so. At the moment I have to read two columns: author and votes.
[04:20] <lifeless> if I knew that proposals from committers would have the committers vote present in the votes column,I could scan faster.
[04:21] <poolie> hm
[04:21] <poolie> i'll think about it
[04:21] <poolie> you can prototype this by manually voting +1 on your own things
[04:21] <lifeless> its only a suggestion ;)
[04:21] <lifeless> hmm, the script would have to run as 'root-alike' I guess.
[04:21] <lifeless> because it would want to impersonate the committer.
[04:22] <lifeless> thumper: ^ would be nice to be able to do the above experiment.
[04:23] <mwhudson> lifeless: thanks for the review
[04:32] <poolie> lifeless: quick call?
[04:32] <lifeless> sure
[04:49] <bialix> hello all
[04:57] <Peng> Hi. :)
[05:26] <lifeless> poolie: btw https://code.edge.launchpad.net/~lifeless/testtools/0.9.1/+merge/15256
[05:42] <lifeless> poolie: thanks for the review.
[05:42] <poolie> thanks for doing it
[05:42] <lifeless> poolie: I think I was more saying 'this is the outcome'
[05:43] <lifeless> do you think its more tasteful like this?
[05:43] <poolie> i do
[05:43] <lifeless> cool
[05:43] <poolie> i think it's less likely to lead to that kind of failure
[05:43] <poolie> i guess we can see if jml agrees
[05:44] <lifeless> I discussed doing a point release with him before doing the change.
[05:44] <lifeless> I'm confident he won't object to the content of the change.
[06:35] <poolie> lifeless: do you have any ideas about https://bugs.edge.launchpad.net/ubuntu/+source/devscripts/+bug/434987
[06:35] <poolie> ideally, a way to work around it
[07:28] <vila> hi all !
[07:30] <fullermd> Whoop, that must mean it's time for me to go   :p
[07:32] <vila> hehe, enjoy your night fullermd :)
[07:33] <fullermd> Oh, it's hardly night, not for many many hours yet...
[07:33] <fullermd> I just got through my post-breakfast stuff.
[07:33] <vila> oooh, you meant go *to* work, sorry for the misunderstanding
[07:44] <poolie> hi vila
[07:46] <vila> hey :)
[07:54] <poolie> vila, so how about if you add the comments for shelve-no-tty and merge it?
[07:55] <vila> poolie: fair enough, I'll do that (<- spiv)
[08:31] <igc> ping jml, spiv
[08:31] <igc> jml, spiv: can we get the emacs mirror on LP updated?
[08:32] <igc> see https://code.edge.launchpad.net/~vcs-imports/emacs/trunk
[08:32] <igc> the new url is http://bzr.savannah.gnu.org/r/emacs/trunk/
[08:32] <jml> igc, what should it be updated to?
[08:32] <igc> jml: how would I change that?
[08:32] <igc> jml: do I need to join some team?
[08:33] <igc> to get permission?
[08:33] <jml> igc, you need to be in ~vcs-imports. I've changed it.
[08:33]  * jml is not here
[08:37] <igc> jml who is not there, can you re-enable that import too? It says Next mirror: Disabled
[08:38] <jml> igc, I have re-enabled it.
[08:39] <jml> but then it gets disabled again very quickly
[08:39] <jml> something is fishfy
[08:39] <jml> fishy
[08:45] <mwhudson> wtf
[08:45] <mwhudson> why
[08:45] <mwhudson> is that owned by ~vcs-imports?
[08:45] <MvG> Hi! While it's still some time off, I'm starting to think about trac-bzr 0.3.x releases. Have just registered a series in lp.
[08:46] <mwhudson> (it doesn't seem like it is an import branch though)
[08:46] <MvG> Now I wonder: should there be beta milestones before the official releases? Would there be enough of a user base to get actual beta-testing done?
[08:46] <MvG> Or would simply asking people around here to give latest checkouts a try be enough of a test so I could simply start with 0.3.0?
[08:47] <bialix> MvG: hi, are you about trac-bzr?
[08:47] <MvG> bialix: Yes.
[08:48] <bialix> given in mind there was no release at all in the past, I'd say you can just cut tarball and move forward.
[08:48] <bialix> i.e. do release, or don't
[08:48] <bialix> beta is overkill right now
[08:49] <MvG> Glad you think so. Will certainly serve me a lot of worries.
[08:51] <bialix> those who used trac-bzr already used to use trunk
[08:51] <bialix> (how's bad I said :-/)
[08:52] <jml> mwhudson, I might have changed the owner way back when
[08:52] <jml> mwhudson, a more interesting question to me is, "why does it apparently retry and then still fail with an error message referring to the old branch location"
[08:53] <mwhudson> jml: yeah, that's a bit odd
[08:56]  * jml drinks something awesome that rhymes with "banoffee"
[08:58] <jml> mwhudson, I'm torn between investigating it, and not.
[09:09] <poolie> hi jml
[09:09] <mwhudson> jml: https://code.edge.launchpad.net/~vcs-imports/emacs/trunk seems happier now
[09:10] <mwhudson> not happy
[09:10] <mwhudson> just happier
[09:10] <jml> mwhudson, looks happyish
[09:10] <mwhudson> let's leave it for 6 hours and see what happens :-)
[09:11] <mwhudson> or kill it and start again
[09:11] <jml> mwhudson, the dates on the 'recent revision' thing seem a little off :)
[09:11] <mwhudson> yeah
[09:12] <jml> (weird, years used to begin with a 1 and no one cared)
[09:12] <jml> poolie, hi
[09:14] <mwhudson> jml: loggerhead seems to have a more plausible idea of the revisions
[09:14] <mwhudson> i wonder if it's choking the scanner
[09:15] <jml> poolie, fwiw, I think that food prepared from _Lobscouse and Spotted Dog_ makes more sense over here.
[09:16] <jml> mwhudson, I'll bet its choking the scanner.
[09:16] <jml> it's
[09:18] <poolie> jml, i bet
[09:47] <lifeless> poolie: re: devscripts, not offhand, let me have a look
[09:47] <poolie> nm
[09:47] <poolie> i'm sending a mail summarizing where i got up to
[09:51] <lifeless> anyhow, I'd be using schroot fwiw
[09:55] <jml> lp devscripts?
[10:38]  * bialix hates to get random errors in the tests with sftp testing server like this: PermissionDenied: Permission denied: "lock/held": [Errno 13] Permission denied
[10:43] <kostja_osipov> Hello
[10:44] <kostja_osipov> could somebody help me with bzr gannotate?
[10:44] <kostja_osipov> what I actually need is to find out the revision id of a changeset that deletes lines
[10:45] <kostja_osipov> since the lines are not in annotate output, I can't find the revision
[10:45] <kostja_osipov> what is the procedure for that in bzr?
[10:45] <bialix> I'm doubt there is simple way to find deleted lines
[10:45] <bialix> they are deleted
[10:45] <bialix> maybe hgrep plugin will help?
[10:45] <bialix> or log -p?
[10:46] <kostja_osipov> oh well... there of course is. you scroll back in the revision history, till you find the changeset that still has the lines
[10:46] <kostja_osipov> the next changeset removes them
[10:46] <kostja_osipov> but it can be quite tedious
[10:46] <bialix> I won't call this way "simple"
[10:46] <kostja_osipov> would be nice if I could see all revisions in a file  on a time line so that I could do binary search on it
[10:47] <bialix> you're need weave representation it seems
[10:47] <bialix> you may want to ask jam when he'll be here
[11:17] <vila> kostja_osipov: bzr qannotate provides the per-file graph, i.e. displays all the revisions that modify a file one way or another
[11:21] <lifeless> gnight
[11:26] <bialix> vila: it's not quite true: this graph is sorted and represents only revisions which modified lines in currently annotated version. but if you go back in history and annotate older versions you'll get more graph
[11:27] <bialix> bonjour vila, btw :-)
[11:27] <vila> bialix: hi !
[11:27] <vila> bialix: you're right, I keep forgetting the difference :-(
[11:28] <vila> bialix: I should really talk to garry about *not* using that graph but presenting the real per-file graph instead, I'm pretty sure the performance penalty will be lost in the noise
[11:28] <bialix> vila: sometimes I have the same needs as kostja_osipov, I'm still not found easy way to bisect this
[11:29] <bialix> vila: you can, but actually this feature done not from performance point of view
[11:29] <bialix> I guess it's intended
[11:30] <bialix> but as we see, sometimes this approach has flaws
[11:30] <bialix> file a bug!
[11:30] <bialix> please
[12:03] <jml> hello
[12:03] <stanman246> lol
[12:04] <stanman246> sometimes i work on a project with someone else. Now i'd like to do some kind of version control, he's been looking into bzr already.
[12:05] <stanman246> It's a webbased project (cakephp) and we're working on the same files every now and then, can this be controlled with bzr?
[12:06] <jml> yes
[12:06] <jml> in a variety of ways
[12:06] <stanman246> ok, will need to go into some tuts i guess
[12:07] <jml> probably.
[12:07] <jml> stanman246, have you used a version control tool before?
[12:07] <stanman246> no
[12:09] <jml> stanman246, the big difference from just editing files is that rather than just hitting "save", you can group changes together in a single "commit", which generally also has a short description of the change
[12:09] <stanman246> come across Git, hows that?
[12:09] <jml> stanman246, roughly speaking it has feature parity with Bazaar. I find it's UI more complex and less helpful.
[12:10] <stanman246> jml: yes, so i saw
[12:10] <stanman246> ah
[12:10] <stanman246> but... bzr is working with .bzr folders locally right?
[12:10] <jml> stanman246, yes, kind of, but that seems an odd question to ask.
[12:11] <stanman246> really need to tut first, before asking, sry
[12:11] <jml> stanman246, are you and your colleague editing PHP files on the web server itself?
[12:11] <stanman246> not at first
[12:12] <jml> stanman246, ok.
[12:12] <jml> that's good :)
[12:12] <stanman246> we used to use winscp to get the files, edit them and then up them
[12:13] <stanman246> but with bzr we could edit the files on the server right?
[12:13] <stanman246> I don't feel really comfy with that thos
[12:14] <jml> it's not a good way of doing things.
[12:14] <jml> VCS makes it slightly easier to separate changing the code from doing a release, IMO.
[12:14] <jml> and changing files onto the webserver in the web area is basically doing a release
[12:16] <jml> anyway, here's what I'd do to start with:
[12:17] <jml> make a copy of your code.
[12:17] <stanman246> local
[12:17] <stanman246> right
[12:17] <stanman246> ?
[12:17] <jml> for now, anywhere.
[12:18] <jml> just make sure you have a copy in case everything goes horribly wrong
[12:18] <jml> but also have a copy that you can change into and run 'bzr init' then 'bzr add' and then 'bzr commit'
[12:19] <jml> this makes a branch that you can play with
[12:20] <jml> if you put that branch onto the server (either by copying it or running 'bzr push' or something) then you can either check it out ('bzr checkout') or branch it ('bzr branch')
[12:49] <kostja_osipov> vila: thanks, I actually used bzr log -p and was able to dig up the changeset i need
[12:49] <vila> kostja_osipov: cool, did you succeed with your cherry-picks yesterday ?
[12:50] <kostja_osipov> vila: i'm still in progress.
[12:50] <kostja_osipov> I am reapplying the first patch in a series, and it touches 40 files and each file has conflicts.
[12:50] <kostja_osipov> our problem yesterday was a bit of a bit larger puzzle :)
[12:51] <vila> hmm, so you're back to doing the *first* merge without using patch -p0 ?
[13:13] <yuval> hey all, I'm seeing the error "not installing http[s]+webdav:// support (only supported for bzr 1.12 and above)" on every command i run. any ideas why this is happening and how to fix? running bzr 2.0.0
[13:17] <marek_> hi i have a question
[13:17] <marek_> i have two repos one or locally connected server
[13:17] <marek_> and other on my local host
[13:18] <bialix> maxb: ping
[13:19] <maxb> pong
[13:20] <bialix> maxb: do you remember your patch for qlog to preserve leading spaces?
[13:20] <maxb> yes
[13:20] <marek_> and the problem is:
[13:20] <bialix> does it still work for you with latest qbzr trunk?
[13:20] <marek_> i first branched from server to my localhost
[13:20] <marek_> than edited few files
[13:20] <marek_> then comited locally
[13:21] <bialix> maxb: when I've merged your patch I've added the test. Now this test started to fail
[13:21] <maxb> bialix: oh. no, it doesn't
[13:21] <marek_> and i can see status "unknown" in olive ide... do you know what does that mean?
[13:21] <bialix> maxb: you've asked me why I want test for such small thing. that is.
[13:21] <maxb> bialix: Your point is proven! :-)
[13:21] <bialix> can we pair to fix it?
[13:22] <maxb> I need to grab lunch now. I will look at it in a few hours
[13:22] <bialix> ok, ping me when you'll have a time
[13:23] <bialix> marek_: any reason to not use bzr-explorer?
[13:24] <marek_> no reasons
[13:24] <marek_> :)
[13:25] <bialix> marek_: I don't see a log of your questions but I can help with explorer, not with olive
[13:28] <bialix> maxb: when you'll back: here is my branch with updated test: lp:~bialix/qbzr/htmlize-nbsp
[13:46] <MvG> To anyone interested in trac-bzr: I've got 7 propesed merges waiting for review at https://code.launchpad.net/~trac-bzr-team/trac-bzr/trunk/+merges . I'd be glad if at least some of them would have a second pair of eyes looking at them before I commit them to trunk. Thanks!
[13:48] <MvG> abentley, mzz: of course past contributors are particularly likely candidates for such reviews, so if you can spare the time...
[13:49] <abentley> MvG: sorry, but I have no interest in trac-bzr anymore.
[13:50] <MvG> abentley: all right, noted. Won't bother you with this in the future.
[13:54] <bialix> maxb: I found the root of problem, but the fix is not so trivial...
[14:05] <bialix> maxb: fixed and pushed to trunk2a. testing are welcome
[14:06] <stanman246> hi, i've got ubuntu 9.04 running and installed bzr
[14:07] <stanman246> but the version is 1.13.1 and my colleague has the repository set up on v 2.0, can i upgrade my bzr version?
[14:11] <vila> stanman246: you can use the bzr PPA
[14:11] <maxb> stanman246: There is a bzr PPA that carries the latest released version of bzr, bzrtools and a few other things
[14:12] <vila> stanman246: https://launchpad.net/~bzr/+archive
[14:12] <vila> stanman246: or you can upgrade to 9.10 :)
[14:16] <stanman246> haha
[14:16] <stanman246> thinking of that...
[14:16] <chx> hey, 9.10 is awesome
[14:16] <vila> the later is a couple of clicks away while the former requires a bit more work :)
[14:16] <chx> it drives my T400s just fine
[14:17] <chx> I think the only feature of the laptop that does not work is the "silence the mic" button
[14:17] <chx> but i bet i could make that work too if i would care :)
[14:23] <stanman246> hmm... on my hp 6720s 9.10 didn't work with compiz..
[14:23] <stanman246> just did the ppa upgrade to 2.0.2!
[14:27] <stanman246> ok, now i'm gonna read some! Thanks for the info!
[14:57] <MvG> bialix: Are you still working on https://bugs.launchpad.net/trac-bzr/+bug/327508 as that report is assigned to you?
[14:58] <bialix> MvG: oh, no sorry, I'm not
[14:58] <MvG> bialix: I guess I'll then reasissign to nobody.
[14:58] <beuno> vila, email2blog: http://beuno.com.ar/archives/168
[14:58] <bialix> yes, please
[14:59] <bialix> MvG: too bad for me, I was too busy since 2009/03 until now
[14:59] <vila> beuno: hehe
[15:01] <bialix> push --no-strict :-P
[15:01] <bialix> bzr upload-files FILES --no-strict :-P :-P
[15:01] <beuno> bzr upload-files --jfdi?
[15:03] <bialix> --jdi? perhaps
[15:03] <bialix> oh, got it
[15:05] <beuno> :)
[15:05] <beuno> it's the ruder version
[15:08] <vila> And the subliminal message is: vila,  http://beuno.com.ar/archives/168, now, jdfi
[15:08] <vila> :-D
[15:09] <beuno> vila, I'm glad that got through  ;)
[15:09] <vila> ha ha ha
[15:58] <MvG> bzr clone lp:~rocky-burt/trac-bzr/bug-263300 fails for me. Seems that the launchpad bzr server for some reason isn't happy:
[15:58] <MvG> bzr: ERROR: bzrlib.errors.ErrorFromSmartServer: Error received from smart server: ('error', "Absent factory for ('TREE_ROOT', 'bialix@ukr.net-20090118015300-t997i4a3wn3jjpr2')")
[15:58] <MvG> Any ideas? Is this a launchpad issue or a bzr issue?
[16:03] <bialix> vila: Bug #488824
[16:04] <vila> bialix: lp:~bialix/bzr/shelve-no-tty make the test suite fail :-/
[16:04] <bialix> details?
[16:04] <bialix> shelve --all / shelve --list ?
[16:05] <vila> blackbox.test_shelve.TestShelveRelpath.test_shelve_in_subdir blackbox.test_shelve.TestShelveList.test_shelve_destroy
[16:05]  * bialix looks
[16:05] <vila> it took me a while to notice because pqm send me a truncated mail for the first failure and I didn't notice the mail at first either
[16:06] <bialix> shelve --all
[16:06] <bialix> so....
[16:06] <bialix> vila, I think plan B then
[16:07] <vila> hmm, weird, pqm fails for the second one only while both fail here..
[16:07] <vila> what is plan B /
[16:07] <vila> what is plan B ?
[16:07] <vila> oh and thanks for filing that bug, I went to lunch and forgot :-/
[16:08] <bialix> you reject my patch and I provide new patch which will check tty presence in osutils around lines     def getchar(): return msvcrt.getch()
[16:08] <bialix> vila: shame on you
[16:09] <bialix> but lunch is the most important, so ok
[16:09] <bialix> vila: but I'll need your help for testing linux-specific getchar()
[16:09] <vila> hmm, I don't think that will work, there are cases where we want to read from stdin being a file and that's a valid use case
[16:09] <bialix> msvcrt.getchar() never read from stdin
[16:10] <bialix> this is direct access to keyboard buffer
[16:10] <vila> but it's windows specific
[16:10] <bialix> so what?
[16:10] <bialix> this is the root of my problem and why this patch is created
[16:10] <vila> so that doesn't match the cover letter of your patch that wasn't windows specific
[16:11] <bialix> vila: because I have no way to test shelve in qrun on non-windows
[16:11] <bialix> can you?
[16:11] <bialix> anybody?
[16:11]  * bialix screams: HEEELP
[16:12] <bialix> vila: osutils.py around line 1900
[16:13]  * bialix has no idea how linux part works, tty and termios not his area of expert
[16:14]  * bialix trying to prepare non-qt test
[16:15] <vila> bialix: how about transfering your patch to shelf_ui.Shelver.prompt instead ?
[16:16] <vila> so you don't have to check at two different places... or in getchar() but making the os specific versions pushed down to _getchar() ?
[16:16] <bialix> this is possible
[16:17] <bialix> I'm clearly get lost in shelf_ui
[16:17] <bialix> usage of sys.stdout makes me nervous
[16:17] <vila> getchar() is used only prompt() but it seems to require a real terminal anyway
[16:17] <vila> hi GaryvdM
[16:18] <bialix> privet Gary
[16:18] <bialix> that means hi
[16:18] <GaryvdM> Hi bialix, vila
[16:18] <bialix> hi GaryvdM
[16:18] <bialix> vila: your chance to say about log in annotate!
[16:18] <vila> hehe
[16:19] <bialix> joke
[16:19] <bialix> I've just stumbled with it myself
[16:19] <vila> GaryvdM: bialix just filed bug #488824 about qblame not using a true per-file graph
[16:19] <vila> GaryvdM: can you remind me why ?
[16:20] <bialix> vila: so ok, I'm agree moving my tty check to prompt
[16:20] <vila> err, I mean
[16:20] <GaryvdM> vila: Performance
[16:20] <bialix> vila: so I need resubmit or you reject or how?
[16:20] <GaryvdM> vila: maybe have a right click - "Show all revisions that change this file" option
[16:20] <bialix> GaryvdM: I'm agree to have knob
[16:20] <vila> bialix: just pushing the change to your branch should be enough
[16:21] <GaryvdM> bialix: knob?
[16:21] <GaryvdM> I want a plugin that has a  pre_change_branch_tip hook, that I configure to run a test suit before I push to a specified location
[16:21] <GaryvdM> That will be like a mini pqm that I can use for qbzr
[16:21] <vila> GaryvdM: that shouldn't be a perf problem, we do that for bzr log FILE by finding the relevant keys in the index
[16:21] <bialix> GaryvdM: checkbox
[16:22] <GaryvdM> vila: Yes - but it is still slower than just taking the list of revisions from the annotate
[16:22] <GaryvdM> bialix: ok - I see
[16:22] <bialix> GaryvdM: or context menu -- does not matter
[16:22] <bialix> GaryvdM: hook? I can do it
[16:23] <vila> GaryvdM: hmm, faster but incorrect :-) It will be nice if you could do it in the background after displaying the first page :-D
[16:23] <GaryvdM> Does such a plugin exist, or should I write one from scratch?
[16:24] <bialix> GaryvdM: it would be pretty trivial
[16:24] <bialix> vila: can I ask about tree.is_ignored?
[16:24] <GaryvdM> vila: Yes - I can do it after the annotate has been shown.
[16:25] <vila> But I'm still a bit surprised that querying the index only makes such a difference compared to the annotation time... anyway, you know better, but we had a use case this morning that your current implementation doesn't help (I thought it was):
[16:25] <bialix> it was afternoon
[16:25] <vila> searching for deleted lines can be done only if all revisions are displayed in the graph
[16:25] <GaryvdM> vila: yes
[16:25] <vila> bialix: before my lunch is morning :-)
[16:26] <vila> bialix: even if I take it at seven PM :D
[16:26] <bialix> yep, I'm a bit distracted
[16:26] <bialix> :-D
[16:26] <bialix> LOL
[16:26] <vila> bialix: what about trees.is_ignored ?
[16:28] <bialix> I think the name is awfully misleading
[16:28] <bialix> so I think is it worth to starting patch or just forget
[16:28] <bialix> this method does not check is file actually ignored
[16:29] <bialix> it returns matching ignore pattern only
[16:29] <vila> that's what the docstring says
[16:30] <bialix> so if file versioned but matches ignore pattern -- this function name is wrong
[16:30] <vila> >-/
[16:30] <bialix> docstring said: Check whether the filename is ignored by this tree.
[16:30] <vila> What will be a better name ?
[16:30] <bialix> this is not true
[16:30] <vila> bialix: look at the workingtree one
[16:30] <bialix> better name: something about ignore pattern
[16:31] <vila> Check whether the filename matches an ignore pattern.
[16:31] <bialix> ECONFLICT
[16:31] <bialix> but anyway, my point still valid
[16:32] <bialix> function name is not correct
[16:32] <bialix> it's counterintuitive for API users (QBzr)
[16:32] <bialix> I've just yesterday fixed serious bug because of this
[16:32] <vila> I don't follow. What are you searching for ?
[16:33] <vila> There is no such thing as an ignored file. If you want to be pedantic you should say: will that file be ignored if I try to add it *now*.
[16:34] <vila> That's what wt.is_ignored() answers
[16:35] <GaryvdM> vila: we understood it to be "is this file ignored"
[16:35] <vila> Hmm, not even
[16:35] <vila> But what does that mean ?
[16:36] <gioele> wt.would_be_ignored() vs wt.is_being_ignored() maybe?
[16:36] <GaryvdM> vila: The bug fix that bialix was taking about = "is_ignored = not versioned and tree.is_ingored()"
[16:37] <GaryvdM> gioele: yes
[16:38] <bialix> vila: WorkingTree subclass MutabkeTree which in turn subclass tree.Tree
[16:38] <bialix> tree.Tree is therefore defined interface IIUC
[16:38] <bialix> and interface in tree.Tree said that is_ignored checks is file actually ignored
[16:39] <bialix> I suppose somewhere along the road original meaning has lost
[16:39] <bialix> and now is_ignored means is_matches_ignore_pattern
[16:39] <vila> Sounds right
[16:39] <bialix> so to remove confusion in weak minds like mine and I have proposal to change method name
[16:40] <vila> bialix: good, you understand that means taking care about deprecating the old name right ?
[16:40] <bialix> yes,
[16:41] <bialix> that's why I'm trying to talk with some of core devs first
[16:41] <bialix> IIUC such change is too big for 2.1.0rc
[16:41] <bialix> so better to make it after 2.1.0 gone glod
[16:42] <bialix> right?
[16:42] <vila> That's for the 2.1 RM to decide, don't worry too much about it, that's why we have deprecations for
[16:43] <bialix> this function is very heavily used
[16:43] <bialix> and not only inside bzrlib
[16:43] <bialix> but and by 3rd party tools, I guess
[16:43] <bialix> at least in QBzr definitely
[16:44] <bialix> I will worry too much
[16:44] <vila> Then maybe only the doc should be fixed ?
[16:44] <bialix> mmmm, no. all or nothing
[16:45] <bialix> the name is misleading in my humble opinion
[16:45] <vila> lol, is that how you negotiate ?
[16:45] <bialix> no :-)
[16:45] <vila> ha, good :)
[16:45] <bialix> but writing such patch only to change docstring in tree
[16:45] <bialix> is too trivial
[16:46] <bialix> and this was real WTF for me
[16:46] <bialix> I guess name is wrong today
[16:46] <vila> hmmm, I'm not a native english speaker, so when in doubt, I either write a test or read the code :)
[16:47] <bialix> as you see there is 2 places to read
[16:47] <vila> I have no idea about other implementations....
[16:48] <vila> tree.is_ignored() returning False sounds.... arbitrary, wt.is_ignored() implementation is obviously tied to .bzrignore (both the user one and the global one),
[16:49]  * bialix inspecting qannotate for tree.py
[16:49] <vila> the misleading bit is that the temporal indication is nowhere to be seen
[16:50] <vila> also, revisiontree inherits from tree so is_ignored() returning False is understandable there
[16:52] <bialix> what's the sense of is_ignored in revisiontree?
[16:54] <bialix> according to annotation Tree.is_ignored has added by lifeless in 2255.7.97 revid:robertc@robertcollins.net-20070305031021-ypbakvagbivyw5mu
[16:54] <bialix> but this revision does not use this api, and don't test it
[16:55] <bialix> no, sorry, I'm wrong
[16:58]  * bialix looks on Gary with prayer to search in qdiff/qannotate
[16:59] <bialix> GaryvdM: idea: what you think about adding grep to qbrowse?
[17:00]  * bialix gave up
[17:02] <GaryvdM> bialix: Search in diff/annotate - Soon
[17:03] <GaryvdM> bialix: for browse: I was planning to use bzr-search.
[17:03] <bialix> bzr-search?
[17:03] <GaryvdM> bialix: like qlog
[17:03] <bialix> no, I mean search in files of specific revision
[17:04] <bialix> bzr-search will going through all history?
[17:04] <bialix> vila: back to shelve-notty: do you have good comment for me so I can use it when I'll rework my patch?
[17:05] <GaryvdM> bialix: but you can filter it for a specific revision easily
[17:05] <bialix> I don't understand yet
[17:05] <GaryvdM> bialix: maybe grep would be better
[17:06] <GaryvdM> bialix: anyway - I'm not plaining to work on that any time soon - sorry
[17:07] <vila> bialix: yup, see lp:~vila/bzr/shelve-no-tty
[17:07] <GaryvdM> bialix: but search in diff/annotate soon
[17:07] <vila> bialix: the tests are passing here, please test that is still works for you
[17:07] <bialix> GaryvdM: I don't asking you to work, I'm asking your opinion
[17:08] <bialix> ideas bouncing as you said other day
[17:08] <GaryvdM> bialix: I see - To be honest, I'm not too familiar with grep
[17:08] <bialix> vila: branching
[17:09] <bialix> GaryvdM: heh, I'm even manage to write something like ack in python for fun
[17:09] <vila> ack or awk ?
[17:09] <bialix> grep just searching in files for pattern
[17:09] <bialix> vila: ack
[17:09] <vila> oh, yes, ack, I keep forgetting about it, the perl thing ?
[17:09] <bialix> yep
[17:10] <GaryvdM> bialix: What I'm unsure of is how you could get grep to read the text of a revision tree.
[17:10] <bialix> because I have no desire to install Perl on Windows only for one utility it was fun to rewrite it (partially)
[17:11] <bialix> GaryvdM: I will do it via python
[17:11] <bialix> I said grep-like not grep itself
[17:11] <bialix> there is hgrep plugin
[17:11] <vila> I don't think hgrep works
[17:12] <bialix> I'm just bad to remember too much things
[17:12] <vila> bialix: that's why grep is good for you :-D
[17:12] <bialix> ?
[17:13] <bialix> perhaps I'm said not precisely what I want to say
[17:13] <bialix> I have very long memory about things no more relevant
[17:13] <GaryvdM> vila: There is a grep plugin on http://bazaar-vcs.org/BzrPlugins, which you are the author of. Is is able to grep a revision tree?
[17:14] <vila> To say the truth, I'm the maintainer only because I upgraded it long ago to the current bzr version at that time,
[17:14] <bialix> vila: http://pastebin.com/d33dd960e
[17:15] <vila> I think I remember that it worked only for the working tree and the plans were to enhance it to work with revision trees, but the internals weren't good enough to do that trivially, there may be some FIXME there...
[17:15] <bialix> vila: running full test suite takes 3 hours for me
[17:15] <vila> bialix: no worries,
[17:16] <vila> I wasn't clear: can you test that with qrun where it was previously failing (as in before your patch)
[17:16]  * bialix -> now
[17:17] <vila> if that works, then push that to your branch and add a comment in the mp when done so I can merge from there
[17:17] <vila> err, I mean merge and submit from there
[17:18] <vila> pfff, forget that, that's silly, tell me if it works and I'll submit from here :)
[17:19] <bialix> vila: http://imagebin.ca/view/9ptrtg_B.html
[17:19] <bialix> it works
[17:20] <vila> hehe, I love Add-Art (the FireFox plugin), even if the art is not always that good, it's always a pleasure to realize that I avoided yet another ad :)
[17:20]  * bialix using NoScript
[17:21] <vila> Yeah, I really should do that too, but I'm lazy and they say there is no virus on Linux :-D
[17:22] <GaryvdM> I use adblock plus. I'm all ways surprised how many ads there are when I work with out it :-O
[17:22] <vila> GaryvdM: Add-Art is on top of adblock :)
[17:23] <GaryvdM> vila: Oh - I see
[17:23] <bialix> so vila you don't see my wonderful screenshot? :'-(
[17:23]  * bialix crying
[17:23] <vila> I see you screenshot, not the ad at the top of the page ;)
[17:24] <bialix> I don't see AD either
[17:24] <vila> meh, soory for the confusion,  the ad was on the pastebin
[17:26] <bialix> I understood
[17:37] <vila> gnight all
[17:38] <bialix> bye
[17:38]  * bialix will go home too
[17:39] <bialix> bye all
[17:39] <GaryvdM> bye
[18:34] <jono> hi all
[18:34] <GaryvdM> Hi jono
[18:49] <jono> hey GaryvdM
[18:49] <jono> when merging I see an M next to files but one has a * - what does that mean?
[19:14] <jelmer> jono: IIRC some of its metadata changed (perhaps it become executable or is no longer executable?)
[19:14] <jelmer> *became
[19:14] <jelmer> yep, looks like it - see "bzr help status-flags"
[19:14] <jono> thats the one
[19:14] <jono> :)
[19:14] <jono> it was a perms change :)
[19:44] <GaryvdM> jono: Sorry - My connection went down. The * most likely the execution permission bit changed.
[19:44] <jono> np :)
[19:44] <jono> figured it out
[19:44] <jono> thanks!
[19:44] <GaryvdM> cool
[19:44] <ronny> jelmer: dulwich seems to have a set of methods that look duplicate on the fist look
[19:45] <ronny> om, mom, pulling the most recent to be sure
[19:47] <ronny> jelmer: ah, right, at least the from_file/from_string classmethods are unnecessary at each class
[19:47] <lifeless> moin
[19:48] <GaryvdM> Hi lifeless
[19:49] <lifeless> hi GaryvdM
[19:51] <ronny> jelmer: and i really dislike the exception hierachy now that i take a look at it, i'll try to make a patch
[19:53] <jelmer> ronny: That's for historical reasons
[19:54] <jelmer> ronny: patches are welcome, but I'm not very keen on breaking backwards compatibility..
[19:56] <jelmer> ronny: btw, there is a #dulwich now
[20:18] <ronny> jelmer: i dont intend to break the backward compatibility
[21:40] <brmassa> Guys, on C/C++ projects, do you normally track the entire project directory or just the source files?
[21:41] <AfC> brmassa: "entire"?
[21:41] <brmassa> AfC: including the "/bin", "/includes" and other possible directories.
[21:43] <AfC> brmassa: well, if bin/ is _build product_ then no
[21:43] <AfC> brmassa: ie, no need to version control things that your build creates.
[21:43] <brmassa> AfC: its useful coz it will track the directories changes (where the project is going to be build), but it also polute the bzr status with tons of files that doesnt need to be versoned
[21:43] <AfC> brmassa: (I suspect you know that, which is why I'm trying to figure out the nuance of what you're asking)
[21:43] <brmassa> AfC: yep,.
[21:43] <lifeless> brmassa: you could 'bzr add --no-recurse bin; bzr ignore bin'
[21:43] <AfC> brmassa: bzr understands how to ignore things
[21:44] <AfC> brmassa: but you want to do:
[21:44] <AfC> $ bzr help ignore
[21:45] <brmassa> AfC: the makefile/projectfile generally include information that is a little beyond the /src dir, like where to build the project. so it would be nice to track the entire project dir, excluding the content of certain dirs.
[21:45] <AfC> brmassa: that said, I'm not sure why you'd need to version the directory bin/ if it is a temporary (or final) output of the build. Surely your Makefile (or whatever) knows how to mkdir bin
[21:45] <brmassa> AfC: my question was more like the common practice than a howto. what people normally do.
[21:46] <AfC> brmassa: right. So version control Makefile.
[21:46] <AfC> brmassa: ah. Well, I can't speak for anyone else, but in the GNOME world we don't version control build artifacts.
[21:47] <brmassa> AfC: hmmm not even the directory structure needed to build a given app?
[21:47] <AfC> brmassa: there is a *horrible* tendency in the Windows centric side of the Java world to whack .jar files the project depends on into version control
[21:48] <AfC> (partly because they don't have a proper package management system they can query & reply on, and partly because they're just doing the wrong thing out of sheer bloody mindedness :)
[21:48] <AfC> brmassa: sure, you can do that, but why not have your Makefile (or whatever) mkdir your temporary & output structure for you?
[21:48] <lifeless> brmassa: if you need a directory structure, and your toolchain doesn't create it automatically, versioning the structure would be a good idea.
[21:48] <lifeless> brmassa: what toolchain are you using ?
[21:48] <AfC> [thereby making it just the sort of thing that can be a) `bzr ignore`d and b) `make {dist,}clean`ed
[21:49] <AfC> brmassa: other than that, listen to lifeless :)
[21:49] <Peng> If you have to version e.g. bin, you could still "bzr ignore bin/*".
[21:49] <AfC> brmassa: [as indeed this isn't the place to talk about comparative merits of different toolchain strategies; bzr can do what you're asking if that's the way you wish to do it]
[21:50] <brmassa> lifeless: im programming using Qt's qmake. well.... it does create directories if i tell so, but i was wondering to just track the myproject/src dir...
[21:50] <AfC> Oh, there's a gem: on #cairo, "git has erased all history of that merge"
[21:51] <lifeless> brmassa: you should track the things that are both: things other people will need to build the software AND things they can't get elsewhere
[21:51] <brmassa> lifeless: hmmm nicely put
[21:52] <lifeless> directories that the toolchain can make for you aren't in that set, IMO :)
[21:52] <AfC> lifeless: that _was_ nicely put
[21:53]  * AfC takes a quote of that, and then wonders how to properly cite an IRC discussion in a footnote :)
[21:53] <brmassa> its because i use a specific dir structure on all my projects, like myproject/src, myproject/includes, myproject/bin, myproject/tests, myproject/media, so i was wondering to just version the part of it instead the whole structure...
[21:54] <brmassa> but for new developers, who wil download the bzr tree, it might help to just see the BIN dir...
[21:55] <AfC> brmassa: {shrug} they will after they type `make` :)
[21:55] <brmassa> AfC: yep. maybe u r right.
[21:55] <AfC> brmassa: in most projects I'm maintainer of, things are structured so that with the exception of a Makefile fragment called .config created by our [custom] top level ./configure,
[21:56] <AfC> brmassa: *all* the build output runs out into directories under a top level tmp/ that the build creates for itself
[21:57] <brmassa> AfC: nice. it seems to be the right thing to do. well thank all you guys.
[21:57] <AfC> brmassa: [with one further exception that there's an entire source tree created during the first step of the build, and so the build mkdir's a tree called generated/ for that]
[21:57] <AfC> brmassa: [but in this case generated/ is a peer twin of src/ so it rather made sense]
[21:58] <AfC> [it could have been tmp/generated/ too]
[21:59] <lifeless> AfC: thanks
[22:53] <thumper> lifeless: any idea on bug 485318 ?
[22:53] <lifeless> looks like a bug to me
[22:55] <thumper> lifeless: should I add a bzr task?
[22:55] <thumper> lifeless: or reassign?
[22:58] <lifeless> let me have a look
[22:59] <lifeless> what is %20 - ' ' ?
[22:59] <lifeless> yeah
[23:07] <thrope> hello - I was following loggerhead and noticed there have been no changes since may... my branch is following %7Eloggerhead-team/loggerhead/trunk/ but I had a look on launchpad and I think they moved to trunk-rich
[23:07] <thrope> can I do bzr switch in my tree? or will it mess everything up
[23:08] <thrope> or can I pull from the trunk-rich
[23:08] <lifeless> thumper: bzr pull lp:loggerhead
[23:08] <lifeless> thrope: ^
[23:08] <lifeless> thrope: and if that errors, run 'bzr upgrade' before pulling ;)
[23:09] <thrope> ERROR: KnitPackRepository('file:///home/robince/src/loggerhead/.bzr/repository/')
[23:09] <thrope> is not compatible with
[23:09] <thrope> CHKInventoryRepository('http://bazaar.launchpad.net/%7Eloggerhead-team/loggerhead/trunk-rich/.bzr/repository/'
[23:10] <thrope> maybe my bzr on this machine is too old
[23:12] <lifeless> thrope: do you have 2.0?
[23:12] <thrope> no 1.16 on here I think... just upgrading
[23:16] <Peng> If it knows about CHKInfoRepository, it has to be at least 1.18, no?
[23:16] <poolie> hello lifeless, peng
[23:16] <Peng> poolie: Good $timeofday. :)
[23:17] <thrope> its ok now
[23:20] <lifeless> Peng: 1.16.1, but see my mail about emacs for why thats not enough
[23:20] <lifeless> hi poolie
[23:23] <Peng> 1.16.1, eh?
[23:28] <lifeless> poolie: you might like to add #launchpad-dev to your channel list
[23:28] <poolie> oh as opposed to lp-code?
[23:29] <poolie> my config is out of date
[23:29] <lifeless> and, not xor
[23:32] <Peng> #launchpad-code?
[23:33] <lifeless> Peng: lp-code is on irc.canonical.com
[23:34] <lifeless> Peng: its where dev discussion happened before the open sourcing
[23:34] <Peng> Oh.
[23:34] <Peng> Is irc.canonical.com open to the public (i.e. me)?
[23:35] <lifeless> no
[23:35] <lifeless> unless you get a job with us :)
[23:35] <Peng> :D
[23:46] <thrope> so I finally got loggerhead running through my apache proxy with serve-branches since the start/stop scripts are deprecated
[23:46] <thrope> I can see host.net/nn_review/files  fine with css etc
[23:46] <thrope> but basically every link is broken
[23:46] <mwhudson> that seems surprising
[23:47] <thrope> changes, annotate/head%3A/nnreview.py
[23:47] <thrope> all give Not Found
[23:47] <mwhudson> if the css/js links are right, i'd expect the other links to be right too
[23:47] <thrope> I am using RewriteEngine instead of ProxyPass
[23:47] <thrope> could that be it?
[23:48] <thrope> I couldn't get ProxyPass to pass the front page properly
[23:48] <thrope> (I dont want a prefix, just bzr.host.net/
[23:48] <mwhudson> thrope: do the links look wrong, or are urls you would expect to work not working?
[23:48] <thrope> not sure about the colon above
[23:48] <thrope> ah wait
[23:48] <thrope> they are to http instead of https
[23:49] <mwhudson> oh right
[23:49] <mwhudson> thrope: you might be able to use proxypassreverse to fix this
[23:49] <thrope> how can I tell loggerhead that?
[23:49] <mwhudson> but i don't know how that works
[23:49] <thrope> ah ill try proxypass again
[23:50] <mwhudson> thrope: i don't think you can, i could add a --https flag to serve-branches
[23:50] <mwhudson> but i don't think i did, just thought about it
[23:51] <thrope> yeah the proxy pass didnt make any difference
[23:52] <mwhudson> ah
[23:52] <mwhudson> i misunderstood how that works
[23:55] <thrope> do you know if theres somewhere in the code I can add the 's' in... actually now I think about it I think I did that before with the older version
[23:55] <thrope> but it looks like its got more complicated since then ;)
[23:56] <mwhudson> i should just give up and generate relative links