#bzr 2008-08-04
<lifeless> op not permitted is interesting
<LarstiQ> Necoro: perhaps an umask?
<lifeless> could be the foo.bar.baz file naming
<lifeless> if its not mounted vfat it can't do that
<lifeless> OTOH repository > 8 anyhow so that can't be it
<Necoro> lifeless: its vfat
<LarstiQ> lifeless: afaik fat doesn't like chmodding to something it can't represent, and raises EPERM.
<lifeless> LarstiQ: interesting
<lifeless> whats the backtrace show?
<LarstiQ> but I really need to sleep, ciao
<lifeless> (from ~/.bzr.log)
<Necoro> LarstiQ: ciao and thanks
<Necoro> lifeless: http://rafb.net/p/BCAK0b42.html
<Necoro> lifeless: and using the print-debugging-style I saw, that it's an os.chmod that's raising the error
<lifeless> ok
<lifeless> we shouldn't be chmodding usually anyhow
<lifeless> I thought you had to turn on a config option to set that
<lifeless> chmodding is slow
<lifeless> in fact -
<lifeless> note this line:
<lifeless> control_files.put_utf8(file, content)
<lifeless> the control files have been initialised with none-None file mods
<lifeless> can you try just 'bzr init' on the usb drive?
<lifeless> and definitely file bus
<lifeless> *bugs*
<Necoro> lifeless: bzr init doesn't work either
<Necoro> lifeless: bug #254514
<ubottu> Launchpad bug 254514 in bzr "Can't create branch/repo on vfat" [Undecided,New] https://launchpad.net/bugs/254514
<Necoro> ok - time to go to bed ... =) - ciao
<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?
<jelmer> meteoroid, just use a bound branch
<meteoroid> a bound branch, eh?
<jelmer> meteoroid: e.g. a bzr branch bound to a svn branch
<jelmer> meteoroid, see the docs for details
<meteoroid> sure
<jelmer> but basically, just run "bzr bind <svn-url>" to do that
<meteoroid> any alternatives for svn:externals ? i think i'm just going to write a script to dl that format of repo urls
<jelmer> not at this point
<meteoroid> can bzr set svn props?
<jelmer> bzr nested trees haven't landed yet but even when they will, it won't be possible to map svn:externals to them
<meteoroid> okay
<jelmer> perhaps bzr-svn can generate a boilerplate config-manager file or something
<meteoroid> hm..
<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?
<jelmer> lifeless, Does that sound sensible ? What are the plans for cm?
<jelmer> markh, it's not likely to be an issue
<markh> cool
<jelmer> markh, if I understand the test output correctly it's something that should be fixed in bzrlib
<markh> yeah, but I was wondering how to present that :)
<markh> ie, if you had an idea of *what*, so I would attempt a patch
<markh> I haven't dug at all - looking for an easy answer ;)
<jelmer> TestCaseInTempDir has a test_dir attribute with inconsistent (different os.path.sep) contents
<Odd_Bloke> CM really needs fixing to not use pybaz.
<jelmer> 'evening poolie
<poolie> hello jelmer
<Odd_Bloke> Else it's likely to be removed from Debian along with bazaar and friends.
<jelmer> poolie: I'm looking at doing bzr-svn and bzr-gtk releases in the next couple of days
<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?
<lifeless> jelmer: well I'd like to delete cm
<lifeless> jelmer: but that means bzr being able to map into foreign systems pervasively etc
<jelmer> lifeless: In favor of what?
<lifeless> jelmer: why won't a bzr tree be able to refer to a svn url for the source of a nested tree?
<lifeless> jelmer: nested trees everywhere
<jelmer> nested trees require a specific revision in the nested tree to be referenced
<lifeless> yes ...
<jelmer> svn:externals allows current head to be referenced, whatever that is at the time the user does the checkout
<lifeless> nested trees permit that too; its UI not core
<lifeless> thats just 'bzr update' after checkout
<jelmer> well, it's not there atm :-)
<jelmer> lifeless: there's also no way to represent that in the current inventory entry class for nested trees
<lifeless> jelmer: in that update is desired? true
<poolie> lifeless: what is cm?
<lifeless> config-manager
<meteoroid> jelmer: externals allow referencing revisions as well
<meteoroid> but typically we use a tag
<lifeless> meteoroid: yes, jelmer is saying that nested trees are a subset of the externals interface
<meteoroid> oh ok, allows, sure
 * meteoroid goes back to trying to get bzr webdav and smart server working in apache
<poolie> i thought so
<poolie> i thought that was an answer re api breakage that's all
<poolie> jelmer, i think it should be just bug fixes from now on
<poolie> the only one i know of so far is that upgrade does not work on a stacked branch
<poolie> lifeless: i'm planning to fix that by making open_unsupported (or similar) take an option to open the branch without fallback repositories
<lifeless> perhaps open_unsopported should be renamed to open_for_upgrade
<lifeless> -> doctor
<poolie> open_backdoor
<beuno> mornin' everyone
<jelmer> poolie: thanks! I'll start working on getting those release out then
<beuno> mwhudson, howdy.  I've been playing with the browsing template a bit.  Have you had a chance to look at it?
<jelmer> hey beuno
<beuno> evening jelmer
<mwhudson> beuno: ah, not really
<mwhudson> beuno: so i did some more stuff and merged your branch
<mwhudson> beuno: see https://code.edge.launchpad.net/~mwhudson/loggerhead/themed-directory-listing
<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
<poolie> marnanel: easiest is bzr diff -c -1
<poolie> or any revisionspec in place of the -1
<marnanel> poolie: wonderful, thanks
<beuno> mwhudson, looking
<beuno> mwhudson, cool!  you made it even nicer  :)
<beuno> one FIXME to go, and it should be mergeable, no?
<lifeless> poolie: don't forget to ring me ;)
<mwhudson> beuno: probably
<beuno> ok, so you're not as enthusiastic  :p
<beuno> it's still sunday for me, so I'm still in a good mood  :)
<beuno> I'll work on whatever is left to polish tomorrow
<mwhudson> beuno: just busy, really
<mwhudson> beuno: a different icon for branches vs folders would be nice
<beuno> mwhudson, sure, what would that icon be?
<mwhudson> beuno: no idea :)
<beuno> mwhudson, folder + bzr icon?
<mwhudson> beuno: yeah, something like that
<mwhudson> would be great
 * meteoroid wonder if there are any recommended ui for bzr, x11 or otherwise
<poolie> meteoroid, apt-get install bzr-gtk
<meteoroid> that's all i need? rawk!
<meteoroid> i saw 'olive' or something on rhel5 but it was a curses newsreader on ubuntu ;d
<poolie> olive is the main front end
<poolie> um
<poolie> i thought it was included
<poolie> meteoroid, you should get an olive-gtk command when installing that package
<poolie> and i thought it was in the menu
<meteoroid> ok
<poolie_> lifeless, spiv, would one of you (if still online) read my patch for #252428
<poolie_> it's pretty tiny
<lifeless> where is it ?
<lifeless> also, your _ is showing
<lifeless> poolie_: ^
<poolie> on the list
<poolie> http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Ce01316480808040016h4deae0daxa9e4a981983d7206%40mail.gmail.com%3E
<poolie> i'm getting probably spurious failures of other upgrade scenarios
<poolie> actually i just sent an update to the list
<lifeless> poolie: trivial question, why didn't you add the tests to per_repository_reference
<poolie> because they're not going to be 1:1 with repository formats
<poolie> eg i want to try upgrades from knits
<lifeless> right
<lifeless> see bzrlib/tests/repository_implementations/test_repository.py
<lifeless> test_upgrade_from_format4
<lifeless> etc
<poolie> hm
<poolie> you mean i could do one dimension of parameterization by scenarios and the other by having multiple methods?
<lifeless> parameterisation will stack
<lifeless> if you have a load_tests in e.g. per_repository_reference/test_upgrade.py
<Odd_Bloke> Hmm, bzr-buildpackage doesn't seem to be doing signing for me ATM.
<lifeless> then the __init__ parameteriser will get pre-parameterised tests and parmeterise them further
<lifeless> interfaces FTW
<poolie> interesting
<poolie> i did not realise load_tests would join up like that
<poolie> maybe because it's not documented ;-)
<lifeless> well
<lifeless> everything that gets tests triggers load_tests
<lifeless> I'm writing up a review for you
<poolie> lifeless, so how does test_upgrade_from_format4 relate to multiple load_tests?
<matid> Hi there!
<matid> I've got a question regarding bzr-svn and Mac OS X. What's the recommended way to get it working?
<matid> Which version of bzr, bzr-svn, subversion, etc.?
<poolie> it looks like it's not using that approach?
<poolie> matid, um, the latest of each would probably be a good idea :-)
<lifeless> poolie: no, its from before load_tests :) - I'm just noting that you can avoid code duplication if you want :>
<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 :)
<poolie> matid, :-/
<poolie> lifeless, i suppose the other thing i was thinking about here (aside from just not knowing/realising they would stack)
<poolie> is that i didn't necessarily want to test all n**2 combinations, just to pick some interesting ones
<lifeless> poolie: well, your comment in the test suggested that you wanted to have it test all formats for whatever you selected
<lifeless> poolie: concretely, I think we should test every 'stackable repository type' for whatever scenarios are interesting
<poolie> probably
<lifeless> poolie: so its not n**2, its still N(stackable)*[interesting]
<poolie> your updated comment is more correct
<poolie> and i agree moving it would be better
<poolie> i have a feeling this test actually wants to be two tests though
<poolie> on a mostly unrelated matter
<poolie> that is, if there is no model change, you do not need to upgrade
<poolie> hm, well, maybe just the if block is enough
<lifeless> upgrade is already tested in that respect.
<lifeless> that if block is purely UI glue
<lifeless> (and if it is a checkout, the user needs to go over to the branch and try 'upgrade' there anyhoo)
<poolie> in which respect?
<lifeless> if there is no model change -> no upgrade
<lifeless> upgrades only changes stuff when there are things to do
<poolie> btw what would you think of systematizing the pattern i use here of making the injected parameters be scenario_*
<poolie> lifeless, well, going from knits to packs is a substantial change but not a model change
<lifeless> so you're saying that in the test parameterisation you don't want same-model formats for these specific tests?
<lifeless> could just skip the test if the model is the same - just return early
<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)
<lifeless> ah right
<lifeless> yes
<lifeless> thats a good test to have too
<poolie> so the annoying thing about putting this into per_repository_reference
<poolie> although i agree it's good to cover all formats automatically and to have same-things-together
<poolie> is choosing the right corresponding formats
<poolie> hm
<lifeless> should be the same list you had before :P
<lifeless> a knit and a pack of model plain
<poolie> hm
<poolie> are you sure stacking load_tests actually works?
<poolie> it doesn't seem to for me
<poolie> i'm kind of tired of this, i think i'll leave it til tomorrow
<lifeless> ok
<lifeless> I'll peek at that for you tomorrow
<lifeless> could be a bug
<lifeless> sleep well
<poolie> it is 10 hours since i started
<poolie> and probly more for you
<lifeless> :> 11
<lifeless> slept in to 7:30
<lifeless> poolie: I fixed quite an old bug today
<poolie> i saw
<poolie> a four digit bug number!
<poolie> many extra points :)
<lifeless> :)
<poolie> maybe that should factor into lp karma?
<poolie> well
<poolie> have a good night
<lifeless> gnight, you too
<awilkins> Is there a conference on or something? It's deathly quiet in here.
<james_w> I don't think so
<Jc2k> bzr is so bug free and feature complete that it no longer needs irc
 * awilkins watches tumbleweed blow past
<fullermd> Either that or somebody broke bzr-irc.
<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)
<LarstiQ> rocky: ok in what sense?
<LarstiQ> rocky: it works, but it may not be the workflow you want?
<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
<LarstiQ> rocky: your commit history is retained anyway
<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 ?)
<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.
<LarstiQ> rocky: those revisions are still referenced though.
<LarstiQ> rocky: but in your case, you might want to use rebase.
<rocky> rebase seems scary ;)
<LarstiQ> that's because it is ;)
<rocky> sorry, i'm still learning bzr ;)
<luks> not necessarily
<luks> (I mean you might not want to use it)
<LarstiQ> rocky: you can also merge trunk and then push the result of that.
<luks> "obviously after i've merged trunk changes into my branch"
<luks> after this, a simple push to trunk is fine
<luks> but you will get some empty looking merge revisions in your trunk
<rocky> hmm
<rocky> that is probably fine
<rocky> but if i were working with pure bzr (no svn) then the workflow would be to just use merges right? not merge/push ?
<luks> hm, wait
<luks> it will probably not do what you want, especially not with bzr-svn
<luks> if you push such a branch with merged trunk to trunk, the revision numbers in trunk will change
<luks> so doing it the other way around, merging the branches to trunk, is better
<matid> jelmer: Hi. You there?
<awilkins> Hmm, "bzr switch" does not behave as I expect
<awilkins> I have a heavyweight checkout, and "bzr switch bar" does not try to switch to <bound_branch>/../bar, it tries <checkout>/../bar
<james_w> yeah
<awilkins> Is this intentional?
<james_w> yeah
<james_w> though I don't know if it's desirable
<awilkins> It doesn't seem to corresepond to what the help says
<awilkins> lthough the help is vague
<james_w> that was added to ease the lives of people who use switch to give one working tree for lots of branches
<james_w> maybe you should raise your use case and see if it could be incorporated
<james_w> I don't use switch, so I'm not the best to add
<awilkins> I think maybe it should try the sibling of the bound branch also
<james_w> s/add/ask
 * fullermd blinks.
<fullermd> That sounds like just the case he's asking for...
<james_w> it depends whether all of the branches are local or remote I guess
<awilkins> fullermd: I have the branch bound to a repo elsewhere, I want it to switch to repo/branches/bar not workfolder/bar
<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
<fullermd> Sounds more like another one of those irritating heavy-vs-light behavioral differences   :|
<awilkins> It is
<james_w> awilkins: perhaps the change could be made without breaking the case it was added for because of that
<awilkins> I believe light would behave as I expected it to
<awilkins> I think checking the sibling of the bound branch after the direct sibling of the branch would provide the feature I want
<fullermd> I think checking the sibling of the checkout at all is a bug; implementation leakage.
<awilkins> Well, I'd think the same but I'm being cautious :-)
<awilkins> I mean, I wouldn't keep a working tree huddled up in a folder fuill of branches myself
<fullermd> I gave my cautious a vacation this week   ;)
<awilkins> The repo is on a USB thumb or I'd go lightweight
<awilkins> I want the backup in case I lose it, and the ability to commit when it's not connected on occasion
<pickscrape> Does the bazaar test suite have any coverage reporting capability?
<awilkins> Intuitively, I'd say that might be difficult for Python..
<awilkins> But intuition is an idiot sometimes
<Jc2k> there is a module to allow it, but it will slow things down a lot
<james_w> pickscrape: I don't think so, but I may remember something about a hack or something to do it
<awilkins> "coverage.py"...
<awilkins> :-)
<Jc2k> http://martinpitt.wordpress.com/2008/04/08/python-code-coverage/
<james_w> yeah, but I seem to remember someone hooking coverage.py in to the test runner
<matid> Hi again! Did anyone recenly got bzr-svn to work on Mac OS X?
<pickscrape> Thanks for the pointers. :) I'm writing tests for diffstat, and wondered how I was doing
<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.
<awilkins> Any pointers on how to determine if a BzrDir is a heavy checkout?
<lifeless> if its got a bound branch
<awilkins> Would get_bound_location always return a value for a checkout?
<awilkins> (I mean even checkouts that are just the local checkout for a standalone branch)
<lifeless> no
<lifeless> lightweight checkouts have no local branch object
<james_w> hey lifeless, did you see the links I pasted?
<lifeless> note that you have have a lightweight checkout of a bound branch to a master branch
<lifeless> yes
<awilkins> Ok, that seems to fix it :-)
<lifeless> james_w: yes I did
<lifeless> bleh
 * awilkins posts a fix for annoying "switch" behaviour to list
<evanton> a bzr branch contains a html file that is generated from rst markup
<evanton> I modify the rst markup and regenerate the html file
<evanton> the problem is that the original version of this html file has windows-style newlines
<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)
<Peng_> unix2dos?
<evanton> this must be a typical issue, is there any documented workaround?
<james_w> evanton: there is a feature that will be in an upcoming version that may help you with this
<james_w> in the meantime unix2dos or similar may be your best bet
<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.
<evanton> wait
<Peng_> D'oh.
<evanton> aha
<evanton> so now my only option is to manually convert files?
<james_w> I'm afraid so
<james_w> though it may be possible to write yourself a hook to correct it when it happens
<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
<evanton> how do I know which files are binary so I could skip them?
<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.
<james_w> in your case I assume you know the names of the files that will be affected
<mathrick> can you have ghosts and still resolve them (ie. if they are present on the parent branch)?
<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)
<james_w> mathrick: what do you mean by resolve?
<mathrick> evanton: why not include that in your makefile rules?
<mathrick> james_w: get info / contents of when needed
<james_w> you would have to fetch the ghosts first
<evanton> it's a pity that the output of "bzr status" is the same for text and binary files
<mathrick> hmm, lemme write up what I have in mind
<james_w> unless you knew what were ghosts and could ask the other branch for the information
<evanton> does bzr do binary patching on modified binary files or just replaces them?
<james_w> or just catch RevisionNotPresent and try the other branch
<james_w> evanton: you mean in it's internal storage format?
<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
<evanton> james_w: yes
<mathrick> would that work if I wanted to merge it with a parent / another branch b2?
<james_w> evanton: yeah, it stores deltas at least some of the time
<evanton> ok, thanks
<james_w> mathrick: that's a stacked branch, if pn is a parent of b1
<awilkins> What's the recommended procedure for submitting "tweaks" to the list
<mathrick> james_w: oh, and what exactly does that mean?
<awilkins> Do you just say "ok then" and let the merging developer do it?
<Peng_> I think the current delta format is line-based, though..
<james_w> awilkins: the original submitter will do it
<awilkins> james_w: That be me then :-)
<james_w> awilkins: if it's a trivial tweak then the approver will normally not vote tweak and just do it
<Stavros> hello
<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.
<awilkins> FAir enough
<Stavros> i'm looking for a good bug tracker that hopefully supports bzr, does anyone know of one?
<Stavros> i don't want it to be open source, like launchpad, though
<james_w> you don't want it to be open source?
<james_w> and what do you mean by "supports" bzr?
<Stavros> i mean, i don't want it mandate my code being open source
<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?
<Stavros> and by "supports" i mean have integration with bzr
<awilkins> Trac has some integration
<Stavros> i'd like to use OSS if possible, but i would like it to support non-OSS projects
<Pilky> Stavros: if you're willing to do a bit of hacking then lighthouse would work
<Stavros> Pilky: what's it written in?
<Pilky> rails, it's a hosted solution
<awilkins> When is Launchpad being Opened anyway?
<Stavros> aha
<Stavros> thanks, i'll look into it
<Pilky> but you'd need to write a post commit hook to talk to their API
<Peng_> Redmine supports bzr, but I dunno how much VCSes are integrated with the bug tracker.
<mathrick> james_w: is there any RTFM around about stacked branches?
<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
<james_w> mathrick: there's a bit of documentation that I think made it to bzr.dev
<Peng_> Yes, it did.
 * mathrick updates
<Stavros> Pilky: it shouldn't be very hard, knowing bzr
<mathrick> is that a new feature?
<james_w> mathrick: it will be in 1.6
<mathrick> k
<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 ;)
<Stavros> Pilky: that's true, i meant for me :p
<Stavros> Pilky: http://www.poromenos.org/tutorials/python
<Pilky> yeah, I've not found a true python tutorial online yet
<Stavros> Pilky: how do you mean true?
<Pilky> well all the ones I've seen have been like that
<Stavros> Pilky: do you know any other languages?
<Pilky> basically listing the data types, control blocks etc
<Pilky> Objective-C, C, Java, PHP, Haskell, bit of VB6 (unfortunately)
<Pilky> I prefer learning while building something
<Stavros> hmm, you shouldn't need a very detailed tutorial then
<Stavros> but try "dive into python", it's pretty good
<Pilky> tried that, it's same as everything else
<Stavros> hmm
<Pilky> each chapter seems to be "here's a big chunk of code, now lets analyse it"
<Stavros> ah
<Pilky> I find I learn better if there are real tutorials, projects that you work through that show you why a language is cool
<LarstiQ> mathrick: if you have b1 ... bn but not p1 ... pn, you should still be able to merge.
<Stavros> Pilky: hmm, i don't know any like that, sadly
<mathrick> LarstiQ: cool
<Stavros> by the way, is redmine any good?
<LarstiQ> Stavros: a friend of mine uses it, haven't heard a complaint so far. But that is all I know.
<Stavros> ah, thanks
<mathrick> I wanted that for an idea of how to implement good rebase --interactive
<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
<Stavros> Pilky: i don't know any tutorials like that for any language, i don't think
<Pilky> they are far and few between unfortunately
<Pilky> I'm kinda spoiled by the book I used to learn Cocoa
<LarstiQ> Pilky: http://www.pythonchallenge.com/
<LarstiQ> Pilky: focus is a bit lopsides towards http and images, but it's fun anyway.
<Pilky> hmm, that's a bit closer to what I'm looking for, but doesn't explain about python as you do it
<Pilky> for example, the Cocoa book I used builds up your knowledge by making you write several apps
<LarstiQ> Pilky: you could try the TG wiki in 20 minutes or something like that.
<LarstiQ> Pilky: but of course, _my_ advice would be to contribute to bzr ;)
<luks> http://docs.python.org/tut is a good one, IMO
<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
<Pilky> LarstiQ: heh, well I'm wanting to extend a few bits with plugins, hence me wanting to learn python
<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.
<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.
<LarstiQ> Pilky: and for the rest, talking/review of more experienced users is what I'd suggest.
<LarstiQ> Pilky: oh, and reading existing code.
<Pilky> yeah, I'll have a look through when I have a few minutes spare
<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/"
<luks> the trick for bzr rm is easy, just rm it
<james_w> carljm: I think there may be a bug there, you may want to search the bug list
<luks> I'm sure there is a bug report about it
<carljm> ok, thanks
<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?
<james_w> hey BrianRice
<BrianRice> (I'm installing 1.5 over what may be 1.1)
<BrianRice> hi
<james_w> looking at the output of "bzr version" would be a good place to start
<james_w> that will show what the two bits it is using are
<BrianRice> yeah, I've looked. mind if I paste the results?
<james_w> should be ok
<BrianRice> (pastebot preferred of course)
<BrianRice> ok I'll keep it short...
<BrianRice> bzr: WARNING: bzrlib version doesn't match the bzr program.
<BrianRice> This may indicate an installation problem.
<BrianRice> bzrlib from ['/Library/Python/2.5/site-packages/bzrlib'] is version (1, 5, 0, 'final', 0)
<BrianRice> Bazaar (bzr) 1.5
<BrianRice>   Python interpreter: /System/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python 2.5.1
<BrianRice>   Python standard library: /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5
<BrianRice>   bzrlib: /Library/Python/2.5/site-packages/bzrlib
<BrianRice> I've rm -Rf'd the bzrlib directory mentioned there between installation cycles, but didn't get an improved result
<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.
<james_w> what does "which bzr" report?
<BrianRice> /usr/bin/bzr
<BrianRice> aha, /usr/local/bin/bzr is different
<BrianRice> and "version" on that does not complain, so that must be the result of the installer (I hope)
<james_w> yup, you're /usr/bin/bzr is probably your 1.1 one
<BrianRice> seems to work now, thanks! :)
<james_w> no problem
<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
<james_w> rocky: there's no easy way to do that as far as I know
<james_w> bzr log -rancestor:../branch-you-are-about-to-merge-in-to > ../commit_message
<james_w> do the merge, edit ../commit_message, and then commit with -F
<james_w> that could be one way to simulate it, but it's obviously not ideal
<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.
<pickscrape> rocky: that's the last thing you want. Trust me on that as a former svk user :)
<pickscrape> If your usage patterns are anything like ours you will end up with 50M+ commit messages.
<rocky> lol
<jelmer> rocky: bzr-svn 0.4.11 will support pushing the merged revisions as well, not just those on mainline
<jelmer> and it will set the appropriate svn:mergeinfo properties that svn 1.5 uses
<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
<ubottu> Launchpad bug 249256 in bzr "'property' object has no attribute 'initialize' " [High,Fix released]
<ahasenack> or was it...?
<james_w> hi ahasenack
<ahasenack> james_w: hi
<james_w> poolie will be the best person to ask, but it's not the right time for him
<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
<ahasenack> or just ping in that ticket
<ahasenack> it says released, but I don't see it in ppa, maybe upstream, let me check
<ahasenack> hmm, no, upstream is at 1.5
<james_w> bzr uses released to mean in bzr.dev
<ahasenack> and committed means what?
<james_w> in a branch somewhere
<ahasenack> ah, ok
<james_w> we discussed this a couple of weeks ago
<james_w> everyone agrees that it's not ideal, but doing the committed->release step on release would be a pain
<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
<ahasenack> james_w: you mean to switch all bugs into released state?
<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
<ahasenack> all bugs in committed state, I mean
<ahasenack> yeah, I feel that pain too. It's in my whishlist for lp to allow changing several bugs at once
<james_w> that could possibly work as well
<ahasenack> I regularly have to switch around 25 bugs from committed to released
<ahasenack> maybe with the new api stuff
<james_w> can you track a bug in multiple releases in a project, like you can in a distro package?
<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
<james_w> launchpad should still think about solving this somehow though.
<plexq> hello - anyone know how I can change my submit branch?
<matkor> bzr <sth>  --remember  ?
<plexq> what is <sth>?
<matkor> what sets submit branch ?
<matkor> bzr push ? merge ?
<beuno> send
<colbrac> jelmer: Shame the info dialog reworking was not merged.. missed that :(
<LarstiQ> colbrac: point release! point release! ;)
<colbrac> lol
<colbrac> That would depend on the powers of Russel Winder, he complained about the (now shipped) version
<mwhudson> beuno: good morning
<beuno> mwhudson, mornin'
<mwhudson> beuno: i just merged themed-directory-listing
<beuno> mwhudson, yay!  thanks
<Peng_> Ooh.
<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?
<mwhudson> beuno: so thumper did https://code.edge.launchpad.net/~thumper/loggerhead/branch_locations
<thumper> mwhudson: that only just got pushed
<thumper> mwhudson: are you getting notifications?
<mwhudson> thumper: no, i was just looking for it
<mwhudson> thumper: mind if i make it public?
<thumper> mwhudson: it is now public
<mwhudson> ok
<mwhudson> we could probably change the privacy policy now
<beuno> mwhudson, I'd also like for you to take a look at: https://bugs.edge.launchpad.net/loggerhead/+bug/254411
<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?
<beuno> it comes with patches, and I'm not really that saavy on how that part of LH works
<mwhudson> Peng: 1) cool, 2) well there wasn't before, one thing at a time :), 3) good idea
<mwhudson> beuno: i wonder if he'd be happier with serve-branches
<beuno> mwhudson, he might, but it's still a valid bug with a patch, isn't it?
<Peng_> Hmm, I could probably figure out how to do #3 myself.
<mwhudson> beuno: let's see how he responds to my comment, i'd really rather let config.py rot and die :)
<mwhudson> beuno: impressive that he figured out how to hack the code to do what he wanted though :)
<Peng_> Oh, also, sorting?
 * Peng_ runs away.
<Peng_> (I just noticed that /files does sorting.)
<beuno> mwhudson, it really is. Shows a lot of will to help  :)
 * beuno knew we should of removed sorting, that only puts the bar higher for the rest of the UI
<mwhudson> Peng_: can you guess what patches are?  starts with 'w', ends in 'elcome'
 * beuno takes a look at thumper's merge request
<mwhudson> Peng_: the hard thing about '..' links is knowing when not to show them
<beuno> thumper, where does branch_link come from?
<mwhudson> beuno: sekrit launchpad glue
<mwhudson> beuno: but!
<thumper> beuno: it comes from whatever creates the BranchWSGIApp
 * beuno waits for a good explanation for that to land in trunk
<thumper> beuno: which on the default server_branches is non existant
<SteveA> hi
<SteveA> does anyone run the bzr test suite on mac os x ?
<mwhudson> beuno: i think that the filesystem server should use links back to the directory listing when it can
<mwhudson> beuno: maybe
<mwhudson> i haven't really thought about this too hard
<beuno> mwhudson, it should. We just have to make sure we're not on the top level
<mwhudson> SteveA: i think vila, igc and jam sometimes use os x
<beuno> Verterok does too
<mwhudson> beuno: well, maybe not the branch name, thinking about it
<mwhudson> beuno: but something :)
<SteveA> mwhudson: __lucio__ just started working with me.  he ran the bzr tests on mac on x, and is seeing some failures.
<mwhudson> SteveA: i guess that's not massively surprising
<SteveA> really?
<SteveA> I find a broken trunk massively surprising.
<Verterok> Hi beuno
<__lucio__> http://pastebin.com/m39e37fff
<SteveA> how can we expect contributions from someone working on mac os x if the trunk is broken?
<beuno> hi Verterok. Maybe you can help?  ^
<mwhudson> SteveA: how can we be sure that trunk isn't broken without automatic checks?
<mwhudson> __lucio__: that looks a bit special though
<beuno> thumper, can I see your patch in action somewhere?
<__lucio__> mwhudson: special how?
<mwhudson> __lucio__: as in 'really broken'
<thumper> beuno: can you see the canonical pastebin?
<beuno> thumper, I never know, but I don't think so.
<thumper> beuno: can you give me a pastebin link?
<beuno> !pastebin
<beuno> damn
<__lucio__> mwhudson: it did manage to run 204 tests without problems
<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)
<beuno> thumper, http://paste.ubuntu.com/
<mwhudson> __lucio__: that error stopped the test suite?
<__lucio__> mwhudson: yes
<mwhudson> __lucio__: there are ~12000 tests in the test suite these days
<mwhudson> __lucio__: file a but
<mwhudson> bug
<__lucio__> ok.
<lifeless> SteveA: a broken trunk on a platform no developer is actively using is not surprising - its not desirable, but its not surprising
<thumper> beuno: http://paste.ubuntu.com/34199/
<SteveA> lifeless: might be the reason no developers are actively using it
<thumper> :)
<beuno> thumper, ah, can I run this against launchpad.dev?  because I do have that
<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"
<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
<mwhudson> bzr basically works on os x
<Verterok> SteveA, lifeless: I'm using os x :)
<thumper> beuno: it required an annoying amount of hacking to get `make run_all` to start loggerhead again
<SteveA> Verterok: yay!
<lifeless> Verterok: are you - cool
<thumper> beuno: it used to work, but for some reason I hit problems
<thumper> beuno: but I did get it working on launchpad.dev
<lifeless> SteveA: anyhow, if you can contribute a macos X developer that will run all tests with high frequency that would be great :)
<lifeless> oh, and hi __lucio__
<mwhudson> i have a machine that's mostly idle
<SteveA> lifeless: I'll see what I can do
<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
<lifeless> mwhudson: its the developer attention on the results that matters most
<SteveA> mwhudson: ftw
<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.)
<mwhudson> lifeless: yeah
<Peng_> I just stole code from, uh, inventory.pt, but like I said, it seems to work.
<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!
<Peng_> beuno: Oh? What'd I do wrong?
<thumper> beuno: can you think of a use for it in LH itself?
<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
<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
<Peng_> beuno: What parent link? I only changed that one link, nothing else.
<lifeless> Verterok: if you want to find and fix bugs a couple times a week that would rock
<lifeless> Verterok: note that this isn't the same thing :)
<Verterok> lifeless: heh, I can try :)
<beuno> thumper, I'm thinking...
<Verterok> about fixing them ;)
<awilkins> Running the tests on windows leaves a huge amount of temp dirs hanging around
<beuno> Peng_, http://bzr.mattnordhoff.com/bzr/
<Peng_> beuno: That's not Loggerhead. http://bzr.mattnordhoff.com/loggerhead/ is Loggerhead.
<Peng_> I don't think I'm smart enough to add parent links. :)
<Peng_> At least, quickly..
<awilkins> Can you hook garbage collection of an object in Python?
<Peng_> Hmm, when you're at the top level, I think the <title> of the page reveals the real name of the directory.
<beuno> Peng_, ah, right, that isn't even the same theme.  I should pay more attention  :p
<Verterok> awilkins: hook into gc? __del__ method maybe?
<beuno> thumper, maybe we can just add that with some explanation on how to feed LH that info?
<Verterok> __lucio__: hi :)
<__lucio__> hi Verterok , hi all :)
<awilkins> Verterok: I was wondering if hooking that in the bit of the test case object that removes folders would be better.
<beuno> __lucio__, hi!  you're working in Canonical now?
<__lucio__> beuno: yep. just started.
<beuno> __lucio__, welcome  :)
<__lucio__> danke :)
<Verterok> __lucio__: wow!
<Verterok> awilkins: I don't known the tests magic enough :(
<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
<beuno> pickscrape, yeap, that's been filed as a bug
<pickscrape> beuno: excellent, I'll let him know :)
<lifeless> SteveA: __lucio__: python bug
<lifeless> tarfile.open(None, "w|gz", sys.stdout) -> boom, on your machine afaict
<pickscrape> Hmm, does anything recently committed to loggerhead require bzr 1.6?
<lifeless> pickscrape: I believe so
<beuno> pickscrape, yes, viewing changes to a file
<pickscrape> Ah
<beuno> that should be fixed this week
<pickscrape> Actually it's the directory view that's breaking for me right now
<pickscrape> ReservedId: Reserved revision-id {null:}
<beuno> pickscrape, oh, that's new
<beuno> pickscrape, can you pastebin the traceback?
<pickscrape> It's only when viewing the root...
<pickscrape> !paste
<ubottu> pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic)
<pickscrape> beuno: http://paste.ubuntu.com/34205/
<pickscrape> As I say, it only happens in the root directory. subdirectories of it (that are also just directories) aren't affected.
<beuno> pickscrape, what version of bzr are you running?
<pickscrape> 1.5
<pickscrape> I've been tempted to put 1.6 on the server for a while now, but it's a pretty critical system :)
<beuno> pickscrape, can you file that as a bug?
<pickscrape> Certainly.
<beuno> pickscrape, thanks  :)
<lifeless> james_w: 3117 follow up posted
<james_w> did you see my followup question?
<lifeless> ah just arrived
<lifeless> no its not an api break
<lifeless> if it was a required parameter it would be an api break
<lifeless> this isn't C++ we don't have linkage determined by function signature :)
<Verterok> lifeless, __lucio__: about Bug #254791, it's fixed in Python 2.5.2 :)
<ubottu> Launchpad bug 254791 in bzr "export to tar broken on mac os x" [Undecided,New] https://launchpad.net/bugs/254791
<pickscrape> beuno: bug 254794
<ubottu> Launchpad bug 254794 in loggerhead "root directory view traceback" [Undecided,New] https://launchpad.net/bugs/254794
<__lucio__> Verterok: what was it?
<pickscrape> Looking at it now that doesn't seem like such a good bug title :)
<beuno> pickscrape, rockin', thanks
<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.
<Verterok> __lucio__: as lifeless commented, a python bug
 * Peng_ waves. Comments on my trivial patch? Want me to send it to the list?
<beuno> Peng_, URL again?  I'll look n' merge
<Peng_> beuno: Branch is at http://bzr.mattnordhoff.com/bzr/loggerhead/dirlisting-revno-link
<Peng_> You can see it in LH at http://bzr.mattnordhoff.com/loggerhead/loggerhead/dirlisting-revno-link/revision/192 :)
<lifeless> james_w: what do you mean then :)
<beuno> Peng_, cool, thanks, I'll merge
<Peng_> beuno: Thanks. :)
<pickscrape> beuno: upgrading to bzr 1.6 doesn't fix it
<james_w> lifeless: I mean forcing plugins to make a change at the same time as the core.
<beuno> pickscrape, ah, then we have a different problem.  Is the branch you are running the problem in public?
<pickscrape> I'm afraid not
<pickscrape> It isn't a branch either: the root is just a directory
<lifeless> james_w: ok, I see. Yes, plugins that implement MutableTree.commit() need to change
<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
<thumper> Peng_: I like the icons on the listing
<Peng_> thumper: It's the new theme in the trunk. :)
<james_w> lifeless: I have no idea if anything does, bzr-svn may I guess.
<lifeless> few plugins add implementations of commit though - I only know of git/svn/hg
<lifeless> and then, its only for 'bzr commit' while sitting in a native svn etc tree
<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
<lifeless> note that adding a new method would also still force the plugin to change: the UI code would be calling the new method
<james_w> there's prior art for adding a "hasattr" I believe
<lifeless> james_w: yes, but not in this case:
<james_w> in the log code I think
<lifeless> a) it was fugly inlog
<lifeless> b) MutableTree would have commit_2(), so all subclasses of it would as well
<lifeless> so it would always be tree
<james_w> true
<lifeless> also
<lifeless> nvm
<james_w> that's fine, you just might want to give a certain ninja plugin developer a heads up.
<beuno> pickscrape, and that is LH trunk?  on what revno?
<lifeless> jelmer: tree.commit has a new parameter, kthxcode
<james_w> done :-)
<lifeless> actually, I'll document this
<pickscrape> beuno: 191. Did I not put that in the bug report?
<beuno> pickscrape, you did, sorry.  This is a shared repo it's running on?
<pickscrape> Not at the root level
<pickscrape> The root is a plain directory that contains a number of shared repositories
<pickscrape> In each of these are both branches and other plain direcotries
<beuno> ok, I see now, it's my fault.  I'm not filtering NULL revisions
<jelmer> lifeless, thanks for letting me know :-) Already in bzr.dev ?
<jelmer> lifeless, Good thing I hadn't put 0.4.11 out yet...
<lifeless> jelmer: may not hit 1.6; about to go to bzr.dev if james is giving me +1
<beuno> does this look familiar to anyone?  http://paste.ubuntu.com/34208/
<beuno> I just updated bzr.dev
<beuno> (to work around bug #249256)
<ubottu> Launchpad bug 249256 in bzr "'property' object has no attribute 'initialize' " [High,Fix released] https://launchpad.net/bugs/249256
<lifeless> james_w: so - +1?
<spiv> beuno: it doesn't look familiar to me...
<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
<beuno> spiv, so file a bug?
<james_w> lifeless: everything looked pretty sounds first time around though
<spiv> beuno: yeah, I think so
<beuno> Peng_, is your server doing aything special I should be aware of?
<Peng_> beuno: bzr+http is on.
<lifeless> spiv: can I ask for an insta review? james_w has reviewed my 3117 branch - latest mail should have just hit the list
<Peng_> beuno: Also, it's Lighttpd, not Apache.
<lifeless> spiv: but it needs someone with voting to say he was right :P
<spiv> lifeless: Ok
<beuno> Peng_, bzr version you're running?
<Peng_> beuno: Uhh, hold on.
<Peng_> beuno: bzr.dev.
<beuno> Peng_, renvo?  (sorry to be such a pain)
<mwhudson> is something like 'merge' for looms implemented yet?
<Peng_> beuno: Latest.
<lifeless> mwhudson: TODO
 * jml sads
<Peng_> beuno: 3602
<mwhudson> lifeless: as i suspected
<beuno> Peng_, cool, you are now part of bug #254797 then  :)
<ubottu> Launchpad bug 254797 in bzr "traceback when branching from bzr+http" [Undecided,New] https://launchpad.net/bugs/254797
<beuno> Peng_, meanwhile, can you send me a bundle for you're patch?
<Peng_> I should just turn off bzr+http. Launchpad hates it, and now plain bzr does too?
<beuno> Peng_, please don't, or it will never get fixed  :)
<Peng_> beuno: http://bzr.mattnordhoff.com/bzr/loggerhead/dirlisting-revno-link/dirlisting-revno-link.patch
<Peng_> So, this time, I didn't manage to break Loggerhead, just bzr? :)
<beuno> Peng_, yes, we're finally starting to win!
<Peng_> Heh.
<beuno> lifeless, I'm hitting this again:  http://paste.ubuntu.com/34209/
<beuno> we already danced around this for this same branch a few months ago, but I don't remember what came out of it
<lifeless> beuno: ah yes we haven't tracked that down yet
<beuno> lifeless, want to give it another shot, or should I just push --overwrite?
#bzr 2008-08-05
<beuno> Peng_, you broke bzr/lp indirectly, ^ is your commit  :p
<jam> lifeless: I just reviewed the "Review Feedback" post
<chevdor> hello, from what I am reading, nautilus-bzr should be installer w/ bzr-gtk... this is not obvious if I look at my menu items :) is there a doc somewhere about nautilus-bzr ?
<chevdor> s/installer/installed
<beuno> chevdor, you should see icons overlayed when you browse a versioned directory with nautilus
<chevdor> beuno, ... but I don't :)
<beuno> chevdor, what version of bzr-gtk have you installed?
<chevdor> beuno, this is why I am asking, I'd like to know what/where to search for a problem
<chevdor> beuno, gtk 0.93.0
<lifeless> beuno: just push, no need for --overwrite
<beuno> chevdor, ah, it's disabled in 0.93. I'd recommend installing 0.95, which was released today
<lifeless> thanks jam
<chevdor> beuno, ahhh ok that explains :) I'll go to bed then and get the trunk tomorrow, thanks for your help, i can't wait to see that :)
<beuno> chevdor, np. G'night
<lifeless> jam: but you didn't do bb:approve :P
<chevdor> beuno, thx, ++
<jam> lifeless: I think I did
<lifeless> http://rafb.net/p/uRBIHU22.html
<beuno> Peng_, revision 192 of loggerhead thanks you for your contribution
<beuno> mornin' poolie
<poolie> hello beuno, lifeless
<james_w> lifeless: there's a review with vote as well
<james_w> hey poolie
<lifeless> ah
<lifeless> its not in my inbox :(
<lifeless> found it
<lifeless> thanks james_w
<lifeless> and jam
<lifeless> spiv: bug 254797
<ubottu> Launchpad bug 254797 in bzr "traceback when branching from bzr+http" [Undecided,New] https://launchpad.net/bugs/254797
<lifeless> spiv: I'm thinking a whole in the interface tests or something ?
<Peng_> Now https://code.launchpad.net/~loggerhead-team/loggerhead/trunk gives the "Pack already exists" error.
<beuno> Peng_, try again, I got the same when committing
<beuno> it's something wrong with auto-packing
<beuno> oh, wait, branch is b0rked in LP
 * beuno pokes lifeless
<Peng_> :)
<beuno> hrm, my commit didn't go through, even though bzr said it did
<Peng_> Finally, I'm not the only one with a broken branc. :)
<beuno> LOL
 * beuno wonders if bzr pack lp:loggerhead fixes it
<beuno> Peng_, what happens if you pull from lp:loggerhead?  do you get revno 192?
<beuno> ok, bzr pack fixed it
<Peng_> ...Yeah, I just did it, and it worked.
<Peng_> Before then, it just said no new changes.
<beuno> Peng_, cool, everything should be back to normal then
<Peng_> :)
<spiv> lifeless: nearly done with the review; I found a test bug
<spiv> lifeless: and I agree, that bzr+http bug does suggest we have a hole in our tests
<lifeless> spiv: the iter_changes ordering assumption?
<lifeless> spiv: cause I think thats actually not a bug :P; we do directory-at-a-time for performance everywhere
<spiv> lifeless: the 'bzr added' output ordering assumption
<spiv> lifeless: and it is a bug, because I get an intermittent test failure
<spiv> :)
<lifeless> oh, ok
<lifeless> thanks!
<james_w> has the mailing list just started sending copies of messages if you are also getting them directly?
<poolie_> james_w, i have not changed it to do that
<james_w> was there perhaps an upgrade?
<james_w> maybe it's something else
<elmo> there wasn't a mailman upgrade
<elmo> it's a per list &| user setting though
<james_w> I'll see if it continues, or it was something else
<meteoroid> if i remove a branch / checkout from a shared repo, can i remove that branch's info from the repo store?
<meteoroid> hm, i am probably using shared repo incorrectly, perhaps i should have one for each distinct remote repo, or project, just to share its' branches, so i wont have to worry about this..
<beuno> meteoroid, when you remove a branch from a shared repo, it's revisions are still there. The only workaround I know if is creating a new shared repo, and branching everything you want to keep into the new one, discard the old one
<meteoroid> beuno: that's what i figured..
<meteoroid> so, e.g. for svn, i should probably share one repo for each svn repo root.
<beuno> meteoroid, yes, I use a different shared repo for each project, which will msot likely share it's history
<meteoroid> makes sense..
<lifeless> === modified file 'bzrlib/tests/test_options.py'
<lifeless> --- bzrlib/tests/test_options.py        2007-09-03 01:50:29 +0000
<lifeless> +++ bzrlib/tests/test_options.py        2008-08-05 00:29:05 +0000
<lifeless> @@ -81,8 +81,7 @@
<lifeless>  
<lifeless>      def test_allow_dash(self):
<lifeless>          """Test that we can pass a plain '-' as an argument."""
<lifeless> -        self.assertEqual(
<lifeless> -            (['-'], {'fixes': []}), parse_args(cmd_commit(), ['-']))
<lifeless> +        self.assertEqual((['-']), parse_args(cmd_commit(), ['-'])[0])
<lifeless>  
<lifeless> spiv: ^
<lifeless> I think the test was overly sensitive; it fails on my 3117 merge
<lifeless> spiv: what do you think ?
<spiv> lifeless: looking...
<lifeless> I nearly JFDIid it
<spiv> lifeless: I agree
<lifeless> there are more in that file
<lifeless> cmd_commit :(
<lifeless> I'll put a XXX there
<spiv> Really test_options shouldn't be relying on cmd_* classes in builtins.
<lifeless> thats what my XXX says :)
<lifeless>         # XXX: Using cmd_commit makes these tests overly sensitive to changes
<lifeless>         # to cmd_commit, when they are meant to be about option parsing in
<lifeless>         # general.
<spiv> Hmm, it imports cmd_log and cmd_status, but doesn't use them.
<lifeless> fixed
<lifeless> sending again
<spiv> pyflakes reports that 'builtins', 'repository', 'symbol_versioning' and 'Command' are also unused, if you want to clean it up more...
<lifeless> done
<lifeless> thanks
<lifeless> jam: ping
<poolie> james_w, i would guess that you used a different sender address from the subscribed address
<james_w> poolie: aha! thanks, that explains it.
<poolie> all: what do you think of sending the standup notes to the bazaar list?
<poolie> would it be too much noise?
<james_w> I think Rob's mailer might have switched addresses for me when replying
<poolie> i guess it's just one more message out of a couple of dozen per day
<lifeless> poolie: I think some of them are relevant, some not.
<lifeless> I'd suggest blogging or twittering for that sort of unfocused stuff though
<poolie> or getting people to send mail individually about what they're doing
<lifeless> which we do:)
<lifeless> I guess what I really mean is
<lifeless> if you feel that theres a canonical internal-knowledge-thing happening; perhaps stop doing daily status reports for the team internally; forcing that communication back onto the regular channels ?
<jelmer> lifeless, any news about bzr-gtk pqm?
<lifeless> no, thanks for reminidng me
<awmcclain> Ug. 1.6r3 requires a version of python central that doesn't exist on gutsy? Boo!
<awmcclain> b3, rather
<poolie> awmcclain, really? i wonder why?
<poolie> from the ppa i assume you mean?
<awmcclain> Maybe I'm doing something wrong.
<poolie> oh i see
<awmcclain> he following packages have unmet dependencies:
<awmcclain>   bzr: Depends: python-central (>= 0.6.7) but 0.5.15ubuntu2 is to be installed
<awmcclain> Correct.
<poolie> i thought it would rebuild on gutsy but obviously not, would you please file a bug
<awmcclain> sure thing
<lifeless> poolie: will changes to .dev land in 1.6 final at this point ?
<poolie> yes
<lifeless> thanks
<poolie> after i deal with your review to the upgrade test i'd like to make rc1
<poolie> i'll ask you to do pqm fu then
<poolie> my desktop's video card is dying which is annoying
<lifeless> my windtendos sound card is sucking
<awmcclain> poolie: I reopened the feisty bug which is the same.
<awmcclain> grumble grumble
<beuno> poolie, the copy package thing bit me last time too  :/
<lifeless> what are you guys doing?
<beuno> I believe that someone pointed out that you should upload the oldest version (dapper probably), and copy dapper -> gutsy, dapper -> hardy, etc
<beuno> lifeless, I *think* it's because we copied from hardy -> gutsy, etc, instead of starting from the bottom
<beuno> or at least that's what cprov recommended if IIRC
<lifeless> erm
<lifeless> I didn't think you should *ever* copy between releases
<beuno> uhm, then what's the copy feature for?
<lifeless> ubuntu never copies, the whole archive is rebuilt from release to release
<james_w> not entirely true
<james_w> they do copy sometimes
<lifeless> I don't know what the copy feature is for; but I can assert that packages from one release to another have no guarantee of working -
<lifeless> ABI changes, support tool changes etc
<lifeless> james_w: slangasek asserted to me that there is a full rebuild in the cycle for every release at this point in time
<lifeless> james_w: when I was last in London
<lifeless> copying between suites is differnet
<james_w> don't PPAs support copying source (might work) or source+binary (will only work in very specific circumstances)
<james_w> I've see hardy-proposed->intrepid
<poolie> beuno, oh i see
<poolie> about coping from oldest to newest
<poolie> they support copying either source or binaries
<lifeless> I urge you to only copy source
<beuno> poolie, that way it will depend on an older version instead of a newer
<poolie> only one option works for this
<poolie> beuno, yes, i see
<poolie> what i mean is, the web ui gives an error if you choose one of the options, so only the other can be chosen
<lifeless> but myself I wouldn't copy at all, I'd use e.g. autoppa and upload each release independently
<poolie> moving to autoppa is probably better
<beuno> what's autoppa?
<jelmer> autoppa really isn't ready yet imo
<jelmer> and not just on sid
<lifeless> jelmer: maybe so, though there are folk using it heavily
<jelmer> lifeless, it does stuff like invoke "bzr revert" on each individual file in the source branch without asking
<lifeless> jelmer: I didn't claim perfection; I claimed that there are folk using it a lot
<jelmer> lifeless: (and I really mean use os.system("bzr revert <filename>") for each file)
<poolie> whoa
<lifeless> lol jkakar needs a cluebat then
<poolie> jelmer, so what do you think we should do instead? manually update all the packages?
<poolie> or write a custom script to do it?
<lifeless> well
<lifeless> I'd file more bugs on autoppa
<jelmer> Fix autoppa, ideally
<jelmer> I think the idea behind autoppa is nice and jkakar doesn't seem to be opposed to improving it :-)
<awmcclain> Autoppa? Is that some holy grail that automatically builds packages for a variety of releases?
<jelmer> awmcclain: yes, that's the idea
<awmcclain> Ooooo...
<jelmer> it can build *source* packages for various releases and uploads them to ppa
<awmcclain> Oh, source is all I want. Is it released?
<jelmer> yeah, http://launchpad.net/autoppa
<awmcclain> Is autoppa compatible with pdebuild or just debuild?
<jelmer> it just invokes debuild atm I think
<awmcclain> mmm. it's written in python?
<awmcclain> Looks like. I could hack that. Wow. I wish I would have known about this when I created 9 packages in my PPA.
<awmcclain> x2 releases.
<awmcclain> Is 1.6 a lot faster than 1.2 or 1.4?
<awmcclain> (subject change)
<awmcclain> a lot = noticably
<awmcclain> *noticeably
<jkakar> I am interested in improving AutoPPA, a lot of it is hackish.
<jkakar> I already have a branch in progress to use bzrlib directly, but I'm stuck on a couple of issues.
<james_w> jkakar: if we can help give us a shout
<jkakar> I haven't managed to get to it, but I have been planning to spend time on it recently.
<jkakar> james_w: Thanks.
<jelmer> I'd be happy to help as well
<jkakar> When I do get to it I'll ask for help; in the meantime, I appreciate bug reports. :)
<jelmer> I already filed a bunch, as you may have noticed :-)
<jkakar> jelmer: Yes, thanks. :)  I still need to review and merge you branches, which I will do soon.
 * Verterok ibook took 6998.977s to ran 13715 tests
<beuno> Verterok, did they all pass?
<Verterok> with: failures=14, errors=13, known_failure_count=17
<Verterok> beuno: ^
<Verterok> and 797 skipped
<beuno> Verterok, time to file bugs!
<Verterok> indeed
<Verterok> but I don't known what test failed :P
<Verterok> beuno: my term history have some arbritary limit :P
 * Verterok now running all the test suite wiht stdout & stderr redirected to files :) 
<beuno> Verterok, I'm guessing none of it gets logged in .bzr.log?
<Verterok> beuno: yeap
<lifeless> also, yay firefox OOM killed
<mtaylor> hey all
<mtaylor>  No such file or directory: u'/home/mtaylor/src/drizzle/.bzr/repository/indices/366c128ec96628e2e71bf57ee4d56c1d.six'
<mtaylor> I got that ^^ while _pushing_
<mtaylor> that would be the source repository, not the dest repository, it's mentioning
<poolie> mtaylor, did you get a traceback in ~/.bzr.log
<poolie> could you please file a bug with the details
<poolie> i think you can retry the push and it will be ok
<mtaylor> poolie: yes... worked on retry
<poolie> i think this is a dupe of something we're going to fix
<poolie> ok
<mtaylor> poolie: you want me to file the bug anyway?
<poolie> um let me find the number and i'll get you to attach it to that one...
<mtaylor> ok
<poolie> bug 153786
<lifeless> mtaylor: were you committing to the source from another process? (or pulling into it?)
<mtaylor> lifeless: no
<mtaylor> lifeless: I had aborted a previous push shortly before
<lifeless> mtaylor: ok, thats interesting then
<lifeless> mtaylor: you grep for 366c128ec96628e2e71bf57ee4d56c1d in /home/mtaylor/src/drizzle/.bzr/repository/pack-names
<mtaylor> lifeless: and after the later successful push was finished, I got an "Read from remote host bazaar.launchpad.net: Connection timed out"
<lifeless> and if its present check for 366c128ec96628e2e71bf57ee4d56c1d.pack in .../packs, and 366c128ec96628e2e71bf57ee4d56c1d.{t,s,r,i}ix in .../indices
<mtaylor> nope. not in pack-names
<lifeless> if 366c128ec96628e2e71bf57ee4d56c1d is not present in the pack-names index then I think its as poolie says, a dupe of a known race condition that is safe (but annoying)
<mtaylor> ok
<lifeless> how is drizzle going?
<poolie> lifeless, about that upgrade test from the other day
<poolie> after sleeping on it, i don't think it does belong in the per-stacking-repository-format tests
<poolie> because there is no straightforward place for that format to be inserted
<poolie> i'm making the stacking repository using basis_bzdir.sprout(... stacked=True)
<poolie> and that lets the other format choos
<poolie> choose*
<lifeless> poolie: hmm, let me do a micro-teset
<poolie> of course we could have a test that makes a new repo of the relevant format and then sets up a fallback, then upgrades the fallback, etc
<poolie> that would be useful, but not quite the same test
<lifeless> poolie: http://infovore.org/archives/2008/02/06/demonstrating-snap/
<lifeless> spiv: yo
<spiv> lifeless: yo
<lifeless> spiv: I'm confused
<lifeless> poolie: btw, load_tests in a sub-area works Just Fine
<spiv> So, it boils down to statements of intent.
<lifeless> poolie: http://rafb.net/p/J3j6NT50.html
<lifeless> poolie: demonstrating adding two scenarios to a module which is further parameterised
<lifeless> spiv: they are the same statement though!
<lifeless> include foo, exclude foo/bar
<lifeless> exclude wins if foo/bar is excluded
<spiv> test_commit_exclude_subtree_of_selected's name says "this is a test for what happens when you exclude a subtree that is also selected."
<lifeless> yes, exactly!
<spiv> Which is different statement to "this is a test for the excludes argument overrides the specific files"
<spiv> Closely related, but not the same.
<lifeless> *blink*
<lifeless> no its not
<lifeless> selected files are specific files
<spiv> Actually, looking at test_commit_exclude_subtree_of_selected I don't even see it passing any specific files.
<spiv> Yes, I know they are synonyms, my point isn't about that.
<lifeless> the default specified path is '/'
<lifeless> but I can add 'a' to the call
<lifeless> anyhow, I still don't understand
<spiv> So, I think a test that does commit('msg', exclude=['foo'], specific_files=['foo']) and is named "test_exclude_overrides_specific_files" declares a different intent than the existing test_commit_exclude_subtree_of_selected, both in name and in implementation.
<spiv> (even ignoring the "selected" vs. "specific")
<lifeless> errr
<lifeless> I disagree
<lifeless> updated comment (thanks) and added specific files to the call:
<lifeless> http://rafb.net/p/k6twXM76.html
<spiv> I see the subtree test as exploring what happens when "a" is selected but "a/b" is excluded, which I think has different intent.
<lifeless> (note that your comment suffers a greater chance of bitrot on refactoring, and is not strictly correct, but if it makes more sense to you I'm happy)
<spiv> That's what happens when the two arguments partially overlap/conflict.
<lifeless> spiv: re intent; I wrote both sets of prose, they have the same *intent*. I think thats why I'm finding your description difficult, you are asserting things that are not true; you can assert that the intent you think it has is different
<spiv> lifeless: (yeah, there's a tradeoff between extreme precise and either too vague or too verbose)
<lifeless> hmm, the more I think about the comment change the less I like it
<spiv> Well, to my mind they are separate claims.
<spiv> I can see how you can consider one to be a strict superset of the other.
<lifeless> the problem is that _update_builder_with_changes *may* record an unmodified version of excluded paths
<lifeless> or it might record a merge
<lifeless> or it might not record it at all if its new
<lifeless> spiv: select foo, exclude foo is a specific corner case in the space of 'excludes override selects'.
<spiv> "... if appropriate"?  "... will $better_verb ..."?
<lifeless> spiv: select foo, exclude foo/bar is another corner case
<lifeless> I think it would be easy to have (foo, foo) pass and (foo, foo/bar) fail, but very difficult to have the reverse.
<lifeless> so I wrote a test for the reverse
<spiv> Right, I absolutely think you need the latter test.
<lifeless> I don't think the prose about excludes is coupled to the (foo, foo) case with anywhere near the glue you seem to think it is
<lifeless> it doesn't say 'an exclude of the same path as a selected path will win'
<spiv> I just think the simpler case might be worth having as it is both as a way to gradually build up the reader's understanding of behaviour and as it directly correlates to how it is explained in the documentation.
<lifeless> it says that excludes take precedence which covers the full range of cases and is not bound to any specific test. In fact the *example given* in the command help is the one I test
<lifeless> spiv: !?
<lifeless>     When excludes are given, they take precedence over selected files.
<lifeless>     For example, too commit only changes within foo, but not changes within
<spiv> As a secondary thing, it wasn't immediately obvious to me as a casual reader that the subtree case was sufficient to cover the simpler case, and I didn't find it when looking for the simpler case.
<lifeless>     foo/bar::
<lifeless>                                                                                                           
<lifeless>       bzr commit foo -x foo/bar
<spiv> So, I really was expressing a very very mild preference :)
<lifeless> I fail to understand how (foo, foo) correlates better to the docs!
<spiv> I'm not meaning to argue to strongly that it should change, just explain my "huh, this didn't quite match my expectations" reaction when looking at the patch, and a possible thing to do about it.
<lifeless> [I'm feeling a little frustrated here; I realise you want to make the code better, but your points don't seem to fit the actual code or docs well, and thats making it hard for me]
<spiv> Part of it was some confusion on my part: it wasn't immediately obvious to me that the subtree case a) covered the simpler case, and b) necessarily covers the simpler case because of the nature of the problem.
<lifeless> I'd rather this as a comment I think:
<lifeless>                 # Skip excluded paths. Excluded paths are processed by
<lifeless>                 # _update_builder_with_changes.
<spiv> Which might still be an argument for having the simpler case as well, but a fairly weak one.
<lifeless> spiv: I'd like to know what docs refer to this simpler case though
<spiv> lifeless: just that first line I quoted.
<lifeless> you say 'as it directly correlates to how it is explained in the
<lifeless>               documentation.
<lifeless> '
<spiv> lifeless: so, the docs and test are fine.
<lifeless> spiv: yet that same paragraph (within REST limitations) describes foo and foo/bar ? Should we expect developers to read less-than-that-paragraph?
<lifeless> spiv: what do you think of my updated comment?
<spiv> lifeless: I like that new comment.  Thanks!
<lifeless> ok, so I merged the previous patch ( it was 'tweak') - here is a post-merge update for it: http://rafb.net/p/Jc6oP514.html
<lifeless> pls approve :)
<spiv> irc:approve ;)
<spiv> (maybe one day bb will watch the IRC channel...)
<beuno> thumper, did you ever get around to making the gnome-theme branch available?
<thumper> beuno: I fixed my problems if that is what is asking
<thumper> beuno: it is public I believe
<thumper> beuno: but not yet on the playground
<beuno> thumper, you where having problems merging in the new theme
<thumper> beuno: firebug to the rescue
<beuno> thumper, cool, so gnome is running the new theme?
<thumper> beuno: not yet, [16:11] <thumper> beuno: but not yet on the playground
<thumper> beuno: but it could be soon
<thumper> beuno: I'm fixing the revision feed for LP
<beuno> thumper, ah, right. Ok, cool, let me know if you need any help with that
<lifeless> spiv: thanks, bombs away
<beuno> thumper, cool, that will be useful now that codebrowse is up most of the time  :p
<beuno> thumper, I'll also get to your merge request in a minute. I'll just slap some comments on it and merge
<thumper> beuno: cool, thanks
<spiv> lifeless: so, at the risk of prolonging a finished discussion, I have a suggestion for you to consider... rename test_commit_exclude_subtree_of_selected to something like test_commit_exclude_overrides_selected_files.
<lifeless> spiv: heh.
<spiv> lifeless: the thinking is that the purpose of the test isn't just for the subtree corner case, that just happens to be how the test is implemented.
<lifeless> spiv: at this point I'll defer; three pqm merges for one small feature are too many
<lifeless> I think you're right
<spiv> lifeless: if you've already fired a patch, then I'm totally cool with doing nothing at this point :)
<lifeless> Pushed up to revision 3604.
<lifeless> Please use submit_branch, not pqm_branch to set the PQM merge target branch.
<lifeless> Checking the working tree is clean ...
<lifeless> Checking that the public branch is up to date ...
<lifeless> $
<lifeless> oh wow
<spiv> Ok, cool.  Sorry for the small confusions on my part that made it hard for us to understand each other!
<lifeless> the pushed up to revision 3604 line is space padded to the rhs
<lifeless> probably the process bar
<lifeless> spiv: no probs, these things happen
<spiv> The small confusions are possibly a sign of something that could be improved.  My guess is that something is my coffee ;)
<spiv> Thinking of food and drink... lunch time.
<lifeless> :>
<gnomefreak> what plugins are needed to run bzr bd in hardy?
<spiv> bzr-builddeb I guess.
<gnomefreak> let me rephrase that. "bzr db" cant load plugin from '/usr/lib/python2.5/site-packages/bzrlib/plugins'
<gnomefreak> bzr-builddeb is already installed
<lifeless> gnomefreak: there should be a backtrace in ~/.bzr.log
<mlh> s/db/bd/
<gnomefreak> you know whats funny the errors are just about the same
<gnomefreak> http://pastebin.mozilla.org/506523 is the full file but im not sure wher eyou need it from so i have full logs
<spiv> gnomefreak: nowhere in that log have you tried to run "bzr bd"
<spiv> gnomefreak: so there's no relevant traceback that I can see.  Another thing you could try is python -c "import bzrlib.plugins.builddeb"
<gnomefreak> spiv: sure it is
<gnomefreak> it left it out
<gnomefreak> maybe too big of a log
<spiv> gnomefreak: there's no line that has "bzr arguments: [u'bd', ...]"
<gnomefreak> http://pastebin.mozilla.org/506525
<gnomefreak> spiv: its not hte whole file, maybe a limit to size on pastebin
<spiv> Ah, ok.
<spiv> "#
<spiv> ImportError: No module named apt_pkg"
<spiv> that's the problem.
<gnomefreak> didnt use apt
<gnomefreak> nor apt_pkg
<spiv> No, but the plugin does.
<spiv> You presumably need to do "apt-get install python-apt"
<gnomefreak> ok will try
<gnomefreak> i would have thought builddeb package would bring it as a dep if its needed
<gnomefreak> that fixed it. thanks
<spiv> Yeah, me too.
<spiv> If you installed it from a deb, then that does sound like a bug in the package.
<Odd_Bloke> gnomefreak: What system are you on and what's the package version number?
<gnomefreak> Odd_Bloke: system? Hardy 386 and let me checkversion
<gnomefreak> builddeb = 0.95 bzr = 1.5-1
<Odd_Bloke> gnomefreak: Where did you get builddeb from?
<mwhudson> beuno: hi
<beuno> mwhudson, hi again
<mwhudson> beuno: https://code.edge.launchpad.net/~mwhudson/loggerhead/directory-listing-improvements <- nice functionality, iffy layout
<gnomefreak> Odd_Bloke: the repos
<mwhudson> beuno: guess what i'd like you to do :)
<gnomefreak> crap wait
<gnomefreak> wrong terminal
 * beuno branches and hopes for the best
<gnomefreak> builddeb = 0.93ubuntu1  bzr = 1.3.1-1ubuntu0.1
<beuno> mwhudson, I'm guessing it has something to do with the "problems with formatting though" of the commit?
<mwhudson> beuno: specifically, this puts the icon for the folder/branch in a separate cell to the target
<Odd_Bloke> gnomefreak: OK, that's more like what I was expecting.
<gnomefreak> sorry i forgot to go to chroot in that terminal
<mwhudson> so the '..' link lines up with the names
<mwhudson> beuno: the icon cell ends up way too wide though
<Odd_Bloke> The issue seems to be that bzr-builddeb depends on python-debian but python-debian only recommends python-apt.
<mwhudson> perhaps it would just be easier to add an icon for uplink...
<beuno> mwhudson, I'll fix, look, and merge  :)
<mwhudson> beuno: thanks!
<beuno> I'm trying to avoid getting to fixing setup, which has annoyed the hell out of me so far
<mwhudson> should address Peng's "leaking root directory name" thing too
<Peng_> Eh what?
<Odd_Bloke> gnomefreak: Ah, it's fixed in Debian.
<Odd_Bloke> And in Intrepid.
<gnomefreak> yeah intrepid does
<gnomefreak> 1.5
<Peng_> Should you guys be asleep yet?
<gnomefreak> Odd_Bloke: would backporting 1.5 be that bad or is bzr depend on alot of other packages
<gnomefreak> that would need to be backported
<Odd_Bloke> gnomefreak: Well, the issue you hit here was in bzr-builddeb, not in bzr.
<mwhudson> Peng: the 'bzr' in http://bzr.mattnordhoff.com/loggerhead/
<Odd_Bloke> And I have no idea about backporting, I'm not involved in Ubuntu development whatsoever.
<mwhudson> in the h1
<gnomefreak> Odd_Bloke: i wasnt sure if bzr built bzr-builddeb
<mwhudson> Peng_: beuno should
<mwhudson> Peng_: it's only 1730 for me
<Peng_> Oh, right, that leak. I forgot.
<beuno> I don't really sleep anymore
<Odd_Bloke> gnomefreak: Nope, it's a separate source package.
<Peng_> I sleep occasionally; I just don't get rested.
<gnomefreak> ok thanks
<Odd_Bloke> gnomefreak: There has been some discussion of backporting bzr itself, but I can't remember what the conclusion was.
<Odd_Bloke> Or even if there was one.
<spiv> The conclusion was "backporting a couple of easy-but-important fixes to 1.3.1 (making 1.3.2?) is worthwhile"
<Odd_Bloke> gnomefreak: ^
<gnomefreak> spiv: oh ok that makes sense
<poolie> hello spiv, lifeless
<lifeless> poolie: hi
<lifeless> poolie: I tested your parameterisation thing; it worked for me
<lifeless> http://rafb.net/p/J3j6NT50.html
<poolie> mm i'm just looking at that
<poolie> probably just user error last night
<lifeless> poolie: :)
<lifeless> Odd_Bloke: nice progress
<lifeless> Odd_Bloke: I'll do a review-run tomorrow I think
<nasloc__> newbie question: how do you keep linux device nodes like /dev/null in bzr's repo? I want to version control /dev using bzr.
<Odd_Bloke> lifeless: Thanks. :)
<lifeless> nasloc__: we don't support special files sorry
<lifeless> nasloc__: you'd have to write something to translate the special files into a storable form and back again (something like tar possibly)
<Odd_Bloke> jml: If you could cast your eyes over the Twisted-related changes in my latest PQM patch (look under pqm/ui/), that'd be much appreciated. :)
<beuno> mwhudson, you win. I'm firing up Gimp to make an "up" icon
<nasloc__> lifeless, oh I see :(
<nasloc__> lifeless, thanks anyway. is there a builtin or a standard way to do it?
<nasloc__> lifeless, like a automatic hook or some else.
<lifeless> nasloc__: there are hooks, but I don't think any would be suitable for what you need
<lifeless>  /dev is extremely dynamic on most linux system these days
<lifeless> igc: ping
<nasloc__> lifeless, oh thanks your info, what I want to do is to keep a embedded system's root filesystem, there's no devfs or udev on it anyway. I guess I'll just use a tarball to keep it.
<lifeless> nasloc__: if you're maintaining a filesystem I'd definitely want something that tracks modes and owners etc
<lifeless> and extended attributes
<lifeless> bzr doesn't do any of these (by design, because they port badly between machines and operating systems)
<matkor> olive-gtk during start: dbus_bindings.DBusException: Unable to determine the address of the message bus (try 'man dbus-launch' and 'man dbus-daemon' for help) - means I have to old dbus system ?
<lifeless> all bzr tracks is the execute bit
<beuno> Peng_, navigating to parent just hit trunk
<Peng_> beuno: Cool.
<gour> morning, attempt to pull from desktop machine to laptop gives me: http://rafb.net/p/xmCu5Z23.html although i would swear they should be the same (desktop repo was created by pulling from laptop). anything could change in latest beta and/or how to fix it?
<poolie> gour, current bzr.dev (after 1.6b3) should give you a better message
<Peng_> Wow, before refreshing the CSS, the look was really messed up. :P
<poolie> could it be that you upgraded one of them to use with bzr-svn?
<gour> poolie: i run b4
<gour> desktop shows: " Packs containing knits without subtree support" and laptop "Packs containing knits without subtree support" and i wonder how they're different
<gour> poolie: no, i don't use (yet) bzr-svn
<poolie> could you get the whole traceback from ~/.bzr.log please?
 * beuno is off to bed
<beuno> g'night all
<Peng_> beuno: It seems to be working perfectly. Good work, both of you. :)
<Peng_> I think I'll go to bed too, maybe.
<beuno> Peng_, thanks. I even had to pull out gimp for that one.  Night!
<gour> poolie: http://rafb.net/p/SgGbGp54.html
<poolie> well, that is interesting
<gour> i'm glad it is ;)
<poolie> and if you go to gaura-nitai what is in ~/bzr/.bzr/repository/format?
<lifeless> night beuno
<gour> poolie: it's not shared repo, i've only branch-format "Bazaar-NG meta directory, format 1"
<Peng_> I'm writing this as a mental note, but: How does loggerhead handle it if you have a branch inside of a branch? Is the inner branch impossible to discover from browsing the website? Is that acceptable?
<nasloc__> lifeless, is there a vcs can do that? tracks modes and owners and extended attribute (just works in linux is ok for me.)
<Peng_> nasloc__: Maybe you should check out etckeeper, which builds on top of a VCS.
<nasloc__> Peng, thanks, I'll check that.
<Peng_> (OK, I'm really going to bed now. Bye.)
<poolie> gour, so it seems that either there is a bug, or one of them is rich-root and the other is not
<poolie> clearly the code thinks there is a difference
<poolie> previously you said "desktop shows..." and i'm wondering where that came from...
<gour> poolie: desktop is gaura-nitai.no-ip.org
<poolie> i mean, which files are you looking at there
<gour> poolie: i wanted to pull from gaura-nitai's repo to laptop's repo
<poolie> gour, does it work if you try to pull over sftp rather than bzr+ssh?
<gour> poolie: let me try
<gour> poolie: no
<gour> poolie: shall i try to upgrade the repo and then try again?
<poolie> i'd like you to find the relevant repository directory for each branch
<poolie> which should be shown by bzr info
<poolie> and tell me the contents of .bzr/repository/format
<poolie> for each
<poolie> just to exclude the possiblitiy that it's some kind of bug
<poolie> if you don't mind
<gour> ok.
<gour> poolie: laptop has "Bazaar pack repository format 1 (needs bzr 0.92)"
<gour> poolie: while desktop (gaura-nitai) does not have that structure - it doe not have .bzr/repository/format only /.bzr/branch-format "Bazaar-NG meta directory, format 1"
<spiv> gour: that's strange, the traceback says there is a repository on gaura-nitai
<spiv> gour: i.e. I'd expect there to be a /home/gour/bzr/.bzr/repository/format based on that error message
<gour> spiv: but it's branch-only
<spiv> gour: what format is the branch?  Is it a branch reference (i.e. lightweight checkout)?
<lifeless> bzr info should help
<spiv> gour: could you try repeating with -Dhpss?  (i.e. bzr -Dhpss pull bzr+ssh://gour@gaura-nitai.no-ip.org/home/gour/bzr/cfgfiles)  That should indirectly show in the ~/.bzr.log which repo format file it is reading from the remote end.
<gour> spiv: here is info http://rafb.net/p/btLqey49.html
<spiv> gour: I'd expect a branch-only bzrdir in ~/bzr/cfgfiles, and a shared repo ~/bzr
<spiv> Right, bzr info says there's a shared repo in ~/bzr
<gour> here is the log http://rafb.net/p/bB7YWS76.html
<spiv> Right, 'get', '/home/gour/bzr/.bzr/repository/format'
<spiv> Which succeeds, i.e. that file exists.
<gour> yes, 'format' exists in laptop repo
<spiv> That log says that file exists on gaura-nitai.
<spiv> Which is your desktop, I think?
<gour> right, gaura-nitai is the desktop machine from which i want to pull
<spiv> Anyway, that bzr info paste says the gaura-nitai repo has rich-roots, and you earlier pasted that ''get', '/home/gour/bzr/.bzr/repository/format'
 * spiv tries again
<spiv> Anyway, that bzr info paste says the gaura-nitai repo has rich-roots, and you earlier pasted that laptop has "Packs containing knits without subtree support".
<gour> and format on gaura-nitai is "Bazaar pack repository format 1 with rich root (needs bzr 1.0)"
<spiv> Right.
<gour> and laptop repo has "Bazaar pack repository format 1 (needs bzr 0.92)
<spiv> So the format is different.  So there's no bzr bug here; you need to "bzr upgrade --rich-root-pack" your laptop repo.
<lifeless> note that this will propogate
<lifeless> if you actually have gone down this path by mistake, don't upgrade rather lets try to sort things out for you
<gour> spiv: ok. clear. i just wonder how the difference was made
<lifeless> bzr-svn uses rich-roots
<gour> but i don't use bzr-svn
<lifeless> if you did 'bzr branch svn:///' it will have made a rich-roots branch
<gour> no, i didn't
<lifeless> gour: someone you collaborate with might have?
<spiv> gour: normally people stumble into this when they've branched from bzr-svn, or from a branch created by bzr-svn.
<gour> no, my private machines and repo is handling my config files
<spiv> Otherwise if you've done 'bzr init --rich-root-pack' or 'bzr upgrade --rich-root-pack' in the past.
<spiv> bzr itself never defaults to this format.
<lifeless> or 1.6-rich-root
<lifeless> gour: this is obviously when you first noticed it ?
<gour> the only thing which i do is to re-build bzr from repo
<lifeless> gour: what have you done recently on your desktop ?
<gour> lifeless: commit a small patch and then i wanted to pull that commit to laptop in order to have them 'in sync'
<gour> ok, upgraded format, merged, committed...
<gour> all is fine now. thank you for the help
<gour> btw, i'm starting with the python (to help/tweak) GNUmed. which python mode you recommend for emacs-23, i.e. is the included one the best one?
<spiv> gour: I'm a vim user, so I can't help much with that :)
<gour> :-)
 * ToyKeeper tries to find a working combination of revisions for bzr + bzr-svn
<ToyKeeper> Okay, just needed bzr 1.5; the latest lp:bzr-svn works with it, but not bzr.dev
<ToyKeeper> Now to figure out how to save each feature branch rev to svn, instead of just one rev for the final merge...
<awilkins> ToyKeeper: Push your feature branches to svn as branches before you merge them ?
<ToyKeeper> I'm basically hoping to preserve history while dumping changes back into svn.  So far, even 'bzr svn-push' seems to send only the merge.
 * ToyKeeper hopes gnome gets converted to bzr soon
<awilkins> ToyKeeper: Yeah, what I'm saying is, push the branch before you merge it into trunk
<ToyKeeper> Yeah.  I was hoping to avoid dealing with svn "branches" at all.  :)
<ToyKeeper> I've figured out what I need to know, though.  It just sounded like 'bzr svn-push' would automate the process for me.
<ToyKeeper> Hmm, working with svn really makes me want URL aliases.
<matid> ToyKeeper: You should be glad you got bzr-svn to work ;) I'm fighting with it for 2 days already :)
 * dato uses zsh aliases for URLs in svn
<ToyKeeper> I had been thinking of making a bzr plugin for URL aliases...  this is just more motivation to do it.
<ToyKeeper> matid: lp:bzr-svn works okay with lp:bzr/1.5 ...  just remember to run 'make' in the bzr-svn dir before using it.
<ToyKeeper> Anyway, after spending an evening accessing at least two different sets of URLs per branch, I find myself longing for [paths] from .hg/hgrc
<lifeless> what does that do?
<lifeless> [we have a couple of similar things in plugins]
<ToyKeeper> It's a simple "key = value" list, where the values are URLs.
<ToyKeeper> The keys can be used anywhere an URL would go in hg
<lifeless> I think the bookmarks plugin is the equivalent for bzr
<ToyKeeper> So, it's easy to "hg pull fred ; hg pull sally ; hg push public ; hg push backup"
<matid> ToyKeeper: Guess it depends on the operating system :)
<matid> ToyKeeper: It fails for me on Mac OS X.
<lifeless> matid: have you filed a bug?
<ToyKeeper> The bookmarks plugin could be nice, except it doesn't work per-branch or per-repo.
<matid> lifeless: Nope, not yet.
<lifeless> ToyKeeper: well, repo's aren't semantic, but I could see it working per-branch or per url-prefix
<ToyKeeper> If I'm working on three different projects with Fred, I can't just "bzr pull fred" in each of them.
<lifeless> ToyKeeper: I believe that you can't today; I'm saying it should be possible for you tod o that
<lifeless> ToyKeeper: I'd start by filing a bug asking for that...
<Stavros> hello
<Stavros> i have pushed to some location and don't have a wc there, how can i get it from the repo?
<james_w> Stavros: "bzr help working-trees" may explain this for you
<Stavros> ah co, thanks :/
<LarstiQ> matid: do you have a pastebin or some such on what your (build?) problem for bzr-svn on mac is?
<matid> LarstiQ: http://gist.github.com/4052
<matid> LarstiQ: I've got lp:bzr/1.5 and lp:bzr-svn.
<matid> LarstiQ: And I did run make in in ~/.bazaar/plugins/svn.
<james_w> matid: can you look in your ~/.bzr.log to see why it can't load the svn plugin
<LarstiQ> james_w: the traceback looks sufficient
<james_w> I think the messages are in the wrong order for it to be causing the failure to load the plugin
<james_w> it maybe that you have two svn plugins around
<LarstiQ> oh right
<james_w> LarstiQ: bzr doesn't show tracebacks from plugin loading by default
 * LarstiQ nods
<LarstiQ> james_w: you are right
<LarstiQ> wb Zindar
<LarstiQ> matid: could you do what james_w said? If you aren't sure which part of .bzr.log is relevant, try with a fresh one and just the result of `bzr plugins`
<matid> LarstiQ: This is the fresh one after bzr branch: http://gist.github.com/4053
<matid> LarstiQ: I'll post another one for bzr plugins.
<matid> http://gist.github.com/4054
<matid> That's it.
<LarstiQ> matid: to me, on quick glance, that looks like lp:bzr-svn is ahead of lp:bzr/1.5 (ie, better fit with 1.6) but let me check the API changes
<james_w> AttributeError: 'module' object has no attribute 'properties_handler_registry'
<james_w> yes, that's new in 1.6
<ToyKeeper> When I tried a few hours ago, lp:bzr-svn worked with lp:bzr/1.5, but not lp:bzr
<matid> OK, will try with lp:bzr instaed of lp:bzr/1.5
<LarstiQ> matid: In general I'd say .dev matches .dev, and specific releases match (http://bazaar-vcs.org/BzrForeignBranches/Subversion mentions 0.4.10 works with 1.4 and 1.5)
<LarstiQ> ToyKeeper: interesting.
<ToyKeeper> ... retracing steps.
<ToyKeeper> It looks like I had to back up to a non-HEAD rev to make it work.
<ToyKeeper> The most recent tag in lp:bzr-svn works with lp:bzr/1.5
<matid> LarstiQ: lp:bzr with lp:bzr-svn throws a bus error at me when running bzr plugins.
<LarstiQ> oh wow
<LarstiQ> matid: just to be curious, did you at one point try released versions, bzr 1.5 icm with bzr-svn 0.4.10?
<ToyKeeper> matid: Try tag:bzr-svn-0.4.10 in lp:bzr-svn instead.
<matid> LarstiQ: Nope, I don't think so.
<ToyKeeper> I had no luck getting the head rev of lp:bzr-svn to work, at all...  and no success getting any rev of bzr-svn to work with bzr.dev
<matid> ToyKeeper: How do I check out that taG?
<gour> i'd like to provide bzr repo on LP for the cvs project. what do you recommend for CVS --> bzr conversion?
<ToyKeeper> matid: bzr branch lp:bzr-svn -r tag:bzr-svn-0.4.10 bzr-svn-0.4.10
<ToyKeeper> (or the same, from your existing trunk/ branch)
<LarstiQ> matid: what I'd do is `bzr revert -r tag:bzr-svn-0.4.10`
<LarstiQ> or if you want to have it seperate, do what ToyKeeper said
<LarstiQ> gour: is there a cvs-fastexport yet?
<matid> It now says that installed subversion does not have updated Python bindings.
<LarstiQ> sigh.
<LarstiQ> matid: you really don't want to get into the business of building patched python bindings on OSX I think.
<LarstiQ> (svn python bindings)
<LarstiQ> so.
<gour> LarstiQ: i'm not aware of. thinking about cvsps-import and tailor
<LarstiQ> matid: our current options are, I think: 1) figure out the bus error 2) find a packaged bzr-svn + up to date bindings 3) figure out two other bzr-svn and bzr revisions that are compatible.
<LarstiQ> gour: do you need it to be a continous sync, or just a one off conversion?
<LarstiQ> matid: are you on 10.4/10.5?
<matid> 10.5
<gour> LarstiQ: one conversion to provide 'sandbox' for devs to play with it
 * gour would like to persuade them to move to bzr ;)
<LarstiQ> matid: what svn version are you using?
<matid> 1.4.4 is installed by default on Leopard, I use 1.5.1 from MacPorts.
<LarstiQ> matid: bzr-svn 0.4.10 uses the svn provided bindings, bzr-svn trunk (which will become 0.4.11 at some point) has it's own bindings
<LarstiQ> matid: oh! 1.5 should be up to date enough I believe.
<LarstiQ> matid: can bzr-svn 0.4.10 find the right libraries then?
<matid> LarstiQ: I think I made some progress.
<matid> LarstiQ: Now I'm on bzr-svn 0.4.10 and lp:bzr/1.5
<LarstiQ> gour: I haven't converted any cvs repository myself. For a free sofware project I'd either let launchpad do the conversion, or figure out what they are using.
<matid> LarstiQ: I fixed my DYLD_LIBRARY_PATH and PYTHONPATH so that bzr sees svn 1.5.1 instead of 1.4.4
<LarstiQ> matid: right, now the combination of bzr, bzr-svn and svn sounds like it should work.
<matid> LarstiQ: That's what I get now though:
<matid> LarstiQ: http://gist.github.com/4060
 * gour is trying with cvsps-import
<LarstiQ> matid: aaargh, now you're running into an API change the svn developers saw fit to make.
<matid> LarstiQ: What should I do then?
<LarstiQ> matid: https://bugs.launchpad.net/bzr-svn/+bug/246683
<LarstiQ> matid: let me see if I can find which change fixed that, you need to have a slightly newer bzr-svn than 0.4.10
<ubottu> Launchpad bug 246683 in bzr-svn "Assertion `*path != '/'' failed" [High,Fix committed]
<LarstiQ> matid: or we can just steal the patch from debian: http://ftp.de.debian.org/debian/pool/main/b/bzr-svn/bzr-svn_0.4.10-2.diff.gz
<awilkins> Bindings should become a moot point when the current tip of 0.4 matures
 * LarstiQ nods
<LarstiQ> matid: I'd still be interested in the bus error for ongoing development btw
<awilkins> Alas, I stll have the opion that they are a little "hinky"
<LarstiQ> but right now I need to get back to studying :/
<LarstiQ> awilkins: yes
<awilkins> They have some catching up to do on Win32 and *nx64
<awilkins> And I have no idea about how well they work on OXS
<awilkins> OXS
<awilkins> Oh screw it, "those mac thingys"
<dato> not thingies? :-P
<gour> cvps-import failed...now trying with tailor
<matid> LarstiQ: OK, seems like that debian patch did the trick.
<LarstiQ> matid: does that mean your branch succeeded?
<matid> It's copying revision 610/1320 as of now.
<matid> It ought to succeed then.
<matid> But I'm still keeping my fingers crossed.
<LarstiQ> ok
<LarstiQ> matid: I'll check back in a while, afk for now
<matid> LarstiQ: k, thanks for your help!
<jelmer> ToyKeeper, what error did you get trying to use lp:bzr-svn and lp:bzr?
<matkor> What is use of dbus in olive (bzr-gtk) ?
<awilkins> That's the commit notfier, no?
<gour> does bzr-gtk still needs seahorse?
<matkor> gour: seems so
<matkor>   File "/home/users/matkor/src/bzr-gtk/trunk-matkor/seahorse.py", line 32, in ?
<matkor>     bus = dbus.SessionBus()
<gour> matkor: hmm, gpa is not enough?
<matkor> gour: I do not know yet .. I just run recent bzr-gtk release and got stuck with fact that it raises exception during launch time
<matkor> gour: Are you bzr-gtk developer ?
<james_w> matkor: I think that part was fixed
<gour> 0.95 works here
<james_w> it uses it if available, but doesn't crash anymore if it isn
<gour> matkor: no
<matkor> james_w: For me it throws exception , I suspect I have older dbus system and situation "not available" is not recognized propertly
<matkor> I even get different exception type: dbus_bindings.DBusException not as expected in code: except dbus.exceptions.DBusException, e:
<pickscrape> So I did get into a bit of trouble upgrading our server from 1.5 to 1.6b3 :(
<pickscrape> Any idea how long before 1.6 final is released?
<awilkins> Just build your own with the version number edited in the source:-}
<pickscrape> :)
<pickscrape> Unfortunately I can't think of a sneaky way to get that to the 1.5 clients.
<pickscrape> Problem is 1.5 is having to reconnect to the server every time, much like my 1.6 client kept having to reconnect to the 1.5 server.
<awilkins> Is that bzr-search thingy any good?
<jelmer> awilkins, yes
<awilkins> What's the query language?
<jelmer> awilkins, it's very basic - nothing boolean, just search for all words in the query I think
<james_w> I think it has negations now
<luks> I wonder why it doesn't use something like xapian
<james_w> because xapian can't back on to bzr's transport API I believe
<luks> it doesn't have to
<james_w> it does for all the things Rob wanted it to do
<awilkins> Hmm, I wanted to do things like "find diffs that this string was removed in"
<jam> luks: http://www.advogato.org/person/robertc/diary/85.html
<jam> I would imagine that xapian fails the
<jam> "trivially installable"
<jam> he mentions it as a candidate
<jam> "xapian - it will need a custom storage backend"
<luks> huh, no it doesn't need a custom storage backend
<luks> it's trivially installable on any linux machine, I'm not sure about windows
<luks> oh, wait, bzr-search works with indexes over bzr tranports?
<jam> luks: afaik ,yes
<luks> e.g. you have a branch on sftp server and bzr search will use the remote files
<luks> ah
<luks> but you have to copy the indexes manually, right? bzr push will not copy them?
<jam> luks: I don't know
<jam> I would assume that is true
<jam> I don't know if you have a post-change hook on the sftp branch, if it will automatically generate them
<jam> like it does locally
<james_w> it installs the hook to update them, but doesn't push them around
<james_w> so "bzr index" a branch and the index will always be up to date
<gour> too bad, ghc decided to move to git :-(
<gour> "Speed ruled out bzr" :-/
<LarstiQ> gour: actual measurements they performed, or speed myths/rumours?
<awilkins> Meh, Bazaar is also the only VCS on the FreeBSD list not being evaluated actively
<awilkins> I have come to the conclusion that the laptop that IT services are supposed to be upgrading me to is a myth
<awilkins> They have rung me today to let me know I can take delivery of it, they know my location... but so far, no sign of it.
<gour> LarstiQ: i'd say rumours only, or one benchmark mentioned on trac' wiki
<gour> LarstiQ: see it at http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation
<jelmer> any DD's around interested in sponsoring bzr-related packages?
<evarlast> we have been working peer to peer style with some success, but as N has increased we think we need to move to a central style. Is there a way I can convert a branch to --no-trees after the fact? I'd like to take a branch and move it to a server
<james_w> bzr remove-tree
<james_w> if you "bzr push" to the server then the branch on the server won't have trees
<james_w> whether or not you create a repo with --no-trees, but I would recommend you doing so anyway
<ronny> hi
<evarlast> remove-tree. thank you. I couldn't find that searching the docs.
<ronny> is there a way to alter commits ? i commited changes i didnt want to by accident
<andrea-bs> ronny: bzr uncommit
<evarlast> I'm going to bzr push to my destination server, then I'm going to bzr remove tree from that destination.
<evarlast> then I'll probably run a smart server out of that branch
<ronny> thx
<LarstiQ> evarlast: are you sure there are working trees on the destination server anyway?
<evarlast> the destination server does not exist.
<evarlast> I'm creating it.
<evarlast> we had been strictly peer to peer with no server.
<evarlast> my goal is to come up with a central branch.
<evarlast> i'm not sure if just branching and removing the tree is what I want, or if I should init-repo and push my revs there somehow.
<james_w> bzr init-repo --no-tree bzr+ssh://server/root/repo
<james_w> bzr push bzr+ssh://server/root/repo/branch
<james_w> should be all you need, repeat the second for as many branches as you want
<LarstiQ> evarlast: pushing remotely doesn't touch the working tree, so you wouldn't have to remove working trees.
<evarlast> and that push will include all my history!  Awesome!  that is EXACLYT what I needed.
<evarlast> <3 U
<evarlast> james_w: where can I send you gifts? :)
<LarstiQ> evarlast: well, that is sort of the point of pushing ;)
<james_w> evarlast: james_w @ my house please
<Pilky> hey, does anyone know of a way to encrypt a bzr repository on a server?
<jelmer> Pilky, you mean encrypt in some way that leaves it usable afterwards without unencrypting the whole repo?
<dato> does somebody know if there's a standalone implementation of bram cohen's diff algorithm? (the one in bzr)
<dato> standalone as in providing /usr/bin/foodiff
<Pilky> jelmer: yeah, so I could still push to it/pull from it but it's stored encrypted on the server itself
<Pilky> got a friend looking at bzr but wants to know about encryption
<jelmer> Pilky, I think there was somebody working on a plugin for the SoC a while back
<jelmer> but I'm not sure how far he got
<Pilky> ok cool, I'll have a look for that
<chevdor> quick one regarding translations in launchpad, some of them are flagged as "Someone should review this translation", if I review a translation and agree with it, shall I uncheck the checkbox ???
<beuno> jelmer, http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/revision/198
<chevdor> i am refering to bzr-gtk
<beuno> thanks  :)
<beuno> chevdor, if you want someone to review it, check the box
<jelmer> dato, afaik the bzr implementaiton can be run as a standalone app
<jelmer> beuno, thanks
<dato> jelmer: yep, somebody in other channel told me, but thanks :)
<chevdor> beuno, well some of them may need another review but the question is : once I do reviesw one that needed review, is it ok to definitely untag the "need review"
<beuno> chevdor, yeah, if you don't feel they don't need review anymore, you can unmark it.  It depends on each translarion group, but if you're confident, IMHO it's fine
<chevdor> ok, then I'll untag a bunch of them and leave the tag for those that are correct but sound a bit weird... :)
<dakira> hi! I just read the complete user docs at bazaar-vcs.org but still have some problems setting up a central repository.. I'd be glad if someone could point me in the right direction. I documented my steps here: http://paste.pocoo.org/show/81301/
<james_w> hi dakira
<james_w> dakira: your expectations were correct
<james_w> what were you hoping the last command would do?
<chevdor> hello, how can i actually install/run bzr-gtk ? I did branch the trunk, ran ./setup.py build, then ./setup.py install, restarted nautilus but still no icons, I can see the new items in the menu though. Pbm w/ icons ? only on my box ??
<james_w> chevdor: did you do a "nautilus -q" ?
<chevdor> james_w, twice :)
<james_w> I'm not sure then I'm afraid
<james_w> I guess it's possible that setup.py install doesn't put the icons in the correct location
<jelmer> chevdor, do you have python-nautilus installed?
<dakira> james_w: I read on a blog howto that just binding would not create the working-tree at the remote location
<james_w> dakira: that is correct
<chevdor> jelmer, i do, I *do* see the menu entries in the nautilus context menu
<james_w> dakira: if you would like to create the working tree then you need to ssh to the box and run "bzr checkout ." in that directory
<jelmer> chevdor, What's not working ?
<james_w> dakira: "bzr checkout sftp://server/.../branch/ sftp://server/.../branch/" might do it, I've never tried
<chevdor> jelmer, i thought I'd see icons on the versioned folders, was I expected too much ? :)
<james_w> dakira: note however that creating the working tree won't keep it up to date as you work.
<jelmer> chevdor, you should see emblems
<chevdor> jelmer, ahh that's what I thought. I do NOT see anything but the regular folder icon (i run compiz... but I don't think it gets on the way)
<dakira> james_w: okay.. maybe I misunderstood the concept.. so when I want to work from a different location can I pull a branch to work on from the remote server even if there are no files in the project directory on the server?
<james_w> dakira: yeah, all you need is ".bzr" to be there. If you want to grab a copy to work on locally then "bzr checkout" or "bzr branch" will create the files locally for you to edir
<jelmer> chevdor, probably caused by the gnome theme you're using
<dakira> james_w: great.. thx..
<dakira> james_w: I should have just started working, instead of wondering why there were no files. So I guess bazaar stores the stuff in the repository?
<james_w> dakira: yeah, all of the content is stored in .bzr, just not in a way that's easily readable.
<dakira> james_w: great. thx for the support and for clearing things up!
<james_w> dakira: no problem, feel free to ask any other questions
<chevdor> jelmer, hmmm I'll check this out but I do see emblems, but not the bzr ones
<chevdor> jelmer, I am using the default one (human). Are u aware of a problem with this one ?
<jelmer> chevdor, human is only the default on ubuntu I think
<chevdor> jelmer, indeed I use ubuntu
<chevdor> jelmer, do u recommand a specific one that works ?
<jelmer> chevdor, not sure
<chevdor> jelmer, I have tried a few, none works
<jelmer> chevdor, are you using the ubuntu package?
<chevdor> jelmer, nop, it provides 0.93 where icons were disabled I think, I am using trunk
<sebp> why isn't there a deb of 1.5.0 for hardy in the ppa?
<beuno> sebp, something went terribly wrong, had tobe removed. You can get the 1.6b3 from: https://launchpad.net/~bzr-beta-ppa/+archive
<sebp> beuno: okay, I install from source then
<evarlast> whoa, just realized I have 1.3.1 on my hardy :)
<beuno> sebp, the 1.5 for Gutsy may work
<beuno> (if you prefer to stick to debs)
<sebp> not really, I just was wondering why it's missing
<beuno> sebp, there was a problem with the packaging of 1.6b2 which superceded 1.5
<hsn_> anybody knows how to convert CVS repo from sf.net to bzr? I tried some convertor utility and it needs local access to repo
<meteoroid> i think there's a way to export
<meteoroid> did you try a cvs converter, or an sf migrator?
<meteoroid> you probably can migrate sf cvs to local cvs or svn and then use that to more easily get into bzr
<meteoroid> also, i think SF may migrate your CVS to SVN for you, which would make it pretty easy to get at with bzr-svn plugin
<fullermd> You can rsync down a sf.net CVS repo...
<meteoroid> nice..
<james_w> hsn_: you can request launchpad do that for you
<meteoroid> nice++ :)
<hsn_> launchpad can do CVS import from sf?
<lifeless> hsn_: it can import MAIN from CVS on sf
<lifeless> hsn_: to do a migration, if you want to move the project to bzr; you should rsync the repo down and run the cvsps-importer
 * beuno hits revno 200 in Loggerhead's trunk and celebrates
<pickscrape> beuno: nice work!
 * pickscrape updates
<beuno> pickscrape, thanks  :)
<alefteris> what option I must use with setup.py to install an extension to .bazaar/plugins?
<lifeless> alefteris: if you are installing a plugin to your home dir, just copy the directory there
<lifeless> then do ./setup-py build_ext -i
<alefteris> thanks a lot lifeless :)
<alefteris> lifeless, updated http://bazaar-vcs.org/UsingPlugins, hope its ok
<malept> hi, I found some rather odd behavior in 1.6b3...it seems that I cannot run `python -c 'from bzrlib import merge'`, throws an ImportError.  I can successfully run that command, however, on 1.5 and 1.6b2.
<malept> traceback: http://paste.ubuntu.com/34519/
<luks> looks like a circular import
<luks> or not
<lifeless> likely is
<lifeless> lazy_import hides these
<lifeless> malept: try importing one of the things it wants first
<lifeless> malept: e.g. from bzrlib import branch, merge
<malept> lifeless: that works.
<malept> lifeless: shall I file a bug?
<malept> (I actually hit this while running cmd_merge().run() in a small script I'm writing, the python one-liner is just the testcase)
<lifeless> sure
<rockstar> beuno, hi
<meteoroid> so, i am branching from an svn repo which houses many projects, e.g. repo/project/trunk repo/project2/branches etc..
<meteoroid> bzr branch doesn't seem to detect the branching pattern, though it looks perfectly sensible for me, or, at least, there is a trunk and there are tags..
<meteoroid> i recall in the past that svn-import was better at this, but it only grabs an entire repo, not just a path
<lifeless> meteoroid: svn-import was better when you branched the root
<lifeless> meteoroid: if you're not branching from the root, AIUI svn-import and bzr branch should do the same thing
<meteoroid> so, my concern is that each tag / branch will be an entire full copy in bzr instead of a proper branch, as i observed last night..
<meteoroid> hm, actually it doesn't look too bad.. okie doke.
<meteoroid> guess ill just have to learn about this by performing lots of tests
<elmo> lifeless: http://voi.aagh.net/bzr-fetch.log
<elmo> lifeless: that's from LP bzr mirroring a branch
<elmo> lifeless:  is the repeated 200-ing expected?  I don't have the http mavenry to know off hand if bzr's range requests would generate a 206 or 200 response
<lifeless> 206's are partials
<lifeless> and there are 206's there
<elmo> right
<elmo> but a lot of repeated 200s too
<lifeless> thats a knit repository
<lifeless> upgrade it to packs; it will be a lot happier
<elmo> lifeless: sure, but, err, is LP doing this to all knits repositories?
<elmo> 21:38 < lifeless> thats a knit repository
<elmo> 21:39 < lifeless> upgrade it to packs; it will be a lot happier
<elmo> Freaky: ^--
<mwhudson> beuno: you rock
<Freaky> ah
<lifeless> elmo: probably yes
<lifeless> I smell a bug though
<lifeless> elmo: ah yes
<lifeless> 1.63
<lifeless> 1.6b3
<lifeless> 1.6b4 has my updated fetch code
<lifeless> so update launchpads bzr, it will also make things more kumtreya
<Freaky> no no, you're supposed to blame me, call me an idiot and then ban me, not fix it before I've even said anything, sheesh, haven't you worked on OSS before?
<elmo> mwhudson: that was the sound of the bzr team knocking the ball back into your side of the court, just fyi ;-)
<jelmer> lifeless: Any chance you can sponsor uploads of bzr-email and trac-bzr ? They're already in the archive but don't have DM-Upload-Allowed: yes set yet
<elmo> jelmer: I can if you like, it's not my working day anymore
<jelmer> elmo: Thanks
 * mwhudson mutters something about the 1.6 release
<jelmer> elmo: The packages are uploaded to mentors.debian.net, let me dig up the links..
<jelmer> http://mentors.debian.net/cgi-bin/maintainer-packages?action=details;package=trac-bzr
<jelmer> http://mentors.debian.net/cgi-bin/maintainer-packages?action=details;package=bzr-email
<elmo> gah
<elmo> that's trying to make me log in
<elmo> jelmer: do you have the packages somewhere public?
<elmo> (if not, I can create an acount, I guess)
<jelmer> try http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=bzr-email
<jelmer> (that's from the list for sponsors rather than the list for maintainers)
<elmo> aha, yep, that works, thanks
<elmo> will it makes things hard for you if I don't use this mentors.d.n ...interestingness?
<jelmer> no
<rocky> is there an easy way to query my main branch to see the commit msgs of the other branch i'm about to merge? (for whatever revisions the merge will figure out to do?)
<jelmer> mentors.d.n is mainly just a ftp server with a fancy web frontend added to track the progress of a package in Debian
<fullermd> rocky: missing maybe?
<rocky> ah yes... that seems to do it
 * pickscrape would like to see something like bzr log --include-pending
 * fullermd has occasionally thought that stat --show-ids should show the revids of the pending merges...
<james_w> I tried to implement a revspec the other day to allow you to specify these revisions, but our current revspec code isn't very amenable to it
<elmo> jelmer: bzr-email seems to have lost the NMU?
<jelmer> elmo: Whoops, I must have forgotten to import that
<elmo> +Depends: bzr (>= 1.0~),
<elmo> looks a little odd - any reason for the '~'?
<rocky> ok, next question ... i can't seem to find docs on the --log-format switch for "bzr missing" ... it's not in the man pages or user guide... any suggestions?
<jelmer> elmo: I used to build with a pre-release version of bzr, that must be how it got in there
<jelmer> elmo: I'll remove it now that I'm importing the NMU entry
<elmo> +has a pricate address (e.g. bzr+ssh but anonymous access might be bzr:// or
<elmo> ^-- speeling (private)
<fullermd> rocky: It's the same as the options for 'log'
<elmo> jelmer :not sure if that's actually your change or not ;-)
<fullermd> rocky: (Actually, it lists them in missing too...)
<jelmer> elmo: Whoops, that's from upstream
 * jelmer files a bug
<jelmer> elmo, I've uploaded a new version with the NMU changelog entry imported and dependency on bzr (>= 1.0) to mentors.d.n
<rocky> fullermd: ok... why can't i seem to find what you'er talking about? :)
<fullermd> rocky: Right below that line, it lists the three.
<rocky> fullermd: oh... --log-format=ARG means line, long, or short? i assumed it took a much more flexible format
<fullermd> No, just one of the pre-defined names.
<mwhudson> jelmer: i'm tempted to post to the 'the list is too busy' discussion
<mwhudson> to say "bazaar-commits is too high volume too, jelmer should stop working so hard"
<mwhudson> :-p
<jelmer> mwhudson, :-)
<elmo> jelmer: blink
<elmo> jelmer: does mentors.d.n allow you to just overwrite the files with same name, different contents?
<jelmer> elmo, yes
<jelmer> elmo, I think the idea is that since review sometimes takes so many iterations, you wouldn't want to have to end up incrementing the debian reversion each time
<dato> aah, that old discussion.
<dato> pops back in the most unexpected places :-P
<lifeless> dato: so, did you read that thread?
<dato> not yet, sorry, work is leaving me with much-less-than-before free time.
<lifeless> thats ok
<Necoro> anyone here having a linux box with 2.6.25 kernel (or later) and a vfat partition at hand?
<Necoro> hmm ... nevermind *tries something different*
<ToyKeeper> If I were to modify bzr's config loader so it checked .bzr/branch/branch.conf first, then checked ~/.bazaar/bazaar.conf if no result was found...  is that likely to be accepted?
<ToyKeeper> That would allow any setting to be per-branch.
<lifeless> branches aren't trusted data
<lifeless> its inappropriate for every setting to be per-branch
<ToyKeeper> No, not every setting should be per-branch.  This would just make it possible.
<lifeless> that said we already have cascading configs so that a setting in
<lifeless> any file can be found from the branch config object
<elmo> +   "smtp_password" is not, you will be prompted for a password.S
<ToyKeeper> Does the code grabbing the setting need to check that explicitly?
<elmo> jelmer: ^-- another trivial/minor typo (end-of-line)
<lifeless> ToyKeeper: only in that it needs to use branch.get_config()
<lifeless> rather than asking for a url config or a global config
<jelmer> elmo: Thanks, fixed (upstream)
<ToyKeeper> And, if the branch has no config, branch.get_config() will return the global setting?
<lifeless> branches always hasve configs
<ToyKeeper> If the branch doesn't have the requested item configured...
<lifeless> it will cascade
<lifeless> through locations.conf and bazaar.conf
<lifeless> and any others a plugin might have wedged in
<ToyKeeper> But it's normal to not check the branch, because the branch might have malicious settings?
<lifeless> it depends on the option
<lifeless> if its an option that is fine to have in a branch just check the branch
<lifeless> options that wouldn't be fine would be e.g. 'download this plugin from this url automatically' :)
<lifeless> and hook code - arbitrary code execution is not a win :)
<ToyKeeper> I'm curious because I was trying to find a way to do per-branch bookmarks, and it occurred to me that the per-branch bit is probably not something the plugin should need to re-implement.
<lifeless> elmo: was the smtp password reference for me ?
<elmo> lifeless: I dunno, it's bzr-email thing, but jelmer said he fixed it
<lifeless> ToyKeeper: right, you don't have to implement anything for something like that; just use branch.get_config().set_user_option
<lifeless> elmo: ah, ok
<ToyKeeper> It looks like it'll be easy to change, then.  :)
<lifeless> you might need to do some fiddling
<lifeless> I imagine that this use case makes sense:
<lifeless> when updating a bookmark, save it to the place it was read from
<Rhamphoryncus> Is it possible to rename a branch?  Why do I get the feeling it's quite easy..
<lifeless> mv
<ToyKeeper> I usually use a config library which has a list of places to look...  it loads them in generic-to-specific order so the last one 'wins', and saves in reverse order, so it's saved to the most specific place available.
<ToyKeeper> Rhamphoryncus: bzr nick new-branch-name
<ToyKeeper> Rhamphoryncus: It's also usually helpful to rename its dir to match the nick.
<Rhamphoryncus> nick?
<ToyKeeper> Rhamphoryncus: Or, if you haven't set a nick, renaming the dir is sufficient.
<Rhamphoryncus> so just renaming the dir in the repository will "just work"?  No weird errors?
<ToyKeeper> Yeah.
<ToyKeeper> You can verify the new name by running 'bzr nick' in the branch.
<ToyKeeper> ('nick' as in 'nickname')
 * Rhamphoryncus will just tarball the repository first.. just in case ;)
<luks> Rhamphoryncus: the branch knows about it's repository, not the other way around
<lifeless> ToyKeeper: thats what our config module does
<luks> so if you move a branch within the repository, nothing will change from that point of view
<lifeless> ToyKeeper: the only thing I was noting is that when you set a key it goes to the top of the stack - so to the branch, but if a user is updating a bookmark they had set globally they probably want it saved globally
<pickscrape> Anyone know why bzrlib.transport.get_transport() might be returning me a readonly transport?
<pickscrape> The transport in question is bzr+ssh
<lifeless> thats not normally readonly, but you might just not have permission to write?
<pickscrape> Normal bzr operations work fine.
<pickscrape> I'm trying to use delete_tree().
<spiv> Ah, that's a bug.
<pickscrape> I am passing a possible_transports list: I wonder if something I did earlier created a readonly transport.
<spiv> RemoteTransport doesn't actually implement delete_tree.
<pickscrape> How are remote branches normally deleted?
<spiv> Or more exactly, it's hard-coded to raise TransportNotPossible('readonly transport').
<pickscrape> spiv: ah, so it's surprising error then
<spiv> Well, it's ok for a transport not to implement delete_tree (according to our test suite)
<pickscrape> Yes, but the error message doesn't exactly tell the truth
<spiv> Though it is a bit funny; I think the other transports that don't support that are either readonly or don't support list_dir.
<pickscrape> This one definitely supports list_dir: I've been using that already
<spiv> Right.
<pickscrape> So how do remote branches normally get deleted?
<spiv> And as you say, the error message is pretty misleading.
<pickscrape> I'm writing this to provide a 'safe' way for our developers to delete branches that are finished with
<pickscrape> But this is something of a barrier :)
<spiv> Instead of "remote_transport.delete_tree(...)", you might be able to do "bzrlib.transport.Transport.delete_tree(remote_transport, ...)"
<pickscrape> spiv: sneaky... I'll try it
<spiv> I think remote branches are normally deleted by hand; I usually do it from a shell prompt on the remote server.  Branches hosted on LP can be removed through the web UI.
<spiv> Typically I just ignore them though, they don't take up much space, so there's not benefit to deleting them.
<pickscrape> Other than seeing the woods for the trees
<pickscrape> If we just leave them we will end up with a *lot* of branches in no time.
<spiv> Yeah.
<spiv> In my case I don't expect people to be browsing my repos directly, though.
<Rhamphoryncus> luks: ahhh
<spiv> BundleBuggy and Launchpad keep track of the interesting work.
<pickscrape> My other alternative is to add a trac plugin that deletes the branch, but since I'm doing so much else in the bzr plugin I'd rather keep it all in the same place.
<spiv> Using the hosting area as a listing of interesting/active branches isn't a bad idea though.  (Just explaining why it hasn't mattered in my case)
 * spiv nods
<pickscrape> The other thing is the code I've got does checks to make sure the branch in question has been merged before deleting it (idiot proof)
<pickscrape> People wandering on the server could accidentally delete the entire shared repo :)
<spiv> It should be possible to remove a branch easily via the smart protocol, so if that isn't possible yet then that is something we ought to fix.
<spiv> And "we" == "me", probably :)
<pickscrape> spiv: in any case, you are a sneaky genius. It worked!
<Rhamphoryncus> thanks y'all, seems to be working fine
<spiv> pickscrape: have you seen https://edge.launchpad.net/bzr-removable, btw?
<spiv> pickscrape: it can scan your branches to check that they have been merged, and don't have uncommitted changes, and don't have code shelved, etc.
<pickscrape> Hehe, nice.
<spiv> pickscrape: i.e. it can find the branches that are safe to remove.
<pickscrape> What would be good for our developers to use as well.
<pickscrape> We're strictly using bound checkouts right now, what I've written is to check for sideways merging, if you know what I mean.
<pickscrape> I might add that one to the list of plugins that our plugin checks out automatically.
<pickscrape> In case you can't tell I have to do a lot of hand holding where version control is concerned...
<pickscrape1> Note to self: don't kick the UPS power button...
<davidstrauss> pickscrape: Did you discover that the power is, indeed, interruptible?
<pickscrape1> I did, and it was remarkable just how quickly the interruption took effect.
 * pickscrape1 wonders why they put the button at the front...
 * davidstrauss thinks he's not going to merge in the changes to the universe created in pickscrape1's branch of reality.
<lifeless> pickscrape1: so that it can be kicked
<pickscrape1> They've diverged too much anyway: too many conflicts
<pickscrape1> Hmm, I appear to be here twice.
<Peng_> I guess the old one hasn't pinged out yet.
<Peng_> If you nick is registered, you can ghost it, or you can just wait.
<pickscrapeX> I am registered. How do you ghost it?
<Peng_> /msg nickserv help ghost, I think.
<pickscrapeX> Peng_: cool, thanks
<pickscrapeX> \o/
<pickscrapeX> Good one to remember that, thanks.
<jelmer> elmo, still there?
<elmo> jelmer: yeah sorry, the Ubuntu CC meeting I was waited for started.  I'll get to the upload after that, if that's OK?  otherwise, feel free to bypass me if you have another DD handy
<Necoro> lifeless: remember the issue with branching/initializing repos failing on vfat?
<jelmer> elmo: No hurry, thanks :-)
<lifeless> Necoro: yah
<Necoro> lifeless: seems to be a kernel issue - works in 2.6.24 - but not in 2.6.25
<lifeless> Necoro: ah interesting
<Necoro> (haven't tested 2.6.26)
<lifeless> Necoro: if you can get a detailed cause we might be able to work around, or if its delibrate and not a bug I guess we'll have to change somehow
<beuno> rockstar, hey!
<beuno> mwhudson, :)
<Necoro> lifeless: it seems like it is only possible now to toggle the "write" flags ... "r" and "x" can't be changed
<beuno> I want 1.6 out the door!
<rockstar> beuno, I'm packaging loggerhead
<beuno> rockstar, you way want to take a look at: https://code.edge.launchpad.net/~jelmer/loggerhead/debian
<rockstar> Hrm, that's close, but not what we really want.
 * rockstar looks around for jelmer
<jelmer> rockstar, hi!
<rockstar> jelmer, hi!
<rockstar> It doesn't look like your package ships with a default conf, just the example.
<elmo> bzr 1.6 is in danger of becoming the DukeNukemForever of VCS
<rockstar> +1 elmo
<jelmer> rockstar: it ships with an example configuration
<jelmer> rockstar: the package is not ready yet though, because loggerhead insists on loading the configuration from the same directory as it itself lives in (e.g. /usr/lib/python2.5/site-packages/loggerhead)
<rockstar> jelmer, shoot, I didn't notice that.  Probably wouldn't have until I actually got the package created
<beuno> jelmer, I'll be happy to fix that and shove it into /etc/*, but I don't really know what the best way to do that is. I'm guessing hard-coding the path isn't one of them
<beuno> I absolutely want 1.6 to be easily installable, above all
<nailor1> i've got some issues with the olive-gtk gui. where would i discuss them
<rockstar> beuno, if you hard code it, my diff for the package will change it.
<jelmer> rockstar: I'm happy to work together on Debianizing loggerhead further, seems pointless to have two efforts
<rockstar> jelmer, absolutely.
<rockstar> I guess I didn't look hard enough when I looked for any started efforts.
<beuno> so, if you guys can figure out the config file bit, I'll keep on smashing the remaining bugs
<rockstar> beuno, I'm sure we can get something figured out.
<beuno> jelmer has already been sending great patches to make the package as "debianizable" as possible
<beuno> on a happy note, as of today, "setup.py install" actually works  :)
<rockstar> jelmer, the basic premise for all of this is that we want people to be able to apt-get install bzr-codehosting, and have all the tools up and running, similar to installing trac, ViewVC, etc.
<jelmer> rockstar, ah, cool
<rockstar> beuno, that's what I saw.  That makes packaging easier, but it looks as if jelmer already knew that.
<beuno> rockstar, you can usually asume jelmer knows everything  :p
<rockstar> so, jelmer == God?  :)
<fullermd> Hm.  If that's so, I've got a *LONG* list of things to talk to him about...
<jelmer> Aren't most rockstars gods as well ? ;-)
<rockstar> jelmer, I'm more of a wannabe rockstar
<jam> rockstar: so sort of : http://en.wikipedia.org/wiki/Rockstar_(Nickelback_song)
<jam> (good song, by the way :)
 * rockstar cringes at Nickleback.  :)
<jam> at least, a fun music video
<jam> lifeless: we should chat sometime when my power isn't fluctuating about your "reachability" stuff
#bzr 2008-08-06
<jam> lifeless: I've been working on a lazy revno mapper, which seems to work well (sometimes)
<jam> I'm considering ways to refine it
<lifeless> jam: is it in bzr.dev?
<jam> lifeless: the *code* is in a branch (not a plugin)
<fullermd> Has anybody noticed a regression in permissions in the repo?
<jam> And I'm planning on submitting it for review
<lifeless> jam: ok
<jam> though I might still want to tweak it a bit
<jam> I don't have power at home right now
<jam> but
<lifeless> jam: I have two use cases that I don't think will work well..
<lifeless> tags and search
<jam> http://bzr.arbash-meinel.com/1.6-dev/lazy_revno when I do
<fullermd> Hm.  There is.
<lifeless> both tend to grab data from fairly evenly distributed bits of the graph and then want a revno for it
<jam> lifeless: sure, but you can still do it with local ops
<jam> instead of traversing the whole graph
<jam> lifeless: at the moment, the time is strictly dominated by 'get_parent_map' calls o
<jam> on my pack repo
<poolie> jam, spiv, igc, call in a sec
<Necoro> lifeless: found the commit in the kernel - and the workaround
<lifeless> jam: right, I agree that you can examine less than whole
<jam> so I'm trying to find ways to minimize "leaks"
 * fullermd files a bug.
<lifeless> jam: but on a 100K tree getting to the root is still what - 20K operations vs 1 for a tag name retrieval and <variable-but-small> for a search result
<jam> lifeless: I don't need to get to root
<jam> lifeless: just to the common ancestor
<lifeless> sure
<lifeless> my point is that unlike merges or 'log' these two operations tend to throw stuff up at or near root routinely
<jam> for example, 45ms for 3512.2.4
<jam> lifeless: i can see your point
<lifeless> how long for '3' ? :)
<jam> running timeit now
<lifeless> for extra credit, how long cold cache
<jam> 936ms on the pack repo
 * fullermd arrogantly assigns it 'critical' status.
<james_w> you got an alogrithm that didn't have to find root? neat.
<james_w> or maybe I had that, I forget
<james_w> at least yours works :-)
<jam> james_w: no, I started from scratch :)
<jam> lifeless: 617ms with a fully packed repo
<lifeless> jam: not the common case :)
<jam> as I mentioned, dominated by the get_parent_map time
<lifeless> might want to try on a btree repo
<jam> sure, something to do later
<jam> family time in the dark for now
<jam> :)
<lifeless> wheee
<jam> lifeless: unpacked btree repo is 787ms versus 936ms for pack-0.92
<lifeless> good
<elmo> jelmer: dh_python: Doing nothing since dh_pycompat exists; dh_pysupport or dh_pycentral should do the work. You can remove dh_python from your rules file.
<jelmer> elmo: Yeah, I noticed that as well. I need to look into avoiding that warning when using cdbs.
<elmo> jelmer: both uploaded
<jelmer> elmo: Thanks, much appreciated!
<Peng_> Hmm, to follow the usual schedule, I think 1.6 final should've been released shortly after 1.6b2.
<Peng_> The new smart protocol would've been the most interesting new feature.
<evarlast> JFYI over here, we are in no rush for 1.6.
<evarlast> release early release often is great, but BZR has been meeting our needs since 1.0.
<jelmer> spiv, any chance of having the smart server support upgrade for 1.7?
<Peng_> evarlast: Sure, but pushing the release back constantly to support large new features isn't very good.
<dato> Peng_: and how many times has that been done in bzr?
<spiv> jelmer: there's a patch on the list for that, so that probably will happen.
<spiv> jelmer: I should say it will happen, I just don't want to cram yet another thing into 1.6 :)
<meteoroid> if there are no branches or tags, only a trunk/, for an svn repo, will that fudge up the recognition of branching pattern of an svn-import ?
<jelmer> spiv: W00t, hadn't seen that one :-)
<jelmer> spiv, It would be nice to have that in 1.6 actually now that it has started whining when branches are in an old format
 * meteoroid wonders if there are ebuilds for 1.6
<jelmer> meteoroid, that should work fine
<meteoroid> jelmer: phew, i get so tired of creating empty branches and tags when svn cp will (i think) create them
<meteoroid> i read somewhere that rename doesnt work when performed in bzr and pushed to svn, is that true? anything i should be sure to do from svn instead of bzr?
<Peng_> dato: Hmm, 0.15 was in the RC stage for a month.
<meteoroid> i am basically using bzr as much as i can to interface with these tortoise users ;d
<spiv> jelmer: by "support" I just mean "works over vfs operations" rather than "performs the upgrade server-side".
<jelmer> meteoroid, no, rename works fine
<meteoroid> awesome
<jelmer> meteoroid, renames done from svn aren't pulled into bzr ok
<meteoroid> oh, really?
<jelmer> meteoroid, since svn doesn't support proper renames
<meteoroid> what happens?
<jelmer> meteoroid, only copy + delete
<meteoroid> really? lame.
<meteoroid> bad svn
<jelmer> spiv: Ahh, ok
<jelmer> spiv: I was hoping for running it server-side
<meteoroid> so, i tried to follow the tutorial for setting up rw webdav for my bzr repos, but when i start apache, i get: Unknown DAV provider: filesystem
<meteoroid> glad to post the virtualhost in question
<meteoroid> using ubuntu hardy - maybe i only have dav_svn, and not dav_normal ?
<meteoroid> cant find a package indicative of such support..
<markh> jelmer: what does the numeric 2nd argument in a SubversionException indicate?
<markh> an svn error code?
<jelmer> markh: Yep
 * markh tries grepping...
<jelmer> markh: What error code are you seeing?
<markh> 175002 pulling the python trunk - but only after a long time, so its possible it was transient.  I'm retrying now
<markh> retrieving revision 462 or 40113 now - it will be a while if it works :)
<markh> of
<meteoroid> jelmer: what does renaming in svn do to the bzr copy?
<jelmer> markh, 175002 is SVN_RA_DAV_ERROR IIRC
<jelmer> markh, In other words "Something went wrong talking webdav"
<jelmer> meteoroid: Renaming in svn basically means the file appearing to be deleted and readded under a different name in bzr
<markh> thanks - I'll see how the new attempt goes.  But at around 1 revision every 2 seconds, it will be many many hours :(
<jelmer> you may want to obtain a local copy of the svn repo
<markh> or just pick a smaller one - it seemed a convenient one to test :)
<pollelu> hello
<pollelu> i have a big problem with bzr
<pollelu> pollelu@confino:~/rapache-icons$ bzr push lp:~rapache-devel/rapache/design
<pollelu> Agent admitted failure to sign using the key.
<pollelu> Permission denied (publickey).
<pollelu> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
<pollelu> pollelu@confino:~/rapache-icons$
<pollelu> some idea?
<james_w> Agent admitted failure to sign using the key.
<james_w> you are on Intrepid?
<pollelu> yes
<james_w> that's a problem with gnome-keyring and/or seahorse
<pollelu> Im working in intrepid
<james_w> running "ssh-add" should fix it
<pollelu> ok thanks
<pollelu> thanks Master of BZR, my problem is now solved :)
<meteoroid> jelmer: ok not a big problem just ugly change history and loss of ancestry :/
<jelmer> meteoroid, yep
<jelmer> meteoroid, hopefully bzr will support file copies at some point
<jelmer> lifeless, wecanhas pathtokens?
 * meteoroid hopes with his crossed fingers
<gambler> Verterok, did u end up releasing that new version?
<Verterok> gambler: Hi, I'm struggling with a concurrency bug...
<Verterok> so, not yet...but trying to get this fixed so it can be "usable"
<gambler> Verterok, ok no rush, let me know when to test
<Verterok> gambler: sure, thanks!
<gambler> :S
<Verterok> gambler: I'll try to (at least) seed a "unofficial" build  ;)
<gambler> no rush :)
<Odd_Bloke> jml: Thanks for the review. :D  I've scanned through it and will sit down and deal with it properly tomorrow.
<lifeless> beautiful : http://www.etsy.com/view_listing.php?listing_id=12792904
<markh> Sorry for the length :)  I'm a little confused about merging.  I've 2 branches, one a pristine copy of the upstream branch (.dev), and another .work branch, branched from the local .dev branch.  The branches diverged for a while, but as the changes landed upstream, and therefore in the .dev branch, all were merged successfully and the branches now appear identical.  However, every time I attempt to re-pull .work from .dev, it fails telling 
<lifeless> markh: has your local branch been fully merged by bzr.dev?
<lifeless> markh: bzr missing will tell you
<markh> lifeless: ah, no - it says I have 3 extra ones.
<markh> but they are all merges :)
<markh> It says I'm missing 4, but I think they are the ones I'm yet to merge-commit from .dev.  (The branches in question are actually bzr-svn ones)
<lifeless> so if you only have extra merges; you can pull --overwrite
<markh> ah - right - and that well "re-converge" them?
<markh> will
<lifeless> it will discard your extra commits
<markh> by "extra" you mean the merges I had to make?
<jml> Odd_Bloke: my pleasure.
<lifeless> markh: yes
<markh> I guess its conceptual - help for '--overwrite' tells me it will let me forget local changes - but from my POV I don't have any local changes - the branches seem "identical".  So once branches have diverged, --overwrite is the only way to "reconverge" them?
<lifeless> markh: or to have your branch merged into bzr.dev
<lifeless> markh: an older version of your branch was merged; but you have made subsequent changes that were not merged
<lifeless> markh: when you do 'commit' you are recording a change
<markh> yeah, or changes that were tweaked etc before being applied
<spiv> markh: "changes" is perhaps a confusing term.  There can changes to content, but there can also be different revision histories without having different content.  If you don't care about the history differences (and it sounds like you don't, given that they are just trivial merges), then you can use --overwrite to replace your branch with a copy of trunk.
<markh> yeah, I understand now, thanks.  It seemed like I was forever doomed to merge/commit cycles on that branch which seemed insane :)
<markh> spiv: yeah, casual reading made me assume it was simply a shortcut for reverting changes before pulling
<igc> hi all
<spiv> igc: hey!
<spiv> igc: how's it going?
<igc> pong lifeless
<markh> lifeless: thanks for the explanation
<igc> hi spiv
<markh> igc: hi
<igc> hi markh
<igc> spiv: not so good this week
<spiv> markh: generally I just wouldn't be keeping branches with no content differences in the first place, though.
<spiv> markh: thus I never find myself making pointless merge commits that I want to throw away :)
<markh> spiv: well, although the branches are currently identical, there is a good chance other work will be done, so keeping that .work branch around made sense
<spiv> igc: I feared as much, you haven't been around much. :(
<lifeless> so --overwrite says ignore differences
<markh> igc: that's no good :(  You able to keep distracted?
<lifeless> I think it should be more precise
<lifeless> igc: :(
<igc> markh: well I'm sleeping almost continuously
<igc> I need to head up to the hospital for my daily visit in 15-20 minutes but I thought I'd quickly say hi and skim my 100s of emails before then
<spiv> igc: we're good at producing emails :)
<igc> markh: did your changes to setup.py get merged yet?
<markh> yuck - i hope you can stay positive
<igc> markh: I volunteered to merge it after tweaks
<markh> igc: not yet, I haven't got back to reworking that patch yet.  I saw that - thanks!
<igc> markh: just checking you weren't waiting on me
<markh> nope - thanks - I'll let you know when I am ;)
<sommer> hey all, I've borked the logs of an LP bzr branch by making changes to a local branch, then merging from lp, then commiting the merge, and finally pushing the changes
<markh> igc: its not actually a real priority for me to be honest, especially while it appears I will be making the binaries themselves anyway.  It wouldn't surprise me to find other tweaks necessary before a 1.6 final...
<sommer> should I have done a pull instead of merge?
<sommer> is there a way to restore the logs?
 * markh lunches...
<igc> markh: np
<sommer> apologies if this isn't the correct place to ask
<spiv> sommer: this is the right place
<spiv> sommer: which branch?  in what way is it borked?
<sommer> spiv: https://code.edge.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-intrepid
<sommer> spiv: basically I overwrote the commit messages of another
<sommer> spiv: happened in revision 62: http://bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-intrepid/revision/62
<sommer> it's happened before, but I couldn't find the steps to correct it
<spiv> sommer: I'm not sure what you mean by "overwrote".  Are you referring to the revisions by Matthew East visible at http://bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-intrepid/changes?start_revid=59.1.6 ?
<sommer> spiv: yes, that's what I mean
<sommer> spiv: I guess not really overwritten, but if the main branch had them it would be better :)
<sommer> well I guess they're still there, but the revision number was at something like 67
<spiv> sommer: so, the history is correct.  The problem is just that the display of revisions at bazaar.launchpad.net isn't as good as it should be.
<sommer> spiv: yes, is there a way to correct that?
<spiv> sommer: the revision numbers are specific to a particular branch.  When you merge changes from another branch the history will change.
<spiv> mwhudson: ^ ping?
<spiv> mwhudson: what happened to showing the authors of merged revisions in loggerhead?
<sommer> spiv: right, do other projects just use the new revision number then?  or is there a preferred way to sync rev numbers?
<spiv> sommer: why do you care about revision numbers?
<sommer> spiv: to be honest, *I* don't, but my guess is others may
<spiv> sommer: or do you just care about giving credit to the right person?
<sommer> spiv: credit is good to
<mwhudson> olckS brydcbi-o p.annf jdabi.o yd.p.
<mwhudson> :)
 * igc lunch
<mwhudson> spiv: so nothing's really changed there
<mwhudson> spiv: it's been talked about, is all
<spiv> mwhudson: I'm sure I saw a beautiful mockup at some point :)
<spiv> mwhudson: ETA for the feature?
<spiv> sommer: so, to credit the right person, mainly what needs to happen is that Launchpad should be displaying better information in this situation.
<spiv> sommer: i.e. it sounds like you're doing everything just fine.
<sommer> spiv: cool, I guess I just wanted to make sure, thanks man
<spiv> sommer: optionally though, next time you could do "bzr commit --author='A. Nother Person'" when committing a merge, I think that will cause existing Launchpad (and "bzr log", etc) to primarily show that rather than you.
<mwhudson> spiv: depends on tuit supply
<mwhudson> spiv: you mean this sort of thing? http://people.ubuntu.com/~mwh/hacked_up_changelog_view_3.png
<spiv> sommer: (the fact that you committed the revision is still recorded, it just also adds an extra property saying that you say the author is someone else)
<mwhudson> spiv: or the one that displays a list of committer names where only one name is displayed now?
<mwhudson> anyway, sprinting
<spiv> mwhudson: right.
<spiv> mwhudson: So, +1 from me for doing that one sooner rather than later, FWIW
<spiv> (which isn't very much, most likely...)
<mwhudson> spiv: it's probably not that hard for a seasoned bzr hacker!
<spiv> Heh.
<lifeless> we should add a ui to set append_revisions_only
<lifeless> or perhaps make that the default for 'bzr init'
<lifeless> or something
<mwhudson> does that prevent uncommit?
<mwhudson> option "dont_let_user_accidentally_oush_over_non_lh_parent" true
<lifeless> mwhudson: it does, but we could teach uncommit to ask about overriding it
<beuno> is it expected that if I run bzr status from outside the branch's dir, the doesn't show the pending merges?
<beuno> Verterok just bumped into that, and we think it's a bug
<beuno> mwhudson, I've been eyeballing bug #240542, but I'm not sure what the idea is for start/stop-loggerhead scripts.  I get the feeling you want to nuke em
<ubottu> Launchpad bug 240542 in loggerhead "Provide a description for nesting urls" [Undecided,Confirmed] https://launchpad.net/bugs/240542
<mwhudson> beuno: i think i want to ignore them for a while, then delete them
<mwhudson> beuno: but i can probably be persuaded otherwise
<lifeless> beuno: you mean 'bzr st foo' where foo is a tree?
<beuno> mwhudson, I've been thinking about persuading you, but I have less and less reasons to
<beuno> lifeless, yeap
<beuno> mwhudson, I do want some sort of global config at some point, but we may want to use serve-branches, and wherever we place it
<mwhudson> beuno: right, yes, the no-config-at-all approach that serve-branches had clearly isn't going to work in the long term
<beuno> mwhudson, ok, I'll un-target that bug, if I find out how
<lifeless> confirmed
<lifeless> its a bug
<beuno> Verterok, you won a bug report
<lifeless> beuno: Verterok: please file a bug; high importance
<Verterok> lifeless: ok, thanks for confirming it
<beuno> lifeless, re: bug #248018
<ubottu> Launchpad bug 248018 in loggerhead/1.6 "slow search results override fast ones" [High,Confirmed] https://launchpad.net/bugs/248018
<lifeless> yes!
<lifeless> pls fix
<beuno> I'm thinking about ignoring the you if you type one letter
<beuno> in addition to fixing the bug
<lifeless> hmm
<lifeless> btw
<lifeless> the 200ms thing confuses people
<lifeless> can I suggest just requesting at each keystroke
<beuno> hm
<lifeless> as long as the best search array so far is whats shown it will be correct, and it give people a hint
<beuno> I don't think the server will like getting hit so many times
<beuno> if I take away the timer, then every single keystrole will get sent
<beuno> I'm pretty sure that's not a good idea
<lifeless> ok
<lifeless> well let me describe what I see people do
<lifeless> they type in a search very quickly
<lifeless> and hit enter
<lifeless> they never even realise it can do completion because they don't pause long enough
<lifeless> so its not discoverable
<beuno> that's not necessarily a bad thing, if they already know so exactly what they want, it makes sense for the find-as-you type to be ignored, no?
<lifeless> not when I'm showing people bling
<beuno> I do agree it's not very discoverable
<beuno> hahah
<beuno> ok, we can have a special show-off edition
<lifeless> even more cool would be word-completing as they type
<beuno> no timer, and a cube like compiz
<lifeless> com|mit
<lifeless> with the | being where the insertion cursor is, and mit being pulled from the completion results
<beuno> ah, that would be cool
<lifeless> (this is where completion for exclusion terms is still useful btw)
<spiv> Even if you don't fire off a query, showing the autocomplete box with a dim "(autocompleting...)" or something in it might be good for discoverability.
<lifeless> (and this is why I'm saying 200ms is _way_ too long)
<lifeless> as I type a term in...
<spiv> so "rapid-type-then-hit-enter" still works, but at least the user gets a signal about the possibility of doing it a different way in the mean time.
<lifeless> all the results are contained in the first response recieved from the search engine
<lifeless> the more they type the smaller the response set is all
<lifeless> when we start doing ranking
<beuno> spiv, that's already sort of the case. It says "loading" when you start typing
<lifeless> and doing clipping
<lifeless> then that may change
<lifeless> beuno: no it doesn't
<lifeless> beuno: it says it when you pause, at least for me
<spiv> For bonus cool: preload the page the with the first N autocompletes for each letter of the alphabet, so you can give instant results!
<Verterok> beuno, lifeless: done,  Bug #255204
<lifeless> spiv: indeed, that needs ranking though
<ubottu> Launchpad bug 255204 in bzr "bzr status doesn't show pending merges when executed outside the branch dir" [Undecided,New] https://launchpad.net/bugs/255204
<beuno> lifeless, ah, you're right, it doesn't.  It should.
<spiv> lifeless: well, the ranking could be "the order I plucked these out of the db" ;)
<lifeless> beuno: anyhow, what I'd *like* is that when I start typing it does in-field completion of the first entry in the completion results
<beuno> lifeless, I need to handle sessions to be able to contain and trim results before sending the response
<spiv> lifeless: and the complete results could be retrieved after the 200ms timer or something, if you want that.
<lifeless> spiv: it is today, but thats not so useful :)
<spiv> Ranking strikes me as an orthogonal issue.
<lifeless> beuno: I don't really care about *how* it does this, just that that is what I would like to give our users.
<spiv> But an important one for making search useful, I agree :)
<lifeless> beuno: if that sounds nice, we can move on to talking about *how*
<beuno> lifeless, in-field completion would be cool. Not sure how I would do that with javascript, but I can't think of a reason it wouldn't work
<beuno> lifeless, it does
<beuno> I'd really prefer doing clipping on the server side
<lifeless> beuno: yes, me too
<beuno> rather than dropping requests on the cliente side
<beuno> hm
<lifeless> beuno: erm, terminology :)
<lifeless> dropping requests is needed because of async nature of the beast
<lifeless> clipping is about sending less than the full set of results because, or ordering whats sent so that partially-recieved data is maximally useful
 * spiv enfoodinates.
<beuno> lifeless, agreed. The interaction needs a lot of work to be impressive
<lifeless> spiv: I think ranking is technically orthogonal but not user-experience orthogonal
<lifeless> beuno: as a thought experiment, whats wrong with requesting on each keystroke?
<lifeless> in broad terms
<beuno> lifeless, the server performing one search per character
<lifeless> beuno: thats all ?
<beuno> lifeless, yeap, it waists tons of resources
<beuno> imagine that on Launchpad
<lifeless> beuno: it will be fine :)
<lifeless> beuno: so, without being silly
<lifeless> lets imagine you dedicate a thread to the client
<lifeless> they ask for ('a',)
<lifeless> you start a search for completions
<lifeless> they ask for ('ab',)
<lifeless> you cancel the first search and start a search for completions for ('ab',)
<lifeless> etc
<lifeless> at some point your searches complete faster than their requests come in, and they get completions happening
<beuno> lifeless, that works fine. The thing is, we currently don't handle sessions in LH, so I can't really do that today
<beuno> as to remember who requested what, on the server side
<lifeless> beuno: I'm not sure it needs sessions but I'll defer that to you
<beuno> I could fake sessions, I guess...
<lifeless> in fact, all it really needs is a nonce per completion-interaction - the same thing sent in every completion request
<beuno> and that would solve both our concerns
<beuno> hrm
<lifeless> but thats just me being tricky and pointing out that generic sessions are >>> what this needs
<beuno> that plus inline completion would be magic
<lifeless> plus arrow down to other completion results
<lifeless> plus ranking
<beuno> plus number of results
<beuno> plus color depending on the depth of the history
<beuno> or type of result returned
<lifeless> well completions are interesting, because they are not looking at documents, only terms - most terms I think will show up in most document types eventually
<lifeless> but sure
<beuno> you could be looking for a committer's name
<lifeless> http://gadgetopia.com/autosuggest/
<lifeless> that does mouse-into-the-completion-widget
<beuno> ah, you can go down with your arrow keys
<lifeless> thought its buggy
<lifeless> yours is better about handling typing and deletion etc
<beuno> yeah, it's not very polished
<lifeless> but I thought you might like to see their code (LGPL!) for the arrow support
<beuno> lifeless, I do, thanks. I can use parts of that
<beuno> good thing is, as it stands now, I should be starting full time with Canonical con monday, so I'll have plenty of time to dive into this  :p
<lifeless> congrats
<lifeless> thats been rather submarine news :)
<beuno> hahah
<beuno> yeah, it's not 100% official yet, so no blog post, yadadada, but we worked the remaining issued out today and set a startinf date
<poolie> hi beuno
<lifeless> very very cool cool
<beuno> and thanks, I'm excited
<beuno> hey poolie
<lifeless> I wonder if flash is needed to do what we want
<beuno> god no
<beuno> we can do this with javascript, just need to bend the rules a little bit
<beuno> please let's not go anywhere near flash  :)
<thumper> beuno: so what are you going to be focusing on most for canonical?
<beuno> thumper, it's a bit blurry ATM, but mainly UI on most canonical projects. And, loggerhead  :)
<thumper> beuno: cool
<thumper> beuno: loggerhead needs some memory love
<beuno> thumper, yeah, I already have something in the works to work around the "too many changed files" issue
<beuno> ajax to the rescue
<thumper> I wasn't aware of the issue
<thumper> I just know that loggerhead chews up memory
<thumper> when run for a while
<beuno> thumper, it times out on some requests
<beuno> see bug #254892
<ubottu> Launchpad bug 254892 in launchpad-bazaar "Cannot view r2704 of ~mysql/mysql-server/mysql-4.1" [Undecided,New] https://launchpad.net/bugs/254892
<beuno> of course, we have to do some profiling to find out where the memory hog is today
<beuno> a *lot* has changed in the past few months
<mwhudson> iooh right
<mwhudson> beuno: so on the files listing
<mwhudson> the revnos link to a 'filtered by fileid' view
<mwhudson> beuno: this is not good for performance
<beuno> mwhudson, ah, right, and doesn't really *do* anything, does it?
<mwhudson> not really
<mwhudson> feel like fixing it? :)
<beuno> mwhudson, sure, easy fix.  Just link to the revno.  I can do that now
<mwhudson> ta :)
<beuno> mwhudson, committed!D
<mwhudson> :)
<markh> does canonical employ/engage a graphic artist by any chance?
<beuno> markh, talk to Joey Stanford, we do graphic work for Canonical
<markh> beuno: is that work gratis?  Or do I first need to speak to someone from canonical to approve it? :)
<lifeless> markh: what do you need?
<beuno> markh, canonical, approve
<markh> The windows icon needs lovin, and we need a tortoise ;)
<lifeless> a pissing chinese tortoise?
<beuno> markh, just an icon?
<lifeless> beuno: tbzr
<markh> and a tortoise ;)  But yeah, the couple of existing bzr icons are fairly poor quality and needs transparency plus anti-aliasing etc
 * beuno looks for the current icon
<markh> the .pngs are good, but nothing seems to do an excellent job at converting them to all the various icon sizes and depths
<beuno> markh, for little amount of work, I can trick someone into doing it for free. For something bigger, you'll need to get approval, etc
<markh> there is an icon checked into bzr.dev - it lacks transparency and when you try and add it, lack of anti-aliasing shows up
<markh> The icon at http://bazaar-vcs.org/LogoOptions is transparent, but looks auto converted and is poor at larger sizes, eg Vista
<markh> oops - actually I don't think it is transparent.  Higher color depth IIRC - but neither are really that great.
<markh> and don't forget the tortoise ;)
<beuno> markh, so, you need a large transparent bzr png, and a tortoise icon for tbzr?
<markh> I blew an hour in visual studio etc, but gave up in disgust as usually happens when I try anything like that
<beuno> markh, http://bazaar-vcs.org/LogoOptions?action=AttachFile&do=get&target=Bazaar+Logo+2006-07-27.svg   is an svg (scales to the infinity) with transparent background
<beuno> what's wrong with that again?
<markh> beuno: a single .ico file can have a large number of actual icon images.  The existing bzr .png files are good, but I'm having trouble getting a single .ico file, with 4 different icon sizes in that file, with high-quality versions of the .png
<markh> (and depending on how many colors are actually used in the logo, the perfect world would probably have multiple color depths of each of the 4 sizes.)
<beuno> markh, so, if you can tell me the the sizes that you need, I can get those 4 PNGs done
<markh> the png files are even the desired size.  Its more a matter of the edges of each image needing touching up.  A picture is worth a thousand words - what is your email address?
<beuno> I have no idea how to create a windows icon though
<beuno> markh, argentina@gmail.com
<lifeless> btw
<lifeless> I've been meaning to say kudos to getting that email addy ;)
<markh> right - whoever we suckered^h^h^h^h^h^hbegged into doing this would need access to a .ico editor.
<beuno> lifeless, I got an invitation the first day it launched. "beuno" is 5 chars, so no-go, and "martin" was taken by one of the devs.  "argentina" seemed like the next "I won't get that later on" choice  :)
<markh> beuno: to be clear, I've already got access to .png files in the desired sizes - just converting them to a transparent windows icon is the issue.
<markh> every process I've tried requires touching up in the icon editor, which is where I tend to make things worse
<beuno> markh, ah, ok. So a little bit trickier then I thought.  I think only one of the gfx people at work have windows.  I'd have to check with them if they know how to do it  :)
<markh> beuno: thanks, it would be great if you could
<beuno> markh, I'll give it a try tomorrow. Did you send that email?  that'll serve me as a reminder  :)
<markh> putting it together now - thanks!
<beuno> markh, np. And include whatever you can think of for the tortoise icon, I will try and get something done with that too
<beuno> I kinda want a new icon for LH too, but asking for 2 tortoises for 2 different projects may be a bit odd
<markh> :)
<beuno> markh, do you currently have an icon?
<markh> yeah, I'll send what I have
<beuno> cool, thanks
<lifeless> poolie: ping
<poolie> pong
<lifeless> up for a short brainstorm?
<lifeless> two topics, marks and dirstate-locks
<poolie> hm
<poolie> maybe later?
<lifeless> tomorrow then
<poolie> btw, i read the auto-add thing and i'd agree people could reasonably want them to be separate
<lifeless> I started at 5am :)
<poolie> silly twisted boy
<lifeless> I think there is an argument for them being separable, but there is also a cost
<lifeless> the status quo is that we have hard to explain behaviour
<lifeless> whatever we do should make it easier to explain
<poolie> lifeless,  did you make a 1.6 branch?
<poolie> could you please?
<lifeless> garh, lynne came and said hi as I got off the phone
<lifeless> doing now
<lifeless> done
<poolie> thanks
<lifeless> jelmer: what does AOL mean ?
<poolie> "me too"
<lifeless> k
<lifeless> I actually have a thought that we should auto-add-delete by default
<lifeless> following the line of thought of requiring users to do as little as possible by default
<poolie> after the habit (when aol was new to the internet)
<poolie> of their users flooding a thread with "me too" top-posts
<abentley> lifeless: I think that setting is particularly poor, and making it default wouldn't satisfy those who like auto-remove or those who dislike it.
<lifeless> abentley: I think that it should be set to the most commonly given value; I don't know what is right now
<lifeless> default on is easy to explain ('by default we record everything in your tree, no explicit action needed'), and default-off is easy to explain ('by default we record what you have asked us to record')
<lifeless> default-partly-on is hard to explain and ultimately why that bug was filed in the first place
<abentley> lifeless: Well, no-auto-anything is relatively safe.  I don't like it, but I long ago gave up trying to understand why people wanted it.
<abentley> lifeless: Auto-everything will cause stuff to be committed that shouldn't be committed, and will cause mvs to be mishandled as add + delete pairs.  I consider this actively harmful.
<lifeless> I can't quite parse that; do you mean that most heuristics have problems of some sort?
<abentley> Auto-everything will cause stuff to be committed that shouldn't be committed.  Because people will leave stuff in their source tree that they don't intend to commit, and then commit.
<lifeless> abentley: auto-remove causes things to be committed that should be [deletes, not user content] and also has the same problem with add+delete pairs (people reach for add first when they see a delete)
<abentley> lifeless: Do you mean "should *not* be"?
<lifeless> yes
<abentley> lifeless: I don't consider auto-deletion to be as dangerous as auto-addition.  Nuclear launch codes.  Nuclear waste.  ISO images.
<abentley> Auto-deletion is easy to repair.
<lifeless> uncommit isn't sufficient?
 * fullermd agrees.
<abentley> Auto-addition can require garbage-collecting your repo.
<lifeless> so, if I write 'uncommit --gc'?
<abentley> I don't agree that auto-remove has the same problem with mv.  It has a problem, but it is different.
<poolie> abentley, what kind of thing do you have in your tree?
<fullermd> If I miss something long enough to commit it, I'm likely to miss it a lot longer, so it's more than GC, it's GC'ing many repos, and other people's code based on it.
<abentley> poolie: The things in my tree that I don't want to commit are typically patches or callgrind files.  Sometimes they're .orig files.
<fullermd> I've got run logs in my trees all the time.
<poolie> mm
<fullermd> (whatever >& out   and the like)
<poolie> i wonder if this really means we should be marking them ignored?
<abentley> lifeless: uncommit --gc would be nice, but wouldn't make me think that auto-add was a good idea.
<poolie> i do often have diffs in there but i also think this is a bit dirty
<abentley> lifeless: Anyhow, auto-all is a default that I would fight against.  I wouldn't fight against auto-nothing, if I can unbreak my own configuration.
<lifeless> abentley: ok. I have replied to the thread breaking the changes down to atoms to be discussed
<lifeless> the default in the current patch is indeed auto-nothing, because its a more conservative default
<abentley> poolie: It is a bit dirty, but that's what clean-tree's for :-)
<poolie> mm
<poolie> it seems like that almost needs an arch-like concept of patterns of cruft
<poolie> maybe that belongs in a makefile though
<lifeless> there is a seperate thread on that
<lifeless> well, on precious vs ignored
<lifeless> anyhow, I've said my bit - IMO we're more complex than we should be, and we can be simpler by a number of different possible changes
<lifeless> I think the most enjoyable to use would probably be the most risky :). [see havoc penningtons unbreakme option rant]
<lifeless> but I'm not going to push for that today; having the option available is enough of a positive for me today
<lifeless> bbiab
<lifeless> back
<lifeless> RAOF_: ping
<lifeless> markh: ping
<markh> lifeless: hi
<lifeless> whats your opinion about using glib routines in bzr (in terms of windows portability)
<lifeless> (not glibC, glib - the gnome/gtk+/gimp low level support library)
<markh> I've no direct experience, but I'd be surprised to find msvc works regularly.  I guess it depends on what aspect of portability you are concerned with :)
<lifeless> http://www.gimp.org/~tml/gimp/win32/downloads.html
<lifeless> actually
<lifeless> http://www.gtk.org/download-windows.html
<lifeless> markh: I'm looking at writing some pure C
<lifeless> markh: binding that to python separately
<lifeless> and so I want tool chain you'll be happy supporting for windows builds :)
<markh> heh - so this is the same thing bzr-gtk needs to bundle?
<lifeless> e.g. I'm thinking scons as a build system. Not because its good, but because its better than autoconf etc on windows
<markh> err - bundle on windows I guess.
<markh> its likely autoconf wouldn't really be needed on windows and that a hard-coded makefile would be ok.  There isn't much to "sniff" on Windows
<markh> isn't there a native alternative to whatever it is you are trying to do? :)
<matkor> Hi ! If I did bzr "lightweight" checkout of -r l_rev  and later bzr upgrade to u_rev, I will be able to browse history see diffs etc in range of revisions from l_rev to u_rev ?
<lifeless> markh: yes, but guido doesn't want CPython to be fast at the expense of clarity
<lifeless> matkor: are you asking if bzr remembers what l_rev was for you ?
<fullermd> You probably could, if update supported -r...
<matkor> lifeless: I am asking if after after bzr update to u_rev I get no history (it still lightweight checkout) I get part of history (l_rev to u_rev) or full history (0..u_rev) is downloaded
<poolie> abentley, so from your last mail it looks like it will be ok as long as auto-add is not the default?
<fullermd> Well, you can't bzr update to u_rev.  But if you could, it would presumably do the former (i.e., much the same as if you'd co'd that rev in the first place)
<abentley> poolie: I will be okay if --auto-remove exists and --auto-add is not the default.
<abentley> And if --auto-remove causes Bazaar to behave the way it does now wrt --strict.
<poolie> and would auto-remove as an option to commit be much different to having it available under bzr rm?
<lifeless> matkor: no history is downloaded locally
<RAOF_> lifeless: pong?
<abentley> poolie: yes.  It would be more work and destroy your original vision of how rm could work.
<lifeless> RAOF_: do you do much C ?
<poolie> test
<poolie> test
<RAOF_> lifeless: Not much.  I'm not totally unfamiliar with it, though.
<RAOF_> Much more C# and python.
<abentley> poolie: I don't know how else to say this.  I don't understand why anyone would want no-auto-anything behavior.  I think auto-remove is perfect.  It has been the default for many years.  If it can't remain the default, there should be a way for everyone who is used to it and likes it to preserve it.
<lifeless> abentley: I don't know why you say it would destroy martins' original vision of bzr rm
<lifeless> could you enlarge on that ?
<abentley> lifeless: martin's original vision was that bzr branches could be manipulated as much as possible using standard unix commands.  cp -r would perform a branch.  rm would delete a file.
<lifeless> ah, of 'rm' not of 'bzr rm'
<abentley> mv would move a branch.
<lifeless> following that logic I would expect touch to add a file
<abentley> lifeless: I don't think that was seriously contemplated at the baz 1.0 sprint.
<lifeless> abentley: I don't recally rm being automatic being discussed at that sprint either - but it was a long time ago now
<abentley> That's certainly how I remember it.  May not be true, of course.
<poolie> well
<poolie> that was what i had in mind
<RAOF_> lifeless: Why were you interested in my Cness?
<poolie> however, the current situation of auto-remove but not auto add is inconsistent with it
<lifeless> RAOF_: I'm checking the impact of C support libraries on e.g. gnome and kde friendliness
<lifeless> RAOF_: and windows
<lifeless> RAOF_: as I'm planning on doing some C soon but I'm out of date on what libraries are broadly available where.
<RAOF_> I understand that glib is both ported everywhere and can make C less of a hassle.
<lifeless> which reminds me
<lifeless> fullermd: ^ sameish questions :)
<lifeless> RAOF_: its more a culture-of-availability than raw can-do that I'm referring to
<lifeless> if e.g. KDE would turn their nose up at a glib using library
<RAOF_> But apart from that, I'm not really up with the library situation, particularly on !gnome.
<lifeless> yah I'm going to ask riddell too
<RAOF_> lifeless: Nah, they wouldn't.
<fullermd> Well, I don't know anything about the Windows side.  But I can't imagine lower-level stuff like glib could matter gnome-vs-kde-vs-whatever.
<RAOF_> fullermd: It's got a 'g' in it!
<lifeless> and
<fullermd> Heck, I run neither gnome nor KDE, but I've got qt and gtk apps around and working...
<fullermd> gWindows?   :p
<lifeless> does glib play nice inprocess with kde, for kde apps using this library :P
<RAOF_> I'm pretty sure the answer to that is a firm "yes".
<RAOF_> I'm sure there's glib/QT mainloop integration somewhere.
<markh> c++ can make C less hassle too ;)
<lifeless> markh: yes, but at the cost of being less accessible from C
<lifeless> so there are several reasons I want to write some plain C
<lifeless> one is profiling - its easier to gprof a small C test driver than all of python
<lifeless> another is addressing some of the [somewhat spurious] complaints from hard-core devs that bzr is not written in a language they feel comfortable in
<lifeless> another is making it a bit easier for folk that are doing LPC calls to be able to get at the core logic
 * fullermd acks.
<fullermd> I'm assuming you mean something different by 'LPC' than I think of...
<lifeless> local procedure calls
<fullermd> Too bad.  I was getting all sorts of twisted evil grins at the thought of accessing bzrlib from LPC...
<luks> lifeless: you know that Qt and so also KDE is linked to glib by default, right?
<luks> so I don't think glib is a problem for anybody on linux
<lifeless> luks: I didn't, cool
<luks> it uses glib's mainloop
<Bronger> Is my observation correct that Bazaar merges without warning into an out-of-date working tree?
<poolie> Bronger: no, it shouldn't
<Bronger> Okay, then I'll have a closer look at it again.
<luks> there is one case where is does, 'bzr up', no?
<poolie> well
<poolie> what specifically do you mean by 'merges'
<poolie> if you do an update or pull it will merge into what you have outstanding in the tree
<poolie> 'merge' itself should not without --force afaik
<Bronger> The scenario was as follows: Everything local on my disk, in a repo.  Some branches with working trees, and one lightweight checkout that I "switch" between the working trees.  I work only on teh checkout, so all branches become out of date over time.  But I have to merge the trees from time to time.  So I entered one branch, did "merge ../<other-branch>", no errors, no conflicts.  Then, I did "bzr update", and I got further changes and conflicts.
<lifeless> right, update is what did that to you
<lifeless> which is actually by design, so tht you can merge to a branch which someone else just committed to
<Bronger> Okay, thank you.  Does the order matter?  Is merge+update the same as update+merge?
<luks> Bronger: just to make sure, you did 'bzr commit' after 'bzr merge'?
<Bronger> No.
<luks> and merge printed 'Nothing to do' or it did merge something?
<Bronger> It did something.
<luks> right, so the pending merges were what causes the problems with bzr update
<Bronger> Yes.
<luks> I'm not sure but I think 'bzr merge' followed by 'bzr merge --force' would cause the same problem
<luks> 'bzr update' is very similar to 'bzr merge' in this case
<lifeless> Bronger: the order does matter
<lifeless> Bronger: update + merge - the merge would complain
<Bronger> The root cause of my questions here is that I found out that a new part of code got lost.  Apparently, during a 3-way marge, the *older* part was used.  I could recover it, however, I'd like to know whether it can be caused by forgetting to say "update" before a merge, or whether I just resolved a conflict wrongly (which may well be the case ;-).
<lifeless> Bronger: 3-way chooses the odd-side out, if both sides are different it conflicts
<luks> Bronger: hm, you had local changes in the working tree? otherwise there is nothing to lose
<luks> generally, to merge the branches and keep the working tree updated you want: 'bzr merge <something>', 'bzr commit' to commit the merge, 'bzr update' to update the working tree
<Bronger> There could be local changes, too.  But in case of those, Bazaar sure would complain, either by conflicts or by an error message, wouldn't it?
<luks> not in case of update
<luks> update is designer to work with modifications in working tree
<luks> merge would complain though
<Bronger> So if I update, remote changes silently overwrite my local changes?
<luks> no, it will try to merge them
<Bronger> Okay.
<luks> which can naturally result in conflicts
<Bronger> Well, then I think I just resolved the conflicts incorrectly.
<Bronger> Good. Thanks to all of you!
<poolie> you're welcome
<james_w> hey poolie
<poolie> hi james
* poolie changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | please test 1.6rc1! /  http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | http://blogs.mysql.com/kaj/2008/06/19/version-control-thanks-bitkeeper-welcome-bazaar/
<poolie> woo
<james_w> woo indeed
<awilkins> Whee, shiny new hardware.
<lifeless> awilkins: :)
<jelmer> lifeless: AOL for America Online
<jelmer> lifeless, their users used to be known for their one-line "me too" postings on usenet
<dwt> jelmer: What is the best way to send patches for bzr-svn to you?
<jelmer> dwt, just "bzr send" them to me
<dwt> Well..., that bombs...
<dwt> bzr stable:1557/> send
<dwt> Cannot lock LockDir(http://people.samba.org/bzr/jelmer/bzr-svn/stable/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
 * dwt is off reading send help
<mib_20juap6b> I'm trying to use bzr-svn for local versioning before commiting back to a subversion server
<mib_20juap6b> The team require files being worked to be locked on the subversion server
<mib_20juap6b> I've tried bzr co on both a subversion checkout and repository
<jelmer> dwt: Alternatively, you can send me the patch generated by "bzr send -o foo.patch"
<dwt> jelmer: Well I tried that already, same error
<jelmer> dwt, did you perhaps create a checkout of bzr-svn rather than a regular cloned branch?
<mib_20juap6b> In both cases running 'svn lock' on files that needed to be locked caused errors when I tried to commit back from bazaar
<mib_20juap6b> Is my desired way of working not possible with bazaar?
<dwt> jelmer: Yes - as far as I remember, you advised me to do that last time we chatted.
<dwt> (My memory may be wrong though)
<jelmer> That would surprise me, there shouldn't be a particular reason to create a bound branch if you don't have write acess to the master branch
<jelmer> dwt, "bzr send" will work if you "bzr unbind" your branch I think
<dwt> jelmer: Thx, I'l try that
<jelmer> mib_20juap6b, I'm not sure what you're after exactly
<jelmer> mib_20juap6b, should bzr-svn attempt to unlock files before doing a commit?
<mib_20juap6b> mib_20juap6b: No the files must stay locked on the subversion server since that is our policy for version control
<mib_20juap6b> I would like bzr to act as a client and allow me subversioning before I commit back
 * AfC misses SCCS too
<dwt> jelmer: strange thing, bzr unbind fails with the same error
<Necoro> hmm ... bzr help send tells me, that the default format is "4" -- but just doing a "bzr send" showed me, that it is 0.9 instead
<mib_20juap6b> Ie: Subversion -> bzr shared repository (lock files)
<Necoro> oh - nevermind
 * Necoro should learn to read
<mib_20juap6b> bzr shared repo -> my feature repo
<AfC> mib_20juap6b: if you require obscure Subversion features like the one you are describing, I imagine you're not going to be able to use bzr-svn.
<AfC> mib_20juap6b: That said, there is no reason you can't create a bzr branch in-place in a Subversion checkout and then just bzr to manage the files you are manipulating.
<AfC> mib_20juap6b: low tech, to be sure, but it can work well enough.
<mib_20juap6b> mib_20juap6b: I tried bzr branch subversion-checkout new-bzr-branch
<mib_20juap6b> But when I tried to commit back from new-bzr-branch it complained about the locked files
<jelmer> mib_20juap6b: bzr-svn doesn't touch locks at the moment
<jelmer> dwt: That sounds like a bug
<jelmer> dwt, alternatively, you can try removing "master_branch = ..." from .bzr/branch/branch.conf
<jelmer> mib_20juap6b, is not touching the locks not sufficient?
<dwt> jelmer: I'l try that - but I'd like to try to reduce the bug first.
<mib_20juap6b> mib_20juap6b: Maybe I am confused
<mib_20juap6b> mib_20juap6b: I created the branch from the svn checkout directory and commited to it
<mib_xfynoqbr> mib_xfynoqbr: How do I commit back to the subversion checkout?
<AfC> mib_xfynoqbr: svn commit?
<mib_xfynoqbr> I used bzr branch to create the branch. So what bzr command can commit back again?
<AfC> mib_xfynoqbr: or, if your question is how do I move changes from one Bazaar branch to another (where the second just happens to also be a Subversion checkout), then `bzr pull ../other` is perhaps what you are looking for.
<mib_xfynoqbr> AfC: That might be it. Let me try...
<mib_xfynoqbr> "No revisions to pull"
<mib_xfynoqbr> And bzr push subversion-checkout complains about the locked file!
<mib_xfynoqbr> In subversion a lock only has meaning for the repository and those interacting with it since it is centralised
<jelmer> mib_xfynoqbr: what command did you use to create the bzr branch? bzr checkout or bzr branch?
<mib_xfynoqbr> So maybe I found a bug in bzr-svn?
<mib_xfynoqbr> I tried both. This time I just did a branch.
<jelmer> mib_xfynoqbr, if you used "bzr checkout", just running "bzr commit" should commit back to svn
<jelmer> if you used "bzr branch", run "bzr commit" and then "bzr push"
<jelmer> mib_xfynoqbr, what sort of error are you getting?
<mib_xfynoqbr> jelmer: I tried both as you described
<jelmer> mib_xfynoqbr, what's not working exactly?
<mib_xfynoqbr> mib_xfynoqbr: SubversionException("Cannot verify lock on path '/hello'; no matching lock-token available"
<mib_xfynoqbr> mib_xfynoqbr: On the commit or push back
<jelmer> mib_xfynoqbr, ah, so it's the lock that's problematic
<jelmer> mib_xfynoqbr, The svn lock tokens aren't stored anywhere in bzr though
<jelmer> mib_xfynoqbr, so I can't think of an easy way to fix this
<splodge> \part
<mib_xfynoqbr> I have just discovered that checkout does not work since if yuo give bzr a subversion checkout directory it actually works on the corresponding subversion repository
<jelmer> mib_xfynoqbr, that's what it's meant to do
<dwt> jelmer: There is no such file ".bzr/branch/branch.conf" the only thing I could find is .bzr/branch/location" which holds just the url
<dwt> jelmer: should I just remove that fileÃ
<dwt> ?
<jelmer> dwt: hmm, that's odd
<jelmer> dwt, are you working in a lightweight checkout by any chance?
<dwt> I guess so
<jelmer> how did you manage to commit your change?
<dwt> well, I didn't
<jelmer> ah, ok
<jelmer> you may want to use "bzr reconfigure" to convert the lightweight checkout into a full-fledged branch
<dwt> aha! :) I'l try that
<jelmer> after that, you should be able to commit your change and bzr send
<pfeil> Hi, I need help with hook programming for bzr.
<jelmer> hi pfeil
<pfeil> Can anyone help me - I am new to phyton.
<jelmer> pfeil, sure, just ask your question
<dwt> jelmer: From reading the docs "bzr reconfigure --branch" seems to be the most sensible thing
<pfeil> I need a start_commit hook that runs a shell command for every file that will be commited
<pfeil> should be simple but I hve no phyton knowledge
<abentley> jelmer: it's not so strange to create a bound branch when you don't have write access to the master branch.  This creates a local mirror that you can't commit to by accident.
<abentley> dwt: bzr reconfigure --tree
<jelmer> abentley, bzr can behave strangely in that situation though (error messages that don't make sense to users) so I don't tend to recommend it
<dwt> abentley: thanks!
<jelmer> abentley, I agree there is a use case for it though
<abentley> jelmer: Sounds like we need to make it give better diagnostics, then.
<jelmer> abentley, yes, indeed
<pfeil> The questin is: can anybody help me with my problem or point me to some example code I can learn from?
<jelmer> pfeil, there was some example code for a start_commit hook posted to the list recently
<jelmer> pfeil, http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/45041/focus=45042
<pfeil> jelmer: Thanks for the hit, I will read into the material...
<dwt> abentley: Sorry to say, but 'reconfigure --tree' bombs for me with: bzr: ERROR: Repository KnitPackRepository('file:///Users/dwt/.bazaar/plugins/svn/.bzr/repository/') is not compatible with repository KnitPackRepository('http://people.samba.org/bzr/jelmer/bzr-svn/.bzr/repository/')
<dwt> abentley: am I doing something wrong?
<james_w> dwt: there's a bug open on that I believe
<dwt> damn. :-)
<abentley> dwt: No, you've hit a corner case.
<james_w> you are using a rich-root repo I guess
<dwt> james_w:
<dwt> I have no idea... :)
<james_w> yeah, it's bzr-svn
<dwt> Well, not really
<dwt> its a pure bzr checkout
<dwt> so bzr-svn can't have a thing to do with this
<jelmer> bzr-svn itself is in rich-root-pack as well
<abentley> jelmer: btw, I had to stop Bundle Buggy from scanning bzr-stats, because it uses a rich-root repo.
<jelmer> dwt, for now, it's probably easiest to just save your patch somewhere and create a fresh copy of the branch
<jelmer> abentley, ah, ok :-(
<dwt> jeah, I was just about to propose that too.
<dwt> thanks for the help
<dwt> though
<ahasenack> hi guys, will there be a bzr 1.5.0 for hardy on bzr's ppa? The other distros have it
<james_w> If I want to retrieve a non standard value from a non-standard section of ~/.bazaar/bazaar.conf do I have to resort to accessing the file with ConfigObj directly?
<dwt> jelmer: after a lot of work... the patch is on it's way. whoa how hard sending a patch can be.
<pfeil> jelmer: Thanks for the hint, I have read the thread and I am running into a similar problem like my precessor:
<pfeil> jelmer: I have installed bzr 1.5 on a Mac
<james_w> dwt: unbinding a lightweight checkout shouldn't be possible as it doesn't make any sense to have a standalone working tree
<james_w> well, it may make sense, but it's not allowed as far as I know
<pfeil> jelmer: When I enter bzr hooks, I get a list of hooks - all "<no hooks installed>". The interesting thing is: There is no start_commit hook listed in the list. Any glue?
<dwt> james_w: Well, I'm not yet firm with what works how in bzr and why, so at least the error message was not at all helpfull
<james_w> dwt: that's true
<dwt> At the time my understanding was that unbind would magically make me a lcoal repository to work with - whatever the previous condition was.
<dwt> I now recognize that there are two completely different concepts in bzr
<dwt> and that a lightwight-checkout is more like a svn checkout
<dwt> that can never (at least not as easily) become it's own repo
<dwt> oh well.
<dwt> bzr is hard. You know that?
<luks> it's hard if you try to use it the svn way
<dwt> luks:  I thought that this was one of the strengths of bzr?
<dwt> ok, cu guys in an hour
<pfeil> Can someone help me then the mutabletree class?
<pfeil> Can someone help me with the mutabletree class?
<luks> pfeil: somebody probably can, even if not right now
<luks> but it helps if you ask the question
<pfeil> luks: Thanks - Just whantet to see if there is someone active here.
<pfeil> luks: I am completely new to python and I need to write a start_comit hook stat runs a shell command for every file that will be commited.
<pfeil> luks: Now I have a working hook skeleton and I know how to run shell commands, My remaining problem is to interate throug all the files
<pfeil> luks: I get a mutabletree as parameter for the hook. I dont know the internal stuctures or the internal concepts of bzr so this is quite a problem for me to get it done quick.
<james_w> pfeil: you have your hook being triggered now?
<pfeil> Should be working, I will try....
<pfeil> Is there something wrong with this line? print "clearing exec bits in " + base
<luks> depends on what is base
<luks> `print "clearing exec bits in", base` would be more universal
<pfeil> Do I need to import something for print?
<luks> no
<pfeil> Ok, this is how it looks like:
<pfeil> def start_commit_hook( tree ):
<pfeil>      config = LocationConfig(tree.basedir) 																		# unsure if this is right
<pfeil>      base = tree.basedir 	
<pfeil>  
<pfeil> 		 #print "clearing exec bits in " + base
<pfeil> I am wondering where basedir is coming from because I could not find it in the class description
<pfeil> is: ' base = "Hallo there" ' valid python?
<luks> starting with one space is usually not valid python
<luks> apart from that, yes
<jelmer> dwt, hmm, not seeing your patch yet
<jelmer> rockstar, ping
<pfeil> Ok, I have removed the spaces, now my hook is working.
<pfeil> The main problem remains, how to iterate throu the tree and execute a shell command on all the files that will be comitted?
<pickscrapeX> pfeil: I went though this recently
<pickscrapeX> Are you getting a tree_delta parameter?
<pickscrapeX> That's proably your mutable tree parameter... Anyway, it has a number of attributes like added, modified, renamed etc that are lists of tuples
<pickscrapeX> If you iterate through those and print out the tuples you'll see what the elements are (filename, file-id, type etc).
<pfeil> pickscraperx: I am sorry, I am new to phyton and I am afraid that what you are talking about is out of my knowledge scope.
<pfeil> pickscraperx: I can only understand and modify python code, not more :-(
<pickscrape> Hmm, didn't know my nick was still wrong :)
<pickscrape> What exactly is it that you are wanting to do with the files that will be committed?
<pfeil> os.system("build++ --minor++ " + filename )
<james_w> pfeil: you can run that on all modified and added files, would that suit you?
<pfeil> Yes :-)
<james_w> jelmer: is there a way to get the specific changes that are being committed in a start_commit hook, or is it that the MutableTree is already those specific changes, and differs from the changes in the working tree if specific files were requested?
<jelmer> james_w: the specific_files list doesn't get specified to start_commit at the moment
<jelmer> it should, though
<james_w> yeah
<james_w> pfeil: if all modified and added files works for you then you want something like
<james_w> changes = tree.changes_from(tree.basis_tree())
<james_w> for path_info in changes.added:
<pfeil> what type is changes here?
<james_w>      path = path_info
<pfeil> sorry
<james_w>      # do something with path
<james_w> for path_info in changes.modified:
<james_w>     path = path_info[0]
<james_w>      # do something with path
<james_w> .
<james_w> the first "path = path_info" should be "path = path_info[0]", same as the second
<pfeil> got it, will try now...
<cjwatson> lifeless: any more luck with bug 246880?
<ubottu> Launchpad bug 246880 in bzr "ghost fetch issue: fail when fetching a text referenced by a live revision introduced by a ghost revision" [High,Triaged] https://launchpad.net/bugs/246880
<cjwatson> or anything more I need to add there?
<pfeil> Ok, thanks james_w for your help, but the code is not exactly what I need. Perhaps I have expressed my self not correctly:
<pfeil> Here is what I need:
<pfeil> When I enter: bzr commit -m "Test" test.file
<pfeil> I want bzr to run build++ [more options] test.file befor any other 'versioning' work is done by bzr.
<pfeil> You code runns throu all modfied files in the tree, not only the test.file.
<james_w> <james_w> pfeil: you can run that on all modified and added files, would that suit you?
<james_w> <pfeil> Yes :-)
<james_w> maybe I wasn't clear, that's the best you can do from one of these hooks currently
<pfeil> james_w: This was a missunderstanding on my side. I thought you are talking about: "...all modified and added files (that where specified on the command line)..."
<awilkins> jelmer: SVN locks are advisories anyway, no? You can just tell the server you are stealing them.
<awilkins> Although that might be a little cavalier where they are being used :-)
<jelmer> awilkins, yep
<james_w> pfeil: no, *all* modified and added files, sorry
<jelmer> awilkins, they also work only on files, you can't lock a directory recursively
<awilkins> THey are a pain in the butt from my perspective
<awilkins> ESp. the thing where someone locks a file then deletes it ; the lock is left hanging around
<awilkins> And you can't rename or delete the parent folder, or create another file with the same path
<pfeil> james_w: So you mean, that there is no way to find out which file the user specified on the command line and run a shell script only on this file?
<james_w> pfeil: not currently, no
<pfeil> james_w: ...and what if I use an other hook, pre_commit for example?
<james_w> you can't modify the tree being commited from them I believe
<awilkins> Can't you modify it in start_commit?
<james_w> yes
<jelmer> pfeil, this is just start_commit missing an argument
<pfeil> What could stop me from modifying the files on the disk in the pre_commit hook? I dont want to modify the internal bzr tree.
<pfeil> jelmer: What do you mean, Have I made a mistake or do you mean that there is some feature missing?
<jelmer> pfeil, There is a feature missing
<jelmer> pfeil, start_commit should not just receive a tree but also a list of files specified for commit
<pfeil> jelmer: I see...
<pfeil> Any other idea how to count up an internal revision number the cvs old school style?
<fog> hi. we have a problem with bzr+ssh using a common group to allow writes. the first time a new branch is pushed the permissions of the directories are 755 instead of 775. that's my mask but can't we have bzr to "clone" the permissions of the repo directory? I have to fix them by hand every time someone pushes a new branch in the repo.
<fbond> Okay, so if I use commit --fixes foo:X, how can I now display bugs fixed by revision Y?
<beuno> fog, maybe related to bug #255155?
<ubottu> Launchpad bug 255155 in bzr "bzr.dev no longer preserves permissions in repository" [Critical,Confirmed] https://launchpad.net/bugs/255155
<james_w> fbond: that's not possible from the command line yet
<james_w> fbond: I think bzr-gtk can do it
<fbond> james_w: So what use is --fixes then? :)
<dwt> jelmer: I sent the patch to jelmer@samba.org
<jelmer> dwt, just got it - thanks!
<jelmer> dwt: Patch looks good, I've merged it
<fog> doh, it is a bug then.
<fog> thanks.
<beuno> fog, sorry  :)
<fog> but I use 1.5, not .dev.. mm.
<beuno> fog, on both sides?
<fog> 1.5 on the client and 1.3.1 on the server
<fog> mm.. time to upgrade that server :)
<dwt> I'd love to debug the second problem that plagues my bzr-svn installation now
<jelmer> dwt, what's that?
<dwt> But I'm currently hanging on understanding how bzr maps its namespace into the plugin directory
<dwt> jelmer: the problem is that it cannot resolve bzrlib.plugins.svn to ~/.bzr/plugins/svn - or at least it seams that way
<james_w> dwt: ~/.bazaar/plugins/svn
<dwt> sorry, thats what I mean
<dwt> or meant, anyway
<james_w> what's the problem you are seeing?
<dwt> james_w: When I try bzr selftest svn, it can't load the svn plugin
<dwt> because it can't resolve the imports to bzrlib.plugins.svn, as being in the directory ~/.bazaar/plugins/svn
<dwt> here's a paste of the problem
<dwt> http://paste.lisp.org/display/64873
<cjwatson> dwt: it works the other way round; bzr imports everything under ~/.bazaar/plugins/ and stashes them in the right places in its namespace
<luks> dwt: if can't import it, because the plugin itself fails
<luks> see ImportError: cannot import name client
<dwt> hm, how can I debug this further?
<luks> do you have client.so or client.py in ~/.bazaar/plugins/svn?
<james_w> dwt: are you on bzr 1.6?
<dwt> luks: yes, client.so
<dwt> james_w: no, I'm on bzr 1.5
<luks> that looks strange then
<james_w> dwt: ok, please paste the whole of one of the stanzas of ~/.bzr.log showing the failure to load the plugin
<luks> dwt: oh, perhaps it's built with a different version of python?
<dwt> you mean the *.so files?
<luks> yes
<dwt> luks: I'l check that after I pasted the errors from loaading the plugin
<dwt> james_w: http://paste.lisp.org/display/64878
<james_w> AttributeError: 'module' object has no attribute 'properties_handler_registry'
<james_w> you are using a version of bzr-svn that is not compatible with bzr 1.5
<dwt> damn.
<dwt> And I was extra carefull to take the stable branch
<dwt> jelmer: Can you tell me which branch would be the right one to get for bzr 1.5?
<jelmer> dwt, there's no branch matching bzr 1.5
<jelmer> dwt, you can use the tarball from the wiki page
<dwt> ok...
<dwt> I'l try that
<jelmer> dwt, or revert back to tag:bzr-svn-0.4.10 in your current bzr-svn branch
<dwt> That sounds much better
<dwt> thanks
<dwt> jelmer: As far as I can tell at that revision you are still using the official python bindings
<jelmer> dwt: Yes, that's correct
<dwt> Too bad, I really wanted to give your bindings a spin.
<jelmer> dwt: You can still try, with bzr.dev
<dwt> I'm a bit weary going to the trunk of bzr
<dwt> I really want to give this plugin a workount
<dwt> with first trying to replicate my workplace conditions
<Peng_> bzr.dev is kept pretty stable.
<dwt> and then trying to switch my workplace
<dwt> but for that I really need stable versions that many people have tested already.
<luks> well, 1.6rc1 is out
<dwt> luks: I am considering just waiting a week or two till it is out.
<luks> not that is has been tested by as many people as 1.5, but at least you have a tarball
<dwt> true
<dwt> Well, after going back to tag:bzr-svn-0.4.10 and making the plugin
<dwt> it seems to load perfectly
<dwt> however running bzr selftest svn dies on the ninth test
<dwt> jelmer: Does it make sense to look into this further
<dwt> or should I just wait for bzr 1.6?
<jelmer> dwt, what sort of version of subversion do you have installed?
<dwt> 1.5
<jelmer> dwt, I guess I would wait for 1.6
<jelmer> (bzr 1.6)
<dwt> sure
<dwt> ok, I'l check back in here as soon as 1.6 hits my repository. :)
<dwt> ok, thanks for the help and cu soon!
<evanton> I'm getting an error when running "make docs" inside the unpacked source tarball of bzr-1.5
<evanton> http://pastebin.com/m762ada0c
<jam> evanton: weird, I'm not seeing that here
<jam> I wonder if it is a different version of rst2html
<jam> evanton: ah, I think this is the rst2hmtl bug we had a workaround for
<jam> specifically there is a '.' in the options
<jam> which rst doesn't usually like
<jam> if you look at our tools/rst2html.py
<jam> there is a workaround in there
<jam> but it is keyed on version
<jam> evanton: you probably just need to expand the version range
<jam> evanton: there should be a line like: if docutils.__version__ <= '0.4.1':
<jam> Just change that to "if True:" or something like that
<evanton> jam: do you want me to tell you the version of docutils I'm using?
<jam> evanton: you can, but I'm 99% sure it is >0.4.1
<jam> :)
<evanton> hold on
<jam> I think we have a fix for that in the 1.6 branch
<jam> In bzr.dev the line is "if True: # this is still required in the distutils trunk as-at June 2008."
<evanton> $ rst2html.py --version
<evanton> rst2html.py (Docutils 0.5 [snapshot 2008-04-24, r5542], Python 2.5.1, on linux2)
<jam> evanton: so... yeah, just a problem with our workaround not being used for newer docutils, you can edit that line and it should work
<jam> And 1.6 will have a fix for it
<evanton> as I can see from the error, "make docs" is calling the rst2html.py that's included in the source tarball of bzr
<evanton> let me try your suggestion
<jam> evanton: we call that one, because of workarounds, etc that we needed to put in
<jam> it shouldn't be calling the global rst2html
<evanton> jam: seems like html files were generated, thanks for your help
<evanton> now it complains about not finding dot, so it's time to google for that :)
<evanton> will be back if will have any other questions
<dato> evanton: dot is shipped with graphviz
<evanton> suggestion: sticking the keyword "graphwiz" into that error message could help a newbie figure out what dot is, since googling for "dot" is irrelevant
<evanton> dato: than's I've found it, will look at graphwiz now
<evanton> s/than's/thanks, /
<Jc2k> 'wg 20
<radix> evanton: it's "graphviz" not "graphwiz"
<evanton> oh
<evanton> I've misspelled it
<rockstar> jelmer, hi
<jelmer> rockstar, hi
<rockstar> Could we chat about loggerhead's packaging needs?
<jelmer> rockstar, yep, sounds good
<jelmer> rockstar: afaik the only thing missing for a stock loggerhead package at the moment is loading the configuration from another location
<rockstar> jelmer, yea.  That would allow it to run daemonized.
<rockstar> However, thumper was telling me that ./serve-branches knows about user dir traversal, and the start-loggerhead script apparently doesn't
<rockstar> I thought I might take a look at that.
<pickscrape> Where can  I find documentation for the template language that loggerhead uses?
<rockstar> pickscrape, the template engine is simpletal
<pickscrape> This one? http://www.owlfish.com/software/simpleTAL/
<Peng_> pickscrape: Yep.
<jelmer> rockstar, ah, cool
<jelmer> I guess the package could also use a init script
<pickscrape> Ah, I think I see... I've been reading it wrong :)
<rockstar> jelmer, we could just leverage the work from start-loggerhead and stop-loggerhead for init scripts
<rockstar> I also have a default config that we'd like to load on installation and start of the server
<asabil> is it possible to make a branch redirect to another branch ?
<Peng_> asabil: There are "branch references", but there's no way to create them through the CLI.
<asabil> hmm, ok
<rockstar> jelmer, do you have time to look into loading the configuration from another location?
<jelmer> rockstar: Yeah, that'd make sense
<wingo-tp> good afternoon!
<luks> good evening!
<wingo-tp> i come begging, hat in hand: lifeless, can you have a look at bug #239499?
<ubottu> Launchpad bug 239499 in bzr "corrupt knit index on an old arch-imported bzr repo" [Medium,Confirmed] https://launchpad.net/bugs/239499
 * wingo-tp <- this guy is a drag, i know
<rockstar> wingo-tp, lifeless won't stir for another hour at least
<jelmer> beuno, ping
<jelmer> rockstar: I've added arguments to override the log folder, config file and pid file for loggerhead
<jelmer> as well as an init script
<beuno> jelmer, pong
<jelmer> beuno: is there some place where loggerhead logs when in daemon mode?
<jelmer> I had syntax errors but they didn't appear to be logged anywhere
<beuno> jelmer, it tries to create a logs/ dir
<beuno> and there should be a debug.log
<beuno> of course, it does so in the same dir, which won't work well with an installation
<beuno> we should change that
<beuno> (make it log in the home dir maybe, ~/.loggerhead.log
<beuno> mwhudson, thoughts?
<james_w> somewhere under /var/log would be better if it's running as a daemon I think
<beuno> james_w, I agree that's the ideal place, but won't we run into potention permission issues?
<beuno> I'm not sure how all that works
<beuno> AFAIK a regular user can't write in /var/log
<james_w> if it's using an init script the you can create /var/log/loggerhead/ and chmod it, as the init script is running as root
<james_w> or do it at package installation time
<james_w> if loggerhead has a normal daemon mode then home dir may be a good idea, with a command line switch to specify somewhere else
<wingo-tp> rockstar: ok, i'll pounce on him then :)
<beuno> james_w, yeah, it has both. So maybe a switch will work best.  jelmer?
<jelmer> beuno, Just did the patch :-)
<jelmer> beuno, I see what I was doing wrong now
<jelmer> I had actually caused a syntax error in the code that dealt with the logging
<beuno> jelmer, oh, very cool
<beuno> ah, right
<jelmer> https://code.edge.launchpad.net/~jelmer/loggerhead/pathargs/+merge/662
 * beuno branches
<beuno> jelmer, revision 202 thanks you for your continued contribution  :)
<jelmer> beuno, w00t, thanks!
<rockstar> beuno, jelmer, the package at least should log to /var/log/loggerhead or something like that
<jelmer> rockstar, Yeah, I've modified them to do that
<jelmer> rockstar, that's why I added the -L option
<rockstar> Ah.
<jelmer> beuno, You seem to've missed a revision
<jelmer> one that fixes the syntax errors
<beuno> jelmer, odd, I branched and merged
<beuno> jelmer, revno?
<jelmer> beuno, 205
<jelmer> it's there in the original location, perhaps lp jsut didn't mirror it yet
<jelmer> http://people.samba.org/bzr/jelmer/loggerhead/pathargs
<beuno> jelmer, updated
<jelmer> beuno, thanks!
<beuno> jelmer, thank *you*  :)
<jelmer> beuno, while you're here...
<jelmer>     from loggerhead import release
<jelmer> ImportError: cannot import name release
<jelmer> it still worked in my own tree because I had the .pyc file around
<jelmer> but the .py file appears to be gone
<beuno> that's still around?
 * beuno greps
<beuno> I thought I ahd removed it
<jelmer> it's in start-loggerhead
<jelmer> and stop-loggerhead
<beuno> removed, committing
<jelmer> beuno: release is still used
<jelmer> start-loggerhead line 82
<jelmer> rockstar, beuno: other than that, the debian package seems to work fine now
<jelmer> (configuration file in /etc/loggerhead.conf, logs in /var/log/loggerhead, init script in /etc/init.d/loggerhead)
<rockstar> jelmer, The one thing we still need is for the daemon to understand userdir branches.
<rockstar> I'm still trying to figure out exactly what that means.
<rockstar> Ah, nevermind, it's quite obvious...  :)
<beuno> jelmer, hrm...  did you merge trunk before working on that branch?
<jelmer> beuno, yeah
<beuno> I should stop drinking during the day then, I would of sworn I removed all of those
<rockstar> beuno, start off by drinking less.
<beuno> rockstar, right, one step at a time..
<rockstar> :)
<beuno> jelmer, removed those too, grep promised me that iw as the last of em
<beuno> s/iw/it
<beuno> see, I can't even type anymore
<jelmer> :-)
<pickscrape> Is it easy to remove a branch that was accidentally pushed over the top of a shared repository?
<pickscrape> It is confusing loggerhead :)
<beuno> pickscrape, just deleting it will do it. Revision will remain in the shared repo though
<beuno> won't be a problem, just take up space
<pickscrape> Delete ~/.bzr/branch ?
<pickscrape> I mean the branch was pushed *to* the shared repo directory, not under it.
<james_w> yeah, make sure to get the "branch" bit :-)
<pickscrape> :)
<pickscrape> I'll try renaming it first
<pickscrape> Worked a treat, thanks!
<jelmer> rockstar, beuno: http://revu.ubuntuwire.com/details.py?package=loggerhead
<beuno> jelmer, you're going to *kill* me
<beuno> but I just landed a fix that makes it work with pre-bzr 1.6b3 versions
<beuno> which should probably be in it, since hardy has 1.3
<beuno> jelmer, and, w00t!
<beuno> jelmer, you're still lacking DD's to sponsor uploads, right?
<jelmer> beuno, yes
<beuno> jelmer, I'll forc^ask again today
<mwhudson> hm
<jelmer> beuno, at the moment for bzr-upload, loggerhead and bzr-search
<mwhudson> is the scanner wedged again? :(
<beuno> mwhudson, it is  :/
<jelmer> beuno, Another bzr-upload upload would be nice
<mwhudson> oh for fuck's sake
<james_w> beuno: did you ever get to play with "upload --auto"?
<beuno> jelmer, ok, so anything that has to do with me  :p    I'm meeting with the DD today, so I'll presure enough
<jelmer> ah, cool
<jelmer> beuno, are you @ debconf?
<beuno> james_w, I handed it out to the user needing it, and haven't heard cursing, so I assume everything went ok  :)
<james_w> beuno: cool :-)
<beuno> jelmer, I'm not.  Starting with Canonical full time on monday, so that derrailed my plans a bit
<jelmer> beuno, ah, cool, didn't know that :-)
<jelmer> beuno, Congrats on your new job :-)
<beuno> jelmer, heh, thanks. I'll make it "official" tomorrow, just did the formal bits today, so I haven't made it too public
<beuno> it's been a rumor for a while not though  :p
<beuno> james_w, if everything goes as planned, we're going to be using bzr-upload at the office *much* more heavily, so it should get more love soon
<james_w> beuno: cool
<james_w> hey, congratulations beuno
<beuno> james_w, thanks!  I'm excited to get started
<beuno> mwhudson, btw, is there anyway you can set LH's permissions to public by default?
<TheEric> how do you get BZR to push new files? e.g. images in an image directory?
<beuno> TheEric, you first have to version them with:  bzr add
<beuno> note that bzr add will add everything unversioned
<beuno> if you only want a specific dir,  bzr add directory/
<beuno> then, commit them
<beuno> and push
<jelmer> beuno, Hmm, loggerhead only supports local urls atm?
<alex-weej> how do i undo a commit?
<alex-weej> i used the wrong commit message
<alex-weej> damn you -m !
<beuno> alex-weej, bzr uncommit
<Jc2k> alex-weej: bzr uncommit
<Jc2k> :)
<beuno> jelmer, local branches?
<jelmer> beuno, yeah
<alex-weej> thanks :)
<alex-weej> hi Jc2k :D
<beuno> jelmer, did you update the bzr-upload package, or is it the same?
<jelmer> beuno, it's the same
<beuno> jelmer, IIRC, mwhudson uses http in LP for branches
<jelmer> beuno, something went wrong during the upload
<jelmer> beuno, ah, cool
<jelmer> beuno, I was trying with SVN urls but that seems to cause weird errors while scanning for branches
<beuno> jelmer, yes, I'll sit down with her and do it together so nothing goes wrong  :)
<TheEric> ah, excellent. I should've thought of the add bit.
<Jc2k> hi alex-weej :P
<jelmer> beuno, ah, it looks like it's the auto_publish_folder stuff that doesn't appear to work with remote urls
<mwhudson> beuno: need an lp admin to do that; i think it's a good idea though
<beuno> jelmer, the official policy is to eventually remove start/stop-loggerhead scripts, so that may be ery low priority
<rockstar> beuno, why's that?
<mwhudson> because loggerhead.conf is bonkers
<beuno> rockstar, we *will* provide a way to do all the current magic, but with serve-branches
<rockstar> beuno, ah, I see.  My concern is that it needs to run as a daemon.
<beuno> rockstar, absolutely, either serve-branches will be optionally work as a daemon, or we'll have a daemon script separately
<beuno> mwhudson, you may know this. Where can I find a branch with a NULL revision in it?  related to bug #254794
<ubottu> Launchpad bug 254794 in loggerhead "root directory view traceback" [High,Confirmed] https://launchpad.net/bugs/254794
<beuno> 5 bugs to go for 1.6 release  :)
<mwhudson> well
<mwhudson> all branches have null: in them, in some sense
<mwhudson> oh, maybe it's when you serve-branches in a directory that has a branch with no revisions at all in it?
<mwhudson> bzr init foo
<mwhudson> serve-branches .
 * beuno tries
<mwhudson> ?
<pickscrape> How do I find out from within a Command object's run() method if the user passed --verbose?
<mwhudson> beuno: yeah, seems like it
<beuno> mwhudson, I don't get a traceback, just No revisions!
<mwhudson> beuno: run serve-branches from the directory _containing_ the branch
<beuno> beuno@beuno-laptop:/tmp/test$ ~/bzr_devel/loggerhead/trunk/serve-branches .
<mwhudson> branch.repository.get_revision(branch.last_revision())
<mwhudson> isn't going to work in such a branch
<beuno> /tmp/test is the empty branch
<mwhudson> beuno: so run it from /tmp
<mwhudson> (i guess "containing" is ambiguous here :)
<beuno> mwhudson, same thing, No revisions
<beuno> oooh
<beuno> wait
<beuno> got it
<beuno> hm
<beuno> I get a different error though
<beuno> pickscrape, gets "ReservedId: Reserved revision-id {null:}"
<beuno> and I get "NoSuchRevision: KnitPackRepository('file:///tmp/test/.bzr/repository/') has no revision null:"
<pickscrape> I had a sysadmin whining about that one today, saying 'bzr is broken' :)
<mwhudson> i get the same as you
<mwhudson> bzr version differences?
<pickscrape> He hadn't read the email I'd sent out about it
<mwhudson> pickscrape: it's always much more likely to be loggerhead :)
<james_w> is vila on holiday?
<pickscrape> mwhudson: well, loggerhead doesn't have 12k+ unit tests does it :)
<mwhudson> pickscrape: no, and we should do something about that at some point
<mwhudson> (well, 12k would be overkill for LH, i think...)
<beuno> I'd love to focus on that in the next release cycle
<pickscrape> I've started writing tests for diffstat. It's interesting, and I think I've even found a bug in doing it.
<beuno> pickscrape, bug #254794 should be fixed now. Could you confirm it?
<ubottu> Launchpad bug 254794 in loggerhead "root directory view traceback" [High,Fix committed] https://launchpad.net/bugs/254794
<pickscrape> beuno: on it
<pickscrape> erm, how strange. I just tried to before updating to make sure I was checking properly and it's working now, which should be impossible...
<mwhudson> i guess the problem branch has a revision in it now
<pickscrape> Nope, it's still a plain directory
<pickscrape> I did update to r201 earlier today though. I wonder if that fixed my problem...
<beuno> pickscrape, it must have a dir with a .bzr in it
<beuno> with no revisions
<beuno> somewhere
<pickscrape> I just checked, definitely no .bzr
<beuno> pickscrape, in a directory inside the root one
<beuno> so you're at  /foo/bar
<beuno> where you used to get the error
<beuno> so /foo/bar/blah
<beuno> has an empty branch in it
<beuno> or it should
<mwhudson> beuno: try:except: is pretty evil
<beuno> and if it doesn't, it's still fixed, because I changed that part of the code  :)
<beuno> mwhudson, I know. But bzr 1.5/1.6 throw different exceptions
<mwhudson> though mind you, i put a try:except: around branch.open, so i can't really talk
<mwhudson> beuno: ugh
<beuno> and I didn't even want to dig into 1.4/1.3
<pickscrape> Aha, I think I know what it is. I asked earlier about deleting a ~/.bzr/branch directory that was accidentally pushed over a shared repository
<beuno> so I chose try: except:  rather than 4 different possible exceptions
<pickscrape> Now that it's removed, it's working.
<pickscrape> I'll update now and try
<beuno> mwhudson, but I'm open to doing it better if you can think of something  :)
<pickscrape> It still works
<beuno> pickscrape, great, thanks!
<beuno> I love instant feedback
<beuno> bzr users rock  :)
<pickscrape> Our sysadmin will be a happy chappy now :)
<beuno> I hate how unhelpful LH's logging is
<beuno> I wonder what it would take to make it resemble bzr's one...
<Peng_> Did you mean to change LH's <title>s from "some/branch : changes" to "/some/branch : changes"?
<beuno> no, whatever goes into debug.log
<beuno> WARNING:simpleTALES.Context:Exception occurred evaluating python path, exception: name 'url' is not defined
<beuno> I have *no* idea where that came from
<beuno> Peng_, re bug #247992
<ubottu> Launchpad bug 247992 in loggerhead "Visiting just "/download" or "/download/" redirects to a bad URL" [Undecided,New] https://launchpad.net/bugs/247992
<beuno> how is it that you end up in /download?
<Necoro> hmm ... by the way - is there sourcecode highlighting support for loggerhead?
<Necoro> and if yes: is there a reason, it isn't turned on LP?
<beuno> Necoro, nope. But there may be if you file a bug requesting it  :)
<Necoro> I'll do when I'm bored ;) ...
<beuno> good, I prefer exciting bugs
<beuno> :p
<Necoro> beuno: http://pygments.org/ =P
<beuno> Necoro, oh, did I mention we *love* patches?
<beuno> even boring ones!
<beuno> either way, we'd have to make it optional. I don't want to add another dependency for this
<Necoro> I hope, LH has some way of configuration =P
<beuno> oh, codescanner just came back from the dead
<Necoro> anyways ... time for bed ;) ... I'll see what I can do tomorrow ^^
 * beuno is off to a dinner
<lifeless> jam: if you want to talk reachability we could skype
<jam> lifeless: sure, though I don't have long before the standup, and we're going on a walk after that (I guess I could skip the standup today)
<lifeless> up to you - poolie said you were interested in what I'm thinking about is all
<igc> morning
#bzr 2008-08-07
<poolie> igc, spiv, jam, hi
<poolie> skype seems to be broken on my laptop now
<igc> hi poolie
<jam> poolie: I'm just chatting with lifeless for now, I'll probably skip the standup
<poolie> hello igc, how are you today?
<lifeless> hi poolie
<igc> poolie: not too bad today
<poolie> shall we just stand up here?
<spiv> Hello.
<poolie> for myself i was planning to make sure usertest is running in the datacentre (if it's not at present)
<poolie> and then look at the results for 1.6rc1 compared to previous ones
<poolie> oh and also update the ppa which i didn't finish yesterday
<spiv> Thinking of 1.6rc1... bzr.dev is now open for changes for 1.7?
<james_w> is usertest extended to history now?
<poolie> yes
<poolie> i should mail about that
<poolie> james_w, i don't think it does large amounts of history atm
<poolie> it should
<james_w> just wondered
<igc> today, I'm planning to catch up on email and add some more tests to my filtered views branch
<james_w> poolie: would you like 1.6rc1 in a distro?
<poolie> i may either add that, or run ad hoc tests on a long history
<poolie> many distros! :_)
<igc> james_w, poolie: if usertest finds a .bzr directory inside a project archive, it skips the initial import task
<james_w> igc: ah, cool.
<igc> so it will handle whatever history you have already setup
<spiv> Today I'm working on the 'effort' tests described in my email from yesterday.
<james_w> poolie: I'll see what I can do
<poolie> i should check if the ppa packaging has diverged from intrepid
<poolie> james_w:  what are you working on on the distro team btw?
<james_w> poolie: importing ubuntu in to bzr. I guess no VCS anywhere will have had this much code in it before
<poolie> wow
<poolie> that must be a lot
<james_w> I have tomorrow off though, so I can push 1.6rc1 to the archive, and possibly Debian as well
<james_w> poolie: fingers crossed for ~16k packages, ~4 years history of uploads
<james_w> sorry to divert your stand-up
<lifeless> james_w: :)
<lifeless> james_w: single repo ?
<james_w> lifeless: no
<james_w> maybe I lied then
<lifeless> cause I have that megarepo :P
<james_w> I'm pretty sure no DVCS will have that much code
<ToyKeeper> Wow.  I hope you've got plenty of space and time.
<lifeless> I suspect MS's internal repos are pretty big
<james_w> lifeless: sure, I'll sell that to the developers. To get started with development just download this 22G repo...
<lifeless> james_w: you can pull out of it in millisecond time :)
<james_w> lifeless: I should have mentioned the meeting to you, sorry
<lifeless> np
<thumper> what is the flag to bzr upgrade to do all the branches too?
<thumper> in a shared repo?
<Peng_> beuno: I think I ended up at /download just by messing with the URL to see what would happen.
<james_w> thumper: I don't think there is one. I may have missed it though
<james_w> thumper: but in most cases converting the repo is 90% of the work
<ToyKeeper> It may be 90% of bzr's work, but it's only one of many commands the user would need to run to convert the repo + branches.
<lifeless> dato: which reminds me; no chance on that mail yet I guess?
<james_w> ToyKeeper: oh yeah, I realise that
<dato> lifeless: nope, sorry; weekend is the safest bet
<lifeless> cool, I'll stop inquiring for a while then
<beuno> Peng_, so the bug is, if you punch in a random URL, it redirects you to a random place, which, in this case, doesn't work. Correct?
<Peng_> beuno: Yep. :)
<beuno> Peng_, marked as duplicate of "we don't validate user input", because I think that if we fix that, then we fix that bug.  Feel free to un-duplicate it if you feel differently
<Peng_> beuno: +0. Doing the redirect seems like an attempt to validate user input; it's just incorrect.
<Peng_> Err, does it incorrectly, I mean.
<beuno> yeah, although a pretty bad one I think
<beuno> hm
<beuno> I'm off to dinner, so I'll leave it to you to decide  :)
<Peng_> beuno: I unduped it.
<markh> jelmer: you have a moment for my daily bzr-svn on windows question?
<jelmer> markh, heh, sure
<markh> many of the bzr selftests are failing when bzr-svn is installed - notably the blackbox tests, which seem to be getting an exit code of 0 when they expect a failure code.  Is that known by you?
<markh> best I can tell, bzr is actually doing the right thing - just the exit codes are screwy
<jelmer> markh, they're failing when bzr-svn is installed and not otherwise?
<jelmer> what sort of errors?
<markh> yes (although I admit I've only disabled *all* plugins - others are bzrtools and qbzr)
<markh> simply that the 'bzr' exit code was zero instead of (say) 3
<jelmer> no strange messages in the output?
<markh> eg, blackbox.test_merge.TestMerge.test_merge_with_missing_file
<markh> nope
<jelmer> markh, hmm, that runs fine on linux
<markh>   File "bzrlib\tests\blackbox\test_merge.pyo", line 132, in test_merge_with_missing_file \nAssertionError: Unexpected return code\nnot equal:a = 1 \n b = 0
<markh> I was afraid you would say that :)
<markh> --noplugins makes it work fine for me.  My attempts at debugging have failed so far, but I was guessing that maybe bzr-svn *also* had a chance to handle the 'bzr merge' command being tested somehow...
<markh> I'll dig some more...
<markh> and it seems that all blackbox test which expect a non-zero exit code are failing
<markh> (the log does show the command being executed and, in this case, failing with conflicts.  So its strange but probably just a test issue)
<james_w> jelmer: how do you plan on handling bzr for Debian during the freeze?
<jelmer> james_w, haven't given it any thought yet
<jelmer> james_w, I guess we can just upload 1.6 & friends to sid since they won't propagate now
<jelmer> james_w, Not sure if there's a good reason for requesting a freeze exception
<jelmer> james_w, what do you think?
<Odd_Bloke> I'm not sure we'd want 1.6 in lenny anyways, as it's introducing quite a lot that might be unstable (ha ha).
<jelmer> well, 1.5 breaks with bzr.debian.org atm..
<james_w> jelmer: I thought maybe experimental
<james_w> and maybe fixing the 1.5 problem would be a good thing for a freeze exception
<jelmer> james_w, any particular reason for experimental rather than sid?
<jelmer> I'm finding that 1.6 works significantly better than 1.5 for me
<james_w> jelmer: I was under the impression that was preferred to leave the unstable->testing route open for targeted fixes
<james_w> perhaps we should ask the opinion of our tame release assistant tomorrow
 * dato waves
<jelmer> dato: hi :-)
<jelmer> dato: ^
<dato> the responsible thing is to upload to unstable; if I was still the maintainer, I would probably had uploaded to sid; but doing that probably reduces your chances of fixing "important" bugs, because it'd have to go through t-p-u
<dato> errrrrrrrrrrrrrrrr
<dato> the responsible thing is to upload to experimental, of course.
<lifeless> :)
<james_w> hey dato
<Odd_Bloke> Incidentally, I've started using bzr-builddeb for my packaging and it's great.  So thanks to people who wrote that. :)
<lifeless> poolie: btw, I want that brainstorm on marks :>
<jelmer> dato, thanks
 * dato goes to bed
<jelmer> Odd_Bloke: Please also set the Vcs-Bzr control field :-)
<Odd_Bloke> jelmer: I wasn't sure if that was meant to point to a bzr.debian.org location, which is the only reason I have yet to do so.
<Odd_Bloke> (because none of my packages are on bzr.debian.org (yet))
<jelmer> Odd_Bloke, no just any URL where your packaging can be found
<Odd_Bloke> Cool, I'll add it in.
<jelmer> Hmm, looks like bzr is the third vcs for debian atm, behind svn and git
<jelmer> although the distance between git and bzr is pretty big
<lifeless> I don't think it actually means a lot, though I'm sure people will think it does
<lifeless> a bunch of maintainers switched with a disproportionate package count
<wildfire> so, I accidently did 'bzr rm --keep .bzrignore' and then realised my mistake and did 'bzr add .bzrignore'
<wildfire> and now 'bzr status' says that .bzrignore is being both added and removed
<wildfire> normal? should I care?
<jelmer> lifeless, I think those numbers reflect reality
<jelmer> lifeless, The number of bzr users in Debian seems to've diminished greatly :-(
<lifeless> wildfire: normal, but you can do bzr revert .bzrignore to just reset it
<jelmer> s/in Debian/under DDs/
<wildfire> lifeless, ah-ha, thanks
<lifeless> wildfire: that will revert any content changes to the file too
 * wildfire hehs
<wildfire> yes, I just realised, it had a conflict reverting things
<cjwatson> wildfire: (it showed up as remove+add because the add operation gave it a new internal file-id)
<wildfire> and moved it all aside to .bzrignore.moved.
<lifeless> ah yes, because there is a file there:)
<lifeless> bzr rm .bzrignore.moved
<lifeless> bzr revert .bzrignore
<wildfire> lifeless, in my case I wanted those changes, so easy enough to fix-up
<lifeless> good good
<lifeless> poolie: ping
<poolie> poing
<poolie> ok, how about now?
<lifeless> cool
<Odd_Bloke> How do I send targetted at a one branch (i.e. the mainline) but generating a patch against another branch (a change on which my branch depends)?
<lifeless> Odd_Bloke: -r branch:dependent
<Odd_Bloke> lifeless: Thanks. :)
<lifeless> e.g. -r thread:..
 * pickscrape uploads loggerhead branch adding breadcrumb links
<mwhudson> ooo
 * AfC eats all the breadcrumbs, dipping some of them in hummus.
<pickscrape> Hopefuly it's any good. I've not done any python web development before.
<mwhudson> hm, maybe an a:hover of a different colour would be nice
<pickscrape> Yes, I can see that. Unfortunately I'm the last person you want to be picking colours :)
<pickscrape> Do you have one in mind?
<mwhudson> not really
<kiorky>    /B 3
<aquarius> I'm getting a weird error when trying to commit to my sftp repos: bzrlib.errors.KnitCorrupt: Knit None corrupt: incorrect number of lines 318 != 253 for version
<aquarius> I've filed it as a bug in launchpad (#254511) but, pending that being fixed, what can I do to make some forward progress? At the moment I can't commit at all :(
<meoblast001> oh no
<meoblast001> bzr: ERROR: Target directory "xeiso" already exists.
<meoblast001> what does that mean
<AfC> meoblast001: you're trying to do a new branch [or checkout]?
<meoblast001> lol i figured it out
<AfC> meoblast001: if so, I would guess that about 30 seconds ago you started doing such a thing, but then ^C aborted, and tried again.
<meoblast001> i deleted the file
<meoblast001> folder*
<meoblast001> and i was cd'd into it
<meoblast001> and it cd'd me into the trash
<meoblast001> O_o
<meoblast001> you learn something new every day
<AfC> aquarius: you might try creating a new local branch from the remote repository and then try to create a new remote branch, committing there instead. That sort of thing tends to workaround [partial] corruption that is outside of Bazaar's control.
<AfC> aquarius: or recreate remote repository, or...
<aquarius> AfC: right, OK. The thing that's in the repos is my home folder; I've committed successfully from machine 1, I've checked it out onto machine 2, but now I can't commit machine 2's changes back.
<AfC> aquarius: (ultimately, all branches are peers, so assuming your local branch isn't  missing anything from the remote branch, you can always nuke remote and recreate it)
<AfC> aquarius: (and, are you using "I checked out" colloquially or do you really mean you did `bzr checkout` rather than `bzr branch`)
<AfC> aquarius: (and, sftp://, huh? Can't get bzr installed on the remote machine? That's a shame; bzr+ssh:// might probably work better)
<AfC> (and, KnitCorrupt ... hm. Does a more modern repo format still give such an error?)
 * AfC is out of interesting questions to ask
<cjwatson> you might try 'bzr check sftp://path/to/remote/branch' (or 'bzr check /local/path' on the remote machine, faster if possible) to see whether it's the remote branch that's broken or the local checkout
<aquarius> I really did bzr checkout. I'm using it like svn...
<aquarius> sftp because the remote box is running debian sarge. How cool am I, eh?
<aquarius> the repo format needs upgrading. But, it said do "bzr upgrade sftp://wherever" and I did that and it didn't help, so, well, I wasn't sure what to do next :)
<cjwatson> rsync branch over, bzr upgrade locally, rsync branch back?
<cjwatson> (if all else fails, use brute force)
<aquarius> ok, trying bzr check on remote repo
<aquarius> heh. I did think about the rsync thing but I'm worried about juggling two copies of my home folder around ;)
<cjwatson> you only need to rsync the .bzr bit
<aquarius> ah, the remote repo has a .bzr folder, got it. I'd not actually looked in the repo at all; I assumed it was some clever collection of files that mustn't be fiddled with :)
<cjwatson> aquarius: the clever collection of files is inside .bzr ;-)
<pbor> grazie
<pbor> ops, wrong window
<AfC> aquarius: for what it's worth, you might want to [manually] install at least bzr 1.5 (and even better yet, manually install >= 1.5 on both local and remote machines). If you are managing your home directory with a VCS I'm not so sure you want to be running an old version of the tool (assuming you were to be doing so).
 * aquarius nods. Yeah. This has occurred to me...
<aquarius> hrm. bbiab.
<awilkins> jam: You're a windows-boy now, yes?
<awilkins> markh: Ping?
<jonnydee> hi :)
<jonnydee> I've got a question: is there any functionality like "svnadmin export REPO" in Bazaar?
<Odd_Bloke> jonnydee: What would you anticipate such a command doing?
<jonnydee> to export a repository/branch into a repository-neutral format
<awilkins> bzr-fast-export  ?
<jonnydee> this way I could export a rich-root-pack repository and import the dump into a new one using knits, for example
<Odd_Bloke> jonnydee: What version of bzr are you using?
<Odd_Bloke> Knits are ooooolde.
<awilkins> They're so old, they smell of wee.
<lifeless> jonnydee: why do you want to do this?
<jonnydee> ooh...there is a bzr-fast-export? I've only read about bzr-fast-import (which does not list bzr as a source)
<jonnydee> well, from time to time I get an error "bzr: ERROR: [Errno 22] Invalid argument"
<awilkins> Ironically, the only source of it I can find is a git repo :-)
<jonnydee> my repository is located on a windows network share
<lifeless> jonnydee: if you want to try knits rather than rich-root-pack, just do 'bzr upgrade --rich-root'
<lifeless> jonnydee: that willdowngrade the repository to a knit based format
<jonnydee> My local working copy is a checkout and after some commits this error occurs. But I don't know the reason, however
<lifeless> jonnydee: exporting through fast-export will just destroy your ability to merge with your own history
<lifeless> its a bad idea
<lifeless> jonnydee: that said, packs are _way_ better than knits at windows friendliness
<AfC> heh. You should call it `bzr downgrade --rich-root` [for the case that you're moving backwards]
<lifeless> if you're getting errors its almost certain that its coming from the working tree logic
<lifeless> and the best way to address that is to ensure there is a bug filed and work with us to fix it
<lifeless> jonnydee: ^
<jonnydee> I already did a  'bzr upgrade --rich-root' just to see if a downgrade is possible (all other downgrades seem to be unsupported).
<jonnydee> I was thinking about filing a bug, but I haven't figured out a pattern which reproduces the mentioned error
<jonnydee> yet
<lifeless> jonnydee: file the bug
<lifeless> jonnydee: if you wait until you know everything about it you may as well just file a patch :) - with a bug, however vague, we can help
<jonnydee> ok, I will file a bug. But I have no further information about when the error occurs...not yet, at least.
<lifeless> thats fine
<lifeless> I take the view that whenever bzr is not ideal there should be a bug filed
<lifeless> from there we can talk/discuss/track/analyse the issue
<jonnydee> ok, that's a godd view point -- I agree :)
<jonnydee> so thank's for your help
<jonnydee> cu, bye
<awilkins> lifeless: I have a change of yours here that causes errors in test_switch on win32
<awilkins> lifeless: robertc@robertcollins.net-20080730095022-4tc7ij34c0tmejb5
<awilkins> Should people log bugs for errors that the test suite shows up?
<awilkins> lifeless: Reading the diff, it's specifically the bit that removes the osutils.isdir() check
<jonnydee> Hi again, I just wanted to let you know about my bug report: https://bugs.launchpad.net/bzr/+bug/255656
<ubottu> Launchpad bug 255656 in bzr ""bzr: ERROR: [Errno 22] Invalid argument" when committing to a checkout (or doing a push) to a repository located on a windows network share" [Undecided,New]
<jonnydee> oh, sorry. there is a but which reports such reports....didn't know that...
<jonnydee> bot
<jonnydee> have a nice day / night ;)
<sven_> hi! when i get a 'contents conflict' during merge, how do i figure out what type of contents conflict it is?
<james_w> jonnydee: it was just responding to you
<james_w> jonnydee: thanks for reporting the bug
<jonnydee> ahh, ok I see. Well, thank you for your support :)
<james_w> jonnydee: it would be really useful to get the backtrace of the problem, could you look in ~/.bzr.log for the problem occuring and attach on of the stazas where it does to the report please?
<jonnydee> I'll have a look...just a moment
<james_w> thanks
<jonnydee> ok, done. I hope it helps...
<james_w> jonnydee: thanks, would you say that it was around 10 commits before this happens?
<james_w> I imagine it is seeing the backtrace
<james_w> there's a problem in the pack logic, and after around 10 commits it will try to autopack
<james_w> jonnydee: at a guess this wouldn't happen if it wasn't on a network mounted drive. The operation is probably doing something that isn't liked by that filesystem
<james_w> jonnydee: is your project particularly large?
<jonnydee> sorry for the late answer:
<jonnydee> yes about 10 commits seems reasonable....
<ronny> how can i show a revision graph with bzr?
<jonnydee> well i hav checked in 3 videos, which are about 90MB each...
<jonnydee> ok, i have to go for lunch now... cu later
<james_w> rocky: "bzr viz", or "bzr qlog" may be what you want
<james_w> rocky: the first is in bzr-gtk, the second in qbzr
<rocky> huh?
<rocky> james_w: fix your autocompleter :)
<james_w> rocky: ah, sorry, I've obviously not woken up yet
<james_w> ronny: ^ that was intended for you
<sven_> hi! how do i find out which revision a file was removed from the repository?
<james_w> sven_: that's pretty tricky at the moment unfortunately
<james_w> sven_: there's no simple command to do it
<james_w> If you have an idea then I think looking in "bzr log -v" around that area may do it. Otherwise bisect is an option
<james_w> It's something we need to improve though
<sven_> james_w, ok, thanks
<sven_> james_w, yes, that would really be helpful to know!
<sven_> james_w, another related issue: would it be possible to give better explanations of 'contents conflicts'? something like "file: removed in THIS, modified in OTHER" or "file: binary file modified concurrently"
<james_w> sven_: I'm not sure, I don't know the conflicts code well
<sven_> james_w, ok
<james_w> sven_: I agree it would be nice to have though, would you file a bug please?
<sven_> james_w, will do. thanks!
<ronny> james_w: thanks
<sven_> james_w, i reported https://bugs.launchpad.net/bzr/+bug/255687 for my first question. about 'contents conflicts', there is already a bug: https://bugs.launchpad.net/bzr/+bug/35015
<ubottu> Launchpad bug 255687 in bzr "Please allow annotating removed files" [Undecided,New]
<sven_> james_w, would it be possible to escalate these bugs? they hit us in MySQL quite frequently
<james_w> sven_: I'm not the person to ask about that I'm afraid
<sven_> james_w, ok. do you know who to ask?
<james_w> sven_: I'm not sure how it's supposed to work, you're probably best off asking someone else at mysql how to go about that
<sven_> james_w, ok, thanks
<awilkins> sven_: A thought ; perhaps if you could get the log based on file_id ?
<awilkins> How hard would it be to get a log for a file_id instead of a path?
<luks> easy, getting the file_id would be harder
<james_w> it would be possible, as that's what the path one does
<luks> (or slower, not harder)
<james_w> but yeah, luks is right
<luks> extracting inventories is expensive, and to find a deleted file you need to extract them a lot
<james_w> specifying a path looks up the file id of that path in the current tree, and then gives all revisions that touch that file id
<luks> unless it's deleted in the last revision
<awilkins> the bug implies that they know a revision from the subset of revisions the file exsinted in, so it's not too bad
<luks> if you know the revision, is should be a simple path -> id lookup
<sven_> luks, how can i do the path->id lookup?
<awilkins> And non-text conflicts do need some usability work ; I have a small patch that adds some options to "conflicts" so you can filter on things other than --text, and use --null separators, but I haven't implemented tests for it yet so I've not submitted it.
<luks> sven_: I meant in bzrlib code
<sven_> luks, ah, i see
<luks> I have a plugin that looks for deleted code somewhere
<luks> but I doubt it still works with bzr 1.6
<luks> and it's slow as hell
<luks> er, I mean it looks for deleted files
<james_w> sven_: it's really easy if you have a revision/tree
<codeRat> hi. I'm trying to setup bzr on my machines. So the way I want to use it is have a central repository on an ubuntu server. And commiting from two windows machines. I can't get it how the setup the thing :S
<codeRat> I have bazaar installed on all three machines..
<james_w> if you want to search for a path then you have to traverse history, so it's an O(history) operation
<sven_> james_w, yes, i guess i have that: since it's a contents conflict, it still exists in one of the trees
<awilkins> Doing a log based on file_id should be simple enough, adding the option to the command would be easy
<bob2> codeRat: once you have the repository setup, just 'bzr co sftp://ubuntu/blah' on the windows machines
<bob2> (or branch)
<awilkins> sven_: If you know a revision where your file exists, you can get the file-id by ``bzr ls --show-ids PATH -r REVISION``
<codeRat> I allways get the Connection reset by peer
<awilkins> codeRat: i) Is Ubuntu running sshd (it's not part of the default install options)
<codeRat> I am using http
<awilkins> codeRat: You can't commit over plain HTTP
<codeRat> how do I check for sshd?
<codeRat> I can ssh to the server..
<cody-somerville> I'm having a problem with the push-and-update plugin
<awilkins> THen it's running
<cody-somerville> On a Windows client, it says:
<cody-somerville> running "ssh mba@redcow.ca bzr update "/home/mba/www/cristallandluckett/""
<cody-somerville> bzr: ERROR: [Error 2] The system cannot find the file specified
<awilkins> codeRat: Ok, first, try opening the URI you are using vaia FileZilla
<awilkins> e.g. sftp://ubuntu/~myaccount/mybranch
<james_w> cody-somerville: try running with "-Derror" please
<cody-somerville> james_w, Okay. I'll get back to you.
 * cody-somerville will have to get his co-worker to run that when he gets into the office.
<sven_> awilkins, i tried 'bzr ls --show-ids PATH' and 'bzr ls --show-ids PATH -r-1', where PATH exists in the current revision, but it doesn't print anything
<james_w> cody-somerville: it might be on the remote side, in which case that probably won't help
<james_w> cody-somerville: I'd also check that bzr is installed on the target machine, and is in the mba user's path, and that the directory quoted exists
<cody-somerville> james_w, I'm wondering if maybe bzr is erroring because it is trying to execute "ssh" and that binary doesn't exist on windows.
<james_w> cody-somerville: I'd also try running the quoted command manually
<codeRat> I can sftp to my server
<cody-somerville> james_w, ah, good point
<bob2> codeRat: did you install bzr using the bzr windows instructions from the website?
<james_w> cody-somerville: that could well be it, if there is no ssh on the user's path then it's clearly not going to work
<cody-somerville> james_w, Does that mean I'll have to modify the push-and-update plugin manually to use putty? lol
<codeRat> bob2, on windows machines yes (I just run the installer :P )
<sven_> awilkins, ah, it can't list individual files, only directories.
<awilkins> sven_: Yes, it would seem so
<james_w> cody-somerville: possibly, there may be some support in bzr for doing this that push-and-update should use
<awilkins> sven_: I think that counts as a bug
<sven_> awilkins, ok, i'll report it...
<abentley> cody-somerville: Bazaar will use paramiko to do ssh if there's no SSH binary.
<cody-somerville> abentley, is that instlalled by default on windows?
<abentley> cody-somerville: Yes.
<sven_> awilkins, reported https://bugs.launchpad.net/bzr/+bug/255705
<ubottu> Launchpad bug 255705 in bzr "'bzr ls' should be able to list individual files" [Undecided,New]
<cody-somerville> so weird.
<james_w> cody-somerville: bzr-push-and-update doesn't use paramiko
<james_w>     cmd = ['ssh', user+host+port, remote_bzr, 'update', path]
<james_w> subprocess.call(cmd)
<awilkins> sven_: Ok, I've implemented an extra option for the log command ; we run into our next issue ; it doesn't list the revision where it was deleted
<sven_> awilkins, wow, that's fast! thank you :-)
<cjwatson> sounds like bzr-push-and-update needs to do the SSHVendorManager.get_vendor thing
<sven_> awilkins, so, the extra option lists all revisions where the file was modified or rename or otherwise touched, except the one where it was removed?
<awilkins> sven_: It was pretty easy ; the first thing the code does is calculate the file_id from the path so it's not hard to feed it one instead
<sven_> awilkins, ok
<awilkins> sven_: The reason it leaves it out is that it only allows revisions with text changes to the file through the filter (does it show renames?)
<sven_> awilkins, i see
<awilkins> Ok, it does show renames
<sven_> awilkins, but there is a filter explicitly removing deletions? would it be easy to just update the filter?
<awilkins> sven_: That's what I'm looking at
<awilkins> sven_: You also have to bear in mind that it would be a change in the behaviour of the command (for the btter, but it might break someones process)
<awilkins> sven_: It's not excluding deletions, it's only including modifications
<sven_> awilkins, but if it was previously impossible to list deleted files, it ought not to affect the output unless the new option is used?
<awilkins> sven_: hmm. Probably true
<luks> listing deletions is only possible if you do an equivalent of 'log -v'
<luks> that means, loading revision deltas
<awilkins> luks: What I've done is implement --file-id for log ; you can now log a file that has been deleted but the filter in  _filter_revisions_touching_file_id doesn't include the deletion
<luks> awilkins: yes, because the revision where is was deleted doesn't touch the file
<luks> it just disappears from the inventory
<awilkins> luks: So do you have to examine the inventory for each revision to see if it contains the file-id?
<luks> awilkins: yes
<luks> alternatively, calculate the revision delta for each revision and check if it's in delta.deleted
<luks> but that's really the same thing
 * sven_ has bad luck today... i ran into this: http://pastebin.com/d160d0b7f
<luks> that's a very old bug
<luks> I sent a patch for it but it was rejected
<sven_> luks, ok. do you know a workaround?
<luks> sven_: not using -r branch:
<luks> you can get the head revision of that branch and use that instead
<sven_> luks, i'm running this command because i want to know the gca of the two branches...
<luks> sven_: I'm not sure if log will get you that
<luks> it's an equivalent of bzr log -r revid:<head of the other branch>
<luks> at least I think it is
<sven_> luks, ah, right
<sven_> luks, i confused branch: with ancestor:
<luks> ah
<awilkins> How is the project fixed for a win32 test box at the moment?
<awilkins> And on the subject, I think the testing could stand to have more organized output
<awilkins> Hmm, maybe this is a list hting.
<jam> sven_: Just to mention, some of those content conflicts are actually bogus, and I have a patch up for review which should eliminate some of them.
<jam> The problem is that your complex history means we have to try harder to track what was actually changed
<jam> luks: you can also use "bzr log -r -1:/path/to/branch"
<jam> instead of "branch:"
<jam> I tried to do a different fix for it as well, and it got reverted.
<jam> We would *like* "bzr log -r branch:" to not fetch
<jam> but it requires updating a lot of commands to handle when the revisions aren't available in the local branch.
<luks> yeah
<abentley> jam: Fully agreed.
<jam> awilkins: I do work on win32 most of the time, I don't (yet) run the full test suite here.
<jam> I would love for "make check" to run cleanly
<jam> I just don't feel it is as high a priority as getting stuff like merge working for sven_ :)
<abentley> jam: I've wondered about the best way to support that.  Perhaps methods like "def get_two_trees(revision_specs, source_location=None, target_location=None, require_revision_trees=False)"
<awilkins> jam: I was thinking that a more strutured test output (something you could upload to a web server with a test viwer like the one the mono project has) would be a boon.
<matkor> I have file under bzr control now. I would like to leavie it as it is and make bzr ignore that file.so I do
<matkor> bzr ignore app/config/database.php
<matkor> Warning: the following files are version controlled and match your ignore pattern:
<matkor> How should I do that ?
<awilkins> matkor: bzr rm --keep ? (it won't be versioned any more)
<james_w> matkor: you mean you want to keep the file versioned, but not commit any changes to it?
<matkor> no, I want stop bzr to tracing changes and updating that fiels if changed in repo
<hsn_> is bzr+ssh protocol stable enough for everyday use? we are using sftp for now
<james_w> matkor: that's not currently possible if I understand your request correctly
<beuno> hsn_, oh yes, absolutely
<beuno> Launchpad uses it by default with bzr
<hsn_> but it needs to have all clients and server at same version?
<beuno> hsn_, ideally, but it's not mandatory. They shouldn't be too far away though
<matkor> james_w: Prolly I am unable to state it claerly bzr ignore + bzr rm --keep seems good solution to my problem ...
<james_w> matkor: ah yeah, that may be it
<hsn_> how to configure user database for bzr serve ?
<beuno> hsn_, bzr doesn't do user authentication, so you have to do that on the ssh side
<awilkins> hsn_: You don't need to run bzr serve for bzr+ssh either
<hsn_> bzr push over bzr+ssh updates working tree on server?
<beuno> hsn_, no, but there is a plugin that can do that
<beuno> push-and-update
<beuno> if you *just* want the working tree on the other side, you can use bzr-upload
<hsn_> plugin runs on server or client?
<beuno> client
<hsn_> server side hooks are not done yet?
<beuno> I think *some* are, but I don't know for sure, and they're probably in the unreleased 1.6
<hsn_> files in absolete_packs needs manual cleaning?
<bob2> no, they'll get removed eventually
<alex-weej> i'm having trouble mirroring my svn repo... i can use "bzr branch svn://url/trunk" but that only creates a trunk obviously
<alex-weej> i tried svn-import, it asks me for my password 3 times and then fails
<Jc2k> svn-import is the way to go
<Jc2k> you are using the exact same url, without the /trunk ?
<Jc2k> have you done an svn co of that url without the /trunk before? (earlier bzr-svn's (not sure when/if it was fixed) couldnt do a co unless svn had been used and it had cached the password before)
<Jc2k> alex-weej: ^
<alex-weej> yes hang on i will give you the error
<awilkins> jelmer: Is this unicode file name meant to be "I squared C" or "I funny-A squared C" ?
<awilkins> (funny-a being circumflex-a)
<alex-weej> Jc2k: bzr: ERROR: exceptions.AssertionError: 'mirror/$reponame/branches/live' is not a valid path
<alex-weej> Jc2k: i don't know where "mirror" is coming from...
<alex-weej> that is with bzr svn-import http://svn.example.com/$reponame
<Jc2k> hmm
<Jc2k> anything interesting in your .bzr.log?
<codeRat> I installed python and paramiko but still if I want bzr to use sftp I get Unsupported protocol..any ideas why? (OS: windows xp)
<codeRat> I'm trying to setup inetd
<codeRat> I have this in the conf file:
<codeRat>  server      = /usr/bin/bzr
<codeRat>         server_args = /usr/bin/bzr serve --inet --directory=/home/tinesu/bzr-repos
<codeRat> Ok, I solved it..Had to delete the bzr command from args
<codeRat> this is different in xinetd than inetd :)
<beuno> codeRat, are you following a tutorial?
<codeRat> I'm trying :)
<codeRat> User guide
<beuno> if something on bzr's help confused you, it may be interesting to fix it  :)
<codeRat> In the userguide there is the line for inetd
<codeRat> when you convert it for xinetd ..you have to change what I told before..that's all
<jelmer> awilkins, I squared C
<awilkins> jelmer: Encoding in Python appears to be confusing then :-(
<awilkins> jelmer: I stabbed at it for some minutes without fixing it.
<jelmer> awilkins, which file?
<awilkins> test_commit_unicode_filename in test_commit.py
<jelmer> awilkins, please make sure it's got -*- coding: utf-8 -*- at the top
<awilkins> It has
<awilkins> The code says "Icircumflex-asuperscript-2C"
<awilkins> (sorry, non-unicode IRC client)
<awilkins> Ah, ok, vim renders it like that
<awilkins> notepad2 is fine with it
<awilkins> i(superscript-2)C
<awilkins> How is the file named in Linux? Windows write the file in text-base just fine (with unicode filename)
<codeRat> I still need some help. I can connect trough bzr:// protocol..but can't with bzr+ssh:// I get this:
<codeRat> bzr: ERROR: Connection closed: please check connectivity and permissions
<bob2> check ~/.bzr.log
<codeRat> on the server or client?
<bob2> also, bzr+ssh is unrelated to bzr:// (i.e. you don't need inetd for bzr+ssh to work, but you do need a working ssh account)
<alex-weej> Jc2k: 10.068  failed to import pycurl: No module named pycurl
<codeRat> I have a working ssh account, but how do I which username to use?
<bob2> how do you tell bzr which to use?  bzr branch bzr+ssh://username@host/path/to/branch/
<beuno> codeRat, bzr+ssh://username@host/path/to/branch
<beuno> hah
<bob2> creepy ;)
<Jc2k> alex-weej: that shouldnt be fatal..
<Jc2k> alex-weej: did it get very far before it errored?
<codeRat> still getting the same error :(
<jam> awilkins: can you give the line that is the problem?
<jam> In general, we don't put UTF-8 into our source code
<Jc2k> alex-weej: i presume this is an internal svn repo i'm not going to be able to poke
<jam> instead using u'\uAAAA" to define chars
<bob2> codeRat: pastebin the last bit of .bzr.log on the client
<awilkins> self.build_tree({u'dc/IÂ²C': "data"})
<jam> awilkins: is this in bzr or bzr-gtk?
<awilkins> bzr-svn
<awilkins> Test code
<jam> ah, ok
<jam> That's Jelmer's realm, and he can do what he wants :)
<codeRat> bob2, Where is htis file (on windows )?
<jam> I would *recommend* not using UTF-8 literals
<jelmer> jam: What's a good alternative?
<awilkins> jam: It still fails if you escape it
<bob2> codeRat: /Users/username/, I guess
<jam> jelmer: Just use the escape code: u'dc/I\xb2C'
<jam> that way you don't have to worry about text editors interpreting the chars wrong
<jam> I know Vim on Win32 thinks it is latin-1
<jam> though I can force it to UTF-8
<jam> awilkins: I don't know what "build_tree" Jelmer is using, it doesn't match the TestCaseWithTransport's build_tree
<jam> awilkins: You're on win32? Are you on FAT by any chance?
<awilkins> jam: Nope, NTFS6 (and FAT32 can use unicode filenames, not sure about FAT16/12)
<jam> awilkins: weird, I'm running NTFS on Vista (not sure the exact version) and doing:
<jam> open(u'I\xb2C', 'wb').close()
<jam> works fine
<jam> And Explorer shows the I^2C file
<codeRat> bob2, http://pastebin.com/m60287138 here it is
<awilkins> jam: That's not the issue
<jam> awilkins: are you just saying that the *test* is failing? I thought the build_tree was failing
<awilkins> jam: Not sure.. build-tree seems fine, the file is appearing in the SVN working copy with a unicode filename
<bob2> codeRat: does 'ssh tinesu@xxx.xxx.xxx.xxx bzr rocks' work?
<codeRat> hmm windows doesn't have ssh
<codeRat> I mean the command ssh
<awilkins> jam: jelmer: think the problem is it being passed ascii/encoded to the SVN client (can that cope with unicode?)
<jelmer> awilkins, the svn client only accepts encoded unicode (e.g. utf8)
<codeRat> heh, I renamed plink to ssh and the error changed :)
<codeRat> bzr: ERROR: [Error 2] The system cannot find the file specified
<jam> awilkins: I would assume it has to be UTF8
<jam> it sounds like there is a layer doing implicit conversion
<jam> (accidentally)
<jam> can you paste the traceback?
<awilkins> http://pastebin.ubuntu.com/35117/
<jam> awilkins: well, I'll give you a quick rundown on the code I have available
<jam> It uses:
<jam> data = osutils.fingerprint_file(open(self._abspath(relpath)))
<jam> And what is happenning
<jam> is that self._abspath
<jam> does
<jam>         return wc.get_pristine_copy_path(self.workingtree.abspath(relpath).encode("utf-8"))
<jam> So it seems to be returning a UTF-8 string
<jam> which is not valid on Windows
<jam> to access local files you *must* use Unicode
<jam> I think it works on Linux
<jam> because the filesystem is UTF-8
<jam> so the UTF-8 str path == Unicode path
<jam> If I'm right
<jam> the fix would be something like:
<awilkins> So utf16 rather than utf8 ?
<jam> j        return wc.get_pristine_copy_path(self.workingtree.abspath(relpath).encode("utf-8"))
<jam> sorry bad copy
<jam>                 osutils.fingerprint_file(open(self._abspath(relpath).decode('utf-8')))
<jam> awilkins: if you use the 8-bit apis, it uses OEM encoding
<jam> which is usually something slightly random
<jam> CP1252 (which is *almost* latin-1, but not really)
<jam> So you need to use the Unicode apis
<jam> Like you say, something like UTF-16 (though again it is MBCS for windows filesystems, which is very similar, but IIRC not exactly UTF-16)
<jam> Basically, passing a 'unicode()' string to open() will use the Windows FooW api
<jam> rather than the FooA api
<jam> I would also guess that SvnBasisTree._abspath() should really be returning a Unicode string
 * awilkins thinks perhaps encoding-specific hungarian var names would be good here.....#
<awilkins> jam: That would be my interpretation ; all the paths should be unicode if both OSs support them
<jam> awilkins: well, the Bazaar model was that file paths are always Unicode in memory
<jam> And that gets serialized/deserialized at the "write bits to disk" or "over the wire" layers
<jam> On the other hand
<jam> *urls* are always 8-bit strings
<jam> (well, technically, always 7-bit strings)
<jam> Because *bzr* doesn't have control over all portions of the path
<jam> It took us a while to get it right in bzrlib
<awilkins> jelmer: Is this down to the pyrex bindings? THe sticking points all seem to be calls into pyrex extensions.
<jelmer> awilkins, there's no pyrex remaining anymore :-)
<awilkins> jelmer: Pardon, C extensions ?
<awilkins> All the places where encodings are occurring for reasons I don't understand are calls into the extensions like client and wc
<jelmer> awilkins: The bindings do indeed require encoded strings
<jelmer> awilkins, not unicode objects
<jelmer> awilkins, I don't understand why that's a problem though
<jam> awilkins: I would also mention that doing a bare "open()" like that is a good way to leave a file handle open on windows, causing problems when trying to rm directories :)
<Pilky> does anyone know of a way to remove a file completely from your bzr history?
<beuno> Pilky, you can't
<beuno> once it's versioned, it's there for ever and ever
<Pilky> ok
<beuno> unless you remove all history after you added it
<beuno> or you may be able to break things someway with rebase
<Pilky> yeah, I suppose if one really wanted to you could create a branch for every revision back to when you added it, uncommit from the main branch and then just copy the changes over and recommit, but that would be a bit long winded
<beuno> it would  :)
<meoblast001> how do you insert a line break into a commit message?
<beuno> meoblast001, bzr ci
<beuno> and it will go into editor mode
<meoblast001> ok thanx
<beuno> you can do anything you want in there
<bob2> or bzr commit -m "something<hitenter>more stuff."
<beuno> (ci is an alias for commit, you just avoid the -m"
<LeoNerd> Its' actually an alias to "check in", which goes riiiight back to pre-RCS days
 * beuno isn't that old   :O
<jam> bob2: I will caution that on windows, bzr.bat doesn't seem to pass through line-breaks
<jam> I think it is a problem with the .bat functionality itself
<bob2> ah, that sucks
<jam> I used it for a while
<jam> and didn't realize it wasn't working
<meoblast001> bzr: ERROR: no changes to commit. use --unchanged to commit anyhow
<jam> so I rewrote a .sh wrapper for cygwin
<meoblast001> O_o
<meoblast001> i made 3 major changes
<bob2> meoblast001: did you save them?
<meoblast001> yes
<meoblast001> hmmm
<meoblast001> i guess that bzr ci automatically commited for me
<bob2> "bzr ci" will commit after you save and exit the editor it started
<meoblast001> yay
<codeRat> just one question..I did init on the server and got a branch.I co it from the client..everything went ok..I then add some files..did a commit. But no files are on the server? What is the right way?
<LeoNerd> When you say "no files", what do you mean?
<bob2> that's fine
<bob2> the "working tree" of the remote branch won't be updated
<LeoNerd> The branch won't look like it has any files in it, no... those files are the working tree. If there isn't one, it won't appear there
<bob2> if you would like it to be, you need a special plugin
<LeoNerd> The branch data is all stored within the .bzr subdirectory
<bob2> push-and-update plugin
<codeRat> but what's the point of having the central repos then
<bob2> ?
<codeRat> when I try to co from another client I don't get anything..
<bob2> the branch data is there, the working copy just isn't updated
<bob2> ah, that shouldn't happen
<bob2> did you 'bzr co' or 'bzr branch' on the client?
<codeRat> co
<codeRat> on both clients
<beuno> codeRat, you did "bzr add", right?
<codeRat> yes
<bob2> does 'bzr status' on the client show that everything has been commited (i.e. it should say nothing)
<codeRat> it doesn't (say anything)
<bob2> what does 'bzr info' say on the client side?
<codeRat> I did just "bzr commit" Than it said Committed revision 1. It seems that everything worked fine..
<codeRat> Location:
<codeRat> Checkout root:.
<codeRat> Checkout of branch: bzr://ip/test/
<bob2> cool
<bob2> then the changes in that commit should be propagated to the central repository
<luks> try `bzr log bzr://ip/test/`
<codeRat> so now..if I do a bzr co on the other client..should I get thos files I added?
<bob2> yup
<codeRat> log is fine (I tried on the other client)
<luks> then the data are on the server
<luks> what does bzr co on the other client says?
<codeRat> bzr: ERROR: File exists: u'P:/Bazaar/test/.bzr': [Error 183] Cannot create a file when that file already exists
<codeRat> but I got the data
<codeRat> can someone explain what is all about with bind/unbind ?
<luks> when you do 'bzr co' instead of 'bzr branch', your local branch is bound to the server branch
<luks> that means a local commit goes directly also to the server
<luks> with 'bzr unbind' you can break that and the branch will become a standalone branch
<luks> then you need to use 'bzr push' to upload the data to the server
<codeRat> at that time when I do the commit it's saved only locally ?
<luks> yes
<codeRat> what happen If I do bind ?
<luks> I'm not sure what happens with existing local commits, but I guess they will get uploaded next time you commit
<codeRat> ok, Thank you very much..
<codeRat> All of you for the patience :)
<jelmer> awilkins, your patch fails the testsuite:
<jelmer> running 13479 tests...
<jelmer> ...-workdir/home/+trunk/bzrlib/doc/api/branch.txt)   OK                  92ms
<jelmer> ...rkdir/home/+trunk/bzrlib/doc/api/transport.txt)   OK                   1ms
<jelmer> ...til.tests.test_bencode.TestBencode.test_bdecode   OK                   0ms
<jelmer> ...til.tests.test_bencode.TestBencode.test_bencode   OK                   0ms
<jelmer> blackbox.test_add.TestAdd.test_add_control_dir    ERROR                  13ms
<jelmer>     'module' object has no attribute 'join'
<awilkins> Oh ass
<awilkins> It's joinpath, not join. I am an idiot
<awilkins> Hmm, ok
<luks> nice example of effective code reviewing, it got two approves :)
<jelmer> luks, well, the code looked alright, no problem there :-)
 * awilkins submits again while hanging head in shame
<luks> that's why you should always add a test case, no matter how small the change is :)
<bob2> does bzr-svn go through a pqm?
<luks> hm, I could swear there were some tests for the test suite
<luks> but I can't find them
<jelmer> bob2, no
<jam> awilkins: Actually, I think the one you want is "pathjoin" yeah, bad naming FTL
<jam> joinpath explicitly denies stuff like '..'
<jam> pathjoin == os.path.join when appropriate
<corporate_cookie> to issue a command like bzr branch lp: launchpad_project_name ..do i need to install a plugin ?
<luks> corporate_cookie: the plugin is built-in
<corporate_cookie> luks: thanks : )
<luks> but its bzr branch lp:launchpad_project_name (no space)
<jam> It was my fault for pointing you incorrectly.
<corporate_cookie> ah : )
<corporate_cookie> stupid spaces
<luks> also, where is your nose? :)
<corporate_cookie> :^) ?
<corporate_cookie> luks: would bzr ERROR: socket.error: (61, 'Connection refused') be indicative of a proxy related issue ?
<luks> hmm, could be
<corporate_cookie> alas : )
<corporate_cookie> thanks for the help
<luks> you can just use the full url
<luks> the lp: thing seems to use a xml-rpc over https
<luks> so if you don't have a https proxy, it won't work
<corporate_cookie> that works : )
<corporate_cookie> thanks
<alex-weej> when i am working with git and i want to work on an orthogonal change, i do "git checkout -b new-work master"
<alex-weej> that branches new-work from master and checks it out
<alex-weej> i am a bit confused with bazaar... branches are directories?
<bob2> yes
<bob2> however, bzr also has the concept of repositories and checkouts
<cjwatson> alex-weej: you have the choice; it's more usual to have one directory per branch, but you can also use 'bzr switch' to take the git approach
<alex-weej> if i use a repository can i branch without having it have to copy my entire working tree?
<bob2> alex-weej: yes, make a checkout of one of the branches, then use 'bzr switch /repo/branchname' to switch that checkout between them
<cjwatson> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html section 5.5 has some information about this
<alex-weej> cjwatson: thanks
<pickscrape> mwhudson: I've added a hover style to the breadcrumbs branch. Nice suggestion, it does look a lot better like that.
<rockstar> jam, hi
<rockstar> beuno, hi
<beuno> rockstar, howdy
<rockstar> beuno, we've been talking about unifying the loggerhead templates, so that they are more easily skinnable.
<beuno> rockstar, unifying?
<beuno> LP and LH's trunk?
<rockstar> Well, I guess "unifying" is not a good term when applied to trunk.
<rockstar> Basically, thumper has other gnome loggerhead stuff, which is slightly different than the ACTUAL loggerhead templates.
<beuno> right
<jam> rockstar: hey, sorry for the delay, TWiB time, right?
<rockstar> I think the gnome stuff has some different needs.
<rockstar> jam, I have to run out to Rinchen's house in 20 minutes to help out with their sprint.
<rockstar> I'll be there for the rest of the day, but I'm pretty open tomorrow.
<beuno> rockstar, so, what's on your mind?  Changing the templates so you can drop in headers?
<rockstar> beuno, header and footer first.
<rockstar> beuno, then, probably make it so we can drop in a search bar, etc.  At least, that was the brainstorm.
<jam> rockstar: well, we'll need to actually *do* it. I skipped last week, and the week before I was late by 5 days or so ... :(
<beuno> rockstar, sounds like a good idea. Is someone going to be doing that work, or is that why you're talking to me?
<jam> I can't say I'm in the mood, but I know people felt it was helpful
<rockstar> jam, yea, and after the good feedback on the mailing list specific to TWiB, I'm really anxious to do it.
<rockstar> beuno, I'm actually working on that right now.  I have been all day.
<beuno> rockstar, oh, very cool
<rockstar> I'm just at a point where I need to let you know what I'm doing, before I can't turn back.
<beuno> sure. Do you have a branch somewhere?
<pickscrape> How are loggerhead contributions handled (reviewed etc)? Via launchpad?
<rockstar> jam, so, should I ping you in the morning tomorrow?
<beuno> pickscrape, yeah, for now. Upload a branch, file a merge request
<rockstar> beuno, I don't have many changes, but I'll shoot you the branch before I quit tonight.
<pickscrape> beuno: I think I already have requested a merge. Do I need to also need to "Request a review"?
<beuno> pickscrape, hm, no, that should be enough. Do you have the URL handy?
<beuno> rockstar, cool. I love the idea, if that's what you where looking for
<pickscrape> https://code.launchpad.net/~pickscrape/loggerhead/breadcrumbs/+merge/664 <- hopefully this is the right URL
<cody-somerville> Can someone take a look at this error one of my coworkers is getting?
<cody-somerville> http://pastebin.ubuntu.com/35191/
<cody-somerville> bzr: ERROR: exceptions.KeyError: 'file:///C:/WebDev/Projects/mba/investfred2/.bzr/repository/upload/r21oxweo2g2wsh2vvcln.pack
<beuno> pickscrape, oh, I did see that this morning. It's on my ToDo!
<pickscrape> cody-somerville: might want to consider upgrading to 1.5 if that is possible
<beuno> I still can't match your nickname you your real name  :)
<pickscrape> beuno: cool! No rush, just didn't know how this whole process works yet :)
<beuno> pickscrape, you nailed it from the start!
<pickscrape> Yeah, weird nickname. I have no imagination. It's a guitar playing technique. :)
<luks> the traceback is not the real problem, it just masks it
<luks> so it's hard to say what's wrong
<cody-somerville> pickscrape, the remote server is running the beta
<beuno> cody-somerville, can you make him peak at his ~/.bzr.log to get the traceback?
<pickscrape> So is the "Request a review" for when you don't think it's worth merging yet but you want feedback?
<beuno> pickscrape, I don't really understand what that's for  :)
<cody-somerville> beuno, what would be the equivalent in windows?
<beuno> abentley might, I think that's his work
<beuno> cody-somerville, oh, windows...  I have no idea  :)
<jam> rockstar: yeah, please ping me, I probably won't be ready until post 12 central (11 yours, iirc)
<beuno> let's see what launchpad says
<beuno> cody-somerville, maybe related to bug #191409 ?
<ubottu> Launchpad bug 191409 in bzr "commit on bound branch yields KeyError" [High,New] https://launchpad.net/bugs/191409
<cody-somerville> beuno, this is a branch
<abentley> pickscrape: In many projects, you must not merge until you get feedback.
<jam> cody-somerville: My Documents\.bzr.log
<jam> (it may move in the future)
<jam> doing 'bzr --version' will show you where it is
<pickscrape> abentley: is the workflow documented anywhere on launchpad?
<abentley> pickscrape: Launchpad is meant to support many different workflows.
<pickscrape> I found myself wondering if registering a branch with a project that I wasn't involved with would be 'socially acceptable' or not.
<rockstar> jam, ack, will do.
<beuno> pickscrape, it's encouraged. Although I do agree it doesn't say anywhere
<pickscrape> And following that, what the project would expect from my contribution. i.e. standards that I should follow, files that I should edit etc.
<jam> pickscrape: I think the feeling (for us at least) is that registering a branch is like posting a patch to their tracker
<abentley> pickscrape: most projects will consider it socially acceptable to register a branch.
<jam> only in a *more* convenient form
<jam> It is a bit different if the project doesn't *use* bzr/lp, but as long as they do, I would guess they would be fine with you posting your own branches.
<abentley> pickscrape: We do not dictate how a particular project handles patches.
<abentley> pickscrape: Some projects use Launchpad only for bugs.  Others host their code there, but do code reviews elsewhere.
<chadmiller> For bzrlib.log.show_log(), what's the least ugly way to make it not emit merged revisions?  Something in the log formatter, I suppose, but I can't place what.
<pickscrape> abentley: understood. However, I think lp could have some place where the project can document "contribution guidelines" or something similar to help out new people.
<abentley> pickscrape: wouldn't the project web site or source code be a more appropriate place?
<pickscrape> Some projects won't have a website other than launchpad. I agree that the code would be a good place to put that, but that requires the user digging about for it. Perhaps allowing links to specific files on the primary branch that appear on the front of the 'code' page?
<pickscrape> Would be a good way to make things like 'release notes' accessible too while simultaneously version controlled with the code
<abentley> I believe we already allow that.
<cody-somerville> beuno, http://pastebin.ubuntu.com/35196/
<pickscrape> abentley: I can't see where you can do that
<abentley> I believe you can enter any URL you like in the project description.
<beuno> cody-somerville, [ 2800] 2008-08-07 14:58:55.887 WARNING: Server is too old for streaming pull, reconnecting.  (Upgrade the server to Bazaar 1.2 to avoid this)
<beuno> that should be a pretty good tip on what to do
<cody-somerville> beuno, it would be
<cody-somerville> beuno, except he is running 1.4
<cody-somerville> and the server is running 1.6
<beuno> cody-somerville, well, that doesn't seem to be the case
<beuno> cody-somerville, can you run "bzr version" on the server?
<pickscrape> Isn't this because of an API call that was removed in 1.6, which makes a pre-1.6 client think the server is 1.2?
<cody-somerville> Yes.
<beuno> cody-somerville, I don't really know then
<beuno> spiv?
<cody-somerville> spiv?
 * cody-somerville will see about getting everyone to upgrade to 1.6 beta :P
<beuno> lifeless, I;ve been trying to reproduce bug #248018, but I'm not able to get it to override results.  The javascript should prevent it, and I can't get it to misbehave  :)
<ubottu> Launchpad bug 248018 in loggerhead/1.6 "slow search results override fast ones" [High,Confirmed] https://launchpad.net/bugs/248018
<jam> beuno: that is a "known bug", the 1.5 client connecting to the 1.6 server
<jam> Specifically, there was a verb added in 1.2
<jam> which we removed in 1.6
<jam> And 1.5 tries it and then thinks you must have an older server
<jam> We can't really fix that without: a) Patching 1.5 (which doesn't help clients over just upgrading to 1.6) b) Implementing the verb, which is *hard* to do efficiently and correctly
<jam> 1.5 correctly falls back (though it unfortunately also reconnects)
<beuno> jam, the bug is it telling that it needs 1.2, not the keyerror thoough, right?
<jam> beuno: right the "needs 1.2" is the bug
<jam> cody-somerville: the client should still *work* just give a semi-bogus message and reconnect
<cody-somerville> jam, it usually does
<jam> cody-somerville: Is this consistently failing?
<cody-somerville> jam, yes
<jam> this actually looks like there is some *other* error which is being triggered, and then this error is covering it up when we cleanup our stack
<jam> cody-somerville: check the permissions on .bzr/repository/upload (If you can)
<jam> It *feels* like we go to create a new pack, mark it for creation, fail to write to it, get an exception
<jam> and then we want to clean up and close the file
<jam> but it was never properly opened
<jam> cody-somerville: You may try just adding a "try/except: KeyError: pass" around the del line
<jam> and see if you don't get a different error
<chadmiller> Ah.  I test the revision.merge_depth now, in the log formatter.  That does what I want.
<cody-somerville> jam, will I want to do this on remote host or local host?
<jam> cody-somerville: the failure is local
<jam> So only on the local machine
 * cody-somerville goes to see if he can reproduce the error himself.
<jam> note that the failure is 4,400 seconds after the process reconnects, which is a bit surprising
<jam> You *can* add '-Dhpss' to the bzr branch line
<jam> but I have the feeling that is just going to dump a lot of nonuseful information
<cody-somerville> :-|
<cody-somerville> Does Canonical provide paid support for bazaar?
<beuno> cody-somerville, AFAIK, they do
<beuno> email poolie
<beuno> so, it's official: http://beuno.com.ar/archives/82
<pickscrape> Congrats :)
<cody-somerville> beuno, you're starting this upcomming Monday?
<beuno> cody-somerville, yeap.
<cody-somerville> me too!! :)
<beuno> cody-somerville, really?  you're joining Canonical?
<cody-somerville> Yes sir
<Odd_Bloke> beuno: Congrats. :)
<beuno> cody-somerville, cool!  what are you going to work on?
<beuno> Odd_Bloke, thanks  :)
 * mwhudson looks around the channel for people we haven't hired yet
<cody-somerville> beuno, Release Engineer for Canonical OEM Solutions Groups
<cody-somerville> *Group
<beuno> cody-somerville, w00t!  congrats!
<beuno> so, we'll meet at some point  :)
<beuno> mwhudson, :p
<cody-somerville> beuno, For sure! Maybe California?
<beuno> cody-somerville, very likely.  I'll know in the following months
<cody-somerville> :]
<Odd_Bloke> mwhudson: Pick meee!
<thumper> Odd_Bloke: :)
<jonnydee> lifeless: regarding my bug report (https://bugs.launchpad.net/bzr/+bug/255656): You asked me to do a "bzr pack REPO_PATH"
<ubottu> Launchpad bug 255656 in bzr ""bzr: ERROR: [Errno 22] Invalid argument" when committing to a checkout (or doing a push) to a repository located on a windows network share" [Undecided,New]
<lifeless> jonnydee: yes, I did
<jonnydee> I already tried that and as far as I can remember it faild indeed with the same error
<lifeless> jonnydee: please do try it and attach what it puts in the log
<lifeless> shouldn't take long
<jonnydee> but, unfortunatelly, I'm not at work now and, therfore, I cannot access .bzr.log. But I will have a look to it tomorrow
<jonnydee> And I recovered already from the "buggy" repository so I need to wait until I stumble over the "Invalid argument" issue again
<jonnydee> I will report information as soon as I can. Thanks for your interesst :)
<lifeless> jonnydee: ok; running bzr pack - if it gives us a way to trigger it repeatedly we can move on to determining exactly why it is happening for you without having to wait for it sporadically happening
<jonnydee> lifeless: that sounds very good -- I will try it tomorrow. But just to be sure I got your idea: You think "bzr pack REPO" should (or might) always fail, so I don't need to wait until auto pack mechanism is triggered, right?
<lifeless> 'bzr pack' and autopack both end up exercising the same code path
<lifeless> so doing 'bzr pack' should fail immediately in the same way that autopack is
<jonnydee> ok, I understand. Thanks a lot -- I will post feedback tomorrow. So have a nice day/night ;)
<jonnydee> CU
<lifeless> thanks
<jam> Odd_Bloke: Aren't you hired for the summer?
<poolie> good morning
<jam> morning poolie
<poolie> jam, shall we talk here in lieu of a standup?
<jam> if you want
<jam> spiv is away
<jam> and I don't know about igc
<jam> poolie: do you want to stay in #bzr?
<poolie> sure. i was just going to say i'm going to update the ppa, read some documents for amanda, take my dead video card back to the shop, do the monthly report, hopefully do some reviews and finish at 5
<lifeless> I'll believe it when I see it
<lifeless> :)
<poolie> heh
<poolie> it does sound a bit ambitious
<lifeless> where is spiv ?
<poolie> maybe i should run sudo -b shutdown 17:00 now?
<poolie> at the physio
<poolie> and i would guess igc is asleep
<lifeless> ah yes I remember
<poolie> jam, lifeless, how about you?
<jam> poolie: so, I'm working on comparing my lazy revno stuff to bzr.dev's merge_sort
<jam> And I found a bug in merge_sort as it stands
<jam> which I've submitted a simple patch for
<lifeless> jam: was this bug in the original merge sort? (You already reimplemented it once I believe?)
<jam> lifeless: I believe it is from my change to use simple 3-digit numbers
<jam> It is because of a pre versus post increment bug
#bzr 2008-08-08
<lifeless> ah yes, we're not doing the original merge sort anymore
<lifeless> well we're doing the same order but different numbers?
<jam> lifeless: right, same ordering
<jam> new root nodes would post-increment the branch counter
<jam> while new intermediate nodes would pre-increment it
<jam> so there are 2 "0.8.1" revisions right now
<lifeless> I read the patch :)
<jam> lifeless: We also should have a fix for ghosts
<jam> For the immediate work, I'm replicating bzr.dev
<jam> and pre-filtering ghosts
<igc> poolie: awake now
<lifeless> by fix you mean: a ghost should reserve a revno for itself' ?
<jam> lifeless: right
<jam> At least, that is my idea
<jam> I could implement it either way
<lifeless> I think thats wrong - because there is an unknown quantity of revnos to reserve
<lifeless> one is no more or less correct than 0 or 50000
<lifeless> and as it is a ghost we have no information to show about it in log etc
<lifeless> actually, by wrong I mean no more correct than our current behaviour.
<Odd_Bloke> jam: Well, yes, but that's not the sort of job I can get a mortgage with. ;)
<jam> lifeless: I sort of understand your point, but there is also: http://rafb.net/p/hfnZd187.html
<jam> Assume 'C' is a ghost in both cases
<jam> In the latter, a spot is reserved for 'd'
<lifeless> D is not a ghost right?
<jam> lifeless: correct
<lifeless> what revno does D get today
<jam> 0.1.1
<jam> today
<lifeless> and you are saying it should get 0.1.2
<lifeless> ?
<jam> lifeless: yes
<jam> C would be 0.1.1 in both cases
<lifeless> but what if theere is F, a parent of C in both cases
<jam> lifeless: obviously we can't go into nodes that we haven't seen at all
<jam> parents of ghosts
<poolie> good morning igc :)
<jam> I *can* mimic current behavior
<jam> it just turns out to be *more* work
<lifeless> I don't see what paste as an argument for or against; one graph isn't a subset, theres no reason for numbers to be stable
<jam> And I'm hesitant to write tests that require it
<jam> morning igc
<poolie> it's desirable they be stable across releases
<igc> hi jam, lifeless
<lifeless> poolie: we've violated that so hard that integer is seeking a restraining order on bzr
<jam> poolie: well, they are already going to change as of today :)
<jam> though not dramatically
<lifeless> jam: I'm all for doing less work; but I'd justify it on that basis not on correct, as correct is ... vague here
<jam> just removing a bug for it
<jam> lifeless: sure, I suppose I'm a bit concerned about knock-on effects
<jam> right now, because we prune ghosts
<jam> the next layers don't worry about whether 'get_revision()' could fail
<lifeless> I'd expect log to fail
<lifeless> etc
<jam> though, I have gotten the feeling we've been trying to push ghost handling further up the stack
<lifeless> jam: we want to stop hiding bugs
<lifeless> for instance a ghost on the mainline should be supportable
<jam> So 'bzr log' could just show that there is a known revision_id, even if it doesn't know the info
<jam> poolie: the one "savior" here, is that it is only changing the "0.X" numbers
<jam> the rest of the numbers are stable either way
<jam> 0.X.Y, I guess
<jam> I guess I'll stick with the current scheme, going via the "principle of minimal change"
<jam> I might just comment out those tests
<lifeless> erm
<lifeless> delete
<lifeless> or fix
<lifeless> please
<jam> anyway, enjoy your day
<lifeless> you too
<lifeless> I'm wowing tomorrow FWIW
<lifeless> jam: do we nest branches as deeply as the original merge_sorted did ?
<lifeless> oh wow WT.remove is crufty
 * igc bbl
<rocky> jelmer: you use trac-bzr much?
<lifeless> jam: ping; an ack on my reply-to-the-annotate-patch would be nice
<laszlok> lifeless: ping
<lifeless> laszlok: hi
<laszlok> re the jokosher email, what does remixing mean?
<lifeless> changing things around
<lifeless> if you're happy with the branches and tags you have today, then you don't need to change stuff - just convert systems
 * jdong resists temptation to turn "remixing" into a Barack Obama energy plan jab....
<laszlok> basically branch refactoring
<lifeless> yup. its much more complex to do that; but I got the impression from your mail that you had something other than a direct switch in mind
<laszlok> not particularly, i think as long as all out svn branches come out as separate bzr trees it should be okay
 * laszlok checks the stale branches in the svn repo
<lifeless> yes, they should
<laszlok> so the svn import will automatically split them up into different repos
<lifeless> if you install bzr-svn and just run bzr svn-import SVN_REPO_ROOT /tmp/svn-conversion
<laszlok> different repos with the same parent
<lifeless> we'll know soon enough
<lifeless> svn-import can be run incrementally so you could do this somewhere more persistent than /tmp too :)
<laszlok> launchpad it currently mirroring the svn trunk, is there a special way to import it, or is it just a simple push?
<lifeless> this will supercede the launchpad mirror
<lifeless> we'll end up with a bunch of branches - you can push some or all of them to launchpad, owned by you, or by a jokosher team if you have one
<lifeless> and we'd turn off the launchpad mirror of svn trunk
<emgent> beuno: ping
<laszlok> lifeless: i did the svn-import with the repositiory root, but all the branches and tags directories are now in the bzr branch :/
<lifeless> laszlok: really? It should create many branches in a shared repository
<laszlok> how do i get a list of branches in the shared repo
<emgent> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
<emgent> some idea?
<emgent> i'm on intrepid.
<emgent> ssh-add dont work.
<lifeless> laszlok: 'bzr branches'
<lifeless> (or just ls :))
<laszlok> yeah there are none
<lifeless> laszlok: how big is the output directory?
<lifeless> and whats the jokosher svn url
<laszlok> 26MB, and when i do a branch of the shared branch the files appear
<laszlok> do the branches/ and tags/ dirs have to be at the top level?
<lifeless> laszlok: I'll defer to jelmer: on that;
<laszlok> cause in jokosher we have modules with separate branches and tags folders
<lifeless> whats the svn repo url ?
<laszlok> maybe that confused it
<laszlok> http://svn.jokosher.python-hosting.com
<lifeless> I was fairly sure that this is a common layout bzr-svn understands
<lifeless> oh except -art and -extra are different
<laszlok> right because they don't release
<laszlok> stupid historical reasons
<lifeless> so you want four projects essentially?
<laszlok> if we can just get JonoEdit converted, that will be enough
<laszlok> gst-chanplit is in gstreamer-cvs now, and the other two are just files. ie no history needs to be saved
<lifeless> ok
<laszlok> laszlo@sescento:~/Software/svn/bzr-jokosher-convert$ bzr st
<laszlok> bzr: ERROR: No WorkingTree exists for "file:///home/laszlo/Software/svn/bzr-jokosher-convert/.bzr/checkout/".
<laszlok> if i branch from bzr-jokosher-convert, then i have a proper working directory
<laszlok> strange
<lifeless> laszlok: the converter doesn't create working trees because you can end with with gb's of data that way
<lifeless> laszlok: imagine a svn repo with several thousand branches/tags
<lifeless> maybe all of them are shared history
<laszlok> okay, but doesn't svn do the same thing when you checkout the entire repo?
<lifeless> svn will create working trees because all the svn commands to get data locally are working tree centric
<lifeless> so svn checkout some-root will indeed give huge downloads and huge disk usage
<lifeless> this isn't really a feature
<laszlok> okay its getting late. thanks for you help lifeless, i will try to see why it isn't splitting the branches tomorrow
<lifeless> laszlok: gnight
<ToyKeeper> If I merge in an unrelated branch and it adds a file with the same name as a previously ignored/unversioned file, is there a way to make bzr not treat it as a conflict?
<ToyKeeper> Or, at least, not report a conflict if the files are identical?
<spiv> ToyKeeper: Well, you can just do "bzr resolve FILE" manually after the merge.
<ToyKeeper> Yeah, I do.  It just seems odd to conflict when the files are identical.
<ToyKeeper> ... just running some experiments for keeping $HOME in bzr.
<spiv> I know what you mean.  bzr is being conservative and so assumes they have different identities in that situation, regardless of content.
<ToyKeeper> I think I'll probably stick with my current svn-based home repo, but it's interesting to find ways to do similar things in bzr.
<spiv> It would probably be fairly easy to write a plugin to add a "resolve-harder" command that would notice that situation and auto resolve them for you.
<ToyKeeper> I'm using externals and partial checkouts and symlinks extensively in svn, so the approach is rather different with bzr.
<jelmer> laszlok, bzr-svn should be able to deal with branches/tags at non-top-level
<spiv> Maybe bzr should deal better with that case natively, although "unversioned file with same contents as added-by-merge file" does sound like a fairly rare case.
<ToyKeeper> spiv: Yeah, pretty uncommon.  I had never encountered it until I tried to do something funky.  :)
<spiv> It's also a bit confusing I think how bzr can have conflicts involving unversioned files; I've seen that surprise people (mainly in the context of the 'bzr up causes weird merge-conflicts-conflicts' bug)
<lifeless> laszlok: it worked for me:
<lifeless> $ bzr branches repo
<lifeless> JonoEdit/branches/0.1
<lifeless> JonoEdit/branches/0.2
<lifeless> JonoEdit/branches/0.9
<lifeless> JonoEdit/branches/Elleo-SoC
<lifeless> JonoEdit/trunk
<ToyKeeper> It's not very well-suited to tracking $HOME.  I love bzr for most purposes, but it's not as good as svn at being a versioned filesystem with different views on every checkout.
<lifeless> gst-chansplit/trunk
<laszlok> lifeless: what command did you use for conversion?
<lifeless> bzr $ cd /tmp/
<lifeless> $ mkdir jokosher
<lifeless> $ cd jokosher/
<lifeless>  bzr svn-import http://svn.jokosher.python-hosting.com repo
<ToyKeeper> Hmm, this still isn't fixed.
<ToyKeeper> w3m -dump http://www.jokosher.org/ | grep -i viagra | wc -l
<ToyKeeper> 18
<lifeless> oh yay hackage lol
<laszlok> lifeless: before it was copying x/1500 revisions, now its doing x/1391. So its not copying the entire repo
<laszlok> i guess it working now
<lifeless> laszlok: you might want to edit that homepage
<lifeless> laszlok: to remove the advertising spam :P
<laszlok> ToyKeeper: yeah we know but jono is too lazy to do anything about it
<lifeless> oh, only jono can edit ?
<laszlok> yeah its on his host
<lifeless> hah!
<laszlok> i dont think hes upgraded his wordpress in a while either
<lifeless> mailed him a nag
<laszlok> just reading the chan topic, was there a bitkeeper->bazaar converter before, or was it special for mysql?
<lifeless> there were some tools that could poke at bitkeeer
<Stumbles> i'm storing some php files in a bazaar branch and publishing it via my http on my website. Was surprised to see that you could use "bzr branch" to get the php files without them being executed. How does that work? If I try to get the php file, say with wget, it gives me the output of the php script.
<spiv> bzr branches are stored in special files in .bzr/ directories, rather than just as the original files.
<Stumbles> oooooh right, confusing the working-copy/repository issue
<Stumbles> thanks spiv
<spiv> Right.
<Stumbles> just got a bit of a fright that I might have been overlooking something that allowed people to download all my .php database config files ;)
<beuno> emgent, pong
<laszlok> lifeless: i think i found the problem; there was a branching-scheme = single-JonoEdit in the ~/.bazaar/subversion.conf from a previous checkout
<lifeless> laszlok: that would do it
<emgent> beuno: i saw your bzr-upload
<emgent> seems very good plugin :)
<emgent> are you packaging it ?
<beuno> emgent, thanks :)   jelmer has packaged it
<beuno> he's looking for a sponsor to get it into Debian
<emgent> oh nice!
<emgent> I was thinking but now is ok :)
<emgent> s/but/to package it but/
<beuno> emgent, cool, thanks anyway.  There may be other bzr plugins in need of packaging
<beuno> emgent, seems I found a sponsor, and it's being built now!
<beuno> (talk about coincidence)
<emgent> nice :)
<beuno> emgent, if you could request the sync into intrepid once it's uploaded, that would be great
<emgent> uhm.. but debian NEW package need FTP master work :)
<emgent> beuno: sure will do when i see it in debian :)
<beuno> emgent, yeah, and it's debconf now, so it will take a while
<emgent> s/see/will see/
<emgent> true :)
<emgent> ~1 month
<emgent> hhehehe
 * beuno crosses fingers
<emgent> Debian FTP Masters are very slow :)
<beuno> yeah, and even more so if they're full of bear on a beach in winter
<emgent> heheh true :)
<mxpxpod> can bazaar do partial branches?
<beuno> mxpxpod, partial as in history or as in files?
<mxpxpod> as in files
<mxpxpod> like, if I just want to grab one directory out of a branch
<beuno> you can't currently do that, no
<mxpxpod> is support for it coming?
<lifeless> mxpxpod: yes
<mxpxpod> lifeless: is there a blueprint for it?
<beuno> Verterok, ping
<Verterok> beuno: pong
<beuno> Verterok, hi!  Just saw you released xmlouput 0.5. Cool!   Just one thing, did you maybe link it incorrectly on the wiki?
<Verterok> beuno: let me check
<Verterok> beuno: yeap, copy & paste madness :P, thanks for pointing it ;)
<beuno> Verterok, :)    I wasn't sure which part was mixed up
<Verterok> beuno: fixed now
<beuno> Verterok, thanks
<Verterok> beuno: actually, thank you :)
<mxpxpod> lifeless: because I'm not seeing anything on it
<lifeless> mxpxpod: the concept is called 'views' and Ian Clatworthy has been doing most towards it
 * beuno heads to bed. Have to go pick up someone at the airport in 5 hours  :/
<mxpxpod> lifeless: ok, thanks
<lifeless> night beuno
<beuno> g'night lifeless!
<beuno> have a good weekend
<lifeless> you too
<beuno> Verterok, we should meet up soon and get the automatic testing on it's way  ;)
<Verterok> beuno: indeed
<Verterok> beuno: there are big chances that I'll be offline during saturday, maybe I can start hacking a proof of concept :)
<lifeless> auto testing?
<beuno> lifeless, we're planning to setup a server which auto-updates and runs the full test suite against all the plugins
<beuno> get reports
<lifeless> beuno: thats a good idea
<beuno> and maybe send them to the list, if people don't get annoyed by them
<lifeless> beuno: can I suggest separately running the set that my patch bundles?
<lifeless> (Preferrably by doing the bundling action and seeing what works)
<beuno> lifeless, so, full test suite, and then just the plugin's?
<beuno> we want to catch plugins that break bzr, and plugins that bzr breaks
<lifeless> the full test will include the bundled plugins
<lifeless> beuno: you saw the patch I'm referring to right?
<beuno> lifeless, nope, not that I recall
<Verterok> lifeless: that  sounds like a good start point, and from there start adding extra plugins :)
<lifeless> pls wait for BB
<lifeless> http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C1217210104.21600.106.camel%40lifeless-64%3E
<lifeless> that patch
<lifeless> ubottu: please be learning about bb, kthxshutup
<ubottu> lifeless: Error: I am only a bot, please don't think I'm intelligent :)
<lifeless> ubottu: hey, I told you to shutup alread
<ubottu> lifeless: Error: I am only a bot, please don't think I'm intelligent :)
<beuno> lifeless, ah, I understand. The more "official" plugins
<beuno> or the ones that will be bundled, so we need to pay more attention to
<lifeless> beuno: well specifically - *what the tarball will have and how it will install*
<lifeless> which is different from taking the list, installing from the plugins own installer
<beuno> lifeless, ok, sounds like a good idea. From the looks of it, they just get copied, instead of being installed.
<lifeless> they get copied into the tarball; and then the bzr installer copies them out again yes
<lifeless> thats the open bug in the patch discussion in fact :)
<lifeless> now, if someone wanted to fix that ... that would rock :)
<beuno> Verterok, we'll ping-pong over the weekend then, and see where we get, and when you're free
<beuno> lifeless, the bug being the individual setup's don't get run?
<lifeless> yes
<lifeless> most plugins won't give a rats
<lifeless> but some will
<lifeless> so we need to figure out how to do that gracefully
<beuno> ok, we'll see what comes out of it  :)
<beuno> I'm really off now
<beuno> night!
<Verterok> beuno: tomorrow I'll be at home..
<Verterok> beuno: g'night
<lifeless> beuno: btw
<lifeless> beuno: I've just done partial tree exports
<marianom> hi everyone, good night (at least here)
<marianom> a little question if you don't mind
<marianom> I was committing a change to LP, interrupted it by mistake and now I get a lock: http://paste.ubuntu.com/35401/
<marianom> I don't know how to break it. can anyone suggest a way out?
<lifeless> marianom: bzr should have broken the lock when you hit ctrl-C, unless you were physically interrupted?
<lifeless> anyhow, bzr break-lock URL
<marianom> lifeless: I was the cause of the error, however I did a break lock but get the unsupported error
<marianom> I used the same info I got from the error message to perform the action
<lifeless> marianom: oh the error is borked there is a bug
<lifeless> pass the url to your branch
<marianom> upps
<marianom> ok
<marianom> https://code.edge.launchpad.net/easyark/trunk
<lifeless> all sorted
<lifeless> ?
<spiv> marianom: bzr+ssh://bazaar.launchpad.net/~easyark/easyark/trunk
<spiv> (Or just lp:easyark should work too)
<marianom> sorry I didn't get it. Can I try to commit again or should I do something with the command you paste?
<spiv> marianom: once you've broken the lock you can commit again, yes.
<spiv> marianom: is that clear, or are you still stuck?
<marianom> in a minute I tell you spiv
<marianom> I did $ bzr break-lock bzr+ssh://bazaar.launchpad.net/~easyark/easyark/trunk
<marianom> but I get permission denied
<spiv> Oh, you need marplatense@bazaar.launchpad.net rather than just bazaar.launchpad.net I guess.
<marianom> ok let's see
<spiv> (I tend to forget that because I've set up my ~/.ssh/config so that I don't need that bit)
<spiv> Basically, you just need to use the same branch URL you used to do "bzr co" in the first place.
<marianom> ok, the lock is gone, committing now
<marianom> it worked. thanks spiv, lifeless for your support
<spiv> marianom: great!  Glad we could help.
<markh> I've got what seems to be a late regression on windows just before the branch 1.6 was made.  Should I submit it with 1.6 as the target, or still use -dev and note it should also be merged to 1.6, or something else?
<spiv> markh: either, probably.  I think BB won't pick it up if you don't target it to bzr.dev, though.
<spiv> Typically we use subject lines like "[MERGE][1.6] Fix frobnicator..."
<markh> spiv: ok thanks, I'll target .dev and make a note about 1.6
<markh> ah - then it implicitly targets both?
<spiv> Nah, we do that just for human benefit :)
<markh> ie, use that subject line, but attach a bundle targetting .dev?
<spiv> (Targetting .dev in the merge directive makes sense because usually bugs in release branches need to be fixed in .dev as well...)
<markh> BB then ignores the [1.6], but its a clue for humands :)
<markh> yeah
<spiv> Happily this doesn't happen often enough that we've really needed smarter tools :)
 * markh must have means humanoids
<spiv> Or human hands smooshed together.
<markh> yeah - I'm saying the tool can ignore the [1.6], but the humanoids can instead.
<markh> :)
<markh> lifeless caused the regression :)  os.listdir doesn't return errno.ENOTDIR on windows :(
<spiv> D'oh.
<lifeless> markh: yay!
<markh> :)
<lifeless> later everyone
<jonnydee> Hello lifeless, how are you doing? I did what you suggested yesterday and, indeed, a "bzr pack" on my repository which is located on the network share failed. I've attached it to the Bug report.
<jonnydee> hi, just a question: is it ok to change the title of a bug report when the problem has been narrowed down? I've done this right now, but now I wonder if this is appreciated or not.. Could someone give me an advice, please?
<spiv> jonnydee: yes, definitely
<jonnydee> ok, thanks a lot :)
<spiv> Thanks for gardening bugs! :)
<awilkins> markh: That's not the only lifeless-related not-a-directory error on windows ; I found one too
<awilkins> http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C489ACEB7.1010503%40gmail.com%3E
<jonnydee> Oh, no problem. I like being able to contribute at least somehow to the wonderful Bazaar community :)
<lopio> hi
<lopio> a simple question about CRLF: someone said a new feature about CRLF management will be introduced in bzr 1.6; have you got some more  details ? thank you
<awilkins> lopio: AFAIK line endings support is not going in because versioned properties are not going in either.
<awilkins> lopio: I personally find it less necessary with each passing year ; the only code editor I use that cares is the VB6 IDE, and I never edit that source on Linux anyway.
<awilkins> lopio: Do you have something badly behaved that messes with your line endings?
<lopio> my problem is that now we develop both under xp and hp-ux using cvs
<awilkins> And CVS is the thing messing with the line endings?
<lopio> when you checout file under xp a LF is added automatically and when you commit is removed; nothingg is done under HP and everything is right
<awilkins> lopio: Are your code editors line-ending aware?
<awilkins> (on XP)
<lopio> this is possible cause there is such a behaviour when you want to bypass this mechanism for example for binary file (cvs add -kb)  )
<awilkins> What are you using? (the windows notepad is about the only editor I know of that isn't ending aware now)
<awilkins> lopio: Can your windows folk not move over to using *nix line endings?
<lopio> for example if you open a .ksh file file with worpad this file is reformatted
<lopio> on the other side .bat file must contains CRLF on XP
<lopio> To manage your repository with cvs you have to : 1) add ascii file with cvs add 2) add binary files with cvs add -kb
<awilkins> lopio: It sounds like your biggest problem is that Wordpad is rude enough to change line endings without asking you.
<lopio> the xp cvs client add or remove LF when co and ci ascii file. nothing else
<awilkins> Yes, I understand the feature, I've tutored people on the SVN equivalent.
<awilkins> Although I find the SVN behaviour to be better (only do line endings when explicitly told to, not by default)
<lopio> I'm not the only developer so i don't know which editors could be used -)))
<luks> I don't like that the SVN approach is not user configurable
<awilkins> Using Wordpad for code is madness, I tell you, Madness!!!!!   ;-)
<luks> if a file has svn:native, I can't use LF on windows even if I want to
<awilkins> lopio: At any rate ; I've not seen line ending support being discussed in here or on the list, so I doubt it's going into 1.6 (unless it says so in NEWS, which it doesn't).
<awilkins> 1.6 is basically a wrap now in terms of features.
<lopio> someone said this cvs / svn mechanism could corrupt files and this is why could not be implemeted in bzr. On the other side i think this could be a blocking problem in a multiplatform environment.
<lopio> checkeol plugin is an attempt to solve it
<awilkins> The CVS flavour certainly can corrupt files if you forget to mark them as binary ; I've seen cases where this is so
<lopio> yes but it's a mistake not a corruption
<awilkins> Tell that to Visio when it can't load the file. "Oh, it's just a mistake.....
<awilkins> And you can't un-do it because there are a mixture of CRLF and LF sequences in there
<awilkins> That's why I like the SVN approach of treating everything as binary by default better
<lopio> i agree
<lopio> what about this answer in launchpad :
<lopio> question "CRLF management will be possible ?"
<lopio> vila answer "There is a work in progress regarding eol handling and keywords expansion that may find its way into bzr 1.6, search the <email address hidden> mailing list for 'content filter' to stay tuned."
<awilkins> My personal position is that line-ending munging is a feature that scratches an itch which should have gone away a long time ago ;
<awilkins> http://search.gmane.org/?query=content+filter&group=gmane.comp.version-control.bazaar-ng.general
<awilkins> There's a patch for it in the bundle buggy waiting approval
<lopio> awilkins thank you very much for your advice
<lopio> bye
<awilkins> hello again :-)
<awilkins> http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C4880CF60.2080805%40canonical.com%3E
<awilkins> The patch is there, if you want to test it out I'm sure Ian will appreciate any user reports
<lopio> hello
<lopio> -)
<lopio> thank you a lot for your link
<awilkins> You're welcome
<lopio> excuse me for my bad english and for my too simple question:
<lopio> what should i do? install bzr-eol?
<awilkins> lopio: For bzr-eol to work, you also need to be running a version of Bazaar with the content filtering feature in it
<awilkins> Which is not in the main line but is provided by the patch linked to
<awilkins> Or you can pull the branch linked to in the comment
<lopio> this patch is developed in a branch (as bzr-eol plugin) , right ?
<awilkins> The plugin is separate to the content-filtering branch
<awilkins> So you need to grab the content-filtering branch (or merge the patch to bzr.dev) to run the plugin
<lopio> Last question -) : after  dowloading this branch  how can i use the new bzr ? via absoluth path? thank you
<lopio> excuse me there is an install -(
<awilkins> lopio: You could build and install it (a slightly tall order on Windows), but it's probably enough to put the bzrlib on your PYTHONPATH
<awilkins> (and remove the old one, of course)
<awilkins> Well, might not have to remove the old one if the new one is first on the path.
<lopio> now i'm under gentoo and i see 1.6b4 -)
<awilkins> I suspect you've just installed it then :-)
<lopio> in the afternoon i'll download and try  the bzr-eol
<lopio> see you later !!! my wife is calling me -)
<awilkins> lopio: Just cd ~/.bazaar/plugins ; bzr branch lp:bzr-eol eol
<lopio> thanks
<awilkins> Wices eh :-)
<awilkins> *wives
<lopio> cd ~/.bazaar
<Cilyan> Hello everyone !
<Cilyan> I have a little question
<Cilyan> I use bazaar to control versions of a current work, only for personal use (a sort of advanced backup)
<Cilyan> The directory tree is Laas/Rapport, Laas/Simulations Laas/Automatique ...
<Cilyan> And at the beginning, I only wanted revisions for my report, so I runned bzr init in Laas/Rapport
<Cilyan> But I'd like now to use bazaar in the root directory, but if possible I'd like to keep the commits I have done in Rapport. Is it possible ?
<Cilyan> In other words, is it possible to move the root of a bzr vc ?
<jonnydee> Cilyan: You could "bzr mv Laas/Rapport Laas/Laas/Rapport"
<awilkins> "Laas" isn't versioned
<jonnydee> Yes, but what could actually do is to put The versioned Rapport directory under a versioned Laas Directory
<jonnydee> So you will have a directurey structure like Laas/Lass/Rapport
<awilkins> Yes, he can just move his "Rapport/*" to "Rapport/Rapport/"
<awilkins> Then rename "Rapport" to "Laas", and move all the old "Laas" stuff to new "Laas"
<Cilyan> So, I have to first init a branch in Laas ?
<awilkins> THen add it
<awilkins> Cilyan: No
<jonnydee> awilkins: that's exactly what I meant
<awilkins> Cilyan: Make a new Rapport folder inside Rapport, move the stuff into it, then copy the other folders from "Laas" into your working tree and add them
<jonnydee> right :)
<Cilyan> Oh, yes, ok :)
<Cilyan> brilliant
<Cilyan> I try at once
<awilkins> You're not moving the root of the tree, your're moving the the stuff in the tree into a lower folder
<jonnydee> exactly
<jonnydee> This could be maybe an idea for a new plugin. A plugin which simulates extending version control to some parent directory...
<Cilyan> I should I proceed if the files are in the root dir ?
<jelmer> beuno, thanks for helping bzr-upload again, also to mlt!
<Cilyan> oops, forget that ^^'
<beuno> jelmer, :)   I made sure lintian didn't complain this time
<awilkins> Could someone with BB privs review http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C489ACEB7.1010503%40gmail.com%3E
<awilkins> I know it's boring but the regression it reverses breaks tests on Windows.
<awilkins> lifeless: You approve it. You submitted the code that broke it, you fix it :-)
<Odd_Bloke> awilkins: People will get to it in time. :)
<awilkins> Odd_Bloke: It should really be in 1.6 as well as dev, IMHO
<Cilyan> Will the files moved keep this directory tree if I need to revert to a previous revision ?
<awilkins> Cilyan: No
<Cilyan> So they will extract like they where before move
<Cilyan> Allright, no matter
<Odd_Bloke> awilkins: Make a note on the list to that effect.
<Odd_Bloke> Right, I'm off.  See everyone in a week and a bit.
<Cilyan> Thanks everyone, it works like a charm !
<Cilyan> Bye
<lifeless> we will be getting line ending support
<manishtech> can anyone help me out a little with bzr checkout?
<jonnydee>  I'm relatively new to bzr, but maybe I can...?
<manishtech> jonnydee: actually am from svn background, so I am finding it a bit difficult to checkout any code to my machine
<jonnydee> My background is svn, too
<jonnydee> So what is your question
<jonnydee> ?
<manishtech> jonnydee: am finding bzr a bit complicated at beginning, i need to checkout tangocms branch on my computer
<manishtech> most of the bzr commands are giving error
<jonnydee> just do "bzr co URL-TO_BRANCH"
<jonnydee> do you have to connect to a svn-repo?
<manishtech> jonnydee: i didnt get you... svn-repo?
<manishtech> thanks trying bzr co
<manishtech> i heard there was something called branch in bzr i tried itbutin vain
<jonnydee> I mean do you want to check out a project from a subversion repository via bzr?
<manishtech> no..  i need to checkout code from launchpad itself
<manishtech> jonnydee: Tangocms is the project which I wanted
<jonnydee> well, there is a command "bzr branch", but if you use "bzr checkout" it does feel like a subversion checkout
<jonnydee> ok, then you should not do a checkout but you will want to branch
<jonnydee> bzr branch URL-TO-PROJECT
<jonnydee> just a moment
<manishtech> jonnydee: this is the page which I get for TangoCMS https://launchpad.net/tangocms
<manishtech> jonnydee: I tried " bzr branch https://launchpad.net/tangocms "
<manishtech> this is the error which i got bzr: ERROR: Not a branch: "https://launchpad.net/tangocms/"
<chadmiller> manishtech: See that "code" section?
<jonnydee> try "bzr branch https://code.launchpad.net/~vcs-imports/tangocms/trunk-imported"
<chadmiller> That url is not the branch location.
<manishtech> chadmiller and jonnydee: thanks... trying
<jonnydee> the one I mentioned should be the right one
<chadmiller> Instead, find the actual branch location on the web page.
<chadmiller> jonnydee's is likely right.  Also, projects at launchpad have a shortcut.
<jonnydee> lp:xxxx -- I know....
<jonnydee> or do talk about something different?
<chadmiller> You got it, j,  lp:~vcs-imports/tangocms/trunk-imported
<jonnydee> AFAIK for using lp:project you should have a ssh-key configured
<manishtech> chadmiller: means the syntax should be bzr branch ï»¿lp:~vcs-imports/tangocms/trunk-imported ?
<radix> jonnydee: nope
<chadmiller> manishtech: One additional change.  The last part of the branch URL is not very useful, often.  Rename it by specifying a different name at the last parameter.
<chadmiller> "bzr branch lp:~vcs-imports/tangocms/trunk-imported tangocms-trunk"
<manishtech> jonnydee: ssh key is configured
<jonnydee> ok... I seee
<manishtech> trying.... checking
<manishtech> thanks all.... its working
<chadmiller> manishtech: Are you comfortable with the distributed nature of this stuff?
<manishtech> chadmiller: worked on svn... not much, but have idea..
<chadmiller> You're getting an exact copy of what's on the far end.  The only criteria we don't call your new branch the official trunk are social.  They're the same except in human behavior.
<jam> Just to note, if someone associates a branch with the development focus of a project "bzr co https://launchpad.net/tangocms" would actually work
<jam> (it does for 'bzr' for example)
<jam> Though I would recommend "bzr co lp:tangocms" at that point, because it is shorter :)
<jonnydee> jam: so this has to be done on the launchpad site directly
<jonnydee> ?
<manishtech> jam: how are co and branch different... its a silly question
<jonnydee> co more behaves like svn
<jonnydee> with one exception:
<jam> jonnydee: Registering a "focus of development" does, indeed, need to be done on LP
<jonnydee> you build up remote history and local history
<jam> manishtech: I can give you the detailed or the overview
<jonnydee> so when you "bzr unbind" you still have access to the complete history contents
<jam> jonnydee: I would also mention that if he is branching over http: he can't commit to a checkout
<manishtech> thanks jonnydee ... Its on 3/5
<chadmiller> manishtech: in "checkout", you don't get a full copy of the history.  You rely on your machine to be able to reach launchpad to make major changes.
<jam> well, under *normal* circumstances
<manishtech> chadmiller: means I should always use branch?
<jam> chadmiller: not true, only if you checkout --lightweight
<jam> It will connect to launchpad at commit time, yes, but all stuff like "bzr log/diff/status/etc" are only local
<chadmiller> manishtech: Theoretically, "checkout" could be faster than "branch", so that could be a reason to use it.  I think there's little difference at present.
<chadmiller> jam: Ah, thanks.
<manishtech> chadmiller: I was trying this, but got stuck up with the URL's http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html
<jonnydee> manishtech: by using a branch all commits go locally. when you want to synchronize with remote repository you do a "bzr push"
<manishtech> jonnydee: means "bzr push" is equal to "svn commit" ?
<jonnydee> commits to a checkout go directly to remote repository, too. (unless you use --commit-local)
<manishtech> jonnydee: one ques, if i checkout a branch and then made a commit on it and got one branch by using "bzr branch" and then made a commit, what's the difference?
<jonnydee> when you work on a branch you can do commits. they will go into your local repository. only when you do "bzr push" will all your local commits be transfered to the remote repository
<jam> jonnydee: don't confuse him with too much detail just yet :)
<jonnydee> when you do commit on a checkout it will go immediately into the remote repository
<jonnydee> jam: you are right -- it's confusing. but it's also the first thing I tried to understand before I started using bzr
<manishtech> jam: ahem, thanks for the care... but i dont think everyone can make a commit to remote repository? we need to be authenticated... is it just by ssh key?
<jam> manishtech: so, first lets find out what *you* want to do
<jam> Are you working on the project?
<jam> Are you just an interested fan
<jam> or one of the main devs?
<manishtech> jam: i am an interested person.. who wants to work on tangocms project..
<manishtech> am not a main dev.... hope i can be one day
<jam> manishtech: ok, as you are unlikely to be given priviledge to commit directly to their branch
<jam> you want to use "bzr branch" to create a local copy that you can modify
<jam> If you are used to svn, think of it as something like doing
<jam> svn branch their/trunk their/branches/myworkspace; svn co their/branches/myworkspace
<jam> except the final repository is on *your* machine, separate from theirs
<jam> manishtech: with me so far?
<manishtech> jam: didnt get what you meant "with me so far"
<jam> manishtech: Do you understand what I have said to this point
<jam> well written, since I didn't speak :)
<manishtech> jam: looks like I missed out something
<jam> manishtech: ok, I'll try a different tack
<manishtech> ï»¿ï»¿jam: i have used code.google.com , there are seperate authorized people on each proj who can commit, so how to find out who can commit to remote branch?
<jam> With SVN, you normally do "svn co URL", right?
<jam> At which point you have files you can modify locally
<manishtech> jam: yeah
<jam> and when you commit, it sends your changes back to URL
<manishtech> yes... that way, and if am authorized to commit on the repo
<jam> manishtech: Bazaar allows you to work it 2 forms
<jam> With 'bzr checkout', when you commit, it sends your changes to the remote URL
<jam> and yes, you wouldn't be able to without authorization
<jam> (it *also* usually creates a copy locally, so you have access to it when you are not online)
<jam> manishtech: Bazaar *also* lets you work a different way
<manishtech> yes, that's the svn way
<jam> which is with "bzr branch URL" it copies the repository from remote to local
<jam> so when you commit, it only stores the changes locally
<jam> And as you aren't accessing the other people's server, there is no way they can give authorization or not
<jam> It is, indeed, by design
<jam> However, when it comes time to share your changes, either they need read access to your changes, or you need write access to push your changes to somewhere they can see.
<jam> Launchpad can facilitate this
<jam> because it lets anyone host their own branch in their own location
<jam> (and access control is done via ssh-keys and group permissions)
<manishtech> means i can create a branch on launchpad itself...
<manishtech> thanks everybody... now i need to work on it... Got the basics, hope now I can learn additionally in due course...
<jam> manishtech: I would recommend the tutorials if you haven't tried them yet
<jonnydee> mansihtech: yes, you can host your own branch on launchpad
<manishtech> jam: i was trying the tutorials when I got stuck... I always feel that the first step is bit tough if it has to be tough, furthur one can manage
<jonnydee> so the developers of Tangocms can have a look at your branch and merge your changes into their official branch
<manishtech> jonnydee: its just a start, i will to read the whole code and see what is to be done... thanks a lot
<jonnydee> you are welcome :) -- have fun!!!
<manishtech> jonnydee: thanks
<manishtech> jam: thanks
<jam> manishtech: well, I'm glad you came here to ask, and if you *talk* to the tangocms guys, you might recommend associating a branch with their development focus
<jam> Then they get "bzr branch lp:tangocms" for everyone to enjoy :)
<manishtech> jam: i have seen people having problems but still dont use irc to solve it.. they feel it a bit geeky.. dunno why.. people here ae some helpful :)
<manishtech> *so helpful
<manishtech> sorry for the typo :P
<jonnydee> manishtech: this is what I experienced, too.
<jonnydee> This is really a nice community here
<manishtech> jonnydee: this is my fist entry in #bzr , will be quite active in future... :)
<jonnydee> that'*s excatly the reason why I am here. I would like to give some help back!!!
<awilkins> I think it intrinsically comes from the mentality that creates a DVCS ; DVCS is inclusive (anyone can branch and commit), not exclusive (central control). That said, the guys in the subversion channel are also great :-)
<awilkins> I remember Ben Collins-Sussman himself uploading a patched build of svn to my SFTP server to examine a partocular issue.
<jonnydee> awilkins: so Ben should use Bazaar to develop svn ;P
<awilkins> Can't really see it happening, that would be like Bazaar migrating to git :-)
<jonnydee> yes, I agree
<jonnydee>  :)
<Necoro> "Please install git to use the live bzr branch" ^^ ... ok - perhaps if used as a naive excuse to avoid bootstrapping issues ^^
<awilkins> Maybe someone will make a "Bazaar" porcelain for git - that would depend on it :-)   (Gitaar?)
<jonnydee> Gitaar..."sounds" funny :)
<Necoro> btw: if I want to have something to control a document repository - what should I use?
<rocky> jelmer: you using bzr+trac ok?
<LeoNerd> awilkins: Bonus points if you can get some mentions of "strings" in there
<Necoro> with "document repository" I mean a repository of documents (scientific papers or letters), where the documents themselves never or rarely change
<Necoro> but might be large ;)
<Necoro> is bzr designed to be used there? - or is it just overkill (esp. because I double sizes)
<jam> awilkins: well, there is bzr-git, which should eventually be able to treat a git repo as "just another bzr branch" like we have for bzr-svn
<jam> I think ATM, it can do "bzr log" on a git repo
<awilkins> jam: Does that use the git plumbing? It sounds like it really should just be a "porcelain"
<jam> awilkins: Last I checked, it just did "git foo" and then interpreted the results
<jam> so "git cat --tree", etc
<jam> It is a bzr plugin, though, not a mod to git
<awilkins> Yeah, but git is just a bunch of shell scripts ; so a bunch of Python scripts is not such a stretch
<awilkins> (plus the nasty C bits of course)
<jam> awilkins: IIRC, there were actually some python and perl and XX bits in git
<awilkins> What is XX
<jam> And the C bits are pretty much focused on being an app and not a lib
<jam> awilkins: "etc"
<awilkins> Ah
<jam> Just saying that it is *mostly* shell porcelain, and then a lot of other stuff
<jam> not sure how much
<jam> so yeah, you could build something on top of git that looks like bzr, but it makes more sense IMO, to build something under bzr that interfaces with git repos
<pickscrape> How would bzr handle me making a lightweight checkout of a checkout?
<pickscrape> Specifically, what would happen on commit?
<awilkins> pickscrape: It commits to the co but doesn't update the tree, and the revision is not propagated to the bound branch
<pickscrape> Would be really smart if it went all the way up the chain :)
<pickscrape> The tree I'm not surprised about though
<jonnydee> but what would happen in turn of merge conflicts...?
<awilkins> Might be difficult though ; you might not have access to the bound branch of the co
<jonnydee> (I mean somewhere up the chain)
<pickscrape> Indeed
<pickscrape> I'm really trying to work around a limitation in my text editor really, which follows my 'active' branch symlink and opens the actual file
<pickscrape> Which makes moving the symlink not do what I want it to do.
<jonnydee> lifeless: what do you think? will solving bug https://bugs.launchpad.net/bzr/+bug/255656 be of high importance? I mean is it likely that it will be focused on in one of the next releases? I'm askinf because if not I have to figure out another feasible solution than hosting the repo on a network share...
<ubottu> Launchpad bug 255656 in bzr ""bzr: ERROR: [Errno 22] Invalid argument" when "bzr pack" is executed manually or when "autopack" is triggered on a repository located on a windows network share" [Undecided,New]
<jam> pickscrape: try it, I believe it *does* propagate the changes
<jam> you only get 1 level of bound to work, but it should at least manage that
<pickscrape> jam: ooh, I will then :)
<Snaggen_> I'm thinking of setting up a BundleBuggy with a PQM in the same way as bzr.dev has it. As I understand you send the patch to BundleBuggy and when it is approved it is submitted to PQM that performs all the tests and then perform the merge. But how do you get BB to send to PQM?
<jam> Snaggen_: not quite right
<jam> We have BB monitor the mailing list
<jam> we don't send things to it directly
<Snaggen_> jam, yes, my bad
<jam> And we send directly to the PQM, it isn't sent from BB
<jam> (bzr-pqm is the plugin we use)
<jam> to add 'bzr pqm-submit -m "pqm commit message"'
<Snaggen_> jam, so BB monitors the list. then when a patch is approved what does it do?
<jam> BB doesn't do much but *track* patches
<jam> humans submit them to PQM
<jam> and BB also tracks the branch
<jam> so it can see when a patch lands
<jam> at least, for Merge Directives, plain patches need manual intervention.
<Snaggen_> So when a patch is approved you manually submit it to PQM?
<jam> Snaggen_: yes
<jam> We've wanted to have a "Submit to PQM" button on BB
<jam> just hasn't happened
<jam> it might be more likely after some of the PQM updates land from Odd_Bloke
<jam> to make it friendlier, etc.
<Snaggen_> jam, would it be interesting att all to have a "auto send approved patches to PQM" feature?
<Snaggen_> jam, or is a button prefered?
<jam> I'm a bit leary of auto-send
<jam> leery
<jam> Just because sometimes something gets approved, but should really wait a day or two
<jam> in case there are objections
<Snaggen_> jam, ok...
<jam> lots of people have votes, I trust some in certain areas more than others
<jam> so... I think having that feature would be neat
<jam> I don't know that we would turn it on for bzr
<Snaggen_> jam, I see... I'm looking in to use BB and PQM for code review and regression testing... if we get to a point where it is interesting enough (which I hope to get to quite soon) we might spend an hour or two to do some adaptions... but we'll see
<jam>  Snaggen_: sure
<jam> I would just mention Odd_Bloke has a lot of nice updates for PQM pending review
<jam> So you may end up with something nice in a week or two.
<Snaggen_> jam, does he have a branch with his work in lp?
<jam> Snaggen_: AIUI he has several branches, just a sec
<jam> Snaggen_: http://bundlebuggy.aaronbentley.com/project/pqm/request
<Snaggen_> jam, and that is PQM... auto-submit would be done in BB I guess... using the bzr-pqm plugin?
<jam> Snaggen_: well, I would expect that once PQM could support an XML-RPC request, then BB would use that to submit merges.
<jam> Further, I think PQM needs to support merge directives directly
<Snaggen_> jam, or would you prefer XML-RPC request.
<jam> Right now, you have to have a public branch for it to merge
<jam> Both of which Odd_Bloke worked on (Daniel Watkins)
<Snaggen_> jam, Ok... if I go down that road I'll lock at the XML-RPC stuff
<jam> The current issue is that lifeless is the maintainer of PQM, and he's a bit overworked right now to review the changes
<jam> It *will* happen, just not sure when
<Snaggen_> jam, I'll go straight to the source then and look att Odd_Blokes RPC branch then
<pickscrape> Is there any difference between bzr checkout and bzr checkout --lightweight if the two branches are both in the same shared repository?
<dato> I don't think so
<dato> (though I believe you'd save a ridicously small amount of bytes :P)
<pickscrape> I'm wondering if one or the other might trigger a slightly more optimal code path for example over the other one.
<pickscrape> Is there a way to bzr branch and have it not create a working tree explicitly?
<jonnydee> pickscrape: if you branched into a shared repo which had been configured not to contain a working tree... but this is not what you intend -- I guess....
<pickscrape> No, this use case is that I have a shared repo that I want to contains a mixture of branches with and without trees.
<jonnydee> but you can configure a tree-less branch into a tree-containging one
<jonnydee> I think it's to be done with "bzr reconfigure"
<pickscrape> Yes, but a --no-tree option would be a lot simpler :) Especially if you want the repo to default to creating a tree.
<jonnydee> yes, of cource, I agree
<jelmer> jam, bzr-git can fetch data from git repos as well
<jam> jelmer: does it get things like "last modified" for directories correct? That was always a hard part for me and formats that don't track directories explicitly
<jam> like, renaming the last file out of a directory deletes it
<jam> etc
<jelmer> jam, I'm not sure
<jelmer> jam, I implemented the .texts and revisiontree interfaces
<jelmer> and fetch suddenly worked out of the box
<jelmer> it was kinda scary, really
<jam> sure, but getting the Inventory object correct is the really tricky part
<Odd-rationale> Hello. I'm using 5-a-day. I have run "5-a-day --add-team <team>". It create the appropriate ~/.5-a-day-<LPID>/team file. But for some reason, i cannot get it uploaded to my bzr branch. The data file pushes fine, however. So is there a way I can force it? Thanks!
<Odd-rationale> BTW, this is for the GBJ :P
<jonnydee> hello, I would like to play around a bit and try to write a plugin for bzr. Can anyone suggest me a powerful python IDE (except emacs)?
<jonnydee> I mean debugging support etc
<jam> jonnydee: I personally like Vim a lot :)
<jam> But as for real IDEs
<jam> I would go with http://www.wingware.com/
<jam> It's vim text-editing mode wasn't very good last I used it, but I've heard its gotten better.
<jonnydee> vim...I merely thought of something like a real ide....
<pickscrape> There's a free one called Eric
<jam> I understand the idea of a nice ide, but since 90% of my time is editing text
<jam> I find a nice *text* editor is the most important
<jam> A good test suite + pdb is usually enough for the debugging side
<jam> Again, an IDE would probably help there
<pickscrape> jam: I agree. Editors seem to really lack in what I consider to be basic editing features.
<jam> but it would have to play nicely with our test environ
<pickscrape> Gah, I mean IDEs lack :)
<jam> pickscrape: There was supposed to be an IDE, that was able to combine your preferred components
<jam> so it would embed vim for editting
<jonnydee> has anyone tried PyDev for Eclipse?
<jam> and various other tools
<jam> jonnydee: I've tried some Eclipse, but again "Vim" mode sucked
<jam> and might have been better if I paid for it
<jam> but their teaser didn't even work
<jam> which didn't inspire me to buy the product :)
<jam> The other problem with Eclipse is that it wanted to configure 1 project per location
<jonnydee> ok I see... well I don't want to spend money, either
<jam> which means it doesn't like feature branches very well
<jam> Eclipse had nice syntax highlighting
<jam> and *could* have been good
<jonnydee> jam: that's a good point
<jam> But it did seem to have a strong java bent
<jam> jonnydee: I've since switched to having a small number of working trees that I 'bzr switch' between branches
<jam> so Eclipse might like that more
<jam> but it really wants you to create Eclipse projects
<pickscrape> I struggled to get decent visible whitespace for Eclipse.
<jam> Oh, and Eclipse wanted to use absolute paths
<jam> so you couldn't create a project, and just copy it around :(
<jam> My Eclipse-fu might be weak, though, as I don't see how people would stand for abspaths all the time
<jonnydee> jam: yes, I know this problem from Java. Absolute paths suck....
<jam> it doesn't even work between *developers*
<jam> I might try it again sometime, but in the short term... it didn't work so well
<pickscrape> My current preference is jedit, though I am always on the lookout for something better.
<jonnydee> ï»¿ok, I'm a bit surprised now, because I thought there exists a good IDE. But it seems like one is better of with simple tools
<pickscrape> jonnydee: you might want to have a look at Eric. It's not bad
<jonnydee> ok, I'll have a look at Eric. I think for my first experiments it should be good enough
<jonnydee> does it support debugging?
<jam> pickscrape: this one? http://die-offenbachs.de/eric/
<jam> I used to use Scintilla as my text editor for a while
<jam> It was pretty nice
<pickscrape> Yes, that's the one. I've not really used it in anger though
<jam> just not *as* good as Vim
<jam> Nothing compares to "." :)
<pickscrape> I use vim for quick editing from the command line.
<jam> jonnydee: http://die-offenbachs.de/eric/images/eric4-screen-03.png
<jam> Integrated unittest running
<jam> jonnydee: debugger in action: http://die-offenbachs.de/eric/images/eric4-screen-02.png
<jonnydee> ok, so thank you very much for your comments and your help. :)
<jonnydee> ok, cool. Eric seems to be the tool I've been looking for... the screenshots look nice :)
<jonnydee> very very nice ... :D
<jonnydee> btw Eric seems to be also in the ubuntu package repository.... I'm installing it right now...
<jam> it does look shiny, just need to know if it *works* right :)
<pickscrape> From my experimentation, the editor wasn't up to jedit's level, but it wasn't terrible.
<jonnydee> well, I can give you some report when I tried it...
<pickscrape> I've heard a lot of good things about 'scribes'
<jonnydee> There is a Flash demo of scribes: http://scribes.sourceforge.net/demo.htm (but it seems to me like this tool is something for people experienced in programming using python...so I think Eric is a better choice--for me, at least)
<pickscrape> Yes, scribes is an editor rather than an IDE. This conversation just reminded me to try it. :)
<jonnydee> well, I think it could be a good choice for you, because you know the language and the APIs already (I guess ;) )
<jam> well, I can get it to run a couple individual tests
<jam> but I can't get it to actually run the whole bzr test suite
<jonnydee> So you can just write down your code and et good support by scribes
<cgrindsXO> Is it possible to pull part of a branch? For example my root is c:/stuff. It contains lots of, well, stuff. I'd like to go to an unrelated dir and do a pull like so: "bzr pull c:\stuff\fan\fansh" but that doesn't work
<Necoro> cgrindsXO: perhaps you should have used a shared repository instead of one large branch ;)
<cgrindsXO> right - I think I started using bzr before shared repos existed. The original reason I went with one large branch is it made it easier to backup one thing instead of all my projects individually
<Necoro> cgrindsXO: bzr help split
<cgrindsXO> Necoro: thxs I'll go read
<cgrindsXO> C:\stuff>bzr split fan
<cgrindsXO> bzr: ERROR: No WorkingTree exists for "file:///C:/stuff/fan/.bzr/checkout/".
<Necoro> cgrindsXO: perhaps you need to update the repository formate to something known subtrees first
<Necoro> but this is only a guess
<Necoro> testing it on a branch of mine, it worked
<cgrindsXO> yeah I tried upgrade and it said
<cgrindsXO> C:\stuff>bzr upgrade .
<cgrindsXO> bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format.
<Necoro> cgrindsXO: try: bzr upgrade --rich-root-pack
<cgrindsXO> Necoro: sigh apparently not my day. bzr: ERROR: Revision {('chris@g.org-20080731173055-6pzgw3yoz1rha0um',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x02010C30>".
<Necoro> oh
<Necoro> hmm ... some bzr-dev here to help?
<jelmer> cgrindsXO, while upgrading to rich-root-pack?
<cgrindsXO> yes
<jelmer> cgrindsXO, please file a bug
<cgrindsXO> jelmer: ok will do
<cgrindsXO> jelmer: https://bugs.launchpad.net/bzr/+bug/256199
<ubottu> Launchpad bug 256199 in bzr "Error when upgrading repo" [Undecided,New]
<jelmer> cgrindsXO, thanks
<jelmer> hopefully one of the australians can have a look on monday
<lifeless> jam: will you be wowing?
<pickscrape> World of Warcraft?
<lifeless> pickscrape: yah
<pickscrape> Ah. You've said that a couple of times and wondered what it meant :)
<Kinnison> lifeless: which realm?
<lifeless> caelsytraz
<lamalex> Is there a way to see when the last time a file was edited was?
<lamalex> rather, the revision number of the last edit
<pickscrape> bzr log -l 1 <filename> ?
<lifeless> lamalex: annotate probably is best today
<lamalex> i actually just found log
<lamalex> pretty much exactly what i needed
<lifeless> lamalex: worth filing a bug I think, noone has asked for that, but I think ls would be a good place to have that be visible
<lamalex> sorry for not rtfm'ing first
<lamalex> no, log was basically it
<lamalex> thanks
<Kinnison> lifeless: presumably not a european realm :-)
<lifeless> Kinnison: nope sorry :)
 * Kinnison grins
 * Kinnison has to admit that he never would have pegged you as a WoWer :-)
<lifeless> Kinnison: well its not on my laptop
<lifeless> so you'll only catch me wowing from home
<lifeless> right now I'm farming mats for my priests epic flying machine
<Kinnison> Heh, I need to be bothered to farm for mats so I can waste 'em skilling up to make an epic flying machine
<pickscrape> Sounds like quite a responsibility.
<Kinnison> heh
 * Kinnison loves the bizarre language which goes with WoWing
<LaniSwe> Hi! I'm trying to setup Bazaar with a central repository on my server. I'm using the "Centralized workflow" tutorial: http://bazaar-vcs.org/Tutorials/CentralizedWorkflow. Unfortunately I'm stuck on 2.3: "Setting up a remote Repository". The tutorial there tells me to run the command: "bzr init-repo --no-trees sftp://centralhost/srv/bzr/", but it does not explain how I should configure the server?
<lifeless> Kinnison: #ubuntu-wow is more topical :)
<LaniSwe> If I just execute that command I get an error that tells me that the directory does not exist. If I create that directory with "sudo" and then run the command again I get an access denied message.
<LaniSwe> So I don't know if I'm on the right track here. As I don't what to create a user account for every user that needs to access the repository.
<LaniSwe> I just want to grant public ssh keys, is that possible?
<LaniSwe> Anyone here that have used Bazaar over ssh?
<pickscrape> We use bzr+ssh
<LaniSwe> pickscrape: Yes I've seen that command, but how do you setup the ssh public keys in a central repository on the server?
<pickscrape> ssh public keys is purely an ssh thing: if the user can ssh to the server via their key, they can do the same with bzr too
<LaniSwe> But I don't want to create a separate user account for every Bazaar user. In git you can create a specific 'git' user on the server and then just add in a file what public keys that should have access to the repository, is there no such thing in Bazaar?
<pickscrape> We just use one 'bzr' user
<pickscrape> We had to add something to ~/.ssh/config for every user though to get ssh to use the 'bzr' user when connecting to that server
<LaniSwe> Ah, ok. But then it will always use the bzr user as default for that server? That's not ideal either, as the server is also used for other things.
<lifeless> LaniSwe: so we took the approach that folk wouldn't want us implementing security sensitive code like user management unless absolutely needed
<lifeless> LaniSwe: there are several options to avoid system users:
<pickscrape> Yeah. I think you are supposed to be able to do it using ~/.bazaar/authentication.conf, but I couldn't get it to work.
<lifeless>  - http with either webdav or bzr+http; in this scenario apache does the authentication
<lifeless>  - a custom sftp server port which doesn't use system users (e.g. twisted has one of these); I believe some-assembly-required for this option
<lifeless>  - doing something like pickscrape describes
<lifeless> I'd say that http is the simplest and most robust
<pickscrape> lifeless: does the bzr+http method allow per-branch authentication?
<LaniSwe> Ah ok, in this case http is acceptable but in future scenarios it might not be. Then encryption might be needed. The .bazaar/authentication.conf sounds ideal, to bad you couldn't get it to work pickscrape.
<lifeless> LaniSwe: we support ssl
<LaniSwe> Ah ok :)
<LaniSwe> Just another thing for me to learn how to setup then ;)
<lifeless> its pretty easy, lots of apache howtos
<LaniSwe> I've just started to like ssh and how simple it is to use and setup :)
<LaniSwe> ok
<lifeless> I love ssh
<LaniSwe> Well I would go that far ;) but it's really nice :)
<pickscrape> lifeless: what are the connection setup overhead differences between http and ssh like?
<LaniSwe> lifeless: Are you aware of an option for specifying the bazaar user in the ~/.bazaar/authentication.conf file that pickscrape talked about?
<lifeless> pickscrape: should be minimal
<lifeless> LaniSwe: authentication.conf is just a credentials cache AFAIK
<LaniSwe> ok
<pickscrape> I couldn't get it to force the ssh user
<lifeless> pickscrape: you can set ssh users by ~/.ssh/config
<LaniSwe> pickscrape: But when I think about it, how would that work? Wouldn't that make all checkins etc come from the bazaar user?
<pickscrape> Yes, that's what we did. However, that means always connecting to the server in question via that user
<lifeless> LaniSwe: no it wouldn't
<lifeless> LaniSwe: checkings are really just a form of push; the data is generated on the client
<LaniSwe> lifeless: ok, so the "bzr whoami" will be used then?
<lifeless> yes
<LaniSwe> ok :)
<LaniSwe> But if pickscrape couldn't get it to work I don't think that I will either :/
<pickscrape> We got the ~/.ssh/config method to work fine.
<pickscrape> It's just not *quite* as convenient as being able to define it in a bzr-specific place.
<LaniSwe> I guess that I could make a separate dns entry like bzr.myserver.com, and then if just myserver.com points to the same ip shouldn't matter? I should then be able to specify a default user for just bzr.myserver.com in the .ssh/config?
<pickscrape> LaniSwe: Yes, that appears to work as you're expecting. The matching is done on the hostname, not the IP address.
<LaniSwe> pickscrape: Ok thank you very much for your help and pointing me in the right direction!
<pickscrape> pleasure :)
<LaniSwe> You to lifeless!
<LaniSwe> pickscrape: You don't happen to have a good reference for the config file? ;) Or is it in the man page maybe? ;)
<lifeless> LaniSwe: my pleasure
<lifeless> man ssh_config
<LaniSwe> ok!
<pickscrape> At the end add: Host <hostname> (newline) User <username>
<LaniSwe> Ok!
<LaniSwe> I'm going to try this out tomorrow. Time for bed now as it is 12:23 am over here now. Thank you for being so helpful and have a nice day/night ;)
<lifeless> sleep well
<mvo> what does the error: http://paste.ubuntu.com/35690/ mean?
<lifeless> I so want to say "bzr never prints error: http://paste.ubuntu.com..."
<mvo> heh :)
<lifeless> also its a bug indicating a deeper problem
<lifeless> that is, its a symptom
<mvo> I guess in this case using a pastebin was not really needed
<lifeless> latest bzr's should show the real error
<mvo> that is bzr 1.5
<dato> oh
<dato> he left
<lifeless> dato: you know him ?
<dato> no
<dato> but I would've told him he doesn't need a DNS entry
<dato> Hostname blablabla
<dato>   Username foo
<dato>   Host 1.2.3.4
<lifeless> oh right :P
<mvo> lifeless: do I need a more recent bzr? is there a workaround (like using sftp instead of bzr+ssh etc?
<lifeless> or even host foo.ar
<dato> yep
<lifeless> mvo: well what were you doing
<dato> s/told him/told them/
<mvo> lifeless: I did a bzr commit on a branch that is bound to bzr+ssh://bazaar.launchpad.net/%7Eubuntu-core-dev/apt/ubuntu/
<lifeless> mvo: so, not sure tbh
<lifeless> check ~/.bzr.log
<lifeless> may be more details there
<mvo> lifeless: some info in http://paste.ubuntu.com/35692/
<lifeless> statik: ping
<lifeless> mvo: probably the autopack race we have a bug open on
<mvo> aha, bzr pack seems to have helped indeed
<mvo> thanks
<lifeless> np
<jelmer> lifeless, still there?
<lifeless> yahuh
<jelmer> lifeless, when is the a directory supposed to be touched in bzr?
<jelmer> I mean, when is it's 'revision' property updated?
<lifeless> same as for a file
<lifeless> metadata-change or heads-of-revision-property-greater-than-one
<jelmer> what is considered metadata though?
<jelmer> are children metadata?
<lifeless> no
<lifeless> see repository.py - commit builder
<lifeless> I can phrase it differently - anything that changes the xml line in todays formats
<jelmer> lifeless, thanks
<lifeless> will count as a 'change'
<lifeless> + do a change anyway if the heads() count is > 1 [this records a merge at the file level]
<jelmer> lifeless: not sure I follow
<jelmer> lifeless, If the heads count is > 1 doesn't it use the revid of one of the parent revids if the text was unchanged?
<lifeless> never
<lifeless> this is not the revision graph
<lifeless> this is the per-file graph
<lifeless> for the heads count to be greater than 1, we must be a) committing a merge, and b) both branches must have made changes to this file
<lifeless> concurrent changes that is
<jelmer> lifeless, ahh, of course
<lifeless> if one side changes you get no-change against that side,and a heads count of one, so you keep the old revision
<lifeless> if both sides change to the same text
<lifeless> you get no-change against both sides, but 2 heads, so you record a merge
<lifeless> the intent
<lifeless> is that if you follow the per file graph you will find every actual change made to the file, and you won't see a change just because someone merged a branch that had changed it
<lifeless> thus the graph has to bifurcate where changes were made concurrently even if no change was made at the bifurcation point
<lifeless> please do check the code
<lifeless> but does that made sense?
<lifeless> jelmer: ^
<jelmer> lifeless, yep, it does
<jelmer> lifeless, thanks
<lifeless> cool
#bzr 2008-08-09
<meteoroid> with bzr-svn, can i give a specific revision #? i want to clone a repo with thousands of revisions and want to pull 1k revisions per night.
<jelmer> meteoroid, yes, see -r
<meteoroid> jelmer - with svn-import ?
<meteoroid> or is it easier if i branch each of the root-level 'project' areas with branch, into a shared repo?
<jelmer> ahh, there's no option for svn-import for that
<meteoroid> yeah see
<meteoroid> i need to svn-import something with over 50k revisions
<meteoroid> and i'd rather not crash their server ;)
<meteoroid> as svn is known to leak and take apache town altogether
<AfC> meteoroid: doing `bzr pull -r $x` where $x is incrementing by a few hundred (or whatever) each loop will probably do fine.
<meteoroid> AfC: but, how should i start it all off? i'd be best off, as i understand, with an svn-import, and i'm concerned if the branching will be properly recognized otherwise, which may increaase the amount needing to be transferred, and the storage used, exponentially..
<meteoroid> i mean this is a huge repo
<AfC> meteoroid: just start it off with a branch at -r 10 or something.
<meteoroid> hm.
<meteoroid> maybe just -r 1
<AfC> meteoroid: (actually a `bzr init --rich-root-packs` or whatever == empty branch works too)
<meteoroid> hm
<AfC> and then a URL on the first pull
<meteoroid> explain more about the last statement..
<meteoroid> i'd love to write a general purpose utility for branching large svn repos as a shell script or something based on your advise
<meteoroid> advice
<AfC> meteoroid: For what it's worth, I wrote about in making an initial Bazaar conversion of a monster branch (GTK, as it happens)  which you might find interesting. http://research.operationaldynamics.com/blogs/andrew/#bzr-branch-of-gtk
<meteoroid> thanks!
<meteoroid> GTK is quite possibly a good bit larger than mine
<meteoroid> how many revs when you started?
<meteoroid> hm 15k revisions
<meteoroid> except for memory limitations on my 1GB Ubuntu slice, I was able to branch over 5k revisions of a 10,5 revision repo
<meteoroid> but i figure if i come up with a gentle strategy for the 52k+ rev repo, it will work for others
<meteoroid> 15k revisions i could probably branch easily on a bigger box in one overnight run
<AfC> meteoroid: the key point is that once *someone* has done the conversion once, no one else has to. They can all just `bzr branch` from you, and then later update their branch via `bzr pull svn+ssh://...`
<meteoroid> no i totoally understand
<meteoroid> i'm just concerned that i can't be busying up the server for more than a handful of hours
<meteoroid> 5k revisions took long enough
<meteoroid> i want to spend a month or so pulling around 100k revisions across a few repo
<AfC> meteoroid: do you have access to this server? The other way to do this is to get an svn dump, transfer that in toto, and then operate on that elsewhere
<AfC> meteoroid: that's how Jc2k built the bzr-mirror.gnome.org set
<meteoroid> AfC : the server admins may be hostile, but i can work on it..
<meteoroid> i know that'd be the best way.  an svndump i could load and then pull the latest from
<meteoroid> i know once i have a copy that updates will be very light
<meteoroid> and that's a big reason i've chosen this approach
<meteoroid> to provide greater branching freedom in our community
<meteoroid> but i'm not sure all people will be welcoming at first
<meteoroid> until we can contribute back..
<meteoroid> so it's a chicken egg problem and i'd like to just spend a few weeks pulling a couple k rev at a time to not overload upstream server.
<meteoroid> but if we need to surf the social issues, we will
<pickscrape> lifeless: are you around?
<pickscrape> Quick question. In the color discussion Jonathan Lange suggested taking the terminal coloring code from twisted.trial: it supports handling things like Win32 already
<pickscrape> What's the bzr policy for taking code from other projects like that?
<meteoroid> twisted license is MIT, ya?
<lifeless> pickscrape: depends on how it will be taken; if its being copyied it needs to be a) licence compatible and b) not large enough to trigger the need for assignment
<pickscrape> Basically it is two classes from here: http://twistedmatrix.com/trac/browser/tags/releases/twisted-8.1.0/twisted/trial/reporter.py
<pickscrape> If it's not feasible I can work on my own implementation instead. I wasn't going to use them verbatim anyway.
 * meteoroid has had some convo recently with RMS regarding GNU licenses and python "dynamic linking" or loading of .py files, which is fuzzy license territory apparently, despite my previous beliefs..
<pickscrape> I think I'll just write my own. Less hassle. :)
<markh> lifeless: ?
<xshelf> I am having problems in building bzr plugins on windows using MinGW (dir_walk plugin), is it a known issue
<xshelf> Since I have been benchmarking it for emacs repository, any performance gain would help
<xshelf> I believe that dir_walk on windows does speed up things, am I right in my assumption?
<xshelf> anyone online now?
<markh> xshelf: if you can get bzr 1.6 building it should already have optimized dir walking for win32.
<xshelf> i am using bzr from the bzr.dev
<markh> right - and can't get the extension building?
<xshelf> i must say it is much better than I (dhruvakm) did a earlier benchmark for emacs
<xshelf> yes, I get an error in building the extension
<xshelf> python setup.py build -c mingw32
<xshelf> something to do with Py_ssize type
<markh> hrm - python 2.4?
<xshelf> it used to build just fine with vc 2003 and my installed python was built using the same compiler
<xshelf> python 2.5.2
<markh> strange - it has Py_ssize_t - what is the error?
<xshelf> i had to update to vc 8, python does not have vc8 distro
<xshelf> I am therefore forced to use mingw
<xshelf> error: bzr.dev\bzrlib/_walkdirs_win32.pyx:65:15: Syntax error in C variable declaration
<markh> I'm afraid I really can't help I'm afraid :(  I think the author of that code does use mingw, so its possible opening a bug report will get results.
<markh> you could always build your own python with vc 8 ;)
<xshelf> it needs a whole lot of stuff like sql-lite, bdb...
<markh> yeah - but so would building from vc7 - but I agree its a PITA :(
<xshelf> i tried hoping it would be quick, just gave up after sometime
<xshelf> i really like the PERL bundling
<markh> oh - right - if you could use vc7 you wouldn't have to build python itself!
<xshelf> I have built PERL using cygwin, mingw and msvc with no sweat
<xshelf> true
<xshelf> and you cannot build python with mingw
<xshelf> i wonder if we have some python devs here listening, get python to build with mingw. I build emacs regularly with mingw and it works fine
<markh> some people have managed and contributed makefiles, but they are rarely kept up to date.  It all relies on volunteers, and on Windows at least, builds using a non-standard compiler are less interesting as you can't get any pre-built binaries for it.
<xshelf> you have CMake
<xshelf> at work, we just moved to cmake
<xshelf> it generates platform/compiler specific build files from a common set of cmake files
<xshelf> I am really impressed by cmake. BOOST is moving towards cmake (giving up their home grown bjam tool)
<xshelf> i never realized you are the same Mark of Python win32 ext
<markh> heh - yeah
<xshelf> great, you really have brought Python to the windows world, thank you for that
<markh> working on bzr 1.6 binaries as we speak - but msvc7 built ones ;)
<markh> my pleasure :)
<markh> thanks!
<xshelf> welcome
<xshelf> yes, building with msvc 7 was easy
<xshelf> i made a blunder of uninstalling it when i had to install vc8
<xshelf> i thought i would save some disk space :-(
<markh> can't you reinstall it?
<xshelf> i have to run to IT, they will ask questions and get license approvals and all the corporate noise...
<markh> heh - bugger
<xshelf> i will try that anyway on monday
<markh> so - bzr 1.6 should be much faster than 1.5 even without that extension
<xshelf> it sure is
<xshelf> i was part of the emacs mail chain opposing adoption of bzr
<markh> although that extension makes a big different for big trees.  Quoting John, its author: " With this patch, doing 'bzr status' in a mysql tree on Win32 changes  from: 4.2s => 0.64s, or about 6.5x faster. It is quite noticeable when your command prompt hangs for 4s versus returning in < 1s."
<xshelf> the turning point was when RMS posted that we have to adopt another GNU project and help make it better
<xshelf> Yes, I keep running such commands too often in my development
<xshelf> i thought of writting something like using inotify for windows
<xshelf> so that, my changes are tracked without walking directories
<markh> The binaries I've got a looking pretty good.  If you ping me on Monday I can make sure one is up for you to play with if you like
<xshelf> i need time to do that, something that sysinternals filemon (procmon) does
<xshelf> i will do that, thanks.
<xshelf> I will try getting vc 7 so that I can build and play myself
<markh> yeah, tortoise will grow a file-watcher
<markh> but bzr status is *very* fast - we are already much much faster than tsvn on most trees I've tried
<xshelf> another question: can bzr seamlessly with perforce?
<xshelf> I am looking for something like git-p4
<markh> not afaik, but its an opportunity waiting to be taken, along the lines of bzr-svn ;)
<xshelf> i am forced to use p4 at work, would love to use just bzr for emacs and work
<markh> but google may well prove me wrong - I'm not that much in the loop that I'd know about it
<xshelf> i have just started looking at vcp from perforce. The svk folks had used vcp to support seamless operability with p4 but dropped it in their new releases
<xshelf> let me do some ground work and keep this channel posted
<xshelf> well, my family is back, will catch you on monday
<xshelf> have a nice weekend. I have to tear myself away from this computer...
<markh> cheers!
<gour> morning
<gour> i just built bzr from the repo and it bears the label:bzr1.7dev. when is 1.6 going to be released?
<spiv> gour: the 13th is the plan (see the release announcement for 1.6rc1)
<gour> spiv: ta. i'm looking at release notes, but there is nothing
<gour> anyway, will bzr come back to regular (aka monthly) releases?
<Bronger> Feature request proposal: I'd like to have diffs with diff's "-c" option.  It should be possible to set this in the conf file, so that not only "bzr diff" but also "bzr commit --show-diff" benefit from it.
<jonnydee> hello -- I'v got a question: what is the best way to incorporate the contents of repository B into A? At the moment I'm only aware of doing a merge... Is it the right way, or is there another approach?
<jonnydee> sorry, I'm confusing repository with branch
<jonnydee> but on the other side doing it with shared repositories would also be interesting
<jonnydee> btw, with "contents" I mean the complete history, too
<Bronger> jonnydee, I think you could also append the changes of one branch to another branch with re-basing.  Haven't done this yet, though.
<jonnydee> rebasing...ok. It sounds like this might be a solution...
<Bronger> Are the contents of both branches disjunct?
<jonnydee> Yes, they generally are. The reason why I'm asking is: I would like to write a plugin that is able to
<jonnydee> convert a branch/repository in such a way that the root of the repository/branch is moved one level up in the directory tree
<jonnydee> (while preserving the directory tree)
<jonnydee> for example, if I have a branch in: /tmp/repo/jonnydee/
<jonnydee> then I would like to be able to move /tmp/repo/jonnydee/.bzr to /tmp/repo
<jonnydee> which means the directory jonnydee is now versioned, too
<Bronger> But repo is not a branch, but a ... well ... repo.
<Bronger> I think that this would create some administrative collisions, although I must admit that I don't knot the Bazaar interna.
<jonnydee> yes, I know. But I need to handle any combinations....
<Bronger> What's the eventual purpose you're thinking of?
<jonnydee> Well the idea came from a discussion here
<jonnydee> someone had exactly this problem: he versione controlled a specific subdirectory and decided to extend version control over to the parent directory
<jonnydee> in his case the solution was simple:
<Bronger> I can imagine his solution already.  You may proceed with explaining a case that is not so simple.  ;-)
<jonnydee> well, sorry, I'm a bit confused at the moment -- I think it's too early in the morning.
<jonnydee> But you got the idea
<Bronger> Not really, because your example can be easily solved without new features.
<jonnydee> the more complicated cases are where one extends version control to a parent directory that has subdirectories containing other branches/repositories....
<jonnydee> ...and now ;)
<jonnydee> ???
<jonnydee> with other words, the general case is: you strat from an arbitrarily deep subdirectory in the file system, which contains the repository/branch you want to extend one level upwards. when you go one level upwards you might encounter a shared repository, or nit
<jonnydee> not
<Bronger> Even then it's simple: Go to the root of your branch (not repo!) and type "bzr mkdir branchname".  Move all other top-level files/directories into that dir with "bzr mv".  Then move the desired files/dirs from .. into the branch root dir, and add them with "bzr add".  Commit everything, voilPONG :niven.freenode.net
<jonnydee> but I do not only want the contents but also their history (if any)
<jonnydee> so lets assume my parent directory is a shared repository. now this means all the branches contained in the shared repository need to be combined into a single branch
<jonnydee> if it is not, then your solution comes into place -- with one exception
<jonnydee> if some subdirectory of the parent directory contains a branch itself (which may be located in an arbitrarily deep subdirectory) then there is no simple way like adding the files
<jonnydee> because we also want the history
<jonnydee> well, while I'm explaining this I am starting to doubt whether such a plugin is woth the work....
<Bronger> Do the branches have a common ancestor?
<jonnydee> maybe they have, maaybe not
<jonnydee> In a general case, you might have or are likely to have common ancestors
<jonnydee> such a plugin would be a nice-to-have for me, but the question is: how often is it needed to extend the root to one (ore more) levels up....
<jonnydee> anyway, I think you see it is not that easy when considering the general case
<jonnydee> ok bye Bronger - cu ;)
<Bronger> In any case, you have to move all dirs to their final positions in their respective branch, so that there are no collisions anymore when you unite them.  If they have a common ancestor, I'd do a merge, if they have not, you have to do a rebase I think.  You can rebase in both cases though.  Given that this is a rare use case (in case of no common ancestry even *very* rare), and given that it is feasible to do it manually, I don't think that it's worth a plugin
<jonnydee> Bronger, I thin you are right.... You know, I'm trying to get into Bazaar development and I thought writing a "simple" plugin would be a good starting point....but this turns out to not be the simplest plugin....
<jonnydee> especially in comparison with the benefit one would gain.... :(
<jonnydee> ok, so thank you very much for your help and feedback!!! :)
<jonnydee> and sorry that I've been wasting your time...
<LarstiQ> jonnydee: bzr merge -r 0..-1 path/to/otherbranch
<Bronger> Not at all. It help me to understand those DVCS more and more.
<jonnydee> thinking positive is always a good idea ;)
<LarstiQ> jonnydee: the key thing there is revision 0, being a virtual revision every revision dag inherits from
<LarstiQ> jonnydee: so even if the two branches don't have anything in common otherwise, you can force them to merge that way
<jonnydee> LarstiQ: When using this command, do I get the complete history from the other branch, too?
<LarstiQ> jonnydee: as came up (I didn't read all backlog), you might want to move directories beforehand to keep things from clashing.
<LarstiQ> jonnydee: yes.
<jonnydee> that sounds like magic :)
<LarstiQ> well, it's just normal operation really :)
 * LarstiQ runs off for the day
<LarstiQ> jonnydee: have fun :)
<jonnydee> thanks larstiq
<jonnydee>  :)
<jonnydee> well, I'm going to play a bit. maybe, I'll implement simple cases, just for fun....and if I still have fun, then maybe I consider more complex cases...
<jonnydee> Thanks a lot to Bronger an to LarstiQ :)
<Peng_> jelmer: I have a couple bzr-svn questions. With that root revision patch, what exactly was broken, and did data get corrupted or anything, or would bzr just traceback?
<Peng_> jelmer: Also, with changing the file ID map version, what exactly does that mean?
<jelmer> Peng_: The root revision patch is more just paranoia at this point
<spiv> gour: yes, back to monthly releases is the plan
<Peng_> jelmer: Okay.
<jelmer> Peng_: the file id map version was changed because older versions of bzr-svn may write invalid data to it in some corner cases
<jelmer> rare, but still
<spiv> jelmer: I liked the suggestion for bumping the version to 1.0, btw.
<Peng_> I dunno about 1.0, but I would vote for 0.5.
<jelmer> spiv, I'd rather wait with any sort of major version change until the mappings change again
<spiv> jelmer: fair enough.  But 1.0 soon is justified I think, it is a pretty mature tool now.
<lifeless> markh: ?
<rocky> jelmer: remember the other day i said i was working on a bzr-svn blog post and would like you to review it before i published it? i have it ready... don't suppose you have an email i could send it to?
<jelmer> rocky, Yeah, sure - my email is jelmer@samba.org
<rocky> sent
<jelmer> brb
<jelmer> rocky, just curious - what sort of blog software do you use?
<rocky> TextPress
<rocky> i'm a python fanatic
<rocky> www.serverzen.net
<rocky> i just blogged on settnig up TextPress ;)
<jelmer> rocky, I don't see any errors
<rocky> any obvious misuse of bzr? i mean, am i using bzr in an acceptable fashion? :)
<jelmer> rocky: heh, no that all looks alright
<dato> jelmer: I think Wilmer van der Gaast sits a few places from me at work. ;-)
<jelmer> dato: Ah, cool
<jelmer> dato, he's a good friend of mine
<jelmer> dato, I was over there at Google a couple of weeks ago
<dato> O'RLY?
<rocky> jelmer: alrighty then
<dato> we missed the chance to meet, then :(
<rocky> now the question is do i wait a bit since i blogged just a few days ago, or post immediately :)
<jelmer> dato, You're working for google these days?
<dato> jelmer: I'm doing an internship this summer, at least for now.
<jelmer> dato, ah, nice
 * pickscrape gets bzr diff --color working for the first time :)
<jelmer> rocky, thanks for the link to textpress, I'll check it out
<jelmer> dato, ask him about french-irish girls in boots :-)
<rocky> jelmer: np, my blog post should get you started fast
<nexus10> hi -- is there any way I can use 'bzr branch' to read a .bzr repo which is served by a webserver at https://server/site/.bzr  -- when this is passwd protected?
<nexus10> I can access the dir using a browser by entering credentials into the basic-auth dialog
<beuno> nexus10, sure, bzr branch https://user@server/site
<beuno> it should just ask you for the password
<nexus10> beuno: :-)
<nexus10> beuno: now I feel *really* smart...
<beuno> nexus10, I went through the same thing before I learned that, so, welcome to the club  :)
<nexus10> :-)
<nexus10> beuno: that bzr branch https://user@server/site worked splendidly, thanks a lot.
<rindolf> Hi all.
<rindolf> How do I use bzr-svn ?
<rocky> rindolf: http://www.serverzen.net/2008/08/09/starting-with-bazaar-bzr-svn
<rindolf> rocky: thanks.
<Peng_> beuno: Loggerhead question: If a commit message is "foo\n\nbar", the /changes page will show "foo" in the summary. Then if you click the expand button, it changes to "foo bar". Is that intended?
<rindolf> rocky: python: subversion/libsvn_ra/ra_loader.c:944: svn_ra_get_log2: Assertion `*path != '/'' failed.
<beuno> Peng_, it's expected rather then intended
<beuno> we strip out all HTML to show in that context
<beuno> including \n
<beuno> so we can show a plain commit message
<beuno> there may be smarter ways of doing that though
<beuno> pickscrape, ping
<Peng_> Ah..
<Peng_> Well, I'm gonna go. Have a nice day. :)
<beuno> Peng_, you too
<rindolf> https://bugs.launchpad.net/bzr-svn/+bug/234010 - hmmm...
<ubottu> Launchpad bug 234010 in bzr-svn "abort: svn_ra_get_log2: Assertion `*path != '/'' failed (dup-of: 229419)" [Undecided,New]
<rindolf> What should I do?
<ubottu> Launchpad bug 229419 in bzr-svn "WorkingSubversionBranch.test_create_checkout fails" [High,Fix released]
<rindolf> Anyone?
<beuno> rindolf, jelmer is the right person to talk to, but probably not on a weekend
<beuno> he'll see the bug eventually, and help you out
<rindolf> beuno: thanks.
<beuno> :)
<asabil> is it normal that the bzr PPA for hardy doesn't actually contain bzr ?
<Peng_> Heh.
<Peng_> Oh, I'm using the beta PPA. I forgot.
<Peng_> asabil: Yes, it is. Someone published 1.6b3 for Hardy, and you can't revert it back to 1.5.
<beuno> asabil, it will contain only releases from now on
<beuno> so beta PPA for betas/rc's, and bzr PPA for releases
<beuno> asabil, https://edge.launchpad.net/~bzr-beta-ppa/+archive
<asabil> beuno: hmm ? but it doesn't even contain bzr 1.5
<beuno> asabil, right, as Peng_ pointed out, something went wrong, and it had to be removed. 1.6 *will* be on there
<asabil> beuno: I don't really want bzr 1.6
<beuno> and everything should be fine from now on
<asabil> oh oki
<NewsMan08> Hello All
<pickscrape> beuno: pong
<beuno> pickscrape, hi  :)
<pickscrape> Afternoon :)
<beuno> I've been looking at your patch/branch
<beuno> I can't figure out *what* it does
<pickscrape> It converts the path string at the top of the file and directory browser pages into breadcrumb links
<pickscrape> So you can click on the parts of the path to browse to that directory
 * beuno tests again
<beuno> pickscrape, cool. Can you make the file browsing do that too?
<pickscrape> I thought I'd got them all... Which view are you looking at?
<beuno> pickscrape, when you end up in the actual branch
<pickscrape> It should already work
<beuno> in /files
<beuno> it doesn't for me  :/
<pickscrape> I just browsed into loggethead/loggerhead/static/css locally. At the top I see "viewing /loggerhead/static/css for revision 206"
<pickscrape> loggerhead, static and css are all links for me
<beuno> pickscrape, aaaaaaah
<beuno> I was expecting the path to continue
<beuno> so when I jumped into the file view
<beuno> I expected to be able to go back
<pickscrape> Ah, you mean the branch name part to the left of the 'viewing'
<beuno> right
<beuno> it deserved some thought
<pickscrape> Yes, I didn't want to play with that because my aim here was to add the links without changing the presentation at all
<pickscrape> But I suppose I could add the path to the branch to the left of the branch name.
<pickscrape> The branch name itself should probably be a link too.
<beuno> yeah, this is a big improvement
<pickscrape> The problem is once you add paths, you start to expect seeing the branch's directory name, and not nick.
<pickscrape> So it might be better doing it with pure directory names and displaying the nick somewhere else.
<pickscrape> I have to pop out for 5 minutes... brb
<beuno> pickscrape, ok, cool. Just one comment on the branch, and it's mergeable. You have no link to the root
<beuno> pickscrape, I gotto run, but if you can add a link to the root, that'll be great. If not, I'll merge anyway when I come back, as this is very practical  :)
<lifeless> beuno: see my export patch ?
<pickscrape> beuno: not sure if you mean a link to the branch root or to the root directory that loggerhead is serving.
<tacone> hello, wondering if I can nest branches one into another. i.e. in my project folder I could have a subfolder which contains libxxx. I'd like libxxx to be referring to an external branch. is that possible ?
<tacone> trying again: hello, wondering if I can nest branches one into another. i.e. in my project folder I could have a subfolder which contains libxxx. I'd like libxxx to be referring to an external branch. is that possible ?
<Peng_> tacone: Well, you can put a branch inside of another one. The outer one will completely ignore the inner one.
<[cliff]> hi all, I'm trying to push my project onto a new launchpad branch and I'm getting this error: Transport operation not possible: http does not support mkdir(). any thoughts?
<Peng_> [cliff]: Run "bzr launchpad-login your_username"
<[cliff]> aha! :)
<meteoroid> hm, why is an svn-import pulling only one portion of a repo?  i branched earlier, deleted that branch - maybe the svn cache is fudged?
<meteoroid> jelmer?
<tacone> Peng_: is it possibile to get the outer branch to "include" the code of the inner one ?
<[cliff]> Peng_, good stuff, everything works. thanks!
<meteoroid> only getting 82 rev of a repo with 577
<meteoroid> even with --all
#bzr 2008-08-10
<jelmer> meteoroid, hi
<jelmer> meteoroid: getting the cache screwed up is always a bug in bzr-svn
<jelmer> meteoroid, not sure I follow what you're trying to do
<jelmer> meteoroid, you branched inside svn or with bzr?
<meteoroid> jelmer: i use bzr-svn to branch a small portion of the svn repo, then i deleted that bzr branch and bzr svn-import the whole repo..
<meteoroid> but, it just pulls this one location that i branched before
<meteoroid> arguably the most important part but yanno..
<jelmer> meteoroid: this is a bug fixed in bzr-svn 0.4.11
<meteoroid> alrighty
<jelmer> meteoroid: for now, remove ~/.bazaar/subversion.conf and try again
 * meteoroid tries just removing that entry
 * jelmer gets some sleep
<meteoroid> thanks jelmer :)
<sohail> hmm... bzr cloning a 16M repository taking a bit too long...
<sohail> still going...
<sohail> we have python running at 150M of RAM and 100% CPU
<sohail> yay
<lifeless> sohail: thats unusual, what is it ?
<sohail> lifeless, my own repository
<lifeless> sohail: has it been this slow for you before ?
<sohail> lifeless, never
<sohail> new situation: I am trying to clone from linux to windows
<sohail> but the windows box has version 1.6
<sohail> linux has 1.3
<sohail> how can I upgrade the repository format? or do I need to?
<lifeless> sohail: is it a pack or knit repo ?
<sohail> I don't know what that means so whatever the default is
<lifeless> well, the default changed at 1.0 - did you have this repo before 1.0
<sohail> no
<sohail> but the repository I'm trying to clone was created with 1.3
<lifeless> lets check
<lifeless> bzr info -v on the repository
<sohail> lifeless, http://rafb.net/p/5XpErU98.html
<lifeless> that should be fine
<sohail> when I do bzr clone from the Windows machine, it hangs at "copying inventory texts 2/5"
<sohail> err "copying context texts 3/5"
<sohail> content**
<sohail> geez
<lifeless> has it allocated a lot of memory perhaps ?/
<sohail> oh yes
<sohail> 200M
<sohail> 250M now
<sohail> I just did a bzr clone on the host and it finished in 30 seconds
<sohail> :-/
<beuno_> lifeless, I did see your export patch, you rock!  I didn't comment because I say you superceded it later on, with something I couldn'y find!
<sohail> lifeless, at 500M now
<beuno_> Pieter, the root to whatever it started on  :)
<sohail> man I am totally out of it today... The repository is 216M not 16M!
<sohail> ok I'll just let it run for a while
<lifeless> beuno_: the later was just refactoring
 * beuno_ stabs LP for logging him out
<beuno> lifeless, that will go into 1.7 though, right?
<lifeless> beuno: assuming it gets reviewed :)
<lifeless> sohail: ok, I think its swapping
<lifeless> sohail: are you branching into a new repo on windows or an existing one ?
 * beuno searches for the merge request to add his +1
<beuno> is BB down?
<Peng_> Several hours ago, it was slow, but not down.
<Peng_> Now, it might just be down.
<lifeless> beuno: please check and see if the export patch is enough
<beuno> lifeless, sure, I'll give it a spin now
<beuno> lifeless, message id 1218178923.4514.146.camel@lifeless-64
<beuno> right?
<lifeless> beuno: it may not be - I think it will tend to write to a file itself; but let me know
<beuno> lifeless, btw, if you'd like to sponsor jelmer's packaging of bzr-search, we can get Loggerhead's package on it's way soon, with bzr-search as a recommends  :)
<markh> speaking of strangeness, I'm seeing bzr spin at 100% cpu and 400MB of ram for over 6 minutes doing "bzr merge --preview ..\other-bzr.dev-branch"
<markh> progress bar is stuck at "0/0" and the "spinner" hasn't moved for many minutes
<beuno> markh, what does .bzr.log claim?
<lifeless> markh: also look for syscall activity
<markh> heh - I think I need to go back to bed.  The 2 trees were actually completely unrelated, so I'm sure it was trying really hard to find something to do :(
<markh> sorry for the nouse
<markh> noise too...
 * markh has too many directories that start with 'bzr'...
<pickscrape> beuno_: Did you mean me here? -> "beuno_: Pieter, the root to whatever it started on :)"
<beuno> lifeless, your patch does *exactly* what I need
<beuno> pickscrape, oh, heh, yes
<beuno> good catch
<pickscrape> I'm still not completely sure what is required. Let's say we are serving from a non-branch directory that contains the path a/b/c, where c is a branch called 'bob'
<pickscrape> When we browse to the branch, currently we will see this: "bob : viewing / for revision X"
<pickscrape> Now, I can make 'bob' into a link that link to the branch root, but that doesn't help you to navigate further up the tree.
<sohail> lifeless, I am cloning an existing repo
<pickscrape> If we start showing the tree leading up to the branch as well, do you then also need to show the branch's directory name instead of its nic?
<beuno> pickscrape, hm
<pickscrape> That also puts you in a position where the branch root isn't very clearly marked
<sohail> lifeless, and it died: http://rafb.net/p/C2dh6O38.html
<pickscrape> This is why I didn't mess with what was displayed :)
<beuno> pickscrape, maybe we should just make that part a clear path, instead of the jumbled text it is today
<beuno> pickscrape, if you want to take a shot at making it less of a mess, that would be great. If not, I'll merge in your patch and work on top of that
<pickscrape> I can try an idea and propose it for merging. The worst that could happen is it doesn't get merged :)
<beuno> pickscrape, and a big hug for trying!
<pickscrape> Happy to be involved :)
<pickscrape> beuno: I'm thinking it might be worth merging what's done already so I can sandbox on top of that easily, unless you'd rather wait for the next step?
<lifeless> sohail: I believe that that bug is fixed in 1.6rc1
<lifeless> markh: are tehre rc1 binaries for windows?
<beuno> pickscrape, I sure can, but, on the other hand, we can take this opportunity and learn more about bzr. You can branch your branch, and work on top of that!
<markh> not that i've uploaded - I keep trying getting distracted trying to fix things :)
<markh> I'm just merging my latest test suite fix in and will test them, then upload them
<lifeless> markh: I think sohail just hit a fixed bug in the betas
<sohail> lifeless, good I'm just installing it now
<sohail> (building from source)
<lifeless> sohail: ok cool
<lifeless> sohail: let mw know if its faster too
<pickscrape> beuno: ok. So when I have something to present I just register another branch? Or just push over the one that is already there?
<sohail> lifeless, will do
<beuno> pickscrape, register a new one. Branch locally, play around, when you're happy, push to a new location in LP
<pickscrape> Sweet
<sohail> lifeless, ok so it isn't any faster, that's for sure!
<lifeless> sohail: can you try something for me ?
<lifeless> sohail: replace bzr+ssh with sftp in your url
<markh> a binary will finish uploading in 15 minutes
<sohail> lifeless, ok
<sohail> lifeless, so you mean bzr clone sftp://...? or bzr clone sftp+ssh:///
<sohail> err bzr+sftp
<sohail> lifeless, oh damn paramiko is needed for sftp... Do you know how to get distutils to use Visual Studio 2005?
<markh> lifeless: most test failures now on Windows relate to a LockContention error being thrown.  Can you think of any characteristics of your locks that would make them more likely to fail under windows (ie, do you ever assume you can delete the lock file while its open, for example?)
<markh> note I'm yet to see a "real" lock contention error - just in the tests
<lifeless> sohail: replace 'bzr+ssh' with 'sftp'
<lifeless> markh: lockdir is unlikely to be a problem on windows; I'd expect the dirstate os lock is the problem
<markh> yeah, I think you are right:
<markh> LockContention: Could not acquire lock "O:/window~1/testbzr-ag21lz.tmp/tatus.test_pending_with_ghosts/work/b/.bzr/checkout/dirstate"
<Leefmc> Question: So with bzr, is a project directory (ie, one which contains the .bzr folder) only ever contain one branch? (coming from a git person).. Say for example you have ~/project_src, if you need to create a test branch, do you then create a bzr copy and place ot elsewhere? ie ~/project_test
<lifeless> Leefmc: have a look inside .bzr
<markh> sohail: http://starship.python.net/crew/mhammond/bzr-setup-1.6rc1-mh1.exe should work pretty well
<lifeless> Leefmc: there are three subfolders in a newly inited project - repository, branch, checkout
<lifeless> Leefmc: the branch folder has the branch details, so yes, you need a directory per branch. but you don't need a new repository (where most of your data is) or a new checkout (which exists when your source code is unpacked on disk for editing) to have a new branch
<Leefmc> lifeless: So for a project, you would have like ~/project/src/.bzr, and your branches would be ~/project/src/trunk ~/project/src/test etc?
<sohail> markh, thanks
<sohail> markh, are you the guy from Jurassic Park
<markh> heh - well, I'm getting a little long in the tooth, but I'm not *that* old ;)
<sohail> :-)
<lifeless> Leefmc: yes, exactly
<lifeless> Leefmc: if you have an expensive working tree - e.g. C projects where you don't want to rebuild
<Leefmc> lifeless: K thanks. I enjoy git, even though i never got that deep into it, but at the same time it seems to have warped my mind for anything non-git heh
<lifeless> then  you'd have a one that you use to edit and switch between
<lifeless> e.g. bzr checkout --lightweight trunk build
<lifeless> cd build
<lifeless> ./configure
<lifeless> etc
<lifeless> bzr switch test
<lifeless> bzr switch trunk
<lifeless> and so on and so forth
<Leefmc> lifeless: Hmm, thats one thing i like about git though, is that in my IDE i never have to switch my files.. ie, say i am working on "main.py", if i want to try something i just create a new branch and try it, i never worry about which "main.py" (./test/main.py vs ./trunk/main.py) i am editing because its always my active branch
<lifeless> Leefmc: so having one tree does that -
<lifeless> you only have one copy of main.py on your disk at a tim
<lifeless> Leefmc: if you have a bzr branch you're working on, its three commands to set this up, and 4 to demo it :)
<Leefmc> lifeless: Yea but with bzr, if you want to take a piece of code and experiment, you make a second branch dont you? And thus, a 2nd main.py file on disk, correct?
<lifeless> no, second branch doesn't imply second checkout
<Leefmc> Git must have really screwed with me hehe :D
<lifeless> do you ahve any code in bzr?
<Leefmc> How is it that i find the "humane" vcs more confusing than one made by Linus! :D (not bashing bzr ofcourse, just poking fun at myself :p)
<lifeless> well
<Leefmc> lifeless: I've got plenty to try, but no projects set up with it yet
<lifeless> git has some nice things about it
<lifeless> its very optimised for the editing-C-code workflow
<Leefmc> right now im creating my directory structures for a new project and i wanted to use bzr because of Launchpad
<lifeless> this isn't intrinsically bad, but it does alter how things fit together
<lifeless> ok
<Leefmc> (I have more faith in launchpad for project hosting rather than Gitorious or Github, for example)
<markh> I think your previous exposure to any other dvcs does tend to cloud your mind for a while when looking at another.
<lifeless> grab a directory somewhere
<lifeless> do this:
<lifeless> bzr init-repo --no-trees repository
<lifeless> bzr init repository/trunk
<lifeless> copy some code - e.g. main.py into repository/trunk and then do
<lifeless> bzr add
<lifeless> bzr commit -m 'import'
<Leefmc> A while back i even used bzr, and it seemed relatively simple and easy (bout too easy), but i had no idea how it worked with my Git-ified workflow of "branch testing"
<lifeless> bzr remove-tree
<lifeless> this will have created a branch in a shared repository with no working files
<lifeless> now do
<lifeless> bzr branch trunk test
<lifeless> and
<lifeless> bzr checkout --lightweight trunk working
<lifeless> cd to working
<lifeless> it will have your main.py
<lifeless> bzr info
<lifeless> will tell you that you are on the branch trunk
<lifeless> bzr switch test
<lifeless> will make test your active branch
<Leefmc> bzr add gives an error about the current dir not being a branch
<Leefmc> Perhaps it was a bad idea to initially learn bzr by the stupid 5 minute tutorial. I should have focused from the ground up.
<Leefmc> I keep trying to make things relative to what i knew (Git) which is.. not easy heh.
<Leefmc> I spose i add the file directory? bzr add ./repository/trunk/__init__.py
<Leefmc> hmm, same thing.. im guessing then i need to cd into one of the repos you had me create. Im still confused on what the first two lines did though. To me it seems like you had me create 2 bzr repositories.
<Leefmc> oh i see i think, bzr uses multiple .bzr files, one for a collection of branches (what git would consider an actual repo), and one for each branch
<lifeless> Leefmc: oh, init probably honoured the no-trees
<lifeless> Leefmc: yes, your last point is right
<Leefmc> ok, im reading your steps tryin to make sense of it, and i am a bit confused. It seems you created 3 branches, trunk, test, and working. Now because there are .bzr dirs for each branch, you actually cd around to switch branches (as you do when you cd into "working"); However, you use a bzr switch command when inside of "working" to switch to "test", how is this possible?
<Leefmc> does bzr cd you to a different directory?
<lifeless> Leefmc: working isn't a branch
<sohail> hey markh that version worked fine except I get this annoying message: "intl3_svn.dll was not found"
<lifeless> Leefmc: its just a tree, like a svn checkout or a cvs checkout
<markh> sohail: bugger - thanks - I'll try and fix that.  If you don't care about bzr-svn, you could probably just nuke the plugins/svn directory
<sohail> markh, yeah I did just that
<sohail> now I need to figure out how to get bzr to ignore the symlinks in my repo :-/
<markh> heh - afraid I can't help you there ;)
<Leefmc> lifeless: Roughly, what would that be in Git? Repositories are collections of Branches, Branches are each a specific revision (with history), so what is a Tree then?
<markh> sohail: are you using a non-english windows?
<sohail> markh, no, english
<markh> hrm
<Leefmc> lifeless: The guide sort of confuses me. It says a Branch is an ordered set of revisions, yet the working tree is the directory of those revisions.. which seems to sound synonymous with Branch
<sohail> markh, maybe you can tell me how I can clone a subdirectory? That way I can just ignore the directory with the symlinks
<Leefmc> lifeless: Or wait, i think i see. The "working tree" is Git's version of the Active Branch
<Leefmc> lifeless: Except with bzr, it is an actual directory aswell (containing files of whatever branch)
<markh> sohail: not sure about that either ;)  I'm still learning the ins and outs myself
<sohail> markh, really! and you are making installers already?!!! :-)
<markh> heh - well that is what I *do* know about ;)
<markh> I thought bzr was trying to hard to at least not break with symlinks on windows
<markh> but I can't find any good references
<sohail> markh, well afaict it isn't doing a very good job :-)
<sohail> so does anyone here know how to clone a sub directory of a bzr repo?
<Leefmc> Question: Is "working" the standard name for the.. working directory? Or is it trunk.. or main.. etc?
<Leefmc> Or does it even matter? Will people only see the branch name, and not my working name?
<sohail> ok I knew how to do this but... bzr clone ...; <do some changes>; bzr commit; bzr push => "No push location known or specified"
<sohail> how do I fix that?
<tacone> sohail: bzr push [location]
<sohail> tacone yeah but what is location?
<sohail> shouldn't bzr default to where I cloned from?
<tacone> sohail: no
<markh> sohail: you probably wanted "bzr branch" in the first place then
<sohail> markh, ah!
<sohail> ok then
<sohail> I have to go just now but that is good to know
<tacone> sohail: if you're using launchpad that could be for example: bzr push lp:~yournick/yourproject/namebranch
<markh> sohail: heh - actually, "clone" is an alias for "branch"!
<markh> so yeah, you have to give the same location you branched from if that is where you want to push it.  I recall a long thread on the bzr mailing list about that now
<markh> it should remember though, and later, you just "push"
<Leefmc> Question: Is there any real difference between a branch and the working tree? Because "bzr checkout" creates a branch correct? Yet lifeless used checkout to create a working tree, so is there any real difference?
<lifeless> bzr checkout without --lightweight
<lifeless> will create:
<lifeless>  - a branch, bound to the source
<lifeless>  - a working tree at the same place as teh new branch
<lifeless> with --lightweight
<lifeless> bzr checkout creates:
<lifeless>  - a branch reference (basically a fancy symlink that works on windows)
<lifeless>  - a working tree
<pickscrape> beuno: ping
<beuno> pickscrape, pong
<pickscrape> beuno: I need a way to find out if loggerhead is serving a branch at the root level or not
<pickscrape> i.e. is the directory that http://example.com/ points to a branch, or a plain directory
<pickscrape> I've got the directory breadcrumbs working. This is the only corner case I can find that makes it behave badly :)
<beuno> pickscrape, for the directory nav?
<pickscrape> Yes
<beuno> pickscrape, it already knows, it shows different icons for each type
<techII> (since i can't find the blog entry I read dealing with this) if I commit to a svn checkout with bzr version 1.3.1, is it going to dump the bzr related stuff into the svn repo?
<pickscrape> Here's an example of what I mean. If I'm serving a loggerhead branch at the root, and I'm currently looking at the /loggerhead/apps directory, the link to the root needs to point to /files, otherwise I will jump to the revisions view
<pickscrape> Conversely, if loggerhead is serving a plain directory at its root, the link to root just need to go to /
<pickscrape> I suppose it's something that loggerhead could detect when it first starts up, but that sounds like quite a change :)
 * beuno thinks
<beuno> pickscrape, this is mixing the files and directories view, right?
<pickscrape> No, this is just making the directory path displayed at the top of the files view into breadcrumb links
<pickscrape> Which entails a link back to / for completeness
<pickscrape> The way I have it now, when the user is looking at a file they are able to jump directly to any of the file's parent directories in the branch, and the directories containing the branch, right up to the root directory that loggerhead is serving
<beuno> I like that
<pickscrape> The only case that doesn't work is when loggerhead's root is itself a branch
<beuno> I see yor problem
<beuno> can you push the branch, so I can toy around with it a little?
<pickscrape> Yes. You'll be able to see the problem very clearly that way :)
<pickscrape> Just give me a few to commit what I've done.
<beuno> sure
<beuno> I'm jumping in between dr. house episodes anyway  :p
<pickscrape> :)
 * pickscrape is up to date on that ;)
<beuno> I'm gladly not
<beuno> I tend to wait until series are past the 3rd season
<beuno> so then, when I get addicted, I don't have to wait every week
<pickscrape> Yeah, it's always a shame when there's nothing left of a good show to see.
<pickscrape> beuno: lp:~pickscrape/loggerhead/directory_breadcrumbs
 * beuno branches
<pickscrape> The other thing is, the file view appears to have a special case for when it is being run as part of launchpad. I've left that part alone.
<beuno> oh, yeah, don't worry about that
<beuno> pickscrape, so, I *love* the way it works now
<beuno> I'll start poking at the "am I starting at the root" problem
<pickscrape> Cool :)
<beuno> and, I'm thinking we should drop the "viewing path/dir..." nonsense
<pickscrape> I just need it to drop the (root) when the root is a branch.
<beuno> and just make the whole thing a path
<pickscrape> Yes, I was wondering about that too.
<beuno> and maybe even make the revision number a link
<beuno> because my instinct tells me that that should be clickable too
<pickscrape> I just wonder if there should be some way to make it clear to the user what part of the path was the branch directory itself.
<beuno> (for consistency's sake)
<pickscrape> beuno: I found myself trying to click the revision number too :)
<pickscrape> Then again, I'm not really sure where it should go
<beuno> pickscrape, maybe a different color for the branch within the path?
<beuno> or underlined?
<pickscrape> I hate choosing colours :) My other thought was underlined.
<beuno> or path == not bold, branch == bold
<beuno> I think the revision number should go to "revision/$revno"
<pickscrape> I actually like the current bold styling, as it is. Having said that, making it not bold makes it fit better horizontally for longer paths
<beuno> where everywhere else links to
<pickscrape> Yes, for the file_id that is currently being viewed. I like that.
<beuno> hm
<beuno> if you serve from:  /code
<beuno> and the branch is in: /code/coolstuff/loggerhead
<beuno> then root goes back to /code
<pickscrape> Yes
<pickscrape> Since that's your root
<beuno> what do you think of going even further, and making the breadcrumbs have the full path?
<pickscrape> It goes as far as it can.
<pickscrape> If you want to be able to browse the full filesystem, just run serve-branches /
<beuno> rightoh, wait, ignore me
<beuno> it works as I expected
<beuno> I just need to pay more attention  :)
<beuno> let me see how we can work out this serve-from-root thing
<pickscrape> If you're in a similar timezone to me, it being late is a good excuse ;)
<beuno> it's 1am, not sure I can use that excuse yet
<pickscrape> It's 11PM here, and I'd have no qualms about using it being late as an excuse already :)
<beuno> hahah
<beuno> good, then it's because it's late  :p
<pickscrape> Then again I was woken up by my son at the usual time of about 7:15 this morning.
<beuno> right, and I... well... my dog got hungry around 1pm, and poked me with his cold nose
<pickscrape> hehe :)
<beuno> pickscrape, got it!
<beuno> what was the other use case?
<beuno> pickscrape, add:  tal:condition="python:updir"
<beuno> to the root bit
<beuno> I'm already checking if we're at the top level
<beuno> well
<beuno> hm
<beuno> no
<beuno> that won't work
<pickscrape> The problem is if you're not at the top level, but the branch is.
<pickscrape> In that case the (root) link basically needs to go away.
<beuno> pickscrape, hrm, also, the link is also invalid for the branch nick
<beuno> because it builds a path, etc
<pickscrape> Ah yes, so it does
<beuno> so, two problems to fix now  :)
<pickscrape> Ah, no still one problem
<pickscrape> if you edit inventory_ui.py, and change line 80 to be if True:
<pickscrape> The link is correct
<beuno> I see, you already have a plan to override
<pickscrape> And that's the if that needs the 'is our root a branch?' question answering.
<pickscrape> Yes, the code to handle both scenarios is already in place
<pickscrape> Just needs the actual fact determining :)
<pickscrape> It's late: I've already forgotten what my own code does :p
<pickscrape> I need to go to bed now anyway: he'll be up at the crack of dawn tomorrow as well :) I'l read back here when I wake up tomorrow.
<pickscrape> Thanks for you help!
<beuno> pickscrape, I'll try and fix and push
<beuno> you're welcome, and thanks for working on this  :)
<ml> hi, anybody here intimately familiar w/ the bzr installer for Mac OS?
<meteoroid> if i set a commit hook or somesuch like for cia, say, or an email, in a bzr branch, does it travel with the branch, or only apply to that copy?
<xshelf> does making socket reads async and having multiple threads pulling different changeset make bzr faster for pull or clone?
<meteoroid> zshelf: it would depend on many factors..
<xshelf> I am yet to see a multi-threaded scm
<meteoroid> heavy threading is more beneficial on highly multicore systems..
 * meteoroid has thought a lot about that
<meteoroid> i'm on 8-core now and looking at moving soon to a 16-core box
<meteoroid> when i have 30-50 checkouts to make for a deployment i'd love some concurrency
<meteoroid> esp if i could do a thread per repo / server
<xshelf> home PC now have multi core or hyper threading
<meteoroid> oh i know i'm just saying even with 2-core or 4-core with other things running, sometimes it's not a big deal to lack threading..
<meteoroid> but when you have an idle box with 8 or 16 cores, as i sometimes have, and a ticking clock on a systems update, concurrency could be awesome. :)
<meteoroid> and yeh even a low-end multicore box relatively idle
<xshelf> so, one can safely assume a majority of users have 1+ core (virtual)
<meteoroid> well assume, no, assume likely, yes
<meteoroid> performing poorly with one core would be bad, imo
<xshelf> we can always have a flag to run in single threaded mode
<meteoroid> sure.
<meteoroid> fair enough :)
<meteoroid> i like the way you think!
<meteoroid> too bad my opinion doesn't matter for bzr ;d
<meteoroid> yet!
<xshelf> I had a tool to fetch source from CVS using CVSweb frontend as I was behind firewall
<meteoroid> ouch
<meteoroid> sounds painful
<xshelf> It was a 2 day hack and I had all such fancy features!
 * meteoroid doesn't doubt it
<xshelf> i managed to host that on savannah too and got people using it
<meteoroid> good for you!
<xshelf> Another idea: With all the distribution and duplication of changesets, would a bittorrent like approach improve speed?
<meteoroid> well for large projects, perhaps.. not sure it's a change worth forcing on everyone
<xshelf> ok
<meteoroid> esp for projects with tons of readers vs. writers ratio
<meteoroid> but also the DSCM approach helps
<meteoroid> you can have a local master pass-through
<xshelf> in a torrent like setup, you can pull bits (few changesets) from different machines.
<xshelf> I just did a google, found an rfc: gittorrent
<markh> multi-cores/threads would also only help if the network was fast enough that your cpu was working at 100% - otherwise asynch would do
<meteoroid> sure.. again for something like linux it might make sense, but for other things a pass-through is even handier.
<meteoroid> markh: well async can also be used to traffic cop for threads
<meteoroid> you dont' have to peak each core to take adv of threads
<lifeless> so
<meteoroid> you lose some cpu cache opt from context switches but you can swap out with other stuff and still be faster..
<lifeless> actually git does some threading, but its a work around for design deficiencies
<meteoroid> a lot of network-dependent apps spend time waiting
<markh> no - but your total throughput will not improve unless the cpu is at 100%
<meteoroid> so if you do 50 checkouts in one thread that waiting all stacks up in one time dimension
<meteoroid> markh: again not true if you are able to put more in wait
<meteoroid> you don't need 100% cpu for each thread
<lifeless> bzr is generally latency and network bound over the network
<meteoroid> you can have 8 cores and 20 threads if each is spending a lot of time in wait
<markh> a true asynch framework would mean you can have as many as you want running, and none of them blocking
<lifeless> e.g. twisted
<lifeless> :P
<meteoroid> :)
<markh> exactly ;)
<lifeless> anyhow
<meteoroid> we're arguing about the same thing i think ;d
<xshelf> how about stackless?
<markh> not many high-perf network bound apps scale via threads
<meteoroid> i'm just saying you don't need to peak each cpu
<lifeless> we chose in bzr to write synchronous code to make it more understandable and approachable for contributors
<xshelf> twisted makes you create a whole lot of processes
<meteoroid> if there are a lot of requests happening, there's a lot of latency
<lifeless> async code abstractions leak in various ways
<meteoroid> and you can juggle more threads than cores
<lifeless> some of the core of bzr uses threads
<meteoroid> python threads? ;)
<meteoroid> like zope. ahh.. zope..
<meteoroid> one process per thread zope..
<markh> threads are both easy and very cool - don't get me wrong ;)
<meteoroid> er per core..
<xshelf> i just did a 'bzr pull --profile' on emacs
<markh> easy compared to asynch programming ;)
<meteoroid> well i mean with twisted generally you mix both..
<lifeless> xshelf: if you're interested in performance work on bzr
<meteoroid> you respond to events in the main interpreter by launching events in thread via C so they don't depend on GIL
<xshelf> The top consumer: 406/265 1848.725    4.554 1848.744    6.976 socket.py:278(read)
<lifeless> xshelf: can I suggest you strt with the btree index plugin and ensure you have 1.6rc1 too
<xshelf> lifeless: I love to work on bzr, I know almost nothing in python
<markh> yeah - true asynch is *very* hard.  A dedicated thread that does nothing but IO, and everything via waiting for the OS to tell you a request is complete.  Less threads == less OS overhead in moving the bits off the wire.  Then you actually have to do something with the bits, which is where it gets more complicated ;)
<xshelf> lifeless: : My daytime job revolves around performance improvements too
<lifeless> xshelf: cool
<lifeless> xshelf: so I'm doing a lot of performance work
<lifeless> xshelf: my current focus is a new compressor with the goal of reducing the amount that has to be sent over the network
<lifeless> but there are several endemic performance issues
<xshelf> lifeless: I have seen that and that really does not make too much of a difference with current network speeds
<lifeless> xshelf: bzr branch for me saturates the network
<xshelf> lifeless: I worked at McAfee and did some real speedups
<lifeless> xshelf: so reducing the data sent be 60% will make a huge difference
<lifeless> cool
<lifeless> anyhow
<lifeless> we have a variety of issues
<xshelf> lifeless: I agree, 60% is big saving
<lifeless> some are algorithmic
<lifeless> working tree operations take time proportional to the number of files that are versioned
<lifeless> so do any operation on historical trees - we have to generate an in memory object called an inventory, which is essentially the entire directory structure
<lifeless> being able to do partial operations on that could make a significant difference
<lifeless> and the repository size issue I mention
<xshelf> point me to a good bzr architecture doc, I will start looking into it
<lifeless> the new b+tree indices are 30% of the current index size
<lifeless> hmm, some operations unnecessarily look at the entire network graph which is another issue
<lifeless> e.g. time 'bzr log | head -n 1'
<lifeless> vs time 'bzr log --line | head -n 1'
<xshelf> Yes, I raised that issue on emacs list when talking on moving to bzr
<lifeless> xshelf: there are various docs in doc/developer and the wiki; but most of the things that need fixing are in discussion on the bzr mailing list
<xshelf> that is the first command I type after a pull and it took quite some time
<xshelf> lifeless: I will join the list, which one should I be joining
<lifeless> yeah
<lifeless> http://lists.canonical.com/mailman/listinfo/bazaar
<xshelf> will join right away
<xshelf> i was working on hg, since emacs might just use bzr, I might invest in bzr
<lifeless> some good folk to chat to -
<lifeless> andrew bennetts does networking - spiv on irc
<lifeless> I do low level storage as well as algorithmic higher level stuff
<lifeless> jam is similar to me - thats John A Meinel
<xshelf> ok, algorithms are over head for me :-(
<xshelf> I do not have formal computer science background...
<lifeless> thats fine
<xshelf> i will do my best
<meteoroid> xshelf: algorithm is just a fancy word for "way to solve a problem", and also a name for an entire formal branch of science / mathematics ;d
<xshelf> lifeless: I realize that but I have failed in some interviews just because they ask an algo by a name and I will not be knowing it
<xshelf> lifeless: In some places (Yahoo), they asked me to solve and I was able to!
<xshelf> lifeless: Google asks many such algos by name
<lifeless> meh
<lifeless> simple memory is not a good indicator for aptitude IMO
<lifeless> it may indicate regular activity in an area
<lifeless> but my brain routinely pages shit out
<xshelf> lifeless: That is most important
<xshelf> lifeless: Anyway, I am now in a place where I get to learn and play with things I am interested in (NetApp)
<lifeless> nice
<lifeless> WAFL is quite interesting
<markh> lifeless: do you happen to know if there is an implication repo.bzrdir.transport.local_abspath() should return a local_abspath with native backslashes on Windows?  It currently returns "/" and tests are failing due to it.  I'm wondering if I should focus on fixing local_abspath() or just hacking the tests to call os.path.abspath()?
<lifeless> all internal paths should be / using
<markh> yeah - but the name of "local_abspath() kinda implied it was an external interface
<lifeless> AFAIK all os functions will work
<markh> ie, it is converting from internal to external
<markh> yeah - I understand that - just wondering what the abstraction was supposed to be
<lifeless> markh: if its still in python its internal :)
<markh> :)  fair enough - so I'll fix the tests ;)  thanks!
<xshelf> lifeless: I got bumped due to drop in network
<xshelf> lifeless: I have joined the bazaar mailing list and looking forward
<lifeless> cool
<Peng_> FWIW, if the last message you saw was from 06:50:47 (it being 07:14 now), you didn't miss anything.
<lifeless> I'm off for the night
<lifeless> ciao
<Peng_> Good night.
<xshelf> login
<markh> if I do a merge that conflicts and leaves conflict markers, is it expected that the first 7 lines in the markers will be identical?
<xshelf> ot: I have heard bzr has the best merge code, if that is true, would it be possible to have a stand alone merge that can be used through scripts?
<Pieter> markh: did you check for whitespace differences? e.g. tabs vs spaces
<markh> Pieter: I suspect that might be the case for eol markers (I'm on Windows) - but I suspect that these have been normalized in the file with the conflict markers, masking the error.
<markh> (ie, it all looks fine in the file with the markers, but the source of the merge may have different eol markers)
<markh> s/eol markers/eol settings/
<markh> *sigh* - the file with the conflict markers looks fine.  The source of the merge leading to the conflict markers may have had different EOL style leading to what I see.
<markh> too many branches, too little time ;)
<mlh> xshelf: yeah I think so .. I know it's been asked before and the response is in the affirmative
<mlh> but don't knw the details
<mlh> you'll have to wait for  bzr dev
<mlh> 'a' bzr dev
<Pilky> Is there any way to send authentication details inline with a command? eg "bzr branch lp:myproj --password mypass" or something like that
<xshelf> is there any hack to use bzr-fastimport with perforce?
<xshelf> lifeless: I was reading you entries on advogato on persistent b+tree/hashtable from python. Ever considered Berkeley DB?
<rocky|away> jelmer: fyi, committing to a bzr-svn svn trunk is still very very slow
<gnomefreak> im guessing bzr-svn wsa never fixed?
<rocky|away> jelmer: to commit 7 file's changes (certainly not totalling > 2k) took 1m27s according to unix time command
<gnomefreak> rocky|away: mines crahsing
<gnomefreak> has been for a month or so
<rocky> which version you using? i'm on ubuntu hardy heron running bzr-svn 0.4.10, svn 1.5, bzr 1.5
<gnomefreak> 0.4.10-2
<gnomefreak> 1.5 bzr
<rocky> which os ?
<gnomefreak> ubuntu
<rocky> i don't know what to say, it works for me ... it's just very slow
<jonnydee> hello, I'd like to create a .deb package of a bazaar plugin for PPA. can someone point me to related documentation or give me some hints? It's my first packaging trial, so I'm a novice regarding packaging. At the moment I'm reading https://wiki.ubuntu.com/PackagingGuide/Complete as suggested by https://help.launchpad.net/PPA...
<Leefmc> Question: I added a file by mistake, how do i remove it before a commit? I dont really wanna comit it.
<sabdfl> Leefmc: try bzr rm?
<sabdfl> hmm... bzr rm --keep
<Leefmc> sabdfl: Makes sense, and i thought of that, but oddly enough i dont see bzr rm in the bzr command list.. am i blind? I typed "bzr" and it gave me a list of commands, yet "bzr rm" is not on there.. is it?
<sabdfl> "bzr help commands" will give you a more detailed list
<sabdfl> remove is there
<sabdfl> and i believe rm is an alias for that
<sabdfl> cheers
<Leefmc> k thanks
<beuno> jelmer, ping
<beuno> jelmer, bzr-upload has been accepted, and I'm poking the DD to upload bzr-search now
<thorwil> i got a bzr: ERROR: exceptions.MemoryError: and filed a bug with traceback. but now i wonder how to fix the upload
<thorwil> as on pushing again, i get [Errno 39] Directory not empty
<thorwil> dang, gotta go
<Adri2000> hi
<Adri2000> when I merge one revision from another branch, and then commit, the commit message of the revision I merged doesn't appear in bzr log, can I change that?
<edcrypt> Adri2000, the commit msg should appear on the log of the branch you merged *to* -- is this what you are doing?
<Adri2000> yes
<Adri2000> but it doesn't appear
<pickscrape> Adri2000: did you merge using bzr merge -r ?
<Adri2000> it does appear if I merge more than one revision, but not if I merge only one
<Adri2000> yes, or -c
<pickscrape> Yes, in that case you're just merging the patch, and not the actual revision.
<pickscrape> As I understand it, tracking of cherry pick merge meta data isn't implemented yet
<Adri2000> it should work with -rRev1..Rev2? I though I tested that as well
<Adri2000> thought*
<pickscrape> It only tracks if you don't specify any revisions at all
<pickscrape> If you use -r (or -c), all that happens is that the patch of the revisions you specify get applied to your working tree
<Adri2000> ah indeed, so the only case where the commits are shown in the log is when you merge a branch completely
<pickscrape> Yes, because that's the only case where it has the merge metadata.
<Adri2000> actually merging a branch up to revision X (-r X) brings the commit messages. so it's just cherry-picking one or multiple commits that doesn't
<Adri2000> pickscrape: and you say that may be implemented in the future?
<pickscrape> I've heard that it is planned, though I don't know anything about when
<Adri2000> ok
#bzr 2009-08-03
<poolie> hi all
<pigmej> hi ;)
<pigmej> anyone alive?
<mwhudson> maybe
<pygi> maybe not
<lifeless> theory has it that we can't really tell
<pigmej> ;]
<pigmej> ok guys :)
<pigmej> I need to setup multibranch env
<pigmej> with bug tracking system...
<pigmej> the question is how to do it "good"
<pigmej> and what do you recomend ;-)
<pigmej> For now I cannot use launchpad...
<pigmej> not yet..
<lifeless> pigmej: I don't really know what you want
<pygi> I think he wants a bug system integrated with bzr
<pigmej> lifeless: I have project...
<pigmej> We have multiple branches
<pygi> pigmej, you might be interested in cluemapper then?
<pigmej> We want to "manage" bugs etc with web interface
<pigmej> I'm trying to do it with Trac
<pygi> pigmej, http://projects.serverzen.com/pm/p/cluemapper
<pygi> :)
<pygi> also look into ClueBzrServer
<pygi> (its there on that page)
<pigmej> hmmm
<pigmej> thanks..
<pygi> but I'm off to sleep now :p
<pigmej> I will look ;)
<pigmej> Cu ;)
<pygi> night
<spiv> Good morning.
<lifeless> jml: are you back?
<poolie> lifeless: i don't think he will be
<poolie> according to my record
<pigmej> hmmm
<lifeless> pigmej: why can't you use launchpad?
<pigmej> I need to store code in private plase
<pigmej> until first public release
<pigmej> GPLv3 licence
<lifeless> launchpad can do that if you get a subscription
<pigmej> lifeless: yah payed one
<lifeless> (private hosting is a for-fee service)
<pigmej> lifeless: lauchpad hasn't private "projects"....
<pigmej> or am I wrong?
<lifeless> hmm, I don't remember
<pigmej> btw error: Could not find suitable distribution for Requirement.parse('TracWysiwyg')
<lifeless> I suggest you ask on #launchpad about that
<pigmej> from easy_install cluemapper
<pigmej> ok I've fixed it
<pigmej> lifeless: launchpad hasn't private "space" in 100%
<pigmej> but it's open source now.. so maybe that's the way..
<poolie> pigmej: if you ask and explain the situation they might give you free temporary private hosting
<poolie> i'm not sure
<spiv> poolie: https://bugs.edge.launchpad.net/bzr/+bug/375013, see comment #1.  That's the hpss blackbox test that fails with 2a.
<ubottu> Launchpad bug 375013 in bzr "Commit doesn't honor stacking invariants" [Critical,Triaged]
<GungaDin> Hi
<poolie> spiv: i pushed lp:~mbp/bzr/default2a
<poolie> nice idea
<GungaDin> While I'm trying to checkout a branch on my Windows machine, I keep getting a' bzr: ERROR [Errno 2] No such file or directory: u'.....'' while bzr is downloading the tree. any ideas why?
<poolie> GungaDin: not unless you provide more information
<lifeless> GungaDin: look in the log - bzr --version will tell you where the log is
<lifeless> there should be a backtrace; could you pastebin that thanks.
<lifeless>         if not hasattr(test, '__call__'):
<lifeless>             raise TypeError("the test to add must be callable")
<lifeless> I sometimes despair about upstream
<pigmej> lifeless: have you tried cluemapper with bzr ?
<pigmej> how to do it?
<GungaDin> http://pastebin.com/d220d4a35
<lifeless> pigmej: I don't know what cluemapper is - so no, sorry.
<GungaDin> oops
<GungaDin> wrong one
<GungaDin> sorry
<lifeless> GungaDin: no problem
<GungaDin> http://pastebin.com/d4f2617a2
<lifeless> I think you might be running into a path depth issue
<GungaDin> .. ?
<GungaDin> why? is there a limitation?
<lifeless> either that, or one of the elements in C:/cygwin/home/me/Sources/myproj/.bzr/checkout/limbo/new-100/A/B/C/D/E/a.b.c.d.e.f.datasource is missing
<lifeless> GungaDin: windows has many limitations
<GungaDin> I hardly believe that's the case.
<lifeless> is that the actual string, or did you edit it somewhat ?
<GungaDin> I just changed that directory and file names. Not the depth.
<lifeless> I need to know how long the original string was
<GungaDin> just a sec, I'll let you know.
<GungaDin> You think it's greater than 255?
<lifeless> 127
<GungaDin> the limit is 127?
<lifeless> there are several different limits
<lifeless> per-dir and total length
<lifeless> I'm just refreshing my memory
<GungaDin> the path string length is 262
<lifeless> ok
<lifeless> the limit is 260
<lifeless> http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx
<lifeless> "In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. "
<lifeless> there are some things that can be done to use longer paths, but they have various different problems
<lifeless> such as causing Windows Explorer to fail
<GungaDin> http://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.aspx
<GungaDin> yeah
<lifeless> if you can make a temp dir a c:\F
<lifeless> and checkout into that it may work better
<lifeless> please file a bug; there are some things we can do to workaround this, if we can detect it even half decently
<GungaDin> MSDN also mentions there are functions to use an extended path name.
<GungaDin> up to 32768 chars.
<lifeless> yes. - as I said above in fact :). "11:46 < lifeless> there are some things that can be done to use longer paths, but they have various different problems"
<lifeless> spiv: are you sending to pqm from lp successfully now?
<spiv> lifeless: not yet, but I don't think I've tried recently.
<spiv> My locations.conf still uses http:// for public_location as a workaround.
<GungaDin> ok, submitted a bug
<GungaDin> thx.
<poolie> lifeless: subunit is making me install libtool; ewww
<poolie> you do get points though for not shipping the standard useless INSTALL file
<meoblast001> hi
<lifeless> poolie: you probably don't need the C bindings; you can just add ./python to your path; or use one of the debs
<meoblast001> i have the BZR-CIA plugin installed, by any chance does anyone know how to remove CIA reporting from a project (i'm going to be pushing to a seperate branch
<lifeless> meoblast001: I don't know, sorry.
<lifeless> fooding
<poolie> you have debs now?
<lifeless> yes
<lifeless> as I said to jam :P
<lifeless> https://edge.launchpad.net/~subunit has two PPA's
<lifeless> releases and snapshots
<poolie> you should link to them from the subunit home page...,
<lifeless> if you're on a distro-release that isn't represented, let me know and I'll upload targetting it for you
<poolie> i'm on jaunty and on karmic
<lifeless> it would be nice if lp would join these things a little more nicely.
<lifeless> anyhow, right now. _food_. I shall return shortly.
<SamB> fools!
<poolie> ?
<SamB> using Ubuntu ;-P
<poolie> rather than?
<SamB> Debian, duh!
<poolie> oh, i thought you were going to say GEOS
<lifeless> poolie: subunit 0.1 (a snapshot between 0.1 and 0.2 actually) is in karmic, no ppa needed there at all
<poolie> k
<poolie> lifeless: does subunit, eg subunit-stats, print out the errors but not the failures?
<SamB> don't you need to use subunit-filter to get that?
<SamB> that's what I'm doing
 * SamB is using 0.0.2~bzr68-1
<lifeless> poolie: subunit-stats consumes the entire stream, just reports the aggregate; if you're seeing other stuff, its being passed through
<lifeless> which can be caused by badly escaped exceptions (I have to check for bugs there), *or* bzr corrupting the stream by e.g. top level network progress output
<SamB> when I run bzr selftest --subunit it tells me *everything*
<lifeless> SamB: right; you can pipe that through subunit2pyunit for a pyunit display; trunk has subunit2gtk, subunit2pyunit --progress to get a bzr progress bar
<lifeless> if you want to read the raw stream, subunit-filter --no-skip is probably what you want
<poolie> lifeless: bug 408186
<ubottu> Launchpad bug 408186 in subunit "subunit-stats prints some errors" [Undecided,New] https://launchpad.net/bugs/408186
<SamB> I usually end up redirecting/teeing to a file and doing different things
<SamB> ... interspersed with cursing unittest for not supporting traceback-format overriding
<lifeless> poolie: checking
<lifeless> SamB: I have some thoughts/plans on how to tie multiple filters together better
<lifeless> a shell Y should utility would be nice
<lifeless> as would a subunit interleaver
<SamB> lifeless: how is that going to help me convince unittest to print tracebacks with variable names, without feeling dirty because of the inevetable monkey-patches?
<lifeless> SamB: it won't, it will just make it easier to deal wiht ;)
<SamB> this would be far more tolerable if I BZR_PDB=1 would catch test failures
<SamB> oh, variable values too ;-)
<lifeless> poolie: thanks
<lifeless> this is an important unittest model issue, as it happens
<poolie> lifeless: also, does it have any understanding yet of the various shade-of-grey results?
<SamB> poolie: hmm, I don't think using shades of gray is a good idea -- it might cause confusion between the light-on-darkers and the dark-on-lighters ;-P
<poolie> mm thanks
<lifeless> poolie: it knows skip
<lifeless> it doesn't have wire representation for unexpected success or expected fail, IIRC.
<poolie> subunit-filter --error includes UnavailableFeature
<poolie> istm it should not
<SamB> lifeless: those probably ought to be added, at least
<SamB> poolie: yeah, you'd think those should count as skipped!
<lifeless> I think my dirstate iter_changes branch will land happily now
<lifeless> sending it in a bit
<lifeless> poolie: in the spirit of getting small things done as they happen - https://edge.launchpad.net/subunit - I've touched it up.
<poolie> looks good
<poolie> lifeless: would it be expected that the text_index for a 2a format holds one more key than in previous formats?
<poolie> maybe for the root directory
<poolie> re bug 408199
<ubottu> Launchpad bug 408199 in bzr "blackbox.test_check fails in 2a format" [High,In progress] https://launchpad.net/bugs/408199
<poolie> yes, apparently for the root
<lifeless> poolie: all rich roots will, yes.
<poolie> thought so, thanks
 * lifeless enqueinates
<AfC> I love it when people look sophisticated looking words ... that get zero Google hits
<lifeless> :)
<AfC> And, of course, just when you're doing what should have been an oh-snap put down, you realize you totally blew it with a editing mistake. {sigh}. I hate the universe.
<AfC> oh boy
<AfC> s/a/an/
 * AfC slinks away in shame
<mwhudson> AfC: irc needs a feature that allows you to scrub stupid things you say from your readers' minds
<lifeless> if it makes you feel better, I checked the spelling on the made up word thrice before using it.
<AfC> mwhudson: the very earliest versions of ICQ chat at sent a-few-characters-at-a-time and backspace worked.
<lifeless> hudson really is very pretty
<AfC> My spelling got much better when I added an "Add all [red underlined misspelled words] to dictionary" feature to the spell checker.
<AfC> My typing is awesome now. I love it.
<mwhudson> lifeless: i really wish that project was called something else
<lifeless> mwhudson: yeah, I can see that ;)
<mwhudson> (my brother uses it at work too)
<lifeless> Does he call his server, Michael?
<mwhudson> i hope not
<lifeless> it would be childishly entertaining
<lifeless> poolie: yes, the mapping to subunit is partly subunit not being as rich as bzr is (fixable) but also partly the way bzr  does its subunit output
<lifeless> we should probably put a decorator TestResult to change missing deps to skips or something
<lifeless> poolie: bug 123688 - use stopTestRun
<ubottu> Launchpad bug 123688 in bzr "selftest leaves the last test showing" [Low,In progress] https://launchpad.net/bugs/123688
<lifeless> I think its called 'done' in bzrlib at the moment
<lifeless> but upstream python merged the feature as 'startTestRun' / 'stopTestRun'
<poolie> that's called on the TestResult?
<lifeless> yes
<poolie> thanks
<lifeless> if it isn't, we should make it so
<lifeless> because its the right design :P)
<poolie> mm
<poolie> so it still feels a bit like whack-a-mole
<poolie> but it's definitely good to have a standard interface for it
<poolie> lifeless: you can read the diff in https://code.edge.launchpad.net/~mbp/bzr/selftest/+merge/9571 if you like
<poolie> well, if you're lucky and the diffmonster put it there
<poolie> i'd like, in a subunit gui or command line, to say
<poolie> get all the tests whose failures look ~like this~ and run them again
<lifeless> poolie: I wouldn't add the comment under done()
<poolie> about the standard name?
<lifeless> that just adds conflicts to resolve when merging a fixup to the right method name
<lifeless> yeah
<poolie> i'd care more about people understanding they're the same than getting one tiny conflict when changing the name
<lifeless> in that case I'd use a docstring not a comment
<poolie> for the sake of the generated api docs etc
<poolie> or rather just because it's public documentation?
<poolie> ok
<lifeless> help(foo.done) / pydoc etc
<lifeless> looking at the source is less common than looking at the objects, or the help on them
<poolie> really?
<poolie> not for me :)
<poolie> anyhow i'll move it
<poolie> i find i use pydoc much less than i did use similar things elsewhere
<poolie> i'm not sure why
<lifeless> because folk write comments ? :)
<poolie> mm :)
<poolie> i kind of feel it's because there's less of a static model
<poolie> but, there is enough to generate some api docs
<poolie> anyhow, it's a beer qn
<lifeless> heh
<lifeless> so, what are you thinking of subunit so far?
<poolie> flaky but intriguing
<poolie> in a nutshell
<lifeless> well, thats better than horrible ;)
<lifeless> poolie: isn't TestUIFactory new anyway ? :)
<poolie> no, it's old
<poolie> CannedInputUIFactory is new
<lifeless> I thought tests used to use SilentUIFactory
<poolie> imbw but i think they were both there
<poolie> there is some cruft
<poolie> thus the bug asking for more thinking and more cutting
<lifeless> huh, 2007
<lifeless> there we go
<lifeless> so, I've spent most of today playing whackamole on iter changes
<lifeless> getting the last kinks out
<poolie> k
<lifeless> I hope to land it tomorrow am
<poolie> well you know what i've been doing :)
<poolie> so far all of them are pretty shallew
<poolie> shallow*
<poolie> but this may not last
<lifeless> would you like to have lunch tomorrow?
<poolie> otoh i haven't particularly been starting with the easy ones, so ...
<poolie> i have lunch most days :-)
<poolie> so yes :)
<poolie> oh, with you? sure.
<lifeless> o/~ welcome to pedanical o/~
<poolie> where?
<lifeless> I was thinking chinese in epping
<lifeless> but anywhere reachable is fine
<poolie> sounds dangerous :/
<poolie> but actually that sounds fine
<lifeless> feel free to file more bugs on subunit btw
<poolie> i'll see you around 12 then
<lifeless> I like bugs, they are a sign of users
<poolie> i wonder how spiv got on?
<lifeless> re 12 - cool
<spiv> poolie: I have lunch most days too ;)
<lifeless> that said, EOD time for me.
<vila> hi all !
<lifeless> hi vila
<poolie> hello vila, welcome back
<vila> lifeless, poolie : thanks ! anything urgent ?
<poolie> getting 2a stable :)
<poolie> stable-er*
<lifeless> other than working on the 2.0 targetted bugs
<vila> ok
<poolie> you could have a look at the six-month-release thread
<poolie> it's not urgent as such but i want to know you're ok with it
<lifeless> you might enjoy the subunit2junitxml + hudson stuff I did ;)
<poolie> spiv, re bug 407834, do your changes add (or remove) a warning for inter-format fetch
<ubottu> Launchpad bug 407834 in bzr "Branching MySQL too slow" [Undecided,Incomplete] https://launchpad.net/bugs/407834
<poolie> i think i put one in at one point...
<poolie> when i mean 're that bug' i'm not implying it's assigned to you
<spiv> poolie: I don't think I've added or removed any warning there, not sure that there is one atm though.
<GungaDin> How can I check the parent of a rev id?
<GungaDin> or parents
<poolie> lifeless: is bug 407834 a bug in its own right? ie can it plausibly be faster?
<ubottu> Launchpad bug 407834 in bzr "Branching MySQL too slow" [Undecided,Incomplete] https://launchpad.net/bugs/407834
<lifeless> it should be; the bugs on IDS, network deltas will make it faster
<lifeless> hundreds or thousands of times faster I suspect
<lifeless> spiv has timing data
<spiv> I'm not sure if my network deltas patch will make much difference to the CPU cost, but it should massively reduce the network traffic (both bytes and roundtrips).
<bob2> hm, cd'ing to a svn checkout inside a bzr branch makes zsh's prompt stuff do bad things
<GungaDin> I just did a really stupid thing...
<GungaDin> and I need help.
<GungaDin> I merged my local branch into trunk...
<GungaDin> then uncommited that revision
<GungaDin> then someone else committed something into trunk
<GungaDin> and now I want to commit a change into my local branch and then merge into trunk... but I can't
<GungaDin> when I try to merge into trunk I get: "bzr: ERROR: Tags not supported by BzrBranch5('file:///home/winnt/TIBRA/yaron.hirsch/Sources/tibra/COM-226/'); you may be able to use bzr upgrade."
<GungaDin> any help please?
<LarstiQ> GungaDin: ehm
<LarstiQ> GungaDin: the tags error is unrelated to what you previously did
<vila> lifeless: bzr.dev revno 4581 breaks --parallel=fork, is there some subunit pending merge I need that isn't found in lp:subunit ?
<vila> lifeless: breakage is about expected failures and unavailable features\
<pigmej> Hey everyone
<pigmej> Has anyone tried ClueBzrServer and/or ClueMapper with bzr ?
<jml> lifeless, I'm in Dublin
<vila> jml: welcome to my TZ :-)
<jml> vila, thanks :)
<mityaj> hi! help me! why  uploading data to master branch generate big traffic(over 10 MB) when commiting changes of little text file?
<mityaj> why by uploading data to master branch does so much traffic generate transfer when I commit changes of short text file
<LarstiQ> mityaj: what format/transport/version of bzr?
<mityaj> LarstiQ: bzr 1.16
<LarstiQ> mityaj: you only answered 1/3rd of my question :P
<mityaj> LarstiQ: sftp
<mityaj> LarstiQ: Bazaar Branch Format 6
<LarstiQ> mityaj: the repository format is more importance, just `bzr info` should tell you
<mityaj> LarstiQ: format: pack-0.92
<LarstiQ> mityaj: k
<LarstiQ> mityaj: did you commit a merge? Or where you previously out of date with master?
<LarstiQ> mityaj: sftp is a so called 'dumb' transport, so potentially reading the index files from the remote end is going to be a sizeable transfer too
<mityaj> LarstiQ:   What should I use instead of sftp?
<LarstiQ> mityaj: or if a pack got performed
<LarstiQ> mityaj: bzr+ssh://, but that requires bzr installed on the remote end
<mityaj> LarstiQ: thank you, I'll try
<lifeless> vila: no, e verything should be landed
<lifeless> vila: (everything in subunit relevant to bzr parallel that is)
<vila> lifeless: weird
<lifeless> jml: theres a subunit patch up if you wanted to review it it would rock
<jml> lifeless, sure thing. I'm probably going to stay in tonight, so I'll try to look at it then.
* You're now known as ubuntulog
<lifeless> you might like the talk I gave at slug too
<lifeless> theres an announce on the subunit lp page
<vila> lifeless: http://paste.ubuntu.com/245975/ "fixes" the problem for me but it also lose the /nnnn in the progress bar :-/
<jml> vila, hey, since I'm in your timezone...
<jml> vila, can you have a look at this? https://bugs.launchpad.net/bugs/408342
<ubottu> Launchpad bug 408342 in bzr "'bzr up' fails against a read-only remote, trying to create a write lock" [Undecided,New]
<vila> lifeless: did you see http://paste.ubuntu.com/245975/, digging deeper, I can confirm that ConcurrentTestSuite and CountingDecorator are incompatible because TextTestRunner.run explicitly tests isinstance(test, testtools.ConcurrentTestSuite) around line 600
<lifeless> kk
<DaffyDuck_> I exported the netbsd sources, then ran "bzr init --2a" in the directory, "bzr add" and finallt "bzr commit -m 'Initial commit.'". I got a memory error.
<DaffyDuck_> So I increased process memory usage to 512MB, then I could add and commit the files.
<DaffyDuck_> ...but I can't branch it. I get some internal error. 512MB doesn't seem to be enough.
<DaffyDuck_> bazaar doesn't scale very well. :(
<DaffyDuck_> Is there anything one can do to make bazaar use less memory?
<Kinnison> define "The netbsd sources" ?
<SamB> DaffyDuck_: prod the developers?
<SamB> DaffyDuck_: I think it's a bit worse than usual at the moment ... some kind of major rejigging of how transfers are done?
<SamB> DaffyDuck_: oh, and anyway that sounds like kind of a dumb thing to do -- wouldn't you want to import the history?
<SamB> DaffyDuck_: btw ... what were the file count and total size of the tree you tried to import?
<DaffyDuck_> SamB: I don't really need the history. I'm developing something on a specific branch.
<DaffyDuck_> ..and it's about 99138 files.
<DaffyDuck_> It's just a plain "cvs export -r netbsd-5-0-RELEASE src", and nothing else.
<LarstiQ> DaffyDuck_: so, what is that exactly? (ref Kinnison's "define netbsd sources")
<LarstiQ> DaffyDuck_: kernel/base system/ports?
<DaffyDuck_> The entire system sources.
<DaffyDuck_> The src module, not including x or pkgsrc.
<LarstiQ> ok
<LarstiQ> DaffyDuck_: keep in mind we don't (necessarily) know netbsd :)
<DaffyDuck_> None the less, it's an excellent testcase for the bazaar developers. :)
<LarstiQ> right, people have been known to version the gentoo/netbsd ports or entirey of Debian before
<LarstiQ> DaffyDuck_: the thing about history would be that each commit is more reasonable than one humongous change
<LarstiQ> DaffyDuck_: having said that, I think SamB is right about specifcally 2a needing some bits to be ironed out
<DaffyDuck_> The first problem appears to be a simple "out of memory" error. Increasing memory size helped. The second problem was a branching problem, which may also be a memory limit issue. The third actually looks like a mini-server (bzr+ssh) problem, but it may be a memory issue as well.
<DaffyDuck_> Should I file a complete bug report?
<LarstiQ> DaffyDuck_: that sounds like 3 different ones, but yes please. The bug filing process should prompt you with similiar bugs (some of yours might already be filed)
<LarstiQ> and if not, it is much easier to set dupes than to split a bug in pieces
<DaffyDuck_> Ah, good point. I'll file three bug reports.
<DaffyDuck_> Just out of curiosity, are there any (semi-)hidden options which dump relevant information useful to the bazaar developers?
<LarstiQ> DaffyDuck_: what kind of information? `bzr info` and possibly `bzr -Derror` (info otherwise in ~/.bzr.log) for general information
<LarstiQ> DaffyDuck_: `bzt dump-btree` is a hidden one specific to some formats, but I doubt you'll need that
<DaffyDuck_> OT: Is there a goo way to link from one PR to another in bug-thingie in launchpad?
<LarstiQ> DaffyDuck_: linking bugs together? you can say 'bug 12355' and it will show up in the ui as a link
<ubottu> Launchpad bug 12355 in xorg "Dell Optiplex GX100 only get 640x480 resolution with live cd (dup-of: 12248)" [Medium,Invalid] https://launchpad.net/bugs/12355
<ubottu> Launchpad bug 12248 in xorg "[i810] ddc sync ranges get lost in mode validation" [Medium,Fix released] https://launchpad.net/bugs/12248
<LarstiQ> also, saying it in here will let ubottu give some info ;)
<DaffyDuck_> Aha! Excellent. Thanks!
<jam> sidnei: just to let you know, I used 1.0rc8 on Kerguelen and everything seems to build
<sidnei> jam: cool, thanks for letting me know
<LarstiQ> jam: iirc you've done things about not holding huge files in memory at once, how about large inventory(deltas) like with DaffyDuck_ trying to commit all of netbsd src in one go?
<jam> LarstiQ: so we should be holding a single copy of file content during commit for 2a format repos
<jam> As for the large tree shape, etc
<jam> I haven't really done memory profiling there
<DaffyDuck_> I'm writing a bug report with complete instructions on how to repliacte the problems I've encountered.
<jam> sidnei: can you think of an easy way to have it put a build number into the final executables?
<jam> so I can get "bzr -setup-1.17-1.exe ?
<sidnei> jam: you could pass it on the command line?
<jam> given the command is "make installer-all" I'm not sure what you would pass
<jam> I'm happy to say at build time "this will be the -1" installer
<jam> I just don't know how to get that info passed around
<sidnei> jam: 'make installer-all BUILD_REVISION=-1' would work?
<jam> yeah, probably be fine
<sidnei> jam: ok, that's not too hard to do.
<DaffyDuck_> bug #408526, in case anyone wants to take a look at it.
<ubottu> Launchpad bug 408526 in bzr "bzr commit on large projects require large amounts of memory" [Undecided,New] https://launchpad.net/bugs/408526
 * SamB wonders why jelmer has all these imports at the beginning of cmd_svn_import.run ...
<LarstiQ> SamB: I'm presuming because they're not shared and provide a import hit otherwise
<SamB> actually, the main issue I have with it is how ugly it all is ;-)
<LarstiQ> hmm?
<SamB> LarstiQ: having all that stuff between the "def run(<args>):" and the actual code
<SamB> that's kind of ugly
 * LarstiQ looks up the cod
<LarstiQ> e
<LarstiQ> that is a sizeable amount of imports
<LarstiQ> SamB: have you looked at annotate/log for those lines?
<SamB> say ... is it possible to have a RegistryOption that filters the registry?
<SamB> LarstiQ: hmm, no ...
<LarstiQ> SamB: on uglyness, I wish python module loading, and python interpreter startup was much faster
<SamB> see, I want to allow specifying a repository format to bzr svn-import
<SamB> I've got that working, but now "bzr help svn-import" lists a bunch of --<format> flags that aren't actually applicable
<LarstiQ> ah
<LarstiQ> SamB: those formats need to move out of the way anyway
<jam> sidnei: so I found a small problem with the build script.
<jam> If you change the release version for a given plugin
<jam> it *doesn't* properly update the 'release' directory
<jam> (specifically, I did a build with bzr-rewrite-0.5.2 and then updated buildout.cfg to use 0.5.3 and the 'release' directory was still at 0.5.2)
<jam> I *think* what I want is to delete all of the release directories before doing a new build
<sidnei> jam: +1
<jam> sidnei: so is this something that should be part of gf.release.bzr ?
<jam> or should I just change the Makefile to do "rm -rf build-win32/*/release" ?
<jam> (especially in ':strict' mode... :)
<jam> also, when I build the python installers
<jam> I delete the extra plugins
<jam> I think I can mimic this by just changing the build order
<sidnei> jam: do the latter for now. i have the impression that it should have detected the change and wiped the release directory, need to investigate.
<jam> so that we build the python installers before we install the plugins
<SamB> jam: wouldn't you still have to delete any that were already installed ?
<jam> SamB: this is the build process, it is building into a new scratch dir
<jam> so it only has things I've put there
<sidnei> jam: that sounds right to me as well.
<jam> I don't remove launchpad and netrc, just svn, etc.
<jam> because they require that the python install location has lots of extra dependencies
<jam> like PyQt or subversion libs
<jam> and those aren't bundled, like the all-in-one installer
<jam> sidnei: k
<jam> so for now, I'll add an 'rm' call
<jam> but I would like to understand why gf.recipe.bzr isn't doing that for me
<SamB> hmm ... how do I have check_conversion_target give details as to why it failed ...
<sidnei> jam: ok. i need to go away for some hours. i will come back with an answer tomorrow for you.
<jam> np
<SamB> oh, maybe that's not what's failing
<jam> sidnei: have a good evening
<jam> sidnei: I'm also now having problems re-running the script because of 'uninstall' issues again:
<jam> """
<jam> While:
<jam>   Installing.
<jam>   Uninstalling bzr-rewrite.
<jam> Error: Abort uninstalling, because of pending local changes.
<jam> I'll see if it is my problem, though
<jam> sidnei: a more complete traceback (when you get back): http://paste.ubuntu.com/246654/
<jam> It seems to be trying to access my default push target
<jam> which certainly doesn't exist for this branch
<jam> ah, it seems to be confused because I have a default push location for all branches
<jam> but that branch certainly doesn't exist for the staging location
<jam> and then it tries to do "bzr missing" but obviously there is nothing that can be done, because the other branch doesn't exist
<jam> sidnei: adding this to my bazaar/locations.conf seemed to get it working again: http://paste.ubuntu.com/246661/
<jam> I would guess you'd want to handle this differently, though I guess I'm not positive to that effect.
<krisives> Hi all :)
<krisives> I have a website I want to put under version control. Would it be wrong to bzr init the public_html ?
<krisives> Anyone here?
<vxnick> krisives: would you want others to be able to branch your website?
<krisives> No, I wanted this to be internal
<krisives> Well, other developers, yes.
<vxnick> krisives: in that case, create the repo locally or out of the web root and then use something like bzr-upload to FTP the website to your server
<jam> krisives: I personally version public_html
<jam> and just tell Apache's config not to share .bzr
<jam> bzr-upload is a reasonable way to do it, though
<krisives> I want to version it on the host, since I have root access etc.
<krisives> Will it create a .bzr inside each sub directory?
<vxnick> nope
<krisives> Thanks!
<krisives> Can I .htaccess the .bzr directory without issue?
<krisives> I think requiring basic HTTP auth will be okay for people who want to branch
<vxnick> krisives: or you could branch using the SFTP transport instead of HTTP
<vxnick> depends on how you want to do it really
<Noldorin> hello
<vxnick> hi
<Noldorin> having some strange issues pushing a repo to an FTP server
<Noldorin> http://pastebin.ca/1517195
<Noldorin> those are the error messages returned
<vxnick> I've not encountered that before, but I'm guessing it'd be the FTP server software rather than bzr
<Noldorin> vxnick: yeah, i thought so...
<Noldorin> but i've double checked that all the permissions are set
<Noldorin> so i'm not sure what could be wrong
<vxnick> which permissions did you check? each line is providing two by the looks of it
<Noldorin> vxnick: all of them. (including change permissions)
<vxnick> afraid i'm not sure then
<vxnick> the only thing I can suggest doing is going through the FTP server config to see if there's any compatibility mode you can enable, or similar
<Noldorin> vxnick: good idea. it's probably a longshot, but worth checking
<vxnick> good luck with it
<Noldorin> heh, cheers.
<krisives> If I bzr ignore a directory will it ignore it's children?
<Noldorin> krisives: yes
<krisives> Okay, because I am doing this on production and some directories will have lots of user-made files inside them. bzr will not bother scanning it if ignored, right?
<Noldorin> yeah, it won't even display them in the status list
<krisives> I love bzr!
<vxnick> same :)
<Noldorin> :)
<krisives> I don't waste time figuring out cryptic erorr statuses or lockings
<Noldorin> i hate bzr at the moment... but i'll love it again once this issue is fixed
<Noldorin> (honestly, it's probably the ftp server's fault)
<krisives> Maybe I can help, I have done some stuff with bzr on restricted hosts (GoDaddy)
<krisives> (Although I assume you're idling in here you must know more than me)
<krisives> Reading your issues above, one sec
<Noldorin> krisives: not exactly :) i'm happing to take suggestions from you
<Noldorin> krisives: i get the following errors when trying to push: v
<Noldorin> http://pastebin.ca/1517195
<krisives> Is it wrong to just delete the lock file (assuming only one person is using it) btw?
<krisives> I like your username on the FTP ;)
<vxnick> I've done it a few times with no ill effect
<krisives> Noldorin: can you CHMOD normally with this FTP?
<Noldorin> krisives: my username?
<Noldorin> krisives: erm, i shuold really check that now
<krisives> Noldorin: "pos@213.175.198.12"
<Noldorin> krisives: see the end of the previous line ;)
<Noldorin> line-wrap
<krisives> oh, lol
<Noldorin> heh
<krisives> It's possible that the FTP is using some kind of file system that doesn't support permissions :-/
<krisives> (FAT32)
<Noldorin> krisives: the site manager for my web host displays unix-like permissions
<Noldorin> so i doubt it
<krisives> If you're in *nix you could try a CHMOD with the `ftp` program to get more details on what happened
<Noldorin> i'm on vista
<Noldorin> erm, the server is windows though.
<krisives> What do you use to modify the permissions?
<Noldorin> even though it seems to have unix permissions
<krisives> Filezilla?
<Noldorin> yeah
<Noldorin> Command:	SITE CHMOD 755 repos
<Noldorin> Response:	500 'SITE CHMOD 755 repos': command not understood
<Noldorin> from filezilla
<Noldorin> hrm
<krisives> Seems like your host has CHMOD disabled
<Noldorin> silliness
<krisives> Try removing the execute
<Noldorin> it's a paid host
<krisives> Maybe they just don't let you set execution rights
<Noldorin> so i'd hope i can enable it still
<Noldorin> yeah
<lifeless> vila: what is the url to your buildbot?
<krisives> Indeed, should be able to do this on almost any host
<Noldorin> storm internet is the host in case you are familiar...
<krisives> Try chmoding as 664
<krisives> That's R/W but no X
<Noldorin> krisives: ok
<krisives> If you're looking for a good cheap host I use these guys and they installed bzr on the server for me: http://holeinthewallhosting.com/ ($10/year)
<krisives> http://67.43.13.30/~kives/test.php is their PHP info
<Noldorin> krisives: same error unfortunately
<krisives> I haven't got around to testing it fully yet though
<krisives> Hmm, I would contact them and find out why you can't CHMOD
<Noldorin> krisives: thanks. unfortunatley i use asp.net though
<Noldorin> yeah
<Noldorin> will do
<krisives> It's possible they setup the account with the wrong permissions
<krisives> Some Windows hosts don't have permissions either :-/
<Noldorin> that would be major fail
<Noldorin> krisives: i've just emailed my web host... have to see what they say
<krisives> Good luck :)
<Noldorin> they've replied promptly and helpfully in the past
<Noldorin> so hopefully it will be good news
<Noldorin> krisives: heh thanks :)
<Noldorin> appreciate your help anyway
<krisives> What are you using BZR for, just curious?
<krisives> I am just curious*
<Noldorin> krisives: hosting my IRC bot code :)
<Noldorin> though i plan to use it for hosting all my projects eventually
<Noldorin> krisives: i chose the web host for other reasons though mainly (ASP.NET support for example)
<poolie> hi all; hi jam
<krisives> Noldorin: Why ASP.NET anyhow?
<Noldorin> krisives: i'm a .NET developer, and i've learnt to love it :)
<Noldorin> it's what i know well
<Noldorin> the AJAX framework is cool too
<krisives> Noldorin: Have you ever used MONO?
<krisives> It's available on Linux hosts
<Noldorin> krisives: yes, a bit
<Noldorin> krisives: the ASP.NET support isn't great though
<krisives> I can understand if you're committed to .NET though
<Noldorin> certainly no entities framework
<Noldorin> yeah
<Noldorin> i'm a bit of an MS guy still :P
<Noldorin> even though i admire the mono project
<Noldorin> i've even taken a close look at it
<Noldorin> certain parts
<krisives> Using bzr on windows pretty legit? Never done it myself
<Noldorin> legit?
<Noldorin> of course
<Noldorin> they release a version for windows lol :)
<Noldorin> krisives: i've host bzr repos on another ftp account of mine for a long time
<mobodo> what's the easiest way to provide browsing from the web to a bzr repository?
<mobodo> (browsing as in from the web)
<mwhudson> mobodo: loggerhead
<mobodo> mwhudson: I looked at loggerhead, but I was under the impression that I'd need admin access to the web server, am I wrong?
<mwhudson> you only need admin access if you want to put it behind the apache or whatever
<mwhudson> (but this would be true of absolutely anything)
<mobodo> where else would I want to put it?
<mobodo> loggerhead will run its own server, right?
<mwhudson> yes, in that it talks http on a port you provide
<mobodo> mwhudson: that's pretty much what I mean by "I was under the impression that I'd need admin access to the web server"
<mobodo> I'm not going to run a daemon on a shared server, let alone run it on port 80
<mwhudson> mobodo: so i'm unsure what answer i could give you that you'd be happy with
<mobodo> :)
<mobodo> I was wondering if there's a cgi script that will let me browser a .bzr
<mwhudson> oh right, cgi
<mobodo> like you can do with cvs/svn
<mobodo> yup
<mwhudson> not aware of any cgi scripts for that no
<mobodo> alrighty
<mwhudson> the 1990s are calling, they want their tech back :)
<mobodo> huh?
<RenatoSilva> verterok: hi
<mobodo> bazaar is totally awesome btw. I had been looking for a while for a version control system that would work over generic http
<mobodo> it's perfect for distributed anonymous development
<mwhudson> mobodo: sorry
<mwhudson> mobodo: just trying to joke that cgi isn't an often requested thing these days
<mobodo> mwhudson: ahh :) see, that's how deep in it I am for not even getting the joke
<andresj> hello, is there a way to tell bzr to use ./adir/.bzr as its directory instead of ./.bzr ?
<krisives> I also am interested in the answer to that
<krisives> As it would be nice to have my public_html/.bzr just be ../.bzr
<andresj> my case is actually, in a way, backwards. I have a directory /my/site which i cannot modify. However, I can modify /home/public, /home/private, and /home/protected. I want to have these directories version-controlled, and use ./private/.bzr as my repo dir
<beuno> krisives, your case is easy, just have a public_html dir as your top level
<beuno> andresj, I don't think you can change bzr's location
<krisives> beuno: Won't the .bzr be in public_html/.bzr though?
<andresj> beuno: hum... any suggestions, then? :D
<krisives> beuno: I see, I thought it would put the .bzr into the public_html if it was versioned
#bzr 2009-08-04
<beuno> krisives, no, bzr only stores it on the top level
<beuno> andresj, I don't know what you want to do  :)
<beuno> my instinct is that you could use bzr-upload
<krisives> Or a symlink?
<beuno> to deploy your cahnges without a .bzr dir
<andresj> bzr-upload? that sounds like it would do its job tremendously well
<andresj> i have a production server, which has the constraints i talked about
<beuno> andresj, yes, bzr-upload pushed the changes that have been made since the last revision
<krisives> To ignore a directory do I do `bzr ignore dir/` or `bzr ignore dir/*` ?
<andresj> then i have a development server, which is hosted in my own machine, so it doesn't have sch constraints
<beuno> uses sftp or ssh
<andresj> does bzr-upload need a .bzr dir?
<andresj> (on the "to" side)
<beuno> not remotely
<beuno> it just stores the last revid uploaded in a hidden file on the remote end
<andresj> ##awesome! :D sounds like a good candidate
<andresj> hum... does that file need to be in the "root" of the remote end's repo?
<krisives> Will `bzr ignore` remove it from version control, or do I also have to `bzr remove --keep dir/` ?
<beuno> andresj, https://edge.launchpad.net/bzr-upload
<andresj> ok, i'll check it out :D
<beuno> andresj, it places it on the root of wherever you tell it to upload
<andresj> hum...
<beuno> but that's much easier to change
<andresj> oooh
<beuno> I can tweak that for you, I'm one of the authors  ;)
<andresj> soudns like a good candidate for a one-word deploy command!! :D
<beuno> andresj, that's exactly what motivated it  :)
<andresj> beuno: lol it would be amazing if you could do that :D
<beuno> andresj, do what?  specify where you want to store that file?
<andresj> beuno: yes.
<beuno> it's just a text file with the revid, has no information
<beuno> but I can easily add a switch that changes it's location  (I think)
<beuno> let me play with it for a bit
<andresj> well i can play around with it; wouldnt want to spend too much of your time :D
<beuno> andresj, if it's a one-off you can just edit the plugin
<beuno> you can even make it upload automatically every time you commit if you want to
<beuno> line 106 of __init__.py specifies where it stores the revid
<andresj> that would actually be awesome.
<andresj> decision: trunk or ubuntu .dev
<andresj> * .deb
<beuno> I'd go with trunk
<andresj> same thoughts here :P
<beuno> http://bazaar.launchpad.net/~bzr-upload-devs/bzr-upload/trunk/annotate/head%3A/README
<beuno> that should give you a nice overview
<andresj> wow, thank you so much! :-) launchpad should have manual "add karma points" option ;P
<beuno> I have IRC karma I add on to manually  ;)
<andresj> lol well that i completely missedâam i not informed enough about these concepts? :P
<AfC> I bought beer for a hacker once. That should also get me Lauchpad karma points.
<krisives> lol
<poolie> i think it should have a 'thanks' button
<poolie> it's nice there is one in answers, but it should be everywhere
<wgrant> That was shot down.
<poolie> maybe it could have a beer bottle icon, but that may give offence to some people
<wgrant> Just recently.
<poolie> wgrant: really? :/
<wgrant> Yes.
 * wgrant finds the bug.
<wgrant> Bug 394076
<ubottu> Launchpad bug 394076 in launchpad-registry "[feature] Add facility to say Thanks to launchpad users" [Undecided,Invalid] https://launchpad.net/bugs/394076
<poolie> i think we should reopen it
<poolie> i don't know if it will get done soon though
<andresj> self.upload_full_tree(): NotImplementedError
<andresj> aaaah
<andresj> no support for symlinks, right?
<bob2> is that the bzr-upload plugin?
<andresj> yes
<andresj> I replaced raise NotImplementedError with continue; maybe i'll implement symlink support later :P
<mobodo> are there bzr binaries available anywhere?
<mobodo> (for linux)
<sidnei> mobodo, you mean ubuntu *wink*
<mobodo> actually, let me check, I'm not sure
<wgrant> The Pyrex bits are just for speed, aren't they?
<sidnei> mobodo, i assume you have looked at this page: http://bazaar-vcs.org/Download
<sidnei> wgrant, mostly confident that's correct.
<lifeless> wgrant: today, the C extensions are all optional, but *strongly recommended*
<mobodo> ah, right, I can extract from a ppa
<lifeless> wgrant: behaviour isn't identical without them, in particular data compression is reduced without the extensions
<wgrant> lifeless: Oh.
<wgrant> I see.
<lifeless> wgrant: for the record, not all the extensions are pyrex either
<mobodo> I feel dumb, I can't even find the linux flavour of my web server :P
<mobodo> uname -a should do it, right?
<mobodo> CentOS... oh my...
<lifeless> fedora RPM's may be the go for you
<mobodo> I'll try that... I need to install locally, so rpm will be easier
<SamB> hmm ... what's a repository format that isn't going to be deprecated for a long time?
<SamB> but isn't bzr-svn's default format either now or soon?
<lifeless> 2a
<SamB> you see, I'm trying to write a blackbox test like jelmer asks for here: https://code.launchpad.net/~naesten/bzr-svn/408560-format-flags/+merge/9606
<lifeless> SamB: we deprecate rarely. whats bzr-svn's current default?
<SamB> I'm adding support for specifying the format for an "svn-import"
<SamB> hmm ...
<SamB> rich-root-pack
<SamB> it seems
<fullermd> I think it actually uses default-rich-root, so whatever that points to at a given point in time...
<igc> morning all
<SamB> fullermd: ah
<SamB> well, I want a format that will be around for a while but definately isn't that in the future ;-)
<lifeless> SamB: 1.9-rich-root then
<lifeless> hi igc
<SamB> thanks
<igc> hi lifeless
<SamB> igc: better?
<igc> hi samb
<SamB> you were sick, I believe?
<igc> SamB: still recovering but orders of magnitude better
<igc> SamB: I had some surgery last Monday (stoma reversal) that was meant to be a few nights in hospital but ...
<igc> SamB: things didn't go so well
<SamB> ah
<igc> SamB: nothing a few days in intensive care, several bags of blood and a second operation couldn't fix though
<igc> SamB: so I'm tired & ticked off with the world but I'll get over it
<lifeless> igc: hi, so faster commit is this || close
<igc> lifeless: that's exciting - well done
<lifeless> igc: if you grab bzr+ssh://bazaar.launchpad.net/~lifeless/bzr/iter-changes-partial-parents and merge bzr+ssh://bazaar.launchpad.net/~lifeless/bzr/commit-specific-files
<igc> lifeless: I'll take a look when I get a moment
<lifeless> the two combined make specific and full commits the same speed for launchpad [hot cache]
<SamB> lifeless: that's too bad
<SamB> because there is no || in python
<lifeless> hold up your thumb and index finger close together
 * SamB ;-P
<SamB> anyway ...
<SamB> it seems that 1.9 and 1.14 aren't distinguishable by "bzr info"?
<lifeless> 1.14 is only a new working tree format
<SamB> ah.
<SamB> so no-working-tree => indistinguishable :-)
 * igc food
<kfogel> 'bzr branch lp:mup' gets the "Absent factory" error (bzr bug #408251) for me.  Wonder if it's my lp plugin?
<ubottu> Launchpad bug 408251 in bzr "ErrorFromSmartServer: Error received from smart server: ('error', "Absent factory for ('**')")" [Undecided,New] https://launchpad.net/bugs/408251
 * spiv -> lunch
<spiv> kfogel: I see that error too, it's not a bug in your client
<kfogel> spiv: dang
<spiv> kfogel: at a glance it looks like the remote branch is faulty.
<kfogel> spiv: I really want to get lp:mup, too.  Thing is, my branch is not the same as the original one in the bug.  CAn that many branches on lp be buggy?
<spiv> kfogel: probably with the "classic" bug, not a new problem
<spiv> kfogel: yes, please read the description of https://bugs.edge.launchpad.net/bzr/+bug/354036
<ubottu> Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Undecided,Confirmed]
<spiv> kfogel: certainly the workaround (bzr branch nosmart+lp:mup) will work for you.
<kfogel> spiv: thx
<SamB> spiv: huh ... why does that look so much like the "bzr send is broken with chk" bug?
<kfogel> spiv: do we think those two are dups?
<kfogel> bug #40825 and bug #354036
<ubottu> Launchpad bug 40825 in linux-source-2.6.15 "Xubuntu Live CD doesn't boot right on laptop" [Medium,Invalid] https://launchpad.net/bugs/40825
<spiv> kfogel: maybe, I don't know.
<ubottu> Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Undecided,Confirmed] https://launchpad.net/bugs/354036
<kfogel> heh
<kfogel> I meant bug #408251
<ubottu> Launchpad bug 408251 in bzr "ErrorFromSmartServer: Error received from smart server: ('error', "Absent factory for ('**')")" [Undecided,New] https://launchpad.net/bugs/408251
<kfogel> spiv: ok
<spiv> The difficulty is that that error is not a very precise symptom.
<spiv> And the cause tends to be somewhat distant.
<SamB> how does that relate to bug 393349 ?
<spiv> i.e. a client with a bug does a push that appears to work, some time later someone else does a pull or branch and gets that error.
<ubottu> Launchpad bug 393349 in bzr "Bundle (bzr send) broken with --2a format" [Critical,Triaged] https://launchpad.net/bugs/393349
<spiv> Basically that error just means "a record that bzr expected to be there wasn't there"
<spiv> And that might be because bzr is looking for the wrong thing, or because it should be there but wasn't pushed, etc.
<SamB> maybe somebody should change AbsentContentFactory to give better AttributeErrors?
<spiv> SamB: it's a related class of problem
<spiv> SamB: (not sending enough data)
<SamB> I'm saying that it should say something about *what* content was absent
<spiv> Hmm, that's better phrased as "it's related because it's the same class of problem"
<SamB> not just look like someone forgot to implement a method ;-)
<spiv> Well, it does, mostly, it gives the key.
<spiv> (in current bzr)
<spiv> See kfogel's bug comment, for instance.
<SamB> spiv: ah, that's basically what I meant ;-)
<SamB> but maybe it should also give a clearer indication that AbsentContentFactories aren't expected to have ... whatever attribute?
<spiv> kfogel: so, the fixer script from 354036 does find some missing inventories on lp:mup
<spiv> kfogel: so your problem is almost certainly that bug.  Unfortunately due to the way codehosting works it's not enough to have an owner of the branch run the fix script :(
<kfogel> spiv: (sorry, in another conversation, will check backscroll and catch up soon)
<spiv> kfogel: summary: it's a dupe, and I've marked the bug as such.
 * spiv -> really lunch.
<kfogel> spiv: ah great, thanks
 * kfogel is away: sleep
<poolie1> igc, not urgent, but would be curious about your comments on https://code.edge.launchpad.net/~mbp/bzr/408193-hardlink/+merge/9567
<igc> poolie1: sure. I certainly won't get it today though sorry
 * poolie1 reading https://code.edge.launchpad.net/~jameinel/bzr/1.18-bundle-and-stack-393349/+merge/9334
<vila> hi all
 * fullermd waves at vila.
<igc> hi vila
<vila> hey igc, glad to see you here :)
<igc> vila: yeah - it's good to be back in the land of the living :-)
<vila> igc: I'm grumpy too this morning if that's of any help :-D
<igc> vila: :-)
<fullermd> Grumpiness is healthy.  It shows that your mind is working well enough that you're not saddled with optimism or other such disorders.
<ronny> fullermd: a set of well-placed optimism helps tho
<fullermd> Pshaw.  Optimists are the people who put water in a glass so they can DROWN you in it.
<ronny> fullermd: if i didnt have some optimism i wouldn't brother with the opensource work i do
<ronny> fullermd: also i figured how to drown you with a drop of water
<mdke> lifeless: around?
<fullermd> Oh, that doesn't require optimism.  Just the conviction that everybody else is incompetent, and if you want something done right, you'll have to do it yourself   8-}
<ronny> fullermd: oh, lol
<ronny> fullermd: i get that surprisingly often
<fullermd> Arrogance is an excellent substitute for optimism, altruism, and various other alternate sources of gumption.
<mdke> perhaps someone else may also be able to help. I need to merge a bzr branch which has been imported from git with a bzr branch that was imported from svn. lifeless recommended I use "bzr fast-export" and "bzr fast-import" but I haven't got those commands
<mdke> I'm running bzr 1.17 - is there a newer version I need?
<fullermd> mdke: They're part of the fast-import plugin.
<mdke> doh
<mdke> fullermd: thanks!
<ronny> fullermd: i dont like arrogance tho, it enables higher falure rate
<fullermd> Only if you're incompetely, like Everybody Else, see.  It totally doesn't apply to Me.
 * bialix tired to unpack zipped branches to do some work with them
<mdke> hmm, I still don't have the command, having installed bzr-fastimport (0.0.1~bzr112-0ubuntu1)
<bialix> how hard would be to implement zip transport or zip+ decorator
<bialix> ?
<ronny> fullermd: humans tend to fail, and tend to liet to themself about it
<bialix> any hints?
<mdke> aha, it's bzr-fast-export
<fullermd> Lying to yourself is ineffective.  There are always other people around to remind you that you're doing it.
<fullermd> That's where mass murder comes into the picture...
<mdke> next questions. lifeless said to use the -r parameter for the export, but bzr-fast-export doesn't seem to have such an option
<bialix> spiv: around?
<ronny> fullermd: when you are better than most people around your current location, they kind of aint in that position
<fullermd> mdke: I've got it in mine.  The release/package may be Really Old.
<mdke> hmm
<fullermd> mdke: Mine says "0.8dev", just pulled as a branch.
<ronny> meh, so far i need the internet to get equivalent and/or better peers
<spiv> bialix: yeah
<spiv> bialix: what can I break^Wdo for you today? :)
<mdke> fullermd: ok, I'll look for a newer version, mine seems to be coming from Ubuntu rather than the bzr ppa
<bialix> spiv: I feel the need to write plugin to work with zipped branches, any hints?
<spiv> bialix: as in a .bzr directory in a zip file?
<bialix> spiv: what is better: zip transport (subclass of Local) or zip+ decorator?
<bialix> entire branch inside zip, yes
<spiv> Hmm, I think a new transport.
<mdke> fullermd: there is a newer version in Ubuntu Karmic, I'll try it there. Thanks again for your help
<spiv> Otherwise what would get_transport('zip+file://....').clone('foo') mean?
<spiv> Does that mean a new zip file, or would it mean a new file inside a zip?
<bialix> spiv: I guess I want read-only transport
<spiv> I think you need more like "zip://<escaped url of zip file>/path/inside/zip"
 * bialix upgrade to ff 3.5.2, sorry if I'll disappear for a bit
<spiv> Or possibly create a ZipServer along the lines of ChrootServer
<spiv> (So URLs like zip-111111://... that are just in-process names for an already-open zip file)
 * bialix back
<bialix> spiv: escaped url?
<spiv> 17:44 < spiv> Or possibly create a ZipServer along the lines of ChrootServer
<spiv> 17:45 < spiv> (So URLs like zip-111111://... that are just in-process names for an already-open zip file)
<spiv> I think that would be a better option.
<bialix> I don't understand
<bialix> in my imagination I'd like to work from command line as: bzr pull zip://path/to/archive.zip/branch/inside/zip
<spiv> Well, it depends a bit on exactly how you want it to work... you want to be able to do "bzr branch http://.../somefile.zip foo"
<spiv> Hmm.
<bialix> I think valid URL for branch inside zip could be zip://path/to/archive.zip/branch/inside/zip
<bialix> so path/to/archive.zip is actually zip file
<spiv> Ok, that works, but only for local paths obviously.
<spiv> If you're fine with that restriction then go for it.
<bialix> yep, that's why I've asked about zip+ decorator
<spiv> (zipfile://... might be clearer?)
<spiv> Or rather, it works with some hackery.
<bialix> zipfile? maybe it is, but longer to type
<spiv> You can't just look at the URL you propose and know what the path to the zip file is.
<bialix> yes, I guess I need to introduce some restrictions
<spiv> Which is why I proposed a scheme more like http
<spiv> Where you have a netloc (host) and a path.
<bialix> or use different URL scheme, as discussed with colocated branches
<bialix> what is netloc?
<spiv> jargon for the "host" part of "http://host/foo", roughly.
<bialix> ok, I understand
<bialix> but no, it will complicate of usage
<spiv> So, zip://path%2Fto%2Farchive.zip/branch/inside/zip, for an ugly example.
<bialix> it's really ugly
<spiv> Yep.
<bialix> and I can't use tab-completion then
<bialix> I can try to find zip file recursively, trying to open path/to/archive.zip/branch/inside/zip, then path/to/archive.zip/branch/inside etc
<spiv> I think there's a better way.
<bialix> once I found zip file I'll use remainder as relpath inside zip
<bialix> what about read-only?
<bialix> is it declared somehow or I just need not to implement write methods?
<spiv> bialix: I think implementing a ZippedBzrDir would actually work better.
<bialix> why?
<spiv> bialix: then plan paths and URLs would Just Work, no new URL syntax in the UI necessary
<bialix> ah, and I can reuse std probing?
<bialix> hi Gary!
<garyvdm> Hi
<spiv> And you won't have this friction with probing in a transport, which in your proposal you'd either be redoing *lots* or doing a hack to share state between Transports, which are mostly stateless.
<bialix> spiv: ZippedBzrDir will be enough? or I need ZippedBzrBranch as well?
<spiv> Right.
<spiv> Well, if I were to implement this, I'd make a ZippedBzrDir and then a ZipTransport/ZipServer
<bialix> perhaps I need to look at bzr-svn/bzr-git to see how they implement foreign formats
<bialix> I don't undertsand
<bialix> what is ZipTransport/ZipServer?
<spiv> The ZippedBzrDir would probe the transport it is given, and if it finds a zip file,
<bialix> garyvdm: can you look at failing test?
<spiv> then it would create a ZipServer object (which gives you a single place to open/close the zip file, and possibly do some caching),
<bialix> spiv: is there example of doing so?
<spiv> (the ZipServer would be backed on to the real transport)
<bialix> spiv: it sounds a lot like black bzr magic
<garyvdm> bialix: The qbzr treemodel test - yes - it will be easy to fix. I'll do it tonight.
<garyvdm> bialix: Sorry - I have been very busy with other things.
<spiv> And then construct a ZipTransport from the ZipServer, and then pass *that* back into regular BzrDir.open_from_transport
<bialix> garyvdm: we need to release qbzr in sync with bzr
<bialix> spiv: oh
<spiv> bialix: take a look at ChrootServer (and bzrlib.smart.server's serve_bzr function)
<spiv> But the ZipTransport here wouldn't be something that could be directly constructed from a URL from a user (just like you can't just pass a chroot:/... URL on the command line).
<spiv> bialix: if you look at ChrootServer it's a very simple class, and I imagine your ZipfileServer would be pretty simple too; basically just an object to hold an opened zipfile.
 * bialix looks at ChrootServer and serve_bzr
<spiv> (like how ChrootServer is basically just an object to remember what the backing transport is, regardless of any t.clone('..') etc done on the individual transport objects)
<bialix>     chroot_server = ChrootServer(transport)
<bialix>     chroot_server.setUp()
<bialix>     transport = get_transport(chroot_server.get_url())
<spiv> Right.
<bialix> I'm not quite understand how it prevents of clone('..')
<spiv> transport there will be an instance of ChrootTransport
<lifeless> mdke: hai
 * igc dinner
<bialix> so, should I subclass Chroot(Server|Transport) for Zipped*?
<spiv> Which implements every method of Transport by first checking the path is safe (see ChrootTransport._safe_relpath), and then calling self.server.backing_transport.<method>
<spiv> I wouldn't subclass Chroot* for you.
<bialix> just reimplement the logic?
<spiv> Yeah.
<bialix> last question: how can I force read-only?
<spiv> I suppose if you subclassed just ChrootTransport you'd be able to reuse all the shim methods... but it's not a very good fit.
<spiv> For that I'd just use the readonly+ decorator, I think :)
<bialix> oh, I found
<bialix> is_readonly method of transport should do
<bialix> so, I have two ways for my plugin: do only zip:// transport, or going hard path and implement ZipBzrDir, Server, Transport
<spiv> For the implementation of write methods like mkdir just raise TransportNotPossible("readonly transport"), just like ReadonlyTransportDecorator does.
<spiv> Personally, I think the latter is actually the easy path :)
<spiv> Because otherwise you're going to be fighting the design of bzrlib.transport rather than working with it.
<bialix> TransportNotPossible: ok
<spiv> (and return False from is_readonly, of course, as you've noticed)
<bialix> maybe you're right about easy path, I need to experiment with Server a bit
<bialix> spiv: thanks for the hints, I'll try to play with it
<spiv> Another example of the Server/Transport pattern is MemoryServer/MemoryTransport.
<bialix> ok
<garyvdm> Hi - Any advice on how I should respond to this: http://paste.ubuntu.com/247031/ ?
<luks> is it worth responding to?
<luks> convincing somebody that version control is useful can be tough
<garyvdm> luks - yes - I have to collaborate with this guy on a website...
<fullermd> In cases like this, I like to use swearing...
<jpds> garyvdm: How does he plan to keep track of change?
<garyvdm> At the moment, I'm commit his changes on his behalf.
<garyvdm> jpds: He doesn't
<bialix> garyvdm: I'm windows box person
<bialix> does my words as former windows maintainer will help?
<luks> I think the problem here is VCS in generally, not bzr specificially
<luks> *general
<garyvdm> bialix: The windows issue is easy to deal with.
<garyvdm> It the "why vcs?" issue that is hard.
<bialix> I don't understand what is windows issue here
<garyvdm> *It's
<garyvdm> bialix: FUD
<bialix> call vcs as automatic backup
<bialix> that's all
<maxb> Ask him how *he* plans to deal with merging changes when you are both doing work simultaneously, and then point out how VCS would make that so much easier?
<garyvdm> maxb: Yes
<luks> make him screw up something, so he needs an older version :P
<garyvdm> Or just keep on overwriting his changes...
<fullermd> I've used that technique with some success.
<fullermd> Though usually, the response ends up being an endless stream of commits with no log messages, and/or the log message "This week's work" every Friday at 16:55.
<maxb> And ask him how he would deal with discovering that a mysterious subtle bug was introduced some time ago, and explain about bisecting :-)
<luks> fullermd: better than nothing
<luks> one step at a time :)
<garyvdm> maxb: That will just go straight over his head...
<maxb> oh dear
<fullermd> Yeah, the response to that will be "Who cares where it came from?  It's there now, so fix it."
<bialix> fullermd: you talk about backup or overwriting changes?
<fullermd> bialix: Overwriting.
<fullermd> Or, you can keep checking it in for him.  And billing him for the time you spend doing so.
<garyvdm> This is what I'm sending him: http://paste.ubuntu.com/247060/
<bialix> there is always enough lights to one who want to see, and enough darkness to one who don't
<luks> heh
<luks> http://crossonline.blogspot.com/2009/08/howto-version-control-using-bzr.html - comparing bzr to rcs
<vxnick> anyone have any experience with bzr-keywords? Not sure how to get it working
<fullermd> Installing the plugin and enabling the filter got it working for me.
<fullermd> Shortcomings in filtering make it less than useful, though.
<bialix> I guess you need to use 2a format to enable filtering?
<fullermd> 1.14
<fullermd> (2a includes the new WT format too of course)
<vxnick> hmm
<vxnick> I setup some rules in ~/.bazaar/rules, but that didn't seem to do anything
<vxnick> and put a keyword in a test file
<fullermd> How are you checking that it does anything?
<vxnick> committing various changes to see if it updates the placeholder in the file with the revision info
<fullermd> That's one of the filter problems rearing its head.  Commit will never update them (expand if they're collapsed, or update if they're already expanded)
<fullermd> If you make a new 'branch' of it, they'll be expanded there.
<vxnick> ah I see
<fullermd> With a branch igc has on LP, they'll be updated on 'pull' too.
<fullermd> Still not commit (or, I think, merge either)
<vxnick> yep you're right, branching expands the keyword fine
<fullermd> revert also won't touch 'em.
<vxnick> that's annoying
<fullermd> Well, that's why I say "yes it works" and "less than useful" in the same breath  :)
<vxnick> I can see why :)
<fullermd> (and of course you can't test whether 'checkout' actually expands them either, since the default format doesn't include rules, and checkout still doesn't have a --format so you can tell it which WT format to use)
<vxnick> bah
<vxnick> is this a known issue or worth raising a ticket for on LP?
<fullermd> Well, there's bug 385879
<ubottu> Launchpad bug 385879 in bzr "EOL filter only applied to files when first checked out" [High,In progress] https://launchpad.net/bugs/385879
<vxnick> ah thanks
<fullermd> The title on that is slightly misleading, since it's really a filter bug, not an EOL (or keywords, for that matter) bug.
<vxnick> I'm guessinf the filter stuff is what's causing the expansion/collapsing problem though
<bialix> is it correct that `bzr rm` without arguments does not throw error?
<fullermd> I'm pretty sure that goes through the tree and explicitly sets removed status for missing files.
<bialix> ok
<poolie1> hello vila
<mobodo> has anybody ever done a local/user install of bzr?
<mobodo> oh, nevermind, it's on the faq :)
<mobodo> hmmmpfr, except that I need gcc to compile and I don't have access to it..
<Kinnison> You don't *need* the gcc IIRC
<Kinnison> it just makes things go faster if you can compile stuff
<poolie1> that's true
<poolie1> it is much better with it though
<vila> poolie1: just back from my lunch break !
<poolie1> pqm seems to be jammed, i just asked on #is
<ronny> hmm, appearantly renaming things is a quite pleasant operation on a memorytree, not so far for all the other things
<ronny> jelmer: you got any example for stuff like recording rename+content_change in subvertpy, the svn api is still like a black box to me
<jelmer> ronny: Rename is a copy + delete, there is no separate operation for that
<jelmer> I'll see if I can update the example to do a simple content change
<ronny> hmm, and i guess i'll have to invent something that records changes on one of my trees so i can do my own magic on each of the vcs's
<jelmer> ronny, updated example pushed
<igc> vxnick, fullermd: I really hope to take a look at the content filtering bugs this week or next
<vxnick> igc: excellent :)
<vxnick> that'd be much appreciated
<igc> xvnick, fullermd: I had planned to a week or so back but had some distractions (doc site upgrade) for a few days and then was off last week for medical reasons
<NEBAP|work> how can I add a user to a project on launchpad?
<vxnick> igc: understandable :) Will bzr-keywords then expand placeholders upon commit, etc, so we can see them in our local copy?
<igc> vxnick: ask me again when I'm awake :-)
<vxnick> np ;)
<igc> vxnick: seriously, if you put a bug report in explaining exactly what you expect, that's the best way for me to asynchronously respond
<igc> ... in a considered way
<vxnick> igc: fair enough, I'll stick a report, thanks
<mobodo> is it possible to list the content of a remote branch?
<vxnick> mobodo: bzr ls ?
<CaMason> I've branched from a main branch and made some changes. I've committed to my branch. How can I now merge back to the other one, whilst retaining my whoami info?
<bialix> merge does not change your whoami info
<CaMason> bialix, ah, it was because I did a selective merge for a particular revision
<bialix> it's called cherrypick
<CaMason> that's the one
<CaMason> so I cherrypicked to a different branch, then merged from that
<bialix> bzr has no good support for this
<bialix> I'm using replay command from bzr-rewrite plugins (former bzr-rebase)
<bialix> instead of cherrypick you can rebase/replay your revisions
<CaMason> this is ok for me - I've got one main working branch, but many of those changes aren't fit for the main trunk
<CaMason> I'll look that up
<bialix> CaMason: do you aware of DAG concept?
<CaMason> nope
<bialix> I'd recommend to read DaggyFixes document from monotone
<CaMason> great - will do
<bialix> after I've started to practice this method my cherrypicks went much better
<CaMason> this is what I've just done, right?
<bialix> I'm not sure what you done
<CaMason> ah it kinda is
<bialix> no, cherrypick to other branch and then merge -- it's like replay works
<CaMason> that's what I did :)
<bialix> DaggyFixes require you to branch not from the tip revision, but from the point where branches have diverged or earlier
<bialix> http://www.monotone.ca/wiki/DaggyFixes/
<CaMason> this is what I'm reading
<CaMason> good - I'm pleased with my ad-hoc decision
<corporate_cookie> the recommended install method for bzr on RHEL is to use the EPEL repo ..but it installs bzr 1.3.1!
<corporate_cookie> is there a repo with a more current version ? ...i mean whoa ..thats dusty
<bialix> CaMason: as you like
<CaMason> this document looks very useful as-a-whole, bialix
<bialix> yes, it is
<JNRo__> Hi guys, I'm having problems cloning.  The three repos I've tried just seize up midway.  The current one I'm waiting on says "Copying inventory texts:Copied record 262/294"  Is there some way to get more info about what is going wrong?
<JNRo__> This happens with repos on lp like fastimport and elsewhere like the one at bugseverywhere.org . Perhaps this is a known problem with high latency connections(3G in my case) and there is some workaround.
<slangasek> vila: jml has suggested that you are interested in bugs like 'bzr status' on an OOD condition resulting in a corrupted branch that I can no longer run 'bzr status' on even after cleaning up some space :)
<slangasek> ah, which james_w informs me is probably 131111
<slangasek> (bug #131111)
<ubottu> Launchpad bug 131111 in bzr "Dirstate breaks when updating disk with no free space" [High,Confirmed] https://launchpad.net/bugs/131111
<vila> slangasek: I wonder why jml said that :-) But what means OOD ?
<jml> vila, mostly because I know you like hard problems & are awake :)
<vila> jml: haaa, I see :)
<jml> vila, OOD = out of disk
<vila> So, if enough space if available now, I'm pretty sure there is a dirty trick to trigger rebuilding the dirstate file, I just don't remember it right now :-/
<james_w> yeah, I just walked Steve through it
<vila> We should really have one official way to force rebuilding it, even as an hidden command
<vila> james_w: care to refresh my deficient memory ?
<james_w> it's non-obvious though, as you can't even branch it due to the code to read from the working tree if it exists
<james_w> mv .bzr/checkout /tmp
<james_w> bzr branch . ../temp
<james_w> mv ../temp/.bzr/checkout .bzr/
<vila> ha yes ! Rebuild a decent dirstate file and then copy it back !
<vila> james_w: thanks
<james_w> np
<slangasek> vila: out of disk
<slangasek> right, laggy brain
<vila> slangasek: yeah, jml translated already, you're out of trouble no right ?
<vila> slangasek: yeah, jml translated already, you're out of trouble now right ?
<slangasek> yeah, the whole reason I was running 'bzr status' was to see whether I could throw it away to free up some more disk space ;)
<slangasek> so it's all done now, thanks
<vila> hmm, yeah, I hate those moments....
<bialix> "vila, mostly because I know you like hard problems" -- this remind me about one TV serial with Gregory as main character. but I know that vila is not Greg. (it was supposed to be a joke)
<vila> bialix: :-) Unfortunately I know no TV serial with Gregory as main character, any url ?
<bialix> vila: hi btw, I'm sure your vacation was great
<bialix> House M.D.
<vila> LOL, Dr House ! Oh yes, thanks for the comparison :-)
<vila> Now I can be grumpy for a good reason :)
<bialix> :-)
<bialix> I was grumpy about your push --strict, and you just in time going away, so you can't hear my scream
<jam> good afternoon vila, good to see you around again
<bialix> jam: hello
<jam> hi bialix
<bialix> jam: we discussed bundling image plugins for Qt into bzr.exe installer. now I have patch
<jam> bialix: yeah, I saw that. I was trying to grab a copy of your branch and test it, though I got side-tracked by about 50 other bug reports :)
<bialix> np, though will be nice to have it merged before 1.18 is out
<vila> I'm almost done with my mail backlog and I saw the threads about push --strict, 1) I'm surprised you don't get the mails related to the merge proposals, 2) I thought (and still think) that adding a config variable is a small price for any power user (and power users should read NEWS :-P)
<vila> jam: good morning !
<bialix> jam: I'm not sure how it collides with recent zc.buildout work you and sidnei done
<jam> bialix: shouldn't conflict much. the zc.buildout stuff is just a wrapper around calling 'setup.py'
<bialix> vila: well, i think such big change deserve big red flashing news! but there was not big
<vila> jam: I hope we can soon plug kerguelen into my buildbot master
<vila> bialix: I really thought power users rarely encounter the context of pushing with uncommitted changes, really
<jam> vila: I think you need to talk to sidnei_ about that
<jam> I thought it was "real close"
<jam> since he has one running himself
<jam> vila: http://buildbot.sidneidasilva.com/waterfall
<bialix> vila: I disagree
<vila> I thought so too two weeks ago :-/
<jam> though that is running a bit slow today
<bialix> vila: anyway, I found good solution for qbzr now
<vila> bialix: I saw that and that's why I didn't answer to the thread
<vila> bialix: and, indeed, since there is an interaction, it's better to ask the user
<bialix> yes
<vila> sidnei_: ping, already there ?
<bialix> jam: is it possible to make mysql's file commit messages a bit more "official"
<bialix> ?
<sidnei_> vila, just woke up *yawn*
<vila> sidnei_: have a coffee and come back later then :-)
<sidnei_> vila, more like lunch actuallly, slept too much, its 11:40 now :)
<bialix> jam: maybe bzr can introduce new (hidden) command-line option for commit to have the way to provide custom revision data to commit?
<vila> sidnei_: do you have an ETA for creating a new buildbot slave that can be plugged in my master and the needed associated master modifications ?
<sidnei_> vila, wouldn't we use kerguelen for that?
<vila> sidnei_: yes, a slave on kerguelen
<vila> sidnei_: that's where your slave for http://buildbot.sidneidasilva.com/waterfall is right now, yes ?
<sidnei_> vila, yes
<vila> instead of switching the exisintg slave to the new master, I thought creating a new one will be eaiser
<jam> bialix: I think something like that would be ok. I think it would be difficult to figure out how to pass things in appropriately.
<jam> I think you want to inject enough data that just passing it on the command line would be insufficient
<bialix> jam: bencode?
<jam> so you probably need a separate file
<jam> with a specific formatting
<jam> bencode would be ok
<jam> though I still think it is *terrible* for human consumption
<bialix> json?
<jam> I think I would prefer a rio formatted file
<jam> we don't use json anywhere else in the code
<jam> so I would avoid that *for now*
<bialix> ok
<bialix> I don't used it either
<jam> I prefer json to bencode, but that isn't what we use *today*...
<bialix> I mention bencode because it good candidate to put things in command-line
<jam> and I don't think we are going to convert everything over to it
<jam> bialix: sort of, but remember again that it would be awful if you wanted to type any of that
<sidnei_> vila, different from real life, buildbot slaves can have many masters *wink*
<bialix> I don't know how they compare re speed
<jam> also, per-file messages are likely to have "\n" in them
<jam> bialix: json has fast C parsers available for python, and they are even bundled in 2.7 or 3.X or something
<bialix> ah, ok
<jam> simplejson is a nice python package
 * bialix sticks with 2.5 for C-extensions and py2exe reasons
<abentley> jam: I don't think json supports recording binary data, which is one thing bencode does.
<vila> sidnei_: huh ? I think the buildbot.tac defines the slave and contains the master adddress, no ?
<jam> abentley: I'm pretty sure you can, though you may have to escape it with base64
<jam> certainly I've done raw dumps w/ py_memory_dump into json
<sidnei_> vila, yes, but you can run multiple instances of buildbot.tac
<abentley> jam: base64 is a way of recording binary data in formats that don't support binary data :-)
<vila> sidnei_: well, that's what I call a slave then :)
<jam> abentley: so I didn't use any specific hacks (that I can remember) in py_memory_dump
<vila> sidnei_: as opposed to the host running the slave I suppose
<jam> abentley: ah, I use the "Unicode escape sequence" to format the output
<jam> if (c <= 0x1f || c > 0x7e) { // use the unicode escape sequence
<jam>     fprintf(out, "\\u00%02x", ((unsigned short)c & 0xFF));
<sidnei_> vila, what you mean by that?
<jam> abentley: so it seems to work for my purposes... :)
<jam> so yes, you need to escape binary data
<jam> one way or another
<jam> on the plus side, json natively supports unicode types, which bencode does not
<vila> sidnei_: by what ?
<sidnei_> vila, "as opposed to the host running the slave I suppose"
<jam> sidnei_: I think the point is that if you have to run *another instance* that is *another slave*
<jam> even if it is on the same machine
 * vila just loves jam :)
<sidnei_> jam, correct. but of course i will be shutting my master down when we switch to vila's so we only need one
<vila> sidnei_: sure, my point was just to allows both slaves to exists during the transition
<Tak> hmm, how does one "install" dulwich from lp?
<jam> Tak: bzr branch lp:dulwich dulwich; cd dulwich; python setup.py install ?
<jam> with maybe a 'sudo' in there as needed
<Tak> cool, thanks
<sidnei_> vila, sure.
 * sidnei_ figures out lunch now
<jam> bialix: what version of PyQt is your patch supposed to work with?
<jam> so far, it doesn't look like it is finding my imageformats
<jam> but I'm still investigating
<bialix> jam: 4.4.3
<bialix> jam: you said you have upgraded to 4.4.3
<jam> is there a difference between that and 4.4.0? (that you know of?)
<jam> On kerguelen I'm pretty sure it is 4.4.3
<jam> I have 4.4.0 locally
<jam> easier to test locally
<jam> I'm not even getting a warning, though
<bialix> in earlier versions of 4.4.x (artleast I saw it with 4.4.1) PyQt4 was installed in different folder
<bialix> jam: can you look into C:\Python25\PyQt4 ?
<bialix> does it have plugins folder?
<jam> bialix: right, so I think that is what I'm seeing. I have both C:\Python25\Lib\site-packages\PyQt4 (which is where 'import PyQt4" comes from
<jam> *and* I have C:\Python25\PyQt4\
<jam> which is where "plugins\imageformats" lives
<bialix> ok, I can check both locations
<bialix> but I can't test it
<jam> I'll look at kerguelen
<bialix> because I have no older pywt
<bialix> *pyqt
<jam> sidnei, vila: Are you connected to kerguelen right now?
<jam> I'm getting "cannot connect" errors
<jam> which is different from "cannot log in because there are too many users"
<jam> I believe I left a connection running because my network died overnight...
<vila> jam: not connected
<sidnei> jam, no, im trying to get lunch :)
<jam> sidnei: go eat then, and stop bothering me :)
<jam> (or stop being bothered by me?)
<vila> sidnei: go go go, and come back before I quit myself :)
<jam> bialix: so one question. Why are you setting "os.environ['PATH']" ?
<jam> so that py2exe can find the dlls during build time?
<bialix> jam: I'm not
<jam>             os.environ["PATH"] = path + os.pathsep + qt_dir
<jam> that is setting the path
<bialix> jam: I think this code has written by Mark Hammond
<bialix> and it supposed to workaround PyQt 4.4.1 issue with different install paths
<bialix> oh
<bialix> I think I remember the same (bad) layout of PyQt even in 4.4.2
<bialix> I've stuck with 4.3.1 because it was much simpler to deal with
<bialix> now 4.4.3 is the best option IMO
<bialix> jam: I'm in process to tweak the search code
<jam> bialix: you can wait, and I'll get it working here first, if you prefer
<jam> since I have an actual test case :)
<bialix> I can wait or write some code
<bialix> it will cost the same amount of time
<jam> just wait, I think I know what to do, and I can quickly know if it actually works
<bialix> actually I'm already write
<bialix> wrote
<bialix> and now I can wait
<bialix> jam: Mark has written that code, revno 3565.5.6, year ago
<bialix> jam: I've made it optional, because newer PyQt (4.4.3) does use different install layout
<jam> bialix: have you tested that it finds imageformats after building and installing?
<jam> (I want to make sure we are installing it where pyqt is going to be looking for it.)
<bialix> jam: yes, I'm working with such configuration right now
<bialix> pyqt looks in the same directory where exe resides either for plugins or qt.conf where path to plugins set
<bialix> I've decided to avoid creating qt.conf
<bialix> although with qt.conf we can put imageformats into lib/
<bialix> but I don't think it makes too big difference, really
<bialix> if we start to bundle more additional pyqt stuff, then it will be better to put it into dedicated folder and create valid qt.conf
<jam> bialix: where does qt.conf need to reside?
<jam> in 'Bazaar/' or in ~user files?
<bialix> in the same folder where bzr.exe is
<bialix> in Bazaar/
<jam> vila: so... from my home machine, I can log into kerguelen's control page, but I can't get to kerguelen itself
<jam> I can ping the ip address
<jam> but DNS isn't resolving the 'hosting24' domain
<jam> ... :(
<bialix> jam: I have tweaked my code to be PyQt 4.4.0 compatible
<jam> bialix: so have I ... :)
<bialix> I can commit and push it if you like
<bialix> well, it should work now with both 4.4.0 and 4.4.3
<vila> jam: err, does that mean that the setup is even worse than before ?
<jam> bialix: so I tweaked the discovery process, etc here: lp:///~jameinel/bzr/bzr.exe-qtimages
<jam> vila: well, I was able to connect to kerguelen *last night*
<jam> so I'm not sure what is going on this morning
 * bialix pulls
<vila> jam: don't look at me, I didn't even try to connect there :-) I just said I wanted a slave there, I'm not sure that counts :-D
<jam> hmm... so it seems nslookup on kerguelen.hosting24.com.au works, it is a problem with nslookup hosting24.com.au that fails
<jam> and I seem to just not be able to connect to that IP address
<jam> I might reboot the machine
<jam> vila: can you try connecting?
<jam> Before I restart, I want to make sure it isn't a problem on my end
<vila> jam: gee, I can try, but I have to find the instructions back first
<bialix> jam: +1 on your tweaks
<jam> vila: rdesktop kerguelen.hosting24.com.au
<jam> I believe
<vila> ERROR: recv: Connection reset by peer
<vila> I can ping it though
<vila> but not the domain
<jam> right, so it sounds the same as here
<jam> I'll just restart it...
<jam> hopefully everything comes back up correctly
<CaMason> with a commit for pending merges, what's the best type of comment?
<jam> CaMason: personally I like summary messages
<jam> of the basic shape of what was merged
<CaMason> sounds like a plan to me
<CaMason> I'll do that
<etank> if the host where my parent branch is stored changes how can i make bzr remember the new location?
<jam> etank: "bzr command --remember" usually
<jam> bzr push --remember
<jam> bzr pull --remember
<jam> etc
<etank> thanks jam
<vxnick> I've used both, but are there any real differences between branches and checkouts?
<vxnick> I'm never quite sure which to use for various things
<darkadept> I'm having trouble setting up a bzr smart server through apache with fastcgi. I'm getting JailBreak errors and I'm not sure how to go about fixing it. (bzr 1.18dev, python 2.6.2)
<jam> bialix: submitted to pqm
<jam> darkadept: bug #348308
<ubottu> Launchpad bug 348308 in bzr "Smart server jail breaks bzr+http with shared repos" [High,Triaged] https://launchpad.net/bugs/348308
<bialix> jam: thx a lot
<jam> vila: I can connect again, now that kerguelen has been restarted.
<darkadept> ubottu: thanks. the last comment on that bug has a little patch... i've tried it i'm not quite sure where to put it
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<vila> jam: seems better here too (I get the login prompt)
<jam> darkadept: the comment says to add it to the "bzr-smart" scritp
<jam> script
<darkadept> jam: hmm i did but it didn't seem to do anything
<darkadept> I just appended it to the bottom of the script
<jam> darkadept: I don't really know. But I would make sure that you restart apache, etc to make sure any cached scripts have been reloaded
<jam> as a monkeypatch it probably just needs to be in the script
<darkadept> jam: hmm ok i'll try
<darkadept> hmm nope. well i guess i should wait until the bug is fixed. would installing a previous version of bzr fix it?
<Noldorin> hello
<Noldorin> i'm having trouble getting bzr to push to a server with no CHMOD command
<Noldorin> firstly, is it possible?
<Noldorin> http://pastebin.ca/1518108
<Noldorin> that's my error log
<SamB> Noldorin: I don't see any fundamental reason why you couldn't ...
<Noldorin> SamB: bzr seems to be locking my repo as i push though
<Noldorin> whenever i push
<Noldorin> as you can see in the error message
<Noldorin> what is bzr doing complaining about a lock it *created* while pushing?
<Noldorin> hmm
<SamB> I don't know -- what I mean is that it should be possible, by changing the code, to make it work
<Noldorin> SamB: ah right fair enough
<SamB> which surely is a better state of affairs than "can
<SamB> 't possibly be made to work"
<SamB> like, say, pushing to your cat or dog would be ;-)
<Noldorin> though not quite as well as i had hoped...
<Noldorin> heh
<Noldorin> SamB: strange thing is that i think i succeeded earlier
<Noldorin> on the same server
<Noldorin> somehow
<SamB> how much earlier ?
<Noldorin> SamB: no longer than a week ago
<Noldorin> 5/6 days maybe
<SamB> same version of bzr, or a different one ?
<Noldorin> same
<abentley> Noldorin: I think bzr thinks it failed to create the lock, assumes that was because another lock was in place, and then tells you about the "other" lock.
<Noldorin> abentley: that sounds like it might well be the cause
<Noldorin> abentley: any workaround you might suggest?
<SamB> I can't find any specs that mention "site chmod"...
<dash> today I have encountered a criss-cross merge
<dash> it's an exciting milestone!
<dash> the default merge gives me 5 conflicts, lca gives me 1 conflict, weave gives me none
<dash> should I feel OK using weave? :)
<LarstiQ> dash: have you inspected the outcome? :)
<dash> LarstiQ: that sounds too hard. :)
<kfogel> Do we know who packages bzr for backports.org (Debian) ?
<kfogel> Ah, looks like jelmer... :-)  Context: I'm trying to get savannah.gnu.org to upgrade to 1.17, so we can switch Emacs over to Bazaar on the new 2a format.  However, savannah (quite sensibly) only wants to run packaged bzr.
<kfogel> They explain this in an old ticket: https://savannah.gnu.org/support/index.php?106612#comment2
<jelmer> kfogel: hi
<kfogel> LarstiQ: ^^  (see backscroll)  You and jelmer help package bzr for backports.org?
<kfogel> hey jelmer
<kfogel> jelmer: I'm wondering if we can get bzr 1.17 backported for Debian.
<LarstiQ> I'm not ware of concerted backporting efforts
<jelmer> kfogel: Yeah, we should be able to get a new version on backports.org
<jelmer> kfogel: (fwiw I've only done the original packaging, not the backports to stable)
<kfogel> LarstiQ, jelmer: ah, I just saw your names listed at http://packages.debian.org/lenny-backports/bzr
<kfogel> jelmer, should I do anything more to make this happen, or are you now tugging on the marionette strings (or whatever the right metaphor is)?
 * LarstiQ can help with packaging on Lenny
<LarstiQ> But I don't know how backport works upload wise
<jelmer> I'm in the keyring so should be able to upload
<kfogel> LarstiQ: Hmmm.  How about I send an email to the group of packagers, including you and jelmer.  I imagine that between everyone, all the necessary skills / accounts / whatever are there.
<kfogel> oh wait, maybe the two of you have everything needed between you? :-)
<LarstiQ> apparently :)
<LarstiQ> kfogel: would it be ok if I do that tomorrow? (wednesday is my day off)
<phinze> bzr one liner challenge!  "total SLOC @ a given revision" ;)
<Tak> depends on the definition of S
<LarstiQ> phinze: bzr export -r rev | sloccount, or something like that
<kfogel> LarstiQ: NO.  YOU MUST DO IT IMMEDIATELY, OR THIS WILL GO ON YOUR PERMANENT RECORD.  YOU HAVE BEEN WARNED.
<kfogel> :-)
<LarstiQ> oh. ok.
 * kfogel is glad we've got that cleared up
<SamB> jelmer: I has a patch for you: lp:~naesten/bzr-svn/hackz
<SamB> (it just adds a docstring)
<jelmer> kfogel, :-)
<jelmer> SamB, thanks
<kfogel> jelmer, LarstiQ: may I add a comment to https://savannah.gnu.org/support/index.php?106951 that you guys are working on this?
<jelmer> kfogel, yeah, np
<kfogel> jelmer: thanks.  I'll wait to hear from LarstiQ too; don't want to put him out publicly for something without explicit confirmation.
<jelmer> SamB, It'd be useful if you could also document the parameters
<SamB> jelmer: hmm.
<jelmer> SamB, that seems like it's actually the bit you can't get from the implementation so you'd be most interested in
<jelmer> SamB, The fact that a method called make_repository() creates a repository seems kindof obvious :_)
<SamB> jelmer: well, yesterday I must have been dense
<LarstiQ> kfogel: I don't specifcally mind, but for me your energy would be more useful to check in on me tomorrow
<SamB> jelmer: yes, but what *kind* is less obvious
 * LarstiQ jots it down on his todo list
<kfogel> LarstiQ: these things are not mutually exclusive.  I will check in with you tomorrow too.  What time zone are you in?
<LarstiQ> jelmer: I see btw you released bzr-svn 0.6.4
<LarstiQ> kfogel: In that case, excellent! CEST / UTC+2
<SamB> jelmer: so ... how does one document parameters that aren't named in the code?
<kfogel> LarstiQ: *nod*  Okay, it will probably be your early or mid afternoon when I get online.
<jelmer> SamB: :param foo:
<LarstiQ> kfogel: cool. I have an appointment from 13.00 till 15.00, but other than that I should be online
<SamB> jelmer: how is that going to mean something when there is no "foo" in the code?
<kfogel> LarstiQ: cool, thx
<SamB> jelmer: any particular reason why you use just "(self, *args, **kwargs)" here?
<jelmer> SamB, yeah, it avoids updating the parameters here if subvertpy changes parameters
<SamB> well, I don't think there are any documentation tools that will work with that ;-)
<LarstiQ> SamB: you sure?
<LarstiQ> SamB: seems to me sphinx could do a reasonable job
<LarstiQ> with some instruction on how to document it
<SamB> LarstiQ: sphinx works on code ?
<LarstiQ> SamB: it was created to document Python
<SamB> LarstiQ: it appears to have been created for the *manual*, not in-band API documentation
<LarstiQ> SamB: with autodoc, it is a consumer of the in-band docstrings
<LarstiQ> SamB: I use it for library documentation at work, as well as a large user guide
<SamB> jelmer: what do you use for bzr-svn API docs?
<jelmer> SamB, pydoctor
<phinze> okay i wonder if there is a way out of this mess i find myself in... i've got parallel subdirs in both trunk and project branches, but i don't think they share a history
<jelmer> SamB, usually though, I just read the source code
<phinze> i try to merge trunk -> project and i get output like this: http://gist.github.com/161511
<SamB> jelmer: any idea why running "pydoctor -c bzr-svn.cfg --make-html" under "~/hacking/bzr-svn/working" gives pydoctor the idea that all the modules to document are within "bzrlib.plugins.svn.working"?
<jelmer> SamB, yeah - it's not a proper python module
<jelmer> SamB: the source files are in . rather than in e.g. subvertpy/
<SamB> jelmer: so why the "working"?
<jelmer> SamB, it takes the name of the directory you specify
<jelmer> SamB, And bzr-svn.cfg specifies .
<jelmer> SamB, if you were documenting subvertpy you would specify the subvertpy directory and it would name it subvertpy
<phinze> ...so while the actual diff from trunk is relatively small (add two files, modify three)... the merge wants me to remove the entire features dir and start over in my project branch
<phinze> i guess my question is: is there any way out of this?
<phinze> or will i have to continue doing a mv/cp dance to get merges with changes in the features subdir properly because i've broken their history
<krisives> Is setting EDITOR=nano good enough to make commit messages edit with nano?
<krisives> or do I have to do something elsE?
<LarstiQ> krisives: unless you also have VISUAL set
<krisives> echo $VISUAL doesn't appear to have anything set
<krisives> echo $EDITOR shows nano
<krisives> Try setting BZR_EDITOR?
<LarstiQ> krisives: shouldn't be needed?
<LarstiQ> krisives: have you actually tried what happens if you have EDITOR set?
<krisives> EDITOR=nano bzr commit works
<krisives> So I must have failed to export or something
<krisives> So even if I can echo $EDITOR and see nano, why couldn't bzr?
<LarstiQ> krisives: the lookup is BZR_EDITOR, editor in config, VISUAL, EDITOR, wordpad.exe, notepad.exe on windows, /usr/bin/editor, vi, pico, nano, joe
<LarstiQ> krisives: echo doesn't imply export afaik
<krisives> I wish I could man export :D
<LarstiQ> krisives: man your shell
<krisives> Kinda gotta find it in the bash man
 * LarstiQ nods
 * krisives giggles at the sound of that
<LarstiQ> ftw
<LarstiQ> ehm
 * krisives gets in the trenches and "mans the shell"
<LarstiQ>  / ftw
<LarstiQ> right
<LarstiQ> :)
<LarstiQ> anyway
<krisives> Thanks for the (deserved) ridicule :D
<LarstiQ> krisives: my .zshrc sets VISUAL and EDITOR to vim as a standard measure
 * LarstiQ blinks
<LarstiQ> did I ridicule?
<Noldorin> hello
<krisives> Not really, just that I should have better manned my shell
<krisives> You are correct
<Noldorin> has anyone has experience getting bzr to work with an ftp server that doesn't support chmod?
<Noldorin> krisives: heya
<krisives> Noldorin: they don't support chmod for real eh?
<krisives> What did they say?!
<Noldorin> krisives: yeah, so it seems :(
<krisives> Drop them, get new host IMO
<krisives> Unacceptable to not allow permissions
<Noldorin> "CHMOD is a feature that applies to Linux hosting packages only."
<Noldorin> from their email
<LarstiQ> ...
<Noldorin> yeah, im tempted to
<Noldorin> just signed up though :S
<LarstiQ> Noldorin: what ftpd is that?
<krisives> Only way you're going to get bzr to work on that is to use bzr export afaik
<Noldorin> does anyone have any ideas how to get around it, for a start?
<Noldorin> LarstiQ: "ftpd"?
<Noldorin> hmm
<krisives> LarstiQ: he's using a host for ASP.NET
<LarstiQ> Noldorin: which ftp server
<krisives> Noldorin: ftpd is what runs the FTP server
<LarstiQ> krisives: right
<Noldorin> ah
<krisives> LarstiQ: I suspect it's because it's a windows host on FAT32 or something else without a permission model :(
<Noldorin> LarstiQ: i just know it's an ftp server running on windows 2003, hosted by storm internet
<LarstiQ> Noldorin: the d is short for 'daemon', unix terminology for detached long running processes
<Noldorin> krisives: i can't set the standard unix permissions in the site manager :S
<LarstiQ> krisives: sure, but the ftpd could just fake the chmod
<krisives> LarstiQ: good point
<Noldorin> LarstiQ: yeah, i'm a windows guy mainly - though i am vaguely familiar with daemons
 * krisives +1 to LarstiQ
<Noldorin> http://pastebin.ca/1518338 - my error log
 * LarstiQ heads home
<Noldorin> bye
<krisives> Bye LarstiQ
<Noldorin> LarstiQ: ping me if you have any ideas please! :)
<krisives> Thanks for your help :)
<LarstiQ> be back in half an hour / an hour :)
<Noldorin> ok
<Noldorin> hrmm
<krisives> Noldorin: you could mount the FTP in Windows as a directory
<Noldorin> short of hacking the source
<Noldorin> i'm wondering what to do
<Noldorin> krisives: interesting suggestion
<krisives> If windows thinks it's a thing without permission support you might be able to get away with that
<Noldorin> krisives: as far as i understand, permissions in bzr repos are non-essential
<krisives> You could also use `bzr export` and manually upload, but that kinda defeats the purpose of bzr
<Noldorin> yeah
<krisives> Well, yeah, someone could patch the source to only use permissions if available
<krisives> IMO that's a lot of work for something very rare
<krisives> Your host should provide CHMOD really
<Noldorin> yeah, it sucks
<krisives> Not preaching, but this is why I use Linux for hosting and in general
<krisives> I can get a linux host for dirt cheap that does everything I need, and they are willing to install a package for me, etc.
<krisives> Windows hosting is slower, more expensive, and less likely to be feature rich without extra cost or much hastle, usually just short of pure dedicated
<Noldorin> yeah
<krisives> The source is Python, so theoritically you could patch the source
<Noldorin> too bad i'm an exclusively .NET guy
<Noldorin> yeah
<krisives> If they are isolating the CHMOD into a class you could add a global switch to not do CHMODing
<jelmer> phinze, if there's no shared history it's correct the files aren't merged
<krisives> Let me pull down the bzr code and check it over
<Noldorin> krisives: ok cheers
<phinze> jelmer: so what would be the best way forward... should i merge the trunk files over to project and then re-add the extra project files?
<emmajane> beuno, ping?
<phinze> i'd have a hiccup in the project's history but that would get the trunk <-> project history synced
<beuno> emmajane, hi!
<emmajane> beuno, I'm back from the holiday weekend. I missed you on Friday.
<emmajane> beuno, let me know if you still want to catch up?
<jelmer> phinze, basically you should resolve the conflict using either the original files or the files that were merged in
<krisives> Off hand anyone know how large the bzr trunk is?
<krisives> At 3Mb already :D
<beuno> emmajane, I do. In  an hbour?
<krisives> (Teach me to fish if you will, where is the size of a trunk listed on LP?)
<Noldorin> krisives: 3MB isn't too bad
<emmajane> beuno, sounds good.
<Noldorin> oh, already
<phinze> jelmer: alright let me fiddle -- i just want to get it to a point where every change in features coming from trunk is not a guaranteed conflict
<Noldorin> you've only download subdirs?
<krisives> We're at 9Mb now
<emmajane> beuno, I have a drupal documentation meeting in two hours. so we'll be able to stay focused when we catch up. ;)
<jelmer> phinze, in that case, you should resolve using the original files
<jelmer> phanatic, those files were moved away I think so you'd have to move them back
<phinze> jelmer: sounds like a plan; i'll see what i can do
<beuno> emmajane, does that mean yes or no?
<emmajane> beuno, do you think we can catch up in an hour? I think we can. :)
<emmajane> beuno, we'll have to stay focused though. ;)
<Noldorin> krisives: i've emailed back my web host to see what they say..
<Noldorin> krisives: in particular regarding my success with a previous repo there
<Noldorin> not sure how i managed to do it!
<krisives> Is there some reason you have to use that host? If they aren't willing to compromise find a different host that will and give them your business
<Noldorin> krisives: yeah i know. it's only that they're cheap, and provided (almost) all of the features i need
<Noldorin> if anyone can point me to a great UK host for ASP.NET web spaces, with unlimited bandwidth, and databases, i would be happy to change :)
<Noldorin> erm, for a decent price of course
<beuno> emmajane, I can do earlier
<beuno> in 30
<beuno> or 20 even!
<emmajane> woo!
<krisives> Anyone in here familiar with the bzr source?
<jelmer> krisives, somewhat
<beuno> emmajane, skype good for you?
<krisives> jelmer: think sftp.py is the right place to add a switch for --no-chmod ?
<emmajane> beuno, yup. I'll log in.
<jelmer> krisives, I think I missed context - what are you trying to do exactly?
<krisives> Noldorin has a Windows server that doesn't support CHMOD
<krisives> Would be nice to have a --no-chmod flag
<Noldorin> yeah
<krisives> Says in the source it should actually only be doing it if FTP supports the CHMOD, have you tried using FTP instead of SFTP?
<jelmer> krisives, and your windows server is running a ssh+sftp server?
<krisives> jelmer: not my server, it's his
<krisives> jelmer: just interested in helping with a patch
<Noldorin> jelmer: just plain ftp
<krisives> Noldorin: have you tried using FTP and not SFTP ?
<jelmer> krisives: if it's plain ftp then sftp.py is unrelated
<Noldorin> ^^
<krisives> Okay, we'll I am also looking at ftp/__init__.py
<jelmer> krisives, adding a flag wouldn't work though, you might be able to do a hack to look at an environment variable though
<krisives> #453 in bzr/bzrlib/transport/ftp/__init__.py says:
<krisives> "Only set permissions if the FTP server supports the 'SITE CHMOD' extension"
<krisives> Also appears to catch the exception and doesn't end execution, but just warns
<Noldorin> krisives: that's quite interesting
<krisives> http://pastebin.com/m2ce7fef0
<Noldorin> hmm
<krisives> You could try nerfing _setmode by just doing return in it
<krisives> And see if it works then
<krisives> It's sloppy but would at least help you figure out what's happening
<Noldorin> krisives: yeah... i ought to try that
<Noldorin> krisives: would i want to submit this as a bug report or feature request though?
<Noldorin> for the next version
<mobodo> how's the "text" vs "binary" handling done in bzr?
<LarstiQ> Noldorin: yes, I think that's fair
<Noldorin> LarstiQ: which one though? :)
<LarstiQ> mobodo: atm, heuristic check for nul byte in the first 1024kb iirc
<mobodo> alright, thanks
<Noldorin> krisives: will probably get around to it at some point tomorrow. not too familiar with python, but i'll give it a go
<Noldorin> thanks for the help
<LarstiQ> Noldorin: we treat them the same, http://bugs.launchpad.net/bzr :)
<Noldorin> LarstiQ: ah of course. launchpad bugs for the win.
<krisives> Noldorin: I think it's most likely their FTP server closing the connection after too many CHMODs
<LarstiQ> krisives: did we figure out the ftpd yet?
<Noldorin> LarstiQ: that was a quick journey home btw ;)
<krisives> That's Noldorin's thing
<krisives> Noldorin: Do you have bzrlib/plugins/transport/ftp ?
<LarstiQ> Noldorin: bout half an hour?
<Noldorin> krisives: i'm sure it's installed by default by the windows installer.
<krisives> I don't use bzr on windows so I have no idea where it goes or whatever
<Noldorin> krisives: i wouldn't even have FTP working at all anyway
<Noldorin> yeah fair enough
<Noldorin> though as i said, i *somehow* managed to get a bzr repo working before with that web host
<Noldorin> though i probably clobbered it
<krisives> Do you have SFTP access?
<Noldorin> krisives: afraid not
<LarstiQ> Noldorin: krisives' suggestion of mounting it and then using bzr 'locally' might work btw
<Noldorin> krisives: if you're willing, i can give you FTP access to my server if you want to mess around.
<Noldorin> krisives: of course, you've been a good help already. wouldn't expect/request it
<krisives> Go ahead and PM me access and I'll try my hack
<Noldorin> LarstiQ: yeah probably, though i'm not fond of the indirectness
<krisives> (Just adding a return to _setmode() )
<Noldorin> LarstiQ: i think you were quicker than 1/2 hour btw
<krisives> It was about an hour actually on my logs
<krisives> (01:43:19 PM) ***LarstiQ heads home
<Noldorin> i got DCed, and i don't log, so i can't check :P
<krisives> I guess it was about 45 mins
<Noldorin> :O
<Noldorin> seems i have a poor sense of time
<LarstiQ> Noldorin: it's not a permanent fix but might help you get going
<mobodo> yay :) I think I have my cgi pretty much working... I can now browse my bzr on the web
<Noldorin> LarstiQ: this is true..
<krisives> If I `make` bzr I can test it locally inside that dir?
<Noldorin> krisives: sure
<LarstiQ> mobodo: how did you set that up?
<krisives> I am building bzr from source
<Noldorin> krisives: i don't see why not
<krisives> That's the question I'm asking
<LarstiQ> krisives: yes
<krisives> LarstiQ: thx
<Noldorin> :P
<Noldorin> lol
<krisives> Do I need to `make` again if I modify a .py ?
<LarstiQ> krisives: nope
<krisives> Yippie :D
<mobodo> LarstiQ: my branch is hosted in my web server, got a php file calling bzr on the branch to list its content
<LarstiQ> krisives: only if you touch the C extensions
<krisives> Noldorin: if you have the info I can test it
<LarstiQ> mobodo: ah :)
<Noldorin> krisives: just setting up atm
<LarstiQ> mobodo: any reason you didn't want to use loggerhead?
<mobodo> LarstiQ: I can't run a server, this is on a web host
<mobodo> LarstiQ: I'm not allowed to run a daemon, let alone open ports
<LarstiQ> mobodo: ah
<LarstiQ> wonder if loggerhead could work in a cgi mode
<krisives> Anyone know if the py scripts are compiled on Windows ?
<mobodo> LarstiQ: that would probably save me a lot of time :-/
<LarstiQ> beuno: ^^?
<LarstiQ> krisives: yes/no
<LarstiQ> krisives: if you use the all-in-one installer they are py2exed
<LarstiQ> krisives: if you use the python based installer, it's just business as usual
<krisives> LarstiQ: thx
<mobodo> I mean, say you are hosting your stuff on a university server, you're not going to install loggerhead on the server
<LarstiQ> mobodo: would you be able to install viewvc though?
 * LarstiQ isn't sure what the target platform is
<luks> I've written myself http://bzr.oxygene.sk/bzrbrowse/trunk for this exact reason
<mobodo> LarstiQ: why do you ask? does it support bzr?
<mobodo> luks: well, I've just been doing pretty much the same thing :)
<mobodo> LarstiQ: thing is, with svn, you get web browsing for free
<LarstiQ> mobodo: iff you have apache with dav_svn
<mobodo> but you can't host a svn on a unversity server because they won't let you configure a repository and a web access
<mobodo> right
<mobodo> the whole point of bzr, to me, was sftp/http access without having a bzr server on the other end
<LarstiQ> right
<mobodo> If I can install loggerhead, I can install webdav
<LarstiQ> so what _can_ you do then?
<mobodo> like luks did and like I'm doing.  Use bzr locally to query a .bzr and allow you to browse
<mobodo> http://bazaar.enseed.com/browse/ <- is the output of a php file
<LarstiQ> so you have python
<mobodo> I have php
<mobodo> oh, yes, I have python
<mobodo> most people do
<LarstiQ> if you have bzr you have python :)
<mobodo> most universities do
<mobodo> and I have a local install of bzr
<LarstiQ> mobodo: well, that is the biggest hurdle taken
<LarstiQ> mobodo: do you have mod_wsgi?
<mobodo> let me check
<beuno> emmajane, http://bazaar-vcs.org/WhoUsesBzr
<mobodo> I don't think so
<LarstiQ> mobodo: mod_python? Or just plain cgi?
<LarstiQ> not sure if there are wsgi servers that run from standard cgi
<mobodo> I'm not sure - how could I find out? I listed the modules in /etc/httpd/modules, but that doesn't seem to list them all...
<mobodo> it's probably not listing the built-in modules
<luks> LarstiQ: from wsgiref.handlers import CGIHandler
<luks> but loggerhead is going to be slooow over cgi
<LarstiQ> luks: k
<beuno> emmajane, is the bzr wiki working for you?  it isn't for me
<LarstiQ> luks: ah well
<emmajane> beuno, define working...?
<emmajane> I can see pages in the wiki....
<emmajane> beuno, and I can pull up an edit page.
<beuno> ok, I don't see them at all  :)
 * emmajane pulls up http://bazaar-vcs.org/BazaarUploadForWebDev her favourite page. ;)
<beuno> :)
<beuno> ok, it works now
<beuno> it just needed for me to make a fool out of myself
<emmajane> You just had to choose the right first page ;)
<LarstiQ> kfogel: from http://packages.debian.org/lenny-backports/bzr I `dget http://backports.org/debian/pool/main/b/bzr/bzr_1.16.1-1~bpo50+1.dsc`
<LarstiQ> kfogel: a debdiff then with 1.16 from testing shows Norbert Tretkowski did the backport
<LarstiQ> kfogel: I'll poke him tomorrow
<LarstiQ> (backport consists of adding a changelog entry and uploading. I can do that! :)
<LarstiQ> yay for debdiff
<SamB> jelmer: Okay, another patch for you in lp:~naesten/bzr-svn/hackz
<jelmer> SamB, thanks
<jelmer> SamB, please follow the bzr coding conventions (e.g. indent 4 spaces where it makes sense to do so rather than at the same offset of the opening parentheses at the previous line)
<SamB> jelmer: oh, sorry
<jelmer> SamB, There shouldn't be a reason to explicitly have those arguments when using *args, **kwargs
<SamB> jelmer: well, you try rewriting the documentation for that case, then!
<SamB> This code shouldn't break any more than the callers would if you change something ...
<SamB> jelmer: and, er, should I put self on the first indented line, then?
<jelmer> SamB, I've fixed it and pushed
<SamB> ah, nice
<SamB> you took out the *args and **kwargs
<LarstiQ> jelmer: should I do a bzr-svn 0.6.4 announcement tomorrow?
<SamB> jelmer: isn't there something in the bzr coding convention about using 80-character lines ?
<jelmer> SamB, yes, where do my changes exceed 80 characters?
<jelmer> LarstiQ, please do
<SamB> jelmer: not your changes, just the existing code ;-)
<LarstiQ> jelmer: k, I will
<jelmer> LarstiQ, the main reason for this interim release was that there were some problems with the probing code where bzr-svn would interfere sometimes
<jelmer> LarstiQ, even if there wasn't any svn repo involved
<LarstiQ> jelmer: ah, I see
<LarstiQ> jelmer: I'll read the bugs involved and try to write up a summary
<SamB> jelmer: oh, I recently noticed that if you accidentally try to pull from the launchpad webpage for a branch instead of the branch, bzr-svn seems to choke on the resulting 405 ...
<jelmer> SamB, which version of bzr-svn?
 * LarstiQ heads to bed
<SamB> well, the one I just pulled from you, for instance
<SamB> I'm not sure if it actually is choking
<jelmer> SamB, please file a bug
<SamB> okay
<poolie> hi all
<lifeless> mdke: still here?
<SamB> jelmer: https://bugs.launchpad.net/bzr-svn/+bug/409074
<ubottu> Launchpad bug 409074 in bzr-svn "bzr-svn appears to choke bzr early when accidentally given a launchpad branch page URL" [Undecided,New]
<jelmer> SamB, thanks
<SamB> jelmer: nothings special about that branch, I just picked one from an open tab ...
<kklimonda> hey, I was wondering if bzr-svn svn-import and branch commands are supposed to be so slow? I can actually see every commit copied..
#bzr 2009-08-05
<jelmer> kklimonda, yes, that's correct
<jelmer> kklimonda, svn-import imports all of history, it's different from e.g. "svn checkout" which downloads just the last revision
<lifeless> jelmer: hai
<jelmer> lifeless, hellÃ¸
<lifeless> https://code.edge.launchpad.net/~lifeless/subunit/nopassthrough/+merge/9557
<jelmer> lifeless, any reason for the two spaces of indentation on line 50 and 51 in the diff?
<lifeless> editor fail
<lifeless> will fix
<jelmer> lifeless, why does launchpad add "(community)" behind jml's name and mine in the reviewer field?
<lifeless> I don't know
<lifeless> there is a bug open about it, that I filed.
<lifeless> https://bugs.edge.launchpad.net/launchpad-code/+bug/400950
<ubottu> Launchpad bug 400950 in launchpad-code "not clear how to tell code reviews that (community) is wrong for a branch" [Low,Triaged]
<lifeless> lol. re fail :(
<lifeless>   File "/usr/lib/python2.6/sre_compile.py", line 517, in compile
<lifeless>     "sorry, but this version only supports 100 named groups"
<lifeless> AssertionError: sorry, but this version only supports 100 named groups
<thumper> lifeless: what are you trying to do?
<lifeless> thumper: just test combination
<lifeless> I suspect a shallow bug in command line aggregation
<lifeless> I'll look at it later
<thumper> jelmer: it seems there is a small bug somewhere in the community identificaiton code ...
<thumper> jelmer: we are looking into it
<thumper> lifeless: do you know much about StringIO and unicode?
<lifeless> sadly yes
<thumper> should it be avoided?
<jelmer> thumper, what is community supposed to be though? Would it be used to identify people who don't have voting rights?
<lifeless> thumper: its ok some of the time, but it doesn't have clearly (or consistently!) defined semantics.
<thumper> jelmer: it is more to indicate that while they may provide a review, it doesn't yet hold the weight of a real reviewer
<thumper> lifeless: it should be well defined
<lifeless> thumper: if you want a bytestream, which is what python 2.x files are meant to be, its a bad bad bad idea to write unicode to the input side
<thumper> I know what it should be
<lifeless> thumper: its not; StringIO and cStringIO, which are meant to be identical, behave differently.
<thumper> ew
<lifeless> thumper: I'm sure it seems well defined though :)
<spiv> thumper: (c)StringIO is meant to emulate a file, which is meant to contain bytes.  So, feed it bytes (str) not unicode, or else unexpected crap happens.
<thumper> spiv: ok, ta
<lifeless> thumper: in py3 there are defined semantics for layering strings down to bytes and back
<thumper> spiv: I'll reject my reviewers suggestion then :)
<spiv> Use CodecReader/Writer (or whatever they are called) wrapped around a StringIO, if you like.
<lifeless> thumper: what did they suggest?
<thumper> I'm using text.splitlines()[:max_lines] -> testlines = islice(StringIO(text), max_lines)
<poolie> hello thumper, lifeless
<lifeless> hi poolie
<thumper> hi poolie
<poolie> thumper: any chance launchpad could stop flattening whitespace in code review comments? :)
<thumper> what?
<thumper> poolie: ref plz
<lifeless> thumper: uhm, islice(text.splitlines(), maxlines)
<lifeless> thumper: is ~=
<lifeless> also
<thumper> poolie: someone must have changed it
<spiv> thumper: yeah, that seems pretty dubious to me.  splitlines really could use a maxsplit argument, like split.
<lifeless> thumper: also
<spiv> lifeless: I assume the point is to avoid a second copy of the (large?) string in memory
<lifeless> islice(bzrlib.osutils.chunks_to_lines([text]), maxlines)
<poolie> thumper:look at eg john's comments in https://code.edge.launchpad.net/~mkbosmans/bzr/topo_sort/+merge/9532
<spiv> thumper: or just use split('\n', max_lines)
<poolie> it's like it was specifically designed by someone who hates python
<lifeless> ^ that is about the most efficient, if you need to deal with large strings/are doing this a lot
<thumper> spiv: that doesn't discard the rest though does it?
<poolie> the problem occurs when you copy and paste from the review diff
 * lifeless repeats
<spiv> thumper: yeah, I guess not.
<lifeless> islice(bzrlib.osutils.chunks_to_lines([text]), maxlines) <- use that
<thumper> poolie: they don't look flattened to me...
<lifeless> thumper: its python, your text isn't getting freed anyway
<lifeless> oh, the other thing you could do is use a buffer object
<lifeless> but really, at that point, I'd rather write C
<thumper> lifeless: what do you mean the text isn't getting freed?
<spiv> lifeless: right, scan ahead for the nth \n, make a buffer object, splitlines that.
<lifeless> text.splitlines() is your big slab of text, its going to be kept in memory until you're done with the last handle to it
<lifeless> spiv: not quite, N buffer objects
<lifeless> splitlines will allocate
<lifeless> depends on parameters thumper hasn't shared about object lifetime
<spiv> lifeless: depends on you are worried about, I guess
<lifeless> ^ great minds
<spiv> lifeless: I'm thinking of say 100M of text after max_lines that you don't care about (and certainly don't want a 2nd in-memory copy of)
<thumper> I don't care that much I guess
<thumper> at most will have 512k
<spiv> thumper: I see poolie's problem; it's in the code lines John's quoted from the review diff, not the new code he's suggested in the comment.
<lifeless> spiv: I was thinking of 20K lines and a little noise after :)
<spiv> thumper: e.g. the first four lines of that comment
<spiv> lifeless: :)
<lifeless> thumper: can you give us a quick english description of the problem
<thumper> gotcha
<thumper> it is actually the tal formatter that formats the diff
<thumper> I get a (maybe unicode) string
<spiv> lifeless: Well, I'm guessing from the "max_lines" value that limiting the amount of data handled is the concern.  It would be good not to guess :)
<thumper> to break up and make pretty
<thumper> yes, I want at most a configurable number of lines
<lifeless> ok
<lifeless> so, here's what I'd do
<lifeless> I'd first pass the string through some coerce_to_unicode thing
<lifeless> noting that diffs from bzr can be in any encoding
<thumper> lifeless: like unicode(text)
<lifeless> and that different files can be different
<lifeless> thumper: like that, but that will fail.
<lifeless> thumper: there are heuristics things around in lp for this already.
<lifeless> in exceptional cases, parts of the diff are in two different encodings
<thumper> lifeless: we have code that attempts to decode the actual diff elsewhere
<lifeless> consider when someone reencodes a NEWS file from cp-1280 to utf8
<lifeless> (this is real, people do it it Debian.Changelog)
<thumper> yes we know there are edge cases
<lifeless> ok
<spiv> thumper: that's just an implicit spelling of text.decode('ascii') (unless you've done evil things to your python runtime, like "import gtk"...)
<lifeless> well, I'd get it to a known state, either all bytes, or all unicode
<lifeless> then then loop on re.finditer(r'\r|\n', re.MULTILINE) to get the position
<lifeless> finally, bzrlib.osutils.chunks_to_lines([buffer(text, 0, pos)])
<lifeless> we may need to bugfix that to deal with buffer objects, but its the right conceptual function for stashing that in.
<thumper> interesting
<thumper> overkill for me now, but interesting
<lifeless> I thinl its overkill too
<lifeless> I think diffs will either be fine to deal with naively
<lifeless> or so big that the first text is already killing you
<lifeless> so actually limiting needs to be pushed down the stack.
<lifeless> alternatively, loop on
<lifeless> re.finditer(r'.*\r|\n', re.MULTILINE)
<lifeless> for match in islice(re.finditer(r'.*(\r|\n)', re.MULTILINE), max_lines):
<spiv> poolie: btw, that case I was worried about turns out to be a non-issue; it's already handled correctly.
<lifeless> thumper: actually, the re one is worth testing, it may well be the bomb
<thumper> :)
<poolie> spiv: way to go
<spiv> ...and it's beating IDS for wall clock time on fetch from 1.9 -> 2a over HPSS.
<igc> morning
<spiv> For bzr.dev -r2000, anyway.  It'll be interesting to see how mysql goes.
<jelmer> hi Ian
<jelmer> moin Andrew
<spiv> jelmer: hola
<lifeless> spiv: \o/
<lifeless> igc: did you get a chance to take commit for a spin?
<igc> lifeless: not yet - will do so today
<lifeless> ok
<krisives> Hey, anyone here familiar with the FTP transport code in bzr?
<lifeless> somewhat
<lifeless> its mainly a thin veneer around ftplib
<lifeless> if I am remembering correctly
<krisives> Someone was having problems with CHMOD not being allowed on their Windows-based FTP server for their host, but from what I read in the code it just warns if CHMOD fails
<lifeless> perhaps the server is giving a fatal failure?
<krisives> Not sure, but I am correct that it should just generate warnings and still push (for example) ?
<krisives> It also seems to have problems pushing because it keeps the branch lock open :(
<lifeless> we catch ftplib.error_perm
<lifeless> its probably returning a different error code
<lifeless> the intent is to warn and continue
<krisives> Well, the error string for that catch is what's being output
<lifeless> oh, if its outputting the string then its being caught ok
<krisives> I suspect that the FTP is killing the connection at sometime, which would leave the branch locked
<lifeless> that sounds plausible too
<krisives> If that happens, what does bzr do?
<krisives> Does it try every X seconds?
<lifeless> if the branch is locked when we try to lock it, yes we spin for a while
<lifeless> if the connection is broken leaving a stale lock, the 'bzr break-lock' command can be used to manually break the lock
<krisives> Indeed, but his FTP is just too borked I think
<krisives> To sync just 1 file it drops the connections so much that you can't realistically break the lock and push, you'd be doing it every few seconds
<lifeless> ouch
<lifeless> I need to go eat; perhaps you or he could file a bug?
<lifeless> we can see if we can improve things - though it may not be feasible
<krisives> I believe he is, but honestly I think it's just the FTP being fudge
<krisives> Unacceptable for an FTP to not have CHMOD IMO
<lifeless> I don't know that its chmod causing the problem
<krisives> Thanks for your help :)
<lifeless> it may be incidental
<krisives> I agree
<lifeless> ciao
<krisives> Either way his FTP is the real issue here
<lifeless> vila: I'm going to look at the test suite this afternoon
<lifeless> I've got my check branch passing again
<lifeless> poolie: do you want to do an incremental review? The changes were all shallow - tests calling branch.check() rather than check_dwim on the branch path (which is the public API according to our docs)
<spiv> lifeless: speaking of reviews, inventory-delta is up for review again.
<spiv> lifeless: it uses a separate substream now and is generally looking fairly shiny I think.
<lifeless> awesomeness
<lifeless> what did you do about the parents issue
<spiv> It transmits them on the FulltextContentFactory.
<lifeless> cool
<spiv> Actually, this is effectively unchanged from the previous interation, I'm pretty sure despite John's comments it was sending them before, too.
<lifeless> :P
<spiv> Anyway, if it's wrong, then a test should fail  :P
<spiv> But I'm pretty sure this is doing the conservative thing.
<spiv> Next up is more interactive testing and maybe see if I can do a cheap hack to do something about the "inserting a stream into 2a causes massive bloat until the final autopack" issue.
 * igc lunch
<spiv> But first, lunch.
<spiv> igc is a trendsetter :)
 * spiv -> lunch.
<poolie> lifeless: hi i'm back
<poolie> lifeless: want to read spiv's thing?
<poolie> igc, we should chat about the web site sometime, if you're up
<igc> poolie: sure. I'm back from lunch now. I'm feeling rather washed out today but discussing websites is well within my mental ability nevertheless :-)
<poolie> igc :) how about now?
<igc> poolie: np
<thumper> poolie: wouldn't mind a chat some time
<poolie> hi thumper
<poolie> omg death by telephone
<lifeless> mtaylor: ask thumper; here.
<poolie> lifeless: i forget, did you want me to reread your check-1 branch?
<mtaylor> thumper: is it possible to use boost::format without using the % operator?
<lifeless> poolie: its up to you
<lifeless> 12:36 < lifeless> I've got my check branch passing again
<lifeless> 12:37 < lifeless> poolie: do you want to do an incremental review? The changes were all shallow - tests calling branch.check() rather than check_dwim on the branch path (which is the public API according to our
<lifeless>                   docs)
<poolie> that's https://code.edge.launchpad.net/~lifeless/bzr/check-1/+merge/7489 ?
<poolie> if you want to use the Trivial Button, use it.
<lifeless> I'll send it to pqm now then
<poolie> lifeless, i'm working up towards doing that subunit-filter feature myself...
<lifeless> cool
<lifeless> I've been thinking about the problem of multiple outcomes for tests
<lifeless> I think its a 2d squashed into 1d problem
<lifeless> erm, not multiple events per fixture, but addSuccess vs AddFailure vs addSkip etc
<lifeless> I might mail TIP about it actually
<poolie> meaning it should be more like addResult('success')?
<lifeless> I think there are multiple dimensions:
<lifeless>  - ran | did not run (reason)
<lifeless>  - failed (details)
<lifeless> I'm exploring the concept at the moment
<lifeless> its not mature
<lifeless> not all coordinates make sense
<lifeless> didn't run, failed   is an interesting one to consider - MissingDependency might be that case
<lifeless> basically I think the that list can't ever be complete the way its tackle at the moment
<lifeless> and that provokes ugliness/continual growth in the API
<vila> hi all !
<lifeless> hi vila
<poolie> agree
<lifeless> vila: I haven't fixed it yet
<poolie> it may be more cleaner to add some kind of object to which you can then add attributes and dimensions
<poolie> hi vila
<vila> lifeless: just reading your last comment, you're on on the right design track though :-)
<lifeless> thanks
<lifeless> vila: so, for --parallel
<lifeless> I think special casing the counting decorator to be applied before the parallel one, would be reasonable.
<lifeless> or something
<lifeless> long term I want to fix the driving problem about status info
<lifeless> push that down to subunit and up to python upstream
<lifeless> first though, its EOD for me, and I'm off to think/tweak nested progress in  subunit
<vila> lifeless: ok, short term I just disabled --parallel=fork in the test farm, but 1) it's a shame, 2) I still need it :)
<poolie> lifeless: how am i meant to invoke the subunit test suite?
<lifeless> poolie: make check / make distcheck
<bialix> vila: hi
<vila> bialix: hi, wow, already up ? :)
<bialix> yep, I'm in +2 TZ
<bialix> vila: bzr pull http://bzr.dev hang
<bialix> http://pastebin.com/m757ed464
<vila> bialix: hehe, I know, but you generally come later
<bialix> is it bug or this is my network ?
<bialix> vila: :-P
<vila> bialix: from what I can see, it should be your network, try with -Dhttp maybe ?
<bialix> I've surprised by  25 bytes left message
<bialix> our ADSL is so flaky :-/
<emmajane> poolie, beuno, igc: incoming email, although I'm outgoing for sleep. :)
<vila> well, it smells a bit but not enough to trigger a deep debug session so far, I've seen it in other reports though so I'm aware that something strange is going on here
<igc> hi emmajane
<vila> emmajane: hi !
<vila> emmajane: good to see you around :)
<igc> emmajane: sorry I've missed you on irc recently - haven't been around much these last 10 days
<bialix> what it means: lock cannot be broken? http://pastebin.com/m3a7d4d30
<emmajane> igc, not to mention yo'ure in the wrong time zone for me. :)
<emmajane> (it's nearly 3AM here)
<igc> emmajane: may be we can catch up some time later this week
<emmajane> igc, that'd be good!
<poolie> bialix: probably something holding the os lock (must die)
<poolie> there should be a traceback in bzr.log
<vila> bialix: isn't it OS lock realted (which must die ?)
<vila> rats
<poolie> jinx :)
<emmajane> vila, ps HAI :)
<bialix> rats
<emmajane> ok. sleep time now.
<vila> HAI ?
<poolie> lifeless: (lazy) how is subunit meant to treat xfail in its tests?
<poolie> sleep well
<emmajane> vila, "hi" in lolspeak.
<emmajane> poolie, thanks. :)
<vila> emmajane: :)
<poolie> lifeless: nm
<lifeless> poolie: it doesn't have any xfail tests at the moment :)
 * emmajane clearly needs sleep :)
<igc> night
<lifeless> poolie: it has tests /of/ xfail
<poolie> it folds it to success, it seems?
<igc> emmajane: yep, certainly wrong timezone but I'm often around in my early morning as well so I'm sure we'll catch up soon enough :-)
<lifeless> poolie: ah yes.
<lifeless> poolie: 2.7 has an addExpectedFailure now, I haven't adjusted subunit to use that yet, is all.
<bialix> vila: -Dhttp does not reveal anything and pull has finished successfully
<bialix> but OSLMD definitely
<vila> OSLMD ?
<igc> hi bialix!
<bialix> invented today: OS Locks Must Die!
<bialix> hi igc
 * vila wonders where he lost his acronym deciphering capabilities...
<vila> OSLMD !!! Of course !
<bialix> LOL
<bialix> igc: today will do review of pending merges in qbzr, after noon in my TZ
<poolie> lifeless: this seems to mean it loses the KnownFailure exception details :/
<igc> bialix: excellent. thanks
<lifeless> poolie: thats a shallow bug now that python has a defined contract
<bialix> but today morning I'm thinking about your mail. Why quncommit is so important for you?
<bialix> igc: ^
<lifeless> poolie: I'm filing a bug on the xfail squash
<poolie> i did already
<poolie> bug 409193
<ubottu> Launchpad bug 409193 in subunit "folding KnownFailure to success loses data" [Undecided,New] https://launchpad.net/bugs/409193
<lifeless> oh, thanks
<poolie> also bug 409191
<ubottu> Launchpad bug 409191 in subunit "want a subunit-sort utility" [Undecided,New] https://launchpad.net/bugs/409191
<poolie> not very related
<poolie> but would be cool with many failures
<lifeless> lp indeed
<lifeless> bah typo
<lifeless> indeed
<lifeless> back shortly
<igc> bialix: it's not to me personally. But it is w.r.t. menu options I'd want to explain in a manual for explorer say
<igc> bialix: scanning over the user guide and 'translating' the tasks to gui actions (instead of bzr commands), we need ...
<bialix> I mean: I don't think this is main operation
<bialix> ah
<igc> bialix: (1) easy importing & (2) being able to undo mistakes
<bialix> easy importing?
<poolie> emmajane: really nice mail :)
<igc> bialix: I personally care more about shelve for example, than uncommit, but most new users will screw up a commit message more often than want to shelve ;-)
<bialix> shelve (shelve2) does not work for me, so
<igc> bialix: "I have a tree of files - put it under version control for me"
<bialix> ok, I've grok your pounti
<bialix> ok, I've grok your point
<bialix> qimport?
<bialix> is not import command still the part of bzrtools>?
<poolie> baz-import is, i think
<poolie> plain import i think has always been built in?
<lifeless> import is in core I'm fairly sure
<poolie> lifeless: there are no blackbox tests iiuc?
<bialix> bzr help import said: From:     plugin "bzrtools"
<bialix> :-P
<lifeless> none!
<poolie> woo, freedom!
<poolie> well that obviously works
<poolie> why do people bother writing tests?
<lifeless> poolie: so, I'll probably add something approximating blackbox tests at some point in the future
<lifeless> poolie: for now, I do TDD for all the core code
<poolie> sure
<lifeless> and treat UI validation as a shallow release task
<poolie> i'm not complaining, i'm just checking i don't miss it
<lifeless> :)
<poolie> i mean i'm changing it and i don't want to submit without tests
<lifeless> thats fine
<poolie> done- https://code.edge.launchpad.net/~mbp/subunit/408821-filter-re/+merge/9680
<poolie> spiv, how's the inventory delta patch? did it turn out it's ok to go?
<poolie> ooh this is very nice
<lifeless> err might not be a string
<lifeless> it seems like a bug there
<lifeless> but otherwise nice
<poolie> i was only assuming it could be cast to a string
<poolie> or i only meant to
<mdke> lifeless: I am now
<mdke> lifeless: just trying this fast-export thing at the moment
<mdke> ok, I've run the export and piped it to a file
<mdke> let's see now
<mdke> an error - http://paste.ubuntu.com/247816/
<mdke> lifeless: if you have any ideas, give me a shout - I'm off to work now but will pick up hilights. Thanks in advance!
<lifeless> a bug in fast-export, or a broken stream
<lifeless> file a bug
 * igc dinner
<poolie> vila, lifeless, i think i'll call it a night
<poolie> bye
<lifeless> ciao
<lifeless> I'm reviewing atm
<vila> poolie: bye
<poolie> i wonder how spiv's patch went?
<lifeless> poolie: reviewed
<poolie> the subunit thing?
<lifeless> I think its nice, but improvable
<lifeless> yes
<lifeless> oh, missed a bit
<lifeless> I don't think the predicate should be public on the filter
<lifeless> it would be odd for someone else to be calling it
<poolie> i thought they might want to chain on it
<lifeless> you mean replace it after construction?
<poolie> yes
<lifeless> mmmm, I think I'd rather have a list of predicates for that, in the object.
<lifeless> its also a bit yagni, as I strongly suspect these filters are build-and-execute, not build-edit-execute
<poolie> did you comment on the mp?
<lifeless> yes
<poolie> i'll make it private
<lifeless> bunch of mostly shallow stuff
<lifeless> it looks really nice as a feature
<poolie> oh, now you did
<poolie> how can it hit on None?
<lifeless> perhaps not from the command line
<lifeless> but addSkip(test, None) is something people might call
<lifeless> its possible I'm overthinking it
<lifeless> k, well I'm going to head for a bit
<lifeless> I'll tackle progress later
 * bialix works on qbzr
<spiv> poolie: I resubmitted the inventory-delta patch for review; didn't Launchpad send you mail about it?
<poolie> oh hi spiv
<poolie> i saw there was a new review from about 5h ago
<poolie> i didn't review it myself though :/
<poolie> maybe john will
<Tak> am I doing something wrong, or is push being strict by default supposed to be super-annoying? :-P
<bialix> hehe
<bialix> you can set push_strict = False in bazaar.conf to disable this
<Tak> ah, nice
<bialix> nice?
<Tak> it's nice that I can disable that in the preferences
<vila> Tak: when do you encounter it ?
<bialix> with qpush you've got yes/no dialog
<bialix> vila: sometimes it's perfectly legal situation to push finished job and get unfinished changes in the tree :-P
<Tak> vila: when I have uncommitted local changes
<vila> bialix: I know it's perfectly legal, I'd like to better understand why and when people encounter it
<Tak> ah
<Noldorin> krisives: ping?
<vila> Tak: but why did you want to push anyway ?
<krisives> Knee deep in CSS :(
<Tak> when working with an ide like monodevelop, it makes a lot of trivial changes to project files (reordering elements, etc) that I don't want to commit
<Noldorin> krisives: hehe, lucky you
 * bialix push anyway to publish his finished work for other people
<Noldorin> krisives: i'll catch you later maybe?
<Tak> so I generally commit source changes only, then push
<vila> Tak: I see
<vila> bialix: I see too :)
<krisives> I'm around just kinda in the background
<krisives> Feel free to ask anything, but I will probably be a while
<bialix> (vila has a good eyesight!)
<Tak> there are other times when I'm halfway through a bugfix or something, but I want to push previously committed changes because I'm going to goto lunch, go home, etc.
<vila> Tak, bialix : both of you are aware of the consequences, push_strict is for newbies that may not realize *what* they are/aren't pushing
 * bialix sighs
<vila> it's a bit unfortunate we realize that so late, but I really think the default should be strict, as Tak said, adding a push_strict = False in bazaar.conf is not a lot to ask to power users
<bialix> yep
<luks> should the default UI be really targetted at people who don't know how to use it?
<vila> luks: ???
<bialix> vila: well, with qpush I don't need to set push_strict
<vila> luks: that sounds obvious, how can you learn it otherwise ?
<Tak> luks: yes.
<luks> vila: by reading the manual
<vila> luks: mwhahahaha
<bialix> lol
<luks> Tak: it's the "Mr .Clippy" issue
<Tak> vila: I'm ok with the config option
<luks> Tak: you don't want the program watching you and tell you what are doing wrong
<vila> Tak: note that you can put it in any config file (bazaar.conf, locations.conf, branch.conf) to restrict its scope
<Tak> of course, I disable spellcheck in all my applications
<Tak> but on the same token, I appreciate that spellcheck is on for other people
<Tak> because then I don't have to stab them as much
<luks> spellcheck that warns and spellcheck that doesn't allow you to save incorrectly spelled words are different
<luks> this is the later case
<vila> luks: novice can't be required to activate a novice mode, power users will feel obvious to desactivate a novice mode
<luks> I wouldn't mind a message, or even a question
<Tak> there is a message: "Use --no-strict to override."
<vila> warning are ignored, questions are even more annoying in CLI !
<Tak> maybe the config option should be mentioned in the message, though
<luks> vila: so take the first --no-strict as a step from novice to advanced mode
 * Tak agree @ CLI questions
<luks> vila: well, I find the need to run the command again even more annoying
<vila> luks: yup, I think the missing bit is a hint that --no-strict can be set in config files
<vila> luks: you should do that only once, learn about the config variable, think about it, set it, forget the problem
<vila> by contrast, if it's off, the novice will suffer before he understand why his changes weren't pushed !!! Where are they ? Are they lost ?
<luks> vila: now we only need support for `bzr config push_strict False` :)
<vila> luks: good point !
<bialix> luks: can I ask about Qt? What is QStyle?
<luks> bialix: class that draws widgets
<bialix> I can use default instance of QStyle?
<luks> well, QStyle is an abstract class
<luks> where do you need it?
<bialix> one sec
<luks> every widget has a style instance associated with it
<luks> you can use widget.style()
<bialix> luks: see http://pastebin.com/m7ae00e28
<bialix> luks: Gary use parent=None here but does not provide default style and this code failed in tests
<luks> bialix: use QtGui.QApplication.instance().style()
<bialix> can I just use style = QStyle() here is parent is None?
<luks> at least I think that's the right name
<bialix> ok
<luks> QStyle() would be wrong
<bialix> ok
 * bialix trying
<bialix> luks: it does not help
<luks> hm, why not?
<bialix> because QtGui.QApplication.instance() is None when I'm running tests
<luks> ah
<luks> you can't work that around that
<luks> the icon loading will have to be moved outside of the model
<bialix> all I need actually is style.standardIcon
<bialix> hmm, but IIUC model should provides these icons
<luks> but they depend on the widget style
<luks> what are the tests doing with the model?
<luks> if they are not asking for the icons, you can move the code and load them lazily
<bialix>         model = TreeModel(None)
<bialix>         modeltest = ModelTest(model, None)
<bialix>         
<bialix>         model.set_tree(tree, tree.branch)
<bialix> ^ it was tests
<luks> hm
<luks> I don't know what ModelTest does, but I guess it does lots of things
<bialix> I'm about mark this test as KnownFailure for 0.13
<luks> so the best solution is probably to load the icons elsewhere and pass it to the model
<luks> and pass empty icons from the test
<luks> or even check if parent is None and just create empty icons in the model
<luks> hacky, but should do the work
<bialix> empty icons sounds good
<bialix> luks: empty icons (aka QtGui.QIcon()) did the trick, thanks
<krisives> How can I get a changelog?
<luks> krisives: bzr log?
<luks> or bzr qlog if you want something cooler :)
<krisives> <-- dumb
<bialix> luks: it seems Gary did the wrong thing with this model
<bialix> luks: TreeModel is subclass of QtCore.QAbstractItemModel, the latter can have parent in constructor as instance of QModelIndex and the latter does not have style()
<krisives> How can I get bzr log to only output changes?
<krisives> (Not dates, file names, etc.)
<Noldorin> krisives: you still busy?
<krisives> Sadly so
<Noldorin> krisives: ok no worries
<krisives> What it do/
<Noldorin> CHMOD is not something that does not work just on our Windows servers, it
<Noldorin> does not work on any Windows servers. CHMOD is supported at present only by
<Noldorin> the Linux operating system.
<Noldorin> that's what my web host replied
<krisives> LOL
<krisives> Well, many FTP servers emulate the permission model, and some use NTFS correctly to do some primitive permissions
<bialix> luks: still around?
<Noldorin> krisives: so that's basically rubbish, isn' it?
<krisives> I would say so
<LarstiQ> Noldorin: imnsho, utter rubbish
<LarstiQ> Noldorin: there are ftp servers which don't use the OS filesystem as a backing store but a database for example
<Noldorin> LarstiQ: yeah, exactly what i thought
<krisives> A quick search reveals many of them
<krisives> http://www.xlightftpd.com/
<krisives> was the first Windows-based result I found
<Noldorin> and if the file system is NTFS, CHMOD should work with no problem
<krisives> I've found the best way to "communicate" things to companies is to just politely tell them "Ok, thanks. I would like to cancel my business with you."
<krisives> Person on the phone will take it as a personal insult...
<the-erm> I have an account on launchpad.net, and I want to add another user who can edit/approve changes to a project.  How do you do that?  Do you have a url that explains it
<krisives> And then you have to break down into 3rd grader mode and be like "Business is business... You can't provide the services I want, so I'm not interested"
<LarstiQ> Noldorin: but I think we should be able to make bzr work without chmod
<krisives> Anyone know how I can get bzr log to return all but the first revision?
<Noldorin> LarstiQ: yes, thats is true
<Noldorin> what is your latest suggestion?
<Noldorin> to use mount a virtual directory for the FTP server?
<krisives> LarstiQ: I did some testing and it's not isolated to CHMOD
<LarstiQ> krisives: bzr log -r 2..-1
<krisives> LarstiQ: Thanks!
<krisives> His FTP just straight kills connections too from what I tested
<LarstiQ> the-erm: the trick is to make the project owned by a team: https://help.launchpad.net/Teams
<Noldorin> yeah
<krisives> It would leave the branch lock while trying to sync a 1 file test repo
<Noldorin> but i still don't understand why ...
<LarstiQ> krisives: nice
<LarstiQ> krisives, Noldorin: has a bug been filed?
<vila> the-erm: try #launchpad instead, but overall, yes you can do that, and start reading at https://help.launchpad.net/
<krisives> I actually put a return statement in _setmode to completely bypass CHMOD
<krisives> Using a custom bzr checkout
<vila> krisives: if you have control over the server ftp is really not the best option
<Noldorin> LarstiQ: not yet
<Noldorin> krisives: hmm, did you paste me your log after doing that?
<Noldorin> LarstiQ: i thikn krisives understands the problem better than me :)
<krisives> I had problems with nautilus with this FTP too
<krisives> I've found that if nautilus gets made it's usually because of passive connections or something like that. What does bzr do in that regard?
<vila> krisives: if you have to use ftp anyway bypassing _setmode shouldn't help because it isn't required anyway, that will make your log easier to read though
<vila> krisives: use aftp: instead of ftp: if you need passive
<vila> lol, no
<vila> aftp is to force active, sorry
<LarstiQ> vila: the server is not under our control
<vila> so we are passive by default, use aftp to force active
<vila> LarstiQ: ha, the hard case :)
<LarstiQ> vila: yup
<krisives> vila: I did that because I thought his server would get irritated with so many bad CHMOD attempts
<vila> krisives: ha, good idea :)
<LarstiQ> vila: it's a windows based ASP.NET hoster
<krisives> vila: Does bzr use passive connections via FTP?
<krisives> Yeah it's not mine either I'm just helping Noldorin
<vila> krisives: yes, passive by default
<krisives> vila: You can change it?!
<Noldorin> hmm
<vila> krisives: you can use active by saygin aftp:// instead of ftp://
<krisives> If you can you might want to try that Noldorin. Like I said nautilus (file browser) uses passive connections and was exhibiting similar problems
<krisives> vila: Sorry, it's late/early for me ;)
<vila> krisives: no worries
<Noldorin> krisives: what's the option for bzr?
<krisives> It's a different protocol
<krisives> Instead of "ftp://blah" it's "aftp://blah"
<Noldorin> oh i misread.
<Noldorin> thought you were just referring to an active connection
<vila> no no, that should be me :)
<krisives> Well, all I know is that there are two ways to connect to the FTP, and one way flat out doesn't work on your server
<vila> Noldorin: ftp has two ... as krisives says :)
<krisives> And I tested both ways because Filezilla worked fine, but others didn't work worth beans
<krisives> That's probably the dumbest way to describe the whole thing, but it's 6:36 AM and I've been dealing with IE6 in a VM
<LarstiQ> krisives: I know it's late/early for you, but if you could file a bug so we can start collobarting/tracking around that, that would be nice
<vila> krisives: what kind of VM ?
<LarstiQ> hmm, that's a fun way to spell collaborate
<krisives> VirtualBox
<vila> krisives: what type of network connection ?
<vila> krisives: NAT, bridged ?
<krisives> Not sure, I think it's NAT bridged
<vila> krisives: what host OS ?
<krisives> Could care less if the VM goes *poof*
<krisives> Ubuntu 9.04
<Noldorin> LarstiQ: that, that would be great if krisives could do it, who understands this problem better than me :)
<krisives> Well, right now I don't know what I would file
<vila> krisives: it's either NAT or bridged, nad NAT is severely limited in my experience
<krisives> Well it works on both local and external network, and it has it's own IP i think
<LarstiQ> krisives: ideally a way to reproduce it, the rest can be fleshed out later
<krisives> I hate having to use `net use x: \\vboxsvr\blah` though, it should be in the Network Stuff area
<Noldorin> krisives: have you tried aftp on my server?
<LarstiQ> krisives: the important part is to have a flag in the ground to rally around
<krisives> Good point
<LarstiQ> krisives: just saying "it doesn't work with hoster X, herre is the traceback" would be a start
<krisives> I don't have your FTP details + I am kinda busy at the momemnt
<vila> krisives: if you use it as a client only NAT generally works flawlessly, if you try to use some servers or mount some NFS volumes and need to be authenticated by the NFS server... things become more complicated
<krisives> I just use this as an exaggerated version of Wine lol
<krisives> It runs IE6 and Photoshop
<vila> krisives: NAT is enough then
<krisives> Using Photoshop in Wine is suicide
<Noldorin> krisives: i'll give them to again later if you fancy doing any more testing :)
<vila> krisives: and will help stay away from the bad boys :)
<krisives> It "works" but in reality it has so many quirks that any real PS user will be irritated to hell
<krisives> Well, I guess I have to play the "I'm behind 3 routers" card
<krisives> So it's good ol' security through obscurity on my home network sometimes
<krisives> (joke)
<vila> krisives: don't know what you're talking about (joke)
<krisives> http://en.wikipedia.org/wiki/Security_through_obscurity for anyone lost
<krisives> (actually lost)\
<krisives> this is getting confusing lol
<vila> STO requires that I don't talk about how I setup my home network :)
<vila> funnily enough, http://www.virtualbox.org/wiki/Changelog says:
<vila> # NAT: fixed passive ftp access to host server (bug #4427)
<ubottu> Launchpad bug 4427 in scorched3d "scorched3d: FTBFS on amd64" [Medium,Fix released] https://launchpad.net/bugs/4427
<vila> sorry ubottu. not for you
<vila> krisives: and that's for VirtualBox 3.0.4 (released 2009-08-04), I don't know if you are up-to-date
<LarstiQ> kfogel: 1.17 could be uploaded, but maybe we want to wait
<krisives> Sorry im back, had to make a corn dog
<kfogel> LarstiQ: hey, thanks, was about to ping.  We would want to wait because... ?
<krisives> The base of my office chair broke, so I just put it on top of 2 ATX towers for the mean time
<LarstiQ> kfogel:  [REGRESSION] bzr 1.17 does not use _knit_load_data compiled extension
<LarstiQ> kfogel: reading that thread, it may not be too serious
<vila> LarstiQ: didn't spiv backport the patch ?
<vila> LarstiQ: no, not really serious, I doubt knit is still widely used
<LarstiQ> kfogel: I suppose you'll want to use 2a?
<LarstiQ> vila: but a 1.17.1 point release has not been made, has it?
<LarstiQ> kfogel: I think I'll just include the fix as a Debian local patch
<vila> LarstiQ: no 1.17.1 AFAIK
<kfogel> LarstiQ: this is to use 2a
<LarstiQ> kfogel: right, then it wouldn't really matter for you
<kfogel> LarstiQ: right
<spiv> vila: I backported it to ~spiv/bzr/1.17, pqm didn't let me commit it to the 1.17 branch though.
<LarstiQ> lp:~spiv/bzr/bzr-1.17 specifically
<lamont> does 1.17 support any (well, commit in particular) hooks in the branch, or are they all still located only under $HOME ?
<LarstiQ> lamont: code or configuration?
<lamont> use case: whenever anyone does a commit in this (shared) branch, i want to run a script
<lamont> last I saw, that required modifying files under $EVERYONE's home directory
<lamont> though to be fair, haven't looked recently, for any value of "recent"
<LarstiQ> lamont: that can be configured in .bzr/branch/branch.conf
<LarstiQ> lamont: problem is, then you'll need to do that in each branch
<LarstiQ> lamont: which especially with pushing new branches is a pain
<spiv> LarstiQ: ta
<vila> spiv: ha, thanks, I thought you did something, so it's in jml hands then ?
<spiv> vila: well, jml is probably too busy with other things atm, I think.
<spiv> I guess you could ask him :)
<spiv> I'm not sure if there's really much enthusiasm for a 1.17.1 or not.
<jml> what huh?
<spiv> jml: :)
<vila> LarstiQ: spiv told me you should ask jml :)
<spiv> jml: there are some small patches that would possibly be worth cutting a 1.17.1 for.
<LarstiQ> spiv: I'm branching now, going to have a look at the diff and apply it locally to the Debian packaging of 1.17
 * LarstiQ wouldn't mind cutting a 1.17.1 if jml is too busy
<lamont> LarstiQ: cool - is the particular config snippet trivially on a manpage somewhere?  and I gather that the rest of that means that it's not copied as part of push/pull/etc operations, but is local to the branch only?
<LarstiQ> lamont: to answer the last question first, correct.
<jml> LarstiQ, I am pretty busy right now, so that would be wonderful.
<spiv> jml, LarstiQ: I think there were only 2 or 3 patches people suggested, check the list archives.
<LarstiQ> lamont: the rest of the configuration is the same as otherwise, so post_commit_to = for the email plugin etc
<vila> LarstiQ: Are you still sheperding bzr dogfooding 2a ?
<LarstiQ> vila: yes, although I haven't actively shepherded lately, should get back to that
<lamont> LarstiQ: ta
<fullermd> If you're not actively shepherding, are you just flocking around?
 * Tak rimshot
<fullermd> Thank you, I'll be here all week.  Try the veal!
<Tak> http://instantrimshot.com/
<vila> jam, sidnei: ping
<jam> greetings and welcome vila
<sidnei> vila: aye
<vila> what is missing to plug the buildbot ?
<jam> hand of god?\
<vila> god: ping
<sidnei> time and goodwill?
<jam> AFAIK, getting sidnei to put a buildbot.tac on kerguelen
<jam> and getting someone to review my patch
<jam> (which may have happened, I haven't gotten through all my mail this morning)
<sidnei> and changing vila's master config to accept kerguelen and send the right instructions
<sidnei> vila: just to confirm,  lp:bzr-buildbot-net is your master config?
<vila> jam: no, not reviewed yet, I'd like to, but I'd really prefer to be able to test it first, see the trend ? :)
<jam> vila: merge locally, "make installer-all"
<jam> I don't really know how "make installer-all" will work into the buildbot setup
<jam> but it at least is a manual bootstrap you can use
<vila> sidnei: yes, merge your changes, setup a slave, publish a branch somewhere and I'll update my master
<vila> jam: I still don't have a windows VM ! I want to use kerguelen for that
<vila> jam: well, I want to use kerguelen as a reference point to configure my VM
<sidnei> vila: awesome. i will work on that between now and tomorrow evening. there's a security release i need to get out tomorrow morning which is urgent.
<vila> sidnei: ok, I'm waiting for your branch and a slave (we still need to sync about the ssh tunnel though)
<jam> vila: rdesktop kerguelen; start cygwin, cd /home/shared/bzr/1.18-win32-buildbot; make installer-all
<vila> jam: doh
<sidnei> vila: i see you named slaves after the os. should i call thsi slave kerguelen or win2k3?
<vila> sidnei: no hard rules so far, but preferably the later but I don't know any windows version called 2003 ???
<sidnei> windows 2003? it's server-only, i think that's what kerguelen is using, or is it xp?
<jam> sidnei: it is 2003 server edition 64-bit
<sidnei> thats what i thought
<vila> sidnei: yeah right, just saw that, so is that an NT variant ?
<sidnei> vila: well, everything after 2000 is an NT variant, including Vista and XP?
<bialix> I think so
<vila> isn't vista more than a variant ?
<vila> and windows7 less ?
<vila> jam: no /home/shared for me
<LarstiQ> vila: all NT
<LarstiQ> vila: Windows ME was the last non-NT derivative
 * LarstiQ doesn't know much about Windows 7 yet
<jam> vila:  I'm sure cd /cygdrive/c/home/shared will work
<jam> I'm not sure where that is mapped into the cygwin world
<jam> (well, where *else* that is mapped in)
<vila> jam: good enough
<jam> I have a symlink from ~/dev => shared/...
<sidnei> for completeness, Vista was based off the 2003 "R2" codebase, not XP
<vila> jam: right and 1.18... is under bzr, finding my way :D
<bialix> LarstiQ: IIRC Vista is 6.0 and Windows 7 is 6.1
<spiv> jam: hey, thanks for offering to review inventory-deltas again.
<jam> spiv: well I'd really like it to be good and land
<LarstiQ> bialix: right, that makes sense
<spiv> jam: I'd really like to be able to land it this time :)
<jam> and then build bundles off of it
<spiv> Right.
<jam> spiv: well if the previous time had actually been sending deltas over the wire, I probably would have been more receptive :)
<spiv> Also if it's going to make the next release it needs to land very soon :/
<spiv> I'm *sure* I had been sending deltas at some point!  I guess not that version...
<vila> jam: so, running make instaler-all raises permission denied
 * vila pester rdesktop for not supporting copy/paste
<jam> vila: silly Windows ACLs
<jam> vila: on *my* machine I end up with a copy & paster service that makes it work
<jam> but that is Windows Terminal Client
<jam> vila: let me go check what groups are what
<jam> it is certainly likely that "jameinel" is the sole owner of that dir
<jam> (to date it hasn't mattered, because nobody else seems to do anything on that machine... :(
<bialix> am I remember right that August 6 is the BIG RELEASE DAY?
<bialix> it will be 2.0 or 1.18?
<jam> bialix: rc1
<jam> and given the open bugs for 2.0 it will probably be 1.18
<jam> depends how this week goes
<bialix> today is August 5, so...
<bialix> ok, I'll release qbzr 0.13 in next few days for bundling into installer
 * vila pester against non-resizable dialogs with scrollbars
<bialix> vila ?
<vila> bialix: not in qbzr !
<vila> :D
<bialix> ah, ok!
<bialix> so I can off my qbzr hat
 * bialix waves
<vila> jam: build-win32 seems to lack write access for Users
<jam> vila: probably
<jam> I'm currently changing the owner of the whole "shared" folder
<jam> but it is taking a while
<jam> lots of files
<vila> jam: can I remove it ? Or does it contain precious downloaded items ?
<jam> vila: not precious in the sense that they won't be redownloaded
<jam> but precious in the sense that it takes... 30min-1hr to download everything
<vila> ok, I'll wait for the ACL change then
<sidnei> vila: is the format of that branch 2a? i got a gnarly error
<awilkins> vila: rdesktop supports clipboard
<vila> sidnei: should be, what error do you get
<sidnei> vila: http://paste.lisp.org/display/84828
<sidnei> vila: i created a 1.9 shared repo, that's why
<vila> sidnei: yes, you need to use the same format than the project if you want to stack
<sidnei> vila: maybe the error message should say that *wink*
<vila> sidnei: that *is* what it said *wink* :-D
<sidnei> that's sad. no human would figure that out.
<jam> vila: owner fixed
<vila> sidnei: I know, that was a (bad) joke :-/
<vila> jam: same problem, Users are still not able to write as they are for 1.18-win32-buildbot say
<fullermd> Wow, I thought I liked bzr a half hour ago.
<sidnei> got another nasty, not sure i need to do something about it
<fullermd> But after fiddling with CVS again...
<sidnei> sidnei@topia:~/canonical/bzr-buildbot-net/kerguelen-windows-installer$ bzr push lp:~sidnei/bzr-buildbot-net/kerguelen-windows-installer
<sidnei> This transport does not update the working tree of: bzr+ssh://bazaar.launchpad.net/~sidnei/bzr-buildbot-net/kerguelen-windows-installer/. See 'bzr help working-trees' for more information.
<sidnei> Created new branch.
<jam> sidnei: it is just a warning, and the push succeeded
<jam> one of the side effects of when the target seems to already exist
<LarstiQ> why o why does it mention the working tree if it is creating a new branch?
<jam> LarstiQ: the dir already existed
<jam> it is a current bug, I'm not sure how it comes about
<vila> LarstiQ: because the branch can have a working tree and the WT will be updated if possible
<LarstiQ> vila: note 'Created new branch'
<fullermd> I think thta's a LPism, actually.
<LarstiQ> jam: right
<vila> LarstiQ: yeah, right, I didn't say the whole was coherent :)
<jam> vila: ok, replacing permissions as well as owner to be 'recursively owner has full control'
<jam> expect it to take another little while
<LarstiQ> jam: would I have access to that host as well?
<sidnei> vila: https://code.edge.launchpad.net/~sidnei/bzr-buildbot-net/kerguelen-windows-installer/+merge/9699
<jam> LarstiQ: we can get you access if you want/need. I don't think you have an account there yet
<LarstiQ> jam: I'll keep it in mind
<vila> sidnei: Did I read it right that you desactivated all of my slaves ?
<jelmer> LarstiQ: hi
<sidnei> vila: not intentionally no, but let me double check
<jelmer> LarstiQ: it looks like the repo on bzr.debian.org is broken, I'll push it agian from scratch
<jam> vila: keep in mind that as you build a windows VM, it would be nice to have a "stock" windows install with nothing extra installed
<jam> so that we can start it up, run the bzr installer, make sure it works, and then reset to scratch
<sidnei> vila: maybe you missed this part "builderNames=[b["name"] for b in c["builders"]]"
<vila> jam: that will be the test VM yes, separate from the dev VM
<LarstiQ> jelmer: did you upgrade it to 2a?
<vila> sidnei: could be
<awilkins> What VM platform are you using?
<jelmer> LarstiQ: I attempted to
<jelmer> LarstiQ: can you try again?
<LarstiQ> jelmer: I would like to get that bug stamped out
<jelmer> LarstiQ: which bug?
<LarstiQ> jelmer: the upgrade getting you branches that do that, I've seen it before
<jelmer> LarstiQ: it's basically being caused by the fact htat the upgrade was partial
<jelmer> and if the upgrade is partial not all of the revisions in the repository would be converted
<jelmer> LarstiQ: so attempting to access the tip revision of a branch would cause a NoSuchRevision error
<jelmer> which bzrlib.builtins.cmd_branch catches
<LarstiQ> jelmer: aha
<jelmer> it would actually be nice if upgrade could do a conversion in a separate bzrdir and then move the existing .bzr out of the way later rather than as the first step
<vila> sidnei: fine, master restarted
 * jelmer files a bug
<sidnei> vila: so next steps is to get the ssh tunnel going, i need to setup autossh on kerguelen
<LarstiQ> jelmer: 1.17 backport almost done building, then one more selftest run and I'll upload the result to richtlijn.be and prod you for a proper upload
<jml> how can I write a tool that uses bzrlib for command-line UI infrastructure but doesn't actually force people to say 'bzr foo'? (Instead: 'my-command foo')
<spiv> jam: I have some hackery towards auto repack of streamed data.  Not working yet, but looks promising.
<awilkins> jml: Write python scripts that call bzrlib for features?
<awilkins> jml: I just have a bunch of shell scripts that run bzr :-)
<LarstiQ> jml: write them as bzr plugins and symlink my-command to bzr *ducks*
<spiv> jam: but it's rather late here so I'm going to sleep now :)
<LarstiQ> jml: proper thing I guess would be to extract the bzr command classes further
<jml> LarstiQ, that's not quite good enough for what I want
<spiv> jml: the answer depends on precisely what you mean by "command-line UI infrastructure", perhaps.
<spiv> jml: e.g. do you want our debug flag handling?
<spiv> And our other magic global options?
<jml> spiv, not specifically, but I wouldn't mind it, as long as I could make sure it was specific to my app
<spiv> jml: I suspect some minor patches to bzr may be required.
<spiv> jml: anyway, g'night.  I hope Dublin is treating you well!
<jml> spiv, looking at 'bzr help global-options', I think all of those would be desirable
<jml> spiv, g'night. Dublin is great
<jml> it's not always raining.
<jam> jml: well, you could consider hooking into the "run_bzr" layer
<jam> def myappsmain(args):
<jam>  from bzrlib.commands import run_bzr
<jam> run_bzr(args)
<jam> you'd probably need to patch 'get_cmd_object' as well, though.
<jam> to not actually load the bzr commands
<jam> jml: though maybe if you just avoid a call to "install_bzr_command_hooks" that will be taken care of for you
<jml> jam, may be. I should experiment with it.
<jam> and as "run_bzr_catch_errors" is the code that actually installs the hooks
<jam> you *could* just call 'run_bzr' directly
<jml> and maybe crib some stuff from commands.main()
<jelmer> hi jam
<jelmer> hi jml
<jml> jelmer, h
<jml> i
<jam> hey jelmer
<jam> jml: no cribbing
<jam> you must blindly get it right on your own
<jml> heh.
<jelmer> hmm, confusing nicks
<jml> nooo
<jrv> D?
<jdw> David
<jml> jam: I've already found things that would have to change if they were to be re-used
<jml> report_user_exception has a 'bzr: ' prefix, for example
<jml> anyway, that's enough to get started on.
<jam> jml: except report_user_exception isn't called inside run_bzr IIRC
<jml> no.
<jam> only run_bzr_catch_user_exception
<jml> jam: exactly.
<jml> but I would need something like exception_to_return_code for my own app, I think.
<jam> sure
<jam> vila: permissions should be fixed now
<vila> jam: sidnei took my place on kerguelen, slave setup in progress
<jam> vila: thought you might be intereseted
<jam> there is a discussion in the merge proposals about optimizing topo_sort
<jam> implementing it on top of KnownGraph gives me KG.topo_sort in 10ms down from about 188ms
<jam> though there is 30-40ms of KG setup overhead
<vila> jam: I marked the discussion as should-re-read-asap but didn't see KnownGraph mentioned...
<vila> jam: it's topo_sort not merge_sort right ?
<jam> topo_sort
<jam> yes
<jam> vila: but it is a promising look at what merge_sort could become :)
<jam> though honestly the slow point is still loading the whole graph...
<vila> jam: my long term plan for that is to have a dedicated index with the parents sorted by gdfo
<vila> sidnei: congrats !!!
<sidnei> \o/
<sidnei> jam: bzr: ERROR: no such option: --no-tree
<sidnei> jam: i guess kerguelen is running an old bzr?
<jam> sidnei: my guess is you are using an old bzr
<jam> though it worked for me
<jam> but perhaps because I forced bzr.bat?
<sidnei> could be
<sidnei> jam: it's got 1.11 installed
<jam> sidnei: that is fairly signifcantly old
<sidnei> jam: should i try to upgrade it?
<al-maisan> Hello there! How does one read bytes from a file given a bzrlib.branch.Branch or similar?
<jam> sidnei: if you want
<jam> I generally prefer to run from bzr.dev myself
<jam> but you should be able to use the installer we built :)
<sidnei> jam: 1.17?
<jam> yeah
<sidnei> wonder if there's a local copy on kerguelen to avoid a download :)
<jam> sidnei: there should be plenty
<sidnei> jam: under shared?
<jam> C:/home/shared/bzr/releases/bzr.1.17 should be the easiest
 * sidnei finds it
<kfogel> LarstiQ: http://backports.org/debian/pool/main/b/bzr/ still on 1.16 -- expected?
<OllieR> Hey, do client and server always need to run the same version of bzr?
<beuno> OllieR, no, in general, they work well together
<beuno> they work better if they're the same version, fo course
<beuno> and if one of them is too old, then you may not be able to
<beuno> but in general, they don't need to be
<LarstiQ> kfogel: yes, testsuite run just finished
<LarstiQ> hmm, now my uploader disappeared :)
<LarstiQ> ah no
<LarstiQ> jrv: http://richtlijn.be/~larstiq/bzr/1.17/
<OllieR> I have noticed commits seems to be taking far too long recently. For example I change one text file, do a commit over sftp to a central repo, and 8mb is transfered, which seems crazy.
<OllieR> Wondering whether this is because I am using such an old version of bzr - Bazaar (bzr) 1.3.1
<kfogel> LarstiQ: *nod*  thanks
<LarstiQ> kfogel: it's a matter of uploading now
<LarstiQ> kfogel: (jelmer changed his nick to jrv (temporarily)?)
 * LarstiQ continues cooking
<kfogel> LarstiQ: great!
<OllieR> Surely a one character change to a text file shouldn't incur such huge data transfer. It makes no sense....
<SamB> jelmer: I'm having auth issues with bzr-svn again :-(
<jelmer> SamB: please be more specific
<SamB> jelmer: are there flags I can use for that?
<jelmer> SamB: you're being very vague - what doesn't work exactly?
<SamB> jelmer: well, let me paste a transcript ...
<SamB> http://paste.ubuntu.com/248182/
<SamB> log is at http://paste.ubuntu.com/248185/
<kfogel> I tried to install python-launchpadlib, but I'm having some problem with bzr and bzrtools (I think, maybe because I build bzr from trunk?):
<kfogel>  I installed python-launchpadlib, but it looks like maybe I'm paying for my habit of installing bzr from trunk?  see https://pastebin.canonical.com/20828/
<SamB> in short, what doesn't work is "bzr push https://dosemu.svn.sourceforge.net/svnroot/dosemu/trunk --no-strict"
<kfogel> sorry that was a paste from another channel, so it duplicated some information.  the pastebin is the main thing
<jelmer> SamB: does push to svn+https:// work?
<SamB> jelmer: no
<jelmer> SamB: same problem?
<jelmer> SamB: when did this break? Does the last known working version still work?
<kfogel> jelmer: (you saw LarstiQ's pings to you above?)
<SamB> jelmer: except it has '' instead of 'dosemu.svn.sourceforge.net' between 'HTTPS ' and ' username: '
<jam> kfogel: yeah, it looks like you already have a /usr/lib/python2.5/bzrlib file
<jam> and so it tries to install bzr using apt and can't
<jam> because files are in the awy
<jam> one possibility is to manually delete bzrlib
<kfogel> jam: ah, thanks
<jam> install from apt
<jam> then install from source
<kfogel> jam: *nod*  will do
<jam> though if you are runinng bzr from source
<jam> you don't have to install it
<jam> just 'make' in that directory is enough
<kfogel> jam: I'd prefer to have it in /usr/local/bin though!
<jam> cd /usr/local/bin
<jam> ln -s ~/bzr/bzr.dev/bzr
<jam> kfogel: symlinks work well for that
<SamB> jelmer: hmm, I don't know :-(
<kfogel> jam: no /usr/lib/python2.5/bzrlib at all
<SamB> mostly I just want bzr-svn to have better support for debugging this type of thing, I guess ...
<kfogel> jam: hmm, could do symlink
<jam> kfogel: /usr/lib/python2.5/site-packages/bzrlib
 * SamB wishes this could be included in the test suite
<kfogel> jam: d'oh
<jam> you'll still want to install the regular apt supported bzr so that apt's db thinks you have bzrlib available
<kfogel> jam: doing now.  I'm going to do it your way: build from source, symlink from /usr/local/bin/, *never* install my source-built bzr, let apt own what it thinks it owns.
<jelmer> kfogel: yeah, I'm on it
<kfogel> although apt shouldn't touch anything in /usr/local
<kfogel> jelmer: wonderful
<kfogel> jam: everything fixed now.  Thank you for the timesaving help.
<Tak> I've always wished there was an `apt-get pretend-to-install`
<SamB> jelmer: is there some way I can trace the authentication process ?
<jelmer> SamB: not really - most of it is in bzr itself anyway
<SamB> jelmer: I'd be a bit happier if it was using SVN's auth stuff ...
<jelmer> SamB: it does use svn's auth cache as well if it's present
<SamB> what is "it"?
<jelmer> SamB: if there are credentials present in svn auth cache for the repository you're connecting to it should use those
<SamB> again, what is "it"?
<jelmer> SamB: bzr-svn
<jelmer> SamB: and bzr
<SamB> jelmer: it can't just let svn do it ?
<jelmer> SamB: no, because if you're using http:// the first access is using bzr
<jelmer> SamB: so a 403 would trigger a password prompt
<jelmer> SamB: anyway, does a "manual" commit work ok with svn on that machine?
<SamB> hmm
<jelmer> SamB: auth over https works fine here with current bzr-svn
<SamB> jelmer: oh ... I guess I never stored that before ...
<jelmer> SamB: so, password prompting should still work
<jelmer> SamB: even if it wasn't stored before
<SamB> hey ... the first access isn't the one that needs authentication here anyway!
<jelmer> LarstiQ, kfogel: We should probably wait for a 1.17.1 with the performance fix
<LarstiQ> jelmer: performance fix?
<LarstiQ> jelmer: I included the knit_load_pyx fix
<jelmer> LarstiQ: the pyrex import stuff
<LarstiQ> jelmer: ie, applied the diff from lp:bzr/1.17 to lp:~spiv/bzr/bzr-1.17
<jelmer> LarstiQ: backports shouldn't include any changes other than backporting existing stuff
<LarstiQ> jelmer: hmja
<jelmer> what are the plans for 1.17.1 ?
<LarstiQ> jelmer: I'm going to look through the list for changes and cut it on Sunday I think
<kfogel> jelmer: the perf fix doesn't affect 2a repositories, does it?
<LarstiQ> jelmer: if you don't want to include the change, I'll prepare a 1.17-2
<LarstiQ> kfogel: it doesn't
<kfogel> jelmer, LarstiQ: then no urgency from Emacs' point of view, since it will be 2a anyway.  But if yuo want to do 1.17.1, that's great!
<LarstiQ> kfogel: 1.17.1 will also have some Windows fixes
<jelmer> there'll be quite some stable users who aren't using 2a yet, so I'd rather not upload something that hurts performance for them
<LarstiQ> jelmer: right. So that is why I included the ~6 lines of changes
<jelmer> LarstiQ: sorry about that, I wasn't aware about this problem in 1.17.0
<LarstiQ> jelmer: and for unstable, my rationale is that they can wait for 1.17.1 or 1.18
<LarstiQ> jelmer: if you absolutely want the change in unstable first I'll do that
<LarstiQ> jelmer: but please look at the debdiff first
<kfogel> LarstiQ: oh, Windows fixes are good.
<LarstiQ> kfogel: yeah, there will be an 1.17.1 anyway, but it will take some more time
<kfogel> jelmer, LarstiQ: maybe it is worth a re-roll and re-upload, then -- if it's not difficult for you guys.
<kfogel> your call
 * LarstiQ nods
<kfogel> we're good to go even with 1.17.0+patch, and remember, clients can get anythig they want -- this is for Savannah to *host* the trunk repository, raelly.
<LarstiQ> kfogel: would Savannah want to take the deb if it doesn't come from backports.org?
<LarstiQ> kfogel: I mean, it runs on Lenny
<LarstiQ> kfogel: but I can understand them not wanting to make an exception in their software channels
<kfogel> LarstiQ: I think they want it from backports.org, they're pretty conservative.
<LarstiQ> kfogel: fair enough
<jelmer> LarstiQ: I've looked at the debdiff, that's how I knew about the change :-)
<jelmer> LarstiQ: I'm hesitating because I'm paranoid about breaking stable users systems.
<LarstiQ> jelmer: ah
<LarstiQ> jelmer: right, that is very sensible
<jelmer> LarstiQ: (and I've never done a backports uplaod before)
<LarstiQ> jelmer: if you want we can ask nobse, who uploaded the previous version, what he thinks about the backports upload specific part?
<jelmer> LarstiQ: Yeah, that's a good idea.
 * jelmer queries
<LarstiQ> jelmer: other than that, I think the question is, would you trust 1.17.1 to be stable enough, or not?
<jelmer> LarstiQ: are you sure the other changes in 1.17.1 are going to be windows fixes?
<LarstiQ> jelmer: the infinite recursion one is pretty bad, so that will go in
<LarstiQ> jelmer: I'll have to look at the list to see what other stuff people have proposed
<emmajane> beuno, No response required. I just wanted to put this on your radar in case you hadn't heard of it: http://www.springloops.com/
<beuno> emmajane, thanks
<emmajane> pricing seems similar to unfuddle, but the basecamp integration looks interesting
<beuno> (on the phone, as usual)
<emmajane> heh
<DaffyDuck_> How does bzr use ElementTree? With regards to the bug reports about bazaar using excessive amounts of memory, I'm wondering if it in my case can be due to cElementTree not being available.
<jelmer> LarstiQ: the infinite recursion problem is windows-specific?
<LarstiQ> jelmer: well, it is uncorrectly splitting the drive letter if your cwd is the top, iirc
<jelmer> ah
<LarstiQ> DaffyDuck_: I doubt that, but possibly.
<LarstiQ> DaffyDuck_: check bzrlib/xml_serializer.py
<beuno> emmajane, do they have their own VCS?
<emmajane> beuno, nope, it's just subversion
<beuno> ah
<beuno> "ew"
<beuno> :)
<emmajane> (unfuddle has git or subversion)
<emmajane> :)
<beuno> it looks slick though
<emmajane> very slick, yes.
<emmajane> and the base camp integration is interesting.
<mobodo> I think I have my bzr browser pretty much sorted out
<mobodo> I'll clean and post the code in case anybody is interested
<mobodo> http://bazaar.enseed.com/
<pygi> :)
<pygi> nice
<mobodo> it's only a php file and a .htaccess, no need to configure the server
<pygi> php xD
<pygi> evil :D
 * beuno finally gets to emmajane's email and start replying
<emmajane> heh
<ronny> hmm, i should do one of those things for all intresting vcs's
<ronny> jelmer: any plans to add a wsgi app to dulwich that implements the http proto ?
<SamB> jelmer: well, I added exception logging to auth.SubversionAuthenticationConfig.get_svn_simple
<SamB> jelmer: you can pull it from bzr+ssh://bazaar.launchpad.net/~naesten/bzr-svn/hackz/
<SamB> and it says:
<pygi> ronny, or I should...since I need it for Roundup
<SamB>   File "/usr/lib/python2.5/site-packages/bzrlib/ui/text.py", line 92, in get_non_echoed_password
<SamB>     password = getpass.getpass('')
<SamB> NameError: global name 'getpass' is not defined
<ronny> pygi: as long as i can use it without roundup >:)
<pygi> ronny, that is/should be the general goal
<pygi> not sure when I'll come around to do it tho
<ronny> pygi: well, i need to write more apps using the historo abstraction, so i can find issues
<pygi> write it then
<pygi> I won't argue :p
<jelmer> SamB: please submit a patch to bzr :-)
<SamB> jelmer: yeah, started looking at that ;-)
<beuno> emmajane, aaaaand, replied (don't need to F5 all the time!)
<emmajane> :)
<emmajane> beuno, thanks :)
<SamB> jelmer: I would suggest trying to find a nicer way to do such exception logging for *all* of bzr-svn's methods that are to be called by subvertpy ...
<emmajane> beuno, you get a cookie for being the first
<jelmer> SamB: generally this isn't a problem
<jelmer> SamB: but some callbacks in the svn API don't allow you to abort the operation e.g. by returning an error code
<SamB> er, that is, when exceptions wouldn't be passed through
<beuno> \o/
 * beuno eats the cookie
<SamB> jelmer: well, okay, I just mean any others of that sort
<jelmer> SamB: there is only one other function like that
<SamB> ah.
<jelmer> SamB: (transport activity)
<SamB> it's hard to tell just from looking at the code!
 * emmajane jumps up and down and gets all excited that beuno responded and looks at everyone else and wonders who else wants cookies. :)
<jelmer> did somebody say cookies ? :-D
<emmajane> jelmer, only if you respond to the RFC for the new home page. :)
<SamB> oh. I should grab some cake ;-)
 * emmajane is not above (or is it below?) bribery. ;)
<jelmer> emmajane: what's the URL?
<emmajane> https://lists.ubuntu.com/archives/bazaar/2009q3/061047.html
<emmajane> http://www.flickr.com/photos/emmajane/3791477132/ has the wireframe itself
<SamB> jelmer: hmm. apparantly it's a bug in "bzr 1.17+4566+119" but not in the bzr.dev I have around ...
<SamB> shouldn't there have been a new PPA build by now?
<SamB> jelmer: oh, but it still seems like it ought to find the credentials in the SVN cache rather than making me type them in
<SamB> especially considering that subvertpy passed in the correct username already!
<SamB> jelmer: ... so my question is now: do you think it would be possible to create a blackbox test for this?
<garyvdm> mobodo: That's interesting - I would like to add a commit screen a PHP cms system. How did you get data from bzr? did you run "bzr ls"?
<garyvdm> *screen to a ...
<mobodo> garyvdm: yes, bzr ls, bzr cat and bzr version-info
<mobodo> and bzr log
<garyvdm> mobodo: That cool. Where is your code?
<mobodo> it being cleaned up as we speak :)
<mobodo> I can send you an email later tonight or tomorrow if you want
<garyvdm> mobodo - Yes please - I probably will copy bits out to make a commit screen in php. garyvdm@gmail.com
<mobodo> sure
<jelmer> SamB: yes, it'll check the svn auth cache and the bzr configuration first, and if there's no data found there it'll prompt
<SamB> jelmer: yeah, so you keep saying
<SamB> but it doesn't seem to work very well for me :-(
<jelmer> SamB: a blackbox test for this is only possible if you can somehow automate starting an apache server with the svn module loaded
<jelmer> SamB: you could do some unit testing for the auth infrastructure though, making sure it asks the right credentials providers
<SamB> jelmer: I was afraid of that :-(
<SamB> I don't suppose we could mock up a dummy svn server that would only do enough to test the authentication?
<SamB> ... and then fail after that?
<jelmer> SamB: you'll have to implement a significant part of the protocol for that
<jelmer> SamB: I think testing just the auth infrastructure should take care of most of these problems though
<jelmer> there's no particular need for blackbox tests
<SamB> jelmer: hmm.
<SamB> well, it certainly sounds more practical than the alternative ...
<SamB> jelmer: hmm ... it works if I hand-edit the file in ~/.subversion/auth/svn.simple to actually work with the simple authprovider ...
<lifeless> deal evolution, doing 3M/s from my disk forever, is not good.
<SamB> where by "works", I mean *those* values get used
<poolie> emmajane: are you here?
#bzr 2009-08-06
<poolie> lifeless: i'm telling you, it's a liberal lie
<jelmer> SamB: bzr-svn is already using platform-specific auth providers where possible
<SamB> jelmer: all of the ones that that function returns?
<SamB> 'cause I didn't see bindings for it
<jelmer> there's one for windows and one for keychain (Mac OS X)
<jelmer> kwallet is missing
<jelmer> support for gnome-keyring is also not there, but already provided through bzr-gtk
<jelmer> SamB: are you still convinced this is a valid bug report?
<SamB> jelmer: well, I do think it would make more sense to use that function than to do everything piecemeal ... though APR is a bit of a pain ...
<SamB> and why is the gnome-keyring bit part of bzr-gtk?
<SamB> svn uses it fine from the CLI ...
<jelmer> SamB: it's part of bzr-gtk because it's not svn-specific in any way
<jelmer> SamB: "plain" bzr can use gnome keyring as well
<SamB> jelmer: oh. well, svn uses it in a particular way
<jelmer> SamB: that function doesn't really allow us to do everything piecemeal, we still have to call it with the name of the client provider we'd like to obtain
<jelmer> that's hardly no more useful than seeing if a method with a particular name exists in Python
<jelmer> s/no/any/
<SamB> jelmer: oh, wait, I must have got mixed up
<jelmer> SamB: related to this, I don't want to know what happens if both bzr-gtk and bzr-svn both register providers that use gnome keyring
<jelmer> SamB: what's the actual problem you're trying to solve? "must use function 'foo'" doesn't seem like a worthwile goal by itself
<poolie> hi jelmer
<jelmer> moin poolie
<SamB> jelmer: er, sorry about that, my computer has been rebooting at the darnedest times lately ...
<SamB> <SamB> jelmer: oh, wait, I must have got mixed up
<SamB> that's the last thing I saw ...
<jelmer> SamB: related to this, I don't want to know what happens if both bzr-gtk and bzr-svn both register providers that use gnome keyring
<jelmer> SamB: what's the actual problem you're trying to solve? "must use function 'foo'" doesn't seem like a worthwile goal by itself
<SamB> jelmer: anyway, right before it rebooted I realized you were probably looking at the singular-named function that is named almost the same as a plural-named function
 * jelmer has another look
<jelmer> ah
<jelmer> SamB: you're right, that would probably be useful to expose on a subvertpy level
<jelmer> SamB: I don't see what problem it would solve for bzr-svn though
<SamB> well, it would mean not having to do anything to support any new platform-specific authentication providers that SVN 1.7 might have ...
<jelmer> SamB: it also means duplication of gnome-keyring
<jelmer> SamB: any specific stuff that svn 1.7 might add we can add support for manually /if it doesn't conflict with stuff bzr already provides/
<SamB> jelmer: I don't understand this whole "conflict" thinking
<jelmer> SamB: if e.g. the password in gnome-keyring is wrong we'll end up sending it twice
<SamB> jelmer: say, is this related to seahorse at all?
<SamB> because I don't *have* that
<jelmer> SamB: no, seahorse is only accessed by bzr-gtk for gpg signatures
<SamB> 'kay
<SamB> how do I get at what gnome-keyring stores?
<jelmer> I think there's a separate app
<jelmer> gnome-keyring-manager or something IIRC
<SamB> jelmer: ah, that's it alright
<SamB> jelmer: so, how is the bzr-gtk support supposed to work?
<jelmer> SamB: it registers a fallback credentials provider
<jelmer> SamB: that gets queried by bzr before it prompts
<SamB> wonder why I didn't see anything like that happen?
<SamB> ... that not need to ask me for a password before it could do anything?
<SamB> +would
<jelmer> SamB: it'll only use existing passwords, never storing new ones
<jelmer> (since it doesn't have a way to tell whether a password that was entered and returned was valid
<SamB> it can check whether there is one without the keyring password being entered?
<jelmer> I don't know
<dash> i've upgraded to a recent enough bzr and svn to set revision properties instead of file properties on push. can I delete all the bzr: file properties in svn without deleterious results?
<SamB> dash: freenode appears to have eaten your "jelmer: "
<SamB> jelmer: hmm, /usr/share/doc/gnome-keyring/keyring-intro.txt.gz tells me that it only asks for a password if something is found
<spiv_> jam: ping?  Are you still looking at the inventory-delta patch?
<SamB> so I'm thinking that either this isn't working at all for bzr, or bzr and svn don't find the same entries
<jelmer> dash: yeah, you should be able to do that. the main thing you'll probably lose is the ability to branch old revisions by revid easily
<dash> not an issue, i expect
<jelmer> dash: emphasis on *should*, this isn't something that a lot of people have been testing afaik
<dash> jelmer: Hooray! Science!
<dash> I will let you know if I develop any adverse symptoms.
<jelmer> SamB: yeah, that sounds sensible
<Luke-Jr> Best way to fabricate commits? XD
<SamB> jelmer: FWIW, the entry that SVN made in my keyring has only the Username, Password, Port, and Domain fields filled in in gnome-keyring-manager ...
<SamB> and the Port field has a 0 in it
<SamB> and is grayed out
<SamB> so maybe that's not really filled in either
<SamB> jelmer: how is the bzr user expected to have gotten entries in there that bzr would use ?
<jelmer> SamB: epiphany
<jelmer> SamB: also, hopefully the API will start supporting the addition of new entries at some point
<SamB> jelmer: the bzrlib API?
<SamB> jelmer: anyway ... it sure looks like your gnome-keyring thingy doesn't subsume SVN's ...
<spiv_> lifeless: want to review my inventory-delta patch?
<lifeless> spiv_: yes
<lifeless> I've been battling a check patch
<lifeless> hopefully its really sorted now, and I'm -> food
<lifeless> but after that
<spiv_> lifeless: hooray!  Thanks :)
<lifeless> also evolution is being utterly retarded
<SamB> lifeless: you ... don't evolve, though
<SamB> you're an individual
<SamB> this is *not* pokemon
<lifeless> I mean really. Its like a kid thats got diarrea crawling backwards and eating off the floor, all at the same time.
<lifeless> SamB: Dunno about you, but my cells divide, have random mutations and undergo a fitness test.
<poolie> ew
<poolie> enough, hey
<lifeless> sorry
<lifeless> 3 hours now I've been trying to get email read
<lifeless> I'm venting elsewhere now
 * emmajane blinks at lifeless.
 * emmajane thinks that sometimes it's better not to read backwards. :)
<jam> spiv: I sent in a little bit more review, but I haven't "finished" yet
<jam> However, for *me* InventoryDelta is significantly *faster* for converting than IDS for bzr.dev @2000
<jam> I think because the extra repacks are costing it a bit of time
<spiv> jam: yeah, I see that too.
<jam> note that it is still *slower* for mysql-525
<jam> I haven't split out the repacking time to know where the problem might be.
<jam> It might be repacking
<spiv> I'm just in the process of grabbing launchpad so I have a larger dataset to work with.
<SamB> repacks tend to crawl for me ...
<jam> it might also be that by default btreebuilder will cache up to 100,000 nodes before writing anything to disk
<jam> while repacking is causing it to write and read again much more often
<jam> spiv: except lp starts as --2a ...
<jam> might want to grab mysql instead
<spiv> Or as well :)
<jam> spiv: so I wonder if the last bit is that IDS will not re-read an inventory from the source if it misses from the cache.
<jam> so occasionally it probably generates a fairly large delta
<jam> spiv: if we could  fix the "re-read full inventories to generate the root texts" and "progress indication" I'd be happy to remove IDS :)
<spiv> jam: I know I'd be happy to remove it :)
<jam> the progress thing is actually a pretty big deal
<jam> try upgrading something like even bzr using -DIDS:never
<jam> and it really just sits there for a long time
<spiv> Yeah, I bet.
<lifeless> jam: we have to fix it for normal push pull too
<lifeless> I don't think it has to be a blocker; if we're going to fix it for 2.0.
<jam> spiv: at least for remote you get transport activity
<jam> removing IDS completely, it is a blocker for me
<lifeless> poolie: http://advogato.org/person/robertc/diary/107.html
<lifeless> poolie: iter-changes may become blocked soon; I'm waiting on Aaron's reply
<igc> lifeless: what 2 branches are they again? I'd like to run usertest on OOo on your work to date
<igc> hi all
<lifeless> iter-changes-partial-parents + commit-specific-files
<lifeless> I really wish review showed commit messages against lines
<lifeless> a mixed diff + annotate
 * lifeless buginates
<thumper> lifeless: what do you mean?
<thumper> although on re-reading, I think I know
<thumper> might be kinda hard in that we store the reviews as text...
<thumper> diffs that is
<lamalex> hi, im getting an error- "bzr: ERROR: [Errno 13] Permission denied: '/home/alex/tangerine/tangerine-0.3.1/TangerinePrefPane/Makefile.in'"
<lifeless> that suggests that permission was denied :P
<lamalex> yes, im an idiot and failed to read to full path until right now
<lamalex> i managed to skip the tangerine-0.3.1 part of the path that make distcheck created
<lifeless> igc: did you find the branches?
<igc> lifeless: yet to look - will after I've finished my current email
<SamB> hehe
<SamB> the info page for bzr-gtk looks bad in bzr-gtk ;-P
<thumper> hardlinking working copy files is not currently supported in <WorkingTree6 of /home/tim/src/lp/review-team>
<thumper> ?!?!
<thumper> what changed?
<mwhudson> thumper: you're now warned about it
<thumper> mwhudson: when?
<thumper> oh
<thumper> before it just wasn't doing it?
<mwhudson> aiui
<thumper> ah
<thumper> so that is where my disk is going...
<poolie> thumper: yeah fraid so
<poolie> NEWS has a pointer to the bug about it
<poolie> you can comment there
<poolie> thumper: https://bugs.edge.launchpad.net/bugs/408193
<ubottu> Launchpad bug 408193 in bzr "bzr branch or checkout --hardlink has no effect in 2a format" [Medium,In progress]
<thumper> poolie, ta
<KhaZ> Hello!  Pardon me for a newbie question, but I'm curious about the best process for something.  I'm building a web application, and as such I've got a 'development' test server and what I hope will be a 'production' web server.  For the production side, should I use a branch and tagging mechanism, or is there a better way to do this?
<poolie> KhaZ: kind of a big question but typically you'd have two branches and merge from development to production at intervals
<poolie> whenever you roll out
<poolie> spiv, how's it going?
<spiv> poolie: enjoying the punishment that the combination of pushing part of mysql-server into 2a and using lsprof gives to my cpu :)
<poolie> robert said he was going to review it after lunch..
<lifeless> I am reviewing it
<spiv> jam has sent a partial review too, where he says that his performance concerns have been addressed, which is good news.
<spiv> poolie: is https://bugs.edge.launchpad.net/bzr/+bug/402778 the bug you wanted me to look at?
<ubottu> Launchpad bug 402778 in bzr "NoSuchRevision error when branching with rocketfuel-get" [Critical,Triaged]
<poolie> actually no, though it does look useful
<poolie> i was thinking of bug 375013
<ubottu> Launchpad bug 375013 in bzr "Commit doesn't honor stacking invariants" [Critical,Triaged] https://launchpad.net/bugs/375013
<poolie> your choice
<spiv> Ah, right.
<spiv> I'll take a look, see which one appears easier ;)
<lifeless> I bags 375013, if you like
<spiv> lifeless: sure, that makes sense I think.
<spiv> As you've probably got commit's guts paged in already.
<lifeless> OTOH you've been doing streams most recently
<lifeless> have a look at the comment I put in 375013 recently
<lifeless> you may prefer to do it
<vila> hi all
<spiv> I'd prefer my wireless to stop mysterious sucking.
<spiv> Good afternoon vila.
<vila> spiv: yeah, hopefully the afternoon will be better than the morning with my daughter waking up at 39.5C :-/
<lifeless> spiv: to give you an update
<lifeless> spiv: lots of little stuff; some baroqueness sneaking in that I think you can just totally axe.
<igc> vila: hopefully she's feeling better soon
<vila> igc: oh, I don;'t worry that much for her, except for the fact that she was about to fly for an additional vacation week and *that* will certainly be cancelled :-/
<spiv> lifeless: cool, that sounds promising.
<lifeless> I'm up to bzrlib/smart/repository
<lifeless> 20 pages to go
<lifeless> I'll be finishing it tomorrow
<pygi> hi ho vila :P
<vila> pygi: hi !
<rif_> Hi guys, is there a command to pull and update at the same time?
<lifeless> rif_: no, folk either pull, or update :)
<lifeless> rif_: are you doing 'pull URL; update' ? if so, you shouldn't need to
<rif_> lifeless: i was making a script to update several repos and I was wandering if i just missed that command
<lifeless> rif_: pull updates the working tree
<lifeless> update is used to update a tree against its own branch
<rif_> lifeless: oaaaa
<lifeless> poolie: EOD; biab;
<poolie> k, bye
<rif_> lifeless: pull updates the working tree indeed :)
<rif_> lifeless: so update would be used if someone pushed stuff to my branch to update the tree?
<mtaylor> lifeless: http://gorf.tangent.org/hudson/job/Drizzle-subunit/3/
<poolie> hello vila
<vila> hi poolie
<poolie> how's stuff?
<vila> kerguelen has been plugged as a slave, I'm debugging it right now
<lifeless> rif_: yes
<spm> is there a pointer to "magic that I can drop in .bzr/branch/branch.conf to run an arbitrary shell command on commit" - if indeed possible? Or an alternate method for same?
<lifeless> mwhudson: SEX
<lifeless> vila: http://gorf.tangent.org/hudson/job/Drizzle-subunit/3/ <- its drizzle, but thats what a result page could look like using subunit
<vila> lifeless: sexy indeed
<lifeless> mwhudson: oops, wrong nick :P
<lifeless> mtaylor: SEX
<pygi> spm, post-commit plugin? :)
<pygi> hook plugin*
<lifeless> spm: no, it would be a huge security hole
<lifeless> spm: you can however write a post commit or post_push or post_tip_change plugin in python, and have it get its parameters from branch.conf
<lifeless> vila: and here - http://gorf.tangent.org/hudson/
<lifeless> you can see if you mouseover drizzle-subunit you get the test details
<vila> grpmf, definitely sexier than buildbot :-/
<spm> lifeless: in this specific case, we'd be relying on O/S security to control who can read, let alone commit. Is that still a hole when used that way?
<lifeless> yes
<lifeless> if root ran 'bzr commit' in a different tree on the system, it could do arbitrary code as root.
<lifeless> the _facility_ to run arbitrary code on commit is the hole
<lifeless> doing a plugin as I described isn't a hole
<spm> Ah. I see. the old PATH=. exploit in essence. right.
<lifeless> yes
<lifeless> I've also jsut realised there's probably one in ~/.bazaar/plugins
<lifeless> if you 'sudo bzr'... without HOME getting set to roots HOME
<spm> hmmm. wouldn't that be a weakness of su and not getting an env set? taking the crud with you?
<lifeless> yes
<lifeless> but the default is the default
<spm> sure
<spm> oki, ta, will pass that back to the questioner. much appreciated.
<lifeless> we'd be happy to help write a bzr plugin - its very easy to check a couple of branch configuration variables
<lifeless> so the idea is, to have a plugin that (say) sms's
<lifeless> youd set my_foo_number = ...
<lifeless> and my_foo_other = ...
<lifeless> in branch.conf
<lifeless> then the plugin checks branch.get_config().get_user_variable('my_foo_other')   [roughly, details vary with contact with the enemy]
<spm> in this case it's to trigger an earlier run of a cron task, but yeah
<lifeless> mwhudson: http://src.opensolaris.org/source/diff/opengrok/trunk/src/org/opensolaris/opengrok/analysis/executables/ELFAnalyzer.java?r2=%252Fopengrok%252Ftrunk%252Fsrc%252Forg%252Fopensolaris%252Fopengrok%252Fanalysis%252Fexecutables%252FELFAnalyzer.java%40554%3Aa40bc05ca4e6&r1=%252Fopengrok%252Ftrunk%252Fsrc%252Forg%252Fopensolaris%252Fopengrok%252Fanalysis%252Fexecutables%252FELFAnalyzer.java%40509%3Ae65b56e2a9f0
<lifeless> mwhudson: pretty
<AfC> Nice URL there
<AfC> Love those percent signs
<lifeless> that part is scary yes
<poolie> heh, the nice thing is they're escaped percent signs, serving as escape signs
<fullermd> Yeah, it's almost as much fun as 7 \'s in a row in the middle of a string  :p
<vila> seven \' or seven \ ?
<fullermd> Yes.
<vila> tought so
<AfC> Git has a revert command which has a -n option:
<AfC> --no-commit       don't automatically commit
<AfC> what in god's name is that!
<fullermd> The way I see it, the problem is that you're looking too closely at git...
<fullermd> But git revert xyz == "bzr merge -rxyz..parent:xyz . ; commit"
<fullermd> (presumably, it's well-named, since it's pretty much synonymous with --no-commit on git merge)
<dannoffs> Anybody home?
<dannoffs> anyone know of a how-to on setting up bazaar on  a godaddy server with SSH access? I know it can be done
 * igc dinner
<lifeless> vila-doctor: when you get back - another hudson feature - graphs - http://gorf.tangent.org/hudson/job/Drizzle-subunit/
<sender> is anyone aware of a way to see the diff between the working tree and a pending update on a checkout? bzr status gives me 'working tree out of date, run bzr update', but i'd like to see what I'm applying.. any ideas?
<Kinnison> bzr diff -r $(bzr revno)..-1
<Kinnison> ?
<vila> lifeless: I'd be interested by their time-travel machine, the results in your last URL are for 2009081[23] 8-D
<lifeless> ;)
<sender> Kinnison: thanx, this shows the diff between the last and pre-last revs right?
<Kinnison> sender: I'd expect "current" and "head"
<Kinnison> sender: I'm guessing -- I don't tend to use checkouts like that
<lifeless> gnight
<sender> Kinnison: I think you are right: head has revno 132, bzr diff -r 131..-1 gives the diff for rev 132... very useful
<sender> Kinnison: I only use it for live instances of sites, as a lightweight checkout of a repo on the same server
<sender> Kinnison: only thing is, a working tree could be several revs 'out of date'..
<sender> Kinnison: same issue: https://bugs.launchpad.net/bzr/+bug/318604
<ubottu> Launchpad bug 318604 in bzr ""bzr diff" after "bzr push" does not display changes" [Undecided,New]
<Kinnison> Hmm
<fullermd> Kinnison: 'revno' gives the revision number of the _branch_, not the working tree.
<fullermd> Kinnison: You wanr 'revno --tree' for that.
<vila> sidnei-away: ping
<Kinnison> fullermd: aah
 * Kinnison only uses checkouts rarely :-)
 * sidnei yawns 
<sidnei> wassup vila
<vila> sidnei: I change the AutoSSH to use '-M 0' instead of '-M 20000', it took me a bit of time to realize how to properly install the service...
<vila> aka using -u Admin
<vila> :-/
<vila> anyway, that should address the connect/disconnect messages that kind of ruin the prettiness of the new .css :)
<vila> sidnei: also, I fixed one DNS IP address and add two more but still no cigar, I'll check with jam later
<stewart> hi! I've just gotten a crash while doing 'bzr rebase': "bzrlib.erros.NoSuchRevision"
<sidnei> vila: ok, thanks for letting me know. do you need any more help?
<stewart> is anyone able to help with my rebase crash?
<vila> sidnei: can you explain why 'nslookup host' can resolve a host when 'ping host' can't ?
<vila> sidnei: otherwise, there are a couple of things I'd like to address in the slave/builder definitions but I need to know how you create the slave and setup the environment, aka, more or less update the README for kerguelen
<sidnei> vila: i suspect it's too early in the morning for me to ponder about ping vs nslookup. :)
<vila> sidnei: ok, np, nearly lunch time here anyway, take your time :)
<sidnei> vila: as for the slave definitions, i just ran 'buildbot create-slave' afair, but the client is running a copy of buildbot trunk, so that might explain the difference
<vila> AAAARGH damn synergy  virtualbox rdesktop windows incompatibility nightmare gimme my mouse back damn it
<vila> sidnei: to run start the slave via a service too ?
<vila> sidnei: do you start the slave via a service too ?
<sidnei> vila: yes, as explained here http://buildbot.net/trac/wiki/RunningBuildbotOnWindows
<vila> sidnei: I can' click on that anymore :-( I just can type here, will reboot shortly, if you can send me the relevant commands by mail, I'll update the README
<vila> sidnei: back,
<vila> ok, reading the URL you mentioned, it appears that the slave is started with buildbot_service.py start "c:/<buildbot_dir>" "d:/<another_buildbot_dir>"
<vila> sidnei: What I did for all the others was to define the environment in the Makefile and start them with 'make start' so that env changes doesn't require restarting the service, but restarting the service takes the changes into account :)
<sidnei> vila: ok
<vila> sidnei: I don't know how much work it involves to get there but if you can start by putting the slave definition (.tac and info dir) under bzr that would be a good start :)
<sidnei> vila: yeah, i will do that today
<vila> ok ta
<vila> the idea above is to end up with a service that just do: 'make -C <slave_dir> start' and nothing more
<mobodo> when I bzr log, is it possible to get the last log (-l1) before or at a given revision (-rX) ?
<vila> look at the other slave Makefiles
<mobodo> if I bzr log -rX and there is no change for that revision, I simply get nothing
 * fullermd can't parse "no change for that revision"...
<fullermd> The stuff log shows is properties of the revision, so they're there...
<Raim> not if you do  bzr log -rX foo.txt  and foo.txt has not been changed in revision X
<fullermd> Oh.  For that you'd want something like "bzr log -r..X -l1 foo.txt"
<fxn> hey .bzrignore is typically added to the repo?
<Raim> fxn: yes
<fullermd> It doesn't have to be; it works merely by being there.  But most of the time, you add it, since it makes sense for anyone else or any other branches to have the same ignores.
<mobodo> thanks! -r..X did the trick
<jelmer> moin jam
<jam> morning jelmer
<vila-lunch> morning jam !
<jam> morning vila
<mityaj> hi! anybody known how to uninstall bazaar windows shell extensions(TortoiseBZR)?
<mityaj> regsvr32 -u tbzr.dll
<vila> jam: LOL, parralel reviews :)
<jam> yeah, my mail got out before yours got in :)
<vila> jam: I think poolie has a plugin to change the default format to 2a and can experiment failures
<vila> jam: anyway, he'll tell us :)
<jam> well, it is easy enough to do it manually
<jam> given that it is a 1 line change
<vila> jam: but you should remember to undo it and do it in every branch, etc
<mobodo> are you supposed to be able to pull a subdirectory from a branch  without pulling the full branch with bzr?
<mobodo> say "bzr branch http://foo.org/bzrbranch/some/sub/project"?
<jelmer> mobodo: no, that doesn't work
<mobodo> ahh, ok, so you'd have to make sub branches
<jelmer> mobodo: it may be supported at some point in the future, although there's nobody working on anything like that at the moment
<vila> jam: I fixed some DNS entries on kerguelen this morning, but still no cigar
<jam> vila: do you have a traceback of the latest failure?
<vila> jam: the context is just trying nslookup and ping
<vila> i.e. 'nslookup host' now works (I think it didn't, can you confirm) but 'ping host' still doesn't
<jam> vila: I'm pretty sure 'nslookup' always works
<jam> as it goes and contacts a DNS server directly
<jam> whatever is messed up on Kerguelen doesn't effect nslookup
<jam> so 'ping' is the real test
<vila> ha ok
<jam> (I could be wrong, but I think that is what I found)
<fullermd> nslookup will use [the platform equivalent of] resolv.conf, but it does do all the query gen/send/recv/dissection internally, yes.
<fullermd> It doesn't use gethostbyname() or the like.
<vila> anyway, the first dns server in 'ipconfig /all' was wrong, I fixed it and added the 3rd and 4th
<vila> fullermd: we're talking windows here, do you know what the equivalent of resolv.conf is ?
<fullermd> Probably something in the registry.  I'm pretty sure it's what ipconfig /all tells you.
<vila> fullermd: http://paste.ubuntu.com/248670/ , I find the IP routing Enabled: No suspicious as well as the default gateway being in a different subnet...
<vila> jam: by the way, why can't we use DHCP ?
<jam> DHCP for?
<fullermd> Eh.  If it's not being used as a router, there's no real reason to enable routing.
<vila> jam: for IP address, default gateway, DNS
<jam> vila: last I checked the default gateway and subnet mask and default dns were a bit crazy
<vila> fullermd: even if talking to different subnets ?
<jam> when we asked the hosting provider to fix
<jam> they said they needed to wipe and re-install the os
<vila> :-(
<jam> if we are going to do that, we'll stop hosting with the
<jam> thm
<fullermd> vila: [I'm pretty sure] that means routing packets THROUGH the host; e.g., the host itself being a router.
<jam> them
<fullermd> Default gateway on a different subnet is unusual perhaps, but still valid (as long as routes exist to get the packets there of course)
<fullermd> But if it were wrong, you'd know it, 'cuz NOTHING would work, so that's not _the_ problem, whatever else it may be.
<vila> fullermd: Yeah, I thought a bit like that, but my past experiences with network is also that when I don't understand something it's often one or several bugs
<vila> s/often/often due/ s/bugs/wrong configurations/
<fullermd> If nslookup works, that means all the network-related bits of DNS lookup is in good shape.
<fullermd> (well, nothing's _certain_, but that's about as good a sign as you can get)
<vila> so, backtrack,
<vila> if dns setup is right, what should be changed for ping to use it
<fullermd> So the likely place to something like ping to fail at getting the IP is in the resolver functions in libc.  gethostbyname() etc.
<fullermd> I have no idea how that hooks together in windows, though.  Presumably, it's the immoral equivalent of how it is on POSIX, but...
<fullermd> Does ping to bare IP work?
<vila> I thought their TCP/IP stack was based on BSD :-P
<vila> ping to hosts declared in the 'hosts' file works
<fullermd> Well, I'm based on amphibians, but I still can't hop worth a damn   :p
<vila> and ping to bare IPs works too (just to answer the question)
<fullermd> Hm.  Well, you've presumably got python on the box; you can try banging up a script to use python's gethostbyname() equivalent (which presumably hooks through libc), and see if you can get results back from that.
<fullermd> Or step down below that and throw together some C test code if you wanted.
<vila> fullermd: I was tempted to try that, but 1) asking first may have worked, 2) I strongly suspect that I will get the same results as ping (and I already encounter problems from python)
<fullermd> Oh.  Well, in that case, I'd like to change my diagnosis to "It's messed up"   :)
<jam> fullermd: gethostbyname fails
<jam> ping or direct access to IP addresses works
<jam> since we can set the IP in hosts and connect
<jam> (I tried that in the past :)
<fullermd> You tested down to the function level?
<vila> fullermd: your help is much appreciated (no kidding, walking the obvious (or not obvious) helps me keep my sanity)
<fullermd> Well, I have no real business doing any debugging on Windows; I haven't really touched it since I wiped it 95 my system 13 years ago   :)
<fullermd> But DNS and networking and all, that I know.  So hopefully I can bring a little something to the party anyway.
<fullermd> ...   13 years ago??  WTF?  It can't have been that long...
<vila> fullermd: kind of same background here except I'm not *that* old :-D
<fullermd> Well, I didn't think *I* was either!
<jam> fullermd: I tested "py -c "import socket; socket.gethostbyname()"
 * Tak only 11 years ago, youngun
<fullermd> Well, so that suggests it's b0rked at the python layer, and while it doesn't prove the problem is down in libc, the ping issue is symptomatically consistent with that, so it's probably a fairly safe guess.
<fullermd> (actually, it may be a separate libresolv and not actually in libc, but same difference)
<fullermd> I wouldn't know where to begin on fully defining or fixing that on win32   :|
<jam> fullermd: well, IIRC,the windows tcp stack *is* based on the BSD stack :)
<jam> hences why it is ".../etc/hosts"
<vila> hmm, things you don't like to find in registry: DhcpDomain REG_SZ sw.ru
<weigon> should $ bzr rebase git://... work (with bzr-git) ?
<weigon> I get:
<weigon> $ bzr rebase git://github.com/hyperic/sigar.git
<weigon> bzr: ERROR: bzrlib.errors.NoSuchRevision: KnitPackRepository('file:///Users/jan/projects/in-bzr/sigar/.bzr/repository/') has no revision ('jan@mysql.com-20090713013128-p2obx3x942vd1waq',)
<mobodo> is there an equivalent to the svn "export" in bzr?
<mobodo> I want to download the branch without ending up with .bzr folders
<Tak> bzr export
<GastonBorys> hi
<GastonBorys> what web application can be used to track the history of bzr in some project?
<GastonBorys> to see diff and changes maked
<cody-somerville> GastonBorys, do you just want like a branch browser or something more?
<beuno> GastonBorys, https://launchpad.net/loggerhead
<GastonBorys> beuno: vos estas en todos lados
<GastonBorys> la idea es que no quieren usar launchpad para el proyecto
<GastonBorys> estaban hablando de savanne
<GastonBorys> pero parece que es un bardo configurarlo en el servidor
<GastonBorys> la otra que habÃ­a pensado es tomar el gtk-olive y hacerlo para entorno web
<beuno> GastonBorys, loggerhead is independiente de Launchpad
<beuno> es un web viewer de bzr
<beuno> lo corres localmente
<beuno> hay muchas proyectos que lo usan
<GastonBorys> beuno: perfecto, no lo conozco, tenes idea si soporta varios sources, de diferentes aplicaciones
<beuno> GastonBorys, como varios sources?
<beuno> solo branches de bzr
<beuno> (sorry for the spanish)
<Tak> hay un plugin bzr por trac, no?
<GastonBorys> el tema es asi, la gente de antico abandono el desarrollo, giuseppe cigala, estoy dandole una mano a los de DelphOs http://delphosproject.org
<GastonBorys> y bueno les voy a ayudar a acomodar un poco el entorno grÃ¡fico, pero quieren desarrollar aplicaciones para ese entorno grÃ¡fico, la idea es hacer un track no solo con antico sino tambiÃ©n con las aplicaciones y quieren algo que integre todo vos decis que funcionarÃ¡?
<GastonBorys> (yes sorry for spanish)
<GastonBorys> Tak: si, pero no soporta esto que mencionÃ©
<GastonBorys> lo voy a mirar mientras igualmente gracias capo
<GastonBorys> thanks!
 * Tak asiente con la cabeza
<beuno> GastonBorys, esto es loggerhead funcionando: http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/changes
<beuno> no tiene integracion con nada, pero las URLs son las de la estructura de directorios
<beuno> asi que sonoredecibles
<beuno> er
<beuno> "son predecibles"
<GastonBorys> loggerhead
<beuno> GastonBorys, de curioso, porque no quieren usar Launchpad?
<GastonBorys> beuno: no se, pero como estoy mitad y mitad no puedo dar ordenes, me voy a tener que adaptar a lo que me pidan, yo les dije, empecemos con launchpad a ver que pasa, pero viste como son las burocracias con la gente que opina de las distos y como launchpad lo utilizan los de ubuntu es como que les molesta
<GastonBorys> no voy a entender nunca esto de las guerras de distros, editores de texto y lenguajes de programaciÃ³n
<beuno> heh, entiendo
<beuno> bueno, loggerehead lo usa Launchpad
<beuno> (hoy no es mi mejor dia para tipear)
<beuno> yo soy uno de los desarrolladores
<beuno> asi que si necesitas ayuda, puedo ir guiandote como integrarlo
<GastonBorys> beuno: muy bien dale
<GastonBorys> para no molestar aca, en donde te puedo encontrar?
<beuno> GastonBorys, argentina@gmail.com
<beuno> o #ubuntu-ar
<beuno> o en privado  :)
 * beuno se va a alm orzar
<GastonBorys> gracias buen provecho
<mobodo> in case this interests anybody else, I've posted the source code for my bzr web browser here: http://bazaar.enseed.com/app/webbzr/
<vila> jam: I give up, I've put some dns servers in registry, they shouldn't do any harm, they may need a reboot...
<vila> jam: also, kerguelen seems to have 8 procs but only 600M, is that correct ?
<jam> vila: sorry was away eating. 8-procs is probably 4 real processors + hyperthreading
<jam> server info say 640MB of ram, yes
<jam> we also seem to be limited to "120 processes"
<jam> and it seems to be limited to "2000 CPU units"
<jam> and 20 GB of disk space
<jam> these are all price configurable ($.20/mo per 1MB of memory, $1/100 units of CPU time, etc)
<jam> though again, if we can get set up on EC2 or something along those lines, we'd probably rather do so.
<lamalex> hey guys, I rm'd a file then created a new one with new content, but bzr is showing a removed and an unknown file
<lamalex> can I just get it to be modified?
<lamalex> they have the same name..
<fullermd> lamalex: You probably want to dance around revert.
<fullermd> (of course, if it's actually a different file, you probably WANT it to be a different file)
<lamalex> well the add/remove is not right, it's the same file just with all new contents. I want to preserve the old history
<kizzo> I do a "bzr rebase-continue" and it fails with an exception: "AssertionError: author property given twice"
<kizzo> Anyone know offhand how to fix this problem?  Anyone know why it even happens?
<vila> jam: ok, we'll do with that, I was asking because one bzr-installer-dev-plugin-release failed with an out of memory error
<vila> s/one/last build/
<jam> vila: interesting, though I would say going OOM w/ 600MB of ram may indicate something we want to fix.
<jml> I would like 'bzr shelve --all; <run relevant tests> && <discard shelf>' as a single operation
<jml> Or, failing that, an undo for 'bzr revert' :)
<abentley> jml: have you tried "bzr alias 'revert=bzr shelve --all'" ? ;-)
<jam> jml: wouldn't that be "bzr shelve --all code/but/not/tests ; <run relevant tests> " ?
<dash> any emacs dvc users about?
<dash> i'm wondering if anyone has successfully used M-x dvc-delta with bzr. :)
<SamB> dash: what's that?
<SamB> dash: this is the first I've heard of it
<SamB> dash: okay, it doesn't work for me either
<SamB> go ahead and report a bug on launchpad!
<SamB> I think dvc needs moar blackbox tests ;-)
 * SamB wonders how you do that for emacs packages ...
 * SamB wonders why jelmer didn't take his exception logging code for bzr-svn ...
<SamB> (for logging exceptions thrown from it's AuthProviderObject ...)
<mkanat> Loggerhead question -- is there a way to get serve-branches to hide parent directories of branches that aren't themselves branches or repositories?
<beuno> mkanat, not with a switch, but it's easy to tweak in the code
<mkanat> beuno: Where would I look?
<mkanat> beuno: Ideally it would be a config thing, though. Something in the repository config.
<mkanat> beuno: My use case is that the top-level directories are client names that I don't want to expose.
<beuno> mkanat, you can easily create a config for it
<beuno> I would look in...
<beuno> mkanat, loggerhead/apps/branch.py:131 is a good place to start
<beuno> you can see examples of configs being used
<mkanat> beuno: Thank you. :-)
<beuno> mkanat, loggerhead/apps/transport.py also has some of it
<jml> jam: that would be interesting too
<jml> jam: maybe it is what I meant.
<RenatoSilva> how to make a diff between two tags?
<jelmer> RenatoSilva: bzr diff -rtag:foo..tag:bar
<RenatoSilva> jelmer: thanks!
<lifeless> hi jml
<jml> lifeless, hi
<SamB> how would one go about adding a -D flag for a plugin?
<lifeless> just check for 'flag' in debug.debug_flags
<lifeless> wher edebug is
<lifeless> from bzrlib import debug
<SamB> okay ...
<sidnei> speaking of bzrlib...
 * sidnei finds lifeless email to reply to
<SamB> but shouldn't it be possible to add *help* for it?
<lifeless> SamB: the help is static at the moment
<lifeless> I don't particularly like that, but tuits
<SamB> lame!
<jelmer> igc: hi
<poolie> hello
<poolie> emmajane: hi?
<poolie> jam, still around?
<emmajane> poolie, Pong. I'm just getting ready for the drupal docs sprint.
<poolie> k
<emmajane> we finish up in ~2h. It's just a short one.
<emmajane> I'll ping you when we're done, poolie
#bzr 2009-08-07
<igc> morning all
<igc> hi jelmer
<SamB> am I right in thinking that bzr selftest -E foo is supposed to put 'foo' in bzrlib.debug.debug_flags ?
<poolie> lifeless: i see we have an Inventory and an InventoryCommon class
<poolie> which i think is the antipattern we were talking about a while ago wrt RepositoryBase
<lifeless> no quite
<lifeless> InventoryCommon is the base; Inventory is really MutableInventory, or InMemoryInventory
<lifeless> but there were enough uses of it that renaming would have been traumatic
<poolie> why is that different?
<lifeless> we've moved a lot of stuff to Common
<lifeless> CHKInventory is immutable
<poolie> i could equally say that Repository is really VFSBasedRepository
<SamB> hooray for immutability
<SamB> poolie: do you have some other kind?
<lifeless> poolie: Repository long ago lost concrete code
<poolie> RemoteRepository
<lifeless> its not a leaf
<lifeless> RemoteRepository is a leaf, as is Inventory, and CHKInventory
<poolie> argh
<lifeless> poolie: I could be wrong; but thats why I think the cases are different
 * SamB wishes for a black board
<poolie> i should be more precise
<poolie> the issue is: things that sound like they should be base classes, actually are not
<lifeless> poolie: oh right. Inventory is a really misleading name
<lifeless> I would love to renamed it to (say) InMemoryInventory
<lifeless> s/renamed/rename/
<SamB> how about rename but leave an alias behind?
<poolie> we could get there from here by either - inserting a new class called *Base or *Common
<SamB> with a comment that it's there to avoid pain
<poolie> or, changing the existing one
<poolie> SamB: it's too hard wrt our api compatibility
<poolie> i'm hoping that introducing different api break windows may make it easier
<lifeless> SamB: do, or do not :).
<poolie> it may still be traumatic even just within bzrlib though
<SamB> well, at least that way people would see the right name if they repr'd it
<poolie> btw re https://code.launchpad.net/~mbp/bzr/403523-status-crash/+merge/9739
<poolie> do you object to me putting has_filename in the base class?
<lifeless> so, to rename it, we could do it, use a factory as Inventory, which can issue deprecationwarning
<poolie> anyhow, concretely
<poolie> the thing to do is change RemoteRepository to inherit from Repository and see if anything breaks
<poolie> or if anything should go into a LocalRepository
<poolie> or some better name
<lifeless> yes
<lifeless> I'd just change RR to inherit from R and see what the fallout is
<lifeless> +1 on that change
<lifeless> has_filename is a little ugly though
<igc> lifeless: that usertest run on OOo with your pending patches got done last night ...
<igc> lifeless: 73.9 -> 1.8 seconds for selective commit
<poolie> ! :)
<lifeless> well, thats better than it was
<lifeless> hows full commit?
<igc> lifeless: and also interesting is ...
<lifeless> [drum roll please]
<igc> send -o dropping from 332 seconds to 69.6 seconds
<lifeless> in my branch?
<igc> lifeless: where 70 seconds still sucks, fwiw
<lifeless> that would be the path2id improvement showing up
<lifeless> igc: whats full tree commit in OOo?
<igc> 1.8 seconds
<lifeless> ok, so we're still dominated by something not addressed
<lifeless> I'd love an lsprof of both incremental and full commits of a single file
<lifeless> I suspect dirstate load/save
<igc> shall do
<igc> lifeless: if it is, I have a patch for that - still in review maybe
<poolie> igc, i assume that send thing is with jam's ptach?
<lifeless> poolie: I improved a code path send uses as well
<igc> poolie: the 332 seconds is with bzr.dev rev 4593 - pretty recent
<igc> poolie: but looking deeper, I'm not sure whether my 'pending' branch with robert's patches has it or not
<poolie> spiv, does my last comment on bug 405251 make any sense to you? :)
<ubottu> Launchpad bug 405251 in bzr "Huge data transfers/bad performance OVERALL" [Undecided,Incomplete] https://launchpad.net/bugs/405251
<thumper> does anyone use bzr with windows and launchpad here?
<thumper> https://answers.edge.launchpad.net/launchpad/+question/79261
<thumper> the question here is trying to work out why it isn't working
<sidnei> thumper: occasionally
<thumper> AFAICT it should work
<thumper> so I'm guessing it has to do with getting bzr on windows to use his putty key
<thumper> and I have no idea how to check that
<spiv> poolie: "I wonder if this is related to binary modules not being built?" ?
<spiv> Oh, there's a newer one now.
<poolie> mm, maybe, or actually to something being stuck or inefficient in hpss protocols
<spiv> It wasn't there when I first loaded the page.  email lag I suppose.
<poolie> bit of a wild-ass-guess
<sidnei> thumper: the steps he outlined seem correct generally. unless he messed up on step 5.
<thumper> sidnei: is there any way for him to check?
<sidnei> step 5 from the launchpad wiki, that is, the one that has a explicit warning about where it can get messed up
<lifeless> igc: there are a few commits from trunk missing
<sidnei> thumper: when you upload the ssh key to launchpad does it get used right away, or there's a time needed for it to sync somewhere?
<lifeless> igc: its missing 4588
<lifeless> which changes bundles as well
<lifeless> igc: I'll merge trunk now
<igc> lifeless: thanks. My 'pending' trunk is usually trunk + merges of stuff I want to benchmark but ...
<igc> lifeless: I'd prefer to just benchmark you branch if it's up to date with trunk
<igc> s/you/your/
<thumper> sidnei: I don't know
<lifeless> sidnei: its usable immediately, modulo db lag
<sidnei> thumper: that's the only thing that comes to mind: he uploaded the key and expected it to work right away, but the key isn't immediately put in place on the server side. but i don't know if that is the case or not.
<thumper> hmm..
<lifeless> sidnei: the ssh daemon isn't openssh, so it just asks the db for the key, rather than waiting for it to be put on disk
<lifeless> igc: pushed
<igc> lifeless: is iter-changes-partial-parents enough yet? Or do I still need to follow that up with a merge from selective-file-commit?
<lifeless> you need both
<poolie> igc, any comments on kiko's vm mail?
<igc> poolie: if we want continuous testing following a commit, we need it up most of the time I suspect
<poolie> yeah
<igc> poolie: perhaps a time out of a few hours would work though and ...
<poolie> that's about $100/month, it shouldn't break the bank
<igc> might result in it being down over weekend periods in particular
<igc> poolie: if we go the mega-vs-simple installer route, ...
<igc> poolie: then the testing only needs the standard simple installer or easy-install
<igc> poolie: building the mega-installer will happen rarely
<sidnei> hey igc, poolie
<sidnei> not sure if vila let you guys know, but we have builds being run by kerguelen now
<lifeless> excellent
<lifeless> sidnei: have you seen hudson?
<sidnei> matter of fact, i did
<mwhudson> ...
<sidnei> :P
<lifeless> mwhudson: change your highlight rules ;)
<mwhudson> lifeless: this one is in my brain, sadly
<lifeless> mwhudson: I hear electroshock is much more refined these days
<mwhudson> heh heh
<kiko> poolie, igc: I'm outta that circuit now -- I have done what I can :-)
<kiko> poolie, igc: again, for me bzr2 is the priority -- this is just something nice to have happen
<poolie> kiko, thanks for connecting the circuit
<poolie> a good 2.0 is the priority but getting good windows builds for it will help make it a good release
<spiv> Hmm, test_pack_repository really ought to be renamed to per_pack_repository or per_repository_pack I think.
<spiv> poolie: actually, that's something you might want to look at while looking at running tests with 2a as the default, test_pack_repository doesn't include 2a in its scenario list!
<spiv> (also, the way the scenario definition duplicates a bunch of format strings etc rather than just grabbing them off the format objects is weird, I think.)
<poolie> :/
<poolie> could you file a bug assigned to me?
<spiv> Sure.
<jfroy> jelmer: is there some guide on using dpush?
<lifeless> poolie: review sent
<lifeless> bah
<lifeless> spiv: review sent
<poolie> for the delta branch?
<lifeless> yes
<lifeless> about 6 hours of reading and thinking
<krisives1> Anyone know how I can get `bzr log` to output time and date?
<lifeless> it does by default?
<krisives1> It outputs date, but no timestamp
<lifeless> timestamp: Fri 2009-08-07 01:03:20 +0100
<lifeless> is what I see
<lifeless> what are you seeing?
<krisives1> Wait, nevermind
<krisives1> I am using `bzr log --short`
<krisives1> Hmm, I want the short but with the timestamp
<krisives1> I suppose I can parse
<spiv> lifeless: thanks!
<krisives1> I know this isn't SQL
<krisives1> Anyone know a good way to swap 2 primary keys?
<lifeless> lunch
<lifeless> if you need me, ring me, I'll be offline
<krisives1> cheers lifeless
 * igc lunch
<emmajane> igc, noooo. no lunch!
<emmajane> :)
<spiv> Oof, reviews replied to.
<poolie> lifeless: are you back?
<poolie> epic review there
<spiv> Yes, "epic" was exactly the word I was just thinking of :)
<spiv> More epic than expected, really.
<spiv> There are a few points still not 100% resolved, but I think it's probably good enough to land, and the last few nits can happen in a followup landing, I think.
 * spiv makes a coffee
<spiv> Yeah, with the aid of this coffee, I'm pretty comfy with the state of this branch, so I'll pqm-submit it now and send the last few fixes later.
<vila> hi all
<vila> poolie: I'd like to answer that mail about the win32 build machines but I miss the meaning of some TLAs: AWS, AMI ?
<bob2> amazon webservices, amazon machine something (disk image)?
<vila> ha right
<poolie> hello vila
<vila> poolie: hey !
<poolie> hi
<poolie> shall we talk about that?
<poolie> i was just going to send mail
<poolie> or maybe i should send mail and then we  should talk
<vila> poolie: same here, mail nearly godd to be sent from here
<poolie> vila what do you mean by "as long as we can be freed from the nightly ones"
<vila> grr, freed "from the risk of regressions"
<vila> wow, this sentence makes no sense at all, sorry :-/
<vila> I meant to say: If the nightly builds gave us the benefit of catching the regressions sooner, the release builds should be hassle free and as such can be done by humans
<poolie> ok, right
<poolie> at least kicked off by a human
<vila> poolie: 'kicked off' as in 'in a freshly started VM' ? Yes
<vila> or any other valid host
<spiv> Heh, "make check" fails on my branch due to "make docs" not liking the markup for the -DIDS:always debug flag.
<poolie> spiv maybe eventually debug_flags should be a dict
<poolie> i'd kind of agree for now it should be IDS_always but whatever
<vila> spiv: 'IDS:' made it kind of obvious that the flags were exclusive... too bad :)
<lifeless> vila: bob2: amazon web services, amazon machine image
<spiv> I could take lifeless' suggestion and just not document them...
<vila> spiv: >-/
<poolie> no, they're fine
<poolie> lifeless: in the context of https://code.edge.launchpad.net/~mbp/bzr/403523-status-crash/+merge/9739
<poolie> what's the difference between test_inv and per_inventory?
<poolie> it looks like they want to be the same thing?
<lifeless> I think they do
<lifeless> except
<lifeless> perhaps
<lifeless> per_inventory wants to be per_mutable_inventory
<lifeless> and the tests at the top of test_inv - the parameterised ones, a small part of the file
<lifeless> want to be per_immutable_inventory
<lifeless> or something along those lines of separation
<poolie> ok
<poolie> then i might:
<poolie> file a bug for this
<poolie> rearrangement;
<poolie> stick a test for has_filename into test_inv
<poolie> and merge my change
<lifeless> yup
<lifeless> per_inventory only tests Inventory today
 * igc dinner
<spiv> lifeless: btw, if I just delete that if block from the per_interrepo fetch test the tests still pass.
<spiv> lifeless: so whatever bug I had that prompted me to add it in is gone.
<lifeless> \o/
<spiv> Another problem solved by deleting some code!
<Kinnison> huzzah
<lifeless> spiv: uhm
<lifeless> spiv: you should delete the if statement and undent the block, I think.
<spiv> lifeless: right, that's what I meant.
<lifeless> phew
<spiv> run the assertions unconditionally.
<lifeless> I thought that on first read
<spiv> Sorry about the false alarm(s) :)
<lifeless> then I read what you wrote.
<spiv> Yeah, my bad.
<lifeless> :)
<OllieR> Hey, do symlinks work in bzr?
<fullermd> In what sense?  bzr sill store and version symlinks, sure.
<vila> sidnei: ping
<jelmer> jfroy: not really, it's basically just like push
<jelmer> igc: hi
<igc> hi jelmer
<jelmer> igc: I've proposed a merge for some foreign branch tests, I was wondering if you could comment on the general approach I've taken, so I know if I'm on the right track before doing a lot more of these tests.
<jelmer> igc: (the merge proposal is at https://code.edge.launchpad.net/~jelmer/bzr/foreign-tests/+merge/9642)
<igc> jelmer: I won't have time in coming days sorry, Maybe vila or jam could offer an opinion? If not, I'll take a look mid-to-late next week
<igc> jelmer: sorry about that but I just have too much other stuff on my plate currently :-(
<jelmer> igc: No worries
<igc> night all
<jelmer> g'night igc
<dgoulet> hey people!, with bzrlib, is it better to use bzrlib.commit or bzrlib.builtins.cmd_commit() for a working tree?
<dgoulet> anybody?
<vila> dgoulet: cmd_commit is very close to the command line but may be harder to use than the command line itself
<vila> bzrlib.commit may be harder to understand if you're not familiar with the bzr internals
<jelmer> dgoulet: any reason for not using WorkingTree.commit()? That invokes bzrlib.commit
<jelmer> moin vila
<vila> jelmer: hi
<dgoulet> no not at all, actually i'm getting deeper into bzrlib day after day and I'm wondering the best way to commit a working tree
<dgoulet> i'm using cmd_commit right now but i was thinking that there might be a better way
<vila> dgoulet: you should have a look at the commit tests and decide from there what suit your needs
<vila> dgoulet: try 'bzr selftest commit --list' to get a taste
<vila> but presumably jelemer is right, you awnt to use wt.commit()
<dgoulet> hmm ok I look into that, very nice
<dgoulet> another question while i'm here
<dgoulet> i have a branch with NO tree (only .bzr)
<dgoulet> what's the best way of getting that into a working tree to work on whitout a cmd_branch() ?
<jelmer> dgoulet: BzrDir.open(path).create_workingtree()
<meuserj> After upgrading bzr to 1.17, my integration with Redmine suddenly stopped working.  Did a little diving into Redmine to see what command is causing the issue, and bzr is indeed crashing on the command which redmine uses: http://pastebin.com/d58052ae2
<meuserj> any fixes or workarounds available?
<jelmer> meuserj: please file a bug report, this looks like a regression in bzr
<meuserj> jelmer: a little more experimentation shows that it is the revno:-1 option which is causing the crash
<meuserj> ah, and it only happens when I use bzr://.. other remote protocols, including bzr+ssh seem to work.
<jelmer> meuserj: ah, odd
<jelmer> meuserj: definitely seems like a bug then
<jelmer> meuserj: the fact that it only occurs with bzr:// probably explains why nobody has noticed it before
<meuserj> jelmer: yeah I assumed that bzr:// isn't used often.. the only reason I use it is that the machine hosting Redmine is different than the machine hosting the central repository, and it's easier to use the bzr server than try to set up ssh keys for the web server user.
<dgoulet> from a working tree, if I want to revert a specific file to a lower revision, how can I make that happen because i'm having no result from wt.revert()... ?
<meuserj> jelmer: wow.. yet another variable.. it only happens with repositories served via bzr-server, not individual branches
<manuee> hi everyone, brand new user here... silly question: if i do bzr ignore dirname, is everything under that directory ignored recursively?
<Tak> dgoulet: I'm using RevisionTree.revert()
<vxnick> manuee: yes
<manuee> ow awesome
<manuee> i was wondering because olive lists the files under those dirs as unknown instead of ignored
<manuee> so i was geting confused
<vxnick> ah :)
<manuee> thanks vxnick =)
<dgoulet> yess that's what I though but when I try to get the RevisionTree from my WorkingTree, it always tell me that NoSuchRevision...
<dgoulet> i'm doing something bad but I can,t figure it out
<manuee> im planing on geting my drupal development under bazaar (soloing)
<Tak> wait, my bad
<dgoulet> from a RevisionSpec, how can I get the revision id ?
<jelmer> dgoulet: the as_revision_id() method IIRC
<Tak> I'm getting the rev from the revision tree, then using WorkingTree.revert() with that rev
<dgoulet> :| how?
<Tak> one sec, let me pastebin some code
<manuee> ive got my repository setup here onmy local development machine, the next step would be to set it up on the production server,... any guides/howtos/tips on how to go about it so ican push changes to my server from my local machine?
<manuee> i know its a broad question... perhaps i should study the manual a bit more
<manuee> :X
<vxnick> manuee: depends if you wanna use commit/update or push/pull
<vxnick> I think the manual has a few examples which you might find helpful
<manuee> yeh i should probably re-read that see if i figure things out
<manuee> ow
<manuee> server doesnt have bzr installed :X
<vxnick> if you want to use push/pull you don't need bzr installed on the server
<manuee> ooow nice
<vxnick> you can do bzr push sftp://you@server.com/path/to/repo
<manuee> push only uploads stuf ?
<dgoulet> Tak: thanks!
<manuee> i rtfm vxnick
<Tak> http://paste2.org/p/366912
<manuee> heheh bbiab
<Tak> that's what I'm doing, which may not be The Right Way
<Tak> err, remove that [0] from the first line
<dgoulet> i figure ;) i'm trying it real quick
<manuee> reading http://bazaar-vcs.org/BazaarForWebDevs atm--- it mentions to use the bzr-push-and-update plugin
<vxnick> manuee: only if you have a remote working tree, which you prob don't need
<manuee> ah right
<manuee> ye only my local box will be having vc
<manuee> thanks vxnick
<vxnick> no probs
<manuee> im tryin to just have a simple setup, im very new to vcs :X
<manuee> =)
<manuee> back to reading (getin excited)
<vxnick> manuee: have you made the repo on your local machine already?
<manuee> humm yes
<manuee> i ran bzr innit
<manuee> ignored everything but the custom code i want on vc
<manuee> and added what i wanted
<vxnick> committed?
<manuee> i committed the first yes
<manuee> i havent created a branch though
<manuee> not sure how that goes :X
<vxnick> do this:
<vxnick> check the manual for bzr push - this will upload your repo to your server. If you want to get a copy of it on other machines, you use bzr branch on the URL
<manuee> bzr info returns Standalone tree (format: pack-0.92)
<vxnick> so when you make changes in future, commit then push again (you don't need to specify the server details each time), then others can use bzr pull to grab your changes
<manuee> ok bzr help push --- reading...
<dgoulet> Tak: it's working very well!
<dgoulet> thanks a lot! I appreciate it!!
<Tak> np
<manuee> ow ok, bzr remove actualy deletes the files
<manuee> lol good go know
<vxnick> you can use --keep to keep them
<manuee> ah awesome
<manuee> im thinkin im only going to vc the theme for now
<vxnick> you may as well do the whole thing, makes life easier :)
<vxnick> and bzr revert should bring back those deleted files, if you want them
<manuee> ah heheh
<manuee> very handy
<manuee> ok moment of truth
<manuee> im using bzr push --creat-prefix sftp:/blabla --use-existing-dir
<manuee> i hope it puts things into its place :X
<vxnick> --use-existing-dir seems redundant as --create-prefix implies that you're pushing to a path that might not already exist
<vxnick> but don't worry about it
<manuee> i didnt use it the first time and it got me an error saying it doesnt have a valid .bzr directory
<vxnick> ah, ok
<manuee> "Created new branch."
<manuee> looks like it worked no?
<vxnick> you can test by branching it to another directory and making sure it pulls all the files
<manuee> humm k i dont understand the whole branching deal it looks like
<vxnick> branching means to copy the repository to another location
<sohail|laptop> getting a wierd problem. I can use putty to connect to my host but when I do bzr+ssh, I get bzr: ERROR: socket.error: Socket is closed
<sohail|laptop> the host that I am trying to bzr+ssh to is a mac
<manuee> hmmm k it isnt working
<manuee> i made a small change to a file to test, commited the change, ran bzr push, which looked ok, but the file didnt get updated on the server
<sohail|laptop> hmm, sftp works
<sohail|laptop> oh well
<vxnick> manuee: the files don't actually end up on the server, just the contents of .bzr
<manuee> ow
<manuee> humm so im missing a step then?
<vxnick> if you branch it though you'll see them :)
<vxnick> nope you've done it correctly
<vxnick> if you actually want the files to be uploaded to the server, look at the bzr-upload plugin
<manuee> ow ok
<manuee> thanks vxnick
<vxnick> no prob :)
<manuee> http://bazaar-vcs.org/BazaarUploadForWebDev =))
<manuee> "No uploaded revision id found, switching to full upload"
<vxnick> that's fine
<manuee> ah its cause its the first time right
<vxnick> yeah
<manuee> oki
<manuee> w00t its working
<manuee> i dont htink i actualy need to push anything right
<manuee> since im not versioning files over there
<vxnick> you don't need to push it if your'e the only one using the repo
<manuee> ah k, i think im starting to understand things
<manuee> so to remove what i did using push, i just delete the .bzr directory on the server, and all is like before there
<vxnick> yep
<manuee> its nice it only adds it at one location, cvs is crazy like that (which is what the drupal proyect is under sigh)
<vxnick> hehe
<manuee> i can barely get my head around cvs to maintain a couple of proyects i have on there
<manuee> everytime i have to look up the docs lol
<vxnick> luckily bzr is a lot simpler :)
<manuee> no doubt
<manuee> thanks a ton for your help & patience vxnick
<manuee> you helped a lot
<vxnick> a pleasure
<SamB> jelmer: so ... I pushed up some code to log SVN editor activity on lp:~naesten/bzr-svn/355143-replay/ ... I added it to PathStrippingDirectoryEditor and PathStrippingEditor. Not sure if that was the best place, thogh... what do you think?
 * SamB wonders how to set a PDB breakpoint in code he can't/shouldn't edit without using the PDB shell ...
<LarstiQ> SamB: edit code; import ipdb; ipdb.set_trace() ?
<SamB> LarstiQ: I hesitate to do that to a module in the globally-installed standard library ;-)
<LarstiQ> SamB: be fearless! ;)
<LarstiQ> SamB: how about starting it with the pdb command then?
<LarstiQ> you can set a break, and then continue
<SamB> I guess I could do that
<SamB> somehow I'd gotten it into my head that that would not work ;-)
<SamB> say, where is debugging of bzr documented?
<LarstiQ> SamB: HACKING I'd think
<LarstiQ> SamB: you're aware of BZR_PDB and C-\ ?
<SamB> LarstiQ: yeah
<SamB> but it might be a good idea to remind folks that they can still use plain-old pdb?
<LarstiQ> sure
<LarstiQ> and the import pdb; pdb.set_trace() routine
<SamB> LarstiQ: though the C-\ trick I picked up only by seeing sigquit listed somewhere related to BZR_PDB, and I think I found out that C-\ is the usual way to send one from wikipedia ...
<LarstiQ> SamB: doh
<SamB> maybe there should be an entry in the online help too?
<SamB> it could even just say to look in some particular other place, for all I care
<LarstiQ> SamB: it is mentioned in HACKING under Debugging
<LarstiQ> SamB: right, good idea
<SamB> oh, speaking of the online help ...
<SamB> https://bugs.launchpad.net/bzr/+bug/408983
<ubottu> Launchpad bug 408983 in bzr "need a "bzr apropos" command to search the topics available through "bzr help"" [Undecided,New]
<SamB> LarstiQ: does that not seem like a good idea?
<SamB> like, practically essential even?
<LarstiQ> SamB: not sure about essential, but I think it is a good idea too.
<jelmer> this is why I don't like the online help system in bzr, we basically end up implementing our own documentation reader in the end :-(
<SamB> jelmer: true
<LarstiQ> jelmer: I'm fine with hooking up with `info`
<jelmer> SamB: Thanks, I'll have a look
<jelmer> sorry for answering in the wrong order :-)
<SamB> jelmer: I'm not at all sure I've taken the right approach with that tracing, which is why I'm asking you to look at it
<SamB> the more I think about it, the more I feel like it might be better to create a set of wrapper classes that, when the flag is enabled, wrap around the actual editors for tracing purposes
<jelmer> SamB: right, that's what we do for transports
<jelmer> SamB: see MutteringTransport
<SamB> that was actually my first idea
<SamB> ;-)
<SamB> jelmer: so do you think I should go ahead and do that?
<SamB> jelmer: and if so, where should I put them?
<SamB> (and I really wish bzr had a concept of "interfaces", if only for documentation purposes ...)
<SamB> jelmer: hmm ... what module is that in?
<SamB> I found something a bit different-looking in bzrlib.transport.trace...
 * SamB wishes bzr selftest could abbreviate test names like 'bzrlib.plugins.' => 'bp.'
<SamB> hmm, would it be allowable for bzrlib to override unittest.TestResult._exc_info_to_string() ?
<jelmer> SamB: sure, just put them in fetch.py
<jelmer> SamB: technically, this is a subvertpy API
<SamB> jelmer: point
<SamB> I realized that pretty soon after mentioning that
<SamB> but, if bzr used interfaces as defined by some standard and/or popular third-party library, subvertpy could too, couldn't it?
<SamB> if only for documentation purposes?
<SamB> jelmer: hmm, is bzr-svn considered to have a public API?
<jelmer> SamB: other than the layout stuff, not really
<jelmer> SamB: also, subvertpy._ra.Editor documents the Editor interface (just committed)
 * SamB wishes one or the other of the python modes would highlight local variables somehow ...
<SamB> heck, even highlighting variables name and attribute names differently would be helpful ...
<SamB> jelmer: committed where exactly ?
<RenatoSilva> how to rename tags?
<SamB> doh. committed to subvertpy, duh ;-P ...
<fullermd> RenatoSilva: No way, the name _is_ the tag.  But you can make a new tag with a different name pointing at the same place.
<meuserj> The topic says that Launchpad is now open source... but I don't see anything about where to get it on launchpad.net...
<RenatoSilva> fullermd: ok
<beuno> meuserj, code.launchpad.net/launchpad
<meuserj> duh.. it make sense that they would host their own card.
<meuserj> err code
<RenatoSilva> is there a way to search for a text that was added or removed in some commit? I have a new line which introduced a bug, and I want to remove it, but before I want to know why that line was inserted. So I want to find the commit which inserted that change. Any idea?
<fullermd> annotate will tell you when a line was last changed (which may or may not be the insertion; you can step backward if it's not)
<fullermd> Removed is obviously harder.
<SamB> fullermd: I think he was hoping for a pickaxe
<SamB> which would be seriously usefull, really
<fullermd> I've got a splitting maul, is that close enough?
<SamB> probably not
<lifeless> RenatoSilva: bzr search can do that
<RenatoSilva> it's a plugin, right?
<lifeless> yes
<lifeless> however, gannotate is probably best
<RenatoSilva> is there a way to at least show a log including the diffs? Then I could use grep...
<lifeless> as it can step through full lines
<lifeless> log -p
<RenatoSilva> Yeah, I just read this in the help, thanks!
<RenatoSilva> lifeless: it was commit 1, and I discovered the reason it was added anyway..
<RenatoSilva> thanks
<SamB> jelmer: ... who is supposed to call close on an Editor ?
<jelmer> SamB: whoever is reporting the changes
<SamB> jelmer: well, I don't see it getting called on my tracing editors ...
<Noldorin> LarstiQ: heya
<Noldorin> LarstiQ: any news on the chmod issue?
#bzr 2009-08-08
<jfroy> bah!
<jfroy> bzr+ssh still doesn't support ~
<jfroy> :grumbles:
<jfroy> I thought a patch had landed back in 1.16 for that
<Noldorin> hrmm... does bzr still treat chmod failure as a fatal error?
<Noldorin> https://bugs.launchpad.net/bzr/+bug/190725
<ubottu> Launchpad bug 190725 in bzr "Bzr can't init branch on ntfs-3g filesystem" [Medium,Triaged]
<Noldorin> reading that, it would seem to
<lifeless> Noldorin: you could try https://bugs.edge.launchpad.net/bzr/+bug/190725/comments/8
<ubottu> Launchpad bug 190725 in bzr "Bzr can't init branch on ntfs-3g filesystem" [Medium,Triaged]
<lifeless> or https://bugs.edge.launchpad.net/bzr/+bug/190725/comments/12
<Noldorin> lifeless: i'll take a look, thanks.
<Noldorin> lifeless: i should mention that i'm not specifically using ntfs-3g
<Noldorin> sorry, wasn't clear on that
<Noldorin> i was just linking to a page that indicates that bzr fails wherever chmod isn't supported
<Noldorin> in my case, i'm just on a windows server that doesn't support chmod :(
<lifeless> Noldorin: Are you running bzr under linux though?
<Noldorin> lifeless: under windows. it shouldn't matter though, afaik
<lifeless> well, I thought perhaps we might not try to chmod at all, as much, on windows
<Noldorin> the fact that windows sever doesn't support chmod is fail though
<Noldorin> mm
<Noldorin> one sec, i'll paste my log
<Noldorin> lifeless: http://pastebin.ca/1521268
<Noldorin> i've already determined (with a bit of help) that this problem with the lock is due to my ftp server closing the connection after numerous failed commands
<Noldorin> so i really need to ask bzr not to make all the chmod requests
<lifeless> ok
<lifeless> please comment in that bug
<lifeless> you might like to go through the ftp.py file and just comment out chmod attempts
<Noldorin> yeah, when i mentioned this to one of the other guys here, he tried to go through the source and do that
<Noldorin> hrmm
<amanica> can one download a tarred copy of a mysql branch somewhere?
<amanica> (and zipped obviously)
<lifeless> amanica: I don't think so; it should stream pretty fast from lp
<amanica> I get them proxy errors
<lifeless> (zipping won't gain much/anything, because bzr data is highly compressed already)
<amanica> so I'm wondering if I have other options
<lifeless> what proxy errors
<amanica> (I realised that after typing that:)
<amanica> bzr: ERROR: Invalid http response for http://bazaar.launchpad.net/~mysql/mysql-server/mysql-6.0/.bzr/repository/packs/047014d22efa60da5232c19a239d4e65.pack: E
<amanica> xpected a boundary (squid/2.6.STABLE5:DF652E15CFBFB2B08FA0D5FF9B08286A) line, got ''
<lifeless> run bzr lp-login :)
<lifeless> then you'll use bzr+ssh to pull
<lifeless> it will be a lot faster
<lifeless> also upgrade your squid to a supported version
<lifeless> that one has numerous CVE's open on it
<amanica> o ok I'll try. I'm downloading from some server
<amanica> CVE ?
<amanica> o no I cant ssh out from that server. thats why I'm trying http
<lifeless> common vulnerablity entry
<lifeless> oh
<lifeless> well, if you fix your squid it will work
<amanica> bummer
<lifeless> may be a tad slow
<amanica> its not my squid to fix :(
<lifeless> current supported versions:
<lifeless> http://www.squid-cache.org/Versions/
<lifeless> (2.7.6 is what you'll want)
<lifeless> the problem is that squid had a bug with range requests that bzr found
<lifeless> you could wget it
<lifeless> wget -R http://bazaar.launchpad.net/~mysql/mysql-server/mysql-6.0/.bzr
<lifeless> /should/ work
<amanica> i tried something like that, will try your command now
<Noldorin> hrmm
<Noldorin> could anyone point me to a guide for building bazaar on windows please?
<Noldorin> (is there one?)
<lifeless> I'm sure its documented
<lifeless> either the wiki or in the docs
<lifeless> have you tried googling?
<Noldorin> can't seem to find it
<Noldorin> it's hidden quite well
<lifeless> http://bazaar-vcs.org/BzrWin32Installer
<lifeless> first hit for 'bzr win32 build' on google
<SamB> Noldorin: you already tried the obvious way ?
<Noldorin> :P
<Noldorin> lifeless: win32 makes all the difference
<Noldorin> enter windows and you'll get nothing useful
<lifeless> ah
<Noldorin> that's not terribly intuitive :S
<Noldorin> but thanks
<lifeless> windows is a very generic term :)
<SamB> that is, install an appropriate version of MSVC, run python setup.py build (with some wierd flag to tell it where MSVC is)
<Noldorin> lifeless: most software release under windows rather than win32 though :)
<Noldorin> since it's no longer 32-bit specific
<SamB> Noldorin: neither is win32
<lifeless> thats fair enough
<Noldorin> SamB: hmm
<SamB> ;-P
<Noldorin> why do i kneed MSVC?
<SamB> they just called it that to distinguish it from the 16-bit API
<Noldorin> yeah, which means it's even more confusing
<Noldorin> and less googlable for sure
<Noldorin> meh
<Noldorin> i have it now
<SamB> well, wikipedia thinks win32 is a *former* name
<SamB> I guess we could just deprecate 9x support and call it the NT port ;-P
<Noldorin> how about just Windows?
<Noldorin> heh
<SamB> Noldorin: too hard to google for
<Noldorin> SamB: are you kidding me? win32 made it hard to google for
<Noldorin> windows is what most people would naturally enter first
<Noldorin> *shrug*
<amanica> lifeless: your url ending in .bzr gives 404  and with it, it starts downloading a loggerhead page.
<SamB> I mean, there's way too much useless garbage with "windows" in it
<Noldorin> i know what you mean. but i'm sure you'd get "bzr window build" to the top of the results page
<Noldorin> windows*
<Noldorin> or "bzr windows setup"
<Noldorin> this is the current top result: https://code.launchpad.net/~sidnei/bzr/windows-build-environment
<Noldorin> meh
 * Noldorin reads the guide now
<lifeless> sidnei has been working on automated builds on windows
<lifeless> his stuff has been merged to bzr.dev
 * SamB tries adding a link to one of the existing top hits
 * SamB added a link near the bottom of http://bazaar-vcs.org/BzrOnPureWindows
<Noldorin> :)
<Noldorin> that should help
<lifeless> btw I have no idea if the page I linked is current
<lifeless> but it seemed accurate to me
<SamB> oh, I also picked it on http://www.google.com/search?q=bzr+windows+build
<SamB> does that move it higher in anyone else's results?
<Noldorin> 3rd down for me
<Noldorin> and it's about the installer rather than the build
<Noldorin> the http://bazaar-vcs.org/BzrWin32Installer should really havbe Build or Building in its title IMO
<SamB> Noldorin: yeah
<Noldorin> but yeah, should improve now that you added that link.
<Noldorin> oh lol. that page is all about building win32 installers on linux
<Noldorin> there's nothing for windows atually
<Noldorin> http://bazaar-vcs.org/BzrWin32Installer
<SamB> Noldorin: seriously?
<Noldorin> yeah
<Noldorin> i hadn't looked at it until just now
<SamB> I'd expect almost any tool that worked for that on Linux to work on Windows too ...
<Noldorin> well
<SamB> If you have all tools installed on your windows machine then with only one command you can build win32 installer for standalone bzr.exe:
<Noldorin> i guess i need to use the MSVC shell
<Noldorin> to get make and such
<SamB> oh, huh, you can use MinGW to build extensions for the standard win32 Python distribution now?
<SamB> neat
<Noldorin> heh
<SamB> anyway ... it sure looks like these instructions will *only* work on Windows
<Noldorin> SamB: why's that?
<SamB> or perhaps, if you are really lucky, under WINE
<Noldorin> there's no general "make" utility for windows
<SamB> Noldorin: it's called GNU make
<Noldorin> yeah
<SamB> lots of software needs that to build even on Windows
<Noldorin> but it's not standard
<Noldorin> MSVC is the standard, if there is one
<SamB> anyway, setup.py usually works
<Noldorin> hmm
<SamB> ... not saying it will work here, exactly
<lifeless> https://lists.ubuntu.com/archives/bazaar-commits/2009-July/013846.html seems relevant
<SamB> ... anyway, I don't know of any tools to cross-compile Python extension modules
<SamB> that's why I have doubts about the possibility of building a win32 installer on anything but a win32 system
<Noldorin> hmm
<Noldorin> you're probably right
<Noldorin> i just get the feeling that guide was not at all written by a windows guy
<SamB> well, the use of make seems odd even to me ...
<Noldorin> it's very much in the style of a linux guide
<SamB> not used to Python stuff using it
<Noldorin> assumes you know where to get everything :)
<Noldorin> (i.e. the package manager)
<Noldorin> heh
<Noldorin> get & setup, that is
<SamB> Noldorin: hmm, well, maybe it's more like they assume the names of the tools are more stable than their website URLs ;-)P
<SamB> actually, there are URLs
<Noldorin> SamB: maybe... though the URLs for the major tools should be fairly constant
<Noldorin> and can be updated easily enough
<Noldorin> yeah i noticed
<Noldorin> just not for everything
<Noldorin> like make :P
<SamB> well, maybe that one has changed before ;-)
<amanica> lifeless: I'm leaving it now overnight with nosmart+https  , maybe I'm lucky and it does not trigger the same problem. I'm giving up after that for now.
<SamB> it might especially hard to find a nice, stable URL for Windows builds of that
<amanica> anyway, I need to go sleep now.
<amanica> thanks for the help
<lifeless> amanica: I didnt thinkg b.l.n ran on https
<lifeless> but if it does \o/
<lifeless> the nosmart shouldn't be needed
<amanica> :(
<amanica> I'm desperate, so I'm just trying stuff
<amanica> b.l.n ?
<lifeless> bazaar.launchpad.net
<Noldorin> SamB: right, i think i've got it now. cheers
<Noldorin> probably encounter problems on the way though
<amanica> anyway. thanks and goodnight.
<Noldorin> SamB: i can't seem to find thet gnu make binaries. maybe my google fu is just really weak? :P
<Noldorin> not on the official website at least
<SamB> Noldorin: they wouldn't be
<SamB> I think GNU has a policy against that ;-P
<Noldorin> *sigh*
<Noldorin> ah
<Noldorin> interesting
<SamB> they
<Noldorin> would have been nice if they had stated that clearly though
<Noldorin> meh
<SamB> seem to have the mistaken belief that offering windows binaries could be construed as encouraging their use
<Noldorin> hehe
<lifeless> huh?
<lifeless> we offer windows binaries
<lifeless> can't have users on windows without doing that
<SamB> lifeless: GNU
<SamB> for make
<lifeless> oh
<lifeless> well, bzr is a GNU project too
<Noldorin> yeah
<Noldorin> but not officially gnu
<SamB> plus, I don't think GNU *has* any windows
<lifeless> I don't :)
<SamB> possibly, if ReactOS were more usable, they might be persuaded to create win32 binaries ;-P
<Noldorin> erm, i really just want to use mingw, don't i?
<SamB> Noldorin: probably ;-)
 * Noldorin loves how the python installers look like they were made for win95
<Noldorin> hrrmm
<Noldorin> seems like a need a module called  pywintypes
<Noldorin> not listed in the build pages though
<Noldorin> SamB: any ideas?
<SamB> you probably need pywin32
<SamB> or is it called win32all
<Noldorin> right
<Noldorin> you're right, it's pywin32
<Noldorin> lifeless: where's this ftp.py file?
<lifeless> bzrlib/transport/ftp/
<lifeless> it used to be one, its a module now
<lifeless> sorry, a package now
<Noldorin> hrm
<Noldorin> well yeah, i only see _gssapi.py and __init__py
<lifeless> __init__.py is the one
<Noldorin> lifeless: ok, cheers
<lifeless> _gssapi is for kerberos authentication
<Noldorin> i see
<Noldorin> lifeless: you seem to know a lot about this. do you hack with it often?
<lifeless> I'm one of the core bzr devs
<Noldorin> ooh, fair enough :)
<Noldorin> a bit more than hacking around, then, lol
 * sidnei raises an eyebrow
<sidnei> what? windows? bzr?
<Noldorin> i say this mainly because the guys i was talking to previously about this had only played around with the source code.
<Noldorin> sidnei: yeah, bzr
<Noldorin> sidnei: what was the raised eyebrow for? :P
<sidnei> Noldorin: what are you looking for? can i be of any help?
<Noldorin> sidnei: oh right, so it was an inquisitive one :)
<lifeless> sidnei: hi
<lifeless> sidnei: Noldorin wants to make a custom bzr build on windows
<Noldorin> sidnei: yes, possibly. i'm trying to kludge bzr into support a windows server without chmod
<lifeless> sidnei: and the wiki docs/user guide don't seem to document current practice for someone on windows doing this
<Noldorin> sidnei: excuse my ignorancve here. are you one of the main bzr devs too?
<lifeless> sidnei: so if you could - help noldorin out, and also update the docs, that would be rad
<Noldorin> lifeless: i've succeeded now actually :)
<Noldorin> well, it's not actually generating the installer, because it's complaing something about inno setup script
<lifeless> Noldorin: sidnei is a colleague of mine @ Canonical and has been helping bzr development out recently vis-a-vis windows daily builds
<Noldorin> but i've got the bzr.exe to play with
<Noldorin> lifeless: ah right, great.
<Noldorin> lifeless/sidnei: an update to the windows build guide would be great, though i've basically managed to get it working now.
<Noldorin> was just thinking it could be a tad clearer/more explicit in parts
<sidnei> Noldorin: i suspect that generally you are interested in building only bzr itself and not any of it's plugins, or am i wrong?
<Noldorin> sidnei: yeah, i just want to build the standard package.
<sidnei> Noldorin: oh, ok. that might be as easy as running 'python setup.py bdist_wininst' then
<Noldorin> erm, since you're here to help now, let me tell you the remaining issue then:
<Noldorin> sidnei: surely i needed gnu make/pywin32/cog/etc.?
<Noldorin> (installing them got things working pretty much)
<sidnei> Noldorin: gnu make and cog are needed for building the full installer, with all the plugins and tortoisebzr and all that
<sidnei> Noldorin: if you're going for the command-line only bzr.exe executable you don't need any of that
<Noldorin> sidnei: oh. well it would be nice to have tortoisebzr, since the version i'm building i'll need to use regularly
<Noldorin> python tools/win32/run_script.py cog.py -d -o tools/win32/bzr.iss tools/win32/bzr.iss.cog
<Noldorin> iscc /Q tools/win32/bzr.iss
<Noldorin> make: iscc: Command not found
<Noldorin> make: *** [installer] Error 127
<sidnei> Noldorin: oh, you got very far!
<sidnei> Noldorin: seems like you're only missing inno setup
<Noldorin> sidnei: heh, yeah. it's just the inno bit, as i said to lifeless
<Noldorin> mm
<sidnei> Noldorin: did you install it?
<Noldorin> i can actually run bzr.exe under win32_bzr.exe dir
<Noldorin> sidnei: yes.
<Noldorin> i'm running under mingw though, so i'm thinking i may havel to tell it something
<sidnei> Noldorin: so you need to add the inno setup dir to your %PATH% environment variable, so that it finds iscc.exe
<Noldorin> put it in the path perhaps?
<Noldorin> ^^
<sidnei> but, again, that's for building an installer, if you only want the bzr.exe, you already got what you need it seems
<Noldorin> might as well finish the process now. could be handy
<sidnei> Noldorin: indeed. we are looking for people to help in this area *wink wink nudge nudge*
<Noldorin> hmm. the bit about the path was in the docs. i'll blame it on the fact it's almost 3:00 am here for missing it?
<sidnei> Noldorin: eh. i would certainly miss that at 3am :)
<Noldorin> hehe
<Noldorin> sidnei: you're interested in getting the docs updated, you're saying?
<sidnei> Noldorin: for sure! let us know what parts are not clear. submitting a branch for review with updates to the docs gets you double points.
<Noldorin> sidnei: i'd be glad to do that :)
<Noldorin> i'll have a look at some point tomorrow
<Noldorin> so i can figure out which bits would still be unclear when i'm *awake*
<sidnei> eh
<sidnei> Noldorin: did you comment out the tortoisebzr bits? it requires msvc to compile. maybe the failure to build that is not being ignored?
<Noldorin> iscc /Q tools/win32/bzr.iss
<Noldorin> Inno Setup 5 Command-Line Compiler
<Noldorin> Copyright (C) 1997-2008 Jordan Russell. All rights reserved.
<Noldorin> Portions by Martijn Laan
<Noldorin> You may not specify more than one script filename.
<lifeless> sidnei: where are the docs
<lifeless> s/h//
<Noldorin> sidnei: nope. i have msvc installed though
<sidnei> Noldorin: ah, that explains it then.
<sidnei> lifeless: which docs more specifically?
<lifeless> sidnei: 'how to build on windows'
<sidnei> lifeless: we're working on that
<lifeless> :)
<sidnei> lifeless: what's missing more specifically is how to get the dependencies installed
<Noldorin> sidnei: any ideas about the "You may not specify more than one script filename." error?
<sidnei> lifeless: once the dependencies are in place its 'make installer-all'
<lifeless> sidnei: well, I'm meaning - where is that documented
<Noldorin> sidnei: agreed
<lifeless> even the make installer-all step
<sidnei> lifeless: its not. :( all there is is a bunch of comments in several setup.py files
<lifeless> ah!
<sidnei> lifeless: they need to be compiled into one document
<lifeless> sidnei: have you seen : http://bazaar-vcs.org/BzrWin32Installer
<sidnei> lifeless: basically the first time i did this i would open the setup.py file of the thing that failed and there was a comment explaining why
<sidnei> lifeless: uhm i hadn't found that before
<sidnei> lifeless: that could use some polishing, but seems like a good part of what's needed is in there
 * sidnei adds a bookmark
 * Noldorin will be idling here regularly, in case you'd like to discuss the build docs
<Noldorin> just let me know
<Noldorin> for now, i just want to get this inno setup erro sorted, followed by some rest. :P
<sidnei> Noldorin, lifeless: maybe bialix will beat me to updating the docs *wink*
<sidnei> Noldorin: soo
<sidnei> Noldorin: try removing the /Q
<Noldorin> heh
<Noldorin> right
<sidnei> Noldorin: any luck?
<Noldorin> sidnei: can't find it in the makefile. i assume that's the wrong place?
<sidnei> Noldorin: i mean, run that same command from the command line
<Noldorin> ok
<Noldorin> Error on line 50 in c:\users\alex\bzr\1.17\tools\win32\bzr.iss: No files found matching "c:\users\alex\bzr\1.17\win32_bzr.exe\msvc*.dll"
<Noldorin> Compile aborted.
<Noldorin> so it seems i'm missing the msvc dir from my path var?
<Noldorin> or someting else?
<sidnei> Noldorin: no, it should have been copied into that directory
<sidnei> Noldorin: by py2exe presumably
<Noldorin> hmm
<Noldorin> sidnei: you want the entire log?
<sidnei> Noldorin: that would help indeed. do you know how to redirect the output?
<sidnei> 'make installer-all 1>build.log 2>&1'
<Noldorin> sidnei: http://pastebin.ca/1521403
<sidnei> Noldorin: there's a py2exe.log around?
<Noldorin> yeah - http://pastebin.ca/1521407
<Noldorin> (i'm currently messing with the source code for ftp/__init__.py, trying to get get rid of all the chmod stuff)
<sidnei> Noldorin: oh, seems like you're building with python2.6
<Noldorin> but we'll leave that to another time :)
<sidnei> Noldorin: you should be using python2.5 i believe
<Noldorin> (that's the real issue. i just need to get bzr compiling nicely first of course)
<Noldorin> sidnei: ah
<sidnei> Noldorin: at least, i havent tried python2.6 myself
<Noldorin> how would thae make a difference with inno though?
<sidnei> Noldorin: no, it has nothing to do with inno. but might explain the missing msvc*.dll
<Noldorin> or is it to do with copying the msvc*.dll files?
<Noldorin> i see
<Noldorin> but the /q option needs to be removed, it would seem?
<sidnei> does it work if you remove it?
<Noldorin> (where is it specified?)
<Noldorin> no, it gives the previous error when i remove it:
<Noldorin> Error on line 50 in c:\users\alex\bzr\1.17\tools\win32\bzr.iss: No files found matching "c:\users\alex\bzr\1.17\win32_bzr.exe\msvc*.dll"
<sidnei> oh, ok
<Noldorin> if i leave it in, it gives:
<Noldorin> You may not specify more than one script filename
<sidnei> it's in build-installer.bat
<Noldorin> hm
<Noldorin> ok
<sidnei> but that's strange. maybe we are using a different version of inno than the on you installed
<sidnei> which version you're using?
<Noldorin> 5.2.3
<Noldorin> yeah, i was thinking that...
<Noldorin> sidnei: could we continue this tomorrow maybe?
<Noldorin> i'm eager to finish it off now, but i know it's far too late really! :/
<sidnei> Noldorin: i won't be around tomorrow, maybe monday?
<sidnei> Noldorin: if you see jam around, he can help too
<Noldorin> sidnei: ah, you're at canonical atm?
<sidnei> Noldorin: i work for canonical yes, but not on the bazaar project. i just happen to have an interest in the windows installer :)
<Noldorin> *thought you were based in the isle of man*
<Noldorin> guess you're somewhere in the US though
<Noldorin> ah, great :)
<sidnei> Noldorin: ah, no. southern brazil.
<Noldorin> well talk to you on monday
<lifeless> most of us work from home
<Noldorin> ah, lucky guys
<sidnei> :P
<Noldorin> am i wrong? :P
<sidnei> no!
<Noldorin> can't be too bad lol
<Noldorin> heh
<Noldorin> sidnei, lifeless: you've both been most helpful - thanks very much.
<Noldorin> we'll talk again soon
<Noldorin> maybe we can discuss how we might get around this CHMOD issue
<sidnei> i will be sprinting in curitiba next week with the landscape team, but i will keep an eye on irc if you're still in trouble
<Noldorin> lifeless: i guess that's something i'll want to talk about with you
<lifeless> Noldorin: sure
<Noldorin> sidnei: that's great, cheers. if you figure out what the inno setup-related prob is, i'd be glad to know :)
<Noldorin> ok
<Noldorin> thanks again.
<Noldorin> good night
<Noldorin> sidnei: erm, i'll probably just try reverting to python 2.5 though and seeing what that does
<Noldorin> meh
<Noldorin> bye
<lifeless> jml: around?
<SamB> geeze, isn't this more important than wishlist? https://bugs.launchpad.net/bugs/408983
<ubottu> Launchpad bug 408983 in bzr "need a "bzr apropos" command to search the topics available through "bzr help"" [Wishlist,Confirmed]
<GastonBorys> hi
<GastonBorys> i need help with bzr, how can i run bzr to use like daemon
<GastonBorys> i've this errro bzr: ERROR: Connection error: failed to connect to delphosproject.org:4155:
<lifeless> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#running-a-smart-server
<GastonBorys> thank u lifeless
<RenatoSilva> Are tags included in bzr send -o patch ?
<Noldorin> hey lifeless
<GastonBorys> morning
<GastonBorys> someone have a link to read how can i set authentication to bzr push?
<GastonBorys> we have a server with bazaar and redmine, we created a repositorie, works fine, but when i do bzr push sftp://user@host/path_to_branch bzr do not authenticate
<GastonBorys> i readed documentation find a authentication.conf file
<GastonBorys> but dont work
<GastonBorys> any idea?
<jelmer> GastonBorys: does the sftp command work?
<GastonBorys> jelmer: no, not work
<GastonBorys> i get this message: bzr push bzr+ssh://gaston@delphosproject.org/~/projects/sapphire
<GastonBorys> gaston@delphosproject.org's password:
<GastonBorys> Permission denied, please try again."
<GastonBorys> i readed, documentation, it say "Configure $HOME/.bazaar/authentication.conf"
<jelmer> GastonBorys: I mean, does the sftp command (unrelated to bzr) work ?
<GastonBorys> no
<jelmer> GastonBorys: bzr just uses ssh to log into remote machines using sftp/bzr+ssh
<GastonBorys> the idea is not create a ssh account for each developer or manteiner to upload changes
<GastonBorys> i thought, may be there was some way to authenticate outside ssh as i read the documentation of authentication.conf file
<GastonBorys> an internal bzr user, i running bazzar with serve --directory
<jelmer> GastonBorys: authentication.conf won't provide you with much help here
<jelmer> if you have a single account that all users log into then they should all also be able to use the sftp utility to log into that account
<GastonBorys> okey
<Noldorin> lifeless: ping?
<anka-ar> pff
<anka-ar> its an english channel?
<GastonBorys> anka-ar: yes
<anka-ar> ok
<GastonBorys> algunos hablan en espaÃ±ol pero me parece que no se puede por que beuno ayer se disculpo por el espaÃ±ol
<anka-ar> we need to upload a few packages to our redmine, and GastonBorys says me that the only way is using ssh?
<anka-ar> no way to use sftpÂ¡
<anka-ar> ?
<GastonBorys> anka-ar: this guys understand prefectly is not necesary to ask the same thing two times
<Noldorin> hrrm.. trying to build the bzr installer for windows here
<Noldorin> make seems to be complaining though
<Noldorin> error: Python was built with Visual Studio 2003;
<Noldorin> extensions must be built with a compiler than can generate compatible binaries
<Noldorin> Visual Studio 2003 was not found on this system. If you have Cygwin installed,
<Noldorin> you can try compiling with MingW32, by passing "-c mingw32" to setup.py.
<Noldorin> passing -c mingw32 makes it complain that "mingw32" is not an option thuogh
<Noldorin> hello. i'm getting the following error trying "make installer" on windows
<Noldorin> c:\MinGW\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: cannot find -lzdll
<Noldorin> collect2: ld returned 1 exit status
<Noldorin> my environment is configured correctly i believe
<Noldorin> any ideas?
<SamB> jelmer: sooo ... svn replays seem to like to issue file_opens when the file never existed before ...
<bialix> garyvdm: hi
<bialix> any ideas on Bug #410580
<ubottu> Launchpad bug 410580 in qbzr "qcommit/qadd/qrevert files view: hide/remove extra columns and make the filename column wider" [High,Confirmed] https://launchpad.net/bugs/410580
<jelmer> SamB: it does file opens with base revisions that we don't necessarily have
<bialix> hi jelmer
<bialix> what's new with bzr-git?
<jelmer> bialix: hi
<jelmer> bialix: not much
<jelmer> have you had a chance to try it again on windows?
<bialix> nope
<bialix> maybe later this month
<bialix> I was under too much work
<bialix> does garyvdm was here earlier?
<jelmer> I haven't seen him
<bialix> k
<garyvdm> Hi bialix
<garyvdm> Taking a look
<bialix> hi garyvdm
<garyvdm> bailix: is it a recent regression?
<garyvdm> I think it is a qt windows bug - I'm not seeing it on ubuntu - But I think it is due to a change in the most recent revision
<bialix> I don't know
<bialix> I'm not sure I saw it at my work computer
<garyvdm> Ok - let me boot into windows.
<bialix> but see it on my home laptop
 * bialix waiting for gary
 * bialix reads irclogs
<bialix> Gha! They called me "not at all windows guy"!
<bialix> me?
<bialix> funny
<bialix> garyvdm: it's regression in revno 870
<bialix> Noldorin, SamB: I've updated URL to GNU Make
<Noldorin> :)
<garyvdm> bialix: Yes - It was due to a qt4.4 bug that I forgot about. I was able to reproduce and I've fixed it now.
<bialix> Noldorin, SamB: I've surprised by your definition "that guide was not at all written by a windows guy"
<Noldorin> bialix: you wrote it?
<bialix> yep
<Noldorin> bialix: and you're a windows guy mainly, i take it
<Noldorin> heh
<Noldorin> so i was wrong :)
<bialix> I follow te Joel idea of one-push build
<Noldorin> bialix: are you going to be updating the guide soon perhaps?
<garyvdm> bialix: I'm also a avid JOS reader!
<Noldorin> i would be happy to give you some suggestions
<Noldorin> if you'll take them
 * Noldorin has heard far too much about the joel test
<Noldorin> there's a question on it on stackoverflow every day ;)
<bialix> garyvdm: :-)
<bialix> Noldorin: this guide is not quite full
<bialix> now installers are building by Jogn Meinel (jam here)
<Noldorin> yeah
<bialix> sorry
<Noldorin> can i give you suggestions perhaps?
<bialix> John Meinle
<Noldorin> with my experience though?
<Noldorin> so you can maybe update it
<bialix> SORRY!
<bialix> Noldorin: it's a wiki
<bialix> you can update it too
<bialix> all you need is lp acount
<bialix> but yes, fell free to give suggestions
<bialix> I'm still curious
<Noldorin> hehe ok
<Noldorin> i would do it myself...
<Noldorin> but i'm kind of busy
<Noldorin> anyway..
<Noldorin> first thing is
<bialix> garyvdm: what's qt bug?
<garyvdm> bialix: I have tonight, tomorrow, and Monday(South African Holiday) to work on qbzr - So I'm going to go through the merge requests, see if there are any bugs to fix
<garyvdm> bialix: It's in the comments in the code.
<bialix> don't approve qexport please
<bialix> I have some comments on it
<garyvdm> ok
<bialix> javier is not here?
<garyvdm> I want to see if I can fix bug 395937 and bug 395817
<ubottu> Launchpad bug 395937 in qbzr "qannotate: Crash when opening qbzr/lib/log.py annotate from qbrowse" [High,Confirmed] https://launchpad.net/bugs/395937
<ubottu> Launchpad bug 395817 in qbzr "qbzr and bzr-pipeline not compatible." [Medium,New] https://launchpad.net/bugs/395817
<bialix> garyvdm: I have several questions/ideas about future of qbzr
<lifeless> Noldorin: hi?
<bialix> can we talk now
<bialix> ?
<lifeless> Noldorin: I'm in a different time zone to you I think :)
<garyvdm> bialix: Now is a good time
<bialix> 1) I'm thinking about launching dedicated site for qbzr
<bialix> I've checked qbzr.org is free
<bialix> I can buy this domain and can buy the hosting
<bialix> but it will be most likely hosting in UA zone
<bialix> if it's bad, then I'd need some suggestions
<bialix> also this site will be mostly static
<bialix> and I'm not web dev guy
<garyvdm> What would that give us that some sub pages on bazaar-vcs.org does not?
<bialix> so if you have (or will have) some ideas -- it's will be nice to hear
<bialix> garyvdm: I'm not sure about bazaar-vcs
<bialix> I've heard poolie want to get rid of wiki there
<Noldorin> lifeless: hi there
<bialix> maybe I'm wrong
<Noldorin> yeah, i suspected so :)
<Noldorin> just thought i'd try earlier anyway
<Noldorin> lifeless: are you also in brazil?
<bialix> garyvdm: so first item is the site: do we need it and how?
<garyvdm> bialix: I know that they (headed by emmajane) are in the process of update bazaar-vcs.org
<bialix> garyvdm: second item: I'd like to have some logo for qbzr
<bialix> garyvdm: I'm thinking about it too long (> 1 year now)
<bialix> garyvdm: I have in mind something based on sun or sunflower with Q letter in/on it
<bialix> garyvdm: yeah, I saw Emma's mails
<garyvdm> bialix: I don't think that having a separate site would give us any pros
<lifeless> Noldorin: nope
<lifeless> australia
<bialix> garyvdm: currently we have only one page http://bazaar-vcs.org/QBzr
<bialix> garyvdm: we can keep it as redirection point
<bialix> garyvdm: what's cons here?
<garyvdm> cost, effort required.
<garyvdm> We do need to put some effort into getting screen shots updated.
<Noldorin> lifeless: ahh right, that explains
<bialix> garyvdm: yes
<Noldorin> lifeless: it must be said...you gave us a thrashing today at headingley :P
<bialix> garyvdm: will be nice to get new screenshots more regularly
<garyvdm> Advocacy - manly by publishing tips and tricks using qbzr
<bialix> garyvdm: cost -- I have some money I can spent on this
<garyvdm> Lots of people are not aware of new features that are available.
<lifeless> Noldorin: :)
<Noldorin> lifeless: i can only assume you're a cricket fan.
<Noldorin> lifeless: no-one in australia isn't afaik!
<bialix> garyvdm: in my evil plan we persuade igc to write some sexy docs for qbzr
<Noldorin> lifeless: we'll come back in the final test though, don't worry
<Noldorin> right, enough off-topic talk now
<garyvdm> bialix: That would be cool. I still don't think that a separate site is needed.
<bialix> garyvdm: I'd prefer to use restructured text instead of wiki markup for the site/docs
<bialix> so I can edit the site pages offline, commit with bzr and upload to the site with bzr
<garyvdm> +1 for using bzr to version the doc/site.
<bialix> garyvdm: using bzr-vcs.org now is possible but not so easy
<Noldorin> lifeless: ping?
<garyvdm> bialix: I don't mind either markup lang.
<bialix> garyvdm: all my personal sites made with rst + bzr
<garyvdm> bialix: re: Icon - I just want to go read up on a old mail.
<bialix> I'm not sure there was big discussion about it
<bialix> but maybe I forgot
<Noldorin> lifeless: so i've managed to get the installer compiling well now :)
<bialix> in the past luks said he don't like the QBzr as name
<bialix> garyvdm: but for me it's not Qt Bzr but Qool Bzr
<bialix> can we made it unofficial motto?
<garyvdm> ;-)
<bialix> :-)
<bialix> Noldorin: cool
<amanica1>  qool
<bialix> hi amanica1
<amanica1> hi
<bialix> good to see you again
<amanica1> yup you too
<Noldorin> bialix: yeah, it required a bit of hacking around, but not too much. i'll tell you what i need to do in a min, sorry
<Noldorin> just waiting to see if lifeless is around still
<garyvdm> Hi amanica1.
<amanica1> hi gary
<bialix> Noldorin: you can send the mail, either to bzr ML or Bzr-Windows ML
<garyvdm> bialix: the subject of the mail I was interested in is "[qbzr] Don't put QBzr in the title bar of a window"
<garyvdm> bialix: I can't find it in the Google Groups interface :-(
<Noldorin> bialix: ok, i might just do that
<bialix> garyvdm: ah
 * bialix looks
<Noldorin> bialix: most of your instructions you wrote were very clear btw. just a few points that were slightly different for me.
<Noldorin> bialix: so thanks a lot - it was a big help to me.
<amanica1> garyvdm: btw. that mysql copy didn't work out for me. I forgot that flashdrive is fat32, and that repository got corupted :(
<bialix> garyvdm: discussion started 18/08/2008
<garyvdm> bialix: yes
<garyvdm> amanica1: :-( - why did the repo corrupt?
<Noldorin> lifeless: are you there still?
<lifeless> yes
<lifeless> thats excellent
<Noldorin> right, now onto the errors i'm getting trying to hack the ftp module
<garyvdm> bialix: I feel that as qbzr is just a interface to bazaar - it should be branded as bazaar - and as such - should use the bzr icon, and name.
<bialix> garyvdm: http://groups.google.com/group/qbzr/browse_thread/thread/68f9c6a13857a27b#
<Noldorin> lifeless: i commented out the following line in ftp/__init__.py: ftp.sendcmd(cmd)
<SamB> bialix: I didn't say you weren't one, exactly
<garyvdm> bialix: as luks said, maybe that is a bit bold.
<Noldorin> and that gets rid of the warnings
<SamB> I might have accidentally agreed with what someone else had said ...
<Noldorin> nonetheless...
<Noldorin> the problem with the repo lock still exists
<bialix> SamB: but you surprised by make
<SamB> bialix: a bit!
<lifeless> Noldorin: uhm, the repo may still be locked from your prior experiment?
<SamB> I guess it's actually necessary ?
<garyvdm> bialix: I see we did take QBzr out the titles.
<Noldorin> lifeless: i'm deleting the push directory manually via FTP each time before i test
<Noldorin> http://pastebin.ca/1522288
<Noldorin> that's what i'm getting still
<SamB> mightn't not calling it "qbzr" make for confusing bug reports ?
<bialix> garyvdm: I second who think it's too bold
<garyvdm> SamB: Yes
<bialix> SamB: np, but it as funny
<lifeless> Noldorin: have you run bzr break-lock ftp://alexreg-repos@213.175.198.12/olivaw-bot ?
<bialix> garyvdm: I'm not talking about icon in the title bar actually
<Noldorin> lifeless: yeah, it just automatically relocks
<bialix> garyvdm: I'm Ok to keep using bzr.ico
<Noldorin> erm
<Noldorin> let me paste you the message
<SamB> bialix: I typically expect that Makefiles for python projects are just wrappers to deal with *nix-hacker reflexes
<amanica1> garyvdm, I dont know why. I copied it and some comands failed. then reconsile gave errors. I'll try a little more now to resurect it.
<bialix> garyvdm: keep using bzr.ico for the title
<bialix> SamB: well, it's not quite true
<garyvdm> SamB: We have a separate error report. That currently points to bugs.lp.net/bzr/+filebug - I'm going to change that to bugs.lp.net/qbzr/+filebug now.
<Noldorin> lifeless: it shouldn't be locking anything on a clean push anyway! the guy i spoke to a few days ago thought it was caused by my ftp server dropping the conn suddenly
<bialix> SamB: but it was indeed was written in such way to simplify review process for the rest of bzr team who is hardcore linux hackers
<SamB> garyvdm: I guess it shouldn't be too much of a burden to shunt the core problems back to core
<bialix> SamB, garyvdm: the problem now that QBzr is a library now
<lifeless> Noldorin: it has to lock during push; that its locking the repo is a little odd, as we do that very late in the process
<lifeless> Noldorin: what does 'bzr info -v ftp://alexreg-repos@213.175.198.12/olivaw-bot' show?
<bialix> SamB, garyvdm: it's used in several other projects
<Noldorin> lifeless: ah right... yes, i was wondering why it was only locking part way through
<Noldorin> erm
<SamB> bialix: oh
<garyvdm> bialix: Ok - I see. Basically for the website, and the about page? (Oh - we don't have one of those.)
<lifeless> Noldorin: we lock to insert the prepared pack
<bialix> garyvdm: yes, branding for the project and site
<lifeless> there is a file - pack-names - that we have to atomically update
<garyvdm> bialix: I think that it would be nice to have, but not very important.
<bialix> garyvdm: it's just my long standing itch
<bialix> garyvdm: 3rd: qbzr 1.0 (again)
<bialix> garyvdm: I remember your position about qmain
<bialix> garyvdm: but may be I can persuade you to change your mind
<garyvdm> now that we have bzr-explorer
<bialix> garyvdm: and don't tie qbzr 1.0 to qmain
<garyvdm> I'm not sure.
<Noldorin> lifeless: here you go. http://pastebin.ca/1522300
<bialix> garyvdm: I feel there is too much things we want to implement, and there is only 2 active developers
<bialix> garyvdm: and you even more active than me
<bialix> garyvdm: I'm just fear qmain takes too long
<Noldorin> lifeless: interestingly, break-lock seems to work now
<garyvdm> and the ideas come in faster that we can get them out :-(
<Noldorin> lifeless: now that i've disabled the chmod sending
<bialix> garyvdm: yeah :-?
<bialix> it's good and bad
<bialix> garyvdm: as I said:qbzr is not just standalone product now
<lifeless> Noldorin: so, I'm not sure what could be going on; the lock appears to be you
<bialix> it's a library that used in bzr-explorer, TBZR, qbzr-eclipse
<Noldorin> lifeless: trying to push again, i get this: http://pastebin.com/m3b40d2c8
<Noldorin> lifeless: hrmm, yeah. no idea why it's being cause
<lifeless> and we should be only locking once; so even if it does make us reconnect, we should be doing that wknowing the lock
<Noldorin> caused*
<Noldorin> lifeless: would it be helpful to run bzr in verbose mode perchance?
<Noldorin> lifeless: i take it there is one.
<lifeless> Noldorin: -Dtransport
<lifeless> will log more stuff to the log about transports
<Noldorin> ok
<lifeless> is this a test repo?
<Noldorin> lifeless: from a clean ftp parent dir?
<Noldorin> lifeless: nope.
<lifeless> or do you have important stuff in it already?
<Noldorin> well, i have real project work in my local repo
<garyvdm> bialix: Do you feel that calling the next release 1.0 will result in more contributions?
<lifeless> ok, can you remove it[on the ftp server], and try from new?
<bialix> garyvdm: not really
<Noldorin> lifeless: yeah, that's what i've been doing so far
<ethana2> Anyone else here use bzr to keep track of communally developed song lyrics?
<bialix> garyvdm: actually I think if people want to help, they just help regardless of numbers
<ethana2> ...and the resulting vocal tracks?
<lifeless> Noldorin: oh, you didn't tell me that :)
<garyvdm> bialix: Do you feel that calling the next release 1.0 will result in more users?
<lifeless> Noldorin: try this please - remove the repo on the ftp server
<bialix> garyvdm: I'm a bit sad on this
<lifeless> run 'bzr init ftp://...'
<lifeless> then 'bzr info -v ftp://...'
<Noldorin> lifeless: yeah, sorry. i might have told the other guy (forget his nick) about that :)
<Noldorin> ok
<bialix> garyvdm: perhaps
<Noldorin> will do
<Noldorin> lifeless: no more info with -Dtransport btw
<bialix> garyvdm: I feel that we need to thinking about better support of per-file commit messages (MySql)
<bialix> garyvdm: so we can match bzr-gtk on this field
<garyvdm> Yes
<bialix> but for commit we need to get some improvements in bzr core first
<Noldorin> lifeless: success with init: Created a standalone branch (format: pack-0.92)
<garyvdm> bialix: I don't think that we should feel sad! We have made some excellent tools.
<bialix> garyvdm: dedicated site + optional logo => the road for 1.0 and more users, yes
<Noldorin> lifeless: info: http://pastebin.com/m2e72917c
<bialix> garyvdm: we still have a lot of room on Mac
<garyvdm> bialix: yes
<bialix> garyvdm: it's shameless question: if you will have a Mac, will you make some mac-specific improvements?
<ethana2> bash: bzr+ssh://login@bazaar.launchpad.net/~ethana2/ubuntusong/branch: No such file or directory
<garyvdm> Of course.
<bialix> garyvdm: maybe if we asking the community, I hope somebody will help
<ethana2> I'm trying to create a bzr branch in launchpad
<ethana2> but I don't really know what I'm doing, at all
<ethana2> I just installed bzr on this machine
<lifeless> #
<lifeless> Lock status:
<lifeless> #
<lifeless>         branch: locked
<ethana2> oh wait, I did it wrong
<bialix> ethana2: read tutorial on using bzr + lp
<lifeless> Noldorin: ^ thats the problem
<lifeless> or a refined version of it
<Noldorin> lifeless: yeah, i suspected so
<garyvdm> bialix: I'm not sure about the version number. I don't feel strongly either way.
<Noldorin> hrmm
<Noldorin> any ideas as to the cause?
<ethana2> bash: bzr+ssh://ethana2@bazaar.launchpad.net/~ethana2/ubuntusong/trunk: No such file or directory
<lifeless> Noldorin: so, if you ran that with -Dtransport we can check that you did send commands to remove the lock
<Noldorin> i wouldn't be surprised if it's just due to my ftp server acting strangely :)
<Noldorin> :P*
<lifeless> s/you/your computer/
<ethana2> bialix: link?
<lifeless> and if you did, and the file is still there on the server, then the ftp server is acting wildly stangely
<garyvdm> bialix: I just want to keep things ticking on - all ways getting better.
<ethana2> bialix: I'm trying to figure out ov
<ethana2> bialix: I'm trying to figure out https://help.launchpad.net/CreatingAHostedBranch
<bialix> garyvdm: well, it's just a number in the end. but releasing 1.x is a bit nicely than 0.xx year by year
<Noldorin> lifeless: run what with -Dtransport now?
<bialix> ethana2: http://doc.bazaar-vcs.org/latest/en/tutorials/using_bazaar_with_launchpad.html
<garyvdm> bialix: If it's going to encourage you, lets do it!
<garyvdm> bialix: Decided! :-)
<bialix> garyvdm: :-/
<lifeless> Noldorin: bzr -Dtransport init ...
<lifeless> (remove the repo first, again)
<Noldorin> yeah, of course
<Noldorin> right
<bialix> garyvdm: so I'm starting to work on the site
<lifeless> then look in your bzr.log
<lifeless> bzr --version will list the path to the log
<garyvdm> bialix: Cool. I'm going to do some coding now.
<bialix> garyvdm: maybe good site + some docs will attract more devs (and users of course)
<bialix> garyvdm: ok
<Noldorin> lifeless: not bzr info this time?
<bialix> garyvdm: will be nice if you'll help with news for 0.13
<lifeless> Noldorin: no need
<Noldorin> ok
<bialix> garyvdm: tomorrow is ok
<garyvdm> bialix: Sure - So is it ok if I do the release on Monday?
<lifeless> after I get the transport log, I'll get you to check via info -v that it is infact still locked. But the debugging bit is the init.
<bialix> garyvdm: yes, but maybe we need to inform the igc about it
<bialix> garyvdm: he want to release explorer after/in sync with us
<garyvdm> bialix: Or do we want it out before poolie does the release for bzr?
<bialix> garyvdm: anyway jam will build installer later
<bialix> garyvdm: np here
<Noldorin> lifeless: hrmm, nothing in the log about the repo i'm working with
<garyvdm> bialix: Ok - I'm going to put that in a mail now.
<bialix> garyvdm: I'm also have some questions about qbzr slowness, but it can wait couple of days
<Noldorin> lifeless: never mind, it's just that tbzr stuff is mixed in with it
<garyvdm> bialix: Lastnight I fixed some qcommit slowness.
<bialix> garyvdm: thanks for the chat, I'm going to sleep now. bye
<Noldorin> lifeless: http://pastebin.ca/1522319
<bialix> garyvdm: qdiff is bother me too
<bialix> gnight all
<garyvdm> bialix: Thanks for the chat! Bye
<lifeless> Noldorin: on the server, can you get a recursive listing of olivaw-bot/.bzr/branch-lock ?
<lifeless> and of
<lifeless> olivaw-bot/.bzr/branch/lock
<Noldorin> ok
<Noldorin> lifeless: nothing in either of those dirs
<lifeless> they are empty?
<lifeless> does bzr info -v show the branch or repo as locked?
<Noldorin> lifeless: nope, no locks
<Noldorin> i just did a bzr init
<Noldorin> so i'd hope not :P
<garyvdm> amanica1: If you want, I'll write it to a CD, and drop it of for you.
<lifeless> Noldorin: well, you just did an init before, and it did leave a lock
<lifeless> Noldorin: I am about to go out - it is sunday here :)
<lifeless> Noldorin: could you - file a bug; attach your patch, summarise what we've learnt
<lifeless> I suspect a push to the repo as it is now will work
<Noldorin> lifeless: heh, fair enough.
<Noldorin> will do
<Noldorin> lifeless: i don't really have a patch though
<lifeless> but we don't have a reason for why it sometimes doesn't unlock
<Noldorin> except for commenting out one line
<lifeless> thats true
<ethana2> AHA!  Got it!  Thanks, guys!
<lifeless> but it means folk debugging can see what you've changed ;)
<Noldorin> alright
<Noldorin> well thanks for the help :)
<Noldorin> talk to you later
<Noldorin> lifeless: yeah, the push succeeded btw
<Noldorin> quite odd
<ethana2> I modified a file in my project directory, but bzr won't push it because it says nothing was modified
<ethana2> ..but launchpad still has the old version of the file
<LarstiQ> ethana2: did you commit it?
<ethana2> LarstiQ: oh, guess not
<ethana2> bzr: ERROR: Path(s) are not versioned: "Remove old song lyrics"
<LarstiQ> ethana2: -m
<SamB> how do I specifically create a non-stacked branch?
<SamB> with push
<LarstiQ> SamB: to launchpad?
<SamB> LarstiQ: yeah
<ethana2> oh whoops, deleted the wrong file
<LarstiQ> SamB: you don't I think, ref a bug about wanting ui to force that
<SamB> LarstiQ: ref?
<LarstiQ> SamB: reference/see
<LarstiQ> there is one filed
<SamB> uh huh
<SamB> it would sure be nice to know what the number was!
<LarstiQ> I'm not going to trawl up my mail at this point
<LarstiQ> SamB: just ircing till my battery runs out, sorru :p
<SamB> ah
<SamB> wish I had an IRC-capable machine with a battery
<LarstiQ> at 1600mAh it's not that great
<LarstiQ> 6 more minutes now actually
<SamB> what sort of device is it?
<amanica1> garyvdm: thanks. I'll see if I can fix it first. I tried to download it from work but a bug in our proxy breaks bzr over http:// and ssh-ing out is blocked.
<amanica1> mm. maybe I'll try ftp
<garyvdm> ok
<amanica1> garyvdm: I can't expect you to drive that far
<amanica1> and I'm not that desperate yet
<amanica1> I mean I dont need it that badly
<garyvdm> I'm working in Morningside now, so It's not to far.
<amanica1> ah ok
<garyvdm> Drop me a mail if you change your mind....
<amanica1> thx
<amanica1> garyvdm: so how is the new job?
<amanica1> working in daytime now?
<garyvdm> Yhea
<garyvdm> And I have weekends, and..... public holidays!!!! off!!!!
<LarstiQ> SamB: Acer Aspire One
<garyvdm> Work is cool - just doing some simple web dev.
<amanica1> garyvdm: sweet
<ethana2> ok, so I've been trying to figure out bzr and have been royally screwing up a bzr branch with basically nothing in it
<ethana2> how do I wipe it out and start over?
<ethana2> it had one small file and I went to change the file, but then I deleted it because I forgot the ~ when I went to delete that other file gedit always makes when you change a file
<ethana2> ..but then I committed that and pushed it and now it says the file is locked and I went to killall bzr but that didn't help and the system monitor says the file /isn't/ locked
<ethana2> and the change I made to the file really is outside of the scope of its development, just some stuff I forgot before uploading it
<ethana2> so I've got the file I want now, and I want to upload it to launchpad as the initial commit
<ethana2> brb
 * ethana2 restarts machines
<ethana2> ok there we go, branch deleted
<wgrant> ethana2: In future, 'bzr break-lock' is your friend.
<wgrant> (as the message bzr gave you says)
<ethana2> wgrant: I tried that but it said it couldn't
<ethana2> when I closed the terminal it said some other thing was stopped though
<wgrant> ethana2: It would have said something more descriptive than that.
<ethana2> wgrant: yeah
<ethana2> it said the file was being modified or in use or something
<ethana2> so it couldn't unlock it
<ethana2> but it wasn't that I could tell, and neither was it according to the system monitor
<ethana2> ok got it
<ethana2> so, you log your bzr into launchpad, then you change the file, then commit the file, then push
<ethana2> I guess that's simple enough
<ethana2> apt says bzr-gtk is installed, but I can't run it using its name
<ethana2> 'olive-gtk'
<ethana2> well, rock on guys, I'll leave you alone now
#bzr 2009-08-09
<SamB> how does one delete files using sftp?
<wgrant> SamB: Which client? I use lftp, which works fine.
<SamB> well, I'd really like a one-liner to do it from the shell ...
<wgrant> You could probably do that with lftp, but there's also probably a better way.
<SamB> hmm, pushing to 2a over smart-server involves an awful lot of Repository.get_parent_map calls ...
<SamB> at least, it does when you have thousands of revs to push
 * SamB tries again with trunk ...
<SamB> wow, 2a repacks are amazingly stupid when done remotely ...
<SamB> first, it evidently readv's each revision one-by-one
<SamB> then (at the same time?) it does the repack locally ...
<lifeless> SamB: smart server should repack remotely
<lifeless> SamB: unless you ran 'bzr pack url' - don't do that.
<SamB> lifeless: I don't!
<SamB> lifeless: so, either launchpad's bzr is dumb, or bzr.dev is ...
<lifeless> SamB: file a bug with what happened then
<lifeless> include your .bzr.log contents for the event
<SamB> lifeless: duh
<SamB> that's the only place I can see the issue ;-)
 * SamB makes sure nobody else has reported one like that ...
<SamB> lifeless: are we still tagging these brisbane-core ?
<lifeless> doesn't matter
<lifeless> I'll look at it on monday :)
 * lifeless is gone
<SamB> https://bugs.edge.launchpad.net/bzr/+bug/410917 if anyone cares
<ubottu> Launchpad bug 410917 in bzr "inter-format push to remote 2a branch does packing on local end" [Undecided,New]
<bialix> garyvdm :-)
<garyvdm> Hi bialix
<bialix> hi Gary
 * bialix reviews qexport
<bialix> garyvdm: nice exception reporter for validate method
 * bialix reviews qunbind
<bialix> garyvdm: do you know what's jam want to achieve in his branch: https://code.launchpad.net/~jameinel/qbzr/progress ?
<garyvdm> bialix: If we call methods that provide progress information, it displays it.
<garyvdm> E.g. Annotate
<bialix> ah, ok
<bialix> it's not finished yet?
<garyvdm> It works - but I think we need to try do some formatting on the messages that it prints.
<garyvdm> may be "Loading: %s" % message
<bialix> ok, so when jam will be ready (after bzr release) we can ping it
<bialix> garyvdm: what you think about https://bugs.launchpad.net/qbzr/+bug/406794
<ubottu> Launchpad bug 406794 in qbzr "qlog shows error dialog when using * in search dialog when filtering on "Bugs"" [High,Confirmed]
<bialix> it looks easy to fix
<garyvdm> And I need to get qlog to show progress information like viz :-)
<bialix> Gary, I don't know how viz works
<bialix> never saw it in action
<garyvdm> re: 406794 - I'll have to look at it.
<bialix> what if we using fnmatch here instead of regexp?
<bialix> so * will work
<bialix> and something like 410??? will work too
<bialix> or 410*
<garyvdm> I don't know  - never used fnmatch.
<bialix> it can translate glob wildcards into regexp
<bialix> so you can write *.png to match filenames
<bialix> do you get the idea?
<bialix> shell patterns
<bialix> try: python -c "import fnmatch; help(fnmatch)"
<garyvdm> Ok - That sound cool
<bialix> I'll fix it then
<garyvdm> Errors from qbzr now point to https://bugs.launchpad.net/qbzr/+filebug and errors from bzr-explorer now point to https://bugs.launchpad.net/bzr-explorer/+filebug :-)
<bialix> nice
<bialix> garyvdm: look at http://paste.ubuntu.com/250209/
<bialix> I wrote docstring. Is everything correct here?
<garyvdm> Looks - good. You just missed how it searches for tags.
<bialix> For message, author and tag it's used as regexp to search in corresponding metadata
<bialix> it's not very clear?
<garyvdm> Oh - sorry - my mistake
<garyvdm> I think that we should also use glob wildcards for every thing.
<bialix> I don't use it very often
<bialix> I have no opinion here
<bialix> but it's possible
<bialix> you want this?
<garyvdm> I've never used re's when searching. And I think that glob wildcards will make it more accessible.
<bialix> what syntax bzr-search used?
<garyvdm> bialix: No wild cards
<bialix> so, I need to use fnmatch for everything except index, rigt?
<garyvdm> right
<garyvdm> I've allways wanted to add the ability to use wild cards when using bzr-search  in qlog
<bialix> and if people start whine about regex we get them back
<garyvdm> Yhea
<lifeless> so
<bialix> I'll update docstring accordingly
<bialix> hai lifeless
<lifeless> you can lookup all possible matches for the wildcard in the index metadata
<lifeless> and then search for all of the resulting things
<garyvdm> lifeless: Yes - thats what I planed to do.
<lifeless> cool
<garyvdm> lifeless - I can also make it not case sensitive that way.
<bialix> garyvdm: new version of docstring: http://paste.ubuntu.com/250216/
<garyvdm> bialix: great!
<bialix> ok
<bialix> it works
<bialix> wow! we have a lot of bugs attached to revisions in qbzr
<bialix> nice
<bialix> we finally have equivalent to tags command
<bialix> run qlog,select tag in search type, enter *
<bialix> :-)
 * bialix commiting
<sender> anyone experience with the illustrious error: "pack-names is not an index of type <class 'bzrlib.index.GraphIndex'>." after bzr status, bzr log, etc..?
<ronny> meh
<ronny> jelmer: i just got started with playing with the subvertpy wc stuff, got pointers to different usages of it
<ronny> hmm, guess i'll make a own example
<ronny> jelmer: can you point me to the code thats usefull for doing checkouts? im a bit lost in the c code
<LarstiQ> ronny: jelmer is at a festival today
<ronny> oh, i see
<ronny> hmm, i think i just found the code i was searching for
<ronny> (it was in client, i digged around in wc
<LarstiQ> right, wc I think would be operations on an existing wc
<LarstiQ> whereas checkout would be a network operation
<Noldorin> hello
<Noldorin> could someone please help me figure out why i can't pull from this repo via HTTP? http://noldorin.com/repos/olivaw-bot/
<Noldorin> pulling via FTP is no problem.
<Noldorin> i get "bzr: ERROR: Not a branch"
<LarstiQ> Noldorin: looking at the page in a browser mentions we don't have access
<Noldorin> LarstiQ: that's just denying the directory listing though
<Noldorin> isn't it?
<Noldorin> does bzr actually need that?
<LarstiQ> Noldorin: it also denies access to .bzr/
<LarstiQ> Noldorin: (and .bzr/format so it is more than just denying directory listing)
<Noldorin> hrmm
<Noldorin> let me check
<Noldorin> LarstiQ: i've checked permissions. they're frine
<Noldorin> fine*
<Noldorin> LarstiQ: any ideas?
<LarstiQ> Noldorin: neither .bzr/branch/format or .bzr/repository/format seem to exist, what kind of object is it supposed to be?
<LarstiQ> Noldorin: could your server be filtering out files starting with a .?
<Noldorin> LarstiQ: it's possible
<Noldorin> LarstiQ: what do you mean by object?
<Noldorin> hrm
<LarstiQ> Noldorin: is it a branch, a repository, a working tree?
<Noldorin> LarstiQ: it's a repository i believe
<Noldorin> since i just did bzr push
<Noldorin> LarstiQ: server seems to havbe no problems recognising files starting with .
<Noldorin> http://noldorin.com/repos/.bar.txt
<LarstiQ> Noldorin: I get: File Not Found
<Noldorin> LarstiQ: sorry, i just deleted it
<Noldorin> http://noldorin.com/repos/olivaw-bot/.bzr/.bar.txt
<Noldorin> there
<LarstiQ> ah ok, good
<LarstiQ> still not finding a format file though
<Noldorin> yeah...
<LarstiQ> Noldorin: could you temporarily disable the denying of directory listing? It is making debugging guessing in the dark
<Noldorin> LarstiQ: seems like extensionless files don't get recognised :S
<LarstiQ> Noldorin: oh &@#^
<Noldorin> LarstiQ: hrmm...unregistered mime type?
<Noldorin> registered the mime type, and no problem now :)
<Noldorin> LarstiQ: should it be text/plain or something else?
<LarstiQ> Noldorin: the mime-type of what exactly?
<Noldorin> files with no extension
<LarstiQ> Noldorin: they can be anything
<LarstiQ> Noldorin: so I'd go with octet-stream
<Noldorin> ok
<Noldorin> will do
<LarstiQ> wonder why your server doesn't do that by default
<Noldorin> yeah
<Noldorin> who knows
<Noldorin> LarstiQ: what's the prefix?
<Noldorin> ???/octet-stream
<LarstiQ> Noldorin: application/octet-stream
<Noldorin> thought so.
<LarstiQ> Noldorin: basically "we don't know what this is, treat it as binary"
<Noldorin> yeah, makes sense really
<Noldorin> thanks for the help :)
<LarstiQ> np
<Noldorin> after all these FTP issues (no chmod) and now this, i should probably just change server
<Noldorin> but oh well
<LarstiQ> what's life without a bit of a challenge :)
<Noldorin> heh, quite
<Noldorin> as long as there's not *too* many :)
<LarstiQ> right
<LarstiQ> Noldorin: and be sure to quit if your blood pressure is rising too much
<Noldorin> lol, yep.
<Noldorin> i just want to figure why dir listing isn't working now
<Noldorin> then it's all sorted i believe
<mxpxpod> can I push a brand new branch to subversion using bzr-svn?
<LarstiQ> lifeless: is http://bazaar-vcs.org/bzr/bzr.1.17/ the right submit location for 1.17.1 pqm?
<LarstiQ> mxpxpod: I think so
<mxpxpod> also, the first time I push a branch, I have to supply the place I want to push it.. is there a way to set that up so I never have to supply it?
<LarstiQ> mxpxpod: you can have a push_location = foo and push_location:policy  = appendpath for example
<mxpxpod> LarstiQ: what's that do?
<mxpxpod> I just want the push location to be set to where I branched from by default
<LarstiQ> mxpxpod: hmm, I don't think you can configure that
<mxpxpod> darn
<LarstiQ> mxpxpod: do have a look at `bzr help configuration` though
<mxpxpod> LarstiQ: thanks
<LarstiQ> mxpxpod: could you check if there is a bug filed on something like 'locations.conf should be able to work with push_location = :parent'?
<mxpxpod> LarstiQ: yeah, I'll check
<mxpxpod> oh, one last thing... let's say I make a branch of a subversion repo, then make a private branch from that branch
<mxpxpod> to keep the private branch up to date with trunk, I'd just do a pull of the initial branch I made, right?
<mxpxpod> and then do a bzr merge ../private within the initial branch to merge the changes from the private branch
<mxpxpod> and then once I do a push in the initial branch, it will create a check-in in the svn repo for each commit I did in the private branch, correct?
<LarstiQ> mxpxpod: that is the workflow I would use
<mxpxpod> LarstiQ: right, I'm just making sure I got my commands right
<mxpxpod> the commands would be different for a public branch, IIRC
<LarstiQ> mxpxpod: you need an additional setting for the individual bzr commits to be svn commits I think, let me check
<mxpxpod> since you'd have to merge from trunk instead of pulling from it
<LarstiQ> mxpxpod: NEWS mentions push_merged_revisions = True
<mxpxpod> like, if you had bzr branch trunk; bzr branch branches/someFeatureBranch
<mxpxpod> instead of pulling from the branched trunk, you'd have to merge from the branched trunk, right?
<LarstiQ> mxpxpod: unless you have no local commits, yes
<mxpxpod> right, ok, thanks
<mxpxpod> now, if I merge from a private branch, I'll probably want to rebase, right?
<LarstiQ> mxpxpod: the situation isn't clear to me, merge from the private branch into trunk?
<mxpxpod> yes
<mxpxpod> LarstiQ: oh, I figured out how to make each change a changeset... use bzr merge --pull ../private; bzr push;
<LarstiQ> mxpxpod: that only works if trunk has not diverged from ../private
<LarstiQ> mxpxpod: (in which case you could also just `bzr pull ../private`)
<mxpxpod> LarstiQ: right, but if you're constantly pulling from trunk and resolving, won't that keep it from diverging?
<LarstiQ> mxpxpod: right, but you will change the mainline, which svn might not lie
<LarstiQ> like
<mxpxpod> LarstiQ: ah, ok
<LarstiQ> mxpxpod: afaik you can't reorder the mainline on / for example
<mxpxpod> ah, gotcha
<LarstiQ> mxpxpod: but more recent svns have gotten better merge support
<LarstiQ> so maybe it is possible now
<mxpxpod> could be
<mxpxpod> IIRC, anything 1.5 or greater handles merges well
<Noldorin> lifeless: hey, you there?
<lifeless> Noldorin: hi?
<Noldorin> lifeless: hi there
<Noldorin> lifeless: i've done a few more tests with my ftp server
<Noldorin> it seems that the problem is indeed nothing to do with CHMOD
<lifeless> Noldorin: go on
<Noldorin> sorry, multitasking too much here :)
<Noldorin> well
<Noldorin> i'm getting the problem with locking again
<Noldorin> it seemed it was a rare occasion when it actually didn't lock..
<Noldorin> hrmm
<Noldorin> can't think what we did differently last time anyway
<Noldorin> lifeless: i'd be glad to set up a temporary FTP account for you, if it might help
<Noldorin> lifeless: ping?
<lifeless> Noldorin: hi
<lifeless> Noldorin: did you file a bug about this?
<lifeless> I think getting a failed run with -Dtransport is probably the most useful thing.
<Noldorin> lifeless: not yetr
<Noldorin> i will do though
<Noldorin> lifeless: will do that right now
<ronny> what does bzr expect for commit timestamps and timezones? same as git?
<lifeless> huh?
<lifeless> ronny: ?
<ronny> lifeless: trying to figure what to pass to mutabletree.commit for timestamp and timezone
<jelmer> 'moin ronny, lifeless
<ronny> sup jelmer
<lifeless> ronny: unless you need to control it, nothing
<Noldorin> lifeless: this is my log with Dtransport turned on: http://pastebin.ca/1523363
<ronny> lifeless: i need to controll it
<lifeless> ronny: then its a float and an int
<lifeless> seconds since epoch and tz in seconds
<lifeless> Noldorin: and this was of a run that left it locked incorrectly?
<Noldorin> lifeless: yep
<ronny> hmm, meh, for now i'll set tz to 0 for all commits
<lifeless> ronny: please don't do that; its easy to get the local tz
<lifeless> Noldorin: your ftp server is broken
<lifeless> broken broken broken :(
<Noldorin> rubbish
<Noldorin> lifeless: in what way, exactly?
<lifeless> Noldorin: can you get a listing of the contents of .bzr/repository/lock ?
<Noldorin> yeah one sec
<lifeless> Noldorin: if you look at the log, search for repository/lock/held
<ronny> lifeless: ok, time to play figuring stuff
<lifeless> http://pastebin.ca/1523372
<lifeless> thats just the held actions
<lifeless> sorry, lock actions :)
<lifeless> the make, put, rename sequence is how we take a lock out
<Noldorin> lifeless: just /held/info
<Noldorin> i see
<lifeless> rename remove remove-directory is how we release a lock
<lifeless> lock/held is the path of the directory that makes up a lock
<ronny> lifeless: aware of good docs for datetime+timezones?
<lifeless> lock/held/info is the metadata about the lock - when, who, and a nonce to allow identification of 'my lock'
<lifeless> ronny: the python date and datetime module docs are quite good
<lifeless> theres also things like bzrlib.osutils.local_time_offset()
<lifeless> Noldorin: so looking in the abridged log I uploaded:
<Noldorin> yeah...
<lifeless> step 17,19,20 releases a lock
<lifeless> held -> releasing.gzbwa6x1m3udf9nugpdm.tmp
<lifeless> rm releasing.gzbwa6x1m3udf9nugpdm.tmp/info, rmd releasing.gzbwa6x1m3udf9nugpdm.tmp
<lifeless> 23, 25, 27 make a new lock and put it into place
<lifeless> except it fails
<lifeless> can you cat /held/info ?
<lifeless> .bzr/repository/lock/held/info, that is
<ronny> lifeless: is it reasonable to expect timezone infos on a datetime object insted of a separate offset
<Noldorin> lifeless: erm, i'm on windows, so i guess not
<lifeless> Noldorin: well, show me the contents of the file :)
<Noldorin> ok
<Noldorin> sorry, not at all familiar with the unix tools like cat
<lifeless> ronny: the datetime module does that; though its a nuisance to work with - you have to subclass stuff yourself, all the time
<lifeless> Noldorin: no problem; I forgot myself is al
<lifeless> all
<Noldorin> heh
<Noldorin> hostname: Alex-Laptop-PC
<Noldorin> nonce: 40qh66wqvotaj97h8gxa
<Noldorin> pid: 7328
<Noldorin> start_time: 1249858210
<Noldorin> user: alexreg@gmail.com
<ronny> lifeless: yes, seems broken
#bzr 2010-08-09
<AfC> Is there a way to get `bzr revert` to also revert (ie remove) "unknown" files?
<fullermd> Pretty sure not.  That's more clean-tree's territory.
<AfC> fullermd: ah!
<AfC> didn't know about that one.
 * AfC reads help
<spiv> Good morning.
<fullermd> I wouldn't mind mornings so much, but do they have to keep coming around every stinkin' day??
<AfC> fullermd: that's just what we need. Thanks
<hopeseekr> .
<hopeseekr> Hi, is it possible to put some specialized string in a file that when its committed will turn into the revision number of that commit?
<spiv> hopeseekr: sort of.  Take a look at the bzr-keywords plugin.
<hopeseekr> thanks
<johnnie_> i'm using bazaar explorer - isit the case that it always creates a trunk subfolder everytime you do an init?
<johnnie_> I find that I navigate to where my files are, do an init and then it creates this trunk subfolder and I have to move the files down in order to add them
<lifeless> I think so, it has a default that scales well
<johnnie_> ok - thanks - so what i'm doing is right?
<lifeless> yup
<johnnie_> gpthca
<johnnie_> gotcha
<lifeless> you should only need to init a project once
<lifeless> after that, branching existing branches
<lifeless> is more appropriate
<johnnie_> ok - think i understand
<johnnie_> i guess it's best to do the bzr init first before creating the dev files?
<lifeless> with explorer yup
<johnnie_> great - tnx
<spiv> Whee, bugs in socket.py in maverick's python2.6
<lifeless> \o/
<spiv> (bug 615236)
<ubot5> Launchpad bug 615236 in Bazaar "'bzr reconcile' unsafe for stacked 2a? (ignores parent inventories) (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/615236
<lifeless> what are we, barries test-case
<spiv> Er, 615240
 * spiv goes to pick up V
<lifeless> bug 615240
<ubot5> Launchpad bug 615240 in python2.6 (Ubuntu) "sock.makefile().flush has UnboundLocalError bug (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/615240
<poolie> hi spiv, bye spiv
<mgz> uuuu, bad feeling about that socket bug
<mgz> that lame "explict free" comment is from the EINTR fix for socket file objects
<mgz> http://svn.python.org/view?view=rev&revision=74426
<mgz> ...but it doesn't have a 'view'... wonder when that was added
<mgz> looks like a bad merge:
<mgz> http://svn.python.org/view?view=rev&revision=83624
<spiv> Back again.
<bialix> hey spiv
<mgz> spiv, are you going to file an upstream bug, or just bug someone to put the one line change on release26-maint?
<mgz> getting an answer from ezio.melotti on why he fiddled with that patch during merging might be useful.
<spiv> mgz: I haven't looked upstream yet, 'ubuntu-bug' is more convenient than bugs.python.org ;)
<mgz> well, it's only a six day old error, so you're probably the first one on it
<spiv> mgz: I'll do so (even if I don't, I'm sure the Ubuntu packagers would forward the bug and fix upstream)
<mgz> ...he fiddled because memoryview isn't in 2.6
<mgz> I don't think his change is really right, even with the line he missed fixed...
<spiv> I only just finished making a coherent bug report before I had to head out the door :)
<mgz> ah, actually it might be, svn view on python server eats whitespace changes, I always forget that
<spiv> mgz: hah: http://bugs.python.org/issue9543
<mgz> wasn't suggestion you were being bad, was just going to volunteer if you were busy
<spiv> mgz: oh, please do, it's basically EOD for me here right now :)
<mgz> ^heh, mear hours in it.
<mgz> okay, bugs linked, think you don't need to do any more work there.
<Pieter> hey all. Is there a way to get bzr diff --using=... to also call the supplied difftool for added or removed files?
<spiv> Thanks!  I went ahead and added a comment with the contents of the script for convenience.
<spiv> Pieter: I think there might be a bug report about that (if not, there probably should be)
<flam_> bzr add command doesn't seem to work: when i add new files with bzr add <filename> it says "adding <filename>" and when i then commit bzr says "added <filename>
<flam_> ups
<flam_> still, when i log into the server and check if that file has been added, it isn't there
<flam_> wtf
<flam_> no error messages are shown
<fullermd> Are you expecting to see it in the working tree of a remote branch?
<poolie> flam_: you may need to run 'bzr update' on the server
<flam_> fullermd, both
<flam_> poolie, i don't think i have rights to do it
<fullermd> bzr doesn't touch working trees of branches it accesses across the network (e.g., anything you `bzr push bzr+ssh://...`), so they'll never be updated.
<MAfifi> Is pushing code to launchpad now a little problematic?
<MAfifi> I'm trying to push a new commit to an already existing branch on launchpad, and I keep getting that error:
<MAfifi> ssh: connect to host bazaar.launchpad.net port 22: Connection refused bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<MAfifi> I've made sure I'm logged in via bzr launchpad-login <username>.
<lifeless> MAfifi: do you have a firewall blocking port 22 perhaps ? its working for me
<MAfifi> No, I even can't checkout code with bzr branch.
<lifeless> Do you have a firewall blocking port 22 ?
<MAfifi> I consulted my system administrator and he stated that it was really blocked, sorry.
<AfC1> Thank god for professional systems administrators, in the service of their users.
<AfC1> Probably blocks port 80 too. Can't be too careful.
<rubbs> actually, as a sysadmin, there is a reason to not let 22 out, not that I'd do it, because it's just too tin-foil hat, even for me.
<rubbs> mostly due to the creation of port forwards and tunnels as a way to defeat incoming firewall rules.
<rubbs> but if you got a guy on the inside punching holes you already have a problem, trying to block outbound ssh isn't going to help that.
<rubbs> IMHO of course
<ddaa> it depends on the level of competency you expect to block
<rubbs> exactly
<ddaa> punching holes out of a http proxy is a bit trickier, I would not know how to do it in a pinch
<rubbs> unless you had an ssh server listening on port 80. There are a million and one tuts out there telling you how you can break through firewalls at work.
<ddaa> I'm sure I could figure it in a couple of hours
<ddaa> note the "in a pinch"
<rubbs> true
<bialix> heya GaryvdM
<GaryvdM> Hi bialix
<bialix> do you have 5 minutes to chat about explorer?
<GaryvdM> sure!
<bialix> I'm starting to think about explorer performance and what to do about it
<bialix> 2 obvious things coming to my mind
<GaryvdM> btw - Thanks for doing the release last week. I was to busy.
<bialix> 1) if explorer using treewidget from qbzr, then on every refresh of the branch status explorer do 2 status operatrions: 1 for its own view, and second (indirectly) for treewidget
<bialix> I think it's a waste
<Noldorin> what can i use for resolving conflicts of files after a merge?
<Noldorin> does bzr come with it's own tool i should be using?
<bialix> GaryvdM: np, it's not hard for me to do release, but gave me a way to come back into bzr dev mindset after vacation
<bialix> Noldorin: you can use extmerge plugin, or qconflicts command from qbzr, or just fire your favorite 2/3-way merge GUI tool
<Noldorin> bialix, winmerge would do the job?
<bialix> Noldorin: winmerge is ok, but you have to run it just from commandline
<GaryvdM> bialix: Sure. I think it would be easiest for us to make the qbzr treewidget accept a delta.
<Noldorin> bialix, why's that?
<bialix> Noldorin: like this: winmergeu file.txt
<Noldorin> ah yes
<Noldorin> bialix, is there a detailed tutorial on how merging works in bzr? i could probably benefit to read up on it
<bialix> Noldorin: because winmerge gets only 1 filename as parameter, but extmerge and qconflicts don't allow you to configure it this way. yet
<Noldorin> right
<bialix> Noldorin: tutorial?
<Noldorin> bialix, or guide, rather
<Noldorin> documentation of some sort
<bialix> it works in the similar way as GNU diff3
<tim> hi, is there a way to clone a repository without downloading the whole history, but just the most recent revision?
<bialix> hmm, is not the User Guide has the section about resolving conflicts?
<GaryvdM> tim: bzr checkout --lightweight
<bialix> Noldorin: http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/resolving_conflicts.html
<tim> GaryvdM, thanks!
<bialix> Noldorin: also http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/merging_changes.html
<GaryvdM> tim: In the feature we hope to support shallow branches/history horizon (http://wiki.bazaar.canonical.com/HistoryHorizon)
<Noldorin> cheers
<GaryvdM> tim: lightweight checkouts kind of suck, because the have to redownload the data if you want to do a diff/status.
<bialix> GaryvdM: 2nd point about explorer: it's almost useless to run explorer under profiler, because it's supposed to be long running process. I'm thinking about adding profile calls for specific operations or for refreshes
<Noldorin> bialix, it doesn't explain what the BASE/THIS/OTHER files correspond to though
<Noldorin> i can guess...
<bialix> Noldorin: http://doc.bazaar.canonical.com/bzr.2.1/en/user-reference/conflict-types-help.html#text-conflicts
<Noldorin> BASE is the ancestor of the file in both branches, THIS is the version of the file in the destination branch, and OTHER the version in the source branch
<Noldorin> ah
<bialix> it's a kinda split over the docs
<tim> GaryvdM, well, it is ok for me ... i was trying to branch a repository, but stopped after downloading almost 3gb
<Noldorin> yeah, i'm noticing. cheers
<GaryvdM> bialix: That should be easy to do. You will just have start the profiler, and stop it you self.
<bialix> Garyvdm: 3rd point: maybe we can provide a result of q-subprocess operations (like qadd, qrevert) back to explorer via some sort of IPC (don't know yet) as list of affected files, to speed-up status update
<bialix> GaryvdM: yep, that's my guess about profiler as well. I can store such data into user directory and then asking people for mailing these data for analysis
<bialix> tim: what is your master branch?
<GaryvdM> bialix: Also, with KCachegrind, you can see the callees of a method. So it's easy to see what is taking long in the refresh method.
<bialix> GaryvdM: also, I'm thinking about using separate process a-la tortoisebzr status RPC service/daemon to collect status info in the background. I'm not sure how good it will be for Linux
<tim> bialix, lp:ubuntu/gcc-4.5
<bialix> tim: ah. sorry
<bialix> GaryvdM: I don't have Ubuntu yet
<GaryvdM> tim: I know that there were some memory issues with gcc checkouts. jam was looking at them.
<bialix> GaryvdM: but maybe I need to get new notebook, where I can create dual-boot system
<GaryvdM> bialix: Do you have any callgrinds I can look at?
<Noldorin> bialix, what would you recommend for merging on windows? i'm not sure i fully like winmerge...
<bialix> GaryvdM: no new data so far, I'm trying to figure the right way to attack this problem
<bialix> Noldorin: I'm using either winmerge, or just text editor
<Noldorin> right
<bialix> Noldorin: many people like diffuse, and Araxis Merge tool (non-free)
<Noldorin> bialix, i'm trying to figure out the correct command-line option for opening a conflict file
<GaryvdM> Noldorin: On windows, I like Araxis Merge. It's propritory :-( and expensive :-(, but works well
<Noldorin> right
<Noldorin> GaryvdM, i see...
<bialix> Noldorin: for which tool?
<Noldorin> winmerge
<bialix> winmergeu FILE_WITH_CONFLICTS
<bialix> just a file name, without THIS/BASE/OTHER
<Noldorin> doesn't work...
<Noldorin> ok
<Noldorin> hmm
<bialix> Noldorin: I'd recommend to use winmerge 2.13.8 or higher
<bialix> previous versions have some bugs in this area
<GaryvdM> bialix: Re explorer, and qbzr dialogs, I think the easiest would be for them to be in the same subprocess...
<Noldorin> bialix, i see. that version is beta as i understand
<bialix> GaryvdM: yep, I think we can run qdialogs from main explorer process, anyway we then invoke qsubprocess, right?
<bialix> Noldorin: I'm using it for very long time
<bialix> Noldorin: no problems detected so far
<Noldorin> ok that's good to know :)
<GaryvdM> bialix: Yes. The issue with that is then you will have different code for qbzr and bzr-gtk dialogs.
<bialix> GaryvdM: well, at some point I can drop bzr-gtk support, if it will be too much hassle
<GaryvdM> I wonder if there  are any people who  launch bzr-gtk dialogs from explorer?
 * bialix too
<bialix> in the end there is olive-gtk, and nautilus
<GaryvdM> bialix: Re https://code.edge.launchpad.net/~garyvdm/bzr-explorer/better_tree_filter/+merge/20519
<ddaa> I would, bzr vis is superior to qlog in some respects
<GaryvdM> bialix: I got stuck with requiring a version qbzr.
<GaryvdM> ddaa: In what way?
<bialix> GaryvdM: what's the problem?
<GaryvdM> ddaa: And do you use bzr explorer?
<ddaa> I find the "show me the revision where this line was introduced" behaviour of vis very nice.
<ddaa> And qlog quite confusing in that respect.
<ddaa> GaryvdM: I'm trying on occasion, but truthfully, I'm too used to the command line and I find a gui clumsy.
<ddaa> So feel free to ignore me.
<GaryvdM> ddaa: Ok
<ddaa> mh
<bialix> ddaa: is not this is annotate?
<ddaa> yes it is :-)
<ddaa> was about to correct myself
<ddaa> duh
<GaryvdM> ddaa: for qannotate, just click on the line of text, and the revision is selected?
<ddaa> GaryvdM: do you really want go into debugging what exactly I found confusing?
<GaryvdM> ddaa: Yes :-)
<bialix> yes
<ddaa> ok, let me fire the bugger
<GaryvdM> ddaa: what version was this in. qannotate got some nice improvements in 0.18
<ddaa> qbzr 0.18.4
<GaryvdM> ddaa: i.e. Find, goto line, and when you change the annotated revision, the scroll remains consistent.
<bialix> in 0.19?
<GaryvdM> ddaa: sorry - in 0.19...
<bialix> GaryvdM: I guess you mean 0.19
<GaryvdM> Yes :-)
<ddaa> mh... maybe my confusion came from scrolling issues indeed
<GaryvdM> bialix: For https://code.edge.launchpad.net/~garyvdm/bzr-explorer/better_tree_filter/+merge/20519 , I have 2 code paths. one for qbzr 0.18, and one for qbzr 0.19
<GaryvdM> bialix: basicly, the methods added in 0.19 are included in that patch as a fall back...
<bialix> GaryvdM: ok, I understand
<bialix> GaryvdM: I'm happy to say that explorer trunk required qbzr 0.19
<Noldorin> bialix, thanks, seems to be working nicely now :)
<GaryvdM> bialix: My problem was I was not able to do that.
<GaryvdM> bialix: let me have another go...
<bialix> GaryvdM: sorry, I can't dig into your code right now
<bialix> GaryvdM: but I will review it ASAP
<bialix> Noldorin: good to hear
<GaryvdM> bialix: I would have just landed it, if it were not for the qbzr version issue.
<GaryvdM> That for me is the issue.
<bialix> hmm
<GaryvdM> bialix: Were should we do the check? In the __init__.py, like we do for bzrlib check in qbzr,
<GaryvdM> or in commands.cmd_explorer.run?
<ddaa> GaryvdM: I'll check the newer qannotate when I get it from the system update.
<bialix> GaryvdM: I'd prefer the latter
<GaryvdM> ddaa: Cool.
<GaryvdM> bialix: ok - I'll do that now.
<Noldorin> bialix, so i've finished doing my merge/conflict resolution. is there any easy way to tell bzr to remove all the .~1~ and .moved files?
<Noldorin> and .BASE, etc.
<bialix> bzr resolve
<Noldorin> thatl leaves them there
<bialix> bzr clean-tree
<Noldorin> ah yes
<maxb> bzr clean-tree --detritus
<bialix> Noldorin: you need to run `bzr resolve` and mark non-text conflicts as resolved
<bialix> qconflicts is your friend
<Noldorin> bialix, yes, bzr resolved tells me there are no more conflicts
<bialix> (or qresolve, it's the same thing)
<Noldorin> but the tree was dirty still
<Noldorin> that did the job though - thanks again
<bialix> now you're ready to commit your merge
<Noldorin> :)
<GaryvdM> Bla - my in progress maverick upgrade has broken pyqt...
<GaryvdM> I guess you or not ment to use it while it's upgrading....
<GaryvdM> bialix: landed.
<bialix> GaryvdM: thanks!
 * GaryvdM off to get food.
<GaryvdM> bbl
<Kaspi> hello
<Kaspi> what's the difference between branch and repository?
<maxb> A repository is an on-disk store of revision data
<maxb> A branch is a store for a reference to a specific revision (and implicitly all of its ancestors), and also a mapping of tag-name -> revision-id.
<parthm> Kaspi: 'bzr help branches' and 'bzr help repositories' have some good notes. There are some more topics under 'bzr help topics' in case you haven't seen it already.
<thrope> does loggerhead have a download tarball link yet?
<Kaspi> parthm: maxb: thanks
<thrope> is there any other bazaar web client that allows downloading a tarball of the latest revision? ive been pretty happy with loggerhead but really need that functionality
<thrope> according to this it can do it
<thrope> https://bugs.launchpad.net/loggerhead/+bug/246764/comments/4
<thrope> but i can't see how
<ubot5> Launchpad bug 246764 in loggerhead "Recreate "Download a Directory" feature (affected: 1, heat: 0)" [Wishlist,Triaged]
<GaryvdM> jam: Ping
<bialix> GaryvdM: ping
<GaryvdM> bialix: Pong
<bialix> GaryvdM: regarding your check for qbzr version in explorer
<bialix> I think it should report in the console AND as GUI MessageBox
<bialix> or only as MessageBox
<bialix> think about bzrw.exe
<GaryvdM> Good point.
<bialix> if there won't be a real console user will not know why explorer does not start
<bialix> even with bzr.exe the console will flashing and closing
<GaryvdM> bialix: If explorer had a ui-mode option, and you ran the command with it, then it would show a message box.
<bialix> we can say that explorer is always run with --ui-mode ;-)
<GaryvdM> bialix: but that's not what I think we should ho
<GaryvdM> *do
<GaryvdM> bialix: The error handler should detect bzrw.exe (using sys.frozen)
<bialix> imho, explorer is GUI application, and I'd prefer to show error messages as GUI dialogs, when possible
<jam> hey GaryvdM
<GaryvdM> Hi jam.
<GaryvdM> jam: I can't connect to the ec2 computer.
<jam> it would be at a different address, I forgot about that
 * bialix waves at jam
<jam> hi bialix
<GaryvdM> jam: That's what I figured.
<dlee> Any way to use a normal bzr repository to manage parts of a tree also managed by svn?  IOW, I have an svn checkout but want to use bzr to manage little bits of it locally.  the .svn folders confuse bzr at sublevels though.
<dlee> i think I'm looking for a way to get bzr 2 to ignore .svn folders, without having to rename them all momentarily.
<GaryvdM> dlee: bzr ignore .svn
<dlee> I doubt that helps... scenario: bzr init in folder a with subfolder b/c/d.  Then cd b/c/d, bzr add file.txt... but there are b/.svn, b/c/.svn, and b/c/d/.svn, all of which keep bzr from finding a/.bzr at all.
<GaryvdM> bialix: I just had a look at the error handling in bzr-explorer. I would like to do some improvements there.
<GaryvdM> bialix: But tonight, I want to get the 2.2.0 final installers done.
<bialix> GaryvdM: ok
<GaryvdM> bialix: How much do you know about buildout?
<bialix> a little
<bialix> but enough to get the bad impression
<bialix> :-/
<GaryvdM> bialix: Would you be able to help me get the build script to use a downloaded version of pycrypto & paramiko, rather than the ones installed on the build system?
<bialix> get?
<bialix> you need to download?
<bialix> or you need to force them in py2exe>
<bialix> or you need to force them in py2exe?
<GaryvdM> bialix: yes, download, and change sys.path.
<bialix> I guess PYTHONPATH should be enough for py2exe
<bialix> lemme pull the branch first, trunk?
<GaryvdM> bialix: yes
 * bialix pulls
<GaryvdM> bialix: I think buildout is ment to be able to do that for you automaticly.
<bialix> I meant: pull the latest changes from lp:bzr-windows-installers
<GaryvdM> Yes
<GaryvdM> I watched a video about buildout. The guy added to install_requires in setup.py, and it automaticly got the egg, and change the sys.path so that the egg got used.
<GaryvdM> The module was not installed on the system.
<GaryvdM> Maybe I need to do that in the setup.py in the py2exe code.
<bialix> file build.py, line 393, def _build_exe
<bialix> IMO, you need to add PYTHONPATH to env dict
<GaryvdM> Ah - ok - so I'm not going to be able to get buildout to do it for me.
<bialix> GaryvdM: btw, in the bazaar_releases.py you have custom bzr
<bialix>         Project('bzr', 'lp:~garyvdm/bzr/2.2b4-optimize'),
<bialix> I think it should be updated to lp:bzr/2.2 ?
<GaryvdM> bialix: Yes
<bialix> and you need to merge my branch with changes to qbzr/explorer versions
<bialix> or I should merge and push?
<GaryvdM> bialix: Allready done :-)
<GaryvdM> oh wait.
<GaryvdM> I did not push
<bialix> yep
<GaryvdM> bialix: Sorry - I thought I had done it.
<GaryvdM> Done now. :-)
<bialix> GaryvdM: now only bzr 2.2 branch need to be changed
<bialix> GaryvdM: to download pycrypto/paramiko I guess you need to add them into bazaar_releases
<GaryvdM> bialix: Yes - and I need to go through the rest of the plugins, and check if there are any new releases.
<bialix> I'd suggest to download them and install into temp directory, then use this directory in the PYTHONPATH
<bialix> GaryvdM: it seems igc has removed some dependencies on buildout
<bialix> before buildout generated bat file to execute build. now it's plain python, and this is good
<GaryvdM> jam, bialix: This is harder than I thought. So I'm going to install the new versions on the build server.
 * bialix nods
<GaryvdM> jam: Sorry - forgot I don't have admin.
<GaryvdM> please will you do it for me.
<GaryvdM> the files are in d:
<jam> GaryvdM: what do you need installed?
<GaryvdM> pycrypto 2.2
<GaryvdM> and paramiko with my patch
<GaryvdM> I have the source for both in d:
<jam> k, be about 5 min
<GaryvdM> jam: Thanks
<jam> GaryvdM: just setup.py install for paramiko?
<GaryvdM> jam: I guess so. I'm not sure what the easest way to get easy_install to manage it.
<GaryvdM> Maybe build an egg?
<jam> GaryvdM: were you expecting pycrypto 2.2 to be installed?
<GaryvdM> jam: Yes - that is the latest release
<jam> k, I only knew about 2.1
<GaryvdM> yes - Very new.
<GaryvdM> I've run the paramiko test suit on it - all passes.
<jam> so I made one small change, bumping 1.7.6 to 1.7.6.1
<jam> so that it will update to this version
<GaryvdM> Ok - cool.
<jam> rather than think it is new enough
<jam> I'm a little concerned about this:
<jam>   warning: GMP library not found; Not building Crypto.PublicKey._fastmath.
<jam> but I guess I'll live with it
<jam> they don't have binaries for pycrypto because of export rules, iirc
<jam> anyway, stuff is installed, care to test it?
<GaryvdM> jam: Thanks - Will do in a sec.
<GaryvdM> Still no 2.2 compatible releases of bzr-loom, and bzr-pipeline :-(
<bialix> jam: there is binary for pycrypto available on voidspace
<quotemstr1> What's the best way to create a private fork of a project already on bzr?
<ddaa> bzr branch
<quotemstr1> On Launchpad, that is.
<quotemstr1> Without having to re-upload the *entire* project to a fresh Launchpad branch.
<GaryvdM> jelmer: I'm getting this error building subvertpy 0.7.3.1: http://pastebin.org/462761, should I log a bug?
<ddaa> define "private fork" in terms of launchpad
<ddaa> when uploading a branch to an existing project, lp will use stacked repo
<jelmer> GaryvdM, please do
<jelmer> GaryvdM, actually, any chance you can try with lp:subvertpy as well?
<jelmer> if it doesn't work with that, I think we should fix the issue and release a 0.7.3.2
<GaryvdM> jelmer: ok
<quotemstr1> ddaa: Ah.
<quotemstr1> ddaa: Is it normal that it bugs me about a missing .bzr directory?
<ddaa> you must be doing something wrong, we'd need the full command and output of bzr (to a pastebin) to be able to tell
<quotemstr1> Well, I created a new branch of Emacs using the bzr web interface, and tried to push to it: http://pastebin.ca/1914036
<ddaa> what about following the hint in the error  message?
<quotemstr1> That'll probably upload the entire project, which is huge.
<ddaa> what about trying?
<quotemstr1> Hrm. It seems to have worked.
<quotemstr1> Thanks.
<ddaa> thanks to stacked repos
<ddaa> canonical does not terribly fancy the idea of hosting one complete copy of the emacs repo for each branch, either
<ddaa> not to mention the fact it would make lp unusable for people
<GaryvdM> jelmer: Yhea - builds fine with lp:subvertpy. I'm going to log a bug, and then release with 0.7.2
<jelmer> GaryvdM, thanks.
<GaryvdM> Ah - allready loged: bug 612056
<ubot5> Launchpad bug 612056 in subvertpy "Can't compile _ra.c using VC++ (affected: 1, heat: 7)" [Medium,Fix committed] https://launchpad.net/bugs/612056
<C-S> Any ideas when bzr-gtk is released? It is not usable on the 2.2 version of bzr...
<dobey> jam: ping :)
<dobey> hrmm
<dobey> so i am having a bit of a weird experience similar to https://bugs.edge.launchpad.net/launchpad-code/+bug/614404 i think
<ubot5> Launchpad bug 614404 in Launchpad Bazaar Integration "commit uses system user-id to generate revision-id even when committer id is supplied (affected: 1, heat: 6)" [Medium,Triaged]
<dobey> but even with jam's patch from there, i still get the same failure, occurring elsewhere
<dobey> http://pastebin.ubuntu.com/475639/
<james_w> dobey: that's not really the same issue, as nothing is specifying --committer for you
<james_w> dobey: in that case I think it's probably that tarmac isn't using bzr's test case and so doesn't get the sanitised environment that should stop this sort of thing from happening
* jam changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | bzr 2.2-final has gone gold, build those installers
<GaryvdM> Bla - I'm stuck. Will continue tomorrow.
<poolie> hi gary,
<poolie> mkanat: hello?
<mkanat> Hey poolie!
<poolie> mkanat: hi there, be with you in a sec
<mkanat> Okay.
<poolie> back
<poolie> i'm glad that's all settled
<poolie> now how about some lp bugs?
<poolie> i mean loggerhead bugs
<mkanat> :-)
<mkanat> Yes, sounds like a plan. :-)
<thumper> mkanat: hi
<poolie> i had a couple of specific suggestions
<poolie> we're seeing crashes every few days
<mkanat> poolie: My schedule has become slightly more occupied since I was last doing loggerhead work, but I have a whole plan for how to fit this in.
<thumper> mkanat: I should really have a chat with you and poolie about directions I'd like to see loggerhead go in
<poolie> the losas may be able to help you characterize it
<poolie> i don't think there's any specific emergency at the moment, so it doesn't need to be right this week or anything
<thumper> poolie: it isn't quite as bad as every few days
<mkanat> poolie: I think the memory leak thing should probably be addressed pretty quickly, though.
<thumper> although we did have a day a while back where it was four times in one day
<poolie> anyhow the suggestions were to do fixes off a stable branch we can roll out
<poolie> maybe a numbered release branch, and then to get lp-loggerhead to converge with that
<poolie> and also perhaps to see about meliae integration
<poolie> perhaps working with jam
<mkanat> poolie: Those sound like reasonable suggestions.
<poolie> meliae should help get better data about future stuff
<poolie> apparently the losas are all at a sprint in utc+2 at the moment
<poolie> thumper: do you have any favourite bug nominations?
<thumper> nothing really beyond the crash and non-responsive fixes
<thumper> my concerns are more with strategic loggerhead direction
<mkanat> That makes sense.
<mkanat> FWIW, my general suspicion on loggerhead strategic direction is that it should switch to Spawning.
<poolie> mm
<poolie> it makes sense to me
<poolie> how hard would it be? perhaps reasonably easy if it's just a wsgi reconfiguration
<poolie> (he says hopefully)
<mkanat> Well, we have a lot of custom code around Paste.
<mkanat> I haven't looked into Spawning too much, but I have seen that there is a Paste layer.
<mkanat> What wouldn't be portable is the kill-hung-threads stuff. But it might also no longer be necessary.
<mkanat> I'm hoping that to get it to the point of doing a basic experiment wouldn't be too much work, but I suspect that a full "correct" migration would be more effort.
<poolie> ok
<poolie> so istm, i'm not sure about tim
<poolie> that if there are smaller point bugs they would be good to do first
<poolie> otherwise, switching to a spawning model makes sense
<poolie> you could send a brief rfc if there's anything more to say beyond your previous mail
<mkanat> poolie: Okay. :-)
<mkanat> poolie: The only tricky part with Spawning is caching, because we can't share in-memory caches. So we have to do everything on-disk.
<poolie> you could have nonshared in memory caching
<mkanat> Yeah, we could.
<mkanat> But I think that would make each process enormous.
<poolie> mm maybe
<mkanat> poolie: Maybe I should just go through every open loggerhead bug, right now, too. There aren't that many.
<poolie> so we could externalize it to tdb, or a bzr pack, or memcached
 * mkanat nods.
<poolie> perhaps the last would be nice eventually but that may require bigger changes
<poolie> also it'll make it less self contained
<mkanat> Yeah, and I don't think it will be necessary.
<poolie> that could be good
<mkanat> That is, I think memcached is in the realm of YAGNI for the moment.
<thumper> I just tried to use "bzr send" for the first time in gnome, and after switching default email client from evo to kmail it now brings up an email, but there is no attached bundle
<thumper> it should right?
<poolie> it should either have a body or an attachment
#bzr 2010-08-10
<dobey> james_w: but the commit() call that tarmac is making, is passing committer='Tarmac' as an argument
<dobey> it was working fine before i upgraded to 2.2.0 today
<mkanat> Is "bzr send" using a "mailto" url or something?
<mkanat> Not all MUAs support all the mailto query parameter extensions.
<thumper> it worked fine in kde, just not gnome
<thumper> probably a weird setting
<mkanat> Ahh, yeah.
<spiv> Good morning.
<poolie> hi there spiv
<jam> mkanat: just a note, the primary in-memory cache is brought down to disk in trunk with the bzr-history-db work
<jam> hi spiv
<mkanat> jam: Yeah, that's the primary thing that makes this possible.
<mkanat> jam: But the revision cache is still in memory, IIRC.
<jam> mkanat: it is, but it isn't as necessary
 * mkanat nods.
<jam> ISTR there are times when it is useful
<jam> we would have to check
<mkanat> Yeah, there are times we have to map revids to revnos in a loop, IIRC.
<jam> we could push harder on moving it to disk if we had to
<mkanat> jam: I think that's probably what we'll do.
<jam> short-term denormalization of a given table
<mkanat> jam: But that won't work in the codehosting situation, will it? Because we can't write to the disk.
<jam> we can
<jam> it already does
<mkanat> Ah, okay.
<james_w> dobey: well, that's when the error was added, so that's no surprise
<james_w> dobey: is test_branch a file you have added?
<james_w> dobey: and in your pastebin "a_branch.tree.commit("Reading, 'riting, 'rithmetic")" doesn't look like it is passing committer=
<mtaylor> if I don't want to re-branch - is there a way to migrate a standalone branch to one inside of a shared repo?
<fullermd> reconfigure
<mtaylor> fullermd: heh. that's too easy
<fullermd> Oh.  Well, the Seven Trials of Courage, climbing the North Face of the Eiger, _then_ reconfigure.
<mtaylor> fullermd: excelent. that's better
<fullermd> Anything for a steady customer  :p
<mkanat> poolie: I should be able to get to Loggerhead stuff by the end of the week. But if there's something that you need more urgently than that, please let me know.
<poolie> mkanat: nothing springs to mind, i'd just suggest talking to chex or spm or similar if you see them online
<mkanat> poolie: All right. :-)
<spiv> poolie: what's the process for getting 2.1.2 into lucid-updates?  There have been quite a few dupes of bug 559436, and it just bit Mary...
<ubot5> Launchpad bug 559436 in Bazaar 2.1 "AttributeError: 'NoneType' object has no attribute 'get_config' (affected: 8, heat: 45)" [High,Fix released] https://launchpad.net/bugs/559436
<lifeless> spiv: read all about it on the stable release update pacge
<poolie> spiv, or see my previous mail about srus
<mtaylor> lifeless: all of the web pages say bzr-hg is under heavy dev ... is it usable for day to day? or will I have less pain with just plain hg?
<lifeless> mtaylor: we use it in prod to import hg on lp.net.
<lifeless> mtaylor: go figure :P
<mtaylor> lifeless: oh - well, that's something then :)
<mtaylor> lifeless: there doesn't seem to be a _great_ way to figure out what form a url should take... can you recommend any help I should look at? or should I just read the source?
<lifeless> http:// ?
<lifeless> I dunno
<mtaylor> lifeless: hah! I was trying to make it much harder - doing hg+http :)
<mtaylor> lifeless: thanks
<spiv> poolie: On reflection I think what I really meant to ask was "why didn't 2.1.2 get proposed as an SRU more-or-less when it was released?"  Ideally we'd have proposed it already given the severity/frequency of that bug I think.
<poolie> i don't think there's any good answer
<poolie> we should have
<poolie> the make-a-release chain is already pretty long
<spiv> *nod*
<spiv> Actually, looking at my mail, lifeless said he was about to propose 2.1.2 as an SRU for lucid the day 2.1.2 released. :P
<lifeless> I may have done so even.
<spiv> Hmm, I wonder where it is then...
<lifeless> https://bugs.edge.launchpad.net/ubuntu/+source/bzr needs some love
<spiv> Yeah, I was just noticing that :(
<spiv> https://code.edge.launchpad.net/~lifeless/ubuntu/lucid/bzr/2.1.2-sru
<spiv> linked to bug 528041
<ubot5> Launchpad bug 528041 in Bazaar 2.2 "bzr: ERROR: exceptions.AssertionError: _remember_remote_is_before((2, 1)) called, but _remember_remote_is_before((1, 6)) was called previously. (affected: 21, heat: 136)" [High,Fix released] https://launchpad.net/bugs/528041
<lifeless> there you go
<lifeless> I was about to claim that I sucked
<spiv> So where in the SRU process did that get stalled?
<lifeless> probably the usual place : the start
 * lifeless takes off the bitter hat
<spiv> Heh.
<spiv> Well, it looks like we got past step 1 of https://wiki.ubuntu.com/StableReleaseUpdates#Procedure :P
<spiv> lifeless: so my reading of the SRU page says the next thing that needs to happen is someone needs upload the package to lucid-proposed.  Does that sound right to you, and can you do that?
<lifeless> AIUI no
<lifeless> ww haven't set up per-package uploads for bzr and its in main
<spiv> So we should subscribe ubuntu-sponsors to the bug to find a sponsor?
<poolie> probably
<poolie> you may need to nag someone
<cody-somerville> I'll sponsor it.
<spiv> cody-somerville: thanks!
<cody-somerville> Does bzr have an exception from the TB to push entire new releases via -updates?
<lifeless> cody-somerville: no, and we're not asking for that
<lifeless> cody-somerville: these point releases are managing in an SRU way upstream
<poolie> cody-somerville: if this is from 2.1.1 to 2.1.2 the changes should be compatible with the sru criteria
<poolie> safe fixes for important bugs
<spiv> This is from 2.1.1 to 2.1.2
<cody-somerville> 47 files changed, 2926 insertions(+), 2331 deletions(-)
<lifeless> noooo
<lifeless> its either very mechanical, or something confused in udd
<spiv> A heap of that is noise from Pyrex-generated C, I suspect.
<lifeless> bzr diff -r bzr-2.1.1..bzr-2.1.2 | diffstat
<lifeless>  34 files changed, 717 insertions(+), 160 deletions(-)
<lifeless> cody-somerville: ignore the .c files, they are autogenerated - equivalent to configure
<spiv> Heh, yep, lots of /home/mbp/ became /home/robertc/ in Pyrex-generated comments in the C.
<lifeless> we should probably add some sed in there
<poolie> urk
<cody-somerville> Generally an SRU is as minimal as possible to fix a single specific bug. Some packages like landscape have permission from the TB to push point releases like this into -updates. Considering bzr's testsuite, you guys should probably ask for the same exception. In the mean time, is there a minimal diff I can upload? If not, I'd recommend pinging someone from the SRU team to get permission as to avoid doing something that'll end up being
<cody-somerville> rejected.
<poolie> hm
<poolie> we have done previous SRUs on similar changes
<spiv> It sounds like it would be good to get formal permission from the TB just to expedite the process?  I know we've had point release SRUs go through before, but IIRC also with some to-and-fro about whether they really satisfy the letter of the SRU policy or not.
 * cody-somerville nods.
<poolie> ok
<spiv> Expedite the process in future, anyway, perhaps not expedite this particular SRU ;)
<poolie> so in the interim, do you want to merge the patch just for this change?
<poolie> i find it a bit hard to believe that will be much safer but i understand the general process
<cody-somerville> Its up to you guys. I was hoping this was just a quick patch that I could do real quick before heading off to bed.
<cody-somerville> If you want you can get approval from SRU board and I can upload when I wake up if you haven't found someone else to sponsor it by then
<spiv> poolie: well, the linked bug is for the siginterrupt issue, which is definitely good to have fixed, but the bug that triggered me asking about SRUs was bug 559436...
<ubot5> Launchpad bug 559436 in Bazaar 2.1 "AttributeError: 'NoneType' object has no attribute 'get_config' (affected: 8, heat: 45)" [High,Fix released] https://launchpad.net/bugs/559436
<poolie> cody-somerville: and how do we get that approval?
<cody-somerville> subscribe ubuntu-sru team
<cody-somerville> and then possibly poke someone on the team
<poolie> spiv, can you do that?
 * bialix waiting for Garyvdm
<poolie> hi bialix
<bialix> hi poolie !
<spiv> poolie: sure
<spiv> (The team was already subscribed to that bug as per the procedure on the SRU wiki page, but I'll find and poke someone on it)
<poolie> spiv, so re https://bugs.edge.launchpad.net/launchpad/+bug/615740
<ubot5> Launchpad bug 615740 in Launchpad itself "test_on_merge.py doesn't handle eintr (affected: 1, heat: 6)" [Undecided,New]
<poolie> what the best plan for handling eintr now?
<poolie> such a saga...
<spiv> poolie: depends!
<poolie> so there's one select call that's failing
<spiv> poolie: don't have any signal handlers is a good plan, if you can
<poolie> oddly, raising select.error not IOError
<spiv> poolie: if you can't, register it with signal.siginterrupt is good, if you can assume python >= 2.6.6
<spiv> if you can't do that (you do want the signal to interrupt syscalls, or you can't assume 2.6.6), then your options are less good.
<spiv> select at least is safe to retry the call, if it's happening in your own code.
<poolie> i think it is
<poolie> i don't know if lp assumes 2.6.6 yet?
<poolie> probably not
<spiv> Given that 2.6.6rc1 only just hit maverick, I doubt it :)
<spiv> Ok, I need to wind up for the day, but at least I have code that makes 'bzr reconcile' fix non-canonical CHKs now.
<poolie> yay
<dakira> hi.. how do I get only a list of modified/added files for the last few commits?
<luks> dakira: bzr st -r -3 (last two commits)
<dakira> luks: great.. thx!
<fullermd> Note the difference between "-r-3" (compare rev -3 to the current working tree status) and "-r-3.." (compare rev -3 to the latest commit)
<dakira> fullermd: so "-r -3" == "-r-3.."?
<fullermd> No, "-r-3" == "-r-3"...  I don't think there's any long form.  "-r-3.." == "-r-3..-1"
<dakira> fullermd: look closely... not "-r-3" but "-r<space>-3".. the latter seems to be equivalent to "-r-3.."
<luks> "-r-3.." != "-r-3..-1" because the range is exclusive
<fullermd> They're the same thing, space or not.
<fullermd> Standard option parsing.
<fullermd> Er, -r-3.. IS exactly the same as -r-3..-1.  Open ended ranges go to the end of the tree.
<luks> then my bzr is doing something wrong :)
<fullermd> (well, mod some bugs that have existed in the past with parsing them at least)
<luks> oh
<luks> my bad
<luks> it's sorted differently
<luks> I wonder why -r-3..-1 isn't sorted
<fullermd> Any other day, I'd say "I dunno".  Today, the answer is obviously "the world is out to get me".
<dakira> luks: hm.. -r-3.. and -r-3 give me the same results (they compare with the working tree) while -r-3..-1 compares with the last commited revision!
 * fullermd frowns.
<fullermd> That's...  unexpected.
<spiv> I occasionally think that -0 should mean "working tree".
<fullermd> I'd rather have a tree: or something.
<spiv> Then I go have a nice cup of tea in a quiet corner somewhere and reason returns ;)
<fullermd> Well, I do see that listed behavior.  I'm pretty sure it used to be like I think it is, so I presume it was changed intentionally...  I don't think I like it though.
<fullermd> spiv: Really, it should be "+1"  ;p
<spiv> fullermd: no, 0 comes after -1
<spiv> fullermd: and the uncommitted working tree is the nearest thing we have to the next revision after the most recently committed one...
<fullermd> Yes, but 0 is already taken for null.  Anyway, we want to go one rev forward from the current state, so...
<spiv> Right, hence -0 ;)
<fullermd> Of course, since it's not committed yet, it's not real.  So, it should be 'i'.
<fullermd> Unless, of course, we steal the imaginary axis to be the timeline along which we allow editing commit logs...
 * fullermd goes off and hides.
<spiv> $\lim_{revno\to 0}revision(revno)$
<dakira> fullermd: here's what I get http://pastebin.com/NvRWeNWq
<spiv> Or something.
 * spiv wanders off
<dakira> bzr is 2.1.1
<dobey> james_w: a_branch is a tarmac.Branch, and its commit method calls the bzr commit with committer='Tarmac'
<james_w> dobey: ok, given that I can't see this code I'll have to take your word for it. Also given that I can't see it I can't help you debug it any more.
<dobey> http://bazaar.launchpad.net/~rockstar/tarmac/main/annotate/head%3A/tarmac/branch.py
<dobey> http://bazaar.launchpad.net/~rockstar/tarmac/main/annotate/206/tarmac/tests/test_branch.py#L40
<bialix> ddaa: hello
<ddaa> hey bialix
<dobey> i'm trying to get those tests back in trunk and working again. and i almost had it. the commit() worked fine yesterday morning, and the started failing after i ran update-manager and bzr got upgraded to 2.2.0
<james_w> dobey: I don't know. It seems to pass it down ok, but it clearly uses it, you might want to pdb and find out at what level it loses it.
<dobey> yeah, i went hunting through the code path from the stack trace last night and didn't see anything obvious in the code :-/
 * jelmer waves to james_w, dobey
<james_w> hi jelmer
<dobey> hi jelmer
<dobey> ah, how the little things can wreck havoc
<dobey> a_branch.*tree*.commit() is not a_branch.commit(). sorry :)
<jelmer> hehe
<jelmer> been there, done that.. with the exact same method.
<dobey> with commit --fixes in bzr, does it store the url as lp:NUM or http://bugs.launchpad.net/bugs/NUM ? or something else?
<jelmer> dobey, the latter
<jelmer> dobey: see also "bzr cat-revision", that will dump the raw representation of a revision
<dobey> ah
<dobey> thanks
<abentley> Anyone have a suggestion on how to debug InvalidUseOfScopeReplacer in the Launchpad test suite, when the test, run by itself, doesn't cause it?
<abentley> I've been trying to backtrack to find the test that is abusing the scope replacer, but so far no dice.
<mgz> nope, 's one of the oddities I've run into before and not had time to track down.
<mgz> a bunch of the doctests fall over with it on ironpython and jython.
<abentley> mgz, with the Launchpad test suite or the bzr test suite?
<mgz> in bzr, sorry.
<Typh> If I push to a location, why would then running bzr update in that location produce "bzr: ERROR: No WorkingTree exists"
<GaryvdM> jam: For  some reason, paramiko is no longer being included in libary.zip
<jam> hmmm. I wonder if it got installed as a plain .egg
<jam> .egg doesn't work with py2exe
<GaryvdM> Typh: If you push to a remote location, working trees are not created.
<GaryvdM> jam: Yes  - It is installed as an .egg
<GaryvdM> Typh: you can create the working tree by running bzr checkout
<Typh> GaryvdM: oh. oops :D. thanks.
<GaryvdM> Typh: and if you push to a remote location that allready has a working tree, it will then be out of date, and will need a bzr update
<GaryvdM> Typh: This is due to limitations in the remote protocols.
<bialix> heya Gary!
<GaryvdM> Hi bialix
<bialix> did you saw my messages?
<GaryvdM> bialix: Yes - was just going to reply.
<rubbs> Typh: also, if you are pushing to a remote location just to update files for say a webserver, you may want to look at some plugins like push-and-update. I'll see if I can dig up relevant links
<bialix> ok
<Typh> rubbs: no no, I was just trying to recreate a borked checkout on the server. I've never had to push a brand new copy anywhere before :)
<rubbs> Typh: ah, cool. Just checking.
<GaryvdM> bialix: Surely there is a syntax that will work for both versions. I'll take a look.
<jam> GaryvdM: I'll log in now and try to fix that
<jam> GaryvdM: I needed to do "python setup.py install -O1 easy_install -O1 -Z" to get it to not install using an egg
<GaryvdM> bialix: Please could you see if this runs with pyqt4.4: http://pastebin.org/466026
<bialix> GaryvdM: with your patch test suite did not errored, but tests failed
<jam> GaryvdM: it should be fixed now, care to try again?
<GaryvdM> jam: Thanks
<GaryvdM> bialix: Please pastebin test output.
<bialix> GaryvdM: that paste writes success, but is it really success?
<GaryvdM> bialix: Yhea - need to check that it's actually connected....
<bialix> GaryvdM: http://pastebin.org/466035
<GaryvdM> bialix: I think that previously, the connections in that test were not connecting, and the are now, and exposing bugs in the test.
<bialix> ouch!
<GaryvdM> Funny that they are connecting in qt 4.4, and not 4.6/4.7.
<bialix> GaryvdM: I would like to add direct support of colo in qbzr. E.g for commands qswitch, qmerge, maybe others
<bialix> there is custom qswitch in the explorer to understand colo, but I think we can do better in qbzr
 * bialix off to home, bbl
<CcxCZ> is there way to bind branch multiple times?
<GaryvdM> jam: Thanks - that worked.
<GaryvdM> jam: Is there an easy to test the speed of paramiko? I'd like to see if my patch makes it faster.
<jam> GaryvdM: I don't know of any specific way. I assume trying to do an ssh loopback and see how fast you can transmit bytes
<jam> I don't really know how to set that up, though
<GaryvdM> ok
<jam> probably you could do something with a loopback to openssh via sftp, and just try to read a 1GB file
<jam> or ssh localhost dd if=/dev/urandom
<jam> or something like that
<jam> you could do /dev/zero because it is fast, but I think the channel auto-compresses, and that compresses a bit too well :)
<CcxCZ> doesn't urandom wait for entropy?
<jam> CcxCZ: I thought /dev/random did and /dev/urandom layered cryptographic randomness on top of entropy
<jam> psuedorandomness
<CcxCZ> A read from the /dev/urandom device will not block waiting for more entropy.
 * CcxCZ RTFMed
<fullermd> Yeah, it's the other way around.  urandom doesn't block; random does.
<CcxCZ> though that's not very good for benchmark I guess
<jam> GaryvdM: if you don't mind working through the bzrlib api, you could probably just use "t = bzrlib.transport.get_transport('sftp://localhost/...'); t.get_bytes()"
<jam> That handles all of the "how do I set up paramiko" stuff :)
<GaryvdM> jam: I specifically want to see if I'v removed the "1-2 seconds" that you mention in Bug 271791
<ubot5> Launchpad bug 271791 in paramiko "Paramiko depends on RandomPool (affected: 3, heat: 17)" [Medium,Triaged] https://launchpad.net/bugs/271791
<jam> GaryvdM: well that is easy to tell
<jam> bzr log sftp://host
<jam> we've patched pycrypto repeatedly for that IIRC
<jam> however, you also have to have a system where time.time()'s resolution is 15ms
<jam> 1ms is fast enough to not really notice 100 calls.
<jam> 1ms == 100ms total, 15ms == 1.5s total, very noticeable
<jam> you can do a loop on time.time() to determine the resolution
<CcxCZ> anyway I guess there isn't simple way synching multiple branches at once. As I look in .bzr/branch/branch.conf, there can be only one bound branch.
<GaryvdM> jam: I have 1ms time.time() resolution, so I guess I won't be able to test.
<jam> GaryvdM: well, IIRC 'import paramiko' triggered it, you could see if it takes 100ms to do so.
<jam> However, I'm pretty sure that code doesn't exist in pycrypto 2.1+
<jam> They, at least, rejected my patch for it on the basis that you shouldn't be using that code anywy
 * GaryvdM going to get food, while I wait for my build to download.
<dobey> i'm not overly familiar with bzrlib, but i need some help with getting revision properties out of the revisions from one branch that are being merged into another
<CcxCZ> dobey: can you elaborate on that?
<dobey> i have one branch that has some revisions, with multiple revisions where one revision has a bug fix, but the last revision does not for example
<dobey> and when i merge that branch into another, i need to get all the bugs revision properties for all the revisions that are being merged in
<dobey> but it's not clear to me how to do that exactly
<dobey> i can get properties from the last revision, but it's not clear to me how to get them for all of the revisions which are being merged
<GaryvdM> dobey: Maybe take a look at what bzr missing does.
<GaryvdM> debey: It will involve some graph call, which, I'm not sure.
<GaryvdM> dobey: If you look at bzrlib.missing._find_unmerged , It's quite clear.
<GaryvdM> Instead if the remote_branch.last_revision_info(), use the last revision that you used when you looked at the branch.
<GaryvdM> dobey: You can also look at the revisons that have been removed from branch using uncommit, or pull/push --overwrite
<abentley> jam, I'm trying to debug an InvalidUseOfScopeReplacer in the Launchpad test suite.  Unfortunately, it's not clear what test is actually misbehaving the tests that raise it run fine by themselves.
<abentley> jam, do you have any suggestion how to debug it?
<dobey> GaryvdM: hrmm, i'm doing a missing._find_unmerged to try and see what's going on, and i get an error:
<dobey> bzrlib.errors.ObjectNotLocked: <bzrlib.groupcompress._GCGraphIndex object at 0x959156c> is not locked
<GaryvdM> dobey: Things are normally locked by missing.find_unmerged, which then calls missing._find_unmerged
<GaryvdM> dobey: I pointed out _find_unmerged, because thats were the interesting code is.
<dobey> ah
<dobey> GaryvdM: thanks!
<jam> abentley: does it tell you the name of the variable it isn't liking?
<abentley> jam, "ui".
<abentley> jam, it's raised from a use of bzrlib.ui.ui_factory.nested_progress_bar in bzrlib/transform.py
<abentley> jam, my bad.  It's _factory.
<jam> hmm... there is some confused imports in that file, given that 'ui' is in the lazy section and spelled out explicitly as 'bzrlib.ui'
<abentley> jam, http://pastebin.ubuntu.com/476067/
<jam> abentley: no it is 'ui', '_factory' is the LazyObject attribute that failed
<abentley> jam, okay.  I thought you were looking for the attribute it wasn't liking.
<jam> abentley: The attribute in the module, which is 'ui', not the attribute of the lazy object.
<abentley> jam, right.
<jam> Anyway, I've seen this when asking meliae to dump_all_objects() because it touches everything (In that after it is run, something crashes late)
<jam> you might try excluding the meliae tests vs running everything
<jam> (or including it :)
<abentley> jam, I don't think the launchpad test suite runs the bzr test suite.
<jam> abentley: not the bzr suite. But recently someone added meliae support to launchpad
<abentley> jam, hmm.  Okay.
<jam> and I've seen when running bzr, if I ^\ and do a dump, when the process finishes it crashes with the IllegalUse error
<jam> I haven't quite tracked it down yet. (As I don't think meliae should be triggering, but I could see that it might when it tries to call __sizeof__)
<abentley> jam, there are no tests that match 'meliae', so I'm not sure if we're testing it.
<jam> abentley: you might grep the source for 'dump_all_objects()"
<abentley> jam, only used in one place, and its test is disabled because it broke other tests.
<jam> ok, so it isn't me triggering it (directly)
<abentley> jam, no I was asking your advice partly because you're awake, and partly because you implemented lazy imports.
<jam> abentley: you could try something trivial like: http://paste.ubuntu.com/476074/
<jam> sorry, there is some noise there
<jam> just the import ui change
<abentley> jam, that noise looks strangely familiar :-)
<jam> mostly I'm trying to help isolate the issue.
<jam> this sort of thing usually occurs when you do
<jam> from module import attribute
<jam> and in module that is actually a lazy attribute
<jam> spiv tracked down a case where a package imports a submodule and triggers this (if in bzrlib you used lazy_import to get bzrlib.ui, for example)
<abentley> jam, since I can't reproduce the problem without doing a full test run, I've started a full test run with the import changed.
<svaksha> hi, while pushing a branch bzr hangs with "|      2KB     0KB/s | Fetching revisions:Inserting stream ". Any idea why this happens? TIA.
<svaksha> earlier today it allowed me to commit so at the moment i'm not sure if the error is due to the network or something else.
<svaksha> never mind, problem solved, network issue
<digitalice> hi
<digitalice> how can i checkout a single file from a repo?
<digitalice> like in git: git checkout folder/file.txt
<abentley> digitalice, you can't checkout a single file, but you can get a copy of one using "bzr cat branch/file.txt > file.txt"
<digitalice> no :S?
<digitalice> mmm
<maxb> huh
<maxb> well sulk then :-)
<maxb> I was about to suggest that 'bzr revert file' might actually be wanted
<jam> abentley, maxb: given http://www.kernel.org/pub/software/scm/git/docs/git-checkout.html
<jam> it actually means he wanted "bzr revert"
<maxb> yup
<maxb> !blame git
<jam> Apparently 'git checkout PATH' is revert the content
<jam> to the explicit value
<jam> not exactly what I think of for checkout, but maybe it fits gits model
<jam> since 'git checkout' is turn the wt into a given revision (possibly based on branch pointer)
<maxb> git has this madness where several commands do almost completely different things depending on whether they act on the whole tree or specific paths
<abentley> jam, crazy.
<jam> abentley: :)
<jam> abentley: for https://code.launchpad.net/~abentley/bzr/revision-id-from-committer/+merge/32246 why only target 2.2 and not older releases?
<ddaa> It probably makes some sense. My guess would be: ease of implementation
<abentley> jam, the bug doesn't cause pain in earlier releases because they won't raise NoWhoami.
<ddaa> since that seems to be an overriding design factor in git
<jelmer> jam: As somebody who has used git on a regular basis, that use of "git checkout" doesn't make sense to me either.
<rubbs> git is confusing
 * rubbs is grateful he learned with bzr, it just makes sense
<maxb> I agree - so much more that git, even a little more than mercurial, bzr's concepts and UI are definitely a strong point
<maxb> (And to anyone who wonders what I meant about mercurial.... 'hg resolve' == 'bzr remerge')
<rubbs> right, and to be honest I find the one directory per branch a feature. also the lack of a staging area (just why?) and sane by default actions.
<rubbs> and the empty directory tracking has saved my bacon before
<maxb> mhm. I'm not sold on the one directory per branch thing, but the rest, yes.
<jelmer> maxb: There is a patch in progress to resolve that :-)
<maxb> Yes. I'm eagerly looking forward to it :-)
<maxb> It would help my case for adopting it at work, where we do java stuff. Java IDEs tend to make project setup / pointing at a new filesystem directory more heavyweight than it should be
<maxb> Although Bazaar's lacklustre Eclipse support is likely still going to be a major sticking point
<jelmer> maxb: I guess lightweight checkouts can be of use there, but unfortunately their setup is less trivial than colocated branches.
<rubbs> ah, yeah I can see the colocation being an issue with IDE's. I'm a sysadmin so most of my "coding" is done in Vim.
<maxb> The problem with lightweight checkouts is that they make sense to someone who has bought into bazaar, but look like a lot of work to someone who has not
<krisives-gearbox> Does anyone know how nested branch support is started/coming along?
<GaryvdM> jelmer: Did you want me to run the test suit on bzr-svn tip, or the last release?
<jelmer> GaryvdM, tip please
<GaryvdM> ok - Doing that now
<jelmer> GaryvdM: also, thanks for doing so!
<GaryvdM> Sure, np
<GaryvdM> jelmer: Sorry - bug seems to still exist.
<jelmer> GaryvdM: ok
<jelmer> GaryvdM: Thanks for checking.
<GaryvdM> jelmer: we need to nag vila to add our plugins to babune...
<jelmer> yeah
<GaryvdM> I'm also hoping to setup a daily build of the windows installers
<abentley> krisives-gearbox, AFAIK, no one is working on it.
<krisives-gearbox> abentley: Is the draft doc rather complete?
<abentley> krisives-gearbox, I don't remember.  It certainly wasn't approved, though.
<krisives-gearbox> abentley: Where would I go to help that get into motion? My employer wants the feature and is willing to commission it
<abentley> krisives-gearbox, you shoul talk to poolie.
<krisives-gearbox> abentley: Does that involve idling in IRC all the time ?
<abentley> krisives-gearbox, he also can be emailed at mbp@canonical.com
<GaryvdM> jam: I'm done on the ec2 instance. So you can shutdone if needed.
<krisives-gearbox> Oh, Martin Pool
<GaryvdM> jam: Can we please save it state to.
<GaryvdM> jam: The paramiko patch is working nicely.
<jam> GaryvdM: starting a bundle request now
<GaryvdM> jam: Thanks for the use of it. Now that I have had the confidence of doing a few builds, I'm going to try build my own build host in a vm.
<GaryvdM> Maybe setup nightly builds.
<jam> GaryvdM: that would be nice. Though we may just want to get it set up on babune
<jam> once vila gets back
<jam> (next week)
<latexer> hey everyone... when using bzr on windows (Win7), I was expecting to be able to put a .ssh/config file in place to override the User config for a certain host...
<latexer> but it doesn't seem to obey/work.
<latexer> I've tried in C:\Users\foo\.ssh\config and C:\Users\foo\AppData\Roaming\.ssh\config
<latexer> neither seem to have an effect.
<latexer> Any suggestions?
<lifeless> are you using putty ?
<lifeless> or openssh ?
<lifeless> if you're using openssh, wherever your openssh looks for the config should work
<latexer> AFAIK, openssh, I used the "standalone" installer to install bzr.
<lifeless> if you're using putty, I think you need to use pageant or whatever
<lifeless> the standalone installer uses putty I think
<lifeless> what change do you need make on a per-host basis (there may be another way to change it)
<latexer> lifeless: it says: "Connected (version 2.0, client OpenSSH_3.8.1p1)" when connecting...
<maxb> Or perhaps bzr on windows might be using paramiko?
<lifeless> latexer: ok definitely openssh then :)
<latexer> lifeless: yeah, so I was trying the usual OpenSSH spots, no luck.
<latexer> lifeless: suggestions for how to find out where OpenSSH is looking?
<lifeless> well, we run ssh pretty simply
<lifeless> uhm, sysinternals have a strace-like tool
<lifeless> you could use that
<latexer> lifeless: oh, indeed. I'll give that a try.
<latexer> lifeless: thanks.
<_habnabit> Is there a bzr command that just returns the URL a branch is bound to?
<_habnabit> Nothing more or less.
<Meths> bzr info with a bit of grep?
<_habnabit> I was hoping to avoid post-processing.
<_habnabit> I guess I could make a plugin to do it.
<Meths> Well when a branch can have no URLs or many what kind of output do you actually want?
<_habnabit> A branch can be bound to multiple URLs?
<Meths> well, not bound probably, but push and pull can be different
<_habnabit> Yeah. I'm only talking about the bound URL.
<lifeless> bzr info only atm
<lifeless> I think you need a 3-line python script / plugin
<_habnabit> Mmkay.
#bzr 2010-08-11
<spiv> lifeless: actually "Connected (version 2.0, ..." means paramiko is being used.  The "client OpenSSH_3.8..." in that string is actually paramiko reporting the server version.
<spiv> lifeless: I filed a bug on paramiko about that recently.
<lifeless> grah
<lifeless> thanks
<spiv> poolie_: http://sphinx.pocoo.org/ext/extlinks.html
<poolie_> spiv, https://code.edge.launchpad.net/~mbp/bzr/doc-2.2/+merge/32293
 * spiv is done for the day, see you tomorrow.
<bialix> hi all
<amanica> dipnlik: I could not find such a bug (https://bugs.launchpad.net/bzr-rewrite/+bugs?field.searchtext=dryrun), so maybe you can file one if you like.
<amanica> ehm. ignore that
<jml> anyone know where I can find the branch management plugin vila was working on?
<rocky> jelmer, quick question for you... if i'm working in a local bzr branch that has a remote svn parent (pushing/pulling) with bzr-svn ... and the remote branch makes changes and i merge them locally, when i push back, will it try and push back the merge?
<jelmer> rocky: Yes
<rocky> even tho the merge should be empty right?
<rocky> that feels like ugly artifacts
<jelmer> rocky: Why would it be empty? That merge would contain their change.
<jelmer> rocky: If you don't want a merge commit to appear, use rebase
<rocky> hm
 * rocky has to think about this some more
<jelmer> rocky: bzr-svn isn't any different from "normal" bzr in this regard.
<rocky> sure, of course i use bzr-svn more often then i use regular bzr ;)
<jelmer> heh, ok
<quicksilver> is there a good solution to the umask issue?
<quicksilver> (that newly remotely pushed branches don't get group writable, and I want them to)
<jelmer> hi quicksilver
<jelmer> quicksilver: I'm not aware of one, but jam might know.
<jam> jelmer, quicksilver: The only thing I've seen is writing a bzr wrapper that calls 'umask 002' before execing bzr proper
 * quicksilver nods
<jam> or similarly for sftp, etc.
<quicksilver> I wondered if it could be fixed in SSH config somehow
<jam> quicksilver: IIRC you can change the global default umask in one of the /etc files
<jam> or something like this: http://jeff.robbins.ws/articles/setting-the-umask-for-sftp-transactions
<jam> http://jeff.robbins.ws/articles/setting-the-umask-for-sftp-transactions
<jam> but bzr doesn't run as a subsystem, just another remote command
<jam> quicksilver: I'm never quite sure whether profile or whatever gets run
<jam> but I think changing /etc/profile.d to set a default umask for everyone to 0002 would get invoked
<jml> is there a way to specify an SVN revision when using bzr-svn?
<jelmer> jml: -rsvn:42
<jelmer> jml, see also `bzr help revisionspec`
<jml> jelmer, it doesn't show up there
<jelmer> jml: that's odd, do you have a recent (less than a year old) version of bzr/bzr-svn?
<jml> huh, I don't even have it installed :)
<jml> I'm using a bzr branch made with bzr-svn :)
<jml> jelmer, sorry for the noise.
<jelmer> np
<lamont> can I tell .bzrignore to ignore everything in foo/ except foo/bar?
<lifeless> yes
<lifeless> you can give it a regex
<lifeless> OTOH
<lifeless> you can just add foo/bar
<lifeless> adds override ignores
<lamont> though changes would still be ignored, yes?
<lifeless> to added files? no
<lamont> so bzrignore is regex(5)?  extended or non?
<lifeless> bzr help ignores
<lifeless> its zsh globs
<lifeless> with an optional make-a-line-a-regex mode
<lifeless> lamont: whats the situation though, I doubt you need this
<lamont> whole bunch of stuff in foo, only want foo/bar to be in bzr from that directory
<lifeless> yeah
<lamont> themes-y stuff
<lifeless> just bzr add foo/bar
<lifeless> done
<lifeless> bzr ignore foo
<lifeless> bzr add foo/bar
<lifeless> win
<lamont> ta
 * lamont looks at the clock, sleeps
<abli> Hi! any idea what might be causing 'Permission denied (publickey)' errors when I am trying to check out (branch) a branch from launchpad? 'bzr branch' says: "bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist." To make it more misterious, branching the same repo works as another user on another computer
<lifeless> do you have your ssh key present /unlocked
<abli> present?  what does that mean? I am trying to do an 'anonymous checkout'
<lifeless> what url are you giving bzr ?
<abli> bzr+ssh://bazaar.launchpad.net/~gregor-muellegger/django-sorted-m2m-field/trunk/
<lifeless> that uses ssh
<lifeless> so you need your ssh key on your machine
<abli> hmm. I'll try bzr+http
<lifeless> just http://
<abli> do I also need an account on launchpad?
<lifeless> no bzr+
<abli> ok
<abli> ah. http:// worked. Thanks!
#bzr 2010-08-12
<wilco> I see there's bzr-svn which seems to work like git-svn, where I keep my central SVN repo; is there an svn gateway for the hold-outs? Most of my team wants to use something more advanced than svn, but there are a few low-level folks that would need too much re-training
<amanica> wilco, I'm not sure what you mean. You can keep everything in a svn repo and then use bzr-svn as a svn client
<amanica> I do that a lot, but I prefer to use bzr for central server too
<wilco> I'm thinking of something like git-cvsserver, but for bzr & svn... I don't want to hobble my central-server-side capability but I want to not break everyone's docs + training
<amanica> wilco, I don't know of a something that works like that. afaik if you want to have pure svn clients, you need a pure svn server
<wilco> I see
<wilco> Thanks for the info
<jelmer> wilco, there is an experimental svn server on top of bzr, but it's not finished yet
<jelmer> wilco, 'bzr serve --svn' IIRC
<wilco> jelmer: Interesting; thanks.
<wilco> any idea of how incomplete it is? I don't see anything in the bzr package docs
<jelmer> wilco: it only implements some parts of the svn smart server protocol, e.g. "svn log". It lacks a few important commands, including checkout.
<spiv> Good morning.
<jelmer> wilco: it's built as a thin layer on top of bzr-svn. I started on it about a year ago but haven't had time to spent on it since.
<poolie> hi spivvo
<wilco> Oh. I was hoping "incomplete" meant a lack of svn attributes and such.
<AfC> jelmer: I know you did a bzr-git release recently. Any chance we can get someone  to put that into the Bazaar PPA?
<AfC> bzr-git crashes for me at the moment, unfortunately [I mean, sure, {shrug} but I daresay it's long since fixed]
<jelmer> AfC: I'm happy to upload to the PPA just now, but I won't make any promises about keeping it up to date...
<jelmer> poolie, spiv: Who is maintaining the PPA these days?
<AfC> jelmer: hey sure :)
<AfC> Come to think of it, shouldn't bzr 2.2 be in the PPA now, too?
<AfC> anyway
<AfC> boat to catch
<poolie> jelmer, mostly me?
<poolie> feel free to upload
<jelmer> poolie: ok
<jelmer> I've just asked the Debian release team for a freeze exception for bzr 2.2 in squeeze
<jelmer> bzr was released just one day after squeeze was frozen, apparently :-/
<poolie> oops
<poolie> did they have 2.2b4? it's a tolerably small change from that
<AfC> jelmer: sorry to drop out on you
<lifeless> AfC: jelmer has halted() :)
<AfC> lifeless: just so as someone reboots him in the morning, we're fine.
* spm changed the topic of #bzr to: Launchpad down/read-only from 0800-0930 UTC for a code update | Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | bzr 2.2-final has gone gold, build those installers
<spiv> Launchpad down... sounds like time to finish work for the day :)
<poolie> good night spiv
<sender> Hi, question: I'm trying to push and get this warning: bzr: ERROR: Working tree "/var/www/" has uncommitted changes (See bzr status). Use --no-strict to force the push.
<sender> Running bzr status, gives me no output. Anyone has an idea what's going on?
<poolie> sender: that's strange
<sender> poolie: thanks... I thought so too. I've tried to sudo both commands. Don't know if that could help, but it didn't. :(
<poolie> and does the push succeed if you do use --no-strict
<poolie> sudo isn't likely to help except for things like permission problems
<sender> poolie: bzr status -S gives me: +   database/db.sql
<sender> poolie: I just rm'ed this file... it was never versioned.
<sender> poolie: is it normal that something shows up in bzr status -S, and not with bzr status?
<poolie> no!
<sender> :(
<poolie> what does 'bzr --version' say?
<sender> Bazaar (bzr) 2.1.1
<sender> poolie: can this be a cause: I got permission errors on ~/.bzr_log, I've chown'd that file to my own user
<sender> poolie: is there a way to verify my bzr repo?
<poolie> 'bzr check'
<sender> poolie: running bzr check now
<poolie> so bzr status really just says nothing?
<sender> that's correct
<poolie> sender: that's really weird, i can't imagine a bzr bug that would make things show up in short mode but not otherwise
<sender> poolie: bzr check didn't return any errors so it seems
<poolie> what does 'bzr st database/db.sql' show you?
<poolie> or 'bzr ls' that file
<mvo> I get the following error on bzr diff http://paste.ubuntu.com/476834/plain/ (version 2.2.0)
<mvo> is there anything I can to do recover?
<sender> poolie: bzr: ERROR: [Errno 2] No such file or directory: '/var/www/database/db.sql'
<sender> poolie: on bzr ls that file
<poolie> sender: and 'bzr info'?
<sender> poolie: bzr status that file gives me nothing
<sender> poolie: (format: 1.9-rich-root)
<poolie> sender: is that file perhaps a symlink ?
<sender> poolie: and related branches... normal stuff
<sender> nope
<poolie> how about plain 'ls -ld /var/www/database/db.sql'
<mvo> is that/could that be releated to LP being down?
<sender> poolie: no connection with LP
<sender> poolie: it's a local project
<sender> poolie: ah I remember: I added the file, then rm
<sender> 'ed it (sorry for the \n)
<sender> poolie: I think I might be able to resolve it by reverting the file...
<sender> poolie: but that doesn't change the fact that status and status -S have a different output
<sender> poolie: and that I can't push without --no-strict...
<poolie> mvo: it's possible, but it's probably not related
<poolie> mvo: is this a new local branch?
<poolie> mvo, can you please file a bug and ask jam to help when he wakes up?
<mvo> poolie: its a checked out branch I was using for some time but recently upgraded to the latest format
<mvo> poolie: sure, will do
<mvo> thanks!
<sender> poolie: should I try to revert the file? Or did I hit a serious BZR bug?
<sender> poolie: Ok bzr revert . did resolve the problem
* spm changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | bzr 2.2-final has gone gold, build those installers
<quicksilver> bzr merge from an old repo format into a new one is a bit broken
<quicksilver> you probably don't care much but I thought I'd remark on it.
<bialix> quicksilver: please, file a bug report
<quicksilver> first of all it said "ERROR: Branches have no common ancestor, and no merge base revision was specified"
<quicksilver> which was not the case
<quicksilver> and then after specifying revision numbers it came up with hundreds, lierally, of conflicts.
<quicksilver> upgrading the old repo first fixed it all.
<quicksilver> I'm not really in a positon to file a reasonable report, and I don't have time today.
<quicksilver> I'll make a note to try to do so next week.
<bialix> quicksilver: error about common ancestors seems familiar for me, what is your bzr version?
<quicksilver> just checking.
<quicksilver> 2.1.0
<quicksilver> the "new" format repo was Bazaar Branch Format 7 (needs bzr 1.6)
<quicksilver> the "old" one was Bazaar Branch Format 6 (bzr 0.15)
<bialix> what is repo format?
<quicksilver> I thought that's what that was
<quicksilver> how do I find out?
<quicksilver> I did cat backup.bzr/branch/format
<quicksilver> to get that part above
<bialix> bzr info -v
<quicksilver> but you need it for backup.bzr I guess?
<bialix> it said about both branch and repository
<bialix> maybe
<quicksilver> ah
<quicksilver> cat  backup.bzr/repository/format
<bialix> then repository/format
<quicksilver> Bazaar pack repository format 1 (needs bzr 0.92)
<quicksilver> new is Bazaar repository format 2a (needs bzr 1.16 or later)
<bialix> ah, rich-root vs poor-root
<bialix> I'd suggest to check with bzr 2.2
<quicksilver> bialix: If I copy the old backup.bzr to .bzr then I have the old repo back for reproduction purposes, right?
<quicksilver> (there never was a working tree anyway)
<bialix> yep
<bialix> sorry, bbl
<jam> mvo: hey, I missed the start of the conversation, but I'm around if you wanted to chat about something
<thrope> is there a way to get a list of controlled files? ie like bzr status but list files that are unmodified
<mvo> jam: I had a problem with my bzr branch, I solved it/worked around it now by using the .bzr dir of a fresh checkout. its the first time this ever happend to me, so it might just be local corruption, not sure its woth debugging it
<thrope> ah bzr ls -V is what I was looking for
 * lamont found 616878 to be most annoying
<jelmer> bug 616878 ?
<ubot5> Launchpad bug 616878 in bzr (Ubuntu) "bzr commit error because of no identity (affected: 1, heat: 8)" [Undecided,New] https://launchpad.net/bugs/616878
<lamont> perfectly good repo, commit requires 2 commands instead of 1
<lamont> in about 400 repos
<lamont> with something like 10 users
<mgz> if you're really doing it that many times, you can write yourself a two line shell script
<jelmer> lamont: previously bzr would use "$USERNAME@$HOSTNAME" and that caused some people to do a lot of commits without a valid email address. IIRC that was the reason this check was put in place.
<jelmer> allowing anonymous commits is reasonable, perhaps we should have "bzr whoami --anonymous" ?
<jelmer> or maybe just "bzr commit --anonymous" ?
<mgz> that bug should probably be converted into a question or something
<mgz> I agree the --anon commit idea is good though, provided it doesn't just get misused
<lamont> mgz: yes, we could, and we will.  just not very happy about it.
<mgz> well, surely it's better than leaking your username and hostname into the repo?
<lamont> these repos never do anything that has anything to do with emailing anything.
<lamont> nor does the repo ever leave the machine in question, other than in backups
<jelmer> lamont: Is it really anonymousness you're after or just wanting to avoid extra configuration ?
<jelmer> it sounds like it's more about configuration than anonymousness
<lamont> it's really just having bzr commit keep working across the upgrade that I'm after... really don't care what the user/email addr are in the commit
<mgz> okay, so we've caused you some pain.
<jelmer> lamont: So it's the extra configuration that was previously not necessary.
<mgz> in your case for no gain, but bar reverting the change (which I think is a bad idea), what can we actually do to help you?
<jelmer> lamont: it will use the EMAIL or BZR_EMAIL environment variables if set, if that helps.
<lamont> jelmer: does it only care about email?
<jelmer> lamont: it doesn't really care about the value, just that there is something set explicitly.
<lamont> cool
<lamont> jelmer: you wanna throw that into the bug as a comment/workaround suggestion?
<lamont> otherwise, I will
<jelmer> Yeah, sure
<lamont> ta
<jelmer> mgz: what do you think about warning rather than errorring out completely ?
<Ng> what about etckeeper? it is a robot doing commits to bzr. a robot with no email address
<Ng> just as a random thing in the ubuntu archive which does non-humanic commits ;)
<jelmer> Hi Chris
<jelmer> Ng: it sets EMAIL explicitly IIRC
<Ng> if it is, it's using $USERNAME@$HOSTNAME? ;)
<jelmer> yep
<mgz> jelmer: but what would bzr do after issuing the warning?
<jelmer> ./commit.d/50vcs-commit:		export EMAIL="$USER <$USER@$hostname>"
<jelmer> mgz: continue on doing the commit
<mgz> using what as the email?
<jelmer> mgz: the guessed email address (as we did prior to 2.2). The user can always uncommit and recommit with an email address set.
<mgz> part of the reason I'm glad so see the old code go is that trying to interpret `username + "@" + hostname` as an email adress lead to a lot of bugs
<mgz> both are unicode on windows, and can contain spaces
<mgz> this means unicodeerrors, and code trying to split things getting confused by extra spaces, and so on.
<jelmer> hmm
<Ng> jelmer: well then that's not a great example ;)
<mgz> also, having my local username and hostname end up in some public repo is a bad thing.
<Ng> mgz: because of your specific circumstances, or general position?
<mgz> I prefer getting yelled at.
<jelmer> I like being told, but not being blocked.
<mgz> ng: well, a general position, it's a Bad Thing.
<jelmer> Perhaps we could just use $USERNAME
<mgz> one repo I poked on launchpad had four different contributors depending on which box the guy who owned it was hacking from.
<lamont> other VCS implementations going back a decade or so use $USERNAME@$FQDN
<lamont> rather than the short hostname
<mgz> might work on a university box,
<mgz> but who has a sensible domain set up from their home machine?
<Ng> mgz: why does that matter?
<lamont> mgz: many of us do
<mgz> I like clean repos with readable blame and stats.
<Ng> then make whoami procedure for your employees :)
<mgz> I'm a lone hacker, and it's other people's repos I worry about.
<jelmer> mgz: I don't think that's a reason to force everybody to have a sane committer email address...
<mgz> I think telling them is better than using an insane address.
<elmo> mgz: you're assuming the email address matters
<mgz> if they want to use something odd, they can set whoami to (nearly) whatever they like
<jelmer> mgz: Telling them is different from forcing them to use a sane address.
<elmo> mgz: that's not a reasonable assumption
<mgz> I think the user *id* matters
<mgz> which unfortunately means Name <Email>
<mgz> the user id is baked into every commit made.
<Ng> what this discussion clearly shows to me is that this is a local policy issue
<mgz> what this discussion shows is that four people are awake currently.
<jelmer> mgz: I count 5 >-)
<mgz> I don't think you can draw big conclusions, but bugging people is always unpopular, sure.
<mgz> whatever happens that isn't a return to buggy code that doesn't even make much sense on nix, I'll live with
<lvh> hey
<jelmer> hi lvh
<lvh> any eclipse+bzr users here? I'm somewhat confused as to how you use the plguin effectively
<lvh> the only way I can figure out is if you use lightweight checkout and switch all the time
<mgz> switching is fine.
<lvh> the other way is if each branch is its own project
<lvh> mgz: I've never done it. What docs should I read? bzr switch manpage?
<mgz> you can have a shared repo with no trees, and one tree under it for eclipse
<mgz> then switch that tree between the other branches on the repo as you work on them
<mgz> I think there was something on the list quite recently with directions you could read...
<maxb> That's basically the only way I can see making sense - it's a shame Eclipse makes it so hard to add/remove projects.
<lvh> yeah
<lvh> it's definitely eclipse's fault but you know it's a sad day when hg integration makes me happier than bzr integration
<maxb> Well... MercurialEclipse is vastly more advanced than bzr-eclipse
<maxb> And qbzr-eclipse, whilst useful, isn't exactly an Eclipse integration
<maxb> I would love to push bzr at work, but this is my primary inhibitor
<jelmer> mgz: fwiw I don't think we should pretend we can guess the email address by using $USERNAME@$HOSTNAME. I'd rather just use the $USERNAME as the full committer text and be done with it; we already have to deal with that situation in other cases anyway when we import committers from svn or cvs.
<mgz> jelmer: encoded as utf-8?
<jelmer> mgz: Yeah (we already mandate that the committer field is encoded as utf8)
<mgz> lvh: this is actually about large repos, but the workflow is the one you want: https://lists.ubuntu.com/archives/bazaar/2010q3/069499.html
<mgz> (maxb can correct me if there's anything wrong)
<maxb> I don't think so
<basic`> Hi everyone, is it possible to force filesystem permissions in bzr?  We're using it for drupal.org webroots and for whatever reason new files are being added with rw------- / 600 permissions that can't be read by the webserver
<basic`> has anyone hit an issue similar to this?  the files in the repository checkout that the commits are coming in from have 664 permissions
<basic`> i read over https://bugs.launchpad.net/bzr/+bug/67589 but it didn't seem to be the right issue
<ubot5> Launchpad bug 67589 in Bazaar "bzr does not store permissions (affected: 0, heat: 1)" [Wishlist,Confirmed]
<maxb> basic`: I would check the umask of the user executing bzr on the webserver
<basic`> maxb: it's 022 like the other users
<maxb> that is surprising
<basic`> it should be creating directories with 755 and files with 644
<basic`> and it seems to be working for the other sites under bzr.. let me test
<basic`> maxb: actually... i take that back it looks like the umask is different on the box that has the nfs mount and these updates are being run... that explains it
<basic`> wait, it's even more permissive on that box (0002)
<maxb> odd.
 * maxb afk now
<basic`> maxb: thanks :)
<dlee> Trying to find revisions lost on revert.  Sequence done: unbind, local commits, bind, update... got a bunch of unexpected conflicts apparently caused by case differences in folder names... mistake?: did a revert, but now I can't find any of my local revisions.  Can I get them w/o knowing revids??
<james_w> dlee: "bzr heads --dead"
<james_w> from bzrtools
<james_w> that should show you the tip revision you had before the upload
<james_w> update I mean
<dlee> I thought bzrtools was integrated now... uknown command "heads" bzr 2.0.0 here.
<dlee> I can probably get that part to work... but on finding it, can I still reintegrate those local commits?  I had planned to do update/rebase/commit to update the upstream repo.
<dlee> Found the revids using a 2.2.0 where "heads" works... so down to that above question. :)
<james_w> dlee: you can either "bzr pull --overwrite -r revid" to get back to where you were before you started
<james_w> or "bzr merge . -r revid" to get back to where you were before the revert
<dlee> Hmm... pull, when the found revid is only local?
<james_w> err, yeah, with a dot as well, sorry
<james_w> "bzr pull . --overwrite -r revid"
<dlee> Trying to decide which makes more sense for the ultimate goal, which is to upload my local commits onto the upstream branch, presumably after a rebase.
<dlee> Ah ... the "pull" should literally rewrite everything to where it was, then I can try the original merge again... wonder if --reprocess will help deal with the mess of foldername conflicts...
<dlee> Getting "no such revision" on "bzr log -rrevid:<foundID>" and a traceback, in 2.0.0 and 2.2.0.
<basic`> maxb: so i'm as stumped as you are with the permissions thing... doing another bzr checkout of the tree has the correct permissions
<dlee> JamesW:  Ouch... your "pull --overwrite" suggestion worked, but I forgot to unbind first!  Result: I overwrote the upstream branch with my local one.  Odd though, the upstream branch is supposed to forbid history alterations.
<dlee> The error I mentioned earlier is a bug in "log": It crashes trying to convert a revid to a dotted revno.  I'll file that one when I can.
<orospakr> Hi!  I'm looking through the docs, but I can't find a mode I thought exists for having a smart-server's repo containing multiple-branches in place.  at least, I don't want to have to make a copy of my entire repo on my server for every new branch I want to have.
<orospakr> (my workflow is creating a new branch for each new ticket of work, so super-cheap branches are a must)
<orospakr> ah, http://doc.bazaar.canonical.com/bzr.2.2/en/user-guide/shared_repository_layouts.html#nested-style-project-branch-sub-branch
<orospakr> I think.
<dlee> orospakr: yes, sounds like a perfect time for a shared repo structure.
<orospakr> hm. with that approach (init-repo), do I have to create all new branches on the server by sshing to it and typing a `bzr branch` command in locally?
<dlee> orospakr: You can do that, but you can also push a branch from elsewhere if you have one to push.  Do all branches start from one common branch?
<orospakr> yeah, everything ultimately has a common ancestor. You're saying that if I happen to fork a new branch on my dev machine, I can push that into the server's shared repository without interacting directly with a shell on the server?
<dlee> I doubt "bzr push bzr+ssh://my.domain.com/var/bzr/proj/branch5" from a local copy of the main branch would cost that much... Others can correct me of course, but I doubt that sends all the texts from local to server when the server has a shared repo for the branches.
<orospakr> ah, so if I just give it the path with $existing_repo/my_new_branch, it should Just Work?
<dlee> orospakr: Yes:  If you have, say, done "bzr co bzr+ssh://my.domain.com/var/bzr/proj/trunk," you can do what I showed above to make branch5.
<orospakr> ie., bzr push  bzr+ssh://myserver/$existing_repo/my_new_branch
<orospakr> sweet. it worked!
<orospakr> thanks.
<dlee> orospakr :)
<orospakr> it'd be a bonus if I could avoid typing the "bzr+ssh://myserver/$existing_repo" part every time I want to make a new branch there.
<orospakr> or rather, *push to* a new branch there.
<dlee> orospakr: (1) shell variables.  (2) "bzr bookmarks" etc., if you have bzrtools (I believe that's part of bzrtools at least)
<fullermd> Separate plugin.
<dlee> oops thanks
<orospakr> hm. I wonder, I want to figure out how my colleague can pull that branch onto her machine, without having to make an entire new local branch, with redundant storage of all the history that is already in her local repo of the main branch of our project.
<orospakr> I guess she could branch her local one, and then pulled the new branch from the server into that new local branch.  Requires more steps that I think would be elegant, though.
<rocky--> jelmer, hey... when i merge from a remote svn branch, commit changes in my local branch, and then push back... i get an error saying operation denied because it would change mainline history... did i do something wrong
<rocky--> ?
<jelmer> rock--: No, but you have to realize your change would remove the current tip from the remote branch and replace it with your merge revision.
<rocky--> hm that sounds more intrusive then i'd like
<jelmer> rocky--: That's why it's requiring you to set a configuration option before allowing that.
<rocky--> is there a less intrusive thing i could have done to achieve a similar result?
<jelmer> rocky--: rebase
<jelmer> or you could've merged your branch into an up to date copy of the remote branch and pushed that.
<dlee> JamesW:  If you're still here, thanks much... got all cleaned up and rebased and in sync.
<quotemstr> Say I have a branch in ~/foo/bar/trunk; I'd like to convert ~/foo/bar to a shared repositroy.
<quotemstr> Can I do that by just running (with CWD being ~/foo/bar) bzr init-repo . and bzr branch trunk trunk2 ?
<jelmer> quotemstr: yes, although you can also do:
<jelmer> bzr init-repo . && cd trunk && bzr reconfigure --use-shared
<quotemstr> Thanks.
#bzr 2010-08-13
<poolie> hi all
<spiv> Hi poolie
<poolie> i might catch up on my pilotage today
<poolie> i got a bit further on feature flags yesterday
<jdk2588> I am trying to merge from one branch to another branch and I am getting this error
<jdk2588> http://pastebin.com/Hh522sk1
<poolie> hi jdk2588, this means you, or someone else, has upgraded one of the repositories but not the other
<poolie> if you're running bzr 2.0 or later i would recommend just using 'bzr upgrade' in both
<poolie> it may take a while if the repo is large
<jdk2588> I am using bzr 1.9
<poolie> ok
<poolie> i'd recommend that you upgrade then
<poolie> what OS are you using?
<jdk2588> Ubuntu 8.04
<jdk2588> now I have upgraded but it shows an error that revisions have no common ancesstor
<poolie> ok, and you're pretty sure these branches are in fact related?
<jdk2588> yes , they
<jdk2588> like if I try to merge branch2 into branch1 it works
<jdk2588> but when branch1 into branch2 it shows now the ancesstor error
<fullermd> Probably one of those criss-cross bugs.
<fullermd> ...  though, that wouldn't be order dependent, I'd think...
<fullermd> Does doing `missing` one way or the other reveal anything surprising?
<jdk2588> yeah I was able to merge
<jdk2588> thanks guys
<jdk2588> ok now in the conflicts  what are the three files like <filename>.{BASE,THIS,OTHER}
<jdk2588> can someone just help me with this
<fullermd> That means there was a conflict in the file.
<fullermd> Assuming it's a text file, you'll have "normal" CVS-ish conflict markers in the file itself, you can just resolve in place.  Those 3 files are there if you need to refer to them, or use an external 3-way tool.
<jdk2588> so how should it be resolved , I did read the docs but  could not understand much
 * fullermd shrugs.
<fullermd> Pull it up and see what the conflict is.  Its presence means that bzr couldn't merge it automatically, so it'll have to be your human understanding of the code (or recipe, or whatever it is)
<spiv> Hmm, the docs aren't very detailed on this.
<spiv> jdk2588: the easiest way usually is to open the file, and look for "<<<<<<<"
<spiv> jdk2588: which will be the start of the conflicting region
<jdk2588> ok and I should remove it
<jdk2588> ?
<spiv> Or if you prefer you can use the BASE/THIS/OTHER files (which can work well if you use a tool like 'meld' to help)
<spiv> Well, you should resolve it.
<spiv> Basically, there are two different changes to the same region of the file.
<spiv> And bzr can't apply both of them automatically, so it's up to you to figure out what the right result would be.
<spiv> It might be to just take the THIS version, or the OTHER, or you might need to combine the differences somehow.
<spiv> The right thing to do depends on the individual circumstances, which is why bzr can't just take care of it for you automatically.
<jdk2588> ok got it
<spiv> jdk2588: http://doc.bazaar.canonical.com/bzr.2.2/en/user-reference/conflict-types-help.html#text-conflicts
<jdk2588> ok thanks for help and your link :)
<m3ga> anyone have any ideas how I can recover from this problem : https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/617224
<ubot5> Launchpad bug 617224 in bzr (Ubuntu) "bzr crashes on 'bzr status' (affected: 1, heat: 6)" [Undecided,New]
<spiv> poolie: can you help m3ga?  I think you have wt/dirstate issues more fresh in your mind than I do.
<poolie> oh hi
<m3ga> hi!
<m3ga> bummer to happen last thing on a friday.
<poolie> sorry about that
<poolie> do you recall what you did leading up to this?
<poolie> it looks like bug 373319
<ubot5> Launchpad bug 373319 in Bazaar "mv --auto does not handle directory adds mixed with the contents of a directory splitting in two: InconsistentDelta error (affected: 2, heat: 1)" [High,Confirmed] https://launchpad.net/bugs/373319
<m3ga> bzr rm lib/oldxmlrpc
<m3ga> which was a tree of about 10 files
<poolie> nothing else?
<m3ga> actually, the bzr rm was in a hardy chroot with the hardy version of bzr, but the hardy version screwed is so it remained screwed when i exited the chroot and ran the lucid bzr
<m3ga> on hardy it was bzr 1.3.1
<m3ga> that makes it a little more complicated doesn't it? :-)
<poolie> it might be something already fixed since hardy
<m3ga> get into the problem yes, but getting back out?
<poolie> probably you should just make a new checkout,
<poolie> eg by branching, and then moving that over the top
<poolie> you might want to add the ~bzr ppa to your hardy chroot
<m3ga> bzr branch broken broken.2 gets "bzr: ERROR: exceptions.AssertionError: Could not find target parent in wt: lib/oldxmlrpc"
<spiv> poolie: tangentially, you might want to look at https://bugs.edge.launchpad.net/ubuntu/+source/bzr/+bug/264275, it appears your work on #192859 has almost fixed it.  I left a comment.
<ubot5> Launchpad bug 264275 in Bazaar "bazaar internal error if adding file in a linked directory (affected: 0, heat: 5)" [Undecided,In progress]
<poolie> oh thanks spiv, when i eventually get back to prague i think a bunch more may be just about fixed
<poolie> m3ga: could you paste the traceback into bug 373319?
<ubot5> Launchpad bug 373319 in Bazaar "mv --auto does not handle directory adds mixed with the contents of a directory splitting in two: InconsistentDelta error (affected: 2, heat: 1)" [High,Confirmed] https://launchpad.net/bugs/373319
<m3ga> poolie: save traceback i posted in #617224?
<m3ga> s/save/same/
<poolie> no, from the error when branching
<m3ga> ok will do
<m3ga> done!
<m3ga> basically my going home time now :-) will probably bug you about it some more on monday.
<poolie> ok, have a good weekend
<poolie> bialix, i'm working on bug 585667
<ubot5> Launchpad bug 585667 in Bazaar "User Reference has an empty list of commands in 2.2 (affected: 1, heat: 2)" [High,In progress] https://launchpad.net/bugs/585667
<jdk2588_> when I am merging from a different branch , I want that few files should not be merged
<jdk2588_> because it creates a conflict by renaming the old file to <filename>.moved
<jdk2588_> and when I rename the file <filename>.moved to the original file it shows original file to be removed
<poolie> jdk2588_: probably the easiest thing is to just revert those files after the merge, before committing
 * spiv feeds a branch to PQM and signs off for the weekend
<spiv> G'night all, see you Monday.
<poolie> cheerio spiv, have a good weekend
<jdk2588_> poolie: there ?
<poolie> hi
<poolie> but not for much longer
<jdk2588_> I was upgrading my launchpad branch for rich-root . but lost the connection
<jdk2588_> now it is in unstable mode
<jdk2588_> neither I can get the branch noe do anything
<jdk2588_> poolie: can you just help with this
<poolie> which branch?
<jdk2588_> the branch in which I have to commit , lp:~systers-dev/systers/membership
<poolie> if you have a copy of it locally it might be easiest to delete that and re-push?
<jdk2588_> can't it be avoided ?
<poolie> i mean delete it from the server, using the web ui, then re-push it
<poolie> i'll have a look at it
<jdk2588_> as other members are also subscribed to it
<poolie> ah ok
<jdk2588_> and I can not staright away delete it :)
<jdk2588_> *straight
<maxb> jdk2588_: There is a better option, to preserve subscriptions.
<maxb> If there is no nicer way to fix it, you can delete the content of the branch using a sftp client, and bzr push --use-existing-dir
<jdk2588_> wont it remove the subscribers
<jdk2588_> ?
<maxb> deleting it in the web UI would
<maxb> jdk2588_: Are you familiar with the 'sshfs' command for mounting a remote sftp location as if it was part of the local filesystem ?
 * jdk2588_ googles 'sshfs'
<poolie> yes, what maxb said is probably best
<jdk2588_> and how do I preserve the Subscribers
<poolie> just for future reference, there is an 'upgrade' button in the web ui, i think
<poolie> jdk2588_: if you just delete it over sftp not through the web ui, the subscribers will be preserved
<maxb> I would recommend not deleting it at all. There is a better way
<maxb> mkdir /tmp/mountpoint
<jdk2588_> ok
<maxb> sshfs bazaar.launchpad.net:~systers-dev/systers/membership /tmp/mountpoint
<maxb> cd /tmp/mountpoint
<maxb> mv .bzr backup.bzr.~1~
<maxb> mv backup.bzr .bzr
<jdk2588_> or one thinng I can do is to move backup.bzr to .bzr
<jdk2588_> yes
<maxb> cd /
<jdk2588_> this is a good option
<maxb> fusermount -u /tmp/mountpoint
<jdk2588_> thanks maxb
<jdk2588_> you saved my day :)
<maxb> At that point, you should be able to access the branch with bzr again. The launchpad web UI may be a bit confused until you next do a bzr write operation on the branch (a no-op push will do)
<jdk2588_> maxb: done ! Thanks
<jdk2588_> :)
<maxb> Ok! Now, on the branch's web page, you should see an "Upgrade" link. If you click it, Launchpad will upgrade the branch to 2a format at some point in the future (hopefully quickly)
<jdk2588_> so will it upgrade the rich-root  for the branch ?
<jdk2588_> yes I can see that "Upgrade this branch"
<jdk2588_> is olive 0.11 is the latest version ?
<jelmer> I don't think there really has been a release since it was split out.
<zyga> hello, which plugin provides lp-propose-for merge command? I cannot find it anywhere and I keep remembering that other folks were using that often
<dobey> if i have a WorkingTree object, how do add a new file to it from the python code?
<jelmer> dobey: wt.add([path1, path2, path3])
<dobey> ah, that easy eh? thanks
<edakiri> Glossary is missing.  http://bazaar.canonical.com/BzrGlossary/
<jelmer> edakiri, http://wiki.bazaar.canonical.com/BzrGlossary/
<edakiri> thanks.  I hope the dead links get fixed.  I don't have commit privileges.
<jelmer> edakiri: please file a bug about the dead link
<edakiri> done
<aaron01> If i try to bzr import a tarball that contains a .bzr dir, it fails with "error: tree transform is malformed" (related: https://bugs.launchpad.net/bzrtools/+bug/237933).
<ubot5> Launchpad bug 237933 in bzrtools (Ubuntu) "attempting to import a directory/archive containing a .bzr directory gives a fatal "tree transform is malformed" error (affected: 1, heat: 4)" [Undecided,New]
<aaron01> nm read the merge date on that patch wrong. Thought I was getting error with patch.
<jdk2588> how can we get a branch with older version ?
<Meths> -r  to specify a revision
<Meths> bzr help revisions
#bzr 2010-08-14
<mkanat> What's the best way to validate that a remote URL is a bzr repository? "bzr info"?
<Kamping_Kaiser> could someone confirm for me if this is bzr or bzr-svn exploding? http://paste.debian.net/83210/ (starts at line 245)
<a_b> Hi
<jelmer> hi
<a_b> I'm trying to clone a repository, lp:pana
<a_b> I always get the message Permission denied(publickey)
<a_b> The repository is public, why doesn't it work?
<jelmer> a_b: bzr will try to connect over ssh but that is failing for some reason.
<a_b> because I don't have write access, I guess
<a_b> how can I make it use another protocol?
<jelmer> a_b: No, that's unrelated to whether you have write access. You don't appear to have the ssh keys you have registered with launchpad locally.
<a_b> yes, that's right
<jelmer> if that's the case, you can get bzr to never use ssh to connect to launchpad by logging out of Launchpad. You can do this by editting ~/.bazaar/bazaar.conf  I believe
<a_b> thanks, it seems to work now
#bzr 2010-08-15
<parthm> hello. whats a good way to capture stdout/stderr in a bzr unittest. i have a unit test that prints ui.ui_factory.show_warning. i want to assertContainsRe that the output has this warning.
<parthm> nevermind. found an example in tests\test_http.py
<lifeless> parthm: uhm, don't do it ?
<lifeless> parthm: capturing stdout/stderr is pretty evil and makes it very hard to debug things. Why do you want to do that ?
<parthm> lifeless: i have a fix for bug #430785 which prints a warning in case clean-tree cannot delete a file.
<ubot5> Launchpad bug 430785 in Bazaar "bzr clean-tree --force --detritus stops on io error (file in use) (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/430785
<parthm> ui.ui_factory.show_warning ... so i am writing a unit test to verify it.
<lifeless> parthm: I don't see why that implies capturing stdout/stderr
<parthm> lifeless: is there any other way of ensuring that the warning is being printed?
<parthm> or generated.
<lifeless> use a known api and confirm that the api is claled
<lifeless> in this particular case, the test UI should accumulate the api calls made on it
<lifeless> so you can just assert that show_warning was called
<lifeless> also
<lifeless>   """Show warning for errors seen by rmtree.
<lifeless>  98        """
<lifeless> one line for one-liners please
<lifeless> """Show warning for errors seen by rmtree."""
<parthm> lifeless: ah. good idea. so i can overrideAttr show_warning. i will do that.
<lifeless> huh
<lifeless> no
<lifeless> there is a test specific UI
<lifeless> it gathers things into strings
<parthm> lifeless: is there any test case i can look at as an example?
<lifeless> hmm, its changed, I could swear we used to have one
<lifeless> anyhow, bzrlib.ui contains SilentUIFactory
<lifeless> ah
<lifeless> its in bzrlib.tests
<lifeless> bzrlib.tests.TestUIFactory
<lifeless> it needs a small tweak to have a show_warning
<lifeless> but even without it
<lifeless> def test_clean_tree_warning(self):
<lifeless>     out = String()
 * parthm greps for TestUIFactory usage
<lifeless>     self.overrideAttr(ui, 'ui_factory', tests.TestUIFactory(stdout=out))
<lifeless>     clean_tree(...)
<lifeless>     self.assertContainsRe('needle', out.getvalue())
<lifeless> # this should do for now, we should make it better and more structured though
<parthm> lifeless: yes. thats the example i found in tests/test_http.py. i will implement this. i agree. confirming that the api is called would be nicer.
<parthm> lifeless: thanks.
<lifeless> parthm: ah, I thought you found something using apply_redirected
<lifeless> which is really quite different :)
<lifeless> becaues *that* does alter stdout/stderr/stdin its very hard to debug within it.
<parthm> lifeless: :) ... no it was test_http. ... test_prompt_for_username
<kyan> Is there any way to upload files to Launchpad using a web interface, as an alternative to a command-line interface? I'm new to Bazaar/version control software, and have been unable to learn, despite some struggling â it seems to require Mac OS 10.5 (I have 10.4). Thanks!
<kyan> I looked at macports but it needs admin access.
<kyan> I don't have it.
<kyan> Admin access, that is.
<kyan> This is one of many reasons I hate mac os: software is next to nonexistant for it.
<kyan> :-p
<lifeless> bai ?
<lifeless> spiv: btw
<lifeless> spiv: I wish there was a pypi operationswithcleanups BSD module. Just saying.
<lifeless> spiv: http://twitter.com/rbtcollins/status/21218747637 is why
<lvh> Hey
<lvh> If I have questions about using bzr with VC (the version control system in emacs23); should I ask here or in #emacs?
<marienz> I only lightly use that integration
<lvh> I used to use DVC
<lvh> Now I'm trying VC since it's supposed to be good
<lvh> basically I made some changes; I was expecting C-u C-x v v to let me use a different branch
<marienz> I haven't used dvc much
<lvh> (currently on "trunk", I'd like to put these changes in a new branch)
<marienz> I don't understand how that'd work (that sounds like it'd require VC knowing much more about how my branches are organized on-disk than it normally does)
<lvh> I was expecting it to be really clever and understand how repositories work
<lvh> So how are you supposed to branch from emacs
<marienz> repositories can work however you want them to. I just use bzr commandline commands to branch
<marienz> "branch" in my case frequently means "create a new branch in a no-trees repository emacs knows nothing about, and then switch the lightweight checkout I work in"
<marienz> that's not really something I'm interested in teaching emacs how to do
<lvh> But M-x term is so many keystrokes :-(
<lvh> I'll try #emacs, if that doesn't help I'm moving back to DVC
<marienz> I don't know enough about vc to know if this is something it is interested in doing for you
<nhandler> I'm playing around with setting up a pre-commit bzr hook for a branch. It would simply run a single shell command. I saw the shell-hooks plugin, which looks like it would be better suited than writting a python plugin for the hook. I'm just having a problem figuring out a) where the plugin looks for the shell script (so I can use a relative path instead ofabsolute) and b) Where the shell script is actually run from
<Noldorin> has anyone had any success using bzr-svn with codeplex?
<Noldorin> doesn't seem to be working for me
<jelmer> Noldorin: the codeplex svn server is broken
<lvh> Hey
<Noldorin> jelmer, ah i see.
<lvh> So what's the reccomended emacs integration for bzr
<jelmer> Noldorin: it returns inconsistent data
<Noldorin> jelmer, have the codeplex admins been notified of thisw?
<lvh> there's DVC, there's VC
<jelmer> Noldorin: I don't know; I don't use any codeplex repositories but I've mentioned what the issue was to several people who ran into issues with codeplex.
<Noldorin> right
<Noldorin> i think i remember you telling me now some time ago actually!
<Noldorin> ah well
<lvh> there's BzrEmacs which is kind of old
<Noldorin> jelmer, any idea what the status of bzr-tfs is like?
<jelmer> lvh: Sorry, I'm not an emacs user. Perhaps there's some folks on the Bazaar mailing list that can help.
<jelmer> Noldorin, what's bzr-tfs?
<fullermd> Talisman For Soupmaking?
<Noldorin> jelmer, https://launchpad.net/bzr-tfs
<fullermd> Shucks.  I was looking forward to soup   :(
<lvh> jelmer: Thanks, I'll give it a try
<jelmer> Noldorin, ah, neat - I hadn't seen that yet
<Noldorin> jelmer, indeed. unfortunately i can't get it to run here though...
<Noldorin> needs some ntlm module
<jelmer> Noldorin: perhaps ask the author and cc the bazaar list?
<jelmer> the bzr-tfs plugin looks nice
<jelmer> too bad I don't have a Microsoft Team Foundation Server to test with :-P
<jelmer> Noldorin, it looks like you need to install the python-ntlm module
<Noldorin> jelmer, codeplex provides free TFS repos :)
<Noldorin> jelmer, also, i installed python-ntlm, but no lucky...
<jelmer> Noldorin: Can you follow-up to the mailing list? The original author announced it there a month ago, he might be able to help.
<Noldorin> jelmer, sure, will give that a go. cheers
<lifeless> mgz: hey
<mgz> hey lifeless
<mgz> was hoping you'd be around
<lifeless> indeedy
<mgz> so, the basic idea which is a bit hard to see in the big diff
<mgz> is that inside TestSuite.run running each TestCase is delegated to a teeny function that only returns a weakref
<lifeless> ...
<lifeless> (Why?)
<mgz> because we need to drop the reference, and then check whether the case is in fact still alive
<lifeless> theres a missing cause/assumption here
<lifeless> I'm at sea
<mgz> hm... I'll try another angle.
<mgz> we want to deallocate test case instances after they run, and *check* they're gone
<lifeless> also, lp:python-fixtures; new shiny for you
<lifeless> mgz: why do we want to check that they are gone ?
<mgz> because otherwise we get regressions.
<lifeless> this seems like a very hard proposition
<mgz> we've had hundreds of revs of the test suite being slow and flakey on my machine without the cause being very clear
<lifeless> 'do not think of the elephant'
<mgz> and... it's not that hard
<lifeless> mgz: yes, agree we need a means to improve and debug this
<lifeless> I'm just trying to make sure I get each step of the logic properly ;)
<mgz> a weakref will return None when called, if the object it points at is gone
<lifeless> so
<mgz> if the case returned is None, all is fine, if it's still a test case, we complain
<lifeless> this implies a few things
<mgz> complaining means I can find cycles.
<lifeless> a) knowing if a given thing *should* be gone
<poolie> hello mgz, lifeless
<mgz> hey poolie
<lifeless> poolie: heya
<mgz> I agree this is complicated and annoying.
<lifeless> so, you could extend TestResult to permit querying 'are you still holding on to X'
<mgz> But I think I can do most of the annoying bits without inflicting them on everyone else who just has 8GB of ram and doesn't care.
<lifeless> if it says 'no', then a weakref to X should return None
<mgz> which problem are we trying to solve here?
<lifeless> mgz: sure, my goal is to help you do this
<mgz> I can live with the test result holding failed tests, in general, that should be a small number.
<mgz> the main issues are cycles (which is a judgment between avoiding them or running a gc collection after every test), and the decorators
<lifeless> mgz: well, we want several things AIUI; actual cycles generated in the code should be obvious (like that stack one - meep); the test suite itself shouldn't create cycles [thus your detection logic]; the tests suite should run fast
<mgz> I think those are achievable goals, the only thing being I've currently got "test not collected" but not any simple way of pointing out where the cycle is
<lifeless> well, meliae can tell, I expect.
<mgz> I wondered if it might, I've just not tried.
<lifeless> so we could have an option to use it for folk that want to debug these things
<mgz> it's much easier to see the problem when it's in code you've just written, so if I fix the remaining ones then make non-collection into some kind of test failure I think that's sustainable
<lifeless> ok
<mgz> if you've just written a test that closes over the test instance and pqm rejects it, I'd hope it wouldn't be hard to resolve.
<lifeless> that works for me
<mgz> so if you're okay with that general approach, I think the remaining possible problem areas are that I've taken a hammer to the TestDecorator classes, and the new unit test _ExpectedFailure
<mgz> well, the first is if it's going to upset anything
#bzr 2011-08-08
<bignose> where can I read about the unit test case categorisation done in Bazaar?
<bignose> I'm on a team that has noticed a rapid growth in unit test suite size, and are worried about the incentive against adding new tests because they might slow the test suite down
<bignose> I recall Bazaar dealing with the issue by marking (decorating?) test cases to run the more resource-intensive ones less often. right?
<bignose> is it part of âtesttoolsâ? we use that and like it
<poolie> hi bignose
<bignose> poolie: howdy
<bignose> poolie: still looking for a new Bazaar developer?
<bignose> I failed to use the recruiter's website (but can't remember the failure)
<poolie> i am: http://bit.ly/ubuntu-vcs-job - though as the url suggests the remit is broader than just bzr
<poolie> hm
<poolie> if you hit it again please let me know what the failure was
<poolie> or, perhaps forward it to someone else you know who could be interested
<poolie> the app is not all that great but it's an improvement on ad hoc spreadsheets and email
<fullermd> bzr?  Yeah, it works a lot better for my versioning needs than spreadsheets   :-D
<bignose> poolie: did you catch my question re. Bazaar's unit tests of about 15 mins ago?
<poolie> nup, i had a late start
<poolie> what was it?
<bignose> I'm on a team that has noticed a rapid growth in unit test suite size, and are worried about the incentive against adding new tests because they might slow the test suite down
<bignose> I recall Bazaar dealing with the issue by marking (decorating?) test cases to run the more resource-intensive ones less often. right?
<poolie> wrong :)
<poolie> we talked about that but we've never done it
<bignose> okay. how does the Bazaar team deal with a large number of tests in the suite?
<poolie> we have made a distinction between benchmarks and tests
<poolie> we added selftest --parallel
<bignose> run them less often? divide them into different categories somehow? suck it up and wait?
<poolie> wow
<poolie> that's a really kind of interesting question actually; perhaps i should write about it
<bignose> heh. âI don't have a solution, but I admire the problemâ?
<poolie> developers can run only a subset of tests, and can reorder them to run the tests guessed most likely to fail first
<poolie> we have a partial solution
<poolie> we run the tests on every commit
<bignose> and the commit fails if the test suite fails?
<poolie> it takes single-digit minutes to run them all on my 1 year old laptop
<poolie> in pqm, yes
<bignose> right
<poolie> oh, i should have said every mainline commit
<poolie> you can commit locally without running them
<bignose> ah okay
<poolie> i think robert has a subunit hack to run tests remotely
<lifeless> --parallel=ec2
<lifeless> its a bzr plugin
<poolie> mm, also we just look at the times and occasionally look hard at the slowest tests or group of tests
<poolie> lifeless, does it spin up new machines every time?
<lifeless> I don't think so
<lifeless> jml has some reporting tools that take a subunit stream and tell you test timing info
<bignose> so the Bazaar solution involves the Patch Queue Manager robot being the only one authorised to commit to trunk
<bignose> right?
<lifeless> well, it involves all tests run for things to get to trunk; separately we've made that hard to avoid by using a robot to do the landings
<bob2> i was amused to see 'thelove' still cropping up in places
<bignose> okay. so currently we allow commits to trunk by any developer, and a build robot reports failures
<bignose> but that's after the commits.
<bignose> in part this is because the test suite has over time gone from taking hours to run, down to twenty minutes, down to a few minutes.
<bignose> now that it's feasible to run the tests without breaking development flow, we're loath to let it get out of hand again.
<poolie> how did you accomplish that huge improvement?
<RenatoSilva> for those who read my question, it seems nature of line-based merges
<bignose> mostly by finding horrible inefficiencies
<bignose> also by getting the database to run in memory
<RenatoSilva> I always have to watch upstream changes so I can see an unusual change will be required in a merge
<bignose> during the same periof the test suite has increased from a few hundred to nearly two thousand and still rising rapidly
<bignose> so we don't want to see the suite become slower by the exact behaviour we're trying to encourage: add more test cases
<poolie> just keep watching it, i suppose
<RenatoSilva> for example upstream refactors some duplicated code into a function, and I have a new function which is using that exact duplicated code. It's not easy to realize you need to replace it with the function call during a merge, unless you have followed all commits since your last sync with upstream
<poolie> oh, also try to add test suite infrastructure that makes it easy to write expressive tests the right, fast, way
<bob2> RenatoSilva: yes merges need manual review and tests to be run
<bignose> poolie: what is the right, fast, way?
<poolie> well, for instance, it's easy for people to test from the ui all the way down across the entire stack
<bignose> RenatoSilva: yes, it's deliberate that a merge requires manual action later to commit
<RenatoSilva> this is one reason for merging as often as possible
<poolie> but, this may be slow
<poolie> it also may be imprecise compared to the kind of test you can write directly to an api
<bignose> poolie: does Bazaar have non-unit tests automated? how are they done?
<RenatoSilva> bignose: yes, I just thought it was just about the conflicts, but it's not!
<bignose> poolie: we've recently had the âunit tests should be small and focussed and shouldn't require instantiating half the entire applicationâ discussion
<poolie> we have some whole-stack tests
<poolie> some of these are old and crummy and would be a good target for people wanting to make the suite faster
<RenatoSilva> bignose: you can get a no-conflicts yet broken merge, I didn't know that
<bignose> poolie: using what to run them? the âunittestâ library doesn't fit very well
<bignose> RenatoSilva: worse, you can get a fine merge that fails your automated tests
<poolie> some are worthwhile integration tests
<poolie> in some cases it's a tradeoff against a blackbox test being easier for a new developer to write
<poolie> bignose, unittest just runs code..
<RenatoSilva> bignose: well, that's better not worse, no? you'll actually *notice* the merge is broken through these tests
<bignose> RenatoSilva: so it's essential to (a) have good unit test coverage, (b) run all the tests every commit â including especially a merge commit.
<poolie> we have wrappers to connect it to something that looks like a command line
<poolie> http://doc.bazaar.canonical.com/developers/testing.html#shell-like-tests
<bignose> RenatoSilva: heh. if your tests don't notice what you call a âbroken mergeâ, then either you have code which is useless or you have insufficient code coverage of your tests :-)
<RenatoSilva> bignose: I mean, it's good the tests fails, it's worse if you don't have them or they pass (*that* is silly)
<bignose> poolie: thanks
<RenatoSilva> bignose: or a bug with the tests
 * fullermd has highly insufficient code coverage of his tests   :p
<lifeless> bignose: LP has huge-time problems
<RenatoSilva> bignose: actually I'm not sure how tests would detect the example I presented
<lifeless> bignose: and there is a social pressure to write less/bigger tests.
 * bignose wants to investigate Pester <URL:http://jester.sourceforge.net/> for mutating code to find poorly-tested code branches
<RenatoSilva> who tests the test tester
<bignose> it's a pity it's Python-using-Java, I'd prefer a pure-Python implementation
<lifeless> bignose: I'm planning to solve this by more aggressive factoring out of stuff into separate packages, which would be tested independently, and provide a test contract back to the main / integration codebase
<lifeless> bignose: part of that is moving to a service based design as well: https://dev.launchpad.net/ArchitectureGuide/Services
<RenatoSilva> bignose: I mean, the tests would be no help in that example! If upstream refactored duplicated code your branch is using in a function foo, the test for foo will still pass!
<bignose> thanks all, poolie I've pointed our team to <URL:http://doc.bazaar.canonical.com/developers/testing.html> for ideas :-)
<RenatoSilva> http://i.imgur.com/mvBLR.png
<RenatoSilva> brb
<bignose> poolie: I may have been mistaken about the recruiter's app failing me. either way, my application is now submitted.
<poolie> good to hear
* poolie changed the topic of #bzr to: current topic is: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jelmer
<seb128> hey
<seb128> could somebody help robert_ancell to fix the lightdm vcs?
<seb128> it's broken in a way similar to bug #772935
<ubot5> Launchpad bug 772935 in Bazaar "ErrorFromSmartServer: Absent factory for StaticTuple" [High,Confirmed] https://launchpad.net/bugs/772935
<wgrant> seb128: Does someone have an old branch?
<wgrant> The original that it was stacked on has apparently been deleted.
<seb128> well, people have checkouts
<seb128> not sure about "old"
<wgrant> Ah, no, the branch is there, I was just looking in the wrong place.
<wgrant> Let's see.
<jam> morning all
<jam> hi wgrant
<wgrant> seb128: You've not tried fetch-all-records?
<wgrant> seb128: I just grabbed the broken branch locally, and it works fine.
<wgrant> Once I've run fetch-all-records against robert_ancell's branch, that is.
<seb128> what arguments do you use?
<seb128> how do you fix the online version?
<wgrant> seb128: bzr fetch-all-records -d lp:lightdm lp:~robert-ancell/lightdm/trunk
<wgrant> I don't have privileges to do that, but anyone in lightdm-team can.
<wgrant> (you'll need to 'bzr branch lp:bzr-repodebug ~/.bazaar/plugins/' first)
<wgrant> Erm.
<wgrant> The branch is unbroken now?
<seb128> how unbroken?
<wgrant> http://bazaar.launchpad.net/~lightdm-team/lightdm/trunk/files
<wgrant> Someone has fixed it.
<wgrant> Possibly someone pushed over it or something.
<wgrant> It was broken 10 minutes ago...
<jam> wgrant: it was just broken again? We 'fixed' it last week sometime
<jam> not a good sign...
<seb128> _raise_smart_server_error
<seb128>     raise errors.ErrorFromSmartServer(error_tuple)
<seb128> ErrorFromSmartServer: Error received from smart server: ('error', "Absent factory for StaticTuple('language.sgml-20100710032117-i0kdmrwf93qvp5j8-1', 'robert.ancell@gmail.com-20100710034239-8eysy1lpccerztec')")
<seb128> wgrant, it's still broken for me
<jam> that looks ~ like the same failure, so maybe it wasn't actually changed before
<seb128> should I ask robert to 'bzr fetch-all-records -d lp:lightdm lp:~robert-ancell/lightdm/trunk'
<seb128> ?
<wgrant> Then why can LP scan it now :/
<wgrant> And why can loggerhead see it...
<wgrant> Unless it depends on just what files are touched.
<jam> seb128: I think so. That looks right to me
<wgrant> seb128: You, or anyone else in ~lightdm-team.
<seb128> jam: then what? what will that do?
<jam> wgrant: You probably can't scan it, because it is old history that is missing
<wgrant> jam: But the last scan worked.
<seb128> what are the argument doing?
<jam> seb128: lp:lightdm used to be stacked on ~robert-ancell...
<jam> but then someone removed stacking, *without* filling in the history
<seb128> how can that happen?
<jam> seb128: 'bzr fetch-all-records' fills in the history
<wgrant> Someone must have altered branch.conf manually.
<jam> seb128: I don't really know, but ".bzr/branch/branch.conf' has 'stacking_location = ""'
<jam> I don't think bzr would set it to an empty string
<jam> I imagine the original bug was a stacking cycle when they switched lp:lightdm from pointing at ~robert-ancell/... to ~lightdm-team/
<wgrant> There wouldn't have been a cycle; the initial ~lightdm-team/ push would have stacked on ~robert-ancell/, then everything afterwards stacked on ~lightdm-team/.
<seb128> jam, wgrant: that doesn't work it seems
<wgrant> robert_ancell: What goes wrong?
<robert_ancell> wgrant, I get "TooManyConcurrentRequests: The medium 'SmartSSHClientMedium(bzr+ssh://robert-ancell@bazaar.launchpad.net/)' has reached its concurrent request limit. Be sure to finish_writing and finish_reading on the currently open request.
<robert_ancell> "
<wgrant> jam: And I only know of one API that breaks on transitive stacking.
<jam> wgrant: if you look at ~robert-ancell, it says it is stacked on ~lightdm-team
<wgrant> !?
<jam> ah, I take that back
<jam> it is empty
<jam> http://bazaar.launchpad.net/~robert-ancell/lightdm/trunk/.bzr/branch/branch.conf
<wgrant> What evil is this...
<jam> It is supposed to be empty, so no problems there
<wgrant> Oh, I thought you meant it said it was stacked on ~lightdm-team on LP anyway.
<wgrant> Despite the empty branch.conf.
<jam> right, no, it is not stacked
<wgrant> robert_ancell: What if you try 'bzr fetch-all-records -d lp:lightdm http://bazaar.launchpad.net/~robert-ancell/lightdm/trunk'?
<robert_ancell> wgrant, running now
<jam> robert_ancell: it is possible that fetch-all-records is accidentally sharing a connection, and it is trying to read and write to the same connection
<wgrant> It's only ~600KB, so should be fairly fast.
<robert_ancell> wgrant, same error
<wgrant> Hrmph.
<wgrant> Indeed, reproducible.
<poolie> hi jam
<wgrant> jam: Perhaps it would be best to reset stacking_location in branch.conf, and do a real unstack.
<jam> wgrant: sounds like something to try
<jam> I know I used hitchiker to bit-wise copy lp:lightdm and setting the stacking_location allowed me to branch from it
<jam> hi poolie, hope you're not working too late again :)
<poolie> hi, no, i'm fine
<wgrant> jam: I grabbed it over sftp and tried a few things with it, yeah.
<seb128_> re
<seb128_> conference internet is not really reliable
<seb128_> robert_ancell is still getting issues with the new command, not sure his messages went through though
<robert_ancell> just back now
<wgrant> robert_ancell: With your favourite SFTP client (eg. nautilus), could you edit sftp://robert-ancell@bazaar.launchpad.net/~lightdm-team/lightdm/trunk/.bzr/branch/branch.conf, setting stacking_location to "~robert-ancell/lightdm/trunk" instead of ""?
<robert_ancell> last I heard was "wgrant: Hrmph."
<wgrant> 18:15:23 < wgrant> Hrmph.
<wgrant> 18:18:16 < wgrant> Indeed, reproducible.
<wgrant> It's unclear how it got set to "" in the first place, but we suspect someone changed it manually.
<jam> poolie: sometimes, facebook is a bit... odd. I just saw your politics post (via twitter), read it, went back to my page to "like" it, and it was now gone from my page. So I had to track it all the way back to your own page, etc.
<jam> the 'ethereal' nature of FB posts is good and bad
<poolie>  huh
<poolie> i think you don't always get repeatable reads either
<poolie> of the same page
<jam> I remember reading that they had tons of knobs to scale with load, which included reducing what is shown, etc.
<jam> so yeah, I tend to spawn pages that I want to read, and come back to them by closing tabs
<jam> which leads to lost state, I guess
<robert_ancell> wgrant, ok, modified
<wgrant> robert_ancell: I suck. Should be "/~robert-ancell/lightdm/trunk"
<wgrant> Forgot the leading /.
<robert_ancell> wgrant, ok, fixed
<wgrant> Yet apparently still broken...
<wgrant> Hrm.
<wgrant> jam: This is odd. It seems to not work on LP.
<jam> wgrant: I see "/+branch-id/..." eleswhere
<wgrant> jam: Perhaps the hpss does odd things.
<wgrant> Yeah, but both work.
<wgrant> +branch-id is only a few months old.
<jam> wgrant: I believe Launchpad's codehosting rewrites the stacked location to clients.
<jam> sure=
<jam> http://bazaar.launchpad.net/~bzr-pqm/bzr/2.1/.bzr/branch/branch.conf
<jam> lp-hosted:///~...
<jam> ah, that is parent location
<jam>  /+branch-id was rewritten for many branches
<wgrant> 7.242  hpss call:   'BzrDir.open_branchV3', '~robert-ancell/lightdm/trunk/'
<wgrant> 7.242               (to bzr+ssh://bazaar.launchpad.net/%2Bbranch/lightdm/)
<wgrant> 7.577     result:   ('branch', 'Bazaar Branch Format 7 (needs bzr 1.6)\n')
<jam> well, you certainly need an opening '/~robert-ancell/...'
<wgrant> Hmm?
<wgrant> When branching lp:lightdm, it successfully opens lp:~robert-ancell/lightdm/trunk as the stacked-on branch.
<wgrant> Oooh.
<wgrant> I wonder.
<wgrant> Could we need to force LP to scan it?
<wgrant> It's possible it won't use the fallback unless the DB knows about it.
<wgrant> I forget exactly how this works.
<jam> wgrant: push --overwrite -r -2; push ?
<wgrant> jam: Probably easiest.
<wgrant> But I need to go and organise dinner.
<jam> wgrant: sure. if you're still here, what is failing, since branching seems to be succeeding
<wgrant> jam: Sure you didn't accidentally use a shared repo?
<jam> wgrant: I'm sure I wasn't locally
<jam> it was a plain recursive cp
<wgrant> It works fine locally, yes.
<wgrant> Hmm, broken over HTTP too.
<wgrant> $ bzr branch http://bazaar.launchpad.net/~lightdm-team/lightdm/trunk
<wgrant> bzr: ERROR: Revision {StaticTuple('language.sgml-20100710032117-i0kdmrwf93qvp5j8-1', 'robert.ancell@gmail.com-20100710034239-8eysy1lpccerztec')} not present in "<bzrlib.groupcompress.GroupCompressVersionedFiles object at 0x236c810>".
<wgrant> Er.
<wgrant> stacked_on_location has reverted to "?
<wgrant> ""
<seb128> hum, timeouted :-(
<seb128> wgrant, jam: did you guys figure what is needed?
<seb128> sorry we keep timeouting there so it's a bit hard to keep track of the discussion
<wgrant> seb128: THe change that robert_ancell made has apparently been reverted.
<wgrant> Which is slightly odd.
<robert_ancell> wgrant, oh, I reverted it so I could push some changes
<wgrant> Ahh. It prevented you from pushing changes?
<wgrant> What was the error?
<wgrant> That's rather unexpected.
<robert_ancell> wgrant, I wasn't sure, but I thought you'd gone to dinner so I put it back just in case
<robert_ancell> and then the network dropped out so I didn
<robert_ancell> 't get to push them anyway
<wgrant> Could you put the real path back and retry the push, if you haven't already pushed?
<wgrant> The current suspicion is that forcing Launchpad to rescan it (by pushing) will make everything see the correct path.
<wgrant> Then we can properly unstack it, and everything will be happy.
<robert_ancell> wgrant, set back to "/~robert-ancell/lightdm/trunk"
<seb128> why are those issues happening in the first place? was there a user mistake there?
<robert_ancell> pushing changes...
<wgrant> seb128: It looks like someone may have tried to unstack the branch by editing branch.conf directly, but it's not entirely clear.
<robert_ancell> 9kb
<robert_ancell> ...
 * robert_ancell smacks head on desk
<robert_ancell> 18kb...
<wgrant> We did do a mass-rewrite of stacked_on_locations on LP 2.5 months ago, but nothing since then.
<wgrant> So, HTTP now works fine.
<wgrant> bzr+ssh still does not, but that may be because the push isn't done yet.
<robert_ancell> 34kb
<wgrant> That's quite a connection you have there.
<jelmer> 'morning poolie :)
<poolie> hi thar
<poolie> i'm off to squash
<poolie> squash something or other
<jelmer> have fun :)
<seb128> re
<robert_ancell> wgrant, ok, managed to push now.  Branch still doesn't work, fetch-all-records has same error
<wgrant> robert_ancell: Indeed... over bzr+ssh it's still broken, but HTTP works.
<wgrant> I am in over my head here; I may leave you to jelmer and jam :)
<robert_ancell> ok
<seb128> jam, jelmer: hey ;-)
<seb128> ok, lunch time there
<seb128> see you later
<seb128> could somebody try to pick on that issue?
<seb128> oneiric feature freeze is this week and having the lightdm vcs broken is blocking distro work
<jml> bzr branch ubuntu:<package> should resolve binary packages, if it doesn't already
<jelmer> jml: It doesn't
<jelmer> apt:<package> does though, but isn't always correct
<jml> why are there two ways?
<jelmer> jml: One looks at the Vcs-* field in the source package
<jelmer> jml: Which is the right thing to do in Debian
<jml> jelmer: ah
<GRiD> hi jelmer. re: merge 70691, what's the UDD importer? also having trouble finding docs on "merge-upstream" ...
<jelmer> GRiD, "bzr merge-upstream" is a part of the bzr-builddeb plugin
<GRiD> ok
<jelmer> GRiD, basically, I'm wondering if the tree implementation should do the warning or the command-line layer that lies on top of that
<GRiD> jelmer, ok i got that much. if it lives in the command-line layer, does that mean the various other (non CLI) clients have to implement it as well?
<jelmer> GRiD, yes, but I'm not sure if they would want to implement it this way
<jelmer> GRiD, e.g.I imagine graphical frontends to simply interactively prompt you whether you are sure
<GRiD> jelmer, yeah that probably makes more sense. if it were done in the tree, how would these other clients handle it now, anyway? they capture warning output?
<jelmer> GRiD: it varies; I think qbzr captures and displays it, bzr-gtk simply ignores it
<GRiD> jelmer, hm. ignoring it would surely baffle users.
<GRiD> jelmer, i think you may be right then. this particular change is probably better off in the front end.
<vila> what happened to pqm ? 40% of the test suite in ~100 mins ?
<jelmer> yeah, something seems to be slowing it down
<vila> jelmer: is your XXX at the end of bzrdir.py still valid ?
<jelmer> vila: somewhat; there is probably still some code relying on it
<jelmer> vila: +1 on removing it for 2.5 though, fixing the fallout shouldn't be too bad
<cyberix> I often start working on something on my laptop by doing bzr init in a folder. Later I decide I want to backup that directory to a shell machine that has ssh.
<cyberix> What is the correct way of doing this?
<LeoNerd> bzr push sftp://...
<cyberix> does create a directory for me on the remote machine?
<LeoNerd> Or maybe bzr+ssh if that machine has bzr installed as well
<jelmer> vila: I guess we should also deprecate using some of the class methods on BzrDir, and instead encourage the use of ControlDir
<LeoNerd> push --create-prefix   will
<vila> jelmer: /me nods
<vila> jelmer: I was mostly wondering if your later refactorings had already addressed the issue
<cyberix> thank you
<glyph> I have a repository in my home directory
<glyph> it has to say there for legacy reasons
<glyph> but I'd really like to make some local branches
<glyph> my thought was that I'd do 'bzr branch . .upstream', then hack on some stuff, and still have a handy local copy of upstream to revert to / compare with
<glyph> (not to mention pull into without merging)
<glyph> but the branch itself isn't a shared repo, apparently
<glyph> is there a way to make a directory be _both_ a branch _and_ a shared repo?  if there is, is that a terrible obscene thing to do that I will regret forever?
<maxb> It's a bit weird, but not terrible afaik
<glyph> maxb: ... OK, so how do I do it?
<maxb> I'm not sure there's an actual UUI
<maxb> * UI
<maxb> I tend to cheat and just run "touch .bzr/repository/shared-storage"
<glyph> maxb: you do this regularly? :)
<glyph> maxb: my concern is that 'bzr init-repo .' raises an exception
<maxb> I have, in the past, used "rm -fr .bzr/branch && touch .bzr/repository/shared-storage" to destroy a branch and turn it into a shared repository keeping the old branch's revision data, into which I can then rebranch other related branches
<maxb> bzr init-repo . does error, but I'm not sure there's any logic to it doing so
 * jelmer waves
<exarkun> maxb: Hiya.  What do you think the chances of hardy packages for bzr betas would be?
<exarkun> Okay nevermind, I guess I don't care about that.
<exarkun> So I'm trying bzr 2.4b5
<exarkun> As far as I can tell, it is ignoring my already-initialized svn metadata cache
<exarkun> which means it takes about 4 hours to check out what I want to check out
<exarkun> are there known issues with bzr-svn and bzr 2.4b5?
<jelmer> exarkun: not in particular
<jelmer> exarkun, did you perhaps uninstall python-tdb since you last used bzr-svn?
<exarkun> nope
<exarkun> Can I provide some other information to help track down the problem?  I have no idea what's going on.
<exarkun> according to python -vv, it found the tdb module
<maxb> <exarkun> maxb: Hiya.  What do you think the chances of hardy packages for bzr betas would be?
<maxb> Zero. Given bzr 2.4 requires python 2.6, which hardy has not
<jelmer> exarkun, that might actually be the issue with your bzr-svn cache, too
<exarkun> What might be?
<jelmer> python-tdb is only built for a single python version, perhaps your bzr is now using a different python version.
<exarkun> according to python -vv, it found the tdb module
<exarkun> Also according to lsof, the tdb sos are in memory
<jelmer> hmm, no idea in that case - did it say anything about creating the cache directory?
<exarkun> /usr/lib/libtdb.so.1.2.9 and /usr/lib/pyshared/python2.7/tdb.so and /var/lib/buildbot/.cache/bazaar/svn/bbbe8e31-12d6-0310-92fd-ac37d47ddeeb/cache.tdb is also open
<exarkun> maybe the svn metadata cache is a red herring, I dunno
<exarkun> it's "copying revision 6141/8348" now
<exarkun> ~25 minutes in
<exarkun> I hoped sticking some extra --verbose flags onto the command would make it report something more interesting, but it seems not
<exarkun> nothing aside from the progress indicator on stdout, nothing interesting in .bzr.log
<jelmer> exarkun, ahh
<jelmer> exarkun, is it just copying more revisions that usually?
<jelmer> exarkun, because it might be unrelated to the cache
<jelmer> exarkun, in 2.4b5 bzr automatically fetches all revisions referenced by tags, even if they are not on the mainline
<exarkun> I don't know how many revisions it usually copies, but it usually completes the checkout in a handful of seconds instead of half an hour or more
<exarkun> I don't entirely understand how tags get mapped from svn to bzr.  I suppose it could be that.
<exarkun> is it a one-time thing?  after this completes it will have the extra revisions and not need to repeat this?
<jelmer> exarkun, yeah
<jelmer> exarkun, and there's a bug open about making this behaviour optional for 2.4.0
<exarkun> 8348 seems like a lot of extra revisions to have been hiding under a tag.  I don't suppose there's any way to learn what revisions it's copying?
<exarkun> On a tangent, why is copying revisions out of svn so slow?  Would it be possible to pipeline requests?  Or open multiple connections?  Or is this just as fast as svn servers can go?
<jelmer> exarkun: svn servers aren't really made for fetching multiple revisions
<jelmer> there are some tricks we don't do yet, that will improve the performance, but it's not going to be significantly faster until the server side is improved.
<exarkun> eyeballing this progress meter, I'd say it's doing about 1 revision every 6 seconds
<exarkun> it was much faster than this at the beginning of the operation
<exarkun> is the svn server worse at serving newer revisions than at older revisions?
<santagada> is there a command line parameter to make bzr run without progress bars and be noninteractive?
<jelmer> exarkun: it depends on the backend being used; for fsfs I think newer revisions are generally faster
<exarkun> This repo is fsfs
<santagada> bzr help global-options don't show anything interesting and so does a google search for bzr noninteractive
<jelmer> santagada, I think there is an environment variable
<santagada> jelmer: probably more than one... but I can't find any docs on this, surely someone is using bzr in semi-batch mode
<exarkun> done, real    39m31.917s
<exarkun> santagada: if you don't have a pty, it doesn't display those things
<jelmer> santagada, bzr help env-variables
<jelmer> santagada, looks like BZR_PROGRESS_BAR=none should help
<santagada> jelmer: mine doesn't have this one
<jelmer> santagada, bzr's command-line commands are already noninteractive, with the exception of "bzr uncommit"
<exarkun> jelmer: So the reason the svn cache wasn't updated by that is that "copying revisions" goes from the svn server into the repository?  And the cache probably already had all of those only-on-a-tag revisions?
<jelmer> exarkun: Are you sure it was updating the cache? It seems like it was just copying a lot of revisions.
<jelmer> exarkun: when it updates the cache it always updates the cache for the entire repository
<exarkun> jelmer: no, it didn't update the cache at all.
<santagada> jelmer: BZR_PROGRESS_BAR is not on my help env-variables
<exarkun> I don't know what "copying revisions" means
<jelmer> santagada, what version of bzr do you have?
<santagada> jelmer: on the server, 2.1.4 ubuntu 10.04 lts
<jelmer> exarkun: what it says, fetching revisions :) The actual revision contents (revision deltas) that is.
<santagada> jelmer: so older versions don't have this?
<jelmer> santagada, it seems it existed before but wasn't documented
<exarkun> sigh
<exarkun> http://buildbot.twistedmatrix.com/builders/lucid32-py2.6-select/builds/1089/steps/bzr/logs/stdio
<exarkun> 2.4b5 not so hot
 * jelmer tries
<glyph> jelmer: adding bzr-svn to our buildbots has been a small disaster in terms of VCS reliability :-(
<lifeless> :(
<glyph> jelmer: is there anything you can recommend that might work around these problems?
<glyph> some secret configuration file option that will slow things down but make it more reliable or something?
<jelmer> glyph: :(
<jelmer> glyph: It depends on what you need exactly
<jelmer> glyph: Are there bugs about about the current issues you've run into?
<glyph> jelmer: apparently not, google's only record of the message in that last error is https://code.launchpad.net/~maxb/bzr-svn/fix-syntaxwarning/+merge/27564
<glyph> jelmer: it's not so much that we have one specific issue as that we seem to keep finding them
<lifeless> exarkun: hi
<lifeless> exarkun: while you are here, I have a question about http://twistedmatrix.com/trac/ticket/2851
<lifeless> actually, let me switch channel
<exarkun> https://bugs.launchpad.net/bzr/+bug/819584 is perhaps the bug about the most recent failure
<ubot5> Ubuntu bug 819584 in Bazaar "bzr: ERROR: Pack '...' already exists in GCRepositoryPackCollection(CHKInventoryRepository('file:///.../.bzr/repository/'))" [Undecided,Incomplete]
<lifeless> poolie should be around in a little bit
<lifeless> its still early-am for him
<nigelb> morning.
#bzr 2011-08-09
<exarkun> And another one, http://buildbot.twistedmatrix.com/builders/lucid32-py2.6-select/builds/1091/steps/bzr/logs/stdio
<glyph> poolie: hi, exarkun found some bugs
<lifeless> hi nigelb
<nigelb> hey lifeless
<nigelb> hmm, I thought this was #launchpad-dev for some reason.
<lifeless> nigelb: nup :P
<nigelb> lifeless: you're everywhere, which confused me :P
<poolie> glyph, nigelb, lifeless, hi
<nigelb> hello poolie
<jam> hey poolie, I'm going to try to be back in time for the stand-up, but we're getting a late start at the house today. So don't wait on it for me.
<poolie> hi poolie, hi nigelb
<poolie> np
<poolie> hi jam
<poolie> lifeless, hi
<poolie> re bug 819604
<ubot5> Launchpad bug 819604 in Bazaar "when an idle ssh transport is interrupted, bzrlib errors" [Critical,Confirmed] https://launchpad.net/bugs/819604
<lifeless> hi
<poolie> your last comment there is correct as far as it goes but it's not really where i thought we ended up
<poolie> hm
<poolie> maybe i'll just reply
<poolie> actually my question is really: why are you unable to deploy to codehosting again?
<poolie> how is this any worse than before/
<poolie> lifeless: ^^?
<lifeless> poolie: we've stopped scheduling monthly downtime
<lifeless> poolie: and in terms of  being worse than before, we had to kill the service every deploy, before.
<poolie> so, if there is a disruption, it will disrupt them more frequently?
<lifeless> if we want to be able to experiment effectively we need a graceful option, otherwise each test is downtime.
<poolie> but, for other reasons, every deploy is downtime at the moment
<poolie> eg the xmlrpc error that comes back during a deploy
<poolie> unless that's recently fixed
<lifeless> that ticket is in progress with hloeung at the moment
<lifeless> should be fixed in a day or two I hope
<poolie> that's great
<poolie> what will happen to connections that are busy for a long time and not idle?
<hloeung> yeah, it should be done within the next couple of days.
<hloeung> poolie, I believe the hard timeout is 2mins
<poolie> which hard timeout?
<lifeless> poolie: appserver connections? or bzr connections?
<poolie> bzr
<lifeless> so, I would like to interrupt them at the next verb
<lifeless> and if we have that, we could set a decent (say 1 hour) period after which we would interrupt anyway
<poolie> ok, but what will happen today if we fix this particular bug?
<lifeless> we'd reset the timeouts
<lifeless> and have a fallback limit of 30minutes after which we would interrupt anyway
<lifeless> the lower backend timeouts would cause a timeout after (N, to be determined - say 3) minutes of inactivity, which would likely be low enough to get the CI servers and PQM and the like to migrate over to the new service instance.
<lifeless> we will need to address both bugs before we can deploy reliably with minimal interruption to users.
<jelmer> vila, do you have a pointer to the testtools-related failure on babune?
<poolie> lifeless: so, you'll leave the old back ends running for up to an hour?
<vila> jelmer: http://babune.ladeuil.net:24842/view/%20High/job/selftest-freebsd/lastFailedBuild/#showFailuresLink
<lifeless> poolie: something-like, once we've got all the friction sorted
<lifeless> poolie: at the moment no timeout is high enough - we've still got a back end running from when we cut over to the haproxy setup last week, I believe.
<jelmer> vila, poolie, jam: http://bugs.python.org/issue12544
<gour> for which date is 2.4 scheduled?
<vila> gour: we're talking about it right now, it depends on https://bugs.launchpad.net/bzr/+bugs?search=Search&field.importance=Critical&field.status=New&field.status=Incomplete&field.status=Confirmed&field.status=Triaged&field.status=In+Progress&field.status=Fix+Committed
<poolie> gour: sometime between this thursday and two weeks after that
<vila> gour: mostly bug #771184 and bug #809048
<ubot5> Launchpad bug 771184 in Bazaar "option to disable/enable fetching of all tags" [Critical,Confirmed] https://launchpad.net/bugs/771184
<ubot5> Launchpad bug 809048 in Bazaar "bzr crashed with AttributeError in stopTest(): '_TypeEqualityDict' object has no attribute 'clear' - breaks bzr selftest on oneiric" [Critical,Confirmed] https://launchpad.net/bugs/809048
<gour> cool...it's on time
<gour> what's with colo branches in 2.4? they are in core?
<poolie> not in core; very good in bzr-colo
<gour> thank you
<jelmer> https://bugs.launchpad.net/bzr/+bug/806348
<ubot5> Ubuntu bug 806348 in Ubuntu Distributed Development "BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing chk node(s) for id_to_entry maps" [High,In progress]
<jelmer> jam, vila: ^
<gour> thanks to jelmer & {hg,git} plugins, bzr is the only dvcs we use now :-)
<vila> gour: \o/
<gour> (after spending many years with darcs, played with mtn, fossil, hg...)
<gour> i've asked web2py to upgrade repo format to 2a..in order to provide correct info, since when is bzr using 2a as default?
<lifeless> since 1.19 or something - its in NEWS
<lifeless> poolie: did you want to talk about these codehosting bugs?
<poolie> on the phone at the moment
<poolie> which ones?
<gour> lifeless: ta
<fullermd> Think it only because default in 2.0.  It existed in 1.18...
<gour> fullermd: ahh...that's what we need. thanks
<fullermd> Sounds like 1.17 has support for it too...
<jam> vila: http://babune.ladeuil.net:24842/job/selftest-chroot-oneiric/lastBuild/testReport/junit/bzrlib.tests.test_selftest/TestTestResult/test_verbose_report_known_failure/
<jam> can't we just do a getattr() to handle different testtools/python versions?
<jelmer> jam: instead of checking the version you mean?
<jelmer> vila: is babune perhaps running some other pre-0.9.12 snapshot of testtools?
<jam> jelmer: I think checking versions is going to be hard to get right
<jelmer> jam: 0.9.12 introduces the fixes, 0.9.11 doesn't have them
<jam> jelmer: that specific bug is in bzrlib because of attribute issues with python's runner, right?
<jelmer> jam: ah, sorry
<jelmer> jam: There are multiple issues here
<jelmer> that one is unrelated to testtools, I've just put up a proposal for it that uses getattr
<jelmer> jam: https://code.launchpad.net/~jelmer/bzr/2.4-809048-workaround/+merge/70834
<lifeless> poolie: the two: gracefully handle tcp disconnects during idle periods of bzr+ssh connetions, and secondly a way to tell the smart server 'disconnect after serving the next verb or now if you are already idle'
<poolie> i agree they'd be useful
<poolie> i see you mentioned them in bug 795025 but they seem a bit distinct from the main bug in the bzr-sftp front end, so i might file two separate bugs
<ubot5> Launchpad bug 795025 in Launchpad itself "Codehosting service didn't stop in a timely manner" [Critical,Triaged] https://launchpad.net/bugs/795025
<poolie> i'm going to downgrade bug 819604 because it doesn't meet our definition of critical
<ubot5> Launchpad bug 819604 in Bazaar "when an idle ssh transport is interrupted, bzrlib errors" [Critical,Confirmed] https://launchpad.net/bugs/819604
<poolie> ie it's not a release blocker
<poolie> and create series tasks
<poolie> it should be fixed though
<lifeless> ok
<lifeless> poolie: so bug 795025 is about not shutting down; the *cause* for that is active sessions having no way to interupt
<ubot5> Launchpad bug 795025 in Launchpad itself "Codehosting service didn't stop in a timely manner" [Critical,Triaged] https://launchpad.net/bugs/795025
<lifeless> poolie: I don't particularly care if you want to split out a bug asking for a way to interrupt, but it seems unnecessary
<lifeless> poolie: these are critical from LP's side, in the sense of queue jumping bugs; and (as I think we've established) we cannot sensibly move forward on the forking-daemon until we have 795025 addressed in some fashion
<poolie> so for 795025 the only change needed to fix it is for bzr to close the connections, either on request or after a 5m timeout?
<poolie> (or, whatever idle timeout?)
<lifeless> on request
<poolie> i guess idleness can be done sufficiently well from haproxy,because the socket will just be idle
<poolie> well, as long as the timeout is long enough we're sure it's not just that one side is busy
<lifeless> a timeout in the server would be a nice bonus, but unless the work just fell out while looking at on-request, I would do it separately.
<poolie> sure
<poolie> i only ask because you suggested a timeout
<poolie> so as far as deployments
<lifeless> ah, I was describing the overall situation before, was probably unclear
<lifeless> yes, I think haproxy is reasonable for timeouts at least in the medium term. We will have to fiddle the timeout counter in it to find a sweet spot eventually.
<poolie> the issue is basically that if you upgrade/downgrade one of the back ends, you will need to choose between leaving the back end live indefinitely, or perhaps making long-lived clients error out
<poolie> is it intolerable to make them error?
<poolie> doesn't tarmac cope with this already?
<lifeless> no, tarmac errors out, pqm errors out, bzr-eclipse errors, buildbot errors.
<poolie> and doesn't recover?
<poolie> how has it possibly coped with our monthly roll outs so far?
<lifeless> well
<lifeless> I'm sure it does when it opens a new transport
<lifeless> users seem to find hour long test runs being aborted a bit of a pain
<poolie> ok
<poolie> i think i understand the situation
<lifeless> perhaps we can touch base tomorrow; its getting late here :)
<poolie> here too
<poolie> i don't want to have a long discussion about whether to fix it or not
<poolie> we should fix it
<poolie> i just want to have clear meanings for bug metadata
<poolie> as do you
<lifeless> yup
<poolie> unfortunately the meanings are a bit different :)
<lifeless> thats a beer topic I think
<gour> is there something one would miss for not using colo-branches when simply using shared repo and each branch in its own dir, iow. should i bother with colo-branches?
<poolie> the main difference is that it's more biased towards having one working tree
<poolie> you can also also use colo-sync-from and colo-sync-to
<gour> yeah, but i do not get if having one working tree is so important
<poolie> it's good if the tree is large relative to your disk (or other resources) or if it takes a long time to compile
<poolie> etc
<poolie> or if your tools like staying in one location
<poolie> or if your working methods do
<gour> i believe that using feature-branches is then good-enough for me
<gour> we'll stay with python for all development (qt & web2py), so compile is not really issue here (except some cython)
<poolie> jam, could you maybe give francesco a bit more of a tip where to add the test or where to look for inspiration?
<jam> vila, your recent mp: https://code.launchpad.net/~vila/bzr/migrate-config-options/+merge/70767
<vila> jam: yes ?
<jam> You mention taking the register key from the option object
<jam> but I don't see that in the patch
<vila> jam: different mp
<jam> vila: read what you wrote on that one
<jam> bullet point 2
<jam> I guess you were saying these are things that aren't part of this but would be done next?
<jam> I thought it was the list of things in this patch
<vila> jam: read what I wrote in introduction: 'follow-up'
<vila> jam: yup
<jam> vila: I tend to skim and focus on bullet points
<vila> no, the introduction was just one line
<jam> putting things that aren't part of the patch into the MP... can be confusing
<jam> anyway, looks good
<jam> just confused
<jam> vila: I have a big concern about your config stack work
<jam> booleans don't come back as booleans...
<jam> http://paste.ubuntu.com/661920/
<jam> I'm looking at how Martin is using "repository.fdatasync" and I'm pretty sure it is wrong
<jam> he is doing:         self.write_stream.close(
<jam>             want_fdatasync=self._pack_collection.config_stack.get('repository.fdatasync'))
<jam> which is sort of what I would expect. But you can't set it to "False" or "F" or ... all of those evaluate to True in python
<jam> (because they are strings)
<jam> I don't see any tests from poolie that the config item can actually disable fdatasync
<vila> jam: I'm working on the boolean config options just now
<vila> jam: you're right that there is a bug right now, my next submission will fix it though
<jam> vila: I'm looking to do something with it for 2.4. Should I just use "get_user_option_as_bool" for now?
<jam> I was also a bit disturbed that just adding that suddenly made an HPSS ratchet test fail because it went from 14 HPSS calls to *34*
<vila> jam: yup
<jam> but that could have been my fault.
<jam> (somehow)
<jam> I haven't worked through all the failing tests yet
<vila> jam: what means "something" ? You're backporting the fdatasync stuff ?
<jam> vila: I was using fdatasync to figure out how to do "no fetch tags"
<jam> only to find out it didn't work
<vila> ha right, adding a new boolean option then ?
<jam> (repository.fdatasync as an example to crib from)
<jam> right
<vila> k
<jam> also, oddly the HPSS verbs are different
<jam> branch.get_config() calls 'Branch.get_config_file'
<jam> BranchStack() calls 'get'
<jam> not even 'get_bytes' from what I can tell
<vila> Store calls get_bytes, Stack doesn't know about which files are involved
<vila> but fdatasync shouldn't care about remote repositories (unless there is a verb for that) or it's a bug no ?
<vila> s/care/apply/
<vila> s/care about/apply to/
<vila> jam: be aware that remote branches doesn't obey bazaar.conf nor locations.conf, they need a specific stack (TBD)
<jam> vila: Remote cares about fetch_tags
<jam> I didn't test anything for fdatasync in that area
<vila> jam: hehe, indeed :)
<blackarchon> someone here involved in qbzr or explorer?
<blackarchon> i'm wondering if there is indeed any code to get the window positions and window dimensions from qbzr.conf?
<jam> blackarchon: I haven't poked at that code recently, but ISTR that there are window positions that are remembered
<jam> I think it involves deriving from a particular class
<jam> like QBZRWindow or somethign
<blackarchon> well I'm asking because this doesn't seem to be working at all
<blackarchon> ok, I will try to find the exact place for this restoreSize function which is called
<vila> blackarchon: AFAICS, there are options for *size* but not for *positions*
<hikiko> hello
<hikiko> I would like some help: I ve created a branch of a project and I want to commit to it
<hikiko> (a launchpad branch)
<hikiko> when I use the command: bzr commit -m "blah blah"
<hikiko> I get the following error:
<hikiko> bzr: ERROR: Cannot lock LockDir(lp-86944400:///%2Bbranch/stellarium/.bzr/branchlock): Transport operation not possible: readonly transport
<hikiko> although i am logged in in launchpad
<hikiko> do you have any idea on what I am doing wrong?
<vila> hikiko: you probably don't have *write* access on this branch (actually, you're probably using a checkout which is bound to the remote branch instead of a local branch that you then push somewhere else)
<hikiko> how can I change this? I mean what I did was: checkout the project code
<hikiko> then create my launchpad user and branch
<hikiko> and then attempt to commit
<hikiko> what step is missing?
<hikiko> oh
<hikiko> I see
<hikiko> you mean i have to do sth like:
<hikiko> bzr branch lp:~<link to my branch>
<hikiko> and then change that code
<hikiko> and bzr push lp: ...
<hikiko> ?
<blackarchon> yes, this would work.
<fullermd> If you checked out _before_ creating your LP user, the checkout is connected over a _non-logged-in_ transport.
<hikiko> yes I checked before
<hikiko> and if I want to update
<hikiko> bzr up
<hikiko> will give me the new code from the branch or from the project?
<hikiko> ok I found it :)
<hikiko> thank you very very much for your help all!
<blackarchon> um... where can I find the default ignore file, which is installed with bzr?
<LeoNerd> ~/.bazaar/ignore  perhaps?
<blackarchon> no, I edited it - and left no backup of it :(
<fullermd> 'm pretty sure bzr writes it if it doesn't exist...
<blackarchon> oh yes? let me try...
<LeoNerd> mv it away and start again?
<fullermd> Semirelatedly, it's probably rather discouraged to be editing it, as a rule.  Since it would no longer match what anybody else has, you can wind up with surprises in branches multiple people touch.
<blackarchon> well no, it doesn't get magically recreated :(
<fullermd> If I mv mine out of the way and run a 'bzr stat', it writes out a new one...
<blackarchon> ah yes, but only if this bzr command succeeds
<blackarchon> my bzr stat wasn't inside a bzr directory, so it hasn't created the file - thx! :)
<blackarchon> I want to fix this bug: https://bugs.launchpad.net/qbzr/+bug/578935
<ubot5> Ubuntu bug 578935 in QBzr "qbrowse crashes when run in repository: 'NoneType' object has no attribute 'last_revision_info'" [High,Confirmed]
<blackarchon> so I added a check if the argument isn't a branch or a wt
<blackarchon> https://code.launchpad.net/~andrebachmann-dd/qbzr/fix_qbrowse
<blackarchon> but I still need an idea of how to proceed, I want to disable all objects in qbrowse
<blackarchon> but I don't have the right hought on how to do that
<blackarchon> any hints?
<vila> more than 3 hours to land on pqm, is it me or it's getting worse ?
<jelmer> vila, it's not just you
<vila> jelmer: :)
<jelmer> vila: can you submit my 2.4 branch? I don't seem to have permission to submit to release branches
<vila> jelmer: 2.4-809048-workaround ?
<jelmer> yep
<vila> done
<jelmer> vila: thanks
<vila> jelmer: nothing showing up on pqm for now :-/
<vila> jelmer: ok, here it is
<vila> jelmer: thanks for that ! Merge it into trunk when you can !
<jelmer> will do :)
<vila> ok, I'm off, see you online on Thursday ;)
<santagada> jelmer: dots don't work on bzr 2.1, only none works
<santagada> jelmer: and I think that for deployment we can't wait for launchpad so we will just tar everything up to the clients
<lifeless> morning poolie
<poolie> hi thar
#bzr 2011-08-10
<poolie> lifeless, i'm going to have a stab at ssh reconnection
<lifeless> poolie: awesome!
<poolie> will be awesome if i fix it, anyhow
<lifeless> poolie: its awesome that you're looking at it, really.
<lifeless> poolie: much appreciated
<thomi> Hi poolie - quick Q: There was some discussion here last Friday regarding the new config file features, and I'm not sure if that changes the next step for my config patch or not. I got the impression that maybe the PatchMatching idea was being dropped?
<poolie> i don't actually know what that is
<thomi> oh - hmm, it seems the devnotes have changed since then anyway :)
<stylesen> poolie: ping
<poolie>  hi stylesen
<stylesen> poolie: pm ?
<gour> i've pulled one branch from LP, converted it to 2a format and now pushing back to my account at LP...is starts speedy, but then it slows down..as a hell...yesterday i had to kill it after 6 hours...it's ~3500revs...any idea what might be wrong?
<lifeless> you haven't converted the copy on LP
<lifeless> at a guess
<gour> i've converted locally
<lifeless> are you pushing to the same branch on LP ?
<gour> the original branch is lp:~mdipierro/web2py/devel and i'm pushing to  lp:~gour/web2py/devel
<gour> here is what i see now: 105548kB    28kB/s / Fetching revisions:Inserting stream:Estimate 51443/54666 and after it arrives at 51000 it crawls
<lifeless> interesting
<lifeless> uhm
<gour> 3500revs is not so big, imho
<lifeless> I suggest filing a question (or asking here in an hour or so - I have to go, and I don't think jam or jelmer or vila are here yet)
<gour> lifeless: ok. thank you...i'll wait here
<gour> jelmer: hello. lifeless told me to ask you, vila or jam about my problem of slow upload to LP...do you mind?
<jelmer> hi gour
<jelmer> gour: what's slow exactly?
<gour> jelmer: push...after some time it starts crawling
<gour> jelmer: the original branch is lp:~mdipierro/web2py/devel and i'm pushing to  lp:~gour/web2py/devel after i converted branch to 2a format
<gour> today i got 'Write failed: Broken pipehing revisions:Inserting stream:Estimate 51485/54666' and yesterday i killed push after not being complete in 6 hours
<gour> my adsl is 256k/4M
<jelmer> gour: how big is the repository?
<gour> jelmer: ~3500revs...let me size it
<gour> jelmer: hmm...tar.gz is 1.1G...no wonder, but i see lot of stuff like 'web2py/.bzr/repository/obsolete_packs/...' is it normal?
<gour> let me check what is the size of original branch in old format
<jelmer> the obsolete packs can be removed
<gour> just remove obsolete_packs directory?
<jelmer> there's no need to remove it, but you should be able to, and please exclude it when looking at the size of the repo
<gour> i'm pulling orignal repo now
<gour> obsolete_packs occupy 590M and ../repository/packs is 577M
<fullermd> Don't remove the _directory_.  Removing the files _in_ it should be fine.
<gour> jelmer: here http://pastebin.com/pQ9LQvVA is du for old format and here http://pastebin.com/bk3xFdG6 for a 2a format which is 2x bigger...is it normal?
<jelmer> gour: that seems to be purely because of the obsolete packs
<jelmer> so it's normal, as the obsolete packs can be removed
<gour> why are they created?
<fullermd> Because some filesystems are lying liars that lie.
<fullermd> (and even when they aren't, the hardware picks up the slack by lying on their behalf)
<gour> heh
<gour> I rm-ed obsolete packs...now checking repo
<jelmer> gour: lp:~gour/web2py/devel doesn't appear to exist
<gour> jelmer: yes, it did not complete
<gour> so i rm-ed it
<jelmer> gour: I'm wondering if perhaps it was in an older format, and bzr was trying to convert back from 2a into that format
<jelmer> while doing the push
<gour> lp:~gour/web2py/devel is supposed to be the original branch in 2a format
<gour> jelmer: no, it was not exuisting before
<gour> however, original web2py is still in old format
<gour> now 2a branch repo is 591M...let me try to push it
<jelmer> gour: not having the obsolete packs won't impact performance in any way
<fullermd> What might LP's stacking stuff do, to pushing a 2a variant of an older format branch?
<gour> let me see if it will complete now in reasonable time...
<gour> it arrived at ~4850/51093...and now it is becoming very slow...
<gour> i cloned original hg repo from google and pushed it to bitbucket...it did the job in ~15mins (14:09,85 total) while pushing to LP is still crawling...it's very frustrating
<jelmer> gour: ah, the original is an import from hg?
<jelmer> gour: that might be related
<gour> jelmer: yes
<gour> but don't know how it's done
<jelmer> what was the original again?
<gour> lp:~mdipierro/web2py/devel
<gour> i'm resisting to use git (bzr-git is great), but there are more & more projects using hg...and things like this make it cumbersome
<jelmer> hmm, doesn't appear to've be done with bzr-hg
 * jelmer tries reproducing the issue
<gour> jelmer: original repo is at hg clone https://code.google.com/p/web2py/
<gour> jelmer: however, bzr branch is regularly synced
<jelmer> gour: not using bzr-hg, that doesn't support the pack-0.92 format
<gour> well, i do not use bzr-hg at all for this repo
 * gour quit-ed push to LP...
<gour> and i wonder how he converts from hg to bzr...
<jelmer> gour: I'm running the upgrade here now, will try to push in a second
<gour> jelmer: thanks a lot
<jam1> jelmer: I'm pretty surprised about how many web2py branches are on Launchpad, given that there isn't a development focus, so they should all be 500MB or so
<jam> anyway, time to pick up my son, catch you guys later
<jelmer> hdy jzm
<jelmer> I mean
<jelmer> Hey jam :)
<jelmer> jam: Have a nice evening
<fullermd> Shoot, you missed by the _whole_ alphabet!   :p
<gour> lol
 * jelmer hits fullermd on the head with the alphabet
 * fullermd is consonantly abused like this   :(
<jelmer> hehe
<gour> jelmer: i've to go out. bbl in ~2hrs
<jelmer> gour: k
<jelmer> gour: push just finished here: bzr push lp:~jelmer/web2py/test  10.66s user 1.19s system 0% cpu 42:35.45 total
<jelmer> gour: it looks like the hg repository has significantly different contents
<Quintasan> jelmer: I think it was some time ago and maxb even told us about it but I forgot to say thanks for fixing bzr in LP so we have KDE imports working
<jelmer> Quintasan: np :)
 * Quintasan is sure forgetful
<jelmer> Quintasan: does that mean all recipes are working now?
<Quintasan> jelmer: If the code inside the branches is working then yes :P
<jelmer> :)
<jimis> jelmer: I got a notification that a fix is ready regarding the bug about lp:gcc svn import timeout
<jimis> Is it to not fetch the tags at all?
<jelmer> jimis: it will fetch the tags but not the revisions those tags are referencing, if those revisions are not part of the ancestry of the branch
<jelmer> jimis: this is consistent with what it did earlier
<jimis> jelmer: did you try increasing the timeout value in Twisted?
<jimis> I haven't worked with Twisted, but here is a relevant thread I found, in case you missed it:
<jimis> http://osdir.com/ml/python.twisted.web/2006-02/msg00048.html
<jelmer> jimis: I'm not sure I follow; how is twisted relevant here?
<gour> jelmer: what do you mean 'different contents' ?
<jimis> jelmer: http://launchpadlibrarian.net/73597623/vcs-imports-gcc-trunk.log
<gour> you have a nice conenction considering it took 42mins only
<jimis> jelmer: Isn't it the same error, twisted.internet.error.TimeoutError?
<jimis> gour: which bzr version you have?
<gour> jimis: 2.3.4
<jimis> I've seen major improvements with 2.4, related to how much data is actually downloaded
<jimis> I wouldn't know if that's relevant to your case however
<jimis> lp:gcc is a huge branch, and it's *unworkable* with 2.3
<gour> jimis: that would be nice improvment..the present sitaution is almost like showstopper
<jimis> 2.4 is working just fine though, even if it feels a bit sluggish (expected with huge repos like this)
<jimis> gour: I'm not sure if it will help your case, but it's easy to try the beta
<gour> jimis: i may try it
<jimis> just make sure your python is >= 2.6
<gour> 2.7.2 here
<jelmer> gour: there is a different number of revisions in both repositories, and the actual files seem to differ
<jelmer> gour: I think my bzr version probably matters as well - what are you running?
<gour> hmm...strange
<gour> jelmer: 2.3.4
<jelmer> gour: So I'm curious how one branch is created from the other
<gour> me too
<jelmer> jimis: the error message is the same, but it's got nothing to do with the actual problem
<jimis> jelmer: ok, I wouldn't know
<jimis> I saw a timeout, so I thought increasing the socket timeout would mitigate the error...
<fullermd> Latency may contribute too; you're probably closer to LP than he is.
<fullermd> Though one would hope that the smarts are smart enough that that's unimportant in such a case...
<jelmer> I'm running 2.4b5, which I suspect will matter.
<gour> i see
<jelmer> gour: the bzr repository includes a bunch of tar files, the hg one does not
<jimis> Just my opinion here: Guys, try to push 2.4 forward as fast as possible, older versions make bzr look like a fool for big projects...
<jimis> I had lost several hours waiting on 2.3 to finish until I came to this channel and you told me to try 2.4 beta
<jelmer> jimis: 2.4.0 will be released in 2 days (:
<jimis> good :-)
<jelmer> gour: the hg repo history doesn't start until dec 2009, until well after those tarballs were removed from the bzr repo
<jelmer> gour: another thing that will help is setting the development focus for web2py on launchpad
<jelmer> gour: and upgrading the main branch to 2a
<jelmer> that will mean every push of a new branch to launchpad won't push up any revisions that are in the development focus
<jelmer> jimis: I agree, although it only matters for the *really* big projects like gcc
<jimis> jelmer: 2.4-final will be incompatible with python 2.4 after all?
<jimis> since I'm running it on RHEL I had to fight around this issue too
<jimis> it's fine now, I'm just curious
<indigo> i'm pondering ways to bring the benefits to revision control to people in my company that spend most of their time in excel and email. Is there a really, really simple, graphical interface to bzr that I should consider?
<jelmer> indigo: qbzr/bzr-explorer/tortoisebzr are the ones to consider I think
<jelmer> I don't have much experience using a graphical interface exclusively
<jelmer> jimis: yeah
<gour> jelmer: i suggested main dev to upgrade to 2a, but wanted to try it ourself first...and those problems are not really auspicious to push migration...
<gour> is there anything special in usinb bzr in-place? i'd like to try 2.4beta
<jelmer> gour: using it in place should be fine, except for plugins that might give warnings
<gour> jelmer: ok, i did 'home' install
 * gour is pushing with 2.4b5
<jelmer> gour: you probably want to make sure the extensions were built and installed too
<gour> jelmer: i believe that, based on --version output, it's ok
<gour> hmm...warning about some extensions
<gour> but launchpad is 2.4.b5
<jelmer> gour: I mean the C extensions
<gour> jelmer: that was built
<urbanape> Hey, all. Using Ubuntu 11.04, with Emacs Snapshot GTK, vc-bzr, and have gpg-agent installed. I'm still having trouble signing my commits. I get the following error: http://paste.lisp.org/display/123944
<urbanape> I've checked (both via shell-mode and getenv) that my GPG_AGENT_INFO is available to emacs.
<urbanape> Google is not much my friend in this regard, but I've searched for 'vc-bzr gpg sign commits' and the like
<jelmer> urbanape: does it work outside of vc-bzr?
<poolie> hi all
<lifeless> hai
<urbanape> jelmer: yes, it does, even from within emacs (shell-mode)
#bzr 2011-08-11
<urbanape> jelmer: http://paste.lisp.org/display/123948
<poolie> hello all?
<spiv> poolie: hi ;)
<poolie> hello
<poolie> could you sanity check https://code.launchpad.net/~mbp/udd/819910-service-root/+merge/71154
<spiv> poolie: ugh, but +1
<vila> Morning all !
<poolie> hi vila, and goodbye
<poolie> i might be back later
<vila> hi poolie, cu later
<jam> morning vila and poolie (if you are back)
<vila> hello jam
<jam> brb, pidgeon forgot who I am again
<jelmer> hi jam, vila, poolie
<jam> morning jelmer
<vila> jelmer: hey !
 * fullermd continues in his quest to outlaw mornings...
 * vila suggests to shut down the sun
<vila> oh wait Oracle did that already
 * fullermd *rimshot*
<fullermd> Shutting down the sun would have the added bonus of the temperature staying out of the 3 digit range.  For a while, anyway.
<vila> nah, bad plan, it will make it harder to boil water (that's what the 3 digit temperatures are about really) and as such coffee production will become harder, definitely a no-go
<fullermd> You can cold press coffee, in extremis.  I just wish it would stop trying to boil water everywhere outside my front door.
<vila> :)
<vila> In other news, with tag fetching being optional and equality_funcs.clear workaround in place and bug #822571 fix backported to 2.4, I'm ready to freeze 2.4.0
<ubot5> Launchpad bug 822571 in Bazaar 2.4 "bzrlib.tests.blackbox.test_version.TestVersionUnicodeOutput.test_unicode_bzr_home fails" [High,Fix released] https://launchpad.net/bugs/822571
<jelmer> vila: \o/
<jelmer> hi Riddell
<vila> jam, poolie, jelmer: pqm was very slow the day before yesterday, dunno if this has changed, but to be safe, please leave pqm alone (or I'll ask losas to kill the submissions ;)
<Riddell> hello jelmer
<vila> Riddell: hey ! You're back :)
<vila> Riddell: welcome back then :)
<jelmer> Riddell: how's the desktop summit?
<vila> Riddell: please leave pqm alone too ;)
<jelmer> vila: :)
<Riddell> jelmer: desktop summit was fun, I got some ideas for Bazaar
<fullermd> Apparently I'm still allowed to ridicule pqm about its childhood etc though.
<vila> fullermd: sure :)
<jelmer> Riddell: cool
<maxb> poolie: I'm curious about your UDD change today, because the previously existing code in udd should have already accounted for the issues concerned
<jam> vila: babune just stopped responding for me, did something happen?
<vila> jam: nothing I'm aware if
<vila> of
<vila> even
<spiv> maxb: that probably explains why his change didn't make any difference on production :)
<jam> vila: seems it was just slow because I was loading multiple pages at once
<jam> or maybe something on my end, given I just DCd from IRC
<jam> vila: I can't reproduce the "PermissionError" bugs, but some of the others I can fix
<vila> \o/
<jam> vila, mgz: One of the tests is a testtools bug
<jam> well, test_selftest is asserting the output
<jam> however the "if" check says "if version <= (0,9,11)"
<jam> but my testtools.__version__ == (0, 9, 11, 'final', 0)
<jam> which is > version
<jam> anyway, "testtools_version[:3] <= " works
<vila> jam: I plan on upgrading testtools on the slaves asap, will that workaround the issue ? (a fix would be better nevertheless)
<jelmer> I guess we could fix the check to use testtools_version[:2]
<jam> jelmer: [:3]
<jam> :2 is (0,9)
<jam> (it is an exclusive range)
<jelmer> jam: ah, right
<jam> vila: both selftest failures were because of that
<jam> I don't know if there is anything else, though, and this is an easy fix
<vila> jam: you mean for windows or you looked at all slaves ?
<jam> vila: https://code.launchpad.net/~jameinel/bzr/2.5-win32-fixes/+merge/71176
<jam> vila: On the windows slave is what I was looking at
<vila> k
<jam> it was checking against 0.9.11 but the checks had the wrong bounds because of the 3-tuple vs 5-tuple
<poolie> hello maxb
<poolie> maxb, i think my change was misguided anyhow, as it doesn't seem to have fixed it
<vila> poolie: I think I lost track about what was planned for pqm, but landing a patch takes more than 3 hours these days so we probably want to do *something* ;)
<poolie> ah, maybe due to it syncing a lot while running the tests?
<vila> ouch
<vila> I was hoping for some unusual load there or some other misbehavior of the host instead :-}
<poolie> that's possible too
<poolie> ask a losa for help?
<vila> poolie: sure, I wanted to check if I was up-to-date first. So nothing has occurred lately right ?
<poolie> i'm not aware of anything else that could have broken it
<vila> ok
<fullermd> What sort of hardware does it sit on?
<poolie> oh, tom was doing some work on setting up a new pqm box, but i didn't read anything about him having changed the existing machine
<poolie> fullermd: an old DL-series hp server i think
<fullermd> Running raw, not virtualized?
<poolie> in a chroot
<poolie> biab
<fullermd> Wouldn't expect the fsync stuff to make a night and day change.
<vila> fullermd: I don't have hard numbers but it seems we went from < 2 hours to > 3 hours
<fullermd> Though the cost isn't trivial.  Still, sounds like an OOM-ish hit on PQM from whatever.
<fullermd> Hm.  I figured pqm ran the test suite in 20, 30 minutes.
<jelmer> vila: are you done with pqm?
<fullermd> The timing poolie gave in the MP for fdatasyn showed ~20% increase.
<vila> jelmer: not yet, still at least one submission to open 2.4.1 (which requires the current one to finish) and potentially a second submission to merge 2.4 to trunk
<jelmer> vila: *nod*
<vila> jelmer: thanks for your patience (though mine is running thin....)
<poolie1> hi vila, jelmer
<jelmer> hey poolie1
<vila> poolie1: so, tom said the new pqm may be ready in a week or two
<vila> also, it seems we're racing with u1 on the actual one which may explain the slowing
<poolie1> ok
<poolie1> we should see about turning off fdatasync during tests
<jam> poolie1: did you see that your config stuff for fdatasync doesn't work?
<jam> the new ConfigStack doesn't know about 'bool'
<jam> so setting it to "False" returns a string which evaluates to True always
<jam> I think you could set it to the empty string
<jam> or an empty list
<jam> (btw, you don't have any tests for it working. :)
<poolie1> :/
<jam> poolie1: I only found out because I was trying to copy your work for my config
<jam> and hey, setting it to False doesn't do anything wth?
<poolie1> we'd better fix that for 2.4.0 then
<vila> that would be for 2.4.1, 2.4.0 is already cut and landing on pqm, with tag
<poolie1> are the criticals all fixed+
<poolie1> apparently yes,that's great
<poolie1> jam, did you file a bug for that?
<vila> yes, I downgraded one since it was covered by the optional tag fetching
<vila> we way still want to bump it to critical for udd though
<vila> poolie1: I'm talking about bug #806348
<ubot5> Launchpad bug 806348 in Launchpad itself "BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing chk node(s) for id_to_entry maps" [Critical,Triaged] https://launchpad.net/bugs/806348
<vila> surprising... ubot5, why do you report about launchpad when bzr is the first project listed on the page and the primary project seems to be udd...
<vila> (primary as in: http://pad.lv/806348 resolves to https://bugs.launchpad.net/udd/+bug/806348)
<ubot5> Launchpad bug 806348 in Launchpad itself "BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing chk node(s) for id_to_entry maps" [Critical,Triaged]
<vila> bah
<poolie1> mm?
<Riddell> vila: can I send things to PQM yet?
<vila> Riddell: nope
<vila> Riddell: :)
<vila> Riddell: or rather, you can, but I will ask a losa to kill it ;)
<poolie1> vila, when did you first notice problems?
<vila> I think I asked to jelmer a couple of days ago
<vila> I tried toying with webnumber but it's not accurate enough to be conclusive
<vila> http://webnumbr.com/bzr-pqm-queue-length.from%282011-06-27%29.to%282011-06-28%29
<vila> http://webnumbr.com/bzr-pqm-queue-length.from%282011-08-09%29
<poolie1> i don't think that's going to really correlate with much though
<poolie1> i guess we could look at mail that was sent to pqm and when it was returned but it's probably easier to see if the sysadmins can find a log for you
<vila> poolie1: yeah, but since the new hardware is expected soon-ish, I'm not sure it's worth investigating either (tom prefer to focus on the new hardware and I see no point disturbing it)
<jam> vila:  because L comes before U, but magically after B?
<poolie1> ok i think i understand the httperror bug
<vila> poolie1: \o/
<vila> jam: I killed your windows fixes submission and re-submitted it
<jam> vila: you're the one that killed my submission?
<jam> k
<jam> I was a bit concerned about a failed test run with no failures
<vila> jelmer, Riddell : feel free to overload pqm now ;)
<jelmer> \o/
<Riddell> vila: what happened?
<poolie1> vila, did you actually kill it or just ask for it to be killed?
<vila> Riddell: cutting a release requires two submissions: one for the release and its tag, one to open the branch for bugfixes, I prefer to pull between the two and not leave the branch in the transient state where nobody can land
<vila> poolie1: I asked a losa
<urbanape> jelmer: sorry I didn't get back to you earlier last night.
<jam> poolie1: he rooted the machine via DDOS and a bug in pqm's web front end, I think :)
<jam> he's really determined that his patch be next
<jelmer> urbanape: np, I'm afraid I don't really have an answer either though. It seems like the issue is with the way the vcs-bzr script in emacs runs
<jelmer> urbanape: (without a tty)
<urbanape> gotcha. okay, bummer
<urbanape> aha!
<urbanape> awesome
<urbanape> I added --no-tty to my agent-gpg script
<urbanape> ta-da
<jam> poolie1, vila: Even more fun. If you do "c = ConfigStack(); c.set('foo', True); c.get()" Returns True the object. But if you write it out, and then create "c2 = ConfigStack(); c2.get()" it returns u'True' the string.
<jelmer> urbanape: ah, that was easy :)
<poolie1> yuk
<urbanape> jelmer: it was
<vila> jam: see my boolean-option (submitted to pqm)
<jam> vila: sure. I'd put it pretty high in the 2.4.1 queue, given that one of the caveats for fdatasync is that people can disable it if they notice a slowdown
<poolie1> thanks vila
<jam> vila: I'm a bit concerned that it requires an api break for a stable series. Should we just switch the code to config.get_user_option_as_bool() ?
<jam> (I guess it isn't a major break)
<vila> jam: the easiest may be to not use configstack at all for the datasync options then. Alternatively, options are strings unless specified otherwise (and in 2.4 nobody specifies otherwise ;)
<vila> jam: yup, that's another alternative, whatever works
<vila> jam: but I agree, backporting boolean-option to 2.4 is a no-go
<vila> jam: and thanks for spotting the issue
<jam> bug #824513
<ubot5> Launchpad bug 824513 in Bazaar 2.4 "config item repository.fdatasync doesn't work as expected" [High,Confirmed] https://launchpad.net/bugs/824513
<vila> the 2.4.1 milestone has been created and the lp:bzr/2.4 is almost opened for bugfixes (you have to wait for the current submission to land to base your branch and get the proper news file)
<vila> Riddell: see above for why I don't like to leave the branch in this transient state :0D
<vila> poolie1: the suspense is killing me, what caused the httperror ??
<vila> :)
<poolie1> see the bug
<vila> wow
<jonathanj> where does bzr cdiff get its colour information from?
<poolie1> that was such an annoying api break
<poolie1> i have some uncommitted changes that i think ought to fix it, but perhaps they don't
<fullermd> Gruuh, LP makes bzrtools difficult...
<fullermd> It says the latest is 2.3.0.  You have to dig to find that (a) there's a 2.3.1 succeeding that, and scroll way down in a list to find 2.4.0.
<vila> fullermd: gigo :-/
<fullermd> It always makes me laugh (funny dear-god-no, more than funny ha-ha...) at how every new bzr release makes me have to work with CVS   :|
<urbanape> jelmer: hmm, I must have done something slightly odd, because now subsequent commits are now blocked. Getting errno 13: Permission denied. I don't see any lock files in the branch-lock directory under .bzr.
<jelmer> urbanape: are you sure it's bzr that's blocked, not gpg?
<Chex> hello there, can someone help me with a bzr branch issue I am having, trying to deploy branches for ISD ?
<Chex> jelmer: I was given your name to try to see if you could help me. :)
<jelmer> Chex: hey!
<jelmer> Chex: Of course, happy to help
<Chex> jelmer: awesome, thank you.. look here: https://pastebin.canonical.com/51102/
<Chex> and here, for related info: https://bugs.launchpad.net/config-manager/+bug/823010
<ubot5> Ubuntu bug 823010 in config-manager "bzrlib error, cannot find revision in branch" [Undecided,New]
<Chex> jelmer: this is a private branch, you wont be able to pull it yourself, but the account we are using has proper access to the branch
<gour> is colo-branches same thing as hg's named branches?
<jelmer> hi gour
<gour> jelmer: hiya
<jelmer> gour: in some regards
<gour> I'm now pulling via bzr-hg from google
<jelmer> gour: it's not exactly the same thing, but they both allow using multiple branches under one file system location.
<jelmer> gour: did 2.4 work any better for the large branch for you yesterday?
<gour> jelmer: not much...i killed it...however repo @google is 24M..it makes a difference
<gour> it was more speedy, but still too slow
<gour> ahh...conection with google dies after 8mins
<jelmer> gour: well, it's almost 600Mb of compressed data
<gour> jelmer: right...it's big repo
<gour> now tryingto pull from google with 2.4
<gour> otoh, hg's named branches are cool...they're, iirc, in mtn, fossil
<jelmer> gour: branch nicks in bzr are pretty similar
<jelmer> gour: when tracking what branch a revision came from
<jelmer> colo-branches is more like git branches
<jelmer> the combination gives you something similar to hg branches
<gour> hmm...it looks i've to re-read bzr docs a bit
<gour> based on taht i read in hg docs, bookmarks are similar to git branches
<jelmer> gour: that's hg bookmarks probably, though?
<gour> yes, hg bookmarks
<gour> too bad LP does not have project wikis like bitbucket...
<jelmer> there was somebody working on that
<jelmer> jml: do you know how far that's gotten?
<gour> well, bug is quite old and still not on horizon (low priority)
<gour> jelmer: how do bzr & hg compare today, considering 2.4 & 1.9.x ?
<gour> (in general)
<jelmer> gour: There was a community developer actively working on it a month or two ago
<jelmer> gour: I'm not sure, my familiarity with hg doesn't really extend beyond the lower levels
<gour> ok
<jelmer> vila: when is 2.4.0 scheduled for?
<gour> pulling with bzr-hr from google is slow..
<jelmer> gour: sure, bzr-hg is still fairly experimental and not really optimized yet
<vila> jelmer: next Tuesday
<jelmer> vila: roger
<vila> jelmer: if pqm can handle the load :-/
<vila> err :)
<jml> jelmer: how far what?
<jelmer> jml: the wiki LEP, do you know what happened to it?
<jml> jelmer: yeah. it's finished & rotting.
<jelmer> jml: :-(
<jml> jelmer: I didn't expect otherwise. Long drawn-out conversations about how we should do something that no one is actually planning to do tend to end this way.
<gour> ok...16mins...let's try to push to LP now
<jelmer> jml: I guess it means at least we have *some* idea of the constraints and requirements
<jml> jelmer: yeah, I hope so. Although until people are actually using it, it's all just waste.
<urbanape> jelmer: not sure. But removing arguments from my vc-bzr-gpg script so that it just calls '/usr/bin/gpg $@' doesn't clear it up, and adding -v to the bzr ci doesn't offer any more information.
<mthaddon> anyone able to help me troubleshoot the new PQM server?
<mthaddon> getting https://pastebin.canonical.com/51118/ and test suite has been running for 50 mins or so
<vila> mthaddon: for bzr ?
<mthaddon> vila: yeah, for the new bzr pqm server
<vila> 50mins is not unusual
<vila> the warnings are a bit worrying though, pqm needs some update obviously
<mthaddon> vila: but this is on much faster hardware, with nothing else happening on the box
<vila> do you have /tmp on a tmpfs ?
<mthaddon> vila: it's running the same version of PQM as the current PQM instance
<mthaddon> vila: nope (nor does the current one)
<mthaddon> (will be doing that later once we get one successful run)
<vila> huge boost for bzr test suite, but you're the judge
<vila> anyway, there should be one or two files to track progress, let me check the makefile
<vila> 'selftest.log' in the directory where the command run
<vila> mthaddon: running 'subunit-stats < selftest.log' may even gives you a summary
<mthaddon> vila: that doesn't seem to have updated since 2011-07-27...
<mthaddon> nm, my mistake
<vila> np
<mthaddon> vila: https://pastebin.canonical.com/51122/
<vila> mthaddon: something bad is going on, NoSuchFile in _check_safety_net... doesn't make sense
<mthaddon> vila: what kind of bad?
<vila> unless the tmp dir was deleted before the end of the run ???
<vila> mthaddon: a kind I don't understand
<vila> check_safety_net is there to protect against some test bugs, but I almost never see it fail
<vila> spiv changed it recently IIRC but that was for performance reasons and I never see it fails either
<vila> mthaddon: does /tmp/testbzr-W7TYpR.tmp/ exists ?
<mthaddon> vila: https://pastebin.canonical.com/51124/
<vila> -R ?
<mthaddon> https://pastebin.canonical.com/51125/
<vila> mthaddon: do you get the same result if you do that again ? (ls I mean)
<vila> a lot of files are missing there
<vila> and dirs
<mthaddon> yeah, same result
<vila> mthaddon: my best guess would be that something went wrong very early in the test suite and failed to build the safety net (a bzr tree that no test should modify)
<vila> and now all tests fail because the net has been damaged (in fact, it looks like a branch lock failed halfway)
<vila> mthaddon: but that's a wild guess as I said, I never saw such a failure
<mthaddon> hmm
<vila> mtaylor: the begining of selftest.log may shed some light ?
<vila> mtaylor: sry, silly auto-completion
<vila> mthaddon: the begining of selftest.log may shed some light ?
<mthaddon> vila: chinstrap:~mthaddon/selftest.log.gz
<micahg> does bzr + pristine-tar have the ability to reproduce .bz2 tarballs?
<vila> mthaddon: wow
<vila> KeyError: 'getpwuid(): uid not found: 2005
<maxb> micahg: Yes, I think it's just .xz that's the problem at the moment.
<micahg> hmm, ok, I guess it was a bad merge-upstream then...
<vila> mthaddon: and indeed it was in _create_safety_net
<mthaddon> vila: so is that an environment issue, or a test suite issue?
<vila> mthaddon: I suspect it's a chroot issue as we are trying to expand ~ and fails
<vila> mtaylor: /etc/passwd missing entries in the chroot kind of stuff
<mthaddon> vila: I think I can reproduce - thx, will get that fixed and retry
<vila> mthaddon: cool, './bzr selftest -s bb.test_add.TestAdd.test_add_control_dir' in the chroot should reproduce it without running the full test suite
<mthaddon> k
<jelmer> maxb: .xz should work too, it's just fairly inefficient because pristine-tar doesn't have proper support for xz
<jelmer> micahg: are you running oneiric?
<micahg> jelmer: not on the machine I was doing this on
<jelmer> micahg: there's a bug with bz2 support in natty, that might explain the issue you were seeing
 * micahg tries in oneiric
<micahg> jelmer: nope, still fails to make a .bz2 tarball
<jelmer> micahg: what fails exactly?
<micahg> jelmer: I have no guarantee a bz2 tarball was even imported into the branch
<micahg> it makes a .orig.tar.gz
<jelmer> micahg: what command are you running?
<micahg> bzr bd  --orig-dir=../tarballs/
<jelmer> micahg: how was the upstream tarball imported into the branch?
<micahg> no idea
<jelmer> micahg: it's likely that it went wrong there
<micahg> supposedly using bzr merge-upstream, will have to find out later, too close to FF to debug
<jelmer> micahg: is the branch public?
<micahg> jelmer: let me get some more information from the committer and get back to you, wouldn't want you to go on a wild goose chase
<jelmer> micahg: thanks
<jml> mgz: this bytes/unicode thing is doing my head in
<mgz> ehhee
<mgz> jml: and if you've not read PEP 383 yet, which poolie linked the other day, know that it only gets messiuer
<mgz> -u
<mgz> I think testtools is basically there, on a hard problem, apart from two things
<jml> I haven't.
<mgz> 1) Matcher and Mismatch classes need to not use %s, specifically StartsWith and MatchesRegex
<mgz> 2) __str__ on Python 2 should mangle to ascii rather than return unicode and blow things up
<jml> Ahhh, you *say* that.
<mgz> testtools can be smart and try __unicode__ first, and other if the objects leak into other less careful libraries they won't be harmed
<mgz> in fact, testtools already is smart.
<jml> mgz: you mean something like http://paste.ubuntu.com/663608/?
<mgz> I'd have spelled it differently, but yup, looks about what I was thinking
<mgz> did it cause issues?
<mgz> the only issue remaining from there is to not let non-ascii bytestrings in, which is why StartsWith etc needs chaning
<jml> mgz: yeah
<mgz> *changing
<jml> mgz: even on Equals(), you get an unprintable assertion.
<mgz> that's the describe() return issue.
<mgz> I think it might be best to check the type in that __unicode__ function and do something similar to how bytes() get repr-ed in Python 3, rather than trying to fix every method...
<mgz> hm.
<jml> http://paste.ubuntu.com/663616/ for something to muck around with.
<mgz> yup, that's the kind of assertion that we want to work for people.
<mgz> okay, I'll think a bit and throw some code up
<mgz> ...not as in vomit, though I don't guarentee it won't look like that
<jml> http://paste.ubuntu.com/663619/
<jml> more data
<jml> mgz: heh heh
<jml> mgz: also, I didn't really know how to turn your demo tests into actual tests.
<jml> mgz: just pushed up my latest changes, fixes the _exception_to_text abstraction violation.
<jml> mgz: but, however you choose to project your code onto the internet, it would be much appreciated.
<mgz> yeah, I left the demo file as was because getting into another layer of assertions gets really confusing, it's clearer to just see the output as a testtools user would
<jml> fair enough
<mgz> tests for the things that then make those cases work as intended are writable
<mgz> (what type the describe() method returns on non-ascii mismatches etc)
<jml> cool. I tried naively turning them into tests, and they all passed, which isn't really what we want.
<jml> yeah
<jml> fwiw, https://bugs.launchpad.net/testtools/+bug/686807 might be relevant
<ubot5> Ubuntu bug 686807 in testtools "Having __str__ not __repr__ as part of the matcher protocol is awkward" [Wishlist,Triaged]
 * mgz looks
<mgz> yeah, that change could probably just be made, the __str__ methods already return things that should work as object creation code, and str() falls back to repr()
<mgz> ids in reprs only matter when the object identity is significant, newer Python code tends to omit them from the repr string when the objects are interchangable
<mgz> repr(Exception("whatever")) has gone from '<exceptions.Exception instance at 0x00B097D8>' to "Exception('whatever',)"
<jml> cool
<jml> I might do that post release
<jml> (I want to have this assertThat bug fixed for the next release though)
<jml> I also just tried to reproduce the only remaining critical bug (https://bugs.launchpad.net/testtools/+bug/672056) and failed.
<ubot5> Ubuntu bug 672056 in testtools "UnicodeEncodeError: 'ascii' codec can't encode characters in position 2217-2258: ordinal not in range(128)" [Critical,Incomplete]
 * jml goes to make some dinner
<mgz> me too :)
<jml> <http://pypi.python.org/pypi/unicode-nazi>
<mgz> ^I have hope that the issues involved in that bug have been seperately resolved,
<jml> mgz: me too. I'm going to give Thomi a few days to reproduce the bug, and close it if he doesn't respond.
<matttbe> Hello jelmer.
<matttbe> micahg said to me that I've to chat with you about a bzr issue.
<matttbe> I used this command (I think but pretty sure, on natty but it was with another computer...)
<matttbe> bzr merge-upstream --version 2.1.1 --distribution=oneiric http://ftp.gnome.org/pub/GNOME/sources/latexila/2.1/latexila-2.1.1.tar.bz2
<matttbe> And it seems that if 'bzr bd' is used to create the source package, it creates a .tar.gz tarball from bzr instead of a .tar.bz2. So a problem to import the right package.
<micahg> merge proposal with branch here: https://code.launchpad.net/~latexila/ubuntu/oneiric/latexila/2.1.1/+merge/70964
<jelmer> sorry, was away for a bit
<jelmer> matttbe: thanks
<poolie> hi all
<jelmer> moinmoin
<poolie> hi mgz
<mgz> hey poolie!
<jimis> How can I switch branch on a lightweight checkout, but keep uncommitted changes in that branch for when I come back? The only way I've found is shelve everything, unshelve when I switch back...
<jimis> But can't I somehow tell switch to preserve local changes, and do it in one step?
<spiv> jimis: oh, you mean you want the uncommitted changes to be hidden until you switch back?
<spiv> jimis: shelving and unshelving is currently the best way to do what you want, I think.
<spiv> jimis: It would be fairly easily to write a switch-and-auto-shelve plugin to automate that, I think.
<spiv> (it'd override the 'switch' command to first shelve uncommitted changes to a shelf named after the current branch, do the switch, then unshelve from the shelf corresponding to the new branch)
<jimis> thanks spiv
<jimis> would be very useful as a switch option too
<jimis> --shelve for example
<spiv> jimis: hmm, could be.  File a bug asking for the feature :)
<spiv> jimis: (just paste in this IRC chat as the description if you want to be lazy)
<jimis> spiv: the reason it's important for changes to be hidden when switching, is avoid unwanted conflicts
<spiv> That said, a good way to prototype that feature would be to write the plugin :)
<jimis> I've had such conflicts before and it took lot of my time
<spiv> jimis: hmm, I think that's just as much an argument for a cheap way to undo the switch (and its conflicts)
<jimis> spiv: that's doable?
<jimis> it would be a live-savour, for *after* the conflict happened :-p
<spiv> jimis: or perhaps an argument for being able to shelve the original changes after the switch
<jimis> whatever
<spiv> (i.e. a way to say âplease shelf the unconflicted changes I had a moment agoâ)
<spiv> I think it's doable, I don't think it's *easy* currently.
<jimis> but after the conflict, you are left with various files injected with conflict marks etc... it's a mess
<spiv> Yeah, I know the feeling.
<jimis> yeah, that's why I think it's better to watch out during the switch
<spiv> And often you don't realise that conflicts are going to be messy until after you've got them.
<jimis> I'd personally advocate for shelving on switch always and transparently, and only taking changes with you if you provide a special flag to switch
<jimis> but I don't think current behaviour can be broken :-s
<spiv> A cheap-ish alternative might be an option on switch to abort (and undo) if there are going to be conflicts
<jimis> true
<spiv> And then you can either commit/shelve/revert/whatever, or you can pass a --force or --allow-conflicts switch to say âthat's ok, I'll copeâ
<jimis> Will submit feature request later, hopefully I'll find some time
<spiv> In fact, 'bzr merge' already behaves somewhat like that
<spiv> You have to --force for it to even start in the presence of uncommitted changes.
<jimis> I wonder why switch is that dangerous...
<spiv> (Although the rationale for merge doing that is not quite the same, there is some overlap)
<jimis> probably because most people work with multi-directory branches, not single-dir checkouts
<spiv> Yeah
<spiv> Although as bzr-colo becomes more popular (and is slowly integrated into the core), your workflow will be more common.
<jimis> but when you have huge projects with thousands of files, checkouts are one-way
<spiv> Right
<jimis> spiv: are you on the bzr team?
<jimis> Because I wonder if any dev agrees with my experience
<spiv> jimis: yes (was a fulltime developer working for Canonical until a couple of weeks ago, have just switched jobs but I still care and have commit rights etc)
<jimis> cool
<spiv> jimis: I'm pretty sure most, maybe all, the core devs agree with you that we should do better for that case
<spiv> And there's been serious talk about switching to single-dir checkouts as the default way of working in a future release (i.e. integrating and polishing the bzr-colo plugin into the core, and then promoting its workflow to be more prominent than the current multi-dirs of branches in shared repo model)
<jimis> very interesting
<spiv> Obviously we'd want to smooth out as many kinks as possible before doing that, including yours :)
<jimis> single-dir checkout of a no-trees branch is my current way
<jimis> It's the only usable way for huge branches like lp:gcc
<spiv> Right.
<jimis> but I've never used colo plugin
<jimis> generally I tend to avoid installing extras
<spiv> bzr-colo is basically intended to make that a bit nicer to use
<kwmiebach> Hi. I have used "bzr fetch ..." from a launchpad repository. How can I switch to an earlier revision locally?
<kwmiebach> Lets say I am aat rev. 500 now and would ike to see rev 450
<spiv> 'bzr pull -r 450 .'  (the dot is significant, it says to pull from the branch in the current directory, which will be a bit faster than looking for that same revision on the remote branch)
<spiv> Depending on what you want to do,
<spiv> 'bzr update', 'bzr revert', 'bzr cat', or 'bzr qlog' (that one from the qbzr plugin) may be better suited to your needs though.
<kwmiebach> spiv, thank you so much, couldnt find it in the docs.
<kwmiebach> i will go and try now
#bzr 2011-08-12
<kwmiebach> 'bzr pull -r 425 .'  resulted in 'No revisions to pull'. But rev 425 is in the log. Strange.
<kwmiebach> I come from git - it is so different
<kwmiebach> I think bzr revert changed something. But how can I find out if I am at the earlier reveision now? 'bzr log' still shows the latest revision as the first entry
<kwmiebach> spiv, thank you. i think i will do a new local branch, maybe it is possible to specify a revision umber
<kwmiebach> (I believe "revert" is doing what I want. But how can I proove the outcome?)
<kwmiebach> spiv, is there also a way to revert to a milestone?
<bignose> kwmiebach: is the milestone a tag?
<bignose> (and if not, why not?)
<bignose> kwmiebach: if so, ârevertâ takes the â--revisionâ option with all the usual revspec values
<bignose> so âbzr revert --revision tag:foomilestonetagâ
<kwmiebach> bignose, thank you. I am only making local copies of some launchpad repositories. Gonna try to see milestones as tags.
<kwmiebach> what if I tomorrow forget which revision I reverted to yesterday? is there a way to find out at which revision I am?
<jimis> kwmiebach: bzr info -v or some other flag possibly?
<kwmiebach> jimis, witth your help I checked the help for "bzr info" and it said "bzr revno" is what I needed. cool.
<kwmiebach> the fog is starting to clear now :)
<bignose> kwmiebach: what I meant was, if you have a milestone and you want to refer to it by name, that's what a tag is for.
<bignose> kwmiebach: what is a milestone to you?
<poolie> lifeless, spiv, hi
<lifeless> hiya
<poolie> can we chat briefly?
<kwmiebach> bignose, I find "milestones" on launchpad projects.
<lifeless> poolie: of course
<kwmiebach> bignose, for example the "do" project: https://launchpad.net/do there is a chart of "series and milestone" approx in the middle column (trunk, 0.8, 0.7, 0.6)
<spiv> kwmiebach: ah, sorry, I forgot to say --overwrite in the 'bzr pull' invocation
<spiv> kwmiebach: launchpad milestones don't necessarily correspond to any revision
<spiv> kwmiebach: (e.g. its common to have milestones for releases that aren't ready yet, and the milestone is used as a tool to track what's left to be done)
<spiv> kwmiebach: but it's common practice that people will add bzr tags when they make releases
<spiv> kwmiebach: e.g. 'bzr tags -d lp:do' reports tags like 0.8.0 and 0.8.5, so you can use e.g. '-r tag:0.8.5' to refer to those tagged revisions
<kwmiebach> spiv, I tried "bzr pull --overwrite -r 1234 ." now. It seems to work on the one hand I get a correct "bzr log" afterwards. But the "bzr pull ..." told  me many conflicts were intrioduced. Is that a normal thing?
<kwmiebach> How can pulling a different revision introduce a conflict?
<spiv> (It occurs to me it might be a nice feature if the launchpad page for a milestone linked to a revision tagged with the milestone name in the corresponding series branch, if that tag exists)
<spiv> kwmiebach: because the tree you were pulling in wasn't a pristine copy of the other revision
<spiv> kwmiebach: it might have had uncommitted changes, or unversioned files
<kwmiebach> spiv, what i did before was some "revert" commands
<kwmiebach> so i throw it away and create a clean local "bzr branch" again
<spiv> Right, if you revert to some revision other than the current revision for that tree, then you have uncommitted changes
<spiv> (as will be clear if you check the output of 'bzr st')
<spiv> kwmiebach: note that you can specify -r with 'bzr branch' too
<kwmiebach> cool
<spiv> kwmiebach: so you can just branch the revision you want directly, rather than branching the current tip then pulling the one you actually wanted.
<kwmiebach> is there a windows command line version of bazaar? I am actually using bazaar on cygwin, but I believe it is slow
<bignose> kwmiebach: there is, and I've used it a few years ago
<bignose> but it was painful. not Bazaar's fault, but Windows's.
<bignose> (might be better with a decent command shell, but that's what Cygwin is for.)
<kwmiebach> bignose, i undersstand. maybe i stay with cygwin-bazaar
<thomi> Does anyone know why __enter__ and __exit__ were removed from bzrlib.transform.TransformPreview with rev 5967?
<thomi> the commit message just says "Cleanups and fixes for merging into null tree. (Aaron Bentley)"
<thomi> bah - figured it out, was looking at the wrong branch :(
<jelmer> moinmoin
 * jelmer heads to a coworkspace, back in 30 min
<vila> moin
<poolie> hi vila
<vila> hey poolie
<vila> I see pqm is still going strong :)
<jelmer> whoa
<vila> I'm glad we do so many landings :)
<vila> <cough>
<vila> poolie: if the datasync stuff is involved in the pqm increased times, it doesn't show up on babune 'build time trends'
<vila> --parallel shouldn't be an explanation but using tmpfs for /tmp on the slaves may (I'm still not fully convinced though)
<vila> jelmer: about your unparsed-url mps
<vila> I'm wondering if we shouldn't take the opportunity to use URL objects as parameters instead of strings and keep the various representations available for the URL life cycle
<poolie> hi vila, jelmer
<vila> instead of converting back and forth between paths/urls/unicode/url-encoded and having these conversions occur everywhere
<jelmer> 'morning poolie
<vila> I'm not advocating for doing that everywhere either (and may be not *now* either)
<vila> but we've encountered so many related bugs...
<jelmer> vila: I wouldn't be opposed to that
<vila> this will also help clarify which parts of the API use which form of URLs (unicode is *not* 42 ;)
<jelmer> yeah, that's indeed a bit undefined at the moment
<jelmer> where some things are unicode paths, some things are utf8 paths, some things are urlencoded utf8 paths, ..
<vila> yeah, and dealing with strings means you lose the original form you may need at some later point
<jelmer> vila: for the moment, I'd like to focus on just getting colocated branch support finished
<vila> so the main idea would be that URL objects are immutable but can provide the various forms
<vila> jelmer: np
<vila> yeah, yeah, I certainly don't want to distract you (almost ;)
<vila> jelmer: oh, and thanks a ton for all the reviews !
<jelmer> vila: no problemo, I am after all patch pilot :)
<vila> mthaddon: I filed bug #825027 about the issue you encountered yesterday
<ubot5> Launchpad bug 825027 in Bazaar "create_safety_net is brittle" [Medium,Confirmed] https://launchpad.net/bugs/825027
<mthaddon> thx
<jelmer> vila: is that a blocker for the new PQM?
<vila> mthaddon: for my own enlightenment, what was the root cause here ? You can really get a chroot without the right users declared ?
<mthaddon> vila: we copied the chroot wholesale from the existing PQM instance, so the UIDs aren't matching up
<vila> jelmer: from the bzr pov, no, we can try working around the issue or at least provide a better feedback but given the pqm workflow, I'm not entirely sure we could have give mthaddon a timely and useful feedback :-/
<vila> mthaddon: wow, I see
<vila> automated deployments ftw ;)
<mthaddon> should be fixable on this end, of course :)
 * vila nods
<poolie> hi vila, would you like to talk?
<vila> poolie: sure
<vila> !
<lifeless> vila: so the failing test didn't output its exception ?
<poolie> actually i might put some dinner on, then can i call you at home?
<vila> lifeless: all failing tests did output their exceptions
<vila> lifeless: the issue is that they were hidden in a redirected file making it harder to understand what was going on
<vila> poolie: wfm
<lifeless> vila: why was the file redirected ?
<vila> lifeless: so it can be post-processed with subunit-stats, man, it's the bzr 'make check' remember ? ;)
<lifeless> vila: its been a bit :>
<lifeless> vila: why didn't pqm send the original stream out in its error mail? it normally does that ? [and extracts the failures itself]
<vila> lifeless: ctrl-alt-del
<lifeless> vila: ?!
<lifeless> sorry
<vila> lifeless: the context was mthaddon debugging the new pqm server, not the usual workflow
<lifeless> â¸
<lifeless> vila: so, I would close that bug invalid :>
<vila> lifeless: well, the subject says 'create_safety_net' is brittle, I use a 'medium' importance
<lifeless> sorry, I should be clearer
<lifeless> the 'hard to debug' aspect of it is unrelated to the way that test fails
<lifeless> it was due to how the test suite was run
<vila> I don't disagree :)
<lifeless> as I read the bug, the hard to diagnose part was the greater part of the problem :)
<vila> On the other hand, a failure at this point could have just *stopped* the test suite, there is no point in failing gracefully there
<lifeless> vila: or run with -1
<vila> lifeless: hmm, running with -1 was abandoned when subunit were used ;)
<lifeless> right, but as you said: this wasn't normal
<lifeless> this was debugging a new server
<vila> lifeless: then -1 is not available for 'make check', I indeed thought about defining a new make target for such cases though
<lifeless> vila: when would it be used?
<vila> but mainly, I agree with you, it has little to do for bzr itself
<vila> lifeless: when validating the selftest environment
<lifeless> vila: which is why if I was still active in bzr I would probably just close the bug invalid :)
<lifeless> vila: I would run ./bzr selftest -1 if I wanted to validate the environment :)
<lifeless> anyhow
<vila> lifeless: yup, I recommended something like that
<lifeless> it was just a cmment, if you want it open, its up to you :)
<lifeless> (IMO)
<vila> lifeless: thanks, I will add such a comment ;)
<ccxCZ> has anyone tried to integrate PQM with issue tracker? I'm currently looking at roundup and how it could handle 'bzr send' messages
<jelmer> ccxCZ: hi
<ccxCZ> hello :-)
<jelmer> ccxCZ, Integrate it in what way, automatically closing bug reports when the fix for that bug lands?
<ccxCZ> or close merge request when it's approved
<jelmer> ccxCZ: It should be possible to do that outside of PQM with just a script that watches the branch
<ccxCZ> I thought about workflow like this: someone bzr-sends me a patch, it goes into roundup as open issue and is forwarded to pqm, which replies with "all tests passed". I then reply via pgp-signed mail or via web interface and say "merge", which closes the issue and merges the branch
<jelmer> ccxCZ: pqm can only really handle merge commands, potentially requiring a testsuite to pass before accepting a merge command
<ccxCZ> okay, seemed to me that way. But what I described shouldn't be that hard to build, right?
<ccxCZ> anyway I kinda miss some documentation on how to handle bzr-send messages
<jelmer> ccxCZ: pqm doesn't handle messages sent with bzr send
<jelmer> ccxCZ, you seem to want a feedback step between having pqm run the tests and actually doing the merge, I don't think that's very easy with PQM at the moment
<ccxCZ> what does handle bzr-send messages? how can I inspect them / assign them to correct repo etc.
<jelmer> ccxCZ, "bzr pull" and "bzr merge" can handle the bundle files that "bzr send" attaches
<ccxCZ> how do I do that? I point it at mbox file instead of uri?
<jelmer> ccxCZ: "bzr send" attaches a file that you can point it at
<ccxCZ> I need to exctract the mime part then, right?
<jelmer> yep
<ccxCZ> hmm, maybe I'll try to involve buildbot then
<ccxCZ> or rather I'll write down usecases for such system first, would you mind writing me what you about it when I do?
<jelmer> ccxCZ: writing what?
<ccxCZ> nvm for now
<poolie> hi jelmer, can you have a go at the review queue today?
<jelmer> hi poolie
<jelmer> poolie: there doesn't seem to be much that needs review at the moment -  is there anything specific I should look at it?
<jelmer> nevermind, maybe I should switch back to ~bzr/+activereviews, ~bazaar+activereviews is too noisy
<thumper> can bzr have a global ignore list?
<jelmer> thumper, ~/.bazaar/ignore IIRC
<thumper> jelmer: ta
<Riddell> wow, PQM is slow
<vila> Riddell: hehe, welcome to the club :)
<vila> Riddell: so, yeah, very slow since ??? but a new server is in the works so the consensus is to wait for it and see if it's still slow and *then* investigate
<vila> Riddell: in other words: *now* is not the time to use pqm to check that the whole test suite pass ;)
<vila> Riddell: I may have an offer you can't resist to though...
<Riddell> vila: qu'est ce c'est?
<vila> Riddell: if you connect to babune once, I can add you to the testers group there so you get more rights to run the test suite on various platforms ;)
<vila> Riddell: for arbitrary branches that is
<Riddell> and then it wouldn't risk failing in PQM and taking another day to pass?
<vila> yup, that's the idea
<Riddell> how do I connect?
<vila> not fully guaranteed as I've seen cases where pqm were raising different failures, but pretty rare these days
<vila> Riddell: click the login button top right
<Riddell> top right of what?
<vila> Riddell: http://babune.ladeuil.net:24842/
<vila> Riddell: omg, you don't know where babune leave on the internet ? :D
<vila> lives
<vila> ruining joke tyops are baclk ;)
<vila> abck !
<vila> back !
<Riddell> me and babune have never been introduced
<Riddell> logged in
<vila> Riddell: meet babune: http://babune.ladeuil.net:24842/
<vila> babune: meet Riddell
<Riddell> bonjour babune
<babune> I'm a bot running the test suite for bzr on various platforms
<babune> You can look at the 'debug' tab to see various jobs which accept various parameters (including a branch) to run various subsets of the test suite
<babune> Riddell: you're now part of the testers group
<Riddell> thanks babune
<Riddell> so how do I test things?
<babune> Riddell: refreshing the page should reveal additional buttons including a clock with a green button to run a given job
<babune> s/button/arrow/
<Riddell> it does
<babune> Riddell: oh, you run the chroot-natty one ?
<babune> So, the 'Critical' and 'High' tabs are the "official" jobs and under normal circumstances are triggered automatically
<babune> Riddell: did you specify a different branch than lp:bzr ?
<Riddell> babune: yes I clicked on the chroot-natty clock icon
<babune> no, good, ho harm done then, perfect
<babune> Riddell: for your own branches, better look at the jobs in the 'debug' tab and yell or file bugs if they don't suit your needs
<vila> What a lovely bot...
<Riddell> how do I specify a different branch?
<vila> 3 min 23 sec, eat that pqm !
<vila> oooh, the 'Critical' jobs have no parameters, I see, try http://babune.ladeuil.net:24842/view/debug/job/selftest-subset-natty/build?delay=0sec
<vila> you'll get a page with the accepted parameters
<Riddell> ah hah
<Riddell> lovely
<vila> jelmer: bad target for your generate-revhistory proposal I suspect
<vila> Riddell: in other news, your submission just started on pqm ;)
<Riddell> --MARK--
<vila> :)
<jelmer> vila: any chance you can submit my fix for 2.4 to lp:bzr/2.4 ?
<vila> jelmer: sure thing
<fullermd> Aw, man, you want vila to make pqm work _harder_??
<vila> work pqm work !
<fullermd> Slavedriver   :(
<vila> That reminds me of lucid-emacs's whip sound :)
<vila> Yeah, I confess I've used lucid-emacs (later called xemacs) before seeing the true light of using GNU emacs
<vila> But RMS said it's ok now
<vila> ggggh
<vila> well done jelmer :)
<jelmer> vila: what did I do ? :)
<vila> tricked me into submitting your proposal before realizing two of mine have failed for conflicts :D
<jelmer> muhahaha >-)
<vila> hehe
<jelmer> (that was actually unintentional...)
<vila> yeah, they all say that...
<vila> jelmer: in fact, I'm more interested in merge 2.4 => trunk right now for babune's sake, so all is fine
<vila> since that means your equality_funcs.clear workaround should turn oneiric blue, finally
<mgz> hm, had I realised oneiric was really going to ship a non-release python version from a random hg checkpoint, I'd have proposed a branch just removing that code entirely
<mgz> it doesn't serve much purpose without the main chunk which has yet to land
<jelmer> I hadn't counted on that either
<jelmer> Perhaps we should've checked with doko
<vila> mgz, jelmer: yeah, worth checking, it would be surprising that python is not upgraded until oneiric is released
<vila> mgz: fixing the bug upstream was the right thing to do anyway, thanks again for that !
<Riddell> is there a bzr equivalent of "git rev-parse --show-prefix"? i.e. finding out where the current directory is relative to the top of the .bzr branch from the command line?
<vila> bzr root ?
<vila> ha no, you want the relpath from that... hmm, worth adding an option to the command...
<vila> Riddell: care to file a bug ?
<Riddell> mm, actually bzr root might be just what I wanted
<bignose> Riddell: branch_root=$(bzr root) ; echo ${PWD#${branch_root}/}
<Riddell> bash is such a messy language :)
<bignose> even better: echo ${PWD#$(bzr root)/}
<vila> why not just: 'bzr root' ?
<bignose> vila: because it's not what is being requested
<bignose> vila: see the difference between 'bzr root' and the shell code I gave
<vila> that's why I'm asking, trying both gives the same result here
<bignose> it should not.
<vila> ha right, different result when I'm not at the root
<bignose> ah okay, it would iff you are already at the root. hmm.
<fullermd> Doesn't work too well without bash either   ;p
 * bignose ignores systems without Bash :-)
<bignose> I'd be happy seeing a 'bzr relative-path [filename]' that does what Riddell is asking
<vila> yeah, that's why I ask RIddell to file a bug. Adding a --relpath to 'bzr root' would have my preference over a new command though
<fullermd> We almost have it, in bzr ls --from-root.  Except it refuses to take a path arg at the same time.
<bignose> I don't think it belongs on the 'bzr root' command, which has a different purpose.
<vila> Well 'Show the tree root directory' doesn't specify if the path is absolute or relative
<fullermd> But he doesn't want the tree root dir.  He wants to know where he is _relative_ to the tree root.
<bignose> vila: showing the *current* directory is not "show the root"
<fullermd> (of course, it has more to do with showing the root than with parsing a rev, but who expects sanity from git commands?  :p)
<vila> bigjools: ouch, you're right, sorry
<bignose> fullermd: exactly
<bigjools> vila: I am.  What was the question? :)
<vila> bigjools: I meant, sorry for the bad auto-completion ;)
<bignose> we don't have to make the same bad UI decisions as Git
<vila> bignose: ouch, you're right, sorry
<fullermd> Quite.  We're perfectly capable of inventing our own all-new bad UI decisions!
<bignose> :-)
<bignose> fullermd: I think Riddell's request is best met by an optional path argument to 'bzr ls --from-root'
<bignose> (since it already does the special case of "current directory" without any changes)
<bignose> and that's me out. g'night, all.
<fullermd> bzr ls already takes a path; it just refuses to take a path AND from-root.  Kinda squirrely-looking.  It also recurses when I specify '.' as the path, even without recursion, but that's another nit...
<fullermd> (though actually, I wish --from-root means to do the _ls_ from root, not show full paths...)
<vila> fullermd: you know you can add test scripts to your bug reports in a syntax very close to a shell script ;)
<fullermd> I write shell scripts to narrow down and reproduce the bug; they just get attached to the reports as a bonus because I've already written 'em  ;p
<vila> fullermd: I know ;)
<vila> but test scripts can be run repeatedly without removing the tmp test dir...
<fullermd> Oh, I just keep up-arrowing to "rm -rf foo ; ./whatever" when I'm working 'em up.
<vila> hehe
<fullermd> I guess that would be "C-x M-9 H-q C-Ã© F-17 M-r" for you?   :p
<vila> nope, M-p
<vila> And F- doesn't exist, you just made it up ;-P
<fullermd> What, you don't have Function keys?
<mgz> seventeen of them? :)
<fullermd> Well, if you're gonna use Emacs...
<mgz> I thought that just required four flavours of meta...
<vila> function keys are f1 f2 etc, capital has a meaning in shortcuts ;)
<vila> Escape Meta Alternate Control Shift, really that's not *that* hard to remember :D
<fullermd> You've never seen a keyboard with a Function key, that you chord with a number to put in Fwhatever?
<vila> foot keyboard ?
<fullermd> No, there are regular keyboards that have it.
<fullermd> As I recall, for one example, my PCjr had one.
<fullermd> (yeah, OK, get your laughing out of the way...)
<vila> ohhh, that reminds me of very old vt100 keyboards maybe
<fullermd> Hm.
 * fullermd goes to check in the closet.
<vila> rats, I can't do that
<vila> I mean, I have a closet of course but no keyboard old enough there ;)
<fullermd> The VT102 doesn't have any Function just, just PF 1-4.
<vila> the oldest may be one with those... DIN plugs ? (Round with 5 pins inside)
<fullermd> I've got a Liberty terminal that has F1-F16.
<fullermd> VT102 is 1/4" TRS.  Lot older than a DIN   :p
<vila> I've amac keyboard with f1->f15 volume-up/down/mute and eject !
<fullermd> That sounds like an AT-style.
<vila> yeah AT-style
<fullermd> Got a handful of those around.
<vila> so volumes and eject should be probably be configurable giving f1->f19, you lose !
<fullermd> Configurable?!  I thought you said "mac"   :p
<vila> plugged into an ubuntu system ;-D
<fullermd> Out of the frying pain, into the fire...
<vila> And wait ! The othe one has f1->f13 plus volumes and eject ! f1-f20 !!! mwhahahahaha
<vila> meh
<vila> f1->f*16*
<fullermd> IBM made some keyboards that went up to f24, I think.  Probably 80's.
<vila> did they run FreeBSD ?
<vila> :-D
<gour> is anyone familiar with both bzr-2.4 & hg-1.9 to tell how do they compare today?
<fullermd> Doubt it.  That would be pre-386, so pre-MMU, so any *nix just points and laughs.  Could probably hook the keyboard up to something current of course.
<vila> pre-MMU... painful memories
<jelmer> hah
<jelmer> pre-MMU! Finally somebody brings something up I remember :)
<fullermd> Long time ago.  So long you'd have to chase a far pointer to...
<vila> jelmer: \o/
<vila> fullermd: FAR pointer ? You *did* code on windows ???
<vila> or DOS for this era
<fullermd> Oh, no, you had to deal with memory models in DOS too...
<jelmer> Turbo C++, good memories :)
<fullermd> (though I'm sure there were SOME other platforms that were dumb enough to deal in segmented memory too)
<vila> never see any other...
<vila> I've dealt with really small processors and memory were you add to switch memory banks to do anything useful, but hey, that's what bare metal is about ;)
<jelmer> hah, finally some progress on colocated branches
<vila> some *more* progress you mean ? :-D
<fullermd> Well, now that we've established at least 16 F keys, we can colocate 4 bits of branches   :p
<vila> jam: I can't find a description of bzr.groupcompress.max_bytes_to_index, can you propose one ?
<jam> vila: doc/en/release-notes.txt "bzr.groupcompress.max_entries_per_source" it got renamed bytes which is the same value *16
<jam> so 'entries_per_source' = 65536 => max_bytes_to_index = 16*65536 = 1M
<vila> I meant a definition suitable for help
<vila> ha found it in delta.h
<gour> is it possible to see in log output whether some revision is gpg-signed?
<Riddell> gour: only in the latest versions
<gour> Riddell: 2.4:x?
<Riddell> gour: yes, since 2.4b5 New option ``--signatures`` for ``bzr log``
<gour> Riddell: that's cool and missing in hg
<Riddell> go me :)
<Riddell> also bazaar kde integration http://blogs.kde.org/node/4467
<gour> when is 2.4 scheduled?
 * gour is using xfce
<vila> 2.4.0 has been frozen, installers and packages are currently built
<gour> thumbs up
<gour> what would be the best way to mimic hg's 'named branches' concept which i like due to its simplicity? fossil has similar stuff
<gour> bummer...py-pyme port required for 2.4b5 fails to build :-/
<jonathanj> if i've got an existing branch (with history) but now i want to put that branch into another branch (one that encompasses a bigger project) how do i do that without losing my history?
<hikiko> hello! is there a way to change the last commit log?
<gour> hikiko: uncommit and re-commit?
<hikiko> uncommit does change the code?
<gour> hikiko: "Unlike revert, uncommit leaves the content of your working tree exactly as it is. Thatâs really handy if you make a commit and accidently provide the wrong error message. "
<hikiko> thank you :)
#bzr 2011-08-13
<jimis> Is there a way to apply to my current branch a specific change commited in another?
<jimis> Not a whole commit, just a hunk of it
<jimis> I did it manually, but I'm being curious
<jimis> I think git has the cherry-pick functionality for this purpose
<hno> Is it normal to get lots of "conversion error: The branch format Meta directory format 1 is already at the most recent format." during bzr upgrade?
<cheater__> hi!
<cheater__> i've found a fairly annoying bug in bzr, it has to do with it losing ownership data of files when i do bzr shelve
 * cheater__ wonders if there is a workaround other than resetting that over and over
<cheater__> i have isolated the reason for the bug
<cheater__> https://bugs.launchpad.net/bzr/+bug/825732
<ubot5> Error: ubuntu bug 825732 not found
<cheater__> ah yes, it's a security bug, it won't be accessible publicly
<cheater__> i'm not sure if i should make it public
<maxb> My inclination is that this is not a bug
<cheater__> how so? it clobbers ownership of the file
<cheater__> no other operations do that
<maxb> Simply that your expectations disagree with the design goals of most version control tools
<cheater__> it's not homogenous in its behavior
<cheater__> other operations do not do this
<cheater__> just shelve (that i know of)
<maxb> No, try bzr revert for example
<cheater__> hm
<cheater__> what others do that?
<cheater__> and which ones don't?
<maxb> pretty much anything that changes the file via the generic treetransform code
<cheater__> is there a reason to overwrite the file instead of updating it?
<cheater__> if not, maybe i can make a patch (if htat part is in python and not, say, C)
<maxb> Yes, bzr prepares all of the updates it is going to do within .bzr, and then moves files in and out to commit the result of the operation in a nearly atomic fashion
<cheater__> mhm
<cheater__> i understand that a rename is atomic while a write doesn't have to be
<cheater__> i wonder if there could be a plugin which takes note of the ownership, and chown's the files (and asks you to sudo if necessary)
<maxb> Not entirely impossible, I suppose, though it does sound like it would have to hook very deeply into the core. I doubt sufficient hooks are available now
<maxb> What is the use case?
<maxb> Software development certainly doesn't require anything like this
<cheater__> dev server, files are in the project folder of the user working on the code, server needs to access it therefore the files need its group
<maxb> Sounds like you should simply make use of the directory setgid bit and an appropriate umask
<cheater__> i know that setgid can be used, the problem wasn't with being able to do that, but instead with the fact that it was a surprising change
<cheater__> pretty much nothing i've done so far has behaved like this in bzr
<cheater__> or it did so in a way that wasn't visible
<maxb> Even a text editor which writes out the new version and renames it into place would behave in the same way
<cheater__> i've never come across a text editor that is broken in this way
<cheater__> hmm.. except one i've written myself
<cheater__> now that i think about it
<cheater__> but it was just a bash wrapper around cat, that doesn't matter
<cheater__> :)
<cheater__> s/matter/count
<cheater__> :)
<cheater__> well, thanks for the response maxb
<cheater__> are you on the bzr team by the way?
<OutOfControl> I get bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<cheater__> good to know.
<cheater__> lol
<cheater__> :)
<cheater__> maxb: in fact, setgid doesn't fix that.. the group is still getting clobbered
<maxb> I think the user would need to be a member of the group for that to work
<fullermd> The files are getting created (and thus getting their ownership set) in limbo somewhere, not in their final dir locations.
<cheater__> fullermd, yes
<cheater__> fullermd, maybe they could instead be copied to the limbo and then emptied as opposed to being just created in limbo
<maxb> cheater__: I'm confused. Why do you care so much about *retaining* ownership? Surely the ownership of newly created files matters just as much?
<cheater__> maxb, when you create new files you know that's a new object and you need to check on permissions
<cheater__> when you just modify files, you don't expect their metadata to slip out from under you
<tshirtman> hi there, i would like to automate bzr pull on a server with crontab, but i need it to stop asking my password of my ssh-key, is it mandatory to use the key to pull?
<AuroraBorealis> uhh
<AuroraBorealis> use a ssh key agent
<AuroraBorealis> like pageant (on windows) or something else (like gnome password manager)
<tshirtman> it's a debian server, i'm not the only one to use it
<tshirtman> i want to keep an up to date clone, and build the doc automaticaly here
<AuroraBorealis> if its over sftp or whatever then you will need the ssh key :3
<tshirtman> it was a bzr branch from launchpad (lp:ultimate-smash-friends)
<tshirtman> hm, i should re-branch with different params?
<AuroraBorealis> you should be able to do it anonmyously
<AuroraBorealis> if its public
<AuroraBorealis> and it will yell at you that you haven't identified but it should still do it
<tshirtman> so i have to unauthentify?
<AuroraBorealis> i dunno
<AuroraBorealis> maybe?
<tshirtman> i'll try that later
<AuroraBorealis> dunno how to get bzr to forget your login name
<maxb> Unnecessary, just branch from http://bazaar.launchpad.net/whatever
<vila> maxb: You know 2.4.0 has been frozen right ?
<vila> maxb: <cough>, I meant hello maxb, by the way you &
<maxb> I had not noticed that, thanks :-)
<vila> maxb: I was wondering if 2.4.0 should go into the beta ppa before the stable one or not at all...
<vila> somehow, I feel the beta ppa users expect 2.4b1... 2.4b5/2.4.0/2.5b1 but I may be wrong
<maxb> 2.4.0 into beta first, get it all promoted into proposed and then stable, and only then start to care about the 2.5 series, IMO
<vila> maxb: /me nods
<vila> maxb: care to reply to the freeze announcement to outline your expected roadmap ? I don't mean ETA, just steps, if only to get more testers at each step
<maxb> Hmm, I'm not seeing the annoucement
<in3xes> how do I launch bzr-gtk? I installed it from debian repos. bzr-gtk doesn't work
<in3xes> 'bzr-gtk' command is not working
<vila> on the bzr ml ? :-/
<jelmer> vila, hi
<vila> jelmer: me ?
<vila> :)
<jelmer> vila: hey!
<jelmer> vila: there doesn't seem to be a tag for 2.4.0
<vila> how did you know ? Freeze announce ?
<vila> WHAT ?
<jelmer> vila: Thanks for releasing 2.4.0 :)
<jelmer> vila: Yeah, just saw the release announcement :)
<vila> I sent the mail on Thursaday but it seems it get blocked for approval :-(
<jelmer> ah :-/
<vila> I subscribe from a news email but mailman didn't realize vila@ and vila+bzr@ are the same...
 * vila blinks
<vila> Where on internet went this flag...
<jelmer> vila: ah
<vila> ok, so, I tagged the right version locally (the tag is not there either) how to I propagate it now... A dummy commit and a pqm submission should do no ?
<vila> I took notes and the notes say I tagged...
<vila> jelmer: how urgent is that ?
<vila> jelmer: pkg-import will blow up ?
<jelmer> vila: it's not urgent, just nice to have this complete (and it means I have to specify the revision manually to 'bzr merge-upstream')
<vila> jelmer: ok, I'll submit to pqm anyway, do you need it on lp:bzr/2.4 or lp:bzr ?
<jelmer> vila: bzr/2.4
<vila> ok, it will propagate to lp:bzr later then
<vila> The weird thing is that poolie knew I did release on Thursday, so if he didn't see the mail nor the tag, how did he know ?
<fullermd> You talk in your sleep.
<vila> hehe
<vila> jelmer: submitted, 1e6 thanks for the heads-up
<jelmer> vila: thank you for adding the tag :)
 * jelmer uploads 2.4.0 to unstable
<jelmer> crap, 6 test failures :-/
<jelmer> vila, Yeah, definitely looks like it was your fix that broke config_dir() for me (though admittedly it was already inconsistent before that)
<vila> 6 test failures where ?
 * hno (or actually Fedora upstream monitoring tool) saw the 2.4.0 tarball on launchpad some day(s) ago.Packaged it for Fedora yesterday.
 * vila applause hno and thanks him
<vila> hno: would you mind replying to the freeze announce on the ml ?
<jelmer> vila: 6 test failures in 2.4 on oneiric
<vila> meh, context ?
<jelmer> vila: some are the testtools compatibility issues
<jelmer> and two are related to locks
<vila> argh, oneiric needs a new testtools ?
<vila> I thought your fix was to workaround that....
<jelmer> no, my fix isn't on 2.4 yet - I'm adding it to the package as a patch now
<jelmer> maybe we should backport it to 2.4
<vila> if you need to add it as a patch, we definitely need to backport it
<jelmer> yeah, that'd be nice
<hno> vila, I have not seen the announce message yet. But only subscribed to bazaar-announce and bzr-packagers.
<vila> hno: bah, I *really* should CC bzr-packagers :-/
<hno> that list should have some better visibility in general as well.. not sure how to find it's existence.
<hno> but yes, it would be great if freeze announses were cc bzr-packagers as it's a heads up to prepare packaging for the next release.
<jelmer> vila: http://pastebin.ubuntu.com/665251/
<vila> hno: releasing.txt updated in that regard
<vila> jelmer: no idea :-/
<vila> and I really need to sleep :-/
<jelmer> vila: no hurry :)
<jelmer> vila: bonne nuit
<jelmer> vous parler de lundi
<jelmer> (or something close to that :)
<vila> jelmer: the only thing that comes to mind is that it's related to the recent poolie change to break dead locks so *may* also be impacted by an unknown bug in config (including some config_dir, though I can't see where in this case)
<jelmer> vila: thanks, I'll have a look
<jelmer> vila: nevermind, I found it
<jelmer> vila: the problem is that my hostname is 'localhost'
<fullermd> Oh cool, I'm not the only one whose hostname breaks tests then  ;p
<gour> fullermd: thank you for 2.4 port...however, i've problem...bzr verify-signatures fails with 'bzr: ERROR: python-gpgme is not installed, it is needed to verify signatures' and i cannot build py-pyme :-/
<jelmer> fullermd: :)
<fullermd> Mmm.  I don't know anything about pyme.  What's wrong with the build?
<jelmer> fullermd, gour: note that bzr doesn't use pyme but python-gpgme
<gour> jelmer: hmm...why that message then?
<fullermd> The message that says 'python-gpgme'?  ;)
<gour> jelmer: dec for py-pyme port says: Python interface to GPGME library
<gour> *description
<fullermd> According to the plist, it's all under pyme, so it seems likely to be something different.
<jelmer> gour: there are multiple python bindings for gpg
<gour> in any case, bzr-2.4 port does not work :-)
<fullermd> Sure it does.  Just verify-signatures doesn't   ;)
<fullermd> The port by itself won't run selftest either; you'd have to install testtools for that.
<gour> he he
<fullermd> I think if there were a py-gpgme port (there doesn't appear to be), I would be inclined to not stick it in the depends list either; pulls in a lot of extra stuff, for a currently-niche feature.
<gour> hmmm...one can do similar thing in hg with simple extension...it would be bad to limit bzr
<fullermd> Oh, I wouldn't be averse to an OPTIONS entry; that would be sensible.  And if signing ever becomes common in the community, defaulting it on would make more sense.  But grabbing all the stuff that would be in the dep chain is a little hefty to want to make it unconditional.
<gour> i'm ok with option
<fullermd> But first someone would have to knock up py-gpgme   ;)
<gour> this is one of the release sections - Digital Signature Verification
<gour> now it's too late here...i was away whole day...se you tomorrow
<dvheumen> hi, I'm casually reading through the source code at the moment, trying to get a good grasp of the code and structure. Now I've encountered some abbreviation a few times that I don't know: e.g. in revisionspec.py, they use 'dwim'. What is 'dwim'?
<fullermd> Do What I Mean
<dvheumen> ah okay, didn't expect that one :) thanks!
<fullermd> (The only opcode needed by the perfect computer   ;)
<dvheumen> yeah, wish it was available already ;)
<dvheumen> I didn't know that diwm was actually used in source code :P so I didn't expect it :P
<fullermd> Only cool source code uses it.
<dvheumen> hmm... I'm honored, I'm ready a cool source then :)
<bignose> lies! I've written very un-cool code referring to DWIM.
<dvheumen> bignose: so did maybe your DWIM was malfunctioning?
<dvheumen> (* -did)
<fullermd> Or maybe it was functioning correctly, and he _meant_ it to be uncool.
<fullermd> (and functioned doubly-properly, in preventing the infinite loop of contradictions of being uncool, too!  Why, that's the coolest thing ever!)
<dvheumen> well, in that case it worked perfectly :)
<dvheumen> hmmm... I'm a bit confused, but I'm not sure where to find this. Bazaar also stores rwx access modifiers right? (or only some of them?)
<fullermd> Only x
<dvheumen> so, it stores executability for files *and* directories?
<fullermd> Not much point in having a -x directory   ;p
<dvheumen> okay, so that explains :) ... the code said that everything but 'file' was not executable ... I was wondering about that :)
<dvheumen> thanks :)
<dvheumen> (b.t.w, it depends on whether you store group information right, we could be storing not executable for group' and it would not be completely meaningless)
<dvheumen> :P
<RenatoSilva> verterok: hi
<pathogenic> hi
<pathogenic> how does Bazaar compare to something like Mercurial or git
#bzr 2011-08-14
<Riddell> pathogenic: Bazaar rocks of course
<pathogenic> is it distributed?
<Riddell> Bazaar users are better looking and more attractive to the opposite sex than git or Mercurial users
<Riddell> yes it's distributed, but you can also do a checkout similar to subversion so you have a choice of workflows
<pathogenic> do they drive Ferraris too?
<fullermd> I hope not.  It's hard to toss a couch in the back of a Ferrari...
<Riddell> no, we're environmentally friendly and cycle
<pathogenic> so what can i do in bzr that i can't in hg?
<pathogenic> what are bzr braches like?
<pathogenic> branches
<pathogenic> ?
<pathogenic> can you use git-diff format in bzr?
<pathogenic> hello?
<pathogenic> are you folks scared to answer?
<fullermd> I don't know of any concise answer to that sort of question, and work doesn't really leave me time for open-ended discussions...
<pathogenic> translation:  i'm afraid to answer, because any answer involves either lying or pointing out how hg is actually better
<fullermd> Oh darn, you broke the code.
<jimis> pathogenic: google is your friend
<jimis> pathogenic: but since you won't, here is the result: http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html
<pathogenic> i already read that, jimism
<jimis> pathogenic: do your homework, try various things, and come ask us specific technical questions
<jimis> pathogenic: do you really expect us to write an essay and list all reasons we prefer bazaar?
<pathogenic> i asked some questions
<pathogenic> it's a chat room
<pathogenic> jimis:  if someone came into #mercurial, i could tell them all about it
<pathogenic> i wouldn't be some stuck-up twat
<bignose> pathogenic: you started out hostile, please don't demand answers to loaded questions.
<pathogenic> i guess you folks are clueless
<bignose> yep, that must be it. you'd better find some people more suited to your needs.
<pathogenic> you've probably never even tried hg
<bignose> pathogenic: see? you don't need us, you already know everything you need to know.
<jimis> I agree
<jimis> I think hg is better suited to your needs, pathogenic
<jimis> now go
<jimis> :-)
<pathogenic> make me
<bignose> ah, so you're not here for information, buit to squat
<pathogenic> you go
<pathogenic> bignose:  leave
<jimis> Cool, I needed a break from work
<pathogenic> hg has far more users anyway
<pathogenic> bzr has little support on various sites
<aminpy> http://dpaste.com/593859/plain/ <- how can I fix this?
<bignose> aminpy: the informative part is â[Errno 111] Connection refusedxmlrpc.launchpad.net:443â
<bignose> aminpy: the informative part is â[Errno 111] Connection refusedâ while it tried to connect to âxmlrpc.launchpad.net:443â
<bignose> aminpy: so you'd best see why that connection is refused. either that host, or something between you and the host, is refusing that connection.
<bignose> I have no trouble establishing that connection directly (using âtelnet xmlrpc.launchpad.net 443â)
<cheater_> hey guys
<cheater_> if i have an up to date checkout of a bzr repo, and no one's working in branches or anything like that, then i can use that checkout to re-create the repo, right?
<bignose> cheater_: you don't have a checkout of a repo
<bignose> cheater_: you have a branch
<cheater_> ok
<bignose> cheater_: the concepts ârepositoryâ, âbranchâ, âtreeâ are all distinct in Bazaar
<bignose> cheater_: am I telling you something new to you?
<cheater_> yes
<bignose> okay. a repository stores revision data
<bignose> a branch is a record of the distinct line of development; it refers to revisions, so is specific to a repository
<bignose> a tree is the state of files that result from applying all the revisions of a branch
<cheater_> gotcha
<bignose> cheater_: so does that help you to re-phrase your question?
<cheater_> not necessarily. i have a bzr repo on a server, and i did bzr co on my local computer. i'm wondering if i can just get rid of the server it's on, or if i need to back up the repository.
<bignose> cheater_: if you actually have the repository locally, you have all the data you need
<cheater_> i don't know. do i have the repository locally?
<cheater_> how can i check?
<bignose> cheater_: one way to tell is to branch from there to somewhere else (make sure it's in a separate location so you're not accidentally using the same repository)
<cheater_> how would i do that?
<bignose> cheater_: another way is to use âbzr infoâ on the branch
<bignose> cheater_: which will tell you what kind of branch it is, and where its repository lies
<AuroraBorealis> if you only have one branch then doing a bzr branch on that will mirror it. but if you have more you would have ot branch all of them
<cheater_> no i just have the, uh, "default" branch or something like that.
<cheater_> sorry, i'm not too versed in the bzr data structure.
<bignose> cheater_: it's okay, you don't need to know much of the structure
<bignose> (one of the key advantages of Bazaar in my opinion)
<AuroraBorealis> if you just have one branch then doing a bzr branch will mirror it.
<cheater_> bzr info on my local computer says:  checkout of branch: bzr+ssh://login@server.com/srv/bzr/project/
<bignose> but the flexibility of Bazaar does unfortunately require knowing that those separate concepts are indeed distinct
<bignose> cheater_: that means the repository to which you commit is at that location
<AuroraBorealis> you need to branch it, not do a checkout
<bignose> cheater_: the purpose of a checkout is to emulate the centralised workflow
<cheater_> ok.
<cheater_> perfect, let me do a branch.
<bignose> cheater_: if you want to be actually distributed-only, don't use checkout
<cheater_> well.. in fact it's only just me using this.
<cheater_> i'm a one-man act :)
<bignose> cheater_: that's fine, I use both distributed and centralised on branches which are just me
<bignose> cheater_: it's great to have the opiton of both, and even both at the same time
<cheater_> yeah
<cheater_> i've never *really* used bzr in distributed mode..
<bignose> you don't need multi-person to get great benefit from distributed VCS
<bignose> nor centralised, I guess
<cheater_> i've used hg once branching out something and then using bitbucket's pull request feature
<cheater_> but they handle all of that through a web gui
<cheater_> so now i gotta learn how to do it per hand in bzr :)
<cheater_> per/by
<bignose> cheater_: you just âbzr branchâ without making it a checkout, without making it bound, without making it lightweight... basically just the default :-)
<cheater_> yeah, doing that
<cheater_> but let's say i did some work on the branch, how do i merge it back into the main repo?
<cheater_> something like bzr push, right?
<cheater_> just guessing here
<bignose> Bazaar defaults to plain old distributed. but doesn't prevent other workflows at any future time.
<AuroraBorealis> so if you just do a branch
<bignose> cheater_: well which is it, you want to remove the other repository or not?
<AuroraBorealis> then its not 'bound' to anything. it will just commit to your local copy
<AuroraBorealis> but you can 'bind' it so that when you commit it will commit to both your local copy and your copy on the server or something
<bignose> cheater_: use âpushâ and/or âpullâ to maintain a mirror.
<AuroraBorealis> or if you don't want to do that, you can either do push (which will make the repo a mirror) or a merge which will merge the repo's branch with yours
<bignose> cheater_: once branches diverge, they're no longer mirrors; that's when you use âmergeâ to reconcile them.
<cheater_> AuroraBorealis, what about committing locally, but then at some point specifically saying "ok, take all the changes i've doneo ver the last few commits since branching, and put them in where i branched out from"
<AuroraBorealis> haha
<bignose> cheater_: first, please confirm whether or not you want the remote repository deleted, like you originally said
<AuroraBorealis> well, you can either bind the branch, and do 'local commits'
<AuroraBorealis> or you can leave it unbound and then commit locally then push or merge the branch'
<cheater_> bignose, actually i do, but right now i'm playing with the (unrelated) idea of distributed work with bzr, since you guys sell it so well.
<cheater_> just getting some info, that's all.
<bignose> cheater_: okay. you have a checkout from a remote location
<cheater_> :)
<bignose> cheater_: so, when you commit, the revision data goes first to the remote branch and then to the local one, automatically.
<bignose> cheater_: that's how Bazaar emulates a centralised workflow
<bignose> cheater_: if you want temporary disconnected operation on the local branch, do one of two things:
<bignose> cheater_: âbzr commit --localâ to do it just for the one commit
<bignose> cheater_: or turn the binding off with âbzr unbindâ, do your disconnected commits for a while, then turn back on the binding with âbzr bind REMOTE_URLâ
<bignose> cheater_: <URL:http://doc.bazaar.canonical.com/explorer/en/guide/core_concepts.html> is essential reading for you now you're askign these questions
<cheater_> cool!
<bignose> cheater_: and <URL:http://doc.bazaar.canonical.com/latest/en/user-guide/using_checkouts.html> for switching between distributed and centralised
<bignose> cheater_: after reading those, explore the rest of the Bazaar documentation as your interest takes you. it's pretty good.
<cheater_> :)
<cheater_> i've noticed the bzr community is fairly supportive, i like that
<bignose> like with PYthon, it helps that the system is *very* well designed and hence easy to teach
<cheater_> yeah, in fact i'm sort of trying to push that sort of thing in the haskell community, i think it's lacking in that regard
<cheater_> ok so.. how can i merge the parent branch with the one i'm in, so that the merged result is in the parent branch?
<bignose> cheater_: I gave up very quickly on Haskell when I found that camelCaseNames are endemic through the library and community :-(
<cheater_> it could've been worse, at least no braces
<bignose> heh
<cheater_> haha
<bignose> cheater_: so first of all the terminology is wrong there
<cheater_> ok so i've done a local branch, did a checkout of that, and added a file which i then committed to my local branch.
<bignose> cheater_: you âmerge branch BAR into FOOâ, in order to get all the revisions from BAR to appear in FOO. FOO remains unaffected.
<AuroraBorealis> camel case isn't that bad o.o
<cheater_> now i want that file to show up in the parent that i branched out of.
<cheater_> AuroraBorealis, your nick tells us you're a proponent..
<cheater_> i'd say you're not objective on that matter ;-)
<bignose> cheater_: no AuroraBorealis has a TitleCaseName, which is fine by me
<bignose> cheater_: it's camelCaseNames that are inconsistent and ugly and stupid
<cheater_> i know, j/k
<AuroraBorealis> eh, its up to someone's opinion =)
<AuroraBorealis> i guess i'm used to it because of java.
<bignose> AuroraBorealis: that may be a reason why I'm emotionally against it :-)
<AuroraBorealis> =P
<bignose> cheater_: so, if you could name these branches, that would help us talking about them.
<cheater_> ok let's call the server branch "server" and the local branch "local"
<cheater_> :p
<AuroraBorealis> what, you don't like classes like these? http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html
<bignose> cheater_: better to name them for the purposes.
<cheater_> that is their purpose. i've only done this to test how branches work.
<bignose> cheater_: perhaps one is âtrunkâ and you branched for the purpose of a âfeature-fooâ?
<bignose> cheater_: any objection to that for the sake of discussion?
<cheater_> nah that's fine too
<cheater_> :)
<bignose> okay. so the implications of those names is that âtrunkâ will eventually get all the revisions that we want to keep, and âfeature-fooâ is limited in span and focussed on one area of work
<cheater_> yes
<bignose> so you might merge from âtrunkâ into âfeature-fooâ if âtrunkâ has gained a bunch of changes that you want to get up to date with on your ongoing work on feature Foo
<bignose> alternatively, you might merge from âfeature-fooâ into âtrunkâ if your work on feature Foo has reached a point that it's worth making part of the main line of development
<bignose> cheater_: so what's the case in this instance?
<cheater_>  yes, i want to merge from "feature-foo" to "trunk"
<bignose> cheater_: okay. a merge is always done into the current branch.
<cheater_> i know how to merge from "trunk" to "feature-foo", i just go to the feature-foo directory and do bzr merge
<cheater_> ok
<cheater_> however, my feature-foo is located behind a firewall
<cheater_> so i'd somehow need to initiate the connection from here
<bignose> cheater_: if the branch doesn't have a remembered location to merge from (it's âparentâ, I think; that might have changed recently)
<cheater_> yes, it's "parent"
<bignose> cheater_: then you specify the branch to merge from on the âbzr mergeâ command line.
<cheater_> ok
<cheater_> how do i go about fixing my firewall problem?
<bignose> cheater_: the concept there is that âfeature-fooâ should ideally keep getting changes from upstream, i.e. changes perhaps made on other branches that themselves got merged into trunk earlier
<cheater_> yeah
<bignose> cheater_: and you choose when that happens by merging explicitly, but the default place to merge from is its parent.
<bignose> cheater_: whereas âtrunkâ shouldn't necessarily have any parent; there is no good default palce to merge from, so you specify each time you merge into trunk.
<bignose> cheater_: what firewall problem?
<bignose> need to be AFK for dinner now. I leave you in the tender care of the other channel denizens.
<cheater_> :)
<cheater_> thanks a lot for the help
<cheater_> enjoy your dinner..
<lifeless> jelmer: is https://bugs.launchpad.net/launchpad/+bug/826082 got any chance of being a regression from your refactoring ?
<ubot5> Ubuntu bug 826082 in Launchpad itself "BadUrl from safe_open opening a branch" [Critical,Triaged]
<jelmer> lifeless, looking
<lifeless> jelmer: thanks!
<jelmer> lifeless: hmm, it indeed seems like it would be related. The problem isn't obvious to me though, and unreproducible (at the moment).
<lifeless> so far only one occurence
<lifeless> but its a little concerning ;)
<jelmer> lifeless: yeah
<thomi> Hi, is there a safe way to delete a branch from disk on a bzr repo server? I mean, what if someone's half way through read/writing it?
<lifeless> so for a read, they will get an error
<lifeless> for a write, their repository transaction will complete ok but then the change to the branch pointer will error
<lifeless> neither case should lead to repository corruption
#bzr 2012-08-06
<HeLLboY`> GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA
<misseru> GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA
<liviu32> GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA
<toate> GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA
<SSE4U> GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA
<Dj-Tresor> GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA
<Netriderz> GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA
<simmy> GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA
<mirela_^^> GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA
<HA9000> GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA GNAA
<mgz> morning
<vila> mgz: yo !
<mgz> :)
<vila> mgz: network is capricious around here but I seem to maintain a connection nevertheless ;)
<gmarkall> I just ran commit and uncommit as follows: http://paste.ubuntu.com/1132925/ - is the assertion failure anything to panic about?
<vila> gmarkall: no. That's bzr-gtk (probably saving some data in its uncommit hook) but may indicate that you need to upgrade it...
<gmarkall> vila: many thanks!
<veebers> Hi all, is there a way for me to commit only part of a change to a single file?
<Peng> There used to be an "interactive" plugin. I dunno about now.
<veebers> Peng: cool, will look into that
<veebers> otherwise I'll use some combination of shelve, diff and manually doing it :)
#bzr 2012-08-07
<bob2> <3 git's index
<michaelh> Hey, I'm getting a zlib integrity check error while doing a bzr export.  Should two packs with the same name have the same content?
<michaelh> Huh, the pack name seems to be the md5sum of the file...
<spiv> michaelh: right
<michaelh> Two machines, one pack file, and they differ in one byte part way through.  I'm assuming dodgy host.
<spiv> michaelh: so md5sum of the file is a good quick check for corruption that's happened after the pack was generated.
<spiv> michaelh: that sounds most likely to me too
<michaelh> It's strange as the problem happened yesterday as well.  A nuke, re-fetch was OK but failed again today
<michaelh> (which also sounds like a dodgy host)
<spiv> Agreed.
<michaelh> Once a pack has been fetched, does it ever change?
<lifeless> no
<lifeless> write once
<michaelh> (ah, but it can't as contents==md5sum)
<lifeless> very hard to have bugs that way
<lifeless> we compact multiple packs together from time to time to amortize the time/space tradeoff
<michaelh> Hmm.  I'll keep an eye on it.
<lifeless> but all reads get the zlib extraction and validation done, and then recompressed into the new pack, so hard for things to slip through there as well
<jono> hey folks
<jono> can nayone help me fix this error I get when pushing:
<jono> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~jonobacon/ubuntu-accomplishments-system/adminportal/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
<spiv> jono: "bzr lp-login && bzr push --overwrite lp:~jonobacon/ubuntu-accomplishments-system/adminportal"
<jono> thanks spiv
<mgz> morning!
<jelmer> moin
<mgz> hey jelmer
<jam> jelmer: see you in mumble in a bit?
<Marqin> hi
<Marqin> where to find in .bzr files Changelog?
<arand> I've: branched lp:ubuntu/precise/redeclipse; added a commit with a patch (committed applied as per the repo setup from original Debian import); branched lp:ubuntu/redeclipse; tried to (fast-forward) merge the former into the latter:
<arand> Then I get this error: bzr: ERROR: Unable to unapply quilt patches for 'other' tree: rmdir: failed to remove `.pc/security-text-command-fix.patch': No such file or directory
<arand> Likewise when I do a --pull merge and then try to use "bzr up"
<wgz> arand: you might want to post to ubuntu-distributed-devel@lists.ubuntu.com for help with bzr-builddeb things
<arand> well, the command itself if just a plain merge, does bzr detect that it is packaging in the repos and add some bzr-bs vodoo on top?
<wgz> no.
<wgz> if you're using the bzr-builddeb plugin on packaging branches it adds some fancy stuff to merge
<wgz> see that plugin's documentation for how to configure it.
<mgrandi> question, does anyone know how to change the name that bazaar explorer shows for a branch?
<mgrandi> cause having a bunch of trunk->trunk names doesn't help
<wgz> `bzr nick whatever-you-like`
<mgrandi> that doesn't seem to do anything to bzr explorer
<wgz> hm. it might be resolutely using folder names instead.
<mgrandi> ill add that to the list of bug reports haha
<mgrandi> also, on my todo list for today is to finally file the bug report against yui, do i link that to any lp bug?
<wgz> yeah... what was it again.
<mgrandi> opera failing on urls and giving like launchpad.net/bugs/null
<wgz> bug 897277
<ubot5`> Launchpad bug 897277 in Launchpad itself "Going to +bugs results in incorrect URL location" [Low,Triaged] https://launchpad.net/bugs/897277
<mgrandi> ok i'll link it there
<mgrandi> or maybe i'll fix it myself since i semi know pyqt4!
<mgrandi> is there a special way to link that? i see a RDF metadata thingy, but im not sure how to link other bug trackers
<wgz> you can set a url on https://bugs.launchpad.net/yui/+bug/897277/+editstatus but yui uses a weird tracker so I'm not sure that'll work nicely
<ubot5`> Ubuntu bug 897277 in Launchpad itself "Going to +bugs results in incorrect URL location" [Low,Triaged]
<mgrandi> ok
<quotemstr> Can I change a branch's URL?
<quotemstr> I have a read-only branch and I'd like to change its URL so I can push to it.
<wgz> ...yes? though I don't really understand what you're trying to do
<wgz> I mean, mv changes a branch's URL, but doesn't make it writable
<quotemstr> I have a clone of a branch from Savannah. It's a bzr:// URL.
<quotemstr> I'd like to start using bzr+ssh:// without pulling down the entire branch again.
<wgz> bzr pull --remember bzr+ssh://
<wgz> (and the rest of the location)
<quotemstr> Ah, okay.
<quotemstr> Thanks.
<wgz> push --remember too, though if it was read-only before you've probably not pushed previously
#bzr 2012-08-08
<mgz> morning
<vila> hi
<vila> james_w: ping, around ?
<james_w> vila, yep
<vila> james_w: I'd like to have a ppa on ~udd to replace ~vila/+archive/pkgimport but I'm not an udd admin :)
<james_w> vila, you are now
<vila> thanks
<vila> james_w: wow, and jam too, you're reading my mind or was that from someone else ?
<james_w> vila, i saw your comment elsechannel
<vila> you rock ;)
<hallyn> hi - when i do 'bzr merge someothertree' it quilt pops all patches.  then doesn't re-push them.  is there any reason not to simply quilt push -a again before checking in?
<hallyn> (i was surprised it didn't do it autmoatcially, figured ther emight be a reason :)
<weigon> I'm trying to find a (performant) way to find all the heads in a repo. I'm actually looking for loose ends after a "uncommit" or "pull --overwrite"
<weigon> I went with repo.get_graph().heads(repo.all_revisions()) ... but that takes quite some time to complete
<jelmer> weigon: there is something slightly faster I think
<weigon> jelmer: I wonder how the revisions are indexed and if that can be utilized
<jelmer> weigon: any access to the revision graph should already use just the indexes afaik
<weigon> jelmer: any idea how to speed it up?
<jelmer> weigon: check out what 'bzr heads' does
<weigon> jelmer: *doh* it is all there ...
<weigon> jelmer: thx
<jelmer> maxb: you're still occasionally contributing to the bzr package, should I consider you one of its maintainers?
<jimis> Can I convert a branch of an lp:project in a local repo, to a stacked one so I can save space, but without re-branching?
<thumper> are you using shared repositories?
<jimis> thumper: I think so, yes
<jimis> you mean if the branch is in a directory where init-repo has run?
<jimis> if so then yes
<thumper> then stacking will make no difference at all
<thumper> as it is already sharing revisions
<jimis> thumper: as it is now I have locally all metadata from the lp:project, which is too much
<jimis> by converting to stacked I was hoping to rid this space and have only local changes
<jimis> local branches etc
<thumper> you really don't want to stack on a remote branch
<thumper> ever
<jimis> I know, bad past experience :-)
<jimis> so it's not possible
<jimis> ?
<thumper> oh  it is possible, but every action will include network which will be very slow
<thumper> lifeless: care to comment?
<jimis> thumper: I hope I'll not do *any* action after converting to stacked. My plan is to do it in a dup copy of the original repo: 1)convert to stacked 2)back it up 3)rm -rf stacked-repo   :-)
<jimis> anyway just playing here to find the best backup method, I'll let you know after experimenting :-)
<thumper> jimis: how about push to launchpad?
<thumper> that is a pretty good backup
<thumper> and saves you 100% disk space
<jimis> thumper: I push what I want to be seen, but too many junk branches I don't want to push
 * thumper shrugs
<thumper> ok
<lifeless> jimis: it will performance very poorly.
<lifeless> jimis: whats the actual problem you are trying to solve ?
<jimis> launchpad answer 205318
<jimis> https://answers.launchpad.net/bzr/+question/205318
<jimis> just trying various ways other then the obvious, to incrementally backup everything.
<jimis> lifeless: Ideally when I'll have to restore from backup, I'll be able to re-convert to non-stacked.
<jimis> this will possibly be slow but it will only happen once, hopefully never :-p
<lifeless> jimis: I think you have a flawed model about how stacked works.
<lifeless> jimis: if you want to run efficient backups of the whole repo to another site, push the whole repo there; a small python script can push all the heads in one network transaction.
<lifeless> something like bzrlib.repository.Repository.open('remotepath').fetch(bzrlib.repository.Repository.open('localpath'))
<lifeless> stacking won't give you the ability to restore reliably, because one missing revision can render a branch unusable; and it will incur a per-branch overhead of 10 or so network round trips.
<lifeless> you can seed the back up repository by cloning lp:gcc from Launchpad directly to your backup server.
<jimis> ah that would be ideal
<lifeless> if you have 400MB of local branch commits, I'd be amazed. I suspect you actually have 20 or 30MB tops
<lifeless> its just not compacted.
<jimis> even less probably of raw text data, that's why I was hoping to generate minimum traffic
<lifeless> bzr will be reasonably efficient at incremental backups.
<lifeless> What I'm describing will get all the revisions
<lifeless> you can use your rsync of the per-branch directories to grab them and their metadata.
<jimis> so I'll clone lp:gcc on my backup server, and then only rsync my branch subdirs, ignoring root .bzr.
<jimis> Right?
#bzr 2012-08-09
<lifeless> yah
<lifeless> into a shared repository
<lifeless> and ues the python fragment I sketched to sync the repository data
<jimis> lifeless: can it be done with a bzr shell command?
<lifeless> no
<lifeless> its using the plumbing
<jimis> also do I have to periodically resync the backup-server repo with lp:gcc, or will all data (even public data on lp:gcc) be pushed when backing up?
<lifeless> jimis: everything you have locally that isn't in the backup server will be copied
<jimis> alright, thanks for helping lifeless
<AfC> Not really a bzr builddeb question, but if I need to do
<AfC> $ DEB_BUILD_OPTIONS=nocheck bzr builddeb -S
<AfC> will the resultant source package, sent to launchpad, be configured to skip the tests?
<AfC> Obviously it works locally, but I'm not really expecting it to propagate. Does it?
<AfC> [Otherwise, I'll have to patch the tests out of the debian/rules file, which seems sub-optimal]
<AfC> Well, doesn't seem to propagate, as expected. Ripping tests out of debian/rules instead.
<mgz> morning all!
<vila> hi all ! (including mgz ;)
<mgz> hey vila
<vila> mgz: I addressed your remark on the TestInTempDir proposal, would you mind re-review (just look at the added revs rather than the whole diff though). Also, if you could share your thoughts about the shared stores one, that would be awesome !
<mgz> yeah, just looking at that now
<vila> cool
<mgz> hm, is the TestActivityMixin code right?
<mgz> can't see from the diff
<mgz> but calling both super...setUp and TestActivityMixin.setUp seems off
<mgz> the new style is just to call super from all methods, no?
<mgz> but I guess there being no object.setUp messes with that...
<mgz> it's a painful way of spelling that bit of code
<vila> right, there are two additional changes summarized by the commit messages,
<mgz> okay, yup, seems to make sense
<vila> 6555 stop relying on base classes deriving from TestCase http://bazaar.launchpad.net/~vila/bzr/thou-shall-use-testcaseintempdir/revision/6554
<mgz> mp is already approved
<vila> and then, always calling super() instead of mentioning the base class, that one is a bit more invasive but mechanical and tested (as in running the full test suite)
<vila> ok
<vila> just wanted to make sure you were till agreeing as the extended proposal is quite bugger
<vila> hehe, bigger
<mgz> send it! :)
<vila> sent :)
<MvG> Hi! What's the significance of executable bits on Windows? A bzr working tree on a Windows system often reports changes to those x bits, which can be quite confusing. Wouldn't it make more sense to simply ignore that bit on windows?
<bob2> windows has no execute bit
<MvG> That's what I thought. But then why does bzr (cygwin command line as well as tortoise bzr) report changes there?
<mgz> it's a cygwin quirk
<bob2> I'd think cygwin would emulate it with some ridiculous hidden file or something
<mgz> ...can't find the bug about this currently
<MvG> But tortoise shouldn't be affected by cygwin quirks. And just because I use the cygwin bash to execute bzr shouldn't influence the python interpreter bzr is using either.
<mgz> maybe bug 938438 then?
<ubot5`> Launchpad bug 938438 in Bazaar "`bzr resolve --take-this` clears x-bit on win32" [Medium,Confirmed] https://launchpad.net/bugs/938438
<MvG> mgz: Not sure whether all my instances of this problem are due to that bug, but it certainly might contribute.
<MvG> Thanks.
<mgz> if you notice any other causes, please file bugs
<mgz> this stuff is fixable :)
<vila> mgz: still on the shared-stores review ? Can I help ?
<mgz> ah, no, wandered off on to other things
<mgz> I shall resume in a sec
<vila> for those following from home: quantal chroot installed on jubany and a first package with problematic xz file successfully imported
<mgz> woohoo.
<kinkie> hi all.. do you know if it's possible to silence the message about mismatching local/remote repository formats? I don't mind the performance hit, but the message is annoying.. thanks!
<james_w> vila, have you seen the fallout?
<vila> james_w: which one ? I just fixed categorize_failures
<james_w> add-import-jobs mail too
<james_w> W: line 14 [quantal]: Deprecated key 'priority' used
<james_w> I: This option will be removed in the future; please update your configuration
<james_w> /usr/bin/python: can't open file '${BASE_DIR}/bin/add-import-jobs': [Errno 2] No such file or directory
<james_w> vila, ^
<vila> ha cool, didn't get the emails yet, that's eexactly the part I'm debugging right now
<vila> ha crap, crontab don't expand variables, why do I keep forgetting that
<vila> james_w: any reason to not use LANG=C instead of LANG="en_GB.UTF-8" ?
<james_w> dunno
<vila> mgz: can the above have any fallout for the fs encoding ?
<vila> james_w: don't remember why you put it there in the first place ?
<james_w> no
<james_w> I suspect fs encoding indeed
<mgz> seems deeply inlikely, what's the full output?
<mgz> or, why are we worrying about what LANG is set to?
<vila> yeah, the later, different issue
<vila> mgz: the chroot has no locale so I'm asked to use LANG=C and I wonder if that will break something else
<mgz> LANG=C *is* no locale
<mgz> or you mean it lacks the package?
<mgz> it may break, depending on whether my filessystem encoding fix is in the bzr version used, and how careful the code is with printing unicode output
<vila> I can upgrade bzr
<vila> err, lacks the package... what do you mean ? The symptom is: bzr: warning: unsupported locale setting
<mgz> vila: run `locale -a`
<vila> http://paste.ubuntu.com/1137936/ C.UTF-8 ?
<mgz> that would be safe.
<vila> mgz: thanks, one less egg to juggle with
<vila>  File "/srv/package-import.canonical.com/new/scripts/udd/scripts/requeue_package.py", line 47, in main
<vila>     lock = icommon.lock_path(conf.get('pi.locks_dir'), package)
<vila> TypeError: lock_path() takes exactly 1 argument (2 given)
<vila> shudder
<LeoNerd> Hrm. I can't   bzr ci foo   when there are conflicts in  bar,  an unrelated file
<fullermd> Conflicts tend to come about from merges.  Last I heard, you couldn't ci foo when there was a pending merge period.
<LeoNerd> My conflict comes from an unshelve
<fullermd> Ah.  That's new on me then.
<jelmer> maxb: ping
<maxb> jelmer: pong
#bzr 2012-08-10
<mgz> morning all!
<vila> mgzorning !
<vila> mgz: shared stores ? Pretty please ? :-}
<mgz> okay, I'll really ...
<mgz> I was typing that already!
<mgz> now it looks like I was just responding....
<jelmer> maxb: ping
<vila> mgz: :)
<maxb> jelmer: hi
<thomi> Hi - I've just seen this odd message and I'm not sure what to make of it:
<thomi> $ bzr merge ../trunk/
<thomi> Not attempting to fix packaging branch ancestry, missing pristine tar data for version 1.0.
<thomi> All changes applied successfully.
<thomi> Any ideas?
<hoolter> How can I make a new branch on a remote git repository from within bzr explorer?
<fullermd> thomi: That's not from bzr itself; that's gotta be some plugin for ubuntu or debian or whatever packaging stuff...
<thomi> fullermd: huh... I wasn't aware that I was running anything like that
<thomi> ahh well, the merge seemed to work, so... *shrugs*
<fullermd> Well, you dont' know I used your credit cards to order 300 pizzas either, but...
<hoolter> hi all, could anyone give me a hand using bzr explorer with github? i'm really in a crunch to get a project wrapped up and sort of freaking out.  i'd super appreciate any tips i could get.
<fullermd> What you don't know won't hurt me   8-}
<fullermd> hoolter: Not me, sorry.  I know almost nothing about bzr-git and less about explorer.
<hoolter> fullermd: if you could give me a hand with the console interface that would be wonderful too.
<fullermd> Well, with bzr itself, I'd use init or push to setup a new branch somewhere.  If that doesn't just DTRT with bzr-git, I'm tapped.
<hoolter> fullermd: any idea why it'd throw an errno 10060?
<fullermd> That doesn't sound like anything I've ever heard of.
<wgz> hoolter, to get help you need to be way more specific about what you're actually trying to do, how you're doing it, and the *full* error
<wgz> 10060 is just WSAETIMEDOUT, in other words the windos socket library saying the other end didn't respond within the deadline
#bzr 2012-08-11
<youlysse`> So I'm pretty new to bzr, and I'm trying to grab the xwidgets-branch of emacs, from "bzr branch http://bzr.savannah.gnu.org/r/emacs/xwidget" but it seems not to be grabbing anything. Is there something I'm missing.
<cody-somerville> youlysse`, What do you mean by it doesn't seem to be grabbing anything?
<youlysse`> cody-somerville: It seems to "freeze" as soon as I try to execute it. It creates a "xwidgets" folder, then there's nothing else that appears to be happening?
<cody-somerville> youlysse`, It'll take a while to branch. There should be a progress indicator.
<youlysse`> cody-somerville: It's been ~40 minutes ... :-L (I see nothing to the key of "progress indicator" too.)
<cody-somerville> youlysse`, You could try a lightweight checkout instead: bzr checkout --lightweight http://bzr.savannah.gnu.org/r/emacs/xwidget
<youlysse`> Trying it now.
<youlysse`> cody-somerville: Does bzr just not display progress (verbosely) without a flag? Maybe it's doing it, but it doesn't seem like the folder is getting any bigger.
<cody-somerville> youlysse`, It shows it by default for me. - What version of bzr are you running and on what platform?
<youlysse`> I'll check, but I'm on Debian Sid, so I'm guessing the latest upstream. Sec
<youlysse`> "2.6.0dev2"
#bzr 2012-08-12
<codepython777> I want to remove all bazaar related files from a repo and have a clean output of the source. How can I get this?
<lifeless> codepython777: bzr export --help
<codepython777> thanks
<codepython777> copied it by hand...
<codepython777> next time, thanks
#bzr 2013-08-05
<ovnicraft> hello i have 2 branches (not stacked) i want to know if its possible extract revs from specific directory in branch A and put w/ that directory in branch B
<andrewuk> good evening
<andrewuk> so i have now setup bzr on my nas drive and i can connect to it through the terminal via SSH with no trouble
<andrewuk> but i cannot connect to my nas through bazaar explorer. I think this is because i need to set BZR_REMOTE_PATH but i cannot see how to do this in explorer
<vila> andrewuk: bzr_remote_path in locations.conf: http://paste.ubuntu.com/5952704/
 * vila bed :)
<vila> err, back to that is
<andrewuk> thanks villa i will take a look tomorrow and see if i can get it working
#bzr 2013-08-06
<janos> hi all
<janos> who can I contact for updating this page: http://wiki.bazaar.canonical.com/BazaarBook
<lifeless> it's a wiki - make an account and edit it, no?
<janos> hm I can try, hang on
<janos> awesome, thank you lifeless
<jelmer> janos: looks interesting :-)
<jelmer> janos: congrats on finishing a book! it's a long and hard process..
<janos> thanks jelmer, yes it was!
<janos> I hope some folks will find it useful
<jelmer> janos: might be worth a post to the mailing list too, or did that already happen?
<janos> which mailing list?
<janos> I sent to bzr-doc, where do you recommend?
<janos> I don't think it worked anyway, because the mail is not appearing in the public archives
<jelmer> janos: I'd send it to bazaar-announce@ - I think it's appropriate for that
<jelmer> that list might be moderated
<jelmer> bazaar-announce@ and bazaar@ I mean
<janos> great, thanks, I'll do that. and the domain name is lists.launchpad.net or something else?
<jelmer> janos: lists.canonical.com
<jelmer> although if you've managed to write a book about bzr, I'm sure you should be able to figure it out ;-)
<janos> haha :-) actually this is it, right now, me figuring out ;-)
<janos> btw, I really wanted to ask you guys to review while writing, but time was extremely tight, I was constantly late for deadlines, it was just not possible :(
<lifeless> jelmer: janos: lists.l.n discards mail from non-subscribers full stop; if it is a lists.l.n list ( I don't remember), you'll need to subscribe to post
<janos> thanks lifeless
<jelmer> lifeless: this is lists.c.c though, not sure what the policy is there
<jelmer> either way, it probably makes sense to subscribe..
<lifeless> jelmer: more relaxed, regular mailman
<janos> the wiki page update will also notify some people
<janos> so one way or another, I hope this will get noticed
<janos> but yeah, I'm typing up the email now
<janos> sent! hope it will work
<janos> thanks a lot jelmer and lifeless , I'm off to bed now but will leave this window open
#bzr 2013-08-07
<mnn> Hey, everyone. I haven't noticed that 2.6 is out. What does that exactly mean? Bazaar development got really sluggish over past year.
<mnn> jelmer?
<mgz> haven't noticed?
<mnn> nope... actually I was considering to move to Git, because of lack of development on bazaar. With that in mind, I would like to have a transitioning period - use bzr with some Git server to store repos
<mnn> so what's the status of using bazaar with git?
<mnn> anyone?
<jelmer> mnn: hi
<jelmer> mnn: you can use bzr on git repositories; there are a few known issues, and bzr-git hasn't been updated to work with some of the newer git features such as signed tags
<mnn> thanks, jelmer... I've read somewhere that dpushing using bzr-git does not preserve renames... is that still true?
<jelmer> mnn: yes, dpush is lossy
<jelmer> mnn: dpush is mainly useful if you want to contribute to an external project that is maintained in git
<mnn> so if I'm working on personal project, you don't recommend mixing bazaar and git, right? :)
<jelmer> mnn: indeed; I'd recommend either staying with bazaar or migrating to git
<jelmer> I was working towards getting bzr-git to support git as just another format in bzr, but never finished that work
<mnn> too bad... nevertheless thanks for info, jelmer
<mnn> what about bazaar development itself? 2.6.0 version was released... was this just "formal" release (not to stall any improvements/fixes in 2.6 betas) and development itself will linger as it has for more than a year?
<jelmer> mnn: Canonical doesn't have any full-time staff on bzr anymore. It's hard to say in a FOSS project how much will happen - it depends on how much time individual contributors want to put in.
<mnn> so it's safe to say that Canonical "killed" Bazaar, right?
<jelmer> mnn: I'm not sure that's fair. They're no longer investing in it while they previously were. A lot of the non-Canonical contributors that were around previously also aren't contributing as much.
<mnn> I know it's not fair. But since rise of Git, bazaar wasn't doing very well, right? Canonical was behind bazaar and Torvalds "was" behind Git. Thus since Canonical does not directly support development of bazaar, bazaar probably will never be able catch up with Git with only external contributors
<mnn> anyway, what would you recommend, jelmer, as experienced VCS user/developer for bazaar user... moving to Mercurial or Git?
<smw_> hi all, I have a bzr repo and I want to push it to a new git repo, is that possible? On a new github repo, I am attempting to do bzr dpush git+ssh://git@github.com/user/repo.git but I get bzr: ERROR: Unsupported protocol for url "git+ssh://git@github.com/user/repo.git"
<LeoNerd> smw_: I remember having to do something about  URL,branch=master
<LeoNerd> Otherwise it doesn't know what branch name to push to
<LeoNerd> Certainly I have managed  bzr dpush git+ss://git@github.com/Foo/Bar.git,branch=master
<smw_> LeoNerd, still isn't working
<smw_> LeoNerd, I am trying to dpush to a new repo though, perhaps that is the problem
<LeoNerd> Ahh.. possibly. I don't imagine it can create them
<smw_> LeoNerd, I tried creating a repo with a single commit and doing it
<smw_> LeoNerd, still didn't work
<LeoNerd> Ah.. notsure then.. I know very little about it :/
<smw_> LeoNerd, np, can you help with something else though? I have a "pending merge", how do I execute it?
<smw_> LeoNerd, I merged a patch I created with bzrsend
<LeoNerd> commit. "pending merge" means that there is merge information waiting for the next commit
<smw_> ah, so I just need to commit?
<smw_> should I put a commit message when I do that?
<LeoNerd> commits need a message, yes
<LeoNerd> Lacking anything else I usually just put  bzr ci -m "Merged from URL -r REVNO"
<smw_> ok
<smw_> just committed, now I see it used the wrong email, got to figure out uncommit now :-\
<LeoNerd> Hah.. uncommit on git? Good luck :/
<smw_> oh wow, it is just bzr uncommit... that is awesome
<smw_> nope, this is on bzr :-D
<LeoNerd> bzr uncommit will do it locally
<LeoNerd> ah.. OK :)
<jelmer> smw_: you need to install bzr-git if you want to push to git
<smw_> jelmer, yeah, just figured that out
#bzr 2013-08-08
<quicksilver> is there any way to add a file in two branches (same file) so they won't conflict when merged?
<quicksilver> --file-ids-from
<quicksilver> documentation++
<jelmer> quicksilver: they'll probably still conflict, but not in the annoying way where ever subsequent merge will cause file id conflicts.
 * quicksilver nods
<quicksilver> well I normally end up deleting one copy
<quicksilver> so there is only one left
<quicksilver> jelmer: seems it doesn't conflict if you merge immediately
<quicksilver> which I have now done.
<quicksilver> merge "the other way" if you follow
<ggherdov> hi all. Is bzr still under active development?
<jelmer> ggherdov: 2.6.0 was released a couple of days ago
<Luke-Jr> jelmer: do you plan to fix bzr-svn?
<jelmer> Luke-Jr: fix what specifically?
<jelmer> linking against libsvn > 1.7 ?
<Luke-Jr> yes
<Luke-Jr> pretty much every distro is removing it completely because it no longer works with current software
<jelmer> I might - most of the work is actually in subvertpy, which I still maintain
<Luke-Jr> hrm, seems my bzr still breaks even after I remove bzr-svn :|
<jelmer> Luke-Jr: with what error?
<Luke-Jr> ImportError: cannot import name CommittedQueue
<Luke-Jr> http://codepad.org/He4KkusS
<jelmer> Luke-Jr: looks like you still have bzr-svn installed in that case. does "bzr plugins" still list it?
<Luke-Jr> yes
<jelmer> sounds like it's still installed then. "bzr plugins -v" will tell you where
<Luke-Jr> looks like the .pyos remain
<Luke-Jr> oh well, bzr-svn was basically all I used bzr for anymore anyway :x
<jelmer> I'm not planning to do more work on bzr-svn itself
#bzr 2013-08-09
 * Luke-Jr ponders what VCS to use for svn repos if bzr is no longer interoperable :x
<jelmer> Luke-Jr: svn ? :-)
<Luke-Jr> svn doesn't make a full repo copy
<fullermd_> I was gonna say that, but I hate seeing a grown man cry.
<Luke-Jr> nor allow local commits
<jelmer> there's also hgsubversion and git-svn, though I don't have experience with either
<Luke-Jr> git-svn at least is not transparent :<
<ggherdov> thanks jelmer
#bzr 2013-08-10
<Wiz_KeeD> hello everyone!
<Wiz_KeeD> Who here is online?
<jelmer> hi Wiz_KeeD
<Wiz_KeeD> hello jelmer
<Wiz_KeeD> I have a question for you...do you use a issue tracking system with bzr?
<Wiz_KeeD> I'm looking for one and can't quite tell
<jelmer> launchpad?
<Wiz_KeeD> a personal one, to use with clients
<smartboyhw> Wiz_KeeD, hmm, you might want a private subscription in LP then
<Wiz_KeeD> :(
<Wiz_KeeD> costs moneeyyyy
<Wiz_KeeD> me no likey
 * Wiz_KeeD cheapskate
<Wiz_KeeD> X
<Wiz_KeeD> XD
<Wiz_KeeD> this http://trac.edgewall.org/ and Redmine look interesting
#bzr 2014-08-04
 * superfly hears the wind blowing in the trees
<kay_> hi, I have run 'bzr branch' on the emacs-24 repository but all I get is a .bzr directory
<LeoNerd> Maybe it doesn't have a checkout yet?
<kay_> do I type a checkout command?
<LeoNerd> I'd be tempted to
<kay_> do i just type 'bzr checkout'
<kay_> it says that its not a branch but that its a repository
<LeoNerd> Hmmm
<kay_> first time bzr user
<LeoNerd> Oh, oops; you might have branched from the repository.. which probably ought to fail but might have had an empty branch in it for some reason
<LeoNerd> A repo is not a branch; a repo -contains- branches.
<kay_> I followed the instructions on the website for emacs development, so i have no idea where to go from here
<LeoNerd> What instructions?
<kay_> on http://savannah.gnu.org/projects/emacs/
<kay_> it says I can access the main repository with 'bzr branch bzr://bzr.sv.gnu.org/emacs/emacs-24'
<LeoNerd> So, you have an  emacs-24  directory?
<kay_> yes
<LeoNerd> And inside that is ... just the .bzr and nothing else?
<kay_> its possible, also, that the bzr command crapped out
<LeoNerd> Ah.. well, it would hopefully have printed some long error message if it did so
<LeoNerd> ... though beware that OOM-killer is silent ;)  check  $?  afterwards
<kay_> i backgrounded it and closed the terminal it was in
<kay_> silly me
<LeoNerd> Ah. :) Well don't do that.  Maybe use 'screen' or similar if you want to detach and resume again later
<kay_> i needed to kill X because I was running in a VM with 512mb ram
<kay_> but yeah, i didn't think it would take 30 minutes ro run
<kay_> re-running it now from better instructions
<kay_> this crap literally takes forever
#bzr 2014-08-05
<mbruzek> Hello bzr folks.  I am working on a system that has limited network access.
<mbruzek> I got this error ssh: connect to host bazaar.launchpad.net port 22: Connection timed out
<mbruzek> when trying to run this command. bzr push lp:~mbruzek/charms/bundles/ceph/local
<mbruzek> So I tried a different approach.
<mbruzek> $ bzr push https://launchpad.net/~mbruzek/charms/bundles/ceph/local
<mbruzek> bzr: ERROR: Transport operation not possible: http does not support mkdir()
<mbruzek> Can someone help me with this problem?
<jelmer> mbruzek: you need ssh access to launchpad to push
<mbruzek> jelmer, can I make the dirs that I need on http://launchpad.net and then push using ssh?
<jelmer> mbruzek: I don't see how that would help?
<jelmer> "bzr push" would take care of creating the branch
<mbruzek> ack thanks jelmer
#bzr 2014-08-07
<xnox> C'est la vie! Au revoir!
#bzr 2014-08-09
<SamB> anyone know how to turn a series of bzr commits into a set of patches ala git-format-patch?
<SamB> hmm, having trouble getting the series at all:
<SamB> % bzr log -p -rbzr://bzr.savannah.gnu.org/emacs/trunk.. lp:~naesten/emacs/nextstep-stuff|less > nextstep-stuff.patches
<SamB> bzr: ERROR: Server sent an unexpected error: ('error', 'GhostRevisionsHaveNoRevno', 'Could not determine revno for {bzr://bzr.savannah.gnu.org/emacs/trunk} because its ancestry shows a ghost at {eggert@cs.ucla.edu-20120708200356-0nr2pnd47pk0ejh2}')
#bzr 2015-08-04
<throstur> where can I find what `bzr update` return codes are?
<throstur> the reference at http://doc.bazaar.canonical.com/bzr.2.6/en/user-reference/update-help.html doesn't tell me
<throstur> trying to scour through the source and I'm not sure where to even start
<throstur> ok that's a lie I know where to start but there's a lot of manual tracing :( pls?
<throstur> what does it return on a conflict?
<verterok> throstur: 0 when all ok, 1 on conflict or error
<throstur> thanks verterok
<verterok> np
#bzr 2016-08-09
<ychaouche> Hello #bzr
<ychaouche> I made a checkout once from a remote machine which had a static IP, now the network is DHCP and I can no longer commit. What do you advise to make the repo local ?
<ychaouche> I can't commit because when I do it tries to reach the remote machine with the old IP
<ychaouche> I would like to turn the checkout into a local thing so that commits would be local.
<LeoNerd> bzr unbind   will remove the remote location
<LeoNerd> Or for one-offs you can  bzr commit --local ...
 * ychaouche should have made a branch, he knows now.
<ychaouche> Thanks LeoNerd
<ychaouche> will unbind once and for all
<LeoNerd> The only -real- difference between branch and checkout is the boundness of it
<LeoNerd> a checkout is a bound branch;   bzr co  is really just  bzr branch followed by bzr bind
<ychaouche> interesting
<LeoNerd> And a bound branch is basically just one in which commit becomes an atomic "commit locally then push" operation
<LeoNerd> Atomic, because if the push operation would fail because upstream is updated, then local commit doesn't happen
#bzr 2016-08-10
<throstur> I've done something wrong, when I try to commit it tells me that it's a read only transport, can I fix it or must I download the repo again?
#bzr 2016-08-12
<LeoNerd> bzr: ERROR: unknown command "vimdiff"
<LeoNerd> booo, what broke? I want to vimdiff between my current file and an earlier revision of iy
<LeoNerd> Aha!  vimdiff FILE <( bzr cat -r12 FILE )
#bzr 2017-08-08
<dorian_> Hey there. Is there a way to color the diffs of the log command from bazaar itself ?
<dorian_> (ie: not using an external tool ?)
