[00:09] <kenichi> LarstiQ: hey there, do you remember my weird negative revno issue from yesterday?  interesting fix: edit .bzr/branch/last-revision and fix the revno.  so far, that seems fix a copy of my borked repo, without taking nearly as long as 'bzr reconcile'
[00:10] <igc> morning
[00:17] <garyvdm> Morning igc - how did it go on Tuesday?
[00:20] <garyvdm> poolie: Hi - The channel topic is still not right?
[00:21] <igc> hi garyvdm. OK thanks. Tired though.
[00:26] <lifeless> garyvdm: you can fix it :)
[00:26] <garyvdm> Ok
[00:47] <poolie> hello jml
[00:47] <poolie> sounds good
[00:47] <poolie> jetlag-induced second breakfast has been served and eaten :)
[00:47] <poolie> hello gary
[00:58] <poolie> spiv, hello, do you know much about bug 385132?
[00:58] <jml> poolie: :D
[00:58] <jml> poolie: I could use a first breakfast :)
[00:58] <poolie> you can do that first if you want :)
[01:07] <spiv> poolie: not a huge amount
[01:08] <spiv> poolie: I don't have any insights to add that aren't already in the bug comments
[01:10] <jml> poolie: hi
[01:10] <jml> poolie: let's talk :)
[01:11] <lifeless> poolie: I love it when people comment on many year old bugs of mine ;)
[01:11] <poolie> lifeless: which one?
[01:11] <lifeless> 1837
[01:12] <lifeless> product/bugs target to milestones page shows fixed bugs
[01:12] <lifeless> at least, I think I filed it
[01:13] <poolie> oh, yeah
[01:13] <poolie> you did
[01:15] <poolie> jml: is that really 5s lag!
[01:15] <poolie> or call me at home
[01:15] <jml> poolie: sure.
[01:32] <jml> igc: does the branch that's in pqm now fix a particular 1.16 bug?
[01:33] <igc> jml: I'm making the requested tweaks from jam's review now
[01:34] <jml> igc: sweet
[01:34] <igc> jml: there's a catch though ...
[01:34] <jml> igc: but I'm actually just wondering if "Thu Jun 11 00:42:04 2009 UTC: Ian Clatworthy <ian.clatworthy@canonical.com>, '(igc) fix rule handling so that eol is optional' " is associated with a bug report...
[01:34] <jml> igc: oh, what is it?
[01:35] <igc> I'm due at the hospital in 25 minutes
[01:35] <jml> :(
[01:35] <igc> and I'm not going to get the tweaks finished by then
[01:35] <igc> so I'll push what I can do by then but not land it yet
[01:36] <jml> igc: ok. I'll see what we can do to get it landed.
[01:36] <jml> (no promises though, sorry).
[01:37] <jml> igc: for the record, is this for bug 362030 or bug 379370?
[01:37] <igc> jml: it still needs a test jam has requested added.
[01:37] <igc> 362030
[01:37] <jml> ok.
[01:37] <igc> the other one has been sent to pqm
[01:39] <jml> igc: thanks.
[01:40] <igc> jml, poolie: see https://code.edge.launchpad.net/~ian-clatworthy/bzr/eol-st-ci-fix/+merge/7269
[01:40] <igc> the first tweak has been pushed to https://code.edge.launchpad.net/~ian-clatworthy/bzr/eol-st-ci-fix/
[01:41] <igc> jml: the second tweak is an additional test which jam has basically written in his review
[01:41] <igc> jml: but it needs some work because the "set rules" bit isn't quite right
[01:42] <igc> jml: poolie might be able to assist you in tweaking it
[01:42] <jml> igc: ahh cool.
[01:43] <igc> jml: we *could* land the branch without the additional test (for now) but please don't do that unless jam or poolie agrees
[01:43] <jml> igc: of course :)
[01:44] <igc> jml: bzrlib/tests/workingtree_implementations/test_eol_conversion.py shows how to patch in custom rules
[01:45] <igc> you can't use absolute paths but that doesn't matter
[01:45] <igc> the important point is that the rules change at all
[01:45] <igc> jml: ok, got to run - back in a few hours
[01:45] <jml> igc: np. thanks for the help :)
[01:46] <lifeless> poolie: bubg 241170
[01:46] <lifeless> poolie: bug 241170. Why did you remove the milestone for when it was fixed?
[01:50] <poolie> lifeless: the bug doesn't say it's fixed
[01:50] <poolie> it says it's still open
[01:50] <lifeless> oh. I'm pretty sure its lying
[01:50] <lifeless> because we adjusted get_parent_map in the manner proposed
[01:51] <poolie> it's not in NEWS eithr
[01:51] <jml> did the Russian doc patch land?
[01:51] <lifeless> true, but if you look at remote.py
[01:52] <poolie> jml: i sent to pqm for the zdll fix and the smaller images
[01:52] <jml> poolie: thank you.
[01:53] <jml> yes, the russian doc patch landed :)
[01:54] <lifeless> poolie: lets ask spiv
[01:54] <lifeless> spiv: ping
[01:57] <spiv> lifeless: pong
[01:57] <lifeless> see scrollback
[01:58] <spiv> I vaguely recall seeing that bug get fixed, but I'm not 100% sure.
[01:59] <spiv> It only affects/ed branch format 5.
[02:00] <poolie> i'll mark it fixed then
[02:00] <poolie> spiv, what was the other bug you were working on on tuesday? is that now landed?
[02:01] <spiv> No, although I'm about to submit a cheap fix for that.  I have a followup that removes all VFS RPCs from the "pull -r 123" case (done in an empty repo, where 123 is a revision found only in the stacked-on repo of a stacked branch).
[02:01] <spiv> (18 RPCs total, down from >40)
[02:05] <spiv> poolie: ah, I believe 241170 may be a dupe of 214894, which is fixed.
[02:06] <spiv> Oh, although the 241170 reporter said they were using 1.5, which apparently had the 214894 fix...
[02:06] <jml> I just sent a status update email for the 1.16 releaese.
[02:06] <jml> would greatly appreciate it if you had a look (particularly spiv & lifeless)
[02:22] <spiv> jml: is it possible to submit a lp merge directive for a specific revision (i.e. not tip) of a branch?
[02:23] <jml> spiv: not through the UI.
[02:23] <spiv> jml: if I do it through email will it DTRT?
[02:23] <jml> spiv: it's possible that emailing a merge directive might do it.
[02:23] <spiv> Ok, experiment time!
[02:23] <jml> spiv: I couldn't say for sure though.
[02:23] <lifeless> spiv: I think that lp is a subset of merge directives.
[02:24] <lifeless> spiv: I'm not sure where the subset lines are drawn though
[02:29] <jml> lifeless: I've got a few questions about this final_stack_pwd.
[02:30] <jml> lifeless: where should I add the tests?
[02:31] <jml> lifeless: TestSmartServerRequestBzrDirInitializeEx seems to suggest that test_bzrdir is the right place.
[02:32] <jml> but in test_bzrdir, I can't see any sign of using the smart server (particularly in TestRepositoryAcquisitionPolicy)
[02:34] <lifeless> are you going to be writing implementation or interface
[02:35] <lifeless> tests
[02:35] <lifeless> ?
[02:35] <jml> lifeless: I don't know.
[02:35] <lifeless> so, I don't know where the tests should go then
[02:36] <jml> lifeless: I was under the impression that there were already tests for this area of functionality
[02:36] <jml> lifeless: where do they live?
[02:36] <lifeless> if you think you've found a misbehaving implementation where tests for the behaviour are either broadly irrelevant or hard to exercise on other implementations, then I'd write implementation tests
[02:36] <lifeless> if you can write the tests as generic exercise-of-interface then interface tests
[02:37] <spiv> jml: hah, the answer is both yes and no: https://code.edge.launchpad.net/~spiv/bzr/stacking-friendly-revision-history-verb/+merge/7314
[02:37] <spiv> jml: the diff in my email is included and shows the intended content (only 4 revs worth)
[02:37] <spiv> jml: but there's a generated diff from lp linked on that page with too much history, and lp is listing all the revs in that branch as unmerged in this proposal.
[02:38] <jml> spiv: good to know :)
[02:38] <lifeless> bzrlib/tests/bzrdir_implementations/test_bzrdir.py +1166
[02:39] <lifeless> jml: the interface is 'initialize_on_transport_ex'
[02:40] <jml> lifeless: thanks. I gather those tests run against every implementation?
[02:40] <lifeless> yes
[02:40] <lifeless> they run against a current and an older protocol version of the smart server too
[02:41] <jml> cool.
[02:41] <jml> so if the bug is actually in SmartServerRequestBzrDirInitializeEx then a properly written test ought to trigger it?
[02:41] <lifeless> well
[02:42] <lifeless> I think we should pin down the contract
[02:42] <lifeless> so yes
[02:42] <lifeless> unit tests for smart server verbs are in
[02:42] <lifeless> bzrlib/tests/test_remote.py +744
[02:42] <jml> test_smart
[02:42] <jml> oh, test_remote
[02:43] <lifeless> there's history here. Don't look under the curtain
[02:43] <jml> ok.
[02:43] <spiv> Well, test_smart.py is unit tests for the server-side.  test_remote.py is unit tests for how the client-side Remote* classes interact with the network.
[02:44] <jml> looking at BzrDir.initialize_on_transport_ex...
[02:45] <jml> the docstring says that stacked_on=None implies following the target's stacking policy.
[02:45] <jml> I guess that means that stack_on_pwd is ignored in that case.
[02:45] <lifeless> spiv: and server side unit tests.
[02:45] <lifeless> spiv: they are there, existence proof :P
[02:46] <lifeless> jml: look at bzrlib/bzrdir.py +3150
[02:54] <lifeless> jml: did that help?
[02:55] <jml> lifeless: probably :)
[02:55] <jml> lifeless: still paging all of this stuff in.
[02:56] <spiv> lifeless: hmm, some tests there do create actual servers rather than using test doubles, but AFAICT the primary purpose of all the tests in test_remote is to test client-side behaviour.
[02:57] <lifeless> spiv: you're likely right
[03:00] <eydaimon> i've done a bzr revert to an earlier revision... how can I do a diff against the latest revision if I didn't know what the rev number is? I was thinking something like bzr diff -r head file
[03:01] <poolie> diff runs against the branch's tip
[03:02] <poolie> so just 'bzr diff' will show the difference
[03:02] <eydaimon> so bzr diff -r tip head?
[03:02] <eydaimon> oh ok
[03:03] <eydaimon> out of curiousity, is there a way to specify tip?
[03:03] <poolie> -r head: i think
[03:03] <spiv> Or -r -1
[03:03] <poolie> jml, i think i'ts ok to slep bug 284038 though i also think it's a mysql bug and deserves a little extra effort
[03:03] <poolie> oh of course
[03:03] <eydaimon> -1 works
[03:04] <poolie> jml, bug 380314 i think is critical to use with launchpad?
[03:04] <spiv> It breaks "bzr pull -r 123"
[03:04] <poolie> i may try bug 385453
[03:04] <spiv> (on stacked branches)
[03:04] <spiv> Which is pretty serious, I think.  The fix is up for review now.
[03:06] <jml> poolie: re 284038, it'd definitely be great to get it in, yes.
[03:07] <jml> poolie: likewise for the 'make dist' bug, but imo format bump & reviewing existing patches (like spiv's) take precedence.
[03:08] <spiv> jml: fwiw I don't have anything to add to your status update email (other than pointing out that my fix is now up for review, which you already know)
[03:08] <poolie> jml, spiv, how about bug 381329 - is that in trunk? in 1.15 (where it's targetted)
[03:08] <spiv> poolie: yes, the 1.15 patch was a direct cherrypick off trunk.
[03:13] <poolie> so i'll mark it released in 1.16 too?
[03:15] <poolie> done
[03:47] <igc> jml: back. I'll keep working on that tweak assuming no-one has picked it up
[03:47] <jml> igc: cool :) as far as I know, no one has.
[03:48] <poolie> jml: format added, am going to do some adhoc testing
[03:48] <poolie> including upgrading to it from dev7
[03:48] <poolie> will put it up soon
[03:48] <jml> poolie: thanks.
[03:49] <lifeless> poolie http://cworth.org/intel/driver_stability/
[03:49] <igc> poolie: be sure to check upgrading from dev6 too
[03:49] <poolie> yeah, and on a small one upgrading from something earlier
[03:49] <lifeless> jml: so tell me when you're  looking at stacking
[03:49] <igc> poolie: there were some problems with that a few days ago
[03:50] <igc> which I think jelmer or jam might have fixed since
[03:51] <poolie> i might get some lunch first though
[03:51] <jml> lifeless: now :) http://paste.ubuntu.com/193156/ -- that's the test I just finished.
[03:53] <lifeless> poolie: I've lost the bazaar-announce moderator password again.
[03:55] <jml> lifeless: any comments on that validity of that test?
[03:56] <lifeless> bad:  except errors.BzrError:
[03:57] <lifeless> jml: asking for 1.9 is problematic
[03:58] <lifeless> jml: I suggest being a little bit more complex:
[03:58] <lifeless>  - make a control dir without specifying format, which will use the parameterised format
[03:58] <lifeless>  - if that is a bzrdirmeta1 then hard code 1.9
[03:58] <lifeless>  - otherwise use whatever branch format that the test makes by default
[03:59] <lifeless> it looks broadly fine though
[04:00] <jml> lifeless: you mean a control dir at the 'stack-on' location?
[04:01] <lifeless> jml: or even a third location
[04:01] <jml> ok.
[04:02] <jml> I'm not sure how to avoid the BzrError.
[04:02] <lifeless> its too generic
[04:03] <lifeless> its like catching Exception
[04:03] <jml> three of the formats simply raise a BzrError when calling set_default_stack_on.
[04:03] <lifeless> mmm
[04:03] <jml> BzrError: Cannot set configuration in <bzrlib.bzrdir.BzrDir5 object at 0x6bb7350>
[04:03] <lifeless> oh
[04:03] <jml> I guess I can check the str() of the exception.
[04:03] <lifeless> then its fine
[04:04] <lifeless> but please make it more specific
[04:04] <lifeless> don't chain the calls so deep
[04:04] <lifeless> config = self.make_bzrdir('.').get_config()
[04:04] <lifeless> try:
[04:04] <lifeless>     ...
[04:04] <jml> *nod*
[04:04] <lifeless> except BzrError:
[04:21]  * spiv -> food
[04:26] <GPHemsley> Ugh... who do I have to poke to get an up-to-date Mac OS X package?
[04:26] <GPHemsley> Preferably, a package that works
[04:27] <GPHemsley> Because my lack of a working subvertpy seems to be causing trouble
[04:28] <GPHemsley> Not to mention that rebase is apparently out of date, too
[04:29] <GPHemsley> Looking for 1.13.0 when 1.15.0 is required
[04:43] <GPHemsley> Well, downgrading to 1.14.1 at least gets rid of the rebase error
[04:46] <poolie> lifeless: you can call me about format naming if you want
[04:46] <poolie> or we can talk here
[04:47] <lifeless> poolie: either is fine
[04:47] <poolie> if we're miscommunicating
[04:47] <lifeless> poolie: I'm filing the bugs we talked about at the moment, just takes a while to make sure htey aren't dups
[04:47] <poolie> there's no super rush
[04:47] <poolie> i am going to put this patch up in a bit, taking teh approach i outlined
[04:48] <lifeless> I think if we're making it supported in 1.16, we should put 1.16 in the version string
[04:48] <lifeless> my key point is that I *know* have a code change which requires a string bump but no disk changes
[04:48] <lifeless> s/no disk/no other disk/
[04:49] <poolie> what is that change?
[04:49] <lifeless> fixing the rich root additions the streaming fetch code sends
[04:49] <lifeless> Its the one I mentioned in the thread
[04:53] <poolie> jml, both the smaller images and the zdll fix landed
[04:54] <mwhudson> .oO(will brisbane-core make a difference to how much i exceed my download cap each month...)
[04:54] <lifeless> poolie: house phone is out of juice
[04:54] <jml> poolie: thanks.
[04:55] <jml> lifeless: fwiw, I'm now stumped on the actual fix to the stacking bug. I'm off to get lunch, should be back in ~20mins.
[04:55] <jml> poolie: I just have you down for the format name thing -- is that your understanding too?
[04:56] <poolie> yes
[04:56] <jml> cool.
[04:57] <lifeless> poolie: I'm assuming that was you ringing
[04:57] <poolie> lifeless: so to me it doesn't make any sense to say it's the same format on disk but it needs a new number
[04:57] <poolie> it was
[04:57] <lifeless> poolie: other suggestions to stop broken code writing to this format appreciated
[04:58] <poolie> is there a bug for this?
[04:58] <lifeless> 13:41 < lifeless> poolie: I'm filing the bugs we talked about at the moment, just takes a while to make sure htey aren't dups
[04:58] <lifeless> (no not yet)
[04:58] <poolie> by which i mean, what broken code are you talking about?
[04:58] <lifeless> there was but I think it got closed when 1/2 the code got fixed
[04:59] <lifeless> because the test suite will fail when we fix the dependent issues
[04:59] <poolie> if using 1.16 to fetch into this format will lose data then that's a blocker for doing this release at all
[05:00] <poolie> if this release is ok, but you want to change the way things are represented in future, then i'd say that really is a change to the ondisk format
[05:00] <lifeless> It won't, because IDS will take over. It will just take hours to pull over the network.
[05:00] <lifeless> poolie: its neither of those cases.
[05:02] <igc> jml: those tweaks are now done. Just running the test suite and I'll submit it to pqm
[05:13] <jml> igc: thanks.
[05:13] <GPHemsley> How do you change repo formats?
[05:13] <GPHemsley> I forget the command
[05:14] <jml> bzr upgrade
[05:14] <GPHemsley> hmm... I should've thought of that
[05:15] <GPHemsley> but thanks :)
[05:48] <lifeless> https://bugs.edge.launchpad.net/bzr/+bug/374735
[06:12] <jml> :(
[06:16] <poolie> jml, lifeless : https://code.edge.launchpad.net/~mbp/bzr/385103-format-name/+merge/7321
[06:16] <poolie> comments on NEWS especially welcome
[06:17]  * jml waits for the diff to generate
[06:17] <lifeless> poolie: 2a - not 2s-rich-root?
[06:17] <lifeless> s/s/a
[06:18] <lifeless> poolie: not every format is listed by bzr init --help IIRC
[06:18] <lifeless> poolie: its controlled by data on the formats
[06:18] <lifeless> poolie: IMBW
[06:19] <poolie> s/every/lots of/ :)
[06:19] <bob2> is there some way to get a full diff of a merge req on lp?
[06:19] <poolie> and i think we need to get away from having -rich-root  in the name
[06:19] <poolie> we need to do it sometime
[06:19] <poolie> now's a good time
[06:19] <poolie> bob2 there's a link to download it
[06:19] <lifeless> poolie: I think we should for 2.0 release
[06:22] <lifeless> poolie: I think you should try working with a bzr tree in 2.0 and see what users get told about the incompatibilities before deciding that we're ready to make it less scary
[06:23] <poolie> i'm upgrading now
[06:24] <lifeless> in particular interacting with the rest of the community
[06:24] <poolie> i'm happy to tweak that text to make it more constructively scarey
[06:24] <lifeless> I don't think people will read the text
[06:24] <poolie> or the short format description
[06:25] <lifeless> indeed
[06:25] <lifeless> often people will just see 'run bzr upgrade --FOO'
[06:25] <lifeless> based on previous observation.
[06:26] <lifeless> Its safer to say 'this is safe to do with [x] conditions' when the string is scary, than is is to say 'this is scary unless [x] conditions' when the string looks safe.
[06:26] <poolie> jml, thumper, do either of you want to talk?
[06:27] <poolie> lifeless: possibly we should say interactively "do you really want an experimental format"?
[06:27] <poolie> we could print a warning but if you just did an upgrade it may be too late
[06:27] <jml> poolie: yes. :)
[06:27] <poolie> i'm open to changing the ui name to say 2a-beta
[06:29] <bialix> garyvdm: still here?
[06:30] <garyvdm> bialix: Yhea - but not for long - I've been up all night :-)
[06:30] <lifeless> poolie: I don't think that is enough. Also showing a interactive question would seem to me to be further away from what you seem to want than 2.0-rich-root would be.
[06:30] <lifeless> poolie: I'm not sayin the disk format needs to mention rich roots.
[06:30] <bialix> garyvdm: almost the same
[06:31] <bialix> Gary, I'm planning to make release today
[06:31] <bialix> it's ok to using current trunk?
[06:31] <lifeless> poolie: fwiw bug 368921 was the IDS version of the bug with the network server
[06:32] <garyvdm> bialix: Cool - I did see you mail. Yhea - there are no bugs/regressions I'm am aware of.
[06:32] <garyvdm> bialix: I've got some stuff I'm holding off till you release.
[06:32] <bialix> gayvdm: I have one question about next one release. It seems we will release next release in sync with bzr 2.0
[06:33] <bialix> garyvdm: I can use separate release branch, so you don't need to hold off
[06:33] <poolie> hello gary, bialix
[06:33] <bialix> I need only finish new Inno Setup based installer
[06:33] <bialix> poolie: good day
[06:33] <garyvdm> bialix: Don't worry - It probably not even ready for trunk yet.
[06:34] <garyvdm> Hi poolie
[06:34] <bialix> garyvdm, poolie, luks, igc: I'm thinking about calling next qbzr release as 1.0
[06:34] <bialix> this is very interesting opportunity
[06:35] <igc> bialix: as in the one after today's?
[06:35] <bialix> igc: the one in next month
[06:35] <igc> bialix: right, so qbzr 1.0 ships with bzr 2.0
[06:35] <bialix> yes, exactly
[06:35] <bialix> recently jelmer asked about releasing bzr-svn as 1.0
[06:36] <igc> bialix: that would be good I think
[06:36] <garyvdm> bialix: I think we should wait untill qmain is finished.
[06:36] <bialix> garyvdm: do you see bzr-explorer?
[06:36] <igc> bialix: Javier will hopefully be adding some more q* commands in coming weeks, e.g. qsend, qexport
[06:37] <garyvdm> bialix: yes - and I have to chatting alot to igc about it.
[06:37] <bialix> Gary, I know we have a lot of unfinished stuff
[06:37] <igc> bialix: and I have plans for putting some together over nights/weekends too, e.g. qbind
[06:37] <garyvdm> bialix: we should probably test if bug 385550 also affects the bzr installer.
[06:38] <bialix> garyvdm: no
[06:38] <bialix> bzr.exe installer uses Inno Setup.
[06:38] <bialix> I wrote it
[06:38] <bialix> qbzr installer wrote luks
[06:38] <igc> bialix: any chance qversion will make the cut this time around?
[06:38] <bialix> I never used NSIS myself
[06:38] <garyvdm> bialix: Ok then it really makes sense to use Inno.
[06:38] <bialix> igc: there is some layout problems with your dialog
[06:39] <bialix> I'll plan to fix it after 0.11
[06:39] <bialix> maybe tomorrow
[06:39] <igc> bialix: ok
[06:40] <igc> bialix: also, thanks for the qview to qviewer change
[06:40] <igc> bialix: do we need to tweak TortoiseBzr accordingly?
[06:40] <bialix> igc: what's your vision of annotate in explorer? this command require filename as argument
[06:40] <bialix> igc: I've checked tbzr trunk: qviewer is not used there
[06:41] <igc> bialix: I'll probably drop it from the menu in the short term ...
[06:41] <bialix> it seems last time Mark Hammond touches the tbzr this winter. and then disaooear
[06:41] <igc> and expect people to reach it via qbrowse say
[06:41] <bialix> poolie: does Mark was contractor?
[06:41] <pygi> bialix: yes, he was a contractor
[06:41] <garyvdm> igc, bialix: or qlog
[06:41] <pygi> but he's god a full time job now afaik, so he isn't as available
[06:42] <igc> garyvdm: right
[06:42] <garyvdm> igc: My 2c about qversion: it would be nice if bzrlib could give us rst which we could convert to html and display in a QTextDocument
[06:42] <bialix> garyvdm: browse see,s more appropriate
[06:42] <bialix> seems
[06:42] <garyvdm> igc: and bzr cli should also use the rst converted into plain text?
[06:42] <bialix> garyvdm: no
[06:42] <pygi> oh noes, garyvdm with his qlog :P
[06:43] <bialix> no need for rst right now
[06:43] <garyvdm> Hi pygi
[06:43] <garyvdm> bialix, igc: Ok but I would like to see qbzr more common with bzr cli.
[06:43] <bialix> so, without Mark it seems like tbzr will stalled
[06:44] <garyvdm> just my 2c..
[06:44] <bialix> garyvdm: https://bugs.launchpad.net/qbzr/+bug/273847
[06:44] <bialix> have not ime for this
[06:45] <garyvdm> bialix: I did start doing some work on tbzr - but you convinced me to refocus on qmain :-)
[06:45] <bialix> garyvdm: there is a lot of hard work for tbzr, especially because it affects entire windows performance
[06:45] <garyvdm> Yhea
[06:46] <bialix> we can implement qmain much faster
[06:46] <garyvdm> And we can do much more interesting things with qmain...
[06:46] <bialix> but I see bzr-explorer as qmain 0.5 ;-)
[06:46] <bialix> exactly
[06:46] <bialix> I'd like to implement projects support
[06:47] <igc> bialix, garyvdm: my main desire for tbzr is to tweak the menu to reflect the one we're using in Explorer & qbzr-eclipse
[06:47] <bialix> ok, so today it's too early think about 1.0 date
[06:47] <bialix> np
[06:48] <bialix> pygi: what's wrong with either gary or qlog? ;-)
[06:48] <garyvdm> I think so
[06:48] <poolie> i think it would be cool to do a 1.0 at the same time
[06:48] <poolie> i'm using it a bit; i haven't dived straight in as much as ian has
[06:48] <poolie> i probably should
[06:49] <fullermd> Hm.  I like how selftest has a --parallel option that takes various values, and doesn't give any hint as to what the possible values are.
[06:49] <garyvdm> Gary will show anybody that give him 2sec qlog's features :-)
[06:49] <poolie> speaking of which, hopefully he'll be around moer in future
[06:49] <igc> poolie: have you tried explorer yet?
[06:49] <poolie> no, good idea though
[06:50] <bialix> igc, btw we have nice working tree widget that could be used in bzr-explorer to show status
[06:50] <lifeless> poolie: so actual review comment added
[06:50] <igc> poolie: it's making progress most weekends
[06:50] <lifeless> poolie: but my prior comments still stand
[06:50] <bialix> garyvdm: maybe if explorer will be pretty usable we can talk about calling qbzr+explorer as qbzr 1.0
[06:51] <bialix> garyvdm: one more question, if you can
[06:52]  * igc returns to reviewing jam's iter-nodes patch before he falls aslepp
[06:52]  * igc afk
[06:53] <garyvdm> bialix ?
[06:53] <pygi> bialix: nothing, I like joking with him xD
[06:54] <poolie> jml, filex bug 381814
[06:54] <bialix> garyvdm: can we chat one day when we both will have enough free time and not be up all the night about alog internals? maybe on some weekend? I have troubles to understand all details, but I'd like to. I have some ideas about adding unit tests to qlog internal engine
[06:54] <poolie> or not
[06:54] <poolie> bug 385814
[06:54] <poolie> only wishlist i think
[06:55] <jml> poolie: yeah, except for reasons I don't understand, we don't use wishlist, just low.
[06:55] <bialix> garyvdm: I'm mostly asking beforehand because it's hard for me to catch you in IRC
[06:55] <poolie> i didn't file it
[06:55] <poolie> i mean i didn't rank it, i'll let that team do it
[06:55] <jml> oh thanks :)
[06:55] <garyvdm> bialix: Ok - I started with tests for qlog at uds - there is just so much to test.
[06:56] <bialix> I need to understand your design first
[06:56] <garyvdm> I'll keep chipping away at it.
[06:56] <bialix> there is too little comments
[06:56] <garyvdm> :-(
[06:56] <AfC> Am I correct in understanding that there's no release of bzr-gtk that works with bzr 1.15.1?
[06:56] <AfC> (if so, pity)
[06:57] <bialix> garyvdm: mostly it's my problem, in my head
[06:57] <bialix> so I need some initial guidance
[06:57] <bialix> e.g. what is msri means, etc.
[06:57] <garyvdm> bialix: ok - questions at the moment?
[06:57] <bialix> perhaps it's very obvious for you
[06:57] <bialix> no
[06:57] <garyvdm> Ok - there is a comment for that - I think
[06:58]  * garyvdm checks
[06:58] <bialix> one more question:
[06:58] <bialix> you recently changed signals for finsihed/failed/errors
[06:58] <bialix> but all dialogs now require uodate to use new signals
[06:58] <bialix> update
[06:59] <bialix> IMO there is need for another refactoring
[06:59] <bialix> GAry, we need to chat more often
[06:59] <bialix> ok, this was last question
[07:00] <garyvdm> Hmm - can't find a comment about msri.
[07:00] <bialix> me too
[07:00] <lifeless> https://bugs.edge.launchpad.net/launchpad-code/+bug/385815
[07:00] <lifeless> poolie: ^
[07:00] <garyvdm> Ok it stands for merge_sorted_revisions_index
[07:00]  * bialix notes
[07:01] <garyvdm> There are 2 types of indexes - before its filtered - msri and after - just called index
[07:02] <bialix> so msri represent a graph?
[07:02] <poolie> jml, igc points out that i also need to specially test upgrading dev6 to dev7
[07:02] <poolie> jelmer may have a patch for this
[07:02] <garyvdm> an index for a revision in merge_sorted_revisions
[07:02] <AfC> I guess we'll have to downgrade to bzr 1.14.1. Again.
[07:03] <bialix> AfC: qbzr has compatible releases
[07:04] <AfC> bialix: that is profoundly fascinating.
[07:04] <poolie> igc could you read just the news in https://code.edge.launchpad.net/~mbp/bzr/385103-format-name/+merge/7321
[07:04] <bialix> :-P
[07:04] <poolie> oeuthaouth
[07:13] <hchen59> Hi, one question: I downloaded .tar.gz file from one project in http://bzr.linuxfoundation.org/unofficial/, extracted to local disk, I found no files except .bzr directory. I tried several bzr commands, while failed to extract version from local bzr repository( some big files in .bzr/repository/indices, I think they are local repository). So which command I should use to extract files? Thanks
[07:13] <bialix> bzr co
[07:15] <hchen59> [root@hchen59 ispras-moblin-misc-test]# bzr co
[07:15] <hchen59> bzr: ERROR: File exists: u'/home/git/ispras-lsb/ispras-moblin-misc-test/.bzr': [Errno 17] File exists: '/home/git/ispras-lsb/ispras-moblin-misc-test/.bzr'
[07:16] <bialix> what tell you `bzr info`?
[07:17] <hchen59> [root@hchen59 ispras-moblin-misc-test]# bzr info
[07:17] <hchen59> Standalone tree (format: pack-0.92)
[07:17] <hchen59> Location: branch root: .
[07:17] <lifeless> hchen59: run 'bzr checkout .'
[07:17] <hchen59> Related branches: parent branch: /home/git/ispras-lsb/misc-test
[07:18] <jml> spiv: btw, what's the status of that RPC bug?
[07:18] <hchen59> [root@hchen59 ispras-moblin-misc-test]# bzr checkout .
[07:18] <hchen59> bzr: ERROR: File exists: u'/home/git/tmp/ispras-moblin-misc-test/.bzr': [Errno 17] File exists: '/home/git/tmp/ispras-moblin-misc-test/.bzr'
[07:18] <bialix> hchen59: what `bzr status` say?
[07:19] <spiv> jml: it's a small patch (100 line diff), still waiting for review.
[07:20] <jml> spiv: ta.
[07:20] <hchen59> bzr status => list a lot of files: " removed: ....."
[07:21] <jml> spiv: poolie offered to review it on our recent phone call.
[07:21] <jml> hchen59: 'bzr revert'
[07:21] <poolie> igc, wow, that's pretty cool!!
[07:21] <poolie> igc: what does 'settings/ignores' do?
[07:22] <poolie> i thought it'd change the .bzrignore file but apparently not?
[07:22] <igc> poolie: edits the per-user ignore file
[07:22] <lifeless> totally freezing cold
[07:22] <igc> poolie: editing of branch-specific config files is coming this weekend
[07:22] <poolie> :)
[07:22] <jml> lifeless: I've got further, but I'm now blocked again.
[07:22] <igc> poolie: along with a nicer status display
[07:22] <lifeless> jml: talk to me
[07:23] <hchen59> great... bzr revert works, files extracted. While it would revert to version before ? how to check current bzr version?
[07:23] <poolie> it'd be nice to be able to see unmodified files too
[07:23] <poolie> as a way to kick off editing them
[07:23] <igc> poolie: right
[07:23] <jml> lifeless: fetch lp:~jml/bzr/default-stacking-bug-385132 and take a look at the diff.
[07:23] <lifeless> hchen59: it looks like whoever made the tarball was a little unused to bzr
[07:24] <jml> (or give me a moment to do paste shenanigans)
[07:24] <lifeless> I have it
[07:24] <jml> http://paste.ubuntu.com/193242/ -- the failure I now get
[07:24] <jml> I've made one of the two blackbox tests pass.
[07:24] <igc> poolie: try https://code.edge.launchpad.net/~jameinel/bzr/1.16-chkmap-updates for a preview of the status display coming
[07:24] <igc> bialix: ^^^
[07:25] <bialix> igc ?
[07:25] <igc> poolie: sorry, wrong paste ...
[07:25] <hchen59> ok, i see, for current bzr revision, I just bzr log, and check top one, right?
[07:25] <lifeless>              final_stack_pwd = response[9] or None
[07:25] <lifeless> +            if final_stack_pwd:
[07:25] <lifeless> +                final_stack_pwd = transport.abspath(final_stack_pwd)
[07:25] <lifeless>              remote_repo = remote.RemoteRepository(repo_bzr, repo_format)
[07:25] <igc> bialix, poolie: lp:~ian-clatworthy/bzr-explorer/better-wt-view
[07:25] <jml> yeah, that won't work if final_stack_pwd is an absolute url, IIUC.
[07:25] <lifeless> abspath('') != '', I think
[07:25] <bialix> ok!
[07:26] <jml> lifeless: that's why it's guarded?
[07:26] <igc> bialix: ui not hooked up to a model yet
[07:26] <fullermd> What's the difference between a selftest FAIL and ERROR?
[07:26] <jml> fullermd: FAIL = failed assertion
[07:26] <jml> fullermd: ERROR = unexpected error
[07:26] <lifeless> jml: paging in
[07:27] <jml> lifeless: ta
[07:27] <lifeless> jml: I think we serialise None as '', so thats why
[07:27] <fullermd> So either one is bad.  Lovely.
[07:27] <hchen59> Thanks guys
[07:27] <jml> lifeless: bool('') is False, so the line above will guarantee it's None, and the if will make sure abspath is called only if it's a non-empty string.
[07:29] <lifeless> jml: so
[07:29] <lifeless> Is 'extra' well, extra?
[07:30] <jml> lifeless: I'm not sure what extra is there for. It's part of the smart server test fixture, afaict.
[07:30] <lifeless> right
[07:30] <lifeless> so the path shouldn't be showing
[07:30] <igc> poolie: so the most important part of explorer so far is the "Bazaar" menu - that's what's going in qbzr-eclipse and (hopefully) TortoiseBzr soon
[07:30] <jml> it's in the test because the external URL is bzr://localhost:NNNN/extra/stack-on
[07:31] <igc> poolie: and one other thing, if you have bzr-gtk installed, try ...
[07:31] <igc> bzr explorer --gtk
[07:31] <lifeless> jml: no
[07:31] <igc> that runs the gtk applets instead of the qbzr ones
[07:31] <lifeless> +        self.make_branch('stack-on', format='1.9')
[07:31] <spiv> The smart server test support intentionally sets up a server with 'extra' as part of the path the flush out some path translation issues.
[07:31] <lifeless> The set_default_stack_on is setting a bad path
[07:32] <lifeless> it should set '/stack-on'
[07:32] <lifeless> jml: or listen to spiv :)
[07:32] <lifeless> jml: specifically, "chroot-93074512:///extra/stack-on/"  is not valid in the chroot
[07:33] <jml> http://paste.ubuntu.com/193245/
[07:33] <jml> there's the error without it.
[07:33] <lifeless> jml: thats better; thats a client side issue
[07:34] <lifeless> jml: so lp sets abs paths?
[07:34] <spiv> jml: you may find -Dhpss -Eallow_debug makes the test output more helpful (or merely more verbose)
[07:34] <lifeless> spiv: IIRC server/extra == '/' in the chroot ?
[07:35] <spiv> lifeless: right
[07:35] <lifeless> jml: so the http://paste.ubuntu.com/193245/ case is more correct
[07:35] <jml> http://paste.ubuntu.com/193248/ -- more debug output
[07:36] <lifeless> jml: it means that path translation is not being done correctly.
[07:37] <jml> lifeless: ok.
[07:37] <lifeless> jml: specifically, '/foo/bar/' in the chroot needs to be turned into '../foo/bar' or something similar
[07:37] <bialix> igc: nice
[07:37] <lifeless> server side
[07:37] <lifeless> because / is not really an absolute url
[07:37] <bialix> igc: new wt view is nice
[07:37] <igc> bialix: thanks
[07:37] <lifeless> jml: there is code to do this, let me dig a sec
[07:38] <jml> lifeless: at the moment I'm doing:
[07:38] <jml>             final_stack_pwd = urlutils.relative_url(
[07:38] <jml>                 target_transport.base, repository_policy._stack_on_pwd)
[07:38] <spiv> So the server says the final_stack_pwd in the result is /stack-on, where the right answer would be /extra/stack-on (or perhaps a path relative to the path of the request).
[07:38] <lifeless> spiv: extra isn't known by the server
[07:38] <lifeless> spiv: has to be relative
[07:38] <spiv> Sure.
[07:39] <lifeless> spiv: its an aspect /of/ the server. Think http mapped servers
[07:39] <spiv> Btw, SmartServerRequest.translate_client_path has one direction of this.
[07:40] <lifeless> repo_relpath
[07:40] <jml> spiv: how do I dump stuff into the debug log?
[07:40] <lifeless> bzrlib/smart/bzrdir.py +84
[07:41] <lifeless> jml: debug(...)
[07:41] <lifeless> or mutter I think
[07:41] <spiv> Requests actually know the /extra, IIRC, it's stashed in self._root_client_path or somesuch.  But as lifeless is saying you can only adjust for paths inside requests, if the request itself was addressed to one HTTP URL by the client then the HTTP server did magic before handing it off to bzr we don't necessarily know about that...
[07:42] <spiv> (Although I believe HTTP servers can pass that info along to the bzr-wsgi glue, perhaps not heavily tested though)
[07:42] <spiv> jml: I generally use (bzrlib.trace.) mutter
[07:42] <fullermd> Last time I looked at setting up bzr+http, it occured to me that I was gonna need a crappile more path translation smarts than I had the slightest idea how to put in place   :|
[07:42] <lifeless> fullermd: it is documented
[07:43] <fullermd> Only AIR in a way that makes sense if all requests are rooted at the same place.
[07:43] <lifeless> spiv: wsgi can do it but its fragile and best to avoid IMO
[07:43] <jml> 2.896  target_transport.base: chroot-96675856:///to/
[07:43] <jml> 2.896  repository_policy._stack_on_pwd:chroot-96675856:///
[07:43] <jml> 2.897     result:   ('.', 'no', 'no', 'yes', 'Bazaar RepositoryFormatKnitPack6 (bzr 1.9)\n', 'Bazaar-NG meta directory, format 1\n', 'Bazaar-NG meta directory, format 1\n', 'True', '/stack-on', '..', '')
[07:43] <spiv> lifeless: I meant specifically the bzrlib's wsgi app, rather than wsgi intrisically.
[07:43] <lifeless> spiv: so did I
[07:43] <lifeless> spiv: :P
[07:44] <fullermd> But when /x and /y aren't peers...
[07:44]  * fullermd watches selftest wind down.
[07:44] <lifeless> fullermd: there is a limit to magic, obviously.
[07:44] <jml> lifeless: so you can see that's returning a relative stack_on_pwd
[07:44] <fullermd> Yah.  But withotu breaking that limit, it won't do what I want, so it doesn't run.
[07:44] <lifeless> jml: no
[07:44] <lifeless> jml: the leading / is the problem
[07:45] <jml> but the stack_on.startswith('/)
[07:45] <lifeless> jml: you need the code from _repo_relpath
[07:45] <lifeless> jml: oh yes, indexed variables suck yada yada
[07:45] <fullermd> Well, that was "fun"...
[07:45] <fullermd> FAILED (failures=12, errors=84, known_failure_count=12)
[07:45] <fullermd> 2039 tests skipped
[07:45] <lifeless> jml: anyhow; the way those two variables interact isn't something I totally get. I didn't write it ;)
[07:46] <jml> lifeless: me neither. ISTR that 'stack_on' is what's actually in the config file & 'stack_on_pwd' is how it should be interpreted.
[07:46] <lifeless> jml: I think so
[07:46] <lifeless> anyway
[07:47] <lifeless> with a smart server a non-abs url isn't usable
[07:47] <lifeless> and a root relpath fragment isn't usable either
[07:47] <lifeless> so I think
[07:47] <lifeless> if stack_on and stack_on[0] == '/': # fix up
[07:48] <lifeless>     segments = ['..' * len(stack_on.split('/'))
[07:48] <lifeless>     stack_on = '/'.join(segments + stack_on.split('/'))
[07:48] <lifeless> vaguely
[07:48] <jml> and what for stack_on_pwd?
[07:49] <lifeless> dunno
[07:49] <lifeless> see what happens first
[07:49] <jml> snrk
[07:49] <jml> ok
[07:49] <lifeless> my emulator is too small
[07:52] <jml> http://paste.ubuntu.com/193256/
[07:53] <jml> I think maybe all of the ../ should go into stack_on_pwd
[07:53] <lifeless> jml: looks like we need to say that if stack_on == '/', stack_on_pwd should be ''
[07:53] <lifeless> or '.'
[07:54] <lifeless> jml: no, because if stack_on == '/'+ anyything, stack_on_pwd is ignored
[07:55] <jml> lifeless: stack_on_pwd = '' -> http://paste.ubuntu.com/193258/
[07:55] <jml> stack_on_pwd = '.' -> http://paste.ubuntu.com/193259/
[07:56] <lifeless> stack_on has too many ..'s
[07:56] <lifeless> uhm
[07:57] <igc> jml, jelmer: see http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20090605165828.GA4605%40vernstok.nl%3E
[07:57] <lifeless> perhaps stack_on_pwd should be used to normalise stack_on somewhat
[07:57] <lifeless> that is, the ..'s from stack_on_pwd shrink stack_on
[07:59] <jml> lifeless: something like this? http://paste.ubuntu.com/193260/
[08:00] <jml> (it doesn't work of course. sanity checking)
[08:01] <lifeless> no
[08:01] <lifeless> you're replacing the pwd with the ..'s from the stack_on
[08:01] <lifeless> I mean adjust by
[08:01] <lifeless> so segments = ['..'] * (len() - stack_on_pwd.count('..')) #sketch
[08:02] <lifeless> thats clearly wrong; presumably we have a path joining function somewhere
[08:03] <spiv> (not following closely, but there's urlutils.pathjoin)
[08:03] <lifeless> jml: or the stack_on version we had before
[08:04] <lifeless> jml: with stack_on = pathjoin(stack_on_pwd, stack_on)
[08:04] <lifeless> and stack_on_pwd = '.'
[08:11] <jml> so, stack_on_pwd = '.', and then calculate how to get from target_transport.base to /foo/bar/baz as a relative path.
[08:12] <lifeless> jml: no. I think you've gottenconfused.
[08:12] <lifeless> jml: we have two inputs
[08:12] <lifeless> stack_on and stack_on_pwd
[08:12] <lifeless> we know that combining them in the server chroot works
[08:12] <lifeless> we want two outputs
[08:13] <jml> so far I am with you.
[08:13] <lifeless> such that combining those two and the clients url for the bzrdir we created will will work from the client
[08:14] <lifeless> there are several options here
[08:14] <lifeless> I need to call it 'done' for the day; possibly the most simple thing is to say
[08:15] <lifeless> '/' stack_on paths are not usable in the smart server. When we see one we will take the transport to the thing we stacked on and transform it as per _repo_relpath
[08:15] <lifeless> so toss out all the data
[08:18] <poolie> jml, are you referring to spiv's patch for bug 380314?
[08:18] <jml> poolie: that one, yes.
[08:19] <spiv> poolie: diff viewable at https://code.edge.launchpad.net/~spiv/bzr/stacking-friendly-revision-history-verb/+merge/7314
[08:20] <jml> igc: did you end up doing your eol tweak?
[08:20] <lifeless> jml: anyhow, there are several ways you could do it. I don't have a preference.
[08:20] <jml> lifeless: ok, thanks.
[08:20] <jml> lifeless: I'll figure something out.
[08:20] <igc> jml: yes. It's landed I believe
[08:20]  * igc checks
[08:20]  * jml checks too
[08:21] <mwhudson> jml: how do you get -D hpss like stuff in the selftest's .bzr.log ?
[08:21] <mwhudson> i thought it was -E hpss
[08:21] <jml> igc: should I mark https://bugs.edge.launchpad.net/bzr/+bug/362030 as Fix Released then?
[08:21] <mwhudson> but that doesn't seem to be it
[08:21] <jml> mwhudson: -Dhpss selftest -Eallow_debug
[08:21] <mwhudson> ah
[08:22] <mwhudson> ta
[08:24] <igc> jml: just did it - thanks for reminding me
[08:24] <jml> igc: cheers.
[08:27] <poolie> jml, spiv, review done
[08:27] <poolie> and S says "get ready!"
[08:27] <poolie> so i will
[08:27] <spiv> poolie: thanks
[08:27] <jml> poolie: thanks!
[08:28] <jml> poolie: have a good evening :)
[08:28] <jml> just requested bzr branch be mirrored immediately
[08:28] <jml> yay
[08:29] <poolie> 2a format sent to pqm
[08:29] <igc> night all - good luck jml with the release
[08:29] <jml> igc: g'night.
[08:29] <jml> igc: thanks for your help :)
[08:30] <poolie> the launchpad workflow for bugs and code reviews is getting really nice
[08:30] <poolie> it could be even better but it's pretty helpful
[08:30] <jml> yeah.
[08:34] <spiv> jml: have replied to poolie's review, will do the minor tweaks and send to PQM
[08:35] <jml> spiv: music to my frosty ears
[08:36] <lifeless> poolie: I'm still really concerned that people will try 2 and then be wedged irrecoverably
[08:38] <lifeless> vila: jml: re bialix's reported problem can you clarify.
[08:39] <jml> lifeless: running the script client side only affects the upload copy of the branch
[08:39] <spm> spiv: pqm is still working for you then?
[08:39] <jml> lifeless: it won't affect the mirrored copy.
[08:39] <lifeless> jml: but the mirrored copy is only accessed over http right?
[08:40] <spiv> spm: we will find out shortly!
[08:40] <jml> lifeless: it's also accessible over bzr+ssh & sftp
[08:40] <lifeless> sftp like http is VFS anyway
[08:40] <jml> lifeless: where you'll get the mirrored copy iff you lack write access to the branch.
[08:40] <lifeless> ok
[08:41] <lifeless> so this raises the 'when is lp bulk fixing things'
[08:41] <lifeless> question
[08:41] <jml> yes.
[08:42] <lifeless> ok
[08:42] <lifeless> well, i'm going to ring poolie quickly and then -> gone
[08:42] <jml> ok.
[08:42] <jml> thanks for the help w/ the release.
[08:42] <lifeless> np
[08:48] <lifeless> jml: are you cuttting the release tonight?
[08:48] <jml> lifeless: yes.
[08:48] <lifeless> jml: or do you think it will be tomorrow? I have a change I want to make that poolie and I don't quite agree on.
[08:49] <spiv> spm: my merge request just came and went in a flash...
[08:49] <jml> lifeless: it's got to be tonight, I'm afraid.
[08:50] <jml> or rather.
[08:50] <jml> it's got to be the 11th.
[08:54] <lifeless> what happens on the 12th?
[08:55] <lifeless> anyhow, you're doing rc1 right?
[08:55] <fullermd> A plague of locusts o'er the land.
[08:55] <lifeless> jml: ^
[08:56] <jml> lifeless: yes, rc1
[08:56] <lifeless> we can always change it between rc and release
[08:56] <lifeless> so don't block on this
[08:56] <jml> lifeless: great news :)
[09:05] <tmetro> What's the best way to get in touch with the maintainer of the bzr packages on backports.org? I suspect the Debian packaging tools view version 1.5 as newer than 1.13. Although it looks like 1.13 has been around since April, so I would have expected someone to notice this before now.
[09:05] <lifeless> tmetro: dpkg considers 1.5 < 1.13
[09:05] <lifeless> tmetro: there used to be contact details on backports.org
[09:05] <lifeless> a bug tracker of some sort
[09:07] <tmetro> Hmmm...I have 1.5 installed, even though I have backports as a repository. It doesn't think there is a newer version. Trying to explicitly install bzr=1.13.1-1~bpo50+1 results in:
[09:07] <tmetro> bzrtools: Depends: bzr (< 1.6~) but 1.13.1-1~bpo50+1 is to be installed.
[09:08] <tmetro> OK, I can check backports.org, if they're the responsible party for creating the builds, and not just hosting them.
[09:08] <lifeless> tmetro: they certainly are.
[09:08] <tmetro> ok, thanks.
[09:08] <fullermd> tmetro: Er, that's telling you your installed bzrtools won't work with 1.13.1
[09:08] <lifeless> you will need to install bzrtools *and* bzr at the same time because bzrtools is version locked to a specific bzr release.
[09:10] <tmetro> But it should pull in bzrtools automatically...regardless, something is broken if I have to specify an explicit version. (Unless I added an apt config that I'm forgetting about.)
[09:10] <lifeless> tmetro: IIRC with backports you have to list each thing you want
[09:10] <lifeless> so you'd need to add bzr and bzrtools to your config
[09:11] <tmetro> Ah, I see, they only have 1.5 of bzrtools on backports.org.
[09:11] <tmetro> http://backports.org/debian/pool/main/b/bzrtools/
[09:12] <tmetro> I'll send them an email...thanks.
[09:14] <spiv> spm: yep, lp: URL in merge request still vanishing without a trace.  I'm going to workaround it with http:// again.
[10:02] <jml> ok. I think I've got this critical bug sorted.
[10:03] <jml> now checking that it fixes the original problem.
[10:03] <awilkins> Does .bzrrules work for in-tree content filtering rules?
[10:05] <awilkins> And I'm having "trouble" with eol filtering
[10:13] <spiv> jml: my branch landed, btw
[10:13] <jml> spiv: cool!
[10:13]  * jml updates the bug 
[10:14] <jml> spiv: I have a patch you can review. I'm blocked on testing it against Launchpad though. :(
[10:23] <jml> vila: hello
[10:35] <awilkins> Ok, correct me if I'm wrong .. If I have a folder that contains a mix of LF-ended and CRLF-ended (*.cs) files, and I add a rule [name *.cs], then after a touch, on a Windows working tree, the result should be that i) bzr reports that LF files created as LF and saved as CRLF since checkout (but no other change) are unchanged 2) LF files that have not been re-EOLed have been changed
[10:36] <awilkins> Not sure about the inverse though.
[10:37] <awilkins> Dammit, I hate tools that switch EOLs on you
[10:39] <awilkins> On linux shouldn't it take files that were created CRLF, check them out as LF.. then what. The file hasn't changed (according to the filter rule, if it's "Native") but should the stored version get flipped to LFs or stay as CRLF?
[10:47] <jml> awilkins: sorry, I don't really have a clue about that.
[10:47] <awilkins> (the hating-tools-that switch EOl is directed at SharpDevelop, not Bazaar)
[10:47] <jml> spiv: so this fix affects both the client and the server.
[10:48] <awilkins> jml: I'm trying to figure it out
[10:48] <jml> spiv: 1.15 is completely broken wrt Launchpad's use of stacking.
[10:57] <stbuehler> bzr needed nearly 30 seconds to push one commit to svn; imho that is not really acceptable: http://paste.lighttpd.net/187
[10:57] <stbuehler> any chances this will be fixed?
[11:02] <jml> spiv: https://code.launchpad.net/~jml/bzr/default-stacking-bug-385132/+merge/7330
[11:02] <jml> (or any other bzr-core member)
[11:05] <bialix> hi, anybody can suggest me the way to find unused imports in python code?
[11:06] <bialix> will be great if this method will look into bzr lazy_imports too
[11:06] <spiv> jml: glancing now
[11:06] <jml> spiv: ta.
[11:06] <jml> bialix: pyflakes
[11:07] <jml> bialix: there's a branch of pyflakes that is bzr lazy_imports aware
[11:07] <spiv> jml: It's not immediately clear to me that given "full_path = self._root_client_path + final_stack[1:]", that calculating the relative_url of that against target_transport.base is sane.
[11:08] <spiv> jml: it certainly feels odd...
[11:08] <jml> bialix: if you use emacs, you can also hook things up so that pyflakes runs all the time (using flymake).
[11:08] <jml> spiv: what did you expect?
[11:08] <spiv> jml: hmm, so s/full_path/client_path/ for clarity, I think
[11:08] <bialix> no, I'm not emacs user
[11:08] <spiv> jml: but, the target_transport.base is presumably ignorant of any _root_client_path
[11:09] <spiv> jml: and may be pointing at a chroot or something, right?
[11:09] <spiv> jml: I would understand relative_url(_root_client_path, client_path)
[11:09] <bialix> I guess this is the branch you mentioned https://code.launchpad.net/~mwhudson/pyflakes/support-lazy-imports
[11:11] <jml> bialix: yeah, I guess so too :)
[11:11] <jml> bialix: I don't actually use that one.
[11:11] <jml> spiv: changed.
[11:11] <spiv> jml: but I don't see why relative_url([backing_transport_url], [a_path_adjusted_for_clients_view]) makes sense.
[11:12] <spiv> This is potentially a failing of me rather than the code, but you'll need to convince me :)
[11:12] <jml> I've changed it to  relative_url(_root_client_path, client_path)
[11:12] <spiv> jml: cool.  does it still work? :)
[11:12] <awilkins> Erm, I think eol support is broken, but that could just be me
[11:12] <jml> yes.
[11:12] <spiv> Even better!
[11:13] <jml> awilkins: it's possible. We landed some patches about that today.
[11:13] <awilkins> Files that you commit on Linux with LF endings don't expand to CRLF on windows, even with eol=naitve
[11:13] <jml> awilkins: bug 362030 and bug 379370
[11:13] <awilkins> But files with CRLF on Windows with eol = native do collapse to LF
[11:14] <spiv> jml: omit self.reset_smart_call_log() calls if you aren't going to inspect the call log in the test
[11:14] <jml> spiv: done.
[11:18] <bialix> pyflakes has no help?
[11:19] <bialix> I need just to run it and specify modules? or I can pass the entire package
[11:20] <jml> bialix: you pass it filenames, I believe.
[11:20] <spiv> jml: reviewed (approve; no other issues)
[11:20] <jml> spiv: thanks. any thoughts on the fact that bzr 1.15 will break on pushing new branches to Launchpad?
[11:20] <spiv> jml: I don't have any great ideas about what to do for old clients.
[11:21] <lifeless> jml: are there client side changes needed?
[11:21] <jml> lifeless: yes.
[11:21] <bialix> cool
[11:21] <lifeless> jml: thats surprising to me.
[11:21] <lifeless> if 1.15 is broken, 1.15.2
[11:21] <bialix> pyflakes even suggest modules to make them lazy
[11:21] <bialix> wow
[11:21] <lifeless> or bump the server verbs if needed.
[11:22] <lifeless> I'm not here.
[11:22]  * lifeless hides
[11:22] <jml> bialix: #divmod if ever you have detailed pyflakes questions.
[11:22] <spiv> Launchpad (and potentially bzr core) could peek at the 'Software version' header and reply with UnknownMethod for that verb...
[11:22] <bialix> jml: I guess suggestions about lazy makes sense only for bzr code
[11:22] <bialix> e.g.
[11:23] <jml> lifeless, spiv: I think this is something that we can resolve over the next week before the final release.
[11:23] <spiv> jml: +1
[11:23] <bialix> C:\work\Bazaar\repos\qbzr-repo-1.9\trunk\lib>pyflakes commands.py
[11:23] <bialix> commands.py:21: import of 'os' could be lazy
[11:23] <bialix> commands.py:22: import of 'sys' could be lazy
[11:23] <bialix> commands.py:23: import of 'ui' could be lazy
[11:23] <bialix> commands.py:25: 'get_cmd_object' imported but unused
[11:23] <bialix> commands.py:25: 'register_command' imported but unused
[11:23] <bialix> commands.py:32: 'QtCore' imported but unused
[11:23] <bialix> mwhudson: hi
[11:23] <lifeless> heh. note that making things lazy that will be needed for most commands is unneeded overhead.
[11:23] <jml> bialix: the lazy branch might actually be up for review on divmod's tracker.
[11:23]  * jml shrugs
[11:24] <bialix> so twisted uses lazy imports too?
[11:24] <spiv> No.
[11:24] <spiv> (But maybe they should!)
[11:25] <bialix> jml: pyflakes even works for the packages! wow
[11:25] <bialix> thx!!!
[11:26] <spiv> bialix: pyflakes is pretty excellent :)
[11:26] <bialix> yeah!
[11:27] <bialix> this is what I need for so long
[11:29] <jml> bialix: also, since it's really fast, it's something that you might be able to always have running & integrate with your editor.
[11:30] <bialix> or as part of test suite
[11:31] <jml> I guess.
[11:31] <jml> it still has false positives.
[11:31] <jml> for Launchpad, we have a wrapper around bzr send that does a pyflakes check on all changed files & includes that in the body of the email.
[11:32] <jml> so they can be caught at review time.
[11:32] <jml> that seems to work ok.
[11:32] <awilkins> Hmm, the eol filtering applies to initial checkouts, but not to subsequent updates
[11:32] <awilkins> Plus I've now noticed the "you checked it out fresh but everything is changed" bug
[11:33] <fullermd> awilkins: That (initial but not update) behavior is one of the things I noticed playing with keywords that just stopped it dead.
[11:33] <awilkins> Is there a bug for that?
[11:33] <fullermd> Dunno.
[11:34] <awilkins> It's also not clear to me what retro-active behaviour should be on e.g. - files that were created CRLF but are now content filtered and should be LF in storage
[11:34] <awilkins> (created with no filter)
[11:34] <fullermd> I didn't file one.  It seems like such an absolute showstopper that I assumed it had to be "incomplete", not "unknown bug".
[11:34] <awilkins> igc: Ping?
[11:35] <fullermd> He left about 3 hours ago.
[11:35] <awilkins> Darn
[11:36]  * awilkins forsees an "eol" tag for the bug tracker
[11:36] <fullermd> Well, since I saw it with keywords, I'd assume it's more "filter" than "eol".
[11:39] <bialix> mere mortals most likely find eol, though
[11:40] <awilkins> And EOL and ignore are the only filters as yet
[11:40] <awilkins> Well, in the default
[11:42] <spiv> fullermd, awilkins: I think igc would appreciate bug reports
[11:42]  * awilkins is filling out one and also composing overall mail of all bugs he is aware of with feature
[11:49] <fullermd> My experience (and memory of it, come to that) is stale.  Bug reports of "I sorta remember way back when X happened" are rarely appreciated   :p
[11:54] <jml> noooo, one test fails.
[11:55] <jml> http://paste.ubuntu.com/193374/
[11:59] <GPHemsley> Is there a way to uninit?
[12:02] <jml> GPHemsley: what precisely do you mean?
[12:03] <GPHemsley> I did an init
[12:03] <GPHemsley> and now I want to undo it
[12:03] <jml> GPHemsley: remove the .bzr file from the directory inited.
[12:03] <jml> GPHemsley: beware, you'll lose any history you've made.
[12:04] <GPHemsley> no command, then?
[12:04] <GPHemsley> no history
[12:05] <jml> GPHemsley: no command.
[12:06] <GPHemsley> now, would you recommand creating a trunk/ directory?
[12:06] <jml> bzr init trunk
[12:06] <GPHemsley> OK, but I'm asking if you think that's a good idea?
[12:07] <jml> GPHemsley: it really depends on the broader context.
[12:07] <jml> GPHemsley: a lot of the time I do this:
[12:07] <jml> bzr init-repo <project-name>
[12:07] <jml> bzr init <project-name>/trunk
[12:08] <GPHemsley> any way to directly convert an init to an init-repo?
[12:08] <fullermd> No more than there are ways to directly convert a submarine to a skyscraper.
[12:08] <GPHemsley> fair enough
[12:09] <jml> GPHemsley: there are things you can do, but they are all a pain, and rarely worth it.
[12:09] <jml> Certainly not if this is for a new project.
[12:09] <GPHemsley> k
[12:09] <fullermd> They're totally different things; it doesn't make sense to convert something that you'd init into something that you'd init-repo.
[12:11] <GPHemsley> cd <project-name>; bzr init-repo .
[12:11] <GPHemsley> is this same thing, right?
[12:11] <GPHemsley> (as the first command above)
[12:11] <jml> yep.
[12:12] <GPHemsley> and then I can cd trunk and bzr init .
[12:12] <GPHemsley> ?
[12:12] <jml> for reference, when you do 'init-repo', you're saying "this directory is going to be a shared repository; a bucket where all of the branches beneath it store their data"
[12:13] <GPHemsley> right
[12:13] <jml> GPHemsley: or just bzr init trunk
[12:13] <GPHemsley> I get this straight eventually
[12:13] <GPHemsley> s/I/I'll/
[12:13] <GPHemsley> well, trunk already exists
[12:13] <GPHemsley> but no matter, it's done
[12:13] <jml> GPHemsley: when you say "bzr init foo", you're saying "I'm starting a new branch -- a new line of development --called 'foo'"
[12:13] <GPHemsley> oh
[12:13] <GPHemsley> hmm
[12:14] <jml> you tend to need at least one of these per project :)
[12:14] <GPHemsley> yeah
[12:14] <GPHemsley> :)
[12:49] <GPHemsley> can bzr store symlinks
[12:49] <GPHemsley> ?
[12:50] <spiv> GPHemsley: yes
[12:50] <GPHemsley> cool
[13:04] <Peng_> But can it handle them decently when you try to check out on a platform that doesn't support them?
[13:05]  * Peng_ goes /away again.
[13:26] <jml> poolie: looks like your format rename branch didn't land.
[13:38] <awilkins> Peng_: You need a plugin for them on Win32
[13:38] <Peng_> awilkins: Oh, nice.
[13:38] <awilkins> Peng_: But AFAIK NTFS does support symlinks with varying degrees of support
[13:39] <awilkins> Peng_: I think the support gets a bit better in Vista and 7
[13:40] <awilkins> Peng_: On XP it's limited to "juncton points" which only link folders on the same physical volume
[13:41] <awilkins> Vista and up support file links, cross volume links, and network symlinks (but only on servers that also support them)
[13:42] <awilkins> And by default non-admin users can't create them... nice
[13:42] <Peng_> I see. Thanks for the information. -- Eh, non-admin users can't create any symlinks, or just weird ones?
[13:42] <awilkins> Peng_: If you are a non-admin or non-elevated admin you can't create a symlink in the default config
[13:42] <awilkins> But you can change the policy
[13:43] <Peng_> ...That's dumb.
[13:43] <Peng_> Maybe it's to prevent symlink attacks?
[13:44] <awilkins> Peng_: Who knows why... perhaps only the ACL for the link is considered when accessing the file, so it could be a potential hack to create links to system files and write viruses into them
[13:46] <awilkins> Peng_: But without testing it....
[13:46] <fullermd> It's tough to get right.  They only had, what, 25 years of prior art to look at for it...
[13:47] <awilkins> Shouldn't be too hard to write into the Python library to use it though (but you'd have to throw an error about setting the policy)
[13:48]  * awilkins requires tea
[14:04]  * jml halts
[14:32] <awilkins> Does the py2exe build process strip the libraries it puts in library.zip?
[14:33] <ddaa> mostly, library.zip contains pyc files, so stripping does not aplly
[14:33] <ddaa> if there are any .dll, they'll (presumably) be in whatever state they were found on the system.
[14:33] <awilkins> ddaa: I don't mean it in the "strip stuff out of libraries" sense, sorry, I meant, does it ignore libraries for which their are no dependencies on the code
[14:34] <awilkins> E.g. - if it doesn't depend on SimpleXMLRPCServer, it won't be in library.zip
[14:34] <awilkins> (I think this may be the case)
[14:34] <ddaa> yes it does
[14:34] <awilkins> Aha
[14:34] <awilkins> That explains why bzr-eclipse doesn't work anymore
[14:34] <awilkins> CAn you just plonk the .py file in the lib folder and have it work?
[14:35] <ddaa> you need to specify some badly documented option to have setup.py include the libs you want in the zip
[14:35]  * awilkins tries the plonk-the-lib-in method
[14:35] <ddaa> that will work
[14:35] <ddaa> but it's ugly
[14:36] <awilkins> I'm not sure it does.. unless SimpleXMLRPCServer now has missing dependencies
[14:37] <bialix> you can put missing py files into library.zip
[14:37] <awilkins> bialix: Ah, but not straight into /lib ?
[14:37] <bialix> nope
[14:37] <ddaa> oh, misread what you meant :)
[14:37] <bialix> awilkins: we using another approach in QBzr
[14:38] <awilkins> the _lib folder?
[14:38] <bialix> yes
[14:38] <awilkins> Oh wait, that's gtk
[14:38] <awilkins> Ah, as well
[14:38] <bialix> so any plugin can support all required but missing libs
[14:38] <bialix> although it's a bit boring
[14:38] <awilkins> I'm jsut trying again, I don't think it killed the process that it had previously spawned
[14:39] <bialix> awilkins: are you using bzr-svn?
[14:39] <awilkins> Yes
[14:40] <bialix> then you can't rebuild bzr.exe without all svn dlls
[14:40] <awilkins> bialix: Yes, I had a win32 build env for bzr going before and it was a real pain to set up
[14:40] <bialix> or may be can
[14:41] <awilkins> bialix: Since then it's all gone kaput
[14:41] <bialix> I'm build bzr.exe for myself w/o bzr-svn
[14:41] <awilkins> bialix: You should be able to rebuild the exe as long as you have the built extensions (with a little finagling and judicious touching)
[14:42] <bialix> awilikins: in fact I think one can use compiled bzr-svn from official installer
[14:42] <awilkins> bialix: Does the python-flavoured one have the bzr-svn extensions in it yet or does it just not bundle them at all now?
[14:43] <bialix> python-based installer installs only bzr+bzrlib+docs, nothing more
[14:43] <bialix> so you agin have to install bzr-svn separately
[14:46]  * bialix never had enough patience to learn bzr-svn build process
[14:46] <awilkins> It's not fun
[14:46] <awilkins> Well, not on windows
[14:46] <bialix> one man gave me instructions
[14:46] <awilkins> On Linux it's doss easy
[14:46] <bialix> apt-get
[14:47] <bialix> ?
[14:47] <awilkins> Even building from scratch
[14:47] <awilkins> You just apt-get a few dev packages
[14:48] <bialix> I'm not sure it's entirely Windows problem. Some credits should go to svn developers
[14:48] <awilkins> Well, there is that
[14:48] <awilkins> I'm sure glad they have those prebuilt dev libs for Windows because the thought of actually building it makes the blood run cold
[14:49]  * bialix nods
[14:51] <tedg> Is there a way to regenerate the indicies?
[14:52] <tedg> I'm getting this error: bzr: ERROR: Error in data for index GraphIndex('file:///home/ted/Development/inkscape.newbzr/.bzr/repository/indices/1d2b8fb37e32a1e94a733fbc3d195756.tix').
[14:53] <awilkins> Does py2exe deliberately not compress the content of library.zip ?
[14:54] <bialix> awilkins: it's controlled by options in setup.py
[14:54] <bialix> when I wrote py2exe support in 2006 I've decided to not compress it
[14:55] <awilkins> I wonder if it might improve startup time to compress it (reduced disk IO vs CPU time)  .. I wouldn't like to guess without testing it
[14:56] <bialix> as I vaguely remembered Mark Hammond suggest to actually compress it.
[14:56] <bialix> I see what you mean
[14:56] <bialix> the difference will be really small
[14:56] <awilkins> Oh yes indeed
[14:56] <bialix> tens of milliseconds
[14:57] <bialix> in the end windows has to read 1 file
[14:57] <bialix> and will ikely this file could be cached by disk subsystem
[14:57] <awilkins> Would pyflakes tell me what bzr-elcipse is dependant on
[14:57] <bialix> no
[14:58] <bialix> but you can use modulefinder.py module from bzr.dev/tools
[14:58] <awilkins> Groovy
[14:58] <bialix> err
[14:58] <bialix> package_mf.py
[14:58] <awilkins> Ah, it's all java
[14:58] <awilkins> And makes XMLRPC calls
[14:59] <bialix> bang
[14:59] <awilkins> So I guess I just need to check what xmloutput and SimpleXMLRPCServer use
[14:59] <bialix> at least
[14:59] <bialix> yes,
[14:59] <bialix> you don't have python traceback from java, do you?
[15:00] <awilkins> bialix: It spawns a process and talks to it over a socket, so no
[15:00] <awilkins> bialix: Unless you trapped the xml server to do it
[15:01] <bialix> it was half/joke
[15:01]  * bialix tried to run eclipse and look at qbzr-eclipse. it looks very decent
[15:02] <bialix> perhaps not too serious like bzr-eclipse
[15:02] <awilkins> It's probably best I stick with it, all my users are on it
[15:02] <awilkins> For some reason, people get antsy about having new software installed
[15:04] <bialix> I'm trying to imagine "ansty"
[15:04]  * bialix cannot
[15:04] <awilkins> I think it's "the feeling of discomfort ones gets from having ants in ones pants"
[15:05] <bialix> it was second half/joke
[15:05] <bialix> don't mind
[15:05] <awilkins> Don't know how Russian you are :-)
[15:06] <bialix> may be I'm just need to sleep a bit more
[15:06] <bialix> but yes, I'm
[15:07] <Spabby> hi guys anyone awake?
[15:08]  * bialix half awake
[15:08] <Spabby> :D
[15:08] <Spabby> I'm wondering if it's possible to use bazaar to run the  way I want, my friend Google hasn't been much help
[15:08] <bialix> you want asking about bzr-svn?
[15:09] <bialix> well, bzr can't make sandwich for you
[15:09] <bialix> so it's hard to suggest you something without more details
[15:10] <Spabby> I want to have a central repo that myself and a colleague can merge to, but I want what I merge to be visible as a proper website, Ie I want to checkout a branch, edit the files, then merge back to the central server, at which point the changes are reflected on the website
[15:10] <Spabby> sorry I was typing a long sentence ;)
[15:10] <Spabby> I'm not particularly concerned about the sandwiches
[15:11] <bialix> it depends how you configure your server and bzr repo
[15:11] <bialix> look at plugins: push-and-update andd/or upload
[15:12] <bialix> or use hook on smart server
[15:12] <Spabby> there are plugins that will push and upload to a server?
[15:12] <bialix> 2 all: this question asked very frequently. Does bzr has some sort of FAQ?
[15:13] <Spabby> I've read the FAQ
[15:13] <pygi> bialix: lies, it can make a sandwich :(
[15:13] <bialix> push-and-update IMO
[15:13] <pygi> the book claims it can :(
[15:13] <Spabby> and i've googled like mad
[15:13] <Spabby> I'm not looking for easy answers, I'm just looking for some help and direction
[15:14] <pygi> Spabby: loggerhead perhaps?
[15:14] <bialix> push-and-update:
[15:14] <pygi> if I got your requirements right
[15:14] <bialix> Provide the "push-and-update" command to automate the running of 'ssh remote bzr update path' after pushing to sftp://remote/path. This allows us to keep a remote working tree up to date.
[15:14]  * pygi just came in :p
[15:14] <bialix> Spabby: does it relevant for you?
[15:14] <Spabby> yes I think so
[15:15] <Spabby> if I'm reading it correctly, after the changes have been pushed, I can trigger an update on another path
[15:15] <bialix> or, if you really need webbrowser for your repository -- loggerhead
[15:15] <Spabby> so if I checkout the bzr branch to the webroot
[15:15] <Spabby> when I push I can trigger an update on that branch?
[15:15] <bialix> if you have smart server running on your server (e.g. bzr+ssh)
[15:15] <Spabby> I'm not stupid, honest :D
[15:16] <bialix> me too
[15:16] <bialix> I'm trying to help
[15:16] <bialix> I'm just bad in English
[15:16] <Spabby> no you are helping
[15:16] <Spabby> and for that I thank you
[15:16] <Spabby> I'm reading on the push-update plugin
[15:19] <bialix> I mean bzr FAQ need more love
[15:19] <Spabby> ok
[15:19] <Spabby> I think I need to buy a good book :D
[15:22] <bialix> or just ask here
[15:24]  * awilkins should write the Bazaar book and make oodles of cash
[15:24] <awilkins> Not that I'm especially knowledgeable, just especially fond of cash
[15:24] <Spabby> I need to understand the basics I think
[15:25] <awilkins> Are you experienced with SVN or CVS?
[15:25] <awilkins> (or other VCS systems with central repo)?
[15:25] <Spabby> for someone who is fairly knowledgable in a wide sphere of IT based stuff, revision control evades me
[15:25] <Spabby> I used svn for about a year but I kept breaking it
[15:25] <Spabby> and I never really understood it
[15:25] <Spabby> well
[15:26] <Spabby> I understood how to update my working copy, and checkin changes
[15:26] <Spabby> but not how it all worked
[15:26] <awilkins> SVN is just another filesystem with the time dimension included
[15:26] <awilkins> You can go back, create absurb paradoxes, etc
[15:26]  * bialix likes paradoxes
[15:27] <Spabby> my problem with svn is that if I deleted a local file I seemed to completely break the repository
[15:27] <awilkins> That is oddd
[15:27] <Spabby> or at least my ability to checkin to the repo
[15:27] <ddaa> I would like to be able not to make it sound like a putdown, but you are clearly confused about something.
[15:28] <ddaa> But we'd need a lot more information to able to identify what you are confused about.
[15:29] <Spabby> I'm confused about a lot, it's not a criticsm
[15:29] <Spabby> I guess that the bzr repo is a database of files, and how those files have changed (at a broad level)
[15:30] <Spabby> and I understand how I can use bzr to manage my revisions on  local level by using commit
[15:30] <Spabby> but  I struggle to understand how it works in a centralized environment
[15:31] <awilkins> Spabby: In a centralized environment you would use bound branches
[15:31] <awilkins> Spabby: The commit occurs either locally_and_centrally or just centrally
[15:31] <Spabby> right
[15:32] <Spabby> I guess the process we want to use is to commit locally during development of a branch, and then centrally when you are ready to publish your changes to the project
[15:32] <awilkins> Spabby: The Bazaar development branch method is an excellent example
[15:32] <Spabby> and I guess not understanding it makes that very difficult for me to visualise how bzr would handle that
[15:32] <awilkins> Spabby: All commits to the main trunk of development are made by the patch queue manager
[15:32] <awilkins> Spabby: And only after they pass testing.
[15:33] <Spabby> is that the "Gatekeeper" from the bzr manual?
[15:33] <awilkins> One manifestation of a Gatekeeper, yes
[15:33] <Spabby> ok
[15:33] <bialix> the great and terrific one
[15:33] <awilkins> Do you have qbzr?
[15:33] <awilkins> Or bzr-gtk?
[15:33] <Spabby> I'm going to read the development branch method
[15:34] <awilkins> Just looking at the revision graph for bzr.dev would be very informative
[15:34] <Spabby> im using cl bzr on Centos ATM to try and setup the central location
[15:34] <awilkins> cl bzr ?
[15:34] <Spabby> I seem to have created the branch and commited the initial files to it
[15:35] <Spabby> command line
[15:35] <awilkins> Ah
[15:35] <awilkins> Right, what serving methods do you have available?
[15:35] <Spabby> http, sftp, ftp, or any other that can be installed if it is better
[15:35] <awilkins> (and which bzr version are you using? Last I looked the CentOS packages were quite old)
[15:35] <mattl> hey, what does this mean?
[15:36] <mattl> bzr: ERROR: Revision {daniel@daniel-watkins.co.uk-20090412154020-0fk0vbvg644oe8zo} not present in "254@1c61c228-c9dc-448a-9a81-c9cbcf67beca:trunk%2Fweb%2Fdata%2FServer.php".
[15:36] <awilkins> If you and all users have ssh access to server than that would work well
[15:36] <Tak> mattl: bzr-svn?
[15:36] <awilkins> Otherwise, http only works both ways with effort
[15:36] <Spabby> yes we have ssh access
[15:36] <mattl> Tak: this was an svn that was converted to bzr.
[15:36] <Spabby> this is a development server hosted on our lan
[15:36] <Spabby> so ssh would be fine
[15:36] <awilkins> Spabby: Use bzr+ssh then, that's probably the least-setup way to do it
[15:37] <Spabby> how do I find out version number sorry awilkins
[15:37] <awilkins> `bzr version`
[15:37] <ddaa> mattl: that means some revision in the svn repo was committed with bzr, but it's missing from your bzr repo (because bzr commit on svn repo do not store the parent revisions of a merge in the svn repo)
[15:37] <Spabby> ah
[15:37] <Spabby> you'd think they would include that in the default command list
[15:37] <Spabby> im running 1.3.1
[15:37] <mattl> ddaa: so, how do we fix this?
[15:37] <awilkins> Spabby: That's the old version I was referring to
[15:37] <Spabby> ok
[15:37] <ddaa> mattl: bzr is normally about to deal with this, they are called ghost revisions
[15:38] <Spabby> i'll try and get an update
[15:38] <ddaa> mattl: so this is a bug that this is causing a crash
[15:38] <awilkins> Spabby: If you have root it's not hard to build from sources
[15:38] <mattl> ddaa: is there a way i can skip these revisions?
[15:38] <Spabby> ok
[15:38] <Spabby> I will do that now :D
[15:38] <awilkins> Spabby: But things will still work at the moment
[15:38] <ddaa> mattl: as I told you, it's a bug that the presence of ghost revisions is causing any problem at all.
[15:38] <Spabby> ah ok
[15:39] <Spabby> so I have a repo setup
[15:39] <awilkins> Your client machine should be able to `bzr checkout bzr+ssh://server/full/path/to/branch
[15:39] <ddaa> mattl: you cannot "skip them", it's just not the way bzr-svn works.
[15:39] <Spabby> at least if I do "bzr info" I see the branch
[15:39] <mattl> ddaa: right, so... should i try a later version of bzr, or is my project repo screwed?
[15:39] <Spabby> how do I check that out to my local pc?
[15:39] <awilkins> `bzr checkout bzr+ssh://server/full/path/to/branch`
[15:39] <ddaa> mattl: if you can identify the bzr branch that was merged into svn prior to the import you are using, you can fill the ghost revisions using "bzr fetch-ghosts"
[15:40] <ddaa> mattl: you should ALWAYS try the latest version of bzr and bzr-svn when you have any sort of problem.
[15:40] <awilkins> Spabby: That produces a bound checkout - commits will be mirrored to the server
[15:40] <awilkins> Spabby: But all the revisions are also held locally
[15:40] <Spabby> and if there are conflicts I will be prompted to merge?
[15:40] <awilkins> Spabby: Yes
[15:40] <Spabby> excellent
[15:40] <awilkins> Spabby: Or update
[15:40] <Spabby> I thank you
[15:41] <ddaa> mattl: as I told you, your repo is not screwed, the presence of ghosts revision is not a problem, bzr and bzr-svn SHOULD be able to deal with them. If you still have this problem using the latest bzr, you should file a bug so bzr can be fixed.
[15:42] <ddaa> actually, ghost revisions is a feature
[15:42] <ddaa> as it allows round-tripping of bzr commits through a svn repo.
[15:45] <Spabby> awilkins that checked out great
[15:45] <Spabby> thanks again
[15:45] <awilkins> Spabby: You're welcome. Soon you'll progress to multiple branches in a no-trees repo and switch between them like a gazelle
[15:50] <Spabby> that worked great
[15:51] <Spabby> but when I commit my changes to the central, is there any way I can force an update on the branch there?
[15:53] <awilkins> Spabby: THere are plugins
[15:53] <awilkins> Spabby: Or you could use a server side hook
[15:53] <Spabby> server side hook sounds intriging
[15:56] <bialix> but anyway you need plugin on server side to hook it in
[15:57] <Spabby> I'm guessing push and commit are not the same thing
[15:57] <awilkins> Nope
[16:04] <Spabby> sorry to perster you awilkins, im using tortoiseBzr on my local machine, any idea how I can get it to use the plugin automirror?
[16:09] <bialix> Spabby: so now you're on Windows? great
[16:09] <Spabby> :D
[16:09] <Spabby> only temporarily
[16:09] <Spabby> actaully scratch that
[16:09] <Spabby> both of us will be working on linux boxes
[16:10] <bialix> you need to get the copy of this plugin
[16:10] <bialix> so why you using tvzr?
[16:12] <Spabby> I'm working on my windows box atm because I have 1m other things going on
[16:12] <Spabby> but when we start developing this app it will be coded on linux boxes
[16:12] <bialix> get the plugin with command: bzr get lp:bzr-automirror automirror
[16:13] <Spabby> I think that's a job for tomorrow :D thanks for all your help again
[16:13] <bialix> put automirror directory (with plugin) to ~/.bazaar/plugins on Linux or %APPDATA%\bazaar\2.0\plugins on Windows
[16:13] <bialix> and read the help on this plugin
[16:14] <Spabby> thanks all, have a good evening
[16:14] <bialix> that's basically all
[16:14] <bialix> bzr need magic button to automagically install plugins
[16:15] <awilkins> I find that `bzr branch lp:<plugin-name> <plugin>`  usually works nicely
[16:17] <bialix> how you're explain usually where one should put <plugin> on Windows?
[16:17] <awilkins> In powershell $env:appdata\bazaar\2.0\plugins
[16:18] <awilkins> In cmd.exe  %appdata$\bazaar\2.0\plugins instead
[16:18] <awilkins> Ack %appdata%
[16:18] <awilkins> Not $
[16:19] <bialix> anyway ~/.bazaar/plugin is way too much shorter
[16:20] <awilkins> Yes
[16:21] <awilkins> Hey, powershell supports ~ for %userprofile%
[16:21] <awilkins> Why did they put BZR_HOME in %appdata% ?
[16:21] <awilkins>  I didn't know it supported ~
[16:22] <awilkins> Dammit, that would be much easier
[16:22] <awilkins> And why the fricking 2.0
[16:23] <bialix> hehe
[16:23] <bialix> I know it's jam invent it
[16:24] <bialix> but now it's too late to change
[16:24] <bialix> but hey!
[16:24] <bialix> we should have bzr 2.0 next month!
[16:24] <bialix> so
[16:24] <awilkins> I'd write a change-the-location-of-BZR_HOME plugin
[16:24] <bialix> jam invented time mechine in 2006
[16:24] <awilkins> But it wouldn't be able to load itself
[16:25] <bialix> so you need to write it virus-like
[16:25] <bialix> so it will reborn itself after total windows reinstall
[16:25] <bialix> :-)
[16:26] <bialix> more seriously: I'm always using BZR_PLUGIN_PATH settings
[16:46] <RockyRoad> Hi :)
[16:46] <RockyRoad> Would someone know what would happen (I mean, would it be safe) if I deleted, from the repository, a branch taking part in the history of another ?
[16:46] <Peng_> RockyRoad: Don't go deleting .bzr/repository data that's necessary. .bzr/branch doesn't matter.
[16:46] <Peng_> RockyRoad: (Unless you're using stacked branches, obviously.)
[16:47] <RockyRoad> I didn't yet understand stacked branches
[16:48] <Peng_> RockyRoad: When using stacking, it says "look at branch X for all the other data" instead of storing it all locally.
[16:48] <RockyRoad> How can I check it is safe
[16:48] <Peng_> RockyRoad: "bzr info", I suppose.
[16:48] <hsn_> is there SLES prebuilt package?
[16:49]  * Peng_ /away!
[16:50] <Peng_> RockyRoad: On disk, branches (.bzr/branch) are simply pointers to data in the repository (.bzr/repository). Deleting them is perfectly safe. However, when using stacked branches, you may have several different repositories holding a few revisions each, so it may not be safe.
[16:51] <RockyRoad> I'm working on lp:planet-drupal
[16:51] <Peng_> Soo?
[16:52] <RockyRoad> (just to let you check picture if you wanted) I think lp:~m-baert/planet-drupal/planet-6x is left behind after a sequence of merges
[16:53] <RockyRoad> but if the others refer to it, they would break
[16:54] <RockyRoad> I've rebuilt all the bzr history from multiple branches
[16:57] <RockyRoad> I think I'd better check ids in bzr log xmloutput
[17:09] <LarstiQ> hsn_: I think there have been, I don't know who is responsible for them
[17:35] <jam> awilkins, bialix: We used "APPDATA" because that is where you are "supposed" to put application specific information on Windows
[17:35] <jam> We used "Bazaar\X.X" because that is also what you are recommended to do
[17:35] <jam> And we used 2.0 because at that time
[17:36] <jam> bzr was likely to be released as Bazaar 2.0 rather than our final choice of releasing it as bzr 1.0
[17:36] <jam> But as Alexander says, it will be there in another month or so :)
[18:19] <beuno> so
[18:19] <beuno> after upgrading about 30 branches at the office
[18:19] <beuno> all of them upgraded fine
[18:19] <beuno> they're all faster
[18:19] <beuno> but about half of them are the same size in bbc than in 1.9
[18:23] <visik7> is there a way to get mail notification on commit ?
[18:25] <visik7> I want to develop a protocol for bazaar
[18:26]  * SamB wonders why aptitude can't show changelogs for packages from PPAs
[18:31] <SamB> hmm ... "bzr trees http://libarchive.googlecode.com/svn/" is failing for me using bzr 1.15+4422+110 ...
[18:31] <SamB>  bzr trees http://libarchive.googlecode.com/svn/
[18:31] <SamB> bzr: ERROR: Transport operation not possible: Transport <bzrlib.transport.http._urllib.HttpTransport_urllib url=http://libarchive.googlecode.com/svn/> has not implemented list_dir (but must claim to be listable to trigger this error).
[18:32] <SamB> ... oops, I missed the "%"
[18:32] <wlawless> Is there a good site to visit if I am having problems with bzr-svn on Windows?
[18:33] <SamB> wlawless: talk to jelmer
[18:34] <SamB> ... who is conveniently missing
[18:34] <SamB> what kind of problems?
[18:35] <wlawless> a bunch of 'procedure entry point missing' errors when I try to do anything that involves the svn repository (checkout, update, commit)
[18:35] <SamB> ("talk to jelmer" is my advice for most situations where a bzr-svn bug is suspected ;-)
[18:35] <SamB> wlawless: could you paste one ?
[18:36] <wlawless> "The procedure entry point svn_client_revprop_set2 could not be located in the dynamic link library libsvn_client-1.dll"
[18:36] <wlawless> plus about 8 more, every time I run a command
[18:39] <SamB> how'd you instal bzr-svn ?
[18:39] <SamB> did libsvn_client come with it ?
[18:40] <wlawless> I used the default installer for windows from here: http://bazaar-vcs.org/Download
[18:40] <wlawless> the instructions says bzr-svn is included
[18:41] <SamB> did you try googling for the error message yet/
[18:41] <SamB> er, ?
[18:42] <SamB> hmm, well, I can't find a thing
[18:42] <schmichael> is there any reason not to always use bzr merge --pull?
[18:42] <wlawless> I did, not much luck
[18:42] <SamB> ... next question: search for files named "libsvn_client-1.dll"
[18:42] <SamB> on your hard drive
[18:43] <wlawless> not that I know of, I'm new to bazaar, so was just following the tutorials I could find
[18:43] <wlawless> the only instance I could find was in c:\program files\Subversion
[18:44] <wlawless> actually, nevermind, there is one in c:\program files\bazaar as well
[18:45] <wlawless> would bzr-svn care what version of the svn client I have on my machine?
[18:59] <bialix> garyvdm: good evening
[18:59] <garyvdm> Hi bialix
[19:00] <bialix> I'm packaging release right now
[19:28] <bialix> garyvdm: done, trunk is open for 0.12
[19:29] <garyvdm> Cool
[19:30] <garyvdm> I'm adding some comments to loggraphprovider
[19:30] <bialix> thank you
[19:31] <bialix> now the most boring part:mark bugs as fix released
[19:36] <wlawless> does the latest bzr-svn work against subversion 1.6 repositories?
[19:42] <garyvdm> bialix: let me help with that.
[19:42] <bialix> ok
[19:43] <bialix> garyvdm: we talked about bug statuses some months ago. you can use fix released when you push your fix to trunk
[19:44] <bialix> I've got too much karma from closing bugs
[19:45] <bialix> thanks, done now
[19:46] <garyvdm> Do you get karma for changing from fix committed to fix released?
[19:46] <bialix> yep
[19:46] <zu22> can someone please help me with bzr import
[19:46] <zu22> this is driving me crazy!
[19:46] <bialix> and I don't think it's quite rigt
[19:46] <zu22> i followed all documented steps i could find and it still fails
[19:47] <zu22> anyone here familiar with bzr's fast-import?
[19:47] <garyvdm> bialix: I think the bug assigne should get the karma
[19:47] <bialix> me a bit
[19:47] <zu22> i am using darcs fast-export and then bzr fast-import
[19:47] <zu22> bialix: ok cool one sec i will get a pastebin for you to see
[19:47] <garyvdm> zu22 - can you pastebin some code.
[19:47] <zu22> sure one sec
[19:47] <zu22> gotta fire up firefox, slow computer :)
[19:48] <bialix> garyvdm: after each release I see karma jump
[19:48] <bialix> you can simply explain
[19:48] <garyvdm> It's rewarding you greatly for a boring job ;-)
[19:49] <bialix> ha ha
[19:50] <bialix> IIUC bzr 1.16 will release brisbane-core
[19:50] <bialix> we need to try conversion of our trunk to bbc (locally)
[19:51] <bialix> garyvdm: you don't have a chance to test brisbane core yet?
[19:53] <garyvdm> I've got a bbc branch of bzr.dev that I have been using to test some parts of qbzr against. But I have not tested upgrading the qbzr branch.
[19:53] <garyvdm> I'll brb
[19:53] <zu22> ok got it
[19:53] <zu22> bialix and garyvdm you guys still here?
[19:53] <zu22> sorry for the delay!
[19:53] <zu22> http://zu22.pastebin.com/f145ddea9
[19:53] <zu22> that shows what is going on
[19:54] <bialix> cool, you have your own pastebin
[19:55] <zu22> heh ya
[19:55] <bialix> zu22: bzr: ERROR: No WorkingTree exists for
[19:55] <bialix> you should run command: bzr co .
[19:55] <zu22> bialix: so what am i doing wrong?
[19:55] <bialix> or simply bzr co
[19:55] <bialix> rtfm?
[19:56] <bialix> run bzr co
[19:56] <zu22> i am converting a darcs repo to a bzr
[19:56] <zu22> ok
[19:57] <zu22> i just did "bzr co" in /var/www/darcs/netrek-client-brmh.bzr and it said:
[19:57] <zu22> bzr: ERROR: Not a branch: "/var/www/darcs/netrek-client-brmh.bzr/.bzr/branch/".
[19:57] <zu22> it seems either darcs export is failing or bzr import or both :(
[19:57] <zu22> any more ideas?
[19:58]  * bialix re-read paste one more time
[19:58] <zu22> lines 31 and 32 is where conversion should happen
[19:59] <bialix> ok, let's try that without cd to .bzr dir and ls it, there is nothing very interesting
[19:59] <bialix> cd trunk
[20:00] <bialix> bzr info -v
[20:00] <bialix> I need output of info command
[20:01] <bialix> zu22: bzr info -v in trunk after import
[20:02] <zu22> ok i will get that
[20:03] <zu22> http://zu22.pastebin.com/f6f26e4c5
[20:04] <bialix> zu22: now: cd trunk; bzr info -v
[20:04] <bialix> does your darcs repo has only 2 commits?
[20:04] <zu22> ok
[20:05] <zu22> there is no trunk directory
[20:05] <zu22> there is "branch-lock" and "repository" directories
[20:05] <zu22> my darcs repo should have 8 patches in it
[20:05] <zu22> but the bzr conversion should import ALL my source code
[20:05] <bialix> don't don't don't don't cd to .bzr/ dir please
[20:05] <zu22> the original code + my code in the darcs repo
[20:06] <zu22> it doesn't import any code at all
[20:06] <zu22> ok
[20:06] <bialix> I see 2 revisions in your trunk
[20:06] <zu22> you can pull my darcs repo and see yourself:
[20:06] <bialix> C:\work\Bazaar\repos>bzr log http://www.jesujuva.org/darcs/netrek-client-brmh.bzr/trunk/ --line
[20:06] <bialix> 2: netrek 2009-06-10 decimal precision conformance patch + compile fixes + updated ChangeLog
[20:06] <bialix> 1: netrek 2009-06-10 Import old source code.
[20:06] <zu22> darcs get http://www.jesujuva.org/darcs/netrek-client-brmh/
[20:06] <bialix> I don't have darcs installed, sorry
[20:06] <zu22> yes
[20:06] <zu22> ok that is correct 2 big patches
[20:07] <bialix> can you do following:
[20:07] <bialix> bzr info -v /var/www/darcs/netrek-client-brmh.bzr/trunk
[20:08] <zu22> i will do it now nad pastebin
[20:08] <zu22> one second
[20:10] <zu22> http://zu22.pastebin.com/f1b21995
[20:11] <bialix> does location /var/www/darcs/netrek-client-brmh.bzr/trunk writable for you?
[20:12] <bialix> this is valid branch. you need to run in /var/www/darcs/netrek-client-brmh.bzr/trunk either `bz revert` or `bzr update`
[20:13] <zu22> it has permissions: drwxr-xr-x
[20:13] <bialix> one of these comands will restore your working files
[20:13] <zu22> oh ok
[20:13] <bialix> so it's read-only for you
[20:13] <zu22> then i will be able see all my code good
[20:13] <bialix> do you have writable location in your session
[20:13] <bialix> ?
[20:13] <zu22> but i run all my commands as root
[20:13] <zu22> yes root can write it :)
[20:13] <zu22> let me try bzr revert
[20:14] <bialix> you can get a fresh copy
[20:14] <zu22> ok how do i do that?
[20:14] <bialix> bzr branch /var/www/darcs/netrek-client-brmh.bzr/trunk ~/trunk.bzr
[20:14] <bialix> last part of command -- is path where new copy will be created
[20:15] <bialix> bzr branch -h | less
[20:15] <bialix> this say you more
[20:15] <bialix> you can browse your trunk with command: bzr log /var/www/darcs/netrek-client-brmh.bzr/trunk
[20:16] <zu22> ah
[20:16] <bialix> check your patches with command: bzr diff /var/www/darcs/netrek-client-brmh.bzr/trunk -c1
[20:16] <bialix> bzr diff /var/www/darcs/netrek-client-brmh.bzr/trunk -c2
[20:16] <zu22> cool bzr has diff!
[20:16] <bialix> so, I;d say conversion was successful
[20:16] <bialix> run this: bzr help command|less
[20:17] <bialix> I recommend you to read this: http://doc.bazaar-vcs.org/bzr.dev/en/mini-tutorial/index.html
[20:18] <zu22> bialix: the 'bzr update' worked, now i must find out how to get my bzr repo to import into launchpad.net :)
[20:18] <bialix> http://doc.bazaar-vcs.org/bzr.dev/en/mini-tutorial/index.html#publishing-your-branch-with-launchpad
[20:19] <zu22> thank you bialix
[20:19] <bialix> np
[20:19] <zu22> bialix: you are Ukraine?
[20:19] <bialix> but it seems you need to read this mini-tutorial
[20:19] <zu22> yes
[20:19] <bialix> yes, from Ukraine
[20:19] <zu22> good
[20:19] <zu22> i remember your leader
[20:20] <zu22> he was poisoned :(
[20:20] <zu22> is he ok now?
[20:20] <bialix> don't worry about him
[20:20] <bialix> he's not very good leader
[20:21] <bialix> why you migrate from darcs?
[20:21] <zu22> our project switch to bzr
[20:21] <zu22> but i prefer darcs :)0
[20:21] <zu22> so i will keep using darcs and import to project using bzr
[20:21] <bialix> I guess fast-import/fast-export should work for you
[20:22] <zu22> yeah i just wish is a nice GUI to do all this
[20:22] <zu22> so i must not fiddle with so many command line options, too easy to make mistake hehe
[20:23] <bialix> GUI for fast-import?
[20:26] <zu22> for both :)
[20:26] <bialix> I'd write a simple script or Makefile
[20:28] <zu22> good idea
[20:28] <zu22> bialix: do you have your own website?
[20:28] <bialix> more or less
[20:28] <bialix> why you asking?
[20:31] <mib_2l987k8u> How do I completely remove a file from history?
[20:32] <mib_2l987k8u> A colleague added a directory of temp files by mistake, and they waste space.
[20:32] <Peng_> mib_2l987k8u: Mostly you don't.
[20:32] <bialix> how many revisions you have after this mistake?
[20:32] <mib_2l987k8u> About two
[20:32] <mib_2l987k8u> >1, if that's what you mean :)
[20:33] <bialix> then create fresh copy of your branch before mistake
[20:33] <bialix> and replay all good commits in new branch
[20:33] <bialix> then kill old branch
[20:33] <mib_2l987k8u> But I cannot (as in Git) just remove the files from each commit?
[20:34] <bialix> you can try this with fastexport/fast-import
[20:34] <mib_2l987k8u> OK, thanks
[20:34] <bialix> but if you have only one revision on top, I'd better replay
[20:34] <mib_2l987k8u> With uncommit?
[20:34] <bialix> no
[20:34] <bialix> with rebase plugin
[20:35] <bialix> like in git
[20:35] <bialix> rebase plugin has handy command: replay
[20:35] <mib_2l987k8u> Ah
[20:35] <mib_2l987k8u> OK, I'll RTFM for the plugin
[20:35] <mib_2l987k8u> Thanks
[20:35] <bialix> np
[20:35] <bialix> but to save the space you need to get fresh copy and delete old branch
[20:36] <bialix> garyvdm: https://bugs.launchpad.net/qbzr/+bug/328598
[20:37] <mib_2l987k8u> Ah
[20:37] <mib_2l987k8u> That's the main thing I'm trying to gain: space
[20:37] <mib_2l987k8u> Since the temp files are just text, but lots of them
[20:37] <bialix> bzr has no garbage collector
[20:37] <mib_2l987k8u> Hmm
[20:37] <garyvdm> bialix: There are 2 out standing issues that I ran into - that would need lots of codeing
[20:38] <mib_2l987k8u> If I revert, just make the final changes, then commit and repack, would I regain the space?
[20:38] <bialix> mib_.... no
[20:38] <mib_2l987k8u> Damn
[20:38] <bialix> uncommitted revisions is not garbage collected
[20:38] <mib_2l987k8u> Maybe I should just bend over and take the wasted space, and hope bzr packs well enough as it is
[20:39] <bialix> garyvdm: :-(
[20:39] <garyvdm> <mib_2l987k8u: if you uncommit, and then push somewhere - that uncommitted rev won't be pushed.
[20:40] <mib_2l987k8u> That would be possible.
[20:40] <bialix> is there short path? may be to limit its functionality a bit?
[20:40] <hsn_> you know if bzr-trac works with Trac 0.11.4? i am getting some exceptions
[20:40] <garyvdm> bialix: I'ts usable as it is. May be we should look at merging it as it is.
[20:41] <bialix> how to test it?
[20:41] <garyvdm> bialix: qpull
[20:41] <garyvdm> qpush
[20:41] <bialix> ok, will look now
[20:41] <garyvdm> qmerge - i think
[20:42] <bialix> hsn_: jelmer or ddaa might know
[20:42] <garyvdm> bialix: One of the issues is that you can't select a revision range, to say do a cherry pick merge.
[20:43] <bialix> this is bearable
[20:43] <bialix> known bug is not bug anymore, but feature
[20:43] <bialix> haaa!
[20:43] <bialix> ErrorFromSmartServer: Error received from smart server: ('error', "'AbsentContentFactory' object has no attribute 'g
[20:43] <bialix> et_bytes_as'")
[20:44] <bialix> from your branch
[20:44] <bialix> can you try to fix it?
[20:44] <garyvdm> bialix: how?
[20:44] <bialix> wait a sec
[20:45] <bialix> https://bugs.launchpad.net/launchpad-code/+bug/354036
[20:45] <bialix> run the script from this bug report as described
[20:46] <garyvdm> on local branch, and then push?
[20:47] <bialix> no
[20:47] <bialix> Run it as 'fix-branch.py bzr+ssh://bazaar.launchpad.net/~user/project/branch'.
[20:47] <garyvdm> ok
[20:47] <meoblast001> hi
[20:48] <meoblast001> i'm trying to help someone set up his new computer with his old bzr email line
[20:48] <meoblast001> how can  be sure i have the exact same line as the old
[20:48] <bialix> bzr whoami
[20:48] <mib_2l987k8u> bzr whoami on his machine to set the new one
[20:48] <mib_2l987k8u> check the old logs for his old one
[20:48] <mib_2l987k8u> bzr whoami "Sam Adams <good@beer.com>"
[20:49] <mib_2l987k8u> Or whichever beer your friend prefers
[20:49] <meoblast001> i don't know what his old one was though
[20:49] <meoblast001> how can i find the logs
[20:49] <mib_2l987k8u> Run bzr log on the old repo
[20:49] <mib_2l987k8u> On any machine with bzr installed
[20:49] <rockstar> meoblast001, bzr log on the old branches
[20:50] <meoblast001> ok
[20:52] <garyvdm> bialix: I ran it and got http://paste.ubuntu.com/193697/
[20:53] <garyvdm> I don't know if that is good or bad?
[20:53] <meoblast001> rockstar: thanks
[20:53] <bialix> garyvdm: I guess now it fixed
[20:53]  * bialix checking
[20:58] <bialix> garyvdm: now this branch is ok, thanks
[20:59] <garyvdm> cool
[21:04] <bialix> garyvdm: so.. your widget works
[21:04] <bialix> it's strange it highlight only one column instead of all row
[21:04] <garyvdm> That the other issue that I can't fix.
[21:04] <bialix> may be we really need to land it and start dogfoding
[21:05] <garyvdm> Going offline for 1 min
[21:05] <tmetro> FYI, it looks like the Ubuntu Intrepid PPA:
[21:05] <tmetro> deb http://ppa.launchpad.net/bzr/ppa/ubuntu intrepid main
[21:05] <tmetro> will successfully work as a stand-in for backports.org, which currently is missing bzrtools, for Debian stable.
[21:06] <bialix> garyvdm: but it produce tracebacks sometime
[21:06] <bialix> e.g. in qtag
[21:07] <bialix> or in qpush when branch is not selected (empty string)
[21:07] <garyvdm> bialix: Yes are rough edges like that
[21:07] <garyvdm> But the big issue is the it sometimes selects only one column
[21:07] <bialix> it's not sometimes for me
[21:08] <bialix> it's all the time
[21:08] <garyvdm> And I can't enable multiple selection.
[21:08] <garyvdm> Yes - i't all the time on windows - some time on linux
[21:08] <bialix> you don't need multiple selection for pull/push
[21:08] <garyvdm> The fix for both issues is the same.
[21:08] <bialix> for qmerge -- maybe just provide 2 revision selectors?
[21:09] <garyvdm> I need to rewrite large bits of QComboBox
[21:09] <bialix> maybe bug with column somehow related to custom painting?
[21:10] <bialix> I assume you draw entire widget
[21:10] <garyvdm> No - QComboBox insists that you can select cels
[21:10] <garyvdm> And insists that you can only select 1 item
[21:11]  * Nafallo wonders if bzr import have changed recently
[21:11] <garyvdm> I've tried all sorts of hacks to get around that to no avail.
[21:11] <Nafallo> it's either that or my memory not working anymore :-P
[21:12] <bialix> garyvdm: ar eyou using "highlighted" signal?
[21:12] <garyvdm> brb
[21:14] <bialix> garyvdm: it fails in strange way when I've tried to invoke qdiff from qlog
[21:14] <bialix> so, it seems is not ready yet to land
[21:15] <garyvdm> bialix: sorry - some unknown process keeps downloading something  - and I work out what it is.
[21:15] <bialix> you hunting on virus?
[21:16] <garyvdm> bialix: Yhea - I need to go through it with a fine comb. There have been a number of merges with trunk that were quite confusing.
[21:16] <garyvdm> I don't know
[21:16] <garyvdm> And netstat is confusing
[21:16] <bialix> are you on Windows right now?
[21:17] <garyvdm> No - ubuntu
[21:17] <bialix> oh, ok
[21:18] <garyvdm> Ok - going to restart to see if that helps.
[21:23] <bialix> garyvdm: I'm going offline. Do you have questions for me?
[21:23] <garyvdm> Seems to be fixed now
[21:24] <garyvdm> bialix: No - I'm working on making one widget for browse, commit, add, revert and qmain
[21:24] <bialix> cool
[21:24] <bialix> I will start to review patches from igc and javier
[21:24] <bialix> tomorrow
[21:25] <garyvdm> Will have better performance and will fix bug 258929
[21:25] <garyvdm> cool
[21:25] <bialix> I guess this is need to be done at wt_list level?
[21:25] <bialix> btw
[21:25] <garyvdm> Yes
[21:25] <bialix> today I've tested pyflakes
[21:25] <garyvdm> but I have not get there today
[21:26] <garyvdm> Sorry - I have not got there yet
[21:26] <bialix> we have a lot of unused imports
[21:26] <bialix> may be we need from time to time clean it
[21:26] <bialix> https://code.launchpad.net/~mwhudson/pyflakes/lazy-import-support
[21:26] <bialix> garyvdm: ^
[21:27] <garyvdm> cool
[21:27] <bialix> no
[21:27] <bialix> this one https://code.launchpad.net/~mwhudson/pyflakes/support-lazy-imports
[21:27] <bialix> jml/spiv can advertise it
[21:28] <garyvdm> Ok - I'll give that a try - I allways forget to check for unnecessary imports.
[21:28] <bialix> me too
[21:28] <bialix> but this tool is damn good
[21:28] <bialix> the branch from mwhudson knows about bzr lazy imports
[21:29] <bialix> it's incredible
[21:29] <mwhudson> :)
[21:29] <bialix> :-)
[21:29] <mwhudson> it's a bit trigger-happy about suggesting imports be lazy
[21:29] <bialix> yeah, I'm talking about pyflakes
[21:29] <bialix> yeah, it was so incredible cool
[21:31] <bialix> the best thing about pyflakes: it does not have extra dependencies
[21:31] <bialix> e.g. I don;t need to install twisted to run pyflakes
[21:31] <bialix> I like it
[21:33] <bialix> btw Gary, sometimes it's interesting to see unversioned (but to be added file) in the qdiff
[21:33] <bialix> e.g. if we select it to add before commit
[21:33] <mwhudson> it's really fast too, that's important
[21:33] <mwhudson> you can just run it all the time
[21:34] <bialix> mwhudson: yeah, it's really fast
[21:34] <mwhudson> (unlike pylint)
[21:34] <bialix> it's even faster than bzr
[21:42]  * Tak head explode
[21:42]  * bialix z-z-z
[21:47] <jdub> anyone about who can help with a weird merging problem with bzr-svn?
[22:46] <kenichi> hello, i'm trying to understand the way post_change_branch_tip hooks get called.  if i'm committing from a checkout to a local filesystem branch, would it make sense for this hook to be called twice?
[22:49] <SamB> who should I talk to about bzr-bisect? it apparantly doesn't use launchpad for bugs ...
[23:06] <garyvdm> kenichi: I think if you commit to a heavyweight checkout - it changes the tip of the local branch (the checkout), and the bound branch.
[23:06] <garyvdm> So post_change_branch_tip probably gets called for each of the branches
[23:06] <garyvdm> *I think*
[23:08] <kenichi> garyvdm: ah i see, i think that makes sense.  i will try with a lightweight to verify.  thanks!
[23:09] <kenichi> garyvdm: yes, verified only one call with a lightweight.
[23:27] <kirkland> doesn't seem that i can add an "-sa" on the end of a "bzr bd -S"
[23:28] <kirkland> suggestions?
[23:32] <kirkland> i found:   bzr bd --builder "debuild -S -sa" --source
[23:32] <kirkland> that might do it for me
[23:34] <lifeless> I think that is what I used for a similar thing
[23:34] <lifeless> I can dig up my scripts if that doesn't work (I was building in a pbuilder myself)
[23:34] <kirkland> lifeless: cheers
[23:46] <Gnx-> still the same question, is there a way to teach bzr that something is a binary file and should not be merged?
[23:49] <james_w> kirkland: "bzr bd -S -- -sa"
[23:49] <james_w> anything after "--" is passed through to debuild verbatim
[23:50] <james_w> anything that starts with a "-" at least
[23:50] <james_w> I'd like to improve that a bit, but I'm not sure what the best plan of action is
[23:53] <lifeless> Gnx-: no; in fact some binaries can be merged very well, and there are text files that don't merge properly. So it is something we would like to address.
[23:53] <Gnx-> lifeless: well, I have an sqlite.db and it currently goes wonk from bzr
[23:54] <lifeless> what do you mean by wonk?
[23:54] <Gnx-> well bzr makes it .THIS .OTHER
[23:55] <Gnx-> the behaviour I'd want would be that it would overwrite to whatever is in the last commit
[23:55] <lifeless> Gnx-: just run 'bzr revert sqlitedbfilename'
[23:55] <lifeless> Gnx-: I realise its not fully automatic, but it should work.
[23:56] <Gnx-> I meant like bzr update -> database gets overwritten from the update source
[23:56] <lifeless> Gnx-: yes
[23:57] <lifeless> Gnx-: bzr update + bzr revert databasefilename == database is overwritten from the update source
[23:57] <Gnx-> ah
[23:57] <Gnx-> okay
[23:57] <lifeless> Gnx-: isn't that what you are asking for?
[23:58] <Gnx-> but I thought revert after update gets you the version from before the update
[23:58] <lifeless> revert gets you the current basis
[23:58] <lifeless> update changes the basis
[23:58] <lifeless> after a *merge* revert would get you what you had before the merge
[23:59] <Gnx-> ah okay, thanks, bzr is kind of MyFirstVCS ;)
[23:59] <lifeless> for a merge you would do 'bzr revert -r branch:mergesource databasefilename'
[23:59] <lifeless> or, more simply
[23:59] <lifeless> cp dbfilename.OTHER dbfilename