[00:00] <lifeless> op not permitted is interesting
[00:00] <LarstiQ> Necoro: perhaps an umask?
[00:00] <lifeless> could be the foo.bar.baz file naming
[00:00] <lifeless> if its not mounted vfat it can't do that
[00:01] <lifeless> OTOH repository > 8 anyhow so that can't be it
[00:01] <Necoro> lifeless: its vfat
[00:01] <LarstiQ> lifeless: afaik fat doesn't like chmodding to something it can't represent, and raises EPERM.
[00:01] <lifeless> LarstiQ: interesting
[00:02] <lifeless> whats the backtrace show?
[00:02] <LarstiQ> but I really need to sleep, ciao
[00:02] <lifeless> (from ~/.bzr.log)
[00:02] <Necoro> LarstiQ: ciao and thanks
[00:03] <Necoro> lifeless: http://rafb.net/p/BCAK0b42.html
[00:03] <Necoro> lifeless: and using the print-debugging-style I saw, that it's an os.chmod that's raising the error
[00:04] <lifeless> ok
[00:05] <lifeless> we shouldn't be chmodding usually anyhow
[00:05] <lifeless> I thought you had to turn on a config option to set that
[00:05] <lifeless> chmodding is slow
[00:05] <lifeless> in fact -
[00:05] <lifeless> note this line:
[00:05] <lifeless> control_files.put_utf8(file, content)
[00:06] <lifeless> the control files have been initialised with none-None file mods
[00:06] <lifeless> can you try just 'bzr init' on the usb drive?
[00:06] <lifeless> and definitely file bus
[00:06] <lifeless> *bugs*
[00:07] <Necoro> lifeless: bzr init doesn't work either
[00:15] <Necoro> lifeless: bug #254514
[00:23] <Necoro> ok - time to go to bed ... =) - ciao
[00:44] <meteoroid> jelmer: is it possible to put a commit hook into a bzr repo with svn parent to push up to svn on commit to bzr?
[00:45] <jelmer> meteoroid, just use a bound branch
[00:45] <meteoroid> a bound branch, eh?
[00:45] <jelmer> meteoroid: e.g. a bzr branch bound to a svn branch
[00:45] <jelmer> meteoroid, see the docs for details
[00:45] <meteoroid> sure
[00:45] <jelmer> but basically, just run "bzr bind <svn-url>" to do that
[00:46] <meteoroid> any alternatives for svn:externals ? i think i'm just going to write a script to dl that format of repo urls
[00:46] <jelmer> not at this point
[00:47] <meteoroid> can bzr set svn props?
[00:47] <jelmer> bzr nested trees haven't landed yet but even when they will, it won't be possible to map svn:externals to them
[00:47] <meteoroid> okay
[00:48] <jelmer> perhaps bzr-svn can generate a boilerplate config-manager file or something
[00:48] <meteoroid> hm..
[00:48] <markh> jelmer: hi!  While I think of it and see a related thread on the bzr list - you recall that failing windows test with an incorrect path sep?  Any thoughts on how to proceed on that?  Is it likely to be a problem in practice?
[00:49] <jelmer> lifeless, Does that sound sensible ? What are the plans for cm?
[00:50] <jelmer> markh, it's not likely to be an issue
[00:50] <markh> cool
[00:50] <jelmer> markh, if I understand the test output correctly it's something that should be fixed in bzrlib
[00:50] <markh> yeah, but I was wondering how to present that :)
[00:50] <markh> ie, if you had an idea of *what*, so I would attempt a patch
[00:51] <markh> I haven't dug at all - looking for an easy answer ;)
[00:51] <jelmer> TestCaseInTempDir has a test_dir attribute with inconsistent (different os.path.sep) contents
[00:51] <Odd_Bloke> CM really needs fixing to not use pybaz.
[00:51] <jelmer> 'evening poolie
[00:51] <poolie> hello jelmer
[00:52] <Odd_Bloke> Else it's likely to be removed from Debian along with bazaar and friends.
[00:53] <jelmer> poolie: I'm looking at doing bzr-svn and bzr-gtk releases in the next couple of days
[00:54] <jelmer> poolie, Are there going to be any more API breakages before 1.6 or is it just polishing things for release at this point?
[00:54] <lifeless> jelmer: well I'd like to delete cm
[00:54] <lifeless> jelmer: but that means bzr being able to map into foreign systems pervasively etc
[00:55] <jelmer> lifeless: In favor of what?
[00:55] <lifeless> jelmer: why won't a bzr tree be able to refer to a svn url for the source of a nested tree?
[00:55] <lifeless> jelmer: nested trees everywhere
[00:55] <jelmer> nested trees require a specific revision in the nested tree to be referenced
[00:55] <lifeless> yes ...
[00:56] <jelmer> svn:externals allows current head to be referenced, whatever that is at the time the user does the checkout
[00:56] <lifeless> nested trees permit that too; its UI not core
[00:56] <lifeless> thats just 'bzr update' after checkout
[00:57] <jelmer> well, it's not there atm :-)
[00:58] <jelmer> lifeless: there's also no way to represent that in the current inventory entry class for nested trees
[01:01] <lifeless> jelmer: in that update is desired? true
[01:03] <poolie> lifeless: what is cm?
[01:03] <lifeless> config-manager
[01:05] <meteoroid> jelmer: externals allow referencing revisions as well
[01:05] <meteoroid> but typically we use a tag
[01:05] <lifeless> meteoroid: yes, jelmer is saying that nested trees are a subset of the externals interface
[01:05] <meteoroid> oh ok, allows, sure
[01:06]  * meteoroid goes back to trying to get bzr webdav and smart server working in apache
[01:06] <poolie> i thought so
[01:06] <poolie> i thought that was an answer re api breakage that's all
[01:06] <poolie> jelmer, i think it should be just bug fixes from now on
[01:06] <poolie> the only one i know of so far is that upgrade does not work on a stacked branch
[01:13] <poolie> lifeless: i'm planning to fix that by making open_unsupported (or similar) take an option to open the branch without fallback repositories
[01:15] <lifeless> perhaps open_unsopported should be renamed to open_for_upgrade
[01:15] <lifeless> -> doctor
[01:15] <poolie> open_backdoor
[01:20] <beuno> mornin' everyone
[01:32] <jelmer> poolie: thanks! I'll start working on getting those release out then
[01:35] <beuno> mwhudson, howdy.  I've been playing with the browsing template a bit.  Have you had a chance to look at it?
[01:36] <jelmer> hey beuno
[01:36] <beuno> evening jelmer
[02:32] <mwhudson> beuno: ah, not really
[02:45] <mwhudson> beuno: so i did some more stuff and merged your branch
[02:45] <mwhudson> beuno: see https://code.edge.launchpad.net/~mwhudson/loggerhead/themed-directory-listing
[03:29] <marnanel> What's the argument to bzr diff to show just the changes for one commit in the current repo?  Sorry, I'm trying to figure it out from help revisionspec and not getting very far
[03:30] <poolie> marnanel: easiest is bzr diff -c -1
[03:30] <poolie> or any revisionspec in place of the -1
[03:31] <marnanel> poolie: wonderful, thanks
[04:35] <beuno> mwhudson, looking
[04:40] <beuno> mwhudson, cool!  you made it even nicer  :)
[04:40] <beuno> one FIXME to go, and it should be mergeable, no?
[04:46] <lifeless> poolie: don't forget to ring me ;)
[04:51] <mwhudson> beuno: probably
[04:52] <beuno> ok, so you're not as enthusiastic  :p
[04:52] <beuno> it's still sunday for me, so I'm still in a good mood  :)
[04:53] <beuno> I'll work on whatever is left to polish tomorrow
[05:03] <mwhudson> beuno: just busy, really
[05:03] <mwhudson> beuno: a different icon for branches vs folders would be nice
[05:04] <beuno> mwhudson, sure, what would that icon be?
[05:05] <mwhudson> beuno: no idea :)
[05:05] <beuno> mwhudson, folder + bzr icon?
[05:05] <mwhudson> beuno: yeah, something like that
[05:06] <mwhudson> would be great
[05:26]  * meteoroid wonder if there are any recommended ui for bzr, x11 or otherwise
[05:48] <poolie> meteoroid, apt-get install bzr-gtk
[05:49] <meteoroid> that's all i need? rawk!
[05:49] <meteoroid> i saw 'olive' or something on rhel5 but it was a curses newsreader on ubuntu ;d
[05:50] <poolie> olive is the main front end
[05:50] <poolie> um
[05:50] <poolie> i thought it was included
[05:51] <poolie> meteoroid, you should get an olive-gtk command when installing that package
[05:51] <poolie> and i thought it was in the menu
[05:54] <meteoroid> ok
[08:57] <poolie_> lifeless, spiv, would one of you (if still online) read my patch for #252428
[08:57] <poolie_> it's pretty tiny
[09:01] <lifeless> where is it ?
[09:03] <lifeless> also, your _ is showing
[09:03] <lifeless> poolie_: ^
[09:03] <poolie> on the list
[09:03] <poolie> http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Ce01316480808040016h4deae0daxa9e4a981983d7206%40mail.gmail.com%3E
[09:04] <poolie> i'm getting probably spurious failures of other upgrade scenarios
[09:05] <poolie> actually i just sent an update to the list
[09:08] <lifeless> poolie: trivial question, why didn't you add the tests to per_repository_reference
[09:10] <poolie> because they're not going to be 1:1 with repository formats
[09:10] <poolie> eg i want to try upgrades from knits
[09:10] <lifeless> right
[09:11] <lifeless> see bzrlib/tests/repository_implementations/test_repository.py
[09:11] <lifeless> test_upgrade_from_format4
[09:11] <lifeless> etc
[09:12] <poolie> hm
[09:12] <poolie> you mean i could do one dimension of parameterization by scenarios and the other by having multiple methods?
[09:12] <lifeless> parameterisation will stack
[09:12] <lifeless> if you have a load_tests in e.g. per_repository_reference/test_upgrade.py
[09:13] <Odd_Bloke> Hmm, bzr-buildpackage doesn't seem to be doing signing for me ATM.
[09:13] <lifeless> then the __init__ parameteriser will get pre-parameterised tests and parmeterise them further
[09:13] <lifeless> interfaces FTW
[09:14] <poolie> interesting
[09:14] <poolie> i did not realise load_tests would join up like that
[09:14] <poolie> maybe because it's not documented ;-)
[09:17] <lifeless> well
[09:17] <lifeless> everything that gets tests triggers load_tests
[09:18] <lifeless> I'm writing up a review for you
[09:18] <poolie> lifeless, so how does test_upgrade_from_format4 relate to multiple load_tests?
[09:18] <matid> Hi there!
[09:18] <matid> I've got a question regarding bzr-svn and Mac OS X. What's the recommended way to get it working?
[09:18] <matid> Which version of bzr, bzr-svn, subversion, etc.?
[09:18] <poolie> it looks like it's not using that approach?
[09:19] <poolie> matid, um, the latest of each would probably be a good idea :-)
[09:19] <lifeless> poolie: no, its from before load_tests :) - I'm just noting that you can avoid code duplication if you want :>
[09:20] <matid> poolie: It's not that easy though :) I failed to get it to work with many combinations of bzr 1.5, 1.63b, svn 1.4, 1.5 and 1.6 and different branches of bzr-svn :)
[09:20] <poolie> matid, :-/
[09:22] <poolie> lifeless, i suppose the other thing i was thinking about here (aside from just not knowing/realising they would stack)
[09:22] <poolie> is that i didn't necessarily want to test all n**2 combinations, just to pick some interesting ones
[09:24] <lifeless> poolie: well, your comment in the test suggested that you wanted to have it test all formats for whatever you selected
[09:24] <lifeless> poolie: concretely, I think we should test every 'stackable repository type' for whatever scenarios are interesting
[09:24] <poolie> probably
[09:25] <lifeless> poolie: so its not n**2, its still N(stackable)*[interesting]
[09:27] <poolie> your updated comment is more correct
[09:27] <poolie> and i agree moving it would be better
[09:27] <poolie> i have a feeling this test actually wants to be two tests though
[09:27] <poolie> on a mostly unrelated matter
[09:27] <poolie> that is, if there is no model change, you do not need to upgrade
[09:28] <poolie> hm, well, maybe just the if block is enough
[09:28] <lifeless> upgrade is already tested in that respect.
[09:28] <lifeless> that if block is purely UI glue
[09:29] <lifeless> (and if it is a checkout, the user needs to go over to the branch and try 'upgrade' there anyhoo)
[09:30] <poolie> in which respect?
[09:32] <lifeless> if there is no model change -> no upgrade
[09:32] <lifeless> upgrades only changes stuff when there are things to do
[09:32] <poolie> btw what would you think of systematizing the pattern i use here of making the injected parameters be scenario_*
[09:33] <poolie> lifeless, well, going from knits to packs is a substantial change but not a model change
[09:35] <lifeless> so you're saying that in the test parameterisation you don't want same-model formats for these specific tests?
[09:35] <lifeless> could just skip the test if the model is the same - just return early
[09:35] <poolie> i want to test this: the stacked-on repostiory is upgraded in a way that does not change its model; the stacked branch should still work (without needing to be upgraded)
[09:36] <lifeless> ah right
[09:36] <lifeless> yes
[09:36] <lifeless> thats a good test to have too
[09:37] <poolie> so the annoying thing about putting this into per_repository_reference
[09:37] <poolie> although i agree it's good to cover all formats automatically and to have same-things-together
[09:38] <poolie> is choosing the right corresponding formats
[09:38] <poolie> hm
[09:39] <lifeless> should be the same list you had before :P
[09:40] <lifeless> a knit and a pack of model plain
[09:45] <poolie> hm
[09:46] <poolie> are you sure stacking load_tests actually works?
[09:46] <poolie> it doesn't seem to for me
[09:46] <poolie> i'm kind of tired of this, i think i'll leave it til tomorrow
[09:47] <lifeless> ok
[09:47] <lifeless> I'll peek at that for you tomorrow
[09:47] <lifeless> could be a bug
[09:47] <lifeless> sleep well
[09:47] <poolie> it is 10 hours since i started
[09:47] <poolie> and probly more for you
[09:48] <lifeless> :> 11
[09:48] <lifeless> slept in to 7:30
[09:49] <lifeless> poolie: I fixed quite an old bug today
[09:49] <poolie> i saw
[09:49] <poolie> a four digit bug number!
[09:49] <poolie> many extra points :)
[09:49] <lifeless> :)
[09:50] <poolie> maybe that should factor into lp karma?
[09:50] <poolie> well
[09:50] <poolie> have a good night
[09:50] <lifeless> gnight, you too
[12:17] <awilkins> Is there a conference on or something? It's deathly quiet in here.
[12:22] <james_w> I don't think so
[12:31] <Jc2k> bzr is so bug free and feature complete that it no longer needs irc
[12:33]  * awilkins watches tumbleweed blow past
[12:33] <fullermd> Either that or somebody broke bzr-irc.
[12:40] <rocky> here's a question, if i'm making small local branches just for work and then want to put them right onto trunk (which may have diverged) ... is it ok to "push" them onto trunk even if i've already pushed them somewhere else? (and obviously after i've merged trunk changes into my branch)
[12:49] <LarstiQ> rocky: ok in what sense?
[12:49] <LarstiQ> rocky: it works, but it may not be the workflow you want?
[12:50] <rocky> well ... if i'm making small changes in my local branch, i don't want to *merge* them onto the main trunk because they show up as one lump commit ... i want my commit history maintained so they show up as several small commits on the trunk
[12:51] <LarstiQ> rocky: your commit history is retained anyway
[12:51] <rocky> when i do a merge to trunk and commit ... and look back through history, it shows up as one commit (perhaps this is specific to bzr-svn ?)
[12:52] <LarstiQ> rocky: aha. bzr-svn can not push the actual merged revisions to svn, so if you pull from svn with bzr you will get ghosts for the merged revisions.
[12:52] <LarstiQ> rocky: those revisions are still referenced though.
[12:52] <LarstiQ> rocky: but in your case, you might want to use rebase.
[12:53] <rocky> rebase seems scary ;)
[12:53] <LarstiQ> that's because it is ;)
[12:53] <rocky> sorry, i'm still learning bzr ;)
[12:53] <luks> not necessarily
[12:54] <luks> (I mean you might not want to use it)
[12:54] <LarstiQ> rocky: you can also merge trunk and then push the result of that.
[12:54] <luks> "obviously after i've merged trunk changes into my branch"
[12:54] <luks> after this, a simple push to trunk is fine
[12:54] <luks> but you will get some empty looking merge revisions in your trunk
[12:54] <rocky> hmm
[12:54] <rocky> that is probably fine
[12:54] <rocky> but if i were working with pure bzr (no svn) then the workflow would be to just use merges right? not merge/push ?
[12:55] <luks> hm, wait
[12:55] <luks> it will probably not do what you want, especially not with bzr-svn
[12:57] <luks> if you push such a branch with merged trunk to trunk, the revision numbers in trunk will change
[12:57] <luks> so doing it the other way around, merging the branches to trunk, is better
[14:04] <matid> jelmer: Hi. You there?
[14:28] <awilkins> Hmm, "bzr switch" does not behave as I expect
[14:29] <awilkins> I have a heavyweight checkout, and "bzr switch bar" does not try to switch to <bound_branch>/../bar, it tries <checkout>/../bar
[14:30] <james_w> yeah
[14:30] <awilkins> Is this intentional?
[14:31] <james_w> yeah
[14:31] <james_w> though I don't know if it's desirable
[14:31] <awilkins> It doesn't seem to corresepond to what the help says
[14:31] <awilkins> lthough the help is vague
[14:31] <james_w> that was added to ease the lives of people who use switch to give one working tree for lots of branches
[14:31] <james_w> maybe you should raise your use case and see if it could be incorporated
[14:32] <james_w> I don't use switch, so I'm not the best to add
[14:32] <awilkins> I think maybe it should try the sibling of the bound branch also
[14:32] <james_w> s/add/ask
[14:32]  * fullermd blinks.
[14:32] <fullermd> That sounds like just the case he's asking for...
[14:33] <james_w> it depends whether all of the branches are local or remote I guess
[14:33] <awilkins> fullermd: I have the branch bound to a repo elsewhere, I want it to switch to repo/branches/bar not workfolder/bar
[14:33] <james_w> if everything is in one directory then the current behaviour is what you want, if the branches are remote then it isn't
[14:33] <fullermd> Sounds more like another one of those irritating heavy-vs-light behavioral differences   :|
[14:34] <awilkins> It is
[14:34] <james_w> awilkins: perhaps the change could be made without breaking the case it was added for because of that
[14:34] <awilkins> I believe light would behave as I expected it to
[14:34] <awilkins> I think checking the sibling of the bound branch after the direct sibling of the branch would provide the feature I want
[14:35] <fullermd> I think checking the sibling of the checkout at all is a bug; implementation leakage.
[14:35] <awilkins> Well, I'd think the same but I'm being cautious :-)
[14:36] <awilkins> I mean, I wouldn't keep a working tree huddled up in a folder fuill of branches myself
[14:36] <fullermd> I gave my cautious a vacation this week   ;)
[14:36] <awilkins> The repo is on a USB thumb or I'd go lightweight
[14:37] <awilkins> I want the backup in case I lose it, and the ability to commit when it's not connected on occasion
[14:37] <pickscrape> Does the bazaar test suite have any coverage reporting capability?
[14:38] <awilkins> Intuitively, I'd say that might be difficult for Python..
[14:38] <awilkins> But intuition is an idiot sometimes
[14:38] <Jc2k> there is a module to allow it, but it will slow things down a lot
[14:38] <james_w> pickscrape: I don't think so, but I may remember something about a hack or something to do it
[14:39] <awilkins> "coverage.py"...
[14:39] <awilkins> :-)
[14:39] <Jc2k> http://martinpitt.wordpress.com/2008/04/08/python-code-coverage/
[14:40] <james_w> yeah, but I seem to remember someone hooking coverage.py in to the test runner
[14:40] <matid> Hi again! Did anyone recenly got bzr-svn to work on Mac OS X?
[14:40] <pickscrape> Thanks for the pointers. :) I'm writing tests for diffstat, and wondered how I was doing
[14:40] <matid> I'm on latest bzr.dev and bzr-svn/trunk and it throws "bzr: ERROR: The branch svn+ssh://***/trunk has no revision None." on bzr branch.
[14:46] <awilkins> Any pointers on how to determine if a BzrDir is a heavy checkout?
[14:47] <lifeless> if its got a bound branch
[14:47] <awilkins> Would get_bound_location always return a value for a checkout?
[14:47] <awilkins> (I mean even checkouts that are just the local checkout for a standalone branch)
[14:48] <lifeless> no
[14:48] <lifeless> lightweight checkouts have no local branch object
[14:48] <james_w> hey lifeless, did you see the links I pasted?
[14:48] <lifeless> note that you have have a lightweight checkout of a bound branch to a master branch
[14:48] <lifeless> yes
[14:54] <awilkins> Ok, that seems to fix it :-)
[14:57] <lifeless> james_w: yes I did
[14:57] <lifeless> bleh
[15:45]  * awilkins posts a fix for annoying "switch" behaviour to list
[15:48] <evanton> a bzr branch contains a html file that is generated from rst markup
[15:49] <evanton> I modify the rst markup and regenerate the html file
[15:49] <evanton> the problem is that the original version of this html file has windows-style newlines
[15:50] <evanton> I'm on Linux, so bzr diff on this file produces a huge diff (due to unix-style newlines in the new html file that was just generated)
[15:50] <Peng_> unix2dos?
[15:50] <evanton> this must be a typical issue, is there any documented workaround?
[15:51] <james_w> evanton: there is a feature that will be in an upcoming version that may help you with this
[15:51] <james_w> in the meantime unix2dos or similar may be your best bet
[15:51] <Peng_> evanton: bzr doesn't currently translate newlines, but it's in progress. You can use a program like unix2dos to convert the file back to CRLF newlines.
[15:51] <evanton> wait
[15:51] <Peng_> D'oh.
[15:51] <evanton> aha
[15:51] <evanton> so now my only option is to manually convert files?
[15:52] <james_w> I'm afraid so
[15:52] <james_w> though it may be possible to write yourself a hook to correct it when it happens
[15:52] <awilkins> My preferences in order would probably be i) Don't version generated content, version sources and optionally the tools 2) fix the tool that generates the file to use the line endings of your choice 3) hasten the development of the line endings stuff by contributing 4) wait for the line endings stuff passively
[15:53] <evanton> how do I know which files are binary so I could skip them?
[15:54] <Peng_> evanton: The usual heuristics are to use the filename (e.g. .png files are probably binary), or to check for the presence of NUL bytes.
[15:54] <james_w> in your case I assume you know the names of the files that will be affected
[15:55] <mathrick> can you have ghosts and still resolve them (ie. if they are present on the parent branch)?
[15:56] <evanton> james_w: that's correct, but in general cases when I have a lot of modified files, I'd rather run unix2dos against every file of the branch (except binaries)
[15:56] <james_w> mathrick: what do you mean by resolve?
[15:56] <mathrick> evanton: why not include that in your makefile rules?
[15:57] <mathrick> james_w: get info / contents of when needed
[15:57] <james_w> you would have to fetch the ghosts first
[15:57] <evanton> it's a pity that the output of "bzr status" is the same for text and binary files
[15:57] <mathrick> hmm, lemme write up what I have in mind
[15:58] <james_w> unless you knew what were ghosts and could ask the other branch for the information
[15:58] <evanton> does bzr do binary patching on modified binary files or just replaces them?
[15:58] <james_w> or just catch RevisionNotPresent and try the other branch
[15:58] <james_w> evanton: you mean in it's internal storage format?
[15:59] <mathrick> let's say I have a parent repo p, with revisions p1 .. pn. Now I want to make a branch b, which has b1 .. bn present, but all of p1..pn are ghosts in it
[15:59] <evanton> james_w: yes
[15:59] <mathrick> would that work if I wanted to merge it with a parent / another branch b2?
[16:00] <james_w> evanton: yeah, it stores deltas at least some of the time
[16:00] <evanton> ok, thanks
[16:00] <james_w> mathrick: that's a stacked branch, if pn is a parent of b1
[16:02] <awilkins> What's the recommended procedure for submitting "tweaks" to the list
[16:02] <mathrick> james_w: oh, and what exactly does that mean?
[16:02] <awilkins> Do you just say "ok then" and let the merging developer do it?
[16:02] <Peng_> I think the current delta format is line-based, though..
[16:03] <james_w> awilkins: the original submitter will do it
[16:03] <awilkins> james_w: That be me then :-)
[16:03] <james_w> awilkins: if it's a trivial tweak then the approver will normally not vote tweak and just do it
[16:04] <Stavros> hello
[16:04] <james_w> the difference between resubmit and tweak is partly a difference in expectation of the time it will take, and partly an indication of the approval for the approach taken.
[16:04] <awilkins> FAir enough
[16:04] <Stavros> i'm looking for a good bug tracker that hopefully supports bzr, does anyone know of one?
[16:05] <Stavros> i don't want it to be open source, like launchpad, though
[16:05] <james_w> you don't want it to be open source?
[16:06] <james_w> and what do you mean by "supports" bzr?
[16:06] <Stavros> i mean, i don't want it mandate my code being open source
[16:06] <awilkins> DO you mean you want an instance that supports non-open projects, or that you don't want to use any OSS software even on a provate server?
[16:06] <Stavros> and by "supports" i mean have integration with bzr
[16:06] <awilkins> Trac has some integration
[16:06] <Stavros> i'd like to use OSS if possible, but i would like it to support non-OSS projects
[16:07] <Pilky> Stavros: if you're willing to do a bit of hacking then lighthouse would work
[16:07] <Stavros> Pilky: what's it written in?
[16:07] <Pilky> rails, it's a hosted solution
[16:07] <awilkins> When is Launchpad being Opened anyway?
[16:07] <Stavros> aha
[16:07] <Stavros> thanks, i'll look into it
[16:08] <Pilky> but you'd need to write a post commit hook to talk to their API
[16:08] <Peng_> Redmine supports bzr, but I dunno how much VCSes are integrated with the bug tracker.
[16:08] <mathrick> james_w: is there any RTFM around about stacked branches?
[16:08] <Pilky> they have one written in ruby for svn which would make a good starting point, I was going to write one myself but I haven't had time to learn python yet
[16:08] <james_w> mathrick: there's a bit of documentation that I think made it to bzr.dev
[16:08] <Peng_> Yes, it did.
[16:09]  * mathrick updates
[16:09] <Stavros> Pilky: it shouldn't be very hard, knowing bzr
[16:09] <mathrick> is that a new feature?
[16:09] <james_w> mathrick: it will be in 1.6
[16:09] <mathrick> k
[16:10] <Pilky> Stavros: well, doing something knowing bzr is different to doing something knowing python. I've got a few scripts and I'm writing a GUI for bzr, don't know a huge amount of python ;)
[16:10] <Stavros> Pilky: that's true, i meant for me :p
[16:10] <Stavros> Pilky: http://www.poromenos.org/tutorials/python
[16:11] <Pilky> yeah, I've not found a true python tutorial online yet
[16:11] <Stavros> Pilky: how do you mean true?
[16:11] <Pilky> well all the ones I've seen have been like that
[16:11] <Stavros> Pilky: do you know any other languages?
[16:11] <Pilky> basically listing the data types, control blocks etc
[16:12] <Pilky> Objective-C, C, Java, PHP, Haskell, bit of VB6 (unfortunately)
[16:12] <Pilky> I prefer learning while building something
[16:12] <Stavros> hmm, you shouldn't need a very detailed tutorial then
[16:12] <Stavros> but try "dive into python", it's pretty good
[16:13] <Pilky> tried that, it's same as everything else
[16:13] <Stavros> hmm
[16:13] <Pilky> each chapter seems to be "here's a big chunk of code, now lets analyse it"
[16:13] <Stavros> ah
[16:13] <Pilky> I find I learn better if there are real tutorials, projects that you work through that show you why a language is cool
[16:13] <LarstiQ> mathrick: if you have b1 ... bn but not p1 ... pn, you should still be able to merge.
[16:14] <Stavros> Pilky: hmm, i don't know any like that, sadly
[16:14] <mathrick> LarstiQ: cool
[16:14] <Stavros> by the way, is redmine any good?
[16:14] <LarstiQ> Stavros: a friend of mine uses it, haven't heard a complaint so far. But that is all I know.
[16:14] <Stavros> ah, thanks
[16:15] <mathrick> I wanted that for an idea of how to implement good rebase --interactive
[16:15] <Pilky> Stavros: yeah, I found it surprising that there weren't any tutorials like that online for Python, especially given how popular it seems to be
[16:15] <Stavros> Pilky: i don't know any tutorials like that for any language, i don't think
[16:17] <Pilky> they are far and few between unfortunately
[16:18] <Pilky> I'm kinda spoiled by the book I used to learn Cocoa
[16:18] <LarstiQ> Pilky: http://www.pythonchallenge.com/
[16:18] <LarstiQ> Pilky: focus is a bit lopsides towards http and images, but it's fun anyway.
[16:19] <Pilky> hmm, that's a bit closer to what I'm looking for, but doesn't explain about python as you do it
[16:20] <Pilky> for example, the Cocoa book I used builds up your knowledge by making you write several apps
[16:21] <LarstiQ> Pilky: you could try the TG wiki in 20 minutes or something like that.
[16:21] <LarstiQ> Pilky: but of course, _my_ advice would be to contribute to bzr ;)
[16:21] <luks> http://docs.python.org/tut is a good one, IMO
[16:22] <Pilky> there's a text to speech app, employee raise tracking app, a car lot tracking app, a typing teacher, an amazon search app etc, simple apps but showing you real world applications
[16:24] <Pilky> LarstiQ: heh, well I'm wanting to extend a few bits with plugins, hence me wanting to learn python
[16:24] <LarstiQ> Pilky: I admit there is a use to that sort of approach, but most people I know start (Python) with several projects in mind.
[16:25] <LarstiQ> Pilky: I do suggest you read the url luks pasted again, it takes you 15 to 30 minutes I guess, and then you'll be up to speed enough.
[16:25] <LarstiQ> Pilky: and for the rest, talking/review of more experienced users is what I'd suggest.
[16:25] <LarstiQ> Pilky: oh, and reading existing code.
[16:26] <Pilky> yeah, I'll have a look through when I have a few minutes spare
[17:57] <carljm> hey all - is there a trick to working with symbolic links?  i've got a versioned symlink that I want to remove, but "bzr rm my_link" just says "ERROR: Not a branch: /place/sym/link/points/to/"
[17:59] <luks> the trick for bzr rm is easy, just rm it
[17:59] <james_w> carljm: I think there may be a bug there, you may want to search the bug list
[17:59] <luks> I'm sure there is a bug report about it
[18:00] <carljm> ok, thanks
[19:15] <BrianRice> I'm getting a "WARNING: bzrlib version doesn't match the bzr program." message from bzr after using the latest OS X Leopard DMG installer. I tried running uninstall-bazaar.py which seems to succeed and then re-ran the DMG installer, but I get the same result. what can I do to fix/debug this?
[19:16] <james_w> hey BrianRice
[19:16] <BrianRice> (I'm installing 1.5 over what may be 1.1)
[19:16] <BrianRice> hi
[19:16] <james_w> looking at the output of "bzr version" would be a good place to start
[19:16] <james_w> that will show what the two bits it is using are
[19:16] <BrianRice> yeah, I've looked. mind if I paste the results?
[19:17] <james_w> should be ok
[19:17] <BrianRice> (pastebot preferred of course)
[19:17] <BrianRice> ok I'll keep it short...
[19:17] <BrianRice> bzr: WARNING: bzrlib version doesn't match the bzr program.
[19:17] <BrianRice> This may indicate an installation problem.
[19:17] <BrianRice> bzrlib from ['/Library/Python/2.5/site-packages/bzrlib'] is version (1, 5, 0, 'final', 0)
[19:17] <BrianRice> Bazaar (bzr) 1.5
[19:17] <BrianRice>   Python interpreter: /System/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python 2.5.1
[19:17] <BrianRice>   Python standard library: /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5
[19:17] <BrianRice>   bzrlib: /Library/Python/2.5/site-packages/bzrlib
[19:18] <BrianRice> I've rm -Rf'd the bzrlib directory mentioned there between installation cycles, but didn't get an improved result
[19:19] <BrianRice> at the very least, I have one machine on which the installer worked, but my older machine with the existing bzr installation has this issue.
[19:19] <james_w> what does "which bzr" report?
[19:20] <BrianRice> /usr/bin/bzr
[19:21] <BrianRice> aha, /usr/local/bin/bzr is different
[19:22] <BrianRice> and "version" on that does not complain, so that must be the result of the installer (I hope)
[19:23] <james_w> yup, you're /usr/bin/bzr is probably your 1.1 one
[19:23] <BrianRice> seems to work now, thanks! :)
[19:26] <james_w> no problem
[19:45] <rocky> hmm... i would love to have some easy way to have my merge commit include the commit msgs of all of the other-branch commits that make up this merge
[19:47] <james_w> rocky: there's no easy way to do that as far as I know
[19:48] <james_w> bzr log -rancestor:../branch-you-are-about-to-merge-in-to > ../commit_message
[19:48] <james_w> do the merge, edit ../commit_message, and then commit with -F
[19:48] <james_w> that could be one way to simulate it, but it's obviously not ideal
[19:53] <LarstiQ> then again, in most cases I wouldn't find that desirable anyway. In rocky's svn-no-merged-revisions case, it can make sense.
[19:56] <pickscrape> rocky: that's the last thing you want. Trust me on that as a former svk user :)
[19:56] <pickscrape> If your usage patterns are anything like ours you will end up with 50M+ commit messages.
[20:03] <rocky> lol
[20:35] <jelmer> rocky: bzr-svn 0.4.11 will support pushing the merged revisions as well, not just those on mainline
[20:35] <jelmer> and it will set the appropriate svn:mergeinfo properties that svn 1.5 uses
[20:37] <ahasenack> hi, is there going to be a bzr 1.6b4? I ask because 1.6b3 backtraces for me with bzr+ssh:// (https://bugs.launchpad.net/bzr/+bug/249256), but this was already fixed but not released
[20:38] <ahasenack> or was it...?
[20:38] <james_w> hi ahasenack
[20:39] <ahasenack> james_w: hi
[20:39] <james_w> poolie will be the best person to ask, but it's not the right time for him
[20:39] <james_w> if you're around for another few hours then you can ask, otherwise a mail to the list might be a good way to get an answer
[20:39] <ahasenack> or just ping in that ticket
[20:40] <ahasenack> it says released, but I don't see it in ppa, maybe upstream, let me check
[20:40] <ahasenack> hmm, no, upstream is at 1.5
[20:40] <james_w> bzr uses released to mean in bzr.dev
[20:41] <ahasenack> and committed means what?
[20:42] <james_w> in a branch somewhere
[20:42] <ahasenack> ah, ok
[20:42] <james_w> we discussed this a couple of weeks ago
[20:42] <james_w> everyone agrees that it's not ideal, but doing the committed->release step on release would be a pain
[20:43] <james_w> having some launchpad help would be good, we have a list of bugs fixed from NEWS, and we also have many revisions with --fixes, so launchpad could do better
[20:43] <ahasenack> james_w: you mean to switch all bugs into released state?
[20:44] <james_w> yeah, take all the ones that are fixed in a release and set them to the released state, and possibly also set the milestone to that release
[20:44] <ahasenack> all bugs in committed state, I mean
[20:44] <ahasenack> yeah, I feel that pain too. It's in my whishlist for lp to allow changing several bugs at once
[20:44] <james_w> that could possibly work as well
[20:44] <ahasenack> I regularly have to switch around 25 bugs from committed to released
[20:45] <ahasenack> maybe with the new api stuff
[20:45] <james_w> can you track a bug in multiple releases in a project, like you can in a distro package?
[20:45] <james_w> yeah, it wouldn't be hard for us to have a script that just grabs all of the bug numbers from NEWS and changes them all
[20:45] <james_w> launchpad should still think about solving this somehow though.
[21:10] <plexq> hello - anyone know how I can change my submit branch?
[21:11] <matkor> bzr <sth>  --remember  ?
[21:12] <plexq> what is <sth>?
[21:13] <matkor> what sets submit branch ?
[21:13] <matkor> bzr push ? merge ?
[21:14] <beuno> send
[22:00] <colbrac> jelmer: Shame the info dialog reworking was not merged.. missed that :(
[22:02] <LarstiQ> colbrac: point release! point release! ;)
[22:02] <colbrac> lol
[22:04] <colbrac> That would depend on the powers of Russel Winder, he complained about the (now shipped) version
[22:26] <mwhudson> beuno: good morning
[22:32] <beuno> mwhudson, mornin'
[22:32] <mwhudson> beuno: i just merged themed-directory-listing
[22:32] <beuno> mwhudson, yay!  thanks
[22:33] <Peng_> Ooh.
[22:33] <beuno> mwhudson, now I have to fix setup, which seems to not work properly. Then I'll take a peak at what other 1.6 release bugs we have.  Anything special you fancy?
[22:35] <mwhudson> beuno: so thumper did https://code.edge.launchpad.net/~thumper/loggerhead/branch_locations
[22:36] <thumper> mwhudson: that only just got pushed
[22:36] <thumper> mwhudson: are you getting notifications?
[22:36] <mwhudson> thumper: no, i was just looking for it
[22:36] <mwhudson> thumper: mind if i make it public?
[22:37] <thumper> mwhudson: it is now public
[22:37] <mwhudson> ok
[22:38] <mwhudson> we could probably change the privacy policy now
[22:38] <beuno> mwhudson, I'd also like for you to take a look at: https://bugs.edge.launchpad.net/loggerhead/+bug/254411
[22:38] <Peng_> mwhudson: Comments on the themed directory listings: 1.) Yay!, 2.) There's no link to the parent directory?, 3.) What about linking the revno to the changes page or something?
[22:39] <beuno> it comes with patches, and I'm not really that saavy on how that part of LH works
[22:39] <mwhudson> Peng: 1) cool, 2) well there wasn't before, one thing at a time :), 3) good idea
[22:40] <mwhudson> beuno: i wonder if he'd be happier with serve-branches
[22:40] <beuno> mwhudson, he might, but it's still a valid bug with a patch, isn't it?
[22:41] <Peng_> Hmm, I could probably figure out how to do #3 myself.
[22:42] <mwhudson> beuno: let's see how he responds to my comment, i'd really rather let config.py rot and die :)
[22:42] <mwhudson> beuno: impressive that he figured out how to hack the code to do what he wanted though :)
[22:43] <Peng_> Oh, also, sorting?
[22:43]  * Peng_ runs away.
[22:43] <Peng_> (I just noticed that /files does sorting.)
[22:43] <beuno> mwhudson, it really is. Shows a lot of will to help  :)
[22:43]  * beuno knew we should of removed sorting, that only puts the bar higher for the rest of the UI
[22:43] <mwhudson> Peng_: can you guess what patches are?  starts with 'w', ends in 'elcome'
[22:44]  * beuno takes a look at thumper's merge request
[22:44] <mwhudson> Peng_: the hard thing about '..' links is knowing when not to show them
[22:46] <beuno> thumper, where does branch_link come from?
[22:47] <mwhudson> beuno: sekrit launchpad glue
[22:47] <mwhudson> beuno: but!
[22:47] <thumper> beuno: it comes from whatever creates the BranchWSGIApp
[22:47]  * beuno waits for a good explanation for that to land in trunk
[22:47] <thumper> beuno: which on the default server_branches is non existant
[22:47] <SteveA> hi
[22:47] <SteveA> does anyone run the bzr test suite on mac os x ?
[22:48] <mwhudson> beuno: i think that the filesystem server should use links back to the directory listing when it can
[22:48] <mwhudson> beuno: maybe
[22:48] <mwhudson> i haven't really thought about this too hard
[22:48] <beuno> mwhudson, it should. We just have to make sure we're not on the top level
[22:48] <mwhudson> SteveA: i think vila, igc and jam sometimes use os x
[22:48] <beuno> Verterok does too
[22:48] <mwhudson> beuno: well, maybe not the branch name, thinking about it
[22:48] <mwhudson> beuno: but something :)
[22:49] <SteveA> mwhudson: __lucio__ just started working with me.  he ran the bzr tests on mac on x, and is seeing some failures.
[22:49] <mwhudson> SteveA: i guess that's not massively surprising
[22:49] <SteveA> really?
[22:50] <SteveA> I find a broken trunk massively surprising.
[22:50] <Verterok> Hi beuno
[22:50] <__lucio__> http://pastebin.com/m39e37fff
[22:50] <SteveA> how can we expect contributions from someone working on mac os x if the trunk is broken?
[22:50] <beuno> hi Verterok. Maybe you can help?  ^
[22:50] <mwhudson> SteveA: how can we be sure that trunk isn't broken without automatic checks?
[22:51] <mwhudson> __lucio__: that looks a bit special though
[22:51] <beuno> thumper, can I see your patch in action somewhere?
[22:51] <__lucio__> mwhudson: special how?
[22:52] <mwhudson> __lucio__: as in 'really broken'
[22:52] <thumper> beuno: can you see the canonical pastebin?
[22:52] <beuno> thumper, I never know, but I don't think so.
[22:52] <thumper> beuno: can you give me a pastebin link?
[22:53] <beuno> !pastebin
[22:53] <beuno> damn
[22:53] <__lucio__> mwhudson: it did manage to run 204 tests without problems
[22:53] <Verterok> beuno: it's been a while since I executed the full test suite, but as I remember I hit some filesystem issues (max files limit, etc)
[22:53] <beuno> thumper, http://paste.ubuntu.com/
[22:53] <mwhudson> __lucio__: that error stopped the test suite?
[22:53] <__lucio__> mwhudson: yes
[22:53] <mwhudson> __lucio__: there are ~12000 tests in the test suite these days
[22:53] <mwhudson> __lucio__: file a but
[22:53] <mwhudson> bug
[22:54] <__lucio__> ok.
[22:54] <lifeless> SteveA: a broken trunk on a platform no developer is actively using is not surprising - its not desirable, but its not surprising
[22:54] <thumper> beuno: http://paste.ubuntu.com/34199/
[22:54] <SteveA> lifeless: might be the reason no developers are actively using it
[22:54] <thumper> :)
[22:54] <beuno> thumper, ah, can I run this against launchpad.dev?  because I do have that
[22:55] <SteveA> lifeless: I can imagine a keen mac os x dev wanting to fix a bug, getting the trunk, running the tests, finding many failures, and going "screw this, it doesn't work"
[22:55] <lifeless> SteveA: it might be but I don't think it is; there are non-core developers building Mac OSX installers regularly, and we get test feedback then
[22:55] <mwhudson> bzr basically works on os x
[22:55] <Verterok> SteveA, lifeless: I'm using os x :)
[22:55] <thumper> beuno: it required an annoying amount of hacking to get `make run_all` to start loggerhead again
[22:55] <SteveA> Verterok: yay!
[22:55] <lifeless> Verterok: are you - cool
[22:55] <thumper> beuno: it used to work, but for some reason I hit problems
[22:55] <thumper> beuno: but I did get it working on launchpad.dev
[22:56] <lifeless> SteveA: anyhow, if you can contribute a macos X developer that will run all tests with high frequency that would be great :)
[22:56] <lifeless> oh, and hi __lucio__
[22:56] <mwhudson> i have a machine that's mostly idle
[22:56] <SteveA> lifeless: I'll see what I can do
[22:56] <beuno> thumper, either way, we should provide some way of using this in LH, or documentation, so it doesn't end up as dead code
[22:56] <lifeless> mwhudson: its the developer attention on the results that matters most
[22:56] <SteveA> mwhudson: ftw
[22:56] <Peng_> mwhudson: http://bzr.mattnordhoff.com/bzr/loggerhead/dirlisting-revno-link -- seems to work. I took out a tal:condition because a surrounding block does the same thing, so I thought it was redundant. (But I don't know SimpleTAL, so I might be wrong.)
[22:56] <mwhudson> lifeless: yeah
[22:56] <Peng_> I just stole code from, uh, inventory.pt, but like I said, it seems to work.
[22:57] <beuno> Peng_, cool!  now, if you can make it *not* show the parent link when you're at the top level, you've got a patch!
[22:58] <Peng_> beuno: Oh? What'd I do wrong?
[22:58] <thumper> beuno: can you think of a use for it in LH itself?
[22:58] <beuno> Peng_, just that you still have the "Parent link" on there when you've reached the top level, and it doesn't go anywhere
[23:00] <Verterok> lifeless: I can try to run the full suite (at least one or two times a week). I usually don't mainly because I hacked on very specfic parts of bzr or plugins
[23:00] <Peng_> beuno: What parent link? I only changed that one link, nothing else.
[23:00] <lifeless> Verterok: if you want to find and fix bugs a couple times a week that would rock
[23:00] <lifeless> Verterok: note that this isn't the same thing :)
[23:00] <Verterok> lifeless: heh, I can try :)
[23:01] <beuno> thumper, I'm thinking...
[23:01] <Verterok> about fixing them ;)
[23:01] <awilkins> Running the tests on windows leaves a huge amount of temp dirs hanging around
[23:01] <beuno> Peng_, http://bzr.mattnordhoff.com/bzr/
[23:01] <Peng_> beuno: That's not Loggerhead. http://bzr.mattnordhoff.com/loggerhead/ is Loggerhead.
[23:02] <Peng_> I don't think I'm smart enough to add parent links. :)
[23:02] <Peng_> At least, quickly..
[23:02] <awilkins> Can you hook garbage collection of an object in Python?
[23:02] <Peng_> Hmm, when you're at the top level, I think the <title> of the page reveals the real name of the directory.
[23:03] <beuno> Peng_, ah, right, that isn't even the same theme.  I should pay more attention  :p
[23:04] <Verterok> awilkins: hook into gc? __del__ method maybe?
[23:05] <beuno> thumper, maybe we can just add that with some explanation on how to feed LH that info?
[23:07] <Verterok> __lucio__: hi :)
[23:07] <__lucio__> hi Verterok , hi all :)
[23:07] <awilkins> Verterok: I was wondering if hooking that in the bit of the test case object that removes folders would be better.
[23:07] <beuno> __lucio__, hi!  you're working in Canonical now?
[23:08] <__lucio__> beuno: yep. just started.
[23:08] <beuno> __lucio__, welcome  :)
[23:08] <__lucio__> danke :)
[23:08] <Verterok> __lucio__: wow!
[23:10] <Verterok> awilkins: I don't known the tests magic enough :(
[23:10] <pickscrape> One of my colleagues today noticed that loggerhead's new skin doesn't have an option to view the diff as unified like the old one did
[23:11] <beuno> pickscrape, yeap, that's been filed as a bug
[23:11] <pickscrape> beuno: excellent, I'll let him know :)
[23:12] <lifeless> SteveA: __lucio__: python bug
[23:12] <lifeless> tarfile.open(None, "w|gz", sys.stdout) -> boom, on your machine afaict
[23:15] <pickscrape> Hmm, does anything recently committed to loggerhead require bzr 1.6?
[23:15] <lifeless> pickscrape: I believe so
[23:15] <beuno> pickscrape, yes, viewing changes to a file
[23:15] <pickscrape> Ah
[23:15] <beuno> that should be fixed this week
[23:16] <pickscrape> Actually it's the directory view that's breaking for me right now
[23:16] <pickscrape> ReservedId: Reserved revision-id {null:}
[23:16] <beuno> pickscrape, oh, that's new
[23:16] <beuno> pickscrape, can you pastebin the traceback?
[23:17] <pickscrape> It's only when viewing the root...
[23:17] <pickscrape> !paste
[23:19] <pickscrape> beuno: http://paste.ubuntu.com/34205/
[23:20] <pickscrape> As I say, it only happens in the root directory. subdirectories of it (that are also just directories) aren't affected.
[23:21] <beuno> pickscrape, what version of bzr are you running?
[23:23] <pickscrape> 1.5
[23:24] <pickscrape> I've been tempted to put 1.6 on the server for a while now, but it's a pretty critical system :)
[23:24] <beuno> pickscrape, can you file that as a bug?
[23:24] <pickscrape> Certainly.
[23:25] <beuno> pickscrape, thanks  :)
[23:25] <lifeless> james_w: 3117 follow up posted
[23:26] <james_w> did you see my followup question?
[23:27] <lifeless> ah just arrived
[23:27] <lifeless> no its not an api break
[23:27] <lifeless> if it was a required parameter it would be an api break
[23:28] <lifeless> this isn't C++ we don't have linkage determined by function signature :)
[23:28] <Verterok> lifeless, __lucio__: about Bug #254791, it's fixed in Python 2.5.2 :)
[23:28] <pickscrape> beuno: bug 254794
[23:28] <__lucio__> Verterok: what was it?
[23:29] <pickscrape> Looking at it now that doesn't seem like such a good bug title :)
[23:29] <beuno> pickscrape, rockin', thanks
[23:29] <james_w> lifeless: but if I implement .commit() then you force me to update for this change. I'm not sure it's something we care about, and I may be using "API break" wrongly.
[23:30] <Verterok> __lucio__: as lifeless commented, a python bug
[23:30]  * Peng_ waves. Comments on my trivial patch? Want me to send it to the list?
[23:30] <beuno> Peng_, URL again?  I'll look n' merge
[23:31] <Peng_> beuno: Branch is at http://bzr.mattnordhoff.com/bzr/loggerhead/dirlisting-revno-link
[23:31] <Peng_> You can see it in LH at http://bzr.mattnordhoff.com/loggerhead/loggerhead/dirlisting-revno-link/revision/192 :)
[23:32] <lifeless> james_w: what do you mean then :)
[23:33] <beuno> Peng_, cool, thanks, I'll merge
[23:33] <Peng_> beuno: Thanks. :)
[23:33] <pickscrape> beuno: upgrading to bzr 1.6 doesn't fix it
[23:33] <james_w> lifeless: I mean forcing plugins to make a change at the same time as the core.
[23:33] <beuno> pickscrape, ah, then we have a different problem.  Is the branch you are running the problem in public?
[23:34] <pickscrape> I'm afraid not
[23:34] <pickscrape> It isn't a branch either: the root is just a directory
[23:34] <lifeless> james_w: ok, I see. Yes, plugins that implement MutableTree.commit() need to change
[23:34] <james_w> lifeless: it's the other way round to usual. I think that not having commit() called commit() would be a bit off though
[23:34] <thumper> Peng_: I like the icons on the listing
[23:34] <Peng_> thumper: It's the new theme in the trunk. :)
[23:35] <james_w> lifeless: I have no idea if anything does, bzr-svn may I guess.
[23:35] <lifeless> few plugins add implementations of commit though - I only know of git/svn/hg
[23:35] <lifeless> and then, its only for 'bzr commit' while sitting in a native svn etc tree
[23:35] <james_w> yeah, I don't know what the policy is here, but I wanted to flag it so that at the least I could find that policy out
[23:35] <lifeless> note that adding a new method would also still force the plugin to change: the UI code would be calling the new method
[23:36] <james_w> there's prior art for adding a "hasattr" I believe
[23:36] <lifeless> james_w: yes, but not in this case:
[23:36] <james_w> in the log code I think
[23:36] <lifeless> a) it was fugly inlog
[23:37] <lifeless> b) MutableTree would have commit_2(), so all subclasses of it would as well
[23:37] <lifeless> so it would always be tree
[23:37] <james_w> true
[23:37] <lifeless> also
[23:37] <lifeless> nvm
[23:37] <james_w> that's fine, you just might want to give a certain ninja plugin developer a heads up.
[23:37] <beuno> pickscrape, and that is LH trunk?  on what revno?
[23:37] <lifeless> jelmer: tree.commit has a new parameter, kthxcode
[23:38] <james_w> done :-)
[23:38] <lifeless> actually, I'll document this
[23:38] <pickscrape> beuno: 191. Did I not put that in the bug report?
[23:39] <beuno> pickscrape, you did, sorry.  This is a shared repo it's running on?
[23:39] <pickscrape> Not at the root level
[23:39] <pickscrape> The root is a plain directory that contains a number of shared repositories
[23:39] <pickscrape> In each of these are both branches and other plain direcotries
[23:40] <beuno> ok, I see now, it's my fault.  I'm not filtering NULL revisions
[23:40] <jelmer> lifeless, thanks for letting me know :-) Already in bzr.dev ?
[23:40] <jelmer> lifeless, Good thing I hadn't put 0.4.11 out yet...
[23:41] <lifeless> jelmer: may not hit 1.6; about to go to bzr.dev if james is giving me +1
[23:44] <beuno> does this look familiar to anyone?  http://paste.ubuntu.com/34208/
[23:44] <beuno> I just updated bzr.dev
[23:45] <beuno> (to work around bug #249256)
[23:45] <lifeless> james_w: so - +1?
[23:46] <spiv> beuno: it doesn't look familiar to me...
[23:46] <james_w> lifeless: sorry, I'm busy with other stuff, I can review if you like, but I don't have a vote, so it wouldn't count for anything
[23:46] <beuno> spiv, so file a bug?
[23:46] <james_w> lifeless: everything looked pretty sounds first time around though
[23:47] <spiv> beuno: yeah, I think so
[23:47] <beuno> Peng_, is your server doing aything special I should be aware of?
[23:47] <Peng_> beuno: bzr+http is on.
[23:47] <lifeless> spiv: can I ask for an insta review? james_w has reviewed my 3117 branch - latest mail should have just hit the list
[23:48] <Peng_> beuno: Also, it's Lighttpd, not Apache.
[23:48] <lifeless> spiv: but it needs someone with voting to say he was right :P
[23:48] <spiv> lifeless: Ok
[23:48] <beuno> Peng_, bzr version you're running?
[23:49] <Peng_> beuno: Uhh, hold on.
[23:49] <Peng_> beuno: bzr.dev.
[23:49] <beuno> Peng_, renvo?  (sorry to be such a pain)
[23:50] <mwhudson> is something like 'merge' for looms implemented yet?
[23:50] <Peng_> beuno: Latest.
[23:50] <lifeless> mwhudson: TODO
[23:50]  * jml sads
[23:50] <Peng_> beuno: 3602
[23:50] <mwhudson> lifeless: as i suspected
[23:51] <beuno> Peng_, cool, you are now part of bug #254797 then  :)
[23:51] <beuno> Peng_, meanwhile, can you send me a bundle for you're patch?
[23:51] <Peng_> I should just turn off bzr+http. Launchpad hates it, and now plain bzr does too?
[23:52] <beuno> Peng_, please don't, or it will never get fixed  :)
[23:53] <Peng_> beuno: http://bzr.mattnordhoff.com/bzr/loggerhead/dirlisting-revno-link/dirlisting-revno-link.patch
[23:53] <Peng_> So, this time, I didn't manage to break Loggerhead, just bzr? :)
[23:53] <beuno> Peng_, yes, we're finally starting to win!
[23:54] <Peng_> Heh.
[23:58] <beuno> lifeless, I'm hitting this again:  http://paste.ubuntu.com/34209/
[23:59] <beuno> we already danced around this for this same branch a few months ago, but I don't remember what came out of it
[23:59] <lifeless> beuno: ah yes we haven't tracked that down yet
[23:59] <beuno> lifeless, want to give it another shot, or should I just push --overwrite?