#bzr 2008-07-14
<mathrick> mwhudson: yeah
<cyberix> still imports the one from site-packages
<mwhudson> cyberix: what exactly are you doing?
<mwhudson> can you pastebin a session?
<cyberix> Just trying to run selftest on a vanilla "checkout" from lp:bzr
<mathrick> mwhudson: it seems to be true for bzr+ssh:// as well
<Verterok> cyberix: that's weird. try removing/not using your current PYTHONPATH, i.e: PYTHONPATH=/path/to/branch
<mwhudson> mathrick: i'm not surprised there
<mathrick> why not?
<cyberix> http://pastebin.com/d73a21e3
<mwhudson> mathrick: because the code for bzr:// and bzr+ssh:// is basically the same at this level
<cyberix> Verterok: That doesn't change anything
<mwhudson> cyberix: hm, seems to be loading the system plugins
<mwhudson> which is wrong, but less wrong than what you first said
<cyberix> oh
<cyberix> Any further suggestions?
<Verterok> cyberix: you can use the --no-plugins option
<mwhudson> ./bzr --no-plugins selftest
<Verterok> cyberix: also there is the BZR_PLUGIN_PATH env var, in the case that you want to include some plugins in the selftest
<mathrick> mwhudson: ok, do you see a fix?
<mathrick> I need to know if I should invest into making it work, or rather take care of the reading part of my app
<mwhudson> mathrick: not really looked yet
<mathrick> aha
<mwhudson> mathrick: i wonder if i can trick spiv into fixing it
<mathrick> hehe
<mwhudson> spiv: https://bugs.edge.launchpad.net/bzr/+bug/175570
<ubottu> Launchpad bug 175570 in bzr "bzr cat over bzr protocol fails" [Medium,Confirmed]
<mathrick> I think he should feel morally obliged to fix it, he knew the bug number instantly when I mentioned it :)
<mwhudson> smart server/remote branches is something he knows more than most about
 * mathrick wonders if that is a good thing
<cyberix> thanks that helped
<spiv> mathrick: "instantly" is a bit of an exaggeration :)
<cyberix> going to sleep now
<cyberix> good night
<spiv> I had to search Launchpad, but happily searching bugs.launchpad.net/bzr for "cat ObjectNotLocked" found exactly 1 bug.
<mathrick> excuses
<mwhudson> spiv: do you know about the locking thing off hand?
<spiv> locking thing?
<mathrick> spiv: the bug I ran into
<mwhudson> spiv: http://pastebin.ubuntu.com/27148/
<spiv> mwhudson: that has the same root cause as 175570, I believe
<spiv> There's another related bug report or two, as well.
<mwhudson> spiv: well, i was more thinking that it could be the root cause for that bug
<spiv> mwhudson: well, that's a symptom, not a cause ;)
<mwhudson> spiv: ok
<spiv> The cause is roughly that RemoteBranch.lock_read doesn't call lock_read on its repo.
<spiv> But just simply doing that breaks other things.
<spiv> There's a discussion of this on the list and/or this mysterious other bug report I'm alluding to.
<mwhudson> hm
<spiv> mwhudson: https://bugs.edge.launchpad.net/bzr/+bug/237067
<ubottu> Launchpad bug 237067 in bzr "RemoteBranch.lock_read() doesn't lock the underlying repository" [High,Confirmed]
<mwhudson> spiv: yay google
<mwhudson> (i just found that too)
<CrashTest_> Aha!  I was going to ask a good-ole' stupid question, but I found the answer!  sftp://myuser@domainname.com/~/svr/bzr/ works, sftp://myuser@domainname.com/svr/bzr does not :)  Silly little ~
<lifeless> woo, 1.6Million key btrees , no memory _explosion_
<lifeless> (and thats not the limit, that was just disk spilling when it blew up cause it exceeded the header size)
<lifeless> megarepo test on b+tree indices:
<lifeless> 115M    .bzr/repository/indices
<lifeless> down from
<lifeless> 444M    backup.bzr/repository/indices/
<lifeless> poolie: oh yeha, hi :)
<poolie> night all
<pagenoare> hi
<pagenoare> anybody using bzrweb with bzr 1.5rc1? :D
<awilkins> lifeless: But are b-trees Faster too?
<lifeless> awilkins: igc mailed the list with some results
<lifeless> awilkins: executive summary: much faster at some things; a bit slower at others, ~= on the rest.
<gabe> hi all
<gabe> wondering if someone might be able to help me out with a bzr related problem
<gabe> get the following error: bzr: ERROR: [Error 32] â§ÐÑÐÑÑÑ ÑÑ ÑÑÑÑÐ ÑÑÑÑÑÑÐâ ÑÑÑÐÑÑ Ñ ÐÑÑÑÑ,
<gabe>  â§ÐÑÐÑÑÑ ÑÑ ÑÑÑÑÐ ÑÑÑÑÑÑÐâ ÑÑÑÐÑÑ Ñ ÐÑÑÑÑ, is unreadable meaningless heap of letters!
<gabe> reported it on https://bugs.launchpad.net/bzr/+bug/237305
<ubottu> Launchpad bug 237305 in bzr "bzr: ERROR: [Error 32] " [Undecided,Incomplete]
<Odd_Bloke> gabe: What OS are you using?
<gabe> that's on windows vista with bzr 1.5
<Odd_Bloke> Hmm, I don't really know enough about Windows to be able to help you debug. :(
<gabe> i know enough about Windows not to use it!
<Odd_Bloke> gabe: That said, attaching the relevant part of .bzr.log to the bug report would probably be helpful.
<gabe> it's actually a russian friend with the problem
<gabe> trying to help him solve it..
<gabe> i'll see if i can get hold of bzr log
<Splodge> Hi, I'm hoping somebody here can help me: is it possible to compare two branches in bzr?
<Splodge> I have a trunk on the server which I've 'branch'ed to my PC. Then, to test things, I updated some files in the working tree and committed them to the local copy of the branch (what's the proper term for this - local mirror?). The question is, is it possible to compare the local copy containing the commits, to the branch on the server in a nice, simple way? Or am I approaching development...
<Splodge> ...with bzr incorrectly?
<Kinnison> cd local-branch
<Kinnison> bzr diff http://path/to/remote/branch
<bob2> 'bzr missing' will show the different commits on each, or you can use bzr diff to show diffs
<lifeless> gabe: sounds liek the error isn't encoding correctly on output
<Splodge>  Ah I see.
<Splodge> 'diff' doesn't show anything for me, but 'missing' does list the extra revisions I have locally.
<Splodge> And the --verbose item will show extra details on the changes to files etc.
<Splodge> That's just what I was looking for. Thank you.
<gabe> thanks
<gabe> I got a section of the bzr log attached to the bug report, it's here... http://launchpadlibrarian.net/16008570/bzr.log
<lifeless> gabe: thanks
<awilkins> gabe: ERr 32 is an IO error ; probably a file being held open by another process
<awilkins> gabe: Which shell are you using? THe error text looks like it's in unicode or something
<awilkins> gabe: Looks like an eastern European error message for err 32. Your local encoding is cp866 so I presume you are cyrillic by nature...
<gabe> yeah it's actually a russian friend I am asking on behalf of
<gabe> what info do you need?
<awilkins> gabe: Well, it's an IO error during a tree transform ; I would suspect that another process has a lock on one of those files
<lifeless> hmm, I was going to say bzr --version
<lifeless> but it doesn't include the encoding
<lifeless> gabe: does your friend see a readable error?
<gabe> what he sees is what I pasted here
<gabe> error 32 etc
<gabe> and some unreadable junk too
<lifeless> gabe: if what he sees is correctly encoded cp866 he will be able to read it even though we can't
<gabe> he's used bzr for a while
<gabe> no problem
<lifeless> thats the nature of encoding
<gabe> yeah but he said it is junk
<gabe> unreadable even to him
<lifeless> gabe: so I'm tryingt o understand if *he* can read it, not if the copy and pasted stuff is unreadable
<lifeless> ok
<lifeless> so there are two issues: why the error, and the error being unprintable
<gabe> he has a checkout of a branch
<gabe> and been doing about 25 --local commits
<lifeless> as for why the error, does he have an editor open on a file or something?
<gabe> then wanted to commit back to the repo
<gabe> but it said he needed to bzr up
<gabe> so he did bzr up and got this
<jelmer> hey *
<gabe> some conflicts
<gabe> and errors
<awilkins> He has a file open
<lifeless> gabe: I would guess an editor open on a file
<gabe> ok
<awilkins> It's during a rename
<lifeless> jelmer: hi
<gabe> i'll make sure he quits any editors and tries again
<awilkins> Windows ia waaay more picky about files being open when it writes over them
<beuno> mornin' all
<jelmer> lifeless: How were things at GUADEC?
<lifeless> jelmer: intense :)
<lifeless> many positive discussions, some rather more neagative
<beuno> lifeless, any guesses on what the outcome for VCS choice will be?
<jelmer> lifeless: what in particular were the negative ones about?
<lifeless> jelmer: some folk felt that canonical was pushing bzr (rather than us being there because gnome devs *wanted* support for bzr)
<lifeless> jelmer: and there were some rather opinionated folk that didn't want a dialogue, but instead wanted to tell me how stupid it was to even hack on bzr given that git exists
<jelmer> lifeless: wow, ok
<lifeless> beuno: no idea yet
<Kinnison> The number of people who think that git is the be-all-and-end-all, perfect, etc. does surprise me
<Kinnison> esp. given how I cannot get on with it no matter how hard I try
<lifeless> Kinnison: the number of them that have used bzr in anger appears to approach zero
<Kinnison> lifeless: surprise surprise.
 * Kinnison wishes git was easier and nicer
 * Kinnison gave up and did his kernel module dev in bzr and supplied a patch to the kernel guys
<Kinnison> because I just can't get git to be of any use to me
<jelmer> lifeless: Thanks for the update
<lifeless> jelmer: should have a interseting ssvn bug for you soon
<jelmer> I'm looking forward to it ;-)
<pbor> lifeless: did you persuade any gnomers (that currently use svn/git) to at least try bzr?
<lifeless> pbor: yes
<pbor> cool
<lifeless> rob taylor from codethink appears quite excited :)
<asabil> lifeless: are you serious ?
<lifeless> Jc2k: how's your head? recovering from guadec?
<lifeless> asabil: about what?
<asabil> about rob taylor
<pbor> getting people to actually try it is the only way to gain user base :-)
<lifeless> asabil: yes
<asabil> wow !
<Jc2k> lifeless: my brain is at about 25% usefulness
<asabil> last time I talked to him (a year ago), he was worshiping git
<lifeless> asabil: he's had Jc2k hammering on him way before guadec :) I just added the straw I think
 * Jc2k nods
<asabil> lol :)
<Jc2k> not just that though
<asabil> well done Jc2k ^^
<Jc2k> he's been poking the Git source code for his project
<asabil> we need more of you
<Jc2k> and Git source would finish anyone of
<Jc2k> f
<Jc2k> its horrible in there.
<pbor> haha
<asabil> I think bzr developers maybe should start blogging code snippets from git's source code
<asabil> maybe that would shed some light on the evil dark corners of git :p
<beuno> jelmer, btw, which BB are we using for bzr-gtk?  it seems we have 2 fighting over it now
<jelmer> beuno, vernstok.nl is still the primary one
<jelmer> until the one on Aarons machine has the right details
<beuno> jelmer, cool, I'm back home now, so I should be able to go through the remaining reviews, and merge some of them
<jelmer> cool
<beuno> sorry I've been so unresponsive, but I've had a few unusual weeks  :)
<fullermd> Heck, I've had a few unusual _months_...
<awilkins> vila: Ping?
<mtaylor> guys, I love you all, but this: bzr: ERROR: Repository KnitPackRepository() is  not compatible with repository KnitPackRepository()
<mtaylor> is quite possibly the worst error message in the history of mankind
<lifeless> mtaylor: totally
<jelmer> mtaylor: Couldn't agree more
<lifeless> mtaylor: and I'm embarrased
<mtaylor> ok.
<lifeless> jelmer: so patch it up :)
<mtaylor> as long as you're embarrassed
<lifeless> jelmer: add the rich root etc stuff to str()
<mtaylor> also, let me verify...
<mtaylor> rich-root-pack is required for former svn repos... but is not recommended at this point for normal use of large projects, say, like the mysql trees?
<jelmer> lifeless: Maybe once I finish browsing through the bzr-svn bugs from the last 5 days...
<lifeless> jelmer: :)
<lifeless> mtaylor: its a one way trap door; shouldn't be performance implications
<lifeless> holy cow
<lifeless> this index is a 5-level B+Tree
<lifeless> 2.9Million keys
<awilkins> lifeless: Did you think about incredibly-scary-judy-arrays ?
<lifeless> awilkins: yes
<awilkins> I never tried them personally, but the papers read really impressively :-)
<lifeless> 5 IO's per key -> not ideal. But hey, its all of ubuntu.
<lifeless> jelmer: https://bugs.edge.launchpad.net/bzr-svn/+bug/248406
<ubottu> Launchpad bug 248406 in bzr-svn "Import of SVK modified SVN repositories" [Undecided,New]
<gabe> ok my russian friend closed his editor
<gabe> did bzr up
<gabe> this is what he said:
<gabe> i've closed editor and run bzr up and it completely removed all my changes
<gabe> all 26 local commits are disappeared
<gabe> why did it do that!?
<lifeless> gabe: bzr st will show you a pending merge
<lifeless> gabe: and he should now 'bzr commit' to record it and put it in the repository
<gabe> oh
<gabe> lifeless: thanks for your continued assistance
<gabe> i'll check on the bzr st
<lifeless> gabe: if he reverted or something then it will have become a dead head and he can do 'bzr heads --dead' or whatever to find the id etc.
<gabe> er
<gabe> this is what his bzr st shows
<lifeless> gabe: check on bzr st :)
<gabe> D:\xampp\htdocs\eastwestfilms\hungerseason>bzr st
<gabe> unknown:
<gabe>   .project
<gabe> no merges :(
<lifeless> gabe: bzr heads --dead-only
<lifeless> gabe: he will need bzrtools installed
<gabe> he had a whole bunch of about 25 --local commits
<gabe> lifeless: he has been using bzr for a while without problem? Is he really missing bzr tools?
<lifeless> gabe: the heads command is in bzrtools
<lifeless> gabe: I don't know if he is missing it or not, but to find the id of the commits that he reverted we need bzrtools
<Splodge> can anyone tell me how to revert a 'branch'ed that has had some commits made back to the trunk version? a 'revert' only reverts the working tree to the branched copy. do I need to do something with 'pull' or provide some optional parameter. googling has turned up unless i'm just looking in the wrong places... (apologies if it is a stupid question)
<gabe> right, i'll make sure he has it installed.
<lifeless> gabe: its there in his repository, we just need to pull it back into his tree
<lifeless> gabe: try the command, if it's unknown command install bzrtools/upgrade bzrtools
<lifeless> Splodge: pull --overwrite
<gabe> try this command? zr heads --dead-only?
<lifeless> gabe: yes
<gabe> bzr heads --dead-only
<gabe> what will it do?
<Splodge> lifeless: Thanks! You guys are good ;)
<lifeless> gabe: report on the name of the stuff he reverted
<gabe> ok i asked him to try
<gabe> lifeless: you are right, unknown command
<gabe> so install bzr tools
<lifeless> gabe: yes
<lifeless> abentley: ping
<abentley> lifeless: pong
<lifeless> abentley: nevermind, something stranger than I considered
<lifeless> abentley: I have an epic fail on my mega repo; with bzrlib.errors.RevisionNotPresent: Revision {('zopezver.init.in-20080520144343-w8u8nix52axlkvgg-19', 'liw@gytha-20080520144343-7pdk3g344utm17vz')} not present in "<bzrlib.knit.KnitVersionedFiles object at 0x2ac7674f8810>".
<lifeless> abentley: but the repo has single commits everywhere so it should be impossible
<abentley> lifeless: This is with B+ trees?
<lifeless> abentley: yes, though I think that that is orthogonal
<lifeless> I know what is happening
<lifeless> bug in my bug fix
<lifeless> abentley: so yes, it was B+trees
<abentley> lifeless: Glad you found it.
<gabe> how to install bzrtools
<lifeless> abentley: I was handling far right hand end nodes wrong if the node had only one child
<Odd_Bloke> abentley: BB doesn't seem to be picking up on when patches have been merged into PQM's trunk (http://bundlebuggy.aaronbentley.com/project/pqm/request/%3C20080710071152.05c913e0@lapbert%3E is the only example ATM).
<abentley> Odd_Bloke: Okay, I'll look into it.
<Odd_Bloke> abentley: Thanks. :)
<abentley> Odd_Bloke: Could you file a bug report, please?
<Odd_Bloke> abentley: Sure.
<gabe> ok my friend has bzr tools installed
<gabe> this is the result of bzr heads --dead-only
<gabe> HEAD: revision-id: kos@pixeco.com-20080714080119-60tpfuob57h4zma4 (dead)
<gabe>   committer: Kos
<gabe>   branch nick: hungerseason
<gabe>   timestamp: Mon 2008-07-14 14:01:19 +0600
<gabe>   message:
<gabe>     Added sIFR for images caption
<lifeless> gabe: ok, you can now do 'bzr merge -r revid: kos@pixeco.com-20080714080119-60tpfuob57h4zma4'
<gabe> oooh ok
<lifeless> gabe: and then 'bzr commit'
<gabe> that's very precise :)
<lifeless> erm, thats revid:kos...
<lifeless> I added a space by mistake
<lifeless> like so:
<lifeless> 'bzr merge -r revid:kos@pixeco.com-20080714080119-60tpfuob57h4zma4 .'
<gabe> ok cheers
<lifeless> that will resurrect his patches
<gabe> D:\xampp\htdocs\eastwestfilms\hungerseason>bzr merge -r revid:kos@pixeco.com-20080714080119-60tpfuob
<gabe> 57h4zma4
<gabe> bzr: ERROR: No location specified or remembered
<gabe> is that bad news?
<lifeless> gabe: add the '.' :)
<jam> gabe: there is a hard to see '.' after the revid
<jam> you could alternatively change the order
<jam> bzr merge . -r revid:.....
<jam> lifeless: are you still in Europe?
<gabe> lifeless: yep, quite right!
<lifeless> jam: London indeed
<lifeless> gabe: happy to help, sorry it took up your friends time
<Odd_Bloke> abentley: https://bugs.launchpad.net/bundlebuggy/+bug/248422
<jam> lifeless: how long before you head back to AU? (Just curious how much time you'll be awake when I am :)
<ubottu> Launchpad bug 248422 in bundlebuggy "Merging of patches to PQM trunk not detected" [Undecided,New]
<abentley> Odd_Bloke: Was the patch merged after BB started tracking PQM?
<lifeless> jam: 1 week
<gabe> lifeless: we're still working on that last command
<gabe> seems he gets
<gabe> "'bzr" is not recognized as an internal or external command,
<gabe> operable program or batch file.
<lifeless> gabe: well, how does he run bzr normally ? :)
<gabe> is that because windows doesn't recognise the quotes around the command?
<lifeless> gabe: you shouldn't copy the quotes, they were to show you what to copy :)
<gabe> he uses the bzr command but not with quotes around it I guess
<gabe> oh woops
<gabe> that worked
<gabe> lifeless: when I work on a checkout make local commits, when I want to commit to repo sometime I need to bzr up, but then it wipes all my changes too - why does this happen?
<lifeless> gabe: it does not wipe them away; you have to run 'bzr revert' to wipe them away
<gabe> so what does it do with my local commits then?
<gabe> and why are they 'taken away'?
<lifeless> it puts them into a pending merge
<lifeless> so that after the update, when yo commit they go into the master
<lifeless> and they are taken away when you run 'bzr revert' because bzr revert removes pending merges
<Odd_Bloke> abentley: I _think_ so, but I'll go and check timestamps.
<gabe> but bzr st doesn't show them?
<lifeless> gabe: bzr st will show them
<gabe> i mean i thought merges didn't really happen with checkouts
<lifeless> gabe: I assure you, he ran - 'bzr up' and then 'bzr revert'
<lifeless> gabe: checkouts can totally do merges
<gabe> ok, so in the future, when my local revisions appear to have been nuked what should be be looking at doing?
<lifeless> gabe: dont run bzr revert after an update and they will never appear to have been nuked
<gabe> mmm ok
<Odd_Bloke> abentley: You sent the message to the ML about PQM now being managed by BB on the 9th, the merge happened on the 10th.
<lifeless> 'bzr update && bzr revert' is guaranteed to give you a tree the same as the thing you have a checkout of.
<lifeless> gabe: (&& means followed by)
<gabe> ah ok
<gabe> and then what did you do to fix that? merge the current tree with a previous version that included local commits?
<lifeless> bzr update && bzr commit is guaranteed to commit your local edits to the thing you have a checkout of.
<lifeless> yes, the use of heads --dead-only, and merge, is how we reinstated the local commits.
<abentley> Odd_Bloke: I'm not sure when the last tweak of the merge-detection code happened.  It may have been afterward.
<lifeless> jam: I am going to make the last node in a row be variable-sized
<lifeless> jam: using b+tree indices in bzr search.. hurt
<jam> lifeless: I understand your desire, but isn't that the last node in the *last* row only?
<lifeless> jam: yes
<gabe> i need to find out about bzr heads
<gabe> bzr heads
<gabe> bzr: ERROR: unknown command "heads"
<gabe> even after doing:  sudo ./setup.py install
<lifeless> jam: its actually really the use of many tiny indices *I think*
<gabe> in the bzrtools extraction dir
<lifeless> gabe: what path did it install into
<jam> lifeless: you realize, that is probably sub-optimal from an FS perspective anyway
<gabe> Writing /Library/Python/2.5/site-packages/BzrTools-1.5.0-py2.5.egg-info
<jam> considering most FS have a minimum 4k page
<lifeless> jam: they are in a pack
<jam> lifeless: you are putting the indexes into a pack file... ok, I guess
<lifeless> jam: better than 100000 files on disk :)
<lifeless> jam: ask mtaylor how long the earlier editions took to delete an index :)
<mtaylor> jam: oit was not pretty :)
<jam> lifeless: because deleting required re-packing everything?
<jam> sounds like a flag "deleted" case :)
<lifeless> jam: no, because ext3 doesn't handle hundred's of thousands of files in a single directory gracefully
<lifeless> jam: bzr-search doesn't delete stuff anyway
<jam> ah, before the packing
<jam> yeah, I seem to remember running into that in the past
<jam> when we were working on medical images and dumped 100k files in a directory
<jam> I had to write a custom script that used the raw C files to move them out
<jam> the raw C *functions*
<jam> because 'ls *' or python listdir() would just take forever to finish
<gabe> ls /Library/Python/2.5/site-packages/bzrlib/plugins/bzrtools/
<gabe> __init__.py             dotgraph.pyc            rspush.py
<gabe> etc
<gabe> seems to be there
<jam> gabe: I would double check that "bzr --version" lists /Library/Python/2.5/site-packages/bzrlib as its bzrlib location
<gabe> ha no
<gabe> it doesn't
<gabe> best fix that
<jam> Odd_Bloke: still getting your random commits on the commit list
<jam> http://bzr.daniel-watkins.co.uk/pqm/work/foo "renamed 'foo' => 'bar'"
<meteoroid> i initialized a repository from generated code, added everything, committed, then branched to a remote bzr+ssh url.  this location on the server only ended up with a .bzr subfolder, and is smaller, significantly, than a branch made from it locally, eg. 'bzr branch main dev'
<meteoroid> clearly there is something basic i don't understand, anyone care to proffer a link or something?
<Odd_Bloke> jam: Ah, thanks.
<jam> meteoroid: I'm guessing on your server you don't have a working tree, which is standard for places that we can't access the wt directly
<jam> you should still have all the revision data
<jam> just no working files
<Odd_Bloke> If I have a lightweight 'work' checkout which is bound to a branch, which location's settings will be used from locations.conf?
<meteoroid> jam: ah ok, that's what i figured, is there some command i run to turn a branch into a wt?
<jam> Odd_Bloke: are you saying light weight => branch => other_branch ?
<jam> meteoroid: 'bzr co'
<jam> but the WT won't be updated by default either
<jam> (there are some workarounds for this)
<meteoroid> hm
<meteoroid> well i shouldn't use the 'master' i set up as a wt anyway
<meteoroid> actually i was kinda curious why the other branches were bigger
<meteoroid> i guess i want to branch remotely
<meteoroid> still have yet to set up http :/
<Odd_Bloke> I have 'pqm/work' bound to 'pqm/foo'.  When I commit in 'pqm/work' (and so in 'pqm/foo') which config in locations.conf will be used, 'pqm/work's or 'pqm/foo's?
<Odd_Bloke> jam: ^
<jam> Odd_Bloke: that isn't a lightweight checkout...
<jam> but I would guess if you have a bound 'work' => 'foo' then 'work' still gets used for the bound branch
<gabe> lifeless: thanks ever so much for your help
<jam> I'm not sure that all functions agree on this, though
<lifeless> dato: ping
<gabe> my friend is so relieved to have all his work back and is very grateful to you :)
<lifeless> gabe: no probs
<gabe> what is a revision that doesn't have descendents and is dead?
<lifeless> gabe: a dead revision is one that no branch refers to
<lifeless> gabe: a revision with no commits that build upon it is a head
<Odd_Bloke> jam: It _is_ a lightweight checkout, I presumably didn't mean 'bound to'. :)
<jam> Odd_Bloke: lightweight will use the target
<gabe> and that is what you get if you do bzr up &&  bzr revert ?
<jam> that I'm sure of
<jam> when we open a light checkout, it instantly redirects to open the target branch
<jam> so we don't really ever *see* the lightweights fake branch
<jam> and almost all config is done at the Branch level, not the WT level
<lifeless> gabe: yes
<jam> lifeless: for the 'failure during deep copy' do you have any hints as to what happened?
<jam> Did it just fail *to* deepcopy?
<jam> (I'm testing with python 2.4.5 and things seem to work)
<lifeless> it just failed to copy
<lifeless> it was 2.4.4
<lifeless> (manganese)
<jelmer> lifeless, Odd_Bloke: Are you going to be around for some sprinting before saturday?
<lifeless> jelmer: I'm in London, get to wolverhampton 9pm friday
<jelmer> I'm in Dublin atm and trying to decide whether to go home for a day or two or to go there directly
<jelmer> lifeless, ah, ok
<lifeless> jelmer: if you wanted to come to London for a bit I'm sure that would be ok
<jam> lifeless: well, the trivial "a = array.array(...); b = copy.deepcopy(a)" works on manganese :(
<lifeless> jam: I was running 'bzr upgrade --btree-plain' with blooms enabled
<lifeless> jam: and this made it fall down go boom
<jelmer> lifeless, That may be a nice idea
<lifeless> jelmer: let me confirm then
<jam> I wonder if it might have been an OOM error
<Odd_Bloke> jelmer: I'm in Coventry (at home) ATM.
<lifeless> jelmer: yes, wouldn't be a problem for you to drop into the office; ned to know the days in advance though :)
<lifeless> jam: don't think so
<lifeless> jam: it had _much_ more meory problemms earlier when it was digging GB's into swap
<jelmer> lifeless: cool, thanks. I'll see if I can figure out the travel
<Odd_Bloke> jelmer: I don't have any solid committments this week, though, so I'm available for sprinting.
<jam> lifeless: that is where you are testing the 1M keys ?
<lifeless> jam: yeah, I have it in btree-plain now
<jam> and if there is memory fragmentation, it is *possible* for it still to die if array's require contiguous memory
<lifeless> jam: it was something about number pof parameters to a method I think
<lifeless> jam: its 2.9M keys btw
<lifeless> jam: look in ~robertc/megarepo/.bzr/repository/indices :)
<jam> lifeless: we seem to have a 16GB pack file in there. I'm kind of happy to see that we support >4GB files :)
<jam> though I wonder if we *really* want to :)
<lifeless> jam: yes, otherwise latency++++
<jelmer> Odd_Bloke: Ah, cool - how far are you from Wolverhampton?
<jam> lifeless: so that is just an aggregate repo of a bunch of different projects, right?
<lifeless> jam: oh, it was 2.5 that blew up
<lifeless>     selected = min(candidates, key=getter)
<lifeless> TypeError: min() takes no keyword arguments
<lifeless> thats on 2.4
<Odd_Bloke> jelmer: About an hour by train.
<lifeless> jam: getting content out:
<lifeless> time python2.5 bzr/bzr branch megarepo/pool/main/libj/libjpeg6b/
<lifeless> real    0m5.365s
<lifeless> then
<lifeless> real    0m1.380s
<lifeless> real    0m2.433s
<lifeless> (the machine is being hammered right now :))
<jam> lifeless: well, the 1.8G resident is a bit of an issue
<lifeless> jam: thats the bzr search task
<lifeless> jam: which is using GraphIndex still (see the 4K page thing I mentioned :))
<jam> james_w: by the way, thanks a *ton* for doing all the work you've been doing on managing the bug tracker, it is really nice to have someone on top of it
<james_w> no problem, I think there's quite a bit more to do to get importance/status assigned.
<lifeless> mtaylor: ping
<mtaylor> lifeless: pong
<lifeless> mtaylor: you were working on server-side email right?
<mtaylor> lifeless: was looking at it
<lifeless> mtaylor: the savannah folk are looking for that : if you could put your branch up that would rock :)
<mtaylor> lifeless: I settled on a modification of bzr-email though
<mtaylor> lifeless: so I have nothing for them :(
<lifeless> oh
<lifeless> nuts :)
<mtaylor> yeah
<mtaylor> sorry
<lifeless> is your modifcation general purpose? you could put it up anyhow :)
<Odd_Bloke> jelmer, lifeless: I'm going out for the evening, let me know if anything transpires sprint-wise and I'll respond when I get back. :)
<lifeless> Odd_Bloke: its up to jelmer really :)
<Odd_Bloke> jelmer: Let me know. :)
<agoebel> is there a way to have the webdav plugin handle authentication?
<abentley> lifeless: ping
<vila> agoebel: the webdav plugin handles authentication by relying on bzr http client implementation handling authentication :)
 * vila ducks
<agoebel> in which case why am I getting a "can't handle 401 auth required" response?
<vila> either because you didn't specify user in url (http://user@host) or your password is wrong
<agoebel> ah, missed the user
<agoebel> figured it would give my a prompt
<agoebel> thanks
<vila> alternatively you can also use authentication.conf to provide user and/or password
<LarstiQ> having it prompt would be real nice
<vila> bug already filed (can't remember it right now, and I'm gone anyway :)
<jelmer> Odd_Bloke, will do
<dato> lifeless: pong
<jelmer> lifeless, ping
<colbrac> jelmer: Currently from olive pressing the push button in the push dialog succesfully pushes, but also gives a bzr-gtk error 'int argument required'
<colbrac> jelmer: Any clue?
<jelmer> colbrac: bzr-gtk probably expects the push function to return an integer
<jelmer> whereas it returns an object these days
<jelmer> PushResult I think
<jelmer> See bzrlib.branch.Branch.push
<colbrac> I see a 'rev = 0' a few lines higher yes
<colbrac> where later try: rev = dopush()
<jelmer> right, rev would actually be a PushResult object rather than the number of revisions pushed
<colbrac> so, in the final lines of that method an info dialog is made with revs as the number of revs pushed
<colbrac> how can I get that number from PushResult?
<colbrac> (if you happen to know by heart) :)
<colbrac> jelmer: The push you are pointing at says 'raise NotImplementedError(self.push)'
<colbrac> :P
<jelmer> colbrac: Well, that should have the API description
<jelmer> See bzrlib.branch.PushResult for the object that's returned by push()
<colbrac> hmm.. has deprecated all over it.. but should return the revno on initiation.. :/ Maybe not initiated anymore in bzr trunk?
<jelmer> I don't see any deprecated stuff there
<jelmer> what in particular are you referring to?
<colbrac> I'm looking in bzr/trunk/bzrlib/branch.py line 2230: class PushResult
<colbrac> But on a closer look of bzr-gtk/trunk/push.py, I don't see any bzrlib.branch imports
<colbrac> bzr trunk as of yesterday
<colbrac> bzr-gtk rev 531
<jelmer> colbrac: that's because it already has a branch instance
<jelmer> that gets passed to it
<jelmer> there's no need for imports
<colbrac> so.. if I read that do_push function correctly, the count var that is returned is not set when a correct branch_to location is given from the start?
<colbrac> which explains the lack of an int
<colbrac> jelmer: The count var is not set in do_push when the first try is succesfull
<colbrac> jelmer: push to '../folder-that-didnt-exist' doesn't give the error, and a PushResult is returned
<jelmer> colbrac: it is, see the "else:" clause
<jelmer> the problem is the fact that br_to.pull() no longer returns an integer
<colbrac> but check.. it does br_to.pull
<colbrac> I saw
<jelmer> Odd_Bloke,lifeless: I'll arrive on wednesday in London
<jelmer> colbrac: Yeah, that's correct
<lifeless> dato: I wanted to chat with you about the use of the index in git and what we might do similarly
<lifeless> dato: but its way late for me now; perhaps tmorrow?
<lifeless> night all
<beuno> g'night lifeless
<dato> lifeless: it's late here too :)
<dato> but I'm only available evening UTC
 * ToyKeeper would love to hear about that too
<agoebel> does anyone have the trunk of bzr-gedit working with gedit 2.22.3?
#bzr 2008-07-15
<Manfre> give the following situation, I create a local branch, make changes and push those back up to lp, then some one else branches my changes and then pushing those back up to the same lp branch, how do I update my local branch without needing to do a merge?
<hmeland> bzr pull?
<jelmer> colbrac, still there?
<colbrac>  yes
<Manfre> Just tried bzr pull and got "Bazaar has encountered an internal error"
<Manfre> i guess i'll use the work around of delete local branch and rebranch
<bob2> well, that's a bug (or corruption), but bzr pull is generally what you want
<colbrac> jelmer: ja
<Odd_Bloke> Manfre: Could you pastebin the error, please?
<Odd_Bloke> ubottu: 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)
<jelmer> colbrac: Just wanted to say thanks for the patches to bzr-gtk you sent over the last week or so.
<colbrac> :) No problem
<jelmer> colbrac: I'll see if I can review and merge some of them during the next couple of days
<colbrac> It's kind of 'wetting my feet' in the world of gtk programming
<jelmer> Ah :-)
<colbrac> start with the launch fix :)
<Manfre> Odd_bloke: http://pastebin.com/d54356310
<Manfre> sorry, it was the bzr status call after the pull that caused problems
<Manfre> ...potentially
<colbrac> jelmer: and I try to use Olive in 'production'.. so deficiencies stand out :)
<Odd_Bloke> Manfre: That error looks familiar.  I'm fairly sure it's been fixed in bzr.dev...
<bob2> #235657
<jelmer> colbrac: Yeah, that helps
<jelmer> colbrac: Personally, I try to use nautilus-bzr on a regular basis
<bob2> though, you seemed to have pulled and merged the same branch - maybe undoing the merge will unconfuse bzr
<Odd_Bloke> Manfre: http://bugs.launchpad.net/bzr/+bug/235407
<ubottu> Launchpad bug 235407 in bzr "'pop(): dictionary is empty' in tsort when showing pending merges" [High,Fix released]
<colbrac> jelmer: Good for you guys I didn't try to use nautilus-bzr yet. ;)
<jelmer> (-:
<colbrac> jelmer: I started on a pure PyGTK version of the olive gui.. I hope that sounds interesting?
<jelmer> colbrac, what do you mean by that exactly?
<colbrac> a OliveGui class that builds the main window instead of the glade one
<Manfre> thanks Odd_bloke
<colbrac> so self.vbox.add(menubar) etc
<colbrac> :P
<Odd_Bloke> Manfre: No problem.
<jelmer> colbrac: Ahh, yeah, that is certainly interesting
<colbrac> lp:~colbrac/bzr-gtk/noglade
<colbrac> still very rough of course etc etc
<jelmer> colbrac: Submitting that in small (but still usable) portions will probably help it being merged quickly, rather than a single big patch
<colbrac> well..
<colbrac> I can make it such that it can be a drop in replacement of the glade one
<colbrac> I think at least :P
<ToyKeeper> If my viz changes are accepted, that scratches most of my bzr gui itches.  :)
<colbrac> ToyKeeper: Did you play around with the diff positioning?
<colbrac> The unsorted bookmarks were a big itch for me personally. :)
<ToyKeeper> Yeah, I haven't been able to find a layout I like better.
<ToyKeeper> The main change I'd still like to see is a way to view all branches in a repo at once, using viz.
<colbrac> jelmer: I don't really know how a full GUI can be merged in in bits..
<jelmer> colbrac, there are different windows in olive for example
<colbrac> oh that..
<jelmer> it makes sense to convert one window at a time
<colbrac> I did that
<jelmer> and merge that separately
<colbrac> it's 1 big patch but with commits per dialog
<jelmer> I agree the main window is probably pretty hard to convert in stages
<Odd_Bloke> ToyKeeper: +1 on the all branches view.
<colbrac> most of the dialogs are done already
<colbrac> only that info dialog looks hard so I didn't try it yet
<colbrac> The olive dialogs cleanup -take3 message in the bzr-gtk list
<jelmer> Odd_Bloke, still there?
<colbrac> jelmer: I now have all widgets of the glade olive main window in a OliveGui class. Only to paste in the right signals and figure out how to properly reference the icons :)
<Odd_Bloke> jelmer: Yeah, though I suspect you may be gone by now. :)
<Odd_Bloke> jelmer: Now I'm going to bed, so it'll have to wait until the morning.
<mwhudson> is bzr really going to be released with a repo format called
<mwhudson> 'Bazaar development format 1 with subtree support (needs bzr.dev from before 1.6)\n'
<mwhudson> ?
<abentley> mwhudson: I hope not.
<mwhudson> abentley: good good
 * igc lunch
<brmassa> guys, is there a program that tracks a CVS repo and imports the changes to bzr and the other way round?
<mwhudson> cvs->bzr yes
<mwhudson> not the other way
<fullermd> Going either way is probably doable.  Both at the same time is another story.
<brmassa> mwhudson: so its not possible to commit to a bazaar branch and it replicates/pings the CVS?
<AfC> You can always do the "Create a Bazaar branch inside the CVS checkout and manually shuttle changes back and forth between the two systems"
<AfC> Manual
<brmassa> AfC: hmmm not quite what i had in mind. well... np them.
 * mwhudson waves https://bugs.edge.launchpad.net/bzr/+bug/248604 around
<ubottu> Launchpad bug 248604 in bzr "locking repository makes no difference to speed of repeated get_revision calls" [Undecided,New]
<stewart> hi! i'm trying to "bzr merge" from a file that contains a merge directive - and i get  "bzr: ERROR: bzrlib.errors.NoSuchRevision: KnitPackRepository('file:///home/stewart/mysql/.bzr/repository/') has no revision ('volpato@cajarana-20080715052545-2fu5im6ll8o2jr6x',)"
<stewart> now... does this mean the merge directive is incomplete, corrupt? against a tree i don't have?
<stewart> or a bzr bug
<lifeless> stewart: it means it was made against a rev you don't have - probably something in the 6.0 trunk to some such
<stewart> lifeless: ahh.. okay. the error message could probably be nicer (or at least on the same screen :)
<stewart> it's like 3 pages of python backtrace up
<lifeless> stewart: ouch; cxare to file a bug ?
<stewart> can do
 * stewart field bug... waits for magic irc bot to say it's done
<igc> night all
<gour> igc: night
<lifeless> poolie: ping
<Odd_Bloke> Moin.
<kiorky> hello, with bzr svn, is this possible to use local svn check outs as a start ?
<lifeless> kiorky: yes
<kiorky> lifeless: do you have any clue or pointer on how to do that?
<lifeless> kiorky: cd to the checkout, start running bzr commands
 * AfC does that rather frequently, not always wanting to import everything and therefore not needing to use bzr-svn et al
<kiorky> then how can i map the svn/bzr thing for commiting back to the svn repo?
<kiorky> when i commit on bzr
<kiorky> s/commit/push/
<lifeless> kiorky: 'bzr checkout svn://url FOO; cd FOO; bzr merge BZRBRANCH; bzr commit'
<lifeless> kiorky: (you need a bzr native tree to do merges in (as far as I  know, jelmer may know more)
<kiorky> lifeless: ha, i dont know if i was clear on what i wanted to do. I have a svn co somewhere , telling its in "foo", but not yet bzr stuff. Rather than doing bzr co svn://myuri FOO, i want to use bzr inside the svn's foo one directly, saving me from co-time as i have it allready
<lifeless> kiorky: you can do that, but as far as I know you can't run one specific bzr command - merge - because svn checkouts don't have a place to store pending merge data
<kiorky> lifeless: so the only way to go is to co again?
<lifeless> kiorky: yes. but once you have done that you can branch locally from it and it won't have to fetch it over the network again
<Odd_Bloke> ubottu: 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)
<lifeless> Odd_Bloke: ?
<Odd_Bloke> lifeless: I was going to paste something, then changed my mind. :)
<lifeless> Odd_Bloke: :)
<jelmer> 'morning
<lifeless> jelmer: can you bzr merge in a svn co?
<jelmer> lifeless, no, since there
<jelmer> *since it's not possible for merge to pull revisions into the local repository
<jelmer> Odd_Bloke, still there?
<lifeless> jelmer: righto
<lifeless> jelmer: could create a pending-merge micro-repo :)
<jelmer> lifeless, yes, but that requires me to detect how the repo is being used
<Odd_Bloke> jelmer: Yup.
<lifeless> jelmer: I mean in e.g. .svn/pending-merges-repo
<abentley> lifeless: did you see bug 248506?
<ubottu> Launchpad bug 248506 in bzr "stacked fetch fails to copy required revisions" [Critical,Confirmed] https://launchpad.net/bugs/248506
<lifeless> abentley: no I hadn't
<abentley> I tried to figure out the exact issue, but I got a little lost.  Can Packer use a fallback repository?
<kiorky> jelmer: uhm i get problems
<kiorky> jelmer: ImportError: cannot import name make_file_factory
<kiorky> jelmer: with svn 1.5, and its binding, bzr1.6 or 1.5 and the stable branch
<lifeless> abentley: no, what I was thinking was to use the generic VF implementation when pulling into a stacked environment; it should perform m~= these days
<kiorky> jelmer: (when doing bzr svn-import URI)
<abentley> lifeless: The current implementation is using Packer for fetch, so that appears to be why it's failing.
<kiorky> jelmer: http://www.friendpaste.com/SLCdppAS
<lifeless> abentley: I suggest doing a check that neither source nor target have fallback repos in the interpackrepo thing
<kiorky> lifeless: do you have any idea on my import problem? ABI changed ?
<lifeless> kiorky: svn wbzr-svn head needs bzr.dev head
<kiorky> lifeless: Ha ok :)
<kiorky> lifeless: there is no way to have svn integration with stable releases ? (even with previous version or bzr svn)
<lifeless> kiorky: yes, but you can't use the head of the branch, you need some commits back; jelmer: ^^
<lifeless> kiorky: (I really want bzr-svn in the ppa to address this, its being discussed on list at the moment)
<kiorky> lifeless: another thing im now using bzr head
<kiorky> lifeless: but now i cant authenticate with the svn repo
<kiorky> it just fails :p
<lifeless> kiorky: if you are using bzr head, then bzr-svn head should work - but you'll need to run make in the bzr-svn dir
<kiorky> lifeless: i mean there is maybe some configuration spoemwhere to get the crendentials info?
<kiorky> lifeless: yep, that what i had done
<kiorky> now, on import, i cant authenticate :)
<kiorky> lifeless: jelmer uhm, i dont suceed in making bzr svn-import run
<kiorky> either i get authenticate problems, or when i put the creds in the url i get : "RROR: Not a branch:"
<kiorky> even on non auth'd enabled servers
<kiorky> (i tried to co the svn repo)
<lifeless> kiorky: hi, have you checked the FAQ?
<Necoro> hey - I've a project - and I deleted a file about 100revs ago.
<Necoro> Is there a way to get it back, w/o having to scan through history manually looking for the revision where I deleted it?
<LeoNerd> Maybe  bzr log path/to/file  will find you the commit where you removed it?
<Necoro> nope
<pygi> Necoro, "bzr revert file" might work
<pygi> not 100% sure tho
<Necoro> pygi: bzr: ERROR: Path(s) are not versioned =/
<pygi> eh, yes, that's only for non-commited stuff
 * pygi thinks
<Necoro> hmm ... ok ... "bzr diff -r1.." at least gives me the date where I deleted it =)
<Necoro> hmm ... no
<pygi> Necoro, bzr revert -r123 some_file should actually do the trick
<fullermd> You need to "revert -r<rev_before_deleted>" to bring it back.
<pygi> as long as you know the revision
<Necoro> but I do not know the revision ;) - that's the problem
<fullermd> But there's no way to find the rev other than "log -v | less ; <search for filename>
<Necoro> I just could use "-r1" but don't know I changed something in between -r1 and -r$deleted
<bob2> bzr log should be ablt to take a file id
<Odd_Bloke> Necoro: You could use the bisect plugin.
<lifeless> Necoro: bzr revert -r -100 FOO
<lifeless> Necoro: or bzr log -v | less, then /filename
<Necoro> lifeless: the latter one works :) - though it isn't as automagic as I thought ;)
<Odd_Bloke> Necoro: If you branch http://bzr.daniel-watkins.co.uk/bisect/automated/ into ~/.plugins/bisect and then do 'bzr bisect run stat <filename>'.
<Necoro> Odd_Bloke: can't branch from inside the company (damn proxy/firewall -.-) ... is there a difference to the lp:bzr-bisect ?
<Odd_Bloke> Necoro: Yeah, there is.  Would it help if I pushed it to LP?
<Necoro> yes - this would be really helpful - because from LP i can branch using bzr+ssh - so there is no HTTP-Proxy in the way doing stupid things :)
<Odd_Bloke> Necoro: https://code.launchpad.net/~daniel-thewatkins/bzr-bisect/automated
<awilkins> Yegods, my sysadmins are morons.
<awilkins> "Hey, poke a hole in the firewall to let SSH in or I'll have to set up a relatively insecure WSGI gateway app"
<awilkins> "I'm sorry, we can't do that for security reasons"Â£
 * awilkins slaps forehead
<_paneb> is there a way to see the parent of a branch?
<_paneb> (i am about to do bzr merge)
<Necoro> Odd_Bloke: thanks - branching worked ;) - but running the command yields: http://rafb.net/p/ZDDJkI98.html
<Necoro> or do I have to do certain things before I'm able to run it?
<bob2> _paneb: bzr info?
<_paneb> ok
<Necoro> and btw:  bzr bisect deletes uncommitted changes w/o notice ;)
<awilkins> Necoro: That's a bug ; needs reporting
<Odd_Bloke> Necoro: Apologies, I didn't realise.
<Necoro> Odd_Bloke: no problem - nothing lost which can't be reproduced using zsh history ^^
<Odd_Bloke> And I probably meant 'bzr bisect run "stat <filename"'.
<Odd_Bloke> Necoro: ^
<Necoro> Odd_Bloke:  http://rafb.net/p/Q9POdw13.html ... still not works
<Necoro> oh - wrong paste
<Necoro> that's the one -> http://rafb.net/p/MrtUS580.html
<Odd_Bloke> Necoro: OK, you actually want the opposite of what stat does.  I'm not sure of the best way to do that.
<Odd_Bloke> Necoro: Try 'bzr bisect run "test ! -e <filename>"'.
<Necoro> Odd_Bloke: wohoo :) works
<Odd_Bloke> \o/
<Necoro> thanks a lot :)
<Odd_Bloke> Necoro: No worries.  It's nice to finally have a real-life use case for that stuff. :)
<Necoro> hehe =D
<Necoro> do you think it is possible to put this in one command? - so like: bzr undelete <filename> ?
<Odd_Bloke> Necoro: I would imagine that'd be possible in a plugin, but I'm not sure if it's a common-enough use case for much more than that...
<lifeless> Necoro: I think we should make getting at the file more easy
<lifeless> Necoro: 'bzr revert -r xxx foo' *is* undelete already
<lifeless> Necoro: so, I think a mode to revert to search for a file, or some means to search for it would bbe sufficient
 * pygi thinks that might be god way to contribute something :)
 * fullermd imagines "bzr path-history <path>"...
<lifeless> fullermd: bzr search path
<Necoro> lifeless: that's true -- but plugins aren't able to overload existing commands, are they?
<LarstiQ> Necoro: they are
<Necoro> ok :)
<LarstiQ> Necoro: but that can be problematic if you have more than one plugin trying to override the default
<awilkins> I think some of the builtins could stand being refactored into multiple routines that you could overload in plugins
<awilkins> Or even provide extension points for them
<lifeless> awilkins: indeed
<Peng> Getting information for AnnotateUI: 118.64552807807922 secs :D
<Peng> Hmm, how do you do a graceful shutdown of Loggerhead?
<Peng> I managed to shut it down in the middle of a request.
<lifeless> Peng: no idea sorry
<awilkins> Can bzr+http:// do certificate authentication?
<Peng> My question is probably more of a Paste question anyway.
<lifeless> awilkins: vila: knows
<lifeless> vila: do we have docs for easy answers on this
<Peng> I hit Ctrl+C, and it did a mostly graceful shutdown: that 118 seconds request actually completed several seconds after all of the other worker threads had been shut down. But then the web server log reports a second request came in at the same time and got dropped on the floor.
<uws> Hmm. bzr just ate ALL my RAM
<uws> almost all 1280 MB of it
<awilkins> I should learn to open my beak less on the "security" issue
<vila> no, but hopefully I will address that soon (when I get back from vacations in 3 1/2 weeks :)
<awilkins> vila: Can it do digest?
<Peng> Is Python's SSL support smart enough to do that?
<vila> awilkins: if you use the pycurl http implementation it will verify certificates
<awilkins> vila: Server, yes, client also?
<vila> awilkins: digest is supported
<vila> awilkins: client certificates ? No. But I'd like to add that too once urllib https implementation knows how to do server certificate verification (including option for self-certified)
<awilkins> Ok then, guess I'm going with digest for the time being :-)
<uws> jelmer: bzr-svn eats all my memory
<Peng> uws: What version?
<uws> jelmer: Can I convert a large SVN repo to bzr+svn stuff in chunks?
<Peng> uws: Yes. I always do that.
<uws> 0.4.10
<awilkins> uws: Yes, I wrote a script to do it 1000 revs at a time
<uws> I had to hard-reset my machine
<uws> Is there a way I can "continue" the previous branching/
<uws> I'm using a repos --rich-root-pack and branched http://...../trunk into "project.trunk"
<awilkins> uws: cd project.trunk ; bzr pull http://.....trunk
<uws> webkit is quite a large project ;)
<Peng> uws: The next version of bzr-svn (possibly paired with svn 1.5) will leak a lot less.
<uws> I already run svn 1.5.0
<awilkins> uws : https://launchpad.net/projects/?text=webkit
<uws> awilkins: Hmmm. How can i branch that?
<uws> awilkins: bzr branch lp:~vcs-imports/webkit-open-source/trunk  doesn't work
<uws> awilkins: ah, it's not imported it seems https://code.launchpad.net/webkit-open-source
<awilkins> Ah well, it was a good try :-)_
<uws> so where's that rev pulling thingy?
<awilkins> uws: It's a powershell script, you probably don't want that ; it's not hard, write a loop, initialise a value with the output of bzr revno, add a few hundred, and pull up to that value.
<uws> awilkins: this'll do for now hopefull:      for revno in $(seq 100 1000 35000 ); do bzr pull --verbose svn+http://svn.webkit.org/repository/webkit/trunk -r $revno; done
<Odd_Bloke> jelmer: When are you going to be arriving on Wednesday?
<andresj> hey how do I get the latest bzr-svn for Ubuntu? The currently available is bzr-svn0.4.9, and its not compatible with bzr1.5... Can anybody add it to the PPA?
<ToyKeeper> andresj: I know this isn't the greatest answer, but you could branch the latest versions from launchpad and use bzr.dev.
<andresj> ToyKeeper: I don't really know what you mean. :P
<ToyKeeper> Basically, you could install from source instead of a .deb.  But I don't know enough about your situation to know if this is appropriate.
<andresj> ToyKeeper: oh well I guess I could do that... but is there really no bzr-svn package available?
<ToyKeeper> There may be a newer one in debian/testing or debian/unstable, and possibly in a PPA.
<ToyKeeper> I just havent looked, since I want the latest bzr.dev to make patches against.  It's easier for me to 'bzr pull' updates than install packages.
<andresj> oh haha ok :) no i dont develop bzr :P   well I guess i'll keep looking or if not install from source. thanks ToyKeeper :)
<ToyKeeper> andresj: If you decide to go that way, the "Run from source directory" section here may help: http://bazaar-vcs.org/InstallationFaq
<andresj> ToyKeeper: allright thanks I'll check it out :)
<ToyKeeper> You can run bzr.dev and every plugin (that I've tried) from source dirs, without needing to actually install them.  Just add a symlink and it's done.
<lifeless> andresj: we're working on the PPA; the list has the current status
<andresj> lifeless: oh cool where is the list? :)
<andresj> ToyKeeper: oh wow thats cool this is one of the few programs that can do that in my expierence :D
<ToyKeeper> In some cases, running "make" is also required.  (including bzr-svn)  And you'll of course need to provide any dependencies.
<andresj> of course :)
<lakshmanan> ï»¿i have a problem with bazaar while pushing my changes to the launchpad branch.... thisis the error message   bzr: ERROR: Transport operation not possible: http does not support mkdir()
<lakshmanan> ï»¿i have a problem with bazaar while pushing my changes to the launchpad branch.... thisis the error message   bzr: ERROR: Transport operation not possible: http does not support mkdir()
<beuno> lakshmanan, have you done:  bzr launchpad-login your_username?
<lakshmanan> but the error messge is somthing different...
<beuno> lakshmanan, yes, that error message is because you're trying to push through http
<lakshmanan> ok.. so what should i do
<beuno> you're probablt using lp:location
<beuno> lakshmanan, what's your username in Launchpad?
<lakshmanan> i enter an email id to login my account
<beuno> lakshmanan, right, but you should also have a username
<lakshmanan> there are two names.. that i have given.. one is display name ->lakshmanan and the other is just a name(as i see in my 'change details' page) -> lak89
<beuno> lakshmanan, is this you?  https://launchpad.net/~lak89
<lakshmanan> yes
<beuno> if it is, then, run:  bzr launchpad-login lak89
<beuno> what exact command are you using to push?
<lakshmanan> i use bzr push <branch location>
<luks> <branch location> is the important part you should paste :)
<lakshmanan> beuno, i ran bzr launchpad-login lak89.... it didn't say anythng... my prompt came back
<lakshmanan> beuno, i did paste the branch location correctly
<beuno> lakshmanan, ok, try pushing now
<lakshmanan> beuno,  i did it... it said this "The authenticity of host 'bazaar.launchpad.net (91.189.94.254)' can't be established. Are you sure you want to continue connecting (yes/no)?
<lakshmanan> "
<beuno> lakshmanan, say yes  :)
<lakshmanan> beuno, bzr: ERROR: Target directory lp:~lak89/getedit/mine already exists, but does not have a valid .bzr directory. Supply --use-existing-dir to push there anyway.
<lakshmanan> .............this is what it is saying
<beuno> lakshmanan, right, do:   bzr push lp:~lak89/getedit/mine --use-existing-dir
<beuno> this won't happen from now on, because you've specified your launchpad ID
<lakshmanan> beuno, what is the correct way of pushn to a branch.. is this so tedious like this everytime
<beuno> lakshmanan, no, again, this happened now because you didn't have your launchpad ID set
<beuno> from now on, it's just:  bzr push [location]
<lakshmanan> beuno, that is if i use that directory for all the puch operations... what if i move to another directory, initialize bzr and push from there ??
<beuno> lakshmanan, this is system-wide
<beuno> so it will just be push
<beuno> this is a one time thing you have to do
<beuno> to use   lp:location   URLs
<beuno> having your username set, it uses ssh instead of http, so it can perform write operations
<lakshmanan> beuno, ok .. actually what went wrong in my steps... what did/might have do/done wrong in my previous attempts...if any... what should i do from now on
<beuno> lakshmanan, from now on, just use:  bzr push location
<lakshmanan> beuno, ok... but everytime.. i restart... should i set this username thing
<beuno> you didn't have launchpad-login specified, and you had already tried to push via http, which creates an empty dir (it's a bug in Launchpad), so you have to specify the --use-existing-dir flag
<beuno> lakshmanan, you will have to specify that again if you reinstall, or use it from a different user on the system
<lakshmanan> ok
<lakshmanan> brb.. thanks
<beuno> welcome'
<Kinnison> lifeless: that compression stuff looks very interesting
<lifeless> Kinnison: :)
<lifeless> Kinnison: play!
<Peng> Is it just me, or is the lp branch "pybloom", not "bzr-pybloom"?
<Kinnison> lifeless: tempting, but I'm busy writing READMEs and tests for my templating library
<dash> what's the current state of bzr-svn? anybody know if bzr-svn 0.4.10 has problems with svn 1.5?
<dash> looks like current bzr-svn requires current bzr as well
<Peng> Uh, there's an svn 1.5 compatibility branch.
<Peng> I don't know much else though.
<Peng> And yes, bzr-svn's 0.4 branch requires bzr.dev.
<Verterok> dash: are you usign bzr-svn from source?
<dash> Verterok: was trying to :)
<Verterok> in that case I think you need install the subversion-dev package from your distro
<dash> yep, got that
<dash> getting an error from libsvn though
<Verterok> dash: bzr-svn now provide it's own python bindings to subversion
<Verterok> so you need to compile them against your installed subversion
<dash> Verterok: even 0.4.10?
<Verterok> dash: I don't know, let me check
<dash> because i'm not seeing any C files in there
<dash> specifically, attempting to branch from an svn url gets me this:
<dash> python: /build/buildd/subversion-1.5.0dfsg1/subversion/libsvn_ra/ra_loader.c:973: svn_ra_get_log: `Assertion *path != '/'' failed.
<Verterok> dash: I encountered a similar error while trying to build it for Mac OS X
<Verterok> dash: are  you building subversion-1.5 from sources?
<dash> no
<dash> using the package in intrepid
<Verterok> dash: I think that error is caused by a minor version number in the subverison build
<dash> yeah apparently the api changed in 1.5
<dash> guess i'll downgrade
<Verterok> dash: bzr-svn branch (0.4) contains the c files
<Verterok> dash: https://code.launchpad.net/~jelmer/bzr-svn/0.4
<dash> yeah I just tried that
<dash> it doesn't work with bzr 1.5 though :)
<Verterok> dash: time to fill a bug them :)
<dash> Verterok: why's that? Peng just said it depends on bzr.dev
<Verterok> oh, sorry I missed that
<Verterok> dash: I assumed svn-1.5 :P
<Peng> Well, I mean, I don't know if it's intentional, but it's the case at the moment.
<dash> bzr 1.6 will be along soon enough
<dash> I can deal with bzr-svn 0.4.10 until then. :)
<dash> hm. so bzr has the idea of a branch attribute called the 'submit branch'. for a workflow that creates branches for specific features/issues, do I understand it correctly to be "the branch this one should be merged into, once it's done"?
<pickscrape> Hi, are there any good instructions out there for building debian/ubuntu packages for bzr plugins?
<pygi> so folks, welome cheezeburger :)
<pygi> a bzr repositories serving tool :)
 * pickscrape pricks his ears up
<pickscrape> Read-only serving or read/write?
<matkor> Does making bzr checkout <remote_branch> downloads full diff history ?
<dash> matkor: yes. "bzr checkout --lightweight" does not.
<matkor> ok.. is it possible to "cut down" given branch history ? Let's I am only interested to have hisory since given revision (make given revision first one) ?
<dash> matkor: 1.6 is going to allow something like that, I believe
<dash> 'stacked branches'
<pygi> pickscrape, read-write
<pygi> pickscrape, it allows easily setting up bzr repositories and access management to them
<pickscrape> pygi: does it use the smart server?
<pygi> probably yes, still gotta see =)
<pygi> it's just an idea I got today, and registered a project
<pickscrape> pygi: Then it sounds very interesting indeed.
<pickscrape> pygi: I'll watch your project with great interest :)
<pygi> :)
<pickscrape> Sorry to ask again, but can someone point me at some docs on packaging bzr plugins for debian/ubuntu?
<pygi> hmmm
<pygi> here's an idea
<pygi> apt-get source bla-package
<pygi> where bla-package is some bzr plugin, and you can see how it's done
<pygi> then if you have any questions, I can probably help
<asabil> pygi: where is the code for cheeseburger ?
<asabil> :D
<pygi> asabil, cheezeburger* :)
<pygi> asabil, in my head, does that work for you? xD
<asabil> lol
<pickscrape> I'm looking in bzr-svn's checkout now, but don't see anything to do with packaging (I'm not at all familiar with debian packages so I really don't know what I'm looking for)
<asabil> sorry, cheezeburger
<pygi> pickscrape, debian directory
<dash> pickscrape: it wouldn't be in the checkout, i bet
<chx> heya. here is a challenge. i would like to put my daily database dumps into some RCS. the file is like 10G. Also, I wonder whether there is a way to throw away old revisions after some time
<pickscrape> Yeah, there isn't a debian directory here
<asabil> pygi: looking forward to see the real thing
<dash> pickscrape: that stuff is usually kept as a patch
<pygi> asabil, :)
<dash> pickscrape: apt-get source will fetch it
<pickscrape> dash: thanks, I'll try that out
<dash> chx: if you're just versioning a single blob, maybe xdelta or git would serve you better
<pygi> chx, ehm, that's not so nice, but ...
<chx> not a blob. text file.
<chx> i have a LOT of data.
<chx> and then some.
<pygi> a blob actually is any file :P
<chx> okay, okay
<dash> chx: question is, what operations do you want to perform
<chx> in databases blob is a binary large object ;)
<chx> dash: commit
<dash> chx: is that all? :)
<chx> dash: when the database server dies under every other blue moon , checkout.
<pickscrape> dash: thanks, that has revealed it :)
<dash> chx: i'd just keep a list of diffs
<pygi> asabil, do you have a use case? :)
<chx> dash: yes. that's all. and, sometimes it'd be great to throw out old stuff.
<dash> chx: yep. you want a backup system, not an RCS :)
<chx> well, no
<asabil> pygi: it's about hosting/managing/serving bzr branches right ?
<chx> An RCS sounds to me like the ideal stuff for this
<pygi> asabil, yup
<chx> after all
<chx> i have a file that grows.
<chx> and, if we have the dump in an RCS who knows what useful things we can do?
<chx> tag it before a big rollout?
<dash> chx: RCSes have to support a lot more operations
<chx> why not.
<dash> chx: like, not forgetting history :)
<chx> dash: I ... know.
<asabil> pygi: something like launchpad's bzr support would be just awesome
<chx> dash: i know.
<chx> dash: i was wondering whether graft would be useable here.. just wondering.
<pygi> asabil, it's not any kind of UI, rather just a server side tool
<pygi> you got that part, right? :)
<asabil> pygi: I would want both :p
<pickscrape> pygi: so in a very loose sense, it's like a bzr equivalent of svnserve?
<pygi> asabil, I agree, but for UI stuff I need help :P
<pygi> pickscrape, ehm, it's something similar to gitosis if you're familiar with it?
<asabil> =_=
<pickscrape> pygi: I'm not actually. Gave up on git when my head started to melt, came here and haven't really looked back
<pickscrape> I'll read up on it though
<pygi> pickscrape, lemme get a link for you
<pygi> http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way
<chx> dash: xdelta...?
<pygi> asabil, if you wanna help tho ... :)
<asabil> pygi: just design it so that a UI can be added on top
<asabil> pygi: I am afraid am really not skilled with UIs
<dash> chx: never mind, thought it was a binary
<chx> no, no
<chx> just a "small" textfiel
<chx> that gives me a ton of headaches
<pygi> asabil, ofcourse, didn't thought of doing it any other way :)
 * pygi goes back to writing some git stuff
<tca> I'm running bzr selftest after I added a small patch for a ghost revision problem. How should I know if any of the test breakages are caused by my patch? Run selftest before and after and compare broken tests?
<mwhudson> well, 'the tests always pass on trunk'
<mwhudson> so if you're seeing failing tests, it's very very likely you introduced them
<mwhudson> but i guess running in a pristine bzr.dev branch first would be good to confirm this
 * luks would change that to 'the tests usually pass on ubuntu/linux machines'
<luks> (with en_* locale)
<mwhudson> well, yes
<Odd_Bloke> pygi: What do you envisage cheezeburger doing?  And shouldn't it be 'cheezburger'?
<colbrac> anybody an idea how to set an icon on a gtk.Window so that it shows up as a big icon in the app switcher (alt-tab)
<colbrac> or is this something missing in pygtk?
<luks> colbrac: http://www.pygtk.org/docs/pygtk/class-gtkwindow.html#method-gtkwindow--set-icon-list ?
<pygi> Odd_Bloke, possible, yes, I messed it up :P
<jam> luks: and --no-plugins
<colbrac> luks: thanks, I've been looking all over that page but this seems worth a try
<pygi> Odd_Bloke, well, keeping ssh keys for people who have commit access to some repo, managing access to repos, coordinating with some web interface for bzr repos, and stuff
<colbrac> woohoo! That worked :) Olive now has an icon in the switcher :D
<Odd_Bloke> pygi: Do you mean repos or branches?
<pygi> Odd_Bloke, ehm, well, branches
<f0ghorn> anyone have thoughts on https://bugs.launchpad.net/bzr-svn/+bug/248289 ?
<ubottu> Launchpad bug 248289 in bzr-svn "concurrent access problems" [Undecided,New]
<Odd_Bloke> jelmer: ^
<igc> igc
<igc> morning
#bzr 2008-07-16
<Verterok> g'morning igc
<thumper> morning
<thumper> can I branch into the current directory?
<thumper> for example:
<thumper> on a server I have a directory which I have rights to
<thumper> but the directory above is root only
<thumper> in that directory I want to get the contents of a bzr branch
<thumper> which was created elsewhere
<mwhudson> bzr init, bzr pull
<mwhudson> will probably work
<thumper> mwhudson: ok, will try
<mwhudson> (means you have to get the format right though)
<thumper> sweet
<thumper> works
<thumper> ta
<mwhudson> which, given sikrit insider infomation, probably means bzr init --rich-root-pack
<thumper> it isn't
<mwhudson> ok :)
<thumper> but thanks anyway
<igc> morning Verterok, how are you?
<beuno> thumper, hi!   kick-ass blog post, btw  :)
<Verterok> igc:
<Verterok> I'm fine, thank you. although a bit busy (hoping to have some free time)
<igc> busy is better than bored I always say :-)
<Verterok> igc: good point :)
<beuno> igc, and how are you?
<Verterok> beuno: hi
<igc> beuno: hi. Quite sleepy these days. The pain killers I'm on have that effect.
<igc> otherwise, just taking each day at a time right now
<beuno> igc, you don't seem that sleepy if I look at your work   ;)
<igc> beuno: it's nice to hear you say that. Quantity is certainly down at the moment.
<igc> I'm in week 2 of a 6 week treatment so ...
<igc> hopefully I'll feel better when it's over
<beuno> igc, I'm sure you will
<thumper> beuno: thanks, but to be honest, abentley wrote most of it
<mwhudson> hm
<mwhudson> is there some way i can create a branch with a ghost on mainline?
<mwhudson> (programming is ok)
<igc> jam: did you see my partial review? I was wondering about that change to Merge3Merger._entries3()
<bob2> lifeless: should that be 'http://bazaar.launchpad.net/~jameinel/%2Bjunk/pybloom/' (i.e. no bzr-)?
<poolie> mwhudson: um, it is possible but probably complicated
<poolie> i would start by looking for an api that will copy just one revision and not its parents
<mwhudson> poolie: ok
<mwhudson> don't push one of these branches to launchpad :)
<bob2> hm, my upgrade to --gc-plain seems to not be progressing
<bob2> hm, I lie, it is churning through it
<jam> mwhudson: I believe there is a 'allow_lefthand_ghost=True' member that you can look for
<jam> I think it is on set_parent_ids/trees
<jam> igc: I did see it, I haven't fully digested it.
<jam> I believe that True => False is *correct* though it doesn't really apply for the weave code
<jam> just something I was trying to get around to, not quite sure how it ended up here
<igc> jam: ok. IIUIC, the rest of the patch is benign, i.e. it doesn't seem to impact anything outside (re)merge --weave?
<igc> that's while I highlighted that change - it has a broader impact potentially?
<igc> s/while/why/
 * igc lunch
<thumper> is there an ETA for bzr-svn in the bzr ppa?
<bob2> 85664   backup.bzr
<bob2> 40232   .bzr/
<bob2> that is quite awesome
<jam> igc: well, when you get back from lunch, the next layer up does a "if changed" check, and filters them all out again, but I'm fine skipping it for now.
<thumper> bob2: from what to what did you upgrade?
<bob2> pack-0.92 -> bt+gc
 * mwhudson stabs non-canonical histories
<thumper> bob2: bt+gc??? I'm lost
<mwhudson> thumper: btree indexes and lifeless's groupcompression thingy
<mwhudson> (i assume)
<thumper> ah
<bob2> the pair of new formats lifeless posted to the list this morning
<lifeless> bob2: :)
<lifeless> bob2: it will be better when the fetcher knows to do inverse-topological-order
<awmcclain> Oh no. Is there any way to undo a bzr revert?
<matkor> awmcclain: bzr revert of uncommited changes ?  I think they are lost ...
<awmcclain> Boo. for that.
<awmcclain> all for doing bzr revert instead of bzr revert .
<awmcclain> not pleased with bzr right now.
<bob2> doesn't help now, but maybe aliasing 'revert' to 'shelve --all' might save you in the future?
<awmcclain> yeah... i just wanted to revert one file.
<awmcclain> so i cd'ed into the child directory
<awmcclain> but bzr revert crawled out and did the entire tree
<awmcclain> bad bzr! naughty!
<asabil> awmcclain: there are backup files
<awmcclain> oh???
<asabil> awmcclain: just check for hidden files in your folder
<awmcclain> okee doke
<asabil> (ones ending with ~)
<asabil> I think there is maybe a way to ask bzr to revert the revert :p
<asabil> but I don't know
<awmcclain> Well, I got it for the one file that really mattered... thank you!
<MvG> Hi! I'm trying to move repository data from a shared repository to a dedicated repository of a single branch. I had assumed that "reconfigure --standalone" would work for this, being the opposite of "--use-shared". However I got a IncompatibleRepositories error from current bzr.dev. Trying again informs me that the tree is already standalone. How can I tell whether the conversion worked? What is the reason for this error message?
<MvG> Steps to reproduce: bzr init-repo --rich-root-pack repo; cd repo; bzr init branch; cd branch; bzr reconfigure --standalone
<Odd_Bloke> lifeless: I'm aiming to get to Canonical's offices sometime between 1 and 2 this afternoon.  Is that OK?
<igc> lifeless: fyi, I'm benchmarking the group-compress stuff tonight on some repos to see how well it compresses them
 * igc dinner
<bob2> MvG: "bzr info" should tell you if it worked
<Stavros> hello
<Stavros> this is a bit offtopic, but i'd like to ask how you guys wrote your distutils script
<MvG> bob2: bzr info tells me it did. But I worry it might have been migrated only partially. Otherwise why the error message?
<lifeless> ogthats cool
<lifeless> igc: thanks
<lifeless> igc: it really needs a custom InterRepository to compress well
<lifeless> igc: it will get about 50% I expect from an existing repo with the current inter object
<lifeless> Odd_Bloke: thats cool
<lifeless> MvG: sounds like you've found a bug; could you please file it in launchpad ?
<MvG> lifeless: Sure.
<Odd_Bloke> lifeless: Excellent. :)  Has jelmer mentioned what time he's going to be arriving?  (SUBTLE PING :D)
<MvG> lifeless: Submitted https://bugs.launchpad.net/bzr/+bug/248932
<ubottu> Launchpad bug 248932 in bzr "reconfigure --standalone raises IncompatibleRepositories" [Undecided,New]
<lifeless> Odd_Bloke: no :)
<lifeless> mv	thanks!
<jaro> hello
<jaro> now trying migration from svn to bzr
<jaro> what tools better to use?
<jaro> bzr fast-import?
<jaro> anyone is here?
<Jc2k> hi jaro
<Jc2k> there is normally someone round who can help
<Jc2k> i only have experience with bzr-svn, which isn't really aimed at doing migration
<jaro> :/
<luks> well, bzr-svn works fine for migration
<jaro> luks: can i with bzr-svn migrate my subversion repository to bzr and i will see all changes?
<luks> jaro: yes
<jaro> how?
<jaro> May by some how to?
<jaro> link
<jaro> ?
<luks> install bzr-svn, run `bzr svn-import <SVN_URL>`
<luks> or just `bzr branch <SVN_URL_OF_TRUNK>` if you want to migrate only trunk
<luks> then you can uninstall bzr-svn and just use plain bzr
<ignas> what is the mystical "front-end" tool that is being mentioned in http://bazaar-vcs.org/BzrFastImport ?
<luks> ignas: http://bazaar-vcs.org/BzrFastImport/FrontEnds
<ignas> luks: thanks
<jaro> luks: i try bzr svn-import <URL>
<jaro> then cd <project>
<jaro> and there are no files
<jaro> :(
<luks> try `bzr info`
<jaro> Repository branch (format: rich-root-pack)
<jaro> Location:
<jaro>   shared repository: .
<jaro>   repository branch: .
<jaro> Related branches:
<luks> or are there no files or directories at all?
<jaro>   parent branch: <url>
<luks> if not, what URL did you use?
<jaro> file:///patch/to/svn/project
<luks> jaro: does the project have only a single branch? no trunk/branches/tags structure?
<jaro> yes
<luks> well, then all you need is in the directory
<lifeless> jaro: do 'bzr checkout .' and you'll get your files
<luks> you can use `bzr checkout .` to recreate the working tree if you want
<luks> :)
<jaro> but bzr checkout only get files
<jaro> But i need history
<luks> bzr log
<luks> in that directory
<ignas> or bzr vis for a nice visual history if you have gtk plugin installed
<jaro> bzr log show my history
<LarstiQ> hey ignas
<jaro> So can I delete /patch/to/svn/project ?
<ignas> LarstiQ: hi
<jaro> And how can I see my files in /patch/to/bzr/project ?
<jaro> To change them ?
<luks> jaro: it's always nice to keep backups, just in case, but yes you can
<luks> jam: bzr checkout .
<luks> jaro:
<luks> evil tab completion
<lifeless> poolie: around?
<jaro> luks: big thanx
<matkor> what is proper way of resolivng binary file confilct ? I end up with foo and foo.moved, how to choose that foo/foo.moved is correct conflcit colvation ?
<lifeless> matkor: that generally means foo and foo.moved were added independently; you should take the one that is in the branch closer to trunk
<poolie> lifeless: hi, a bit
<lifeless> poolie: can we chat about get_record_stream a bit? perhaps a quick call ?
<igc> lilfeless: so my first group-compress test is still running after 2h30minutes
<igc> I'm wondering if I'm doing the right thing?
<igc> I'm doing this ...
<igc> bzr init --gc-plain .
<LarstiQ> igc: is there a windows vm running the testsuite yet?
<igc> bzr pull ../normal-repo
<matkor> lifeless: yah, but how to say to bzr: use foo/foo.moved and forget about second one ? Deleting foo.moved and bzr resolve deos not make confilct resolved ...
<igc> lifeless: the normal repo I'm trying first is python
<igc> hi LarstiQ
<lifeless> matkor: does bzr st list foo.moved as unknown? if so, you probably just had foo.moved on local disk before the merge
<LarstiQ> igc: heya :)
<igc> LarstiQ: not to my knowledge
<LarstiQ> igc: hmmm
<lifeless> igc: yes, the fetch logic is O(n^2) at the moment
<igc> I'm pretty sure jam is running on Windows these days
<lifeless> igc: the raw compressor is better, but *shrug*
<igc> lifeless: when n = # of revisions?
<igc> s/when/where/
<igc> LarstiQ: and vila was for a while as well IIRC
<LarstiQ> igc: ok. I watched a run on markh's laptop, and it didn't look too good.
<lifeless> igc: yeah; it caps at 20MB of raw output and resets, but it will be doing 1000's of extractions
<lifeless> igc: I should have a better InterObject done today
<igc> LarstiQ: as in the test suite didn't look good? or some particular bzr operations?
<igc> lifeless: ok. VM memory use for the pull is up to 780MB fwiw
<matkor> lifeless: Is hard to say what happend becouse other person asks me to help with that ...
<lifeless> igc: mysql? ooo?
<LarstiQ> igc: test failures, including not entirely deterministic ones related to test cleanup
<igc> lilfeless: I'm planning to do those tonight but I was waiting for the python one to finish first
<lifeless> matkor: ok. well, if bzr st shows one as unknown, just use regular 'mv' etc
<lifeless> igc: it may well be faster to do a upgrade to --btree-plain first (or btree-rich-root etc9
<igc> lilfeless: interesting. I did try the same thing with --btree-plain. That took 195 secs
<igc> which is slowly than a branch (170s) but not by a lot
<lifeless> igc: so the btree index layer won't bloat anywhere near as much as teh graphindex one
<lifeless> igc: 'bzr upgrade --btree-plain' will be _much_ faster than a pull :)
<igc> s/slowly/slower/
<lifeless> igc: (upgrade --btree-plain will rewrite just the indices)
<ignas> how do I cancel a merge?
<awilkins> ignas: Revert
<ignas> bzr revert seems to only revert the changes
<ignas> i still can see the merged revisions in the pending merges list
<lifeless> ignas: are y ou running 'bzr revert'
<lifeless> ignas: or something more complex ?
<ignas> "bzr revert ." ;)
<ignas> got the hint
<lifeless> ignas: the . tells revert not to touch pending merges :)
<menesis> ignas: bzr revert --forget-merges
<ignas> menesis: thanks, just plain "revert" worked too though
<ignas> by the way - what is the correct way to resolve a tricky situation:
<ignas> i have a release branch 2008.04
<ignas> and trunk
<ignas> I had a bugfix branch for small bugfixes
<ignas> it worked fine
<ignas> but I have managed to do bzr pull from trunk to it
<ignas> and now if I want to merge a couple more of the bugfixes to 2008.04
<ignas> i am getting all the new stuff from trunk that got pulled ...
<ignas> i could -r rev1..rev2 the merge to my release branch
<ignas> but then I will lose the history for separate commits (I think)
<ignas> any ideas? except for picking all the separate commits from the bugfix branch (that is based on trunk now) and moving them to some other branch
<ignas> that is based on some common ancestor of trunk and release
<ignas> and a related question - where should I be branching my "feature that will probably go into the release and trunk" from to have nice merges later?
<ignas> I am adding python2.5 support at the moment, and if i am branching from 2008.04 directly - I am getting release specific changes in the merge from 2.5 branch to trunk...
<ignas> must I always branch specifically from the "branching" point of the release and trunk branches?
<lifeless> ignas: I generally branch features from trunk, and do a cherrypick merge if needed
<lifeless> ignas: but if you know a-priori that it will go into a release branch as well as trunk I would tend to start with the release branch
<ignas> well - release branch has at least some release specific changes (like setting of the version for a 2008.04.02 release for example)
<ignas> so as menesis just explained to me - bugfix branch should be branched out as early as feasible (like when the bug was first encountered/appeared in the code)
<ignas> and features should not be merged into release branches that have been in use in general
<lifeless> well, different folk find different things work
<lifeless> I generally ignore history and just code to head; backporting is usually dead easy bzr-wise
<ignas> and how do you do backporting?
<ignas> cherry picking?
<ignas> oh, apparently I can bzr revert some changes that were release specific, and it seems that it is "legal" to do so, so I can just skip the changes made to version.txt and to setup.py when merging from "a branch that was branched from release" to "trunk"
<lifeless> ignas: yes, I cherry pick when needed
<jelmer> re
<uws> So, when is a new .pack file created?
<uws> the sizes are really different in my repository
<uws> I'm using a --rich-root-pack repos (that's best, right?)
<jelmer> uws, hi
<uws> hey jelmer
<jelmer> uws, rich-root-pack would probably be the best choice if you don't have to worry about pre-1.0 clients
<uws> i'm hip and up-to-date, so no worries there :)
<jelmer> (-:
<uws> jelmer: also, i'm cloning a svn repos using svn+http://  and it seems to open a new connection for each revision
<uws> is that right?
 * jelmer catches up on three days of bzr-svn highlights
<jelmer> uws: No, that'd be a bug
<uws> svn+http://  is ok right?
<jelmer> though a known one if you're using particular older versions of bzr-svn
<jelmer> yeah, svn+http:// and http:// should both work
<uws> ii  bzr-svn                  0.4.10-2                 Bazaar plugin providing Subversion integration
<spiv> jelmer: I'd love a fix for the find_tags stage being very slow.
 * spiv is about to sleep
<uws> jelmer: If i pull from the http:// one later after branching from svn+http://, will that download all revisions again?
<jelmer> uws: No, the identity of the repository does not depend on the location
<uws> so what does it depend on?
<jelmer> spiv: I may have a look at that in the next two days
<jelmer> uws: the subversion repository uuid
<spiv> jelmer: wonderful!
 * spiv -> sleep
<jelmer> uws, and the path in the repository
<uws> ah ok
<jelmer> spiv: goodnight
<uws> I'm cloning webkit svn ;)
<uws> takes a LONG time
<jelmer> ah, ok
<jelmer> I need to do more memory use profiling
<uws> jelmer: yeah, it leaks so I pull like 1000 revs at once
<jelmer> siretart: do you happen to be in .uk as well?
<uws> jelmer: it seems bzr-svn 0.4.10-2 (debian package) calls connect() to the http server quite often\
<uws> my guess is each revision
<jelmer> uws: That should not be the case with the 0.4 branch of bzr-svn
<lamalex_2> Is there a howto for setting up an external branch? I'm starting a new project for work, want to use bzr, but don't want to use launchpad.
<uws> bzr-svn is also quite cpu bound it seems
<uws> lamalex_2: just type "bzr init" and you're done
<jelmer> uws, some of that has changed as well
<uws> connect(5, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("17.254.17.56")}, 16) = -1 EINPROGRESS (Operation now in progress)
<uws> connect(11, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("17.254.17.56")}, 16) = -1 EINPROGRESS (Operation now in progress)
<lamalex_2> uws: ... that's too easy
<uws> jelmer: ^^ i see that every few seconds
<lamalex_2> how do I control write access?
<uws> lamalex_2: to a shared repository? just file system access rights, or share a shell accoutn
<lamalex_2> ah ok
<jelmer> uws: Yeah, so that's a known issue which is fixed in the 0.4 branch
<lamalex_2> great thanks
<uws> jelmer: does it affect speed seriously?
<jelmer> uws: The reconnects probably don't matter much
<uws> jelmer: so I shouldn't have to upgrade manually (and remove the debian package)
<jelmer> uws: I can run a webkit import here as well with the 0.4 branch and see how fast that is
<uws> jelmer: it's really slow :)
<jelmer> uws, what's the URL?
<uws> jelmer: svn+http://svn.webkit.org/repository/webkit/trunk
<pickscrape> I can't for the life of me get authentication.conf to work :(
<pickscrape> I want it to change the username I connect to a server using, but it always ends up connecting as me.
<siretart> jelmer: sorry, no
<uws> does running "bzr pack" once in a while help for speed?
<siretart> jelmer: I'm .de
<pickscrape> Anyone have any experience on this happening and knows what I'm doing wrong?
<uws> pickscrape: you can use  sftp://username@host instead
<pickscrape> uws: thanks, but I don't want to have to tell my colleagues that they have to specify the username every time they want to access the server :)
<uws> pickscrape: is it ssh?
<pickscrape> yes
<uws> pickscrape: if so, you can also force it in ~/.ssh/config for that particular host
<lamalex_2> uws: why would I use init vs init-repository?
<uws> furthermore, urls for push/pull are remembered so it's really a one time thing
<pickscrape> uws: Oh, thanks for that I'll look into it.
<uws> lamalex_2: depends on whether you will have multiple branches, which will share the same "backing storage"
<lamalex_2> what do you mean by backing storage, and is this wiki'd somewhere? I hate to waste your time if there's already an article on this
<uws> lamalex_2: "bzr help init-repository" versus "bzr help init"
<lamalex_2> that doesn't give me why I should use one or the other, advantages,  disadvantages, etc
<uws> lamalex_2: branches created with "init" contain ALL history in .bzr
<uws> so if you have two branches for the same project, most history will be there twice, resulting in unnecessary disk usage
<uws> a repository holds all the revision data, and your branches (doesn't matter how many) just point to a specific revision,
<lamalex_2> ah
<uws> this results in the repository .bzr dir to be large, and the branch .bzr dirs to be really smalls (a few KB)
<lamalex_2> so it sounds like repository is the safer choice, are there any large disadvantages?
<uws> lamalex_2: you can't copy the branch directory using conventional means (cp, drag/drop in file browser) to other media
<uws> lamalex_2: but you can of course still create branches outside the repo as well
<pygi> greetings asabil
<jam> Odd_Bloke: want some help with bug 160530?
<ubottu> Launchpad bug 160530 in bzr-pqm "pqm-submit is sending messages pqm doesn't understand" [Critical,Fix released] https://launchpad.net/bugs/160530
<asabil> hello pygi :)
<Odd_Bloke> jam: Yeah, I haven't really looked into it a great deal, but copy-pasting the strings in the bug into PQM's queue didn't cause a problem.  So I don't know if this has been magically fixed, or...? :)
<jam> Odd_Bloke: I couldn't tell you for sure, are you seeing stuff that uses the email library to parse the requests, rather than reading the raw string?
<colbrac> jelmer: Working on bzr-gtk?
<Odd_Bloke> jam: I haven't really looked into it enough, I'll look into it further later.
<jam> Odd_Bloke: np
<jam> Someone certainly could have cleaned up PQM's message parsing and not mentioned it
<uws> jelmer: is it right that bzr-svn looks like it's cpu-bound?
<uws>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
<uws>  7210 uws       20   0  469m 442m 6700 R 43.7 44.1   7:44.93 /usr/bin/python /usr/bin/bzr pull -v -r 18500
<uws> like that, all the time
<uws> (also 100% btw)
<jelmer> uws: Yeah, some bits may be CPU bound, especially in < 0.4.11
<jelmer> colbrac: somewhat
<colbrac> jelmer: Is that account coming through?
<jelmer> colbrac, yep, just give me a few minutes
<jelmer> uws, it's pretty slow here as well, but not using a lot of cpu
<jelmer>  2497 jelmer    20   0  209m 178m 7992 S   14 11.8   8:11.88 python
<uws> jelmer: Hmm, your 0.4 branch installs ra.so and client.so (and some other files) directly into site-packages/
<uws> is that right?
<uws> jelmer: Unable to load bzr-svn extensions - did you build it?
<uws> strange, I did
<lifeless> jelmer: http://news.launchpad.net/ppa/introducing-autoppa
<jelmer> lifeless, blegh, ubuntu only :-( Hopefully it works on Sid :-)
<james_w> rockstar: hi, are you still looking for me?
<rockstar> james_w, kinda.  I've got some questions about using bzr-builddeb
<james_w> rockstar: ah, sure, ask away
<lifeless> jam: hi
<rockstar> Well, I'm having an awkward time trying to find a good workflow.  I just wondered, since you probably use it on a normal basis, I wonder if you could recommend a workflow
<rockstar> james_w, ^^
<james_w> I don't use it that much :-)
<james_w> what are you struggling with?
<lamalex_2> uws: is there any apache setup or anything I need to do to make this repo accessible?
<lamalex_2> wow no! this rules. bzr+ssh://host/path
<jam> lifeless: hi, probably afk for a bit, my son is waking up from the morning nap, and I'll be taking him to day care in a bit
<jam> LarstiQ: I *do* use win32 probably 75% of the time, but I *don't* run the full test suite (on either platform). I know that BzrDir.clone() is broken (BzrDir.sprout() works, which is a bit weird), but that is something that probably makes a lot of tests fail
<jelmer> uws, hmm, it is slow
<jelmer> uws, I'm at 800 revisions now
<jelmer> 28k to go :-)
<uws> jelmer: yeah, just stop it. you can branch from me later if you wish
<uws> I'm at ~18000 already
<jelmer> ah, ok - over how much time?
<jam> lifeless: I would be curious to know how you did remote testing of your btree code
<uws> ~1.5 days
<jelmer> wow, ok
<jam> As I'd like to put the new bloom stuff through its paces over a remote connection
<jelmer> uws: I guess the 0.4 branch is a bit faster then
<uws> jelmer: I couldn't get it to work
<jam> So far, I've just finally managed to do better than no blooms on a local filesystem
<uws> jelmer: complained about needing bzr 1.6, and it doesn't work with the 1.6b2
<uws> complaining about make_knit_factory or something
<jam> Not a *lot* better yet, but *better* which means they are viable :)
<jelmer> uws: yeah, it needs bzr.dev
<uws> jelmer: will the speed improvements be an order of magnitude?
<jam> lifeless: oh, and until I get the 'paged bloom' code written, they won't scale to 1M+ pack files, because they will always read the full array
<jelmer> uws, it's doing about one revision per three seconds here
<jelmer> what sort of speed are you seeing?
<jam> Though we could still *create* them, even if we didn't always use them yet.
<uws> jelmer: roughly that yes
<uws> jelmer: however I don't see that anywhere
<uws> jelmer: only from the "strace -econnect)
<uws> It just says "Pull phase 0/2" for a VERY long time
<rockstar> james_w, for instance, I'm trying to package a tarball from upstream to put in my PPA.  It doesn't make sense for me to version the contents of the tarball, so I figure I version debian/
<LarstiQ> rockstar: why, that almost sounds like a larstiq workflow ;)
<uws> jelmer: will speed be constant when the revision number gets higher for my bzr-svn branching?
<rockstar> At this point, what does bzr-builddeb provide over the standard debian tools?
<jelmer> uws, yeah, that's the idea
<uws> jelmer: Ok, I'll just let it run for the next few days then :S
<uws> launchpad doesn't have a mirror either
<uws> would they be interested in mine?
<james_w> rockstar: if you only want to version debian/ then bzr-builddeb will construct the source package for you by assembling the bits in the right way. You can do this yourself, but you may find it more convenient.
<rockstar> Where is the convenience?  That's really what I'm looking for.
<jelmer> uws, installation of the 0.4 branch should be fixed now
 * jelmer wonders who he has to bribe to get his gssapi patch reviewed
<james_w> rockstar: to build the source package you need the upstream tarball unpacked, with debian/ in place. You can obviously do this by hand, but I found doing that tedious.
 * LarstiQ takes euros and litas.
<jelmer> LarstiQ: I can give you 200 litas I think
<jelmer> :-P
<jelmer> I still have some from last year, not likely to need them in the near future
<LarstiQ> jelmer: you sir, have a deal!
<LarstiQ> but first I'm going to bbq in the park.
<rockstar> james_w, Ah, so you can say "download the tarball from here, build everything" ?
<james_w> rockstar: yeah, one thing it can do is to try and get a tarball for you if you don't have one already (using apt or uscan).
<rockstar> james_w, Ah, that's what I was looking for.
<jelmer> LarstiQ: heh, bon appetit
<lamalex_2> This transport does not update the working tree of: bzr+ssh://combatshadow/var/www/acetechgroup.com/systems/htdocs/systems/. See 'bzr help working-trees' for more information. -- What does that mean? Why can't I push to my repo?
<radix> you can, it just doesn't update the working tree
<lamalex_2> what does that mean?
<james_w> lamalex_2: did you have a look at "bzr help working-trees"?
<lamalex_2> so I have to run bzr update in my repo whenever I push
<lamalex_2> that's annoying
<james_w> lamalex_2: there are two plugins that might interest you, the first is "push-and-update", which automates "ssh wherever 'bzr update'" when you push
<james_w> then second is "bzr-upload" that allows you to upload the working tree to a remote location, this is what web developers usually want.
<lamalex_2> that's what I want too
<lamalex_2> where can I get the push-and-update plugin?
<lifeless> https://launchpad.net/bzr-push-and-update
<Odd_Bloke> lifeless: So I've looked at your cleanup of thumper's queue-abstraction branch and it _mostly_ looks OK.  There are a couple of things that I think could be better, but it's hard to know whether it makes sense in this branch...
<bud3030> Hi bzr  I have changed email address should i change it in bzr.conf, auth,conf, location,conf
<Odd_Bloke> bud3030: Use 'bzr whoami <new string>' and 'bzr whoami' again to check it's correct.
<bud3030> Odd_bloke thanks Ill give a try
<pickscrape> Would the correct way to reverse a changeset on a branch be: bzr merge -r 8..7 . (where the revision to reverse if r8)?
<pickscrape> s/if/is/
<pickscrape> Actually... yes, that works. I'd accidentally done the merge the other way round, and the result makes bzr stat crash
<pickscrape> bzr diff --stat
<pickscrape> oops
 * thumper wonders what bzr diff --stat does
<pickscrape> Nothing unless you install the diffstat plugin :)
<rockstar> Dangit, someone took my bzr-stats idea...
 * rockstar snoozed and lost
<pickscrape> rockstar: It's been around for ages
<pickscrape> https://launchpad.net/bzr-diffstat
<asabil> pickscrape: you can also simply uncommit
<pickscrape> I recently picked it up and got it working with 1.5.
<asabil> if you didn't publish the branch yet
<pickscrape> asabil: no, this is a changs from a couple of revs back from HEAD that has been published. I figure it out though.
<rockstar> pickscrape, that doesn't make me any less of a sad panda  :)
<pickscrape> rockstar: :( One of the reasons why I've not started any projects of my own too
<bud3030> jam how can one correct the error 13 : hook route to ubuntu machine
<bud3030> am i log in to go privite
<newz2000> hi, maybe this is esoteric, but it never hurts to ask...
<newz2000> is there a plugin that will export a project as a zip file?
<newz2000> (or some other archive)
<beuno> newz2000, bzr export
<beuno> it's not a plugin, it's a default command
<newz2000> :-D
<newz2000> that explains why it wasn't on the plugins page
<newz2000> so I guess I'm not the only one who's wanted this feature then
<beuno> probably not  :)
<newz2000> ok, one more thing then...
<newz2000> I have a workflow for some projects that includes a few steps. Is there a way to bundle these steps into one process? I like the plugin that does ssh -c bzr co .
<newz2000> I can script it of course, just wondering if there was a hook for bzr push that would do it automatically
<beuno> you can hook to post-tip-change, and make that run a script
<newz2000> ok, I see this in the docs... out of curiosity, is it possible to define different actions on a per project basis?
<beuno> hm, that's a good question
<beuno> I don't think there's a straight forward way of doing that from bzr
<beuno> you can probably do that on your script
<beuno> pass on the branch nick or path
<newz2000> At a diff job we did this with ant, so maybe I'm crossing the point of what my vcs should be doing for me
<newz2000> beuno: thanks for the export tip... that's a big help.
<beuno> newz2000, welcome'
<uws> So, my bzr-svn for webkit will take a few days methinks
<uws> there's no launchpad mirror. would they me interested in mine?
<bkor> jelmer: could you please advise on https://bugs.launchpad.net/bugs/248119 ?
<ubottu> Launchpad bug 248119 in bzr-svn "SubversionException: Delta does not fill the target window" [Undecided,New]
<chadmiller> Hi all.  One of my cow-orkers is using bzr.dev of an hour ago, and gets a AttributeError exception. ...
<Peng> chadmiller: Pastebin the traceback?
<Peng> chadmiller: Does he have any plugins installed?
<Peng> chadmiller: FWIW, it works for me, but I haven't tried to commit or anything.
<chadmiller> Five lines pasted here:
<chadmiller>   File "/usr/local/lib/python2.5/site-packages/bzrlib/bzrdir.py", line 1092, in sprout
<chadmiller>     hardlink=hardlink)
<chadmiller>   File "/usr/local/lib/python2.5/site-packages/bzrlib/bzrdir.py", line 1386, in create_workingtree
<chadmiller>     return self._format.workingtree_format.initialize(
<chadmiller> AttributeError: 'property' object has no attribute 'initialize'
<chadmiller> That's from "bzr branch".
<chadmiller> I have him checking that ssh is working correctly.  I've seen some weird problems caused by transport failure.
<chadmiller> Ideas anyone?  It wasn't ssh.
<bob2> anything in lp with that error?
<mwhudson> whuut
<mwhudson> chadmiller: is your co-worker proficient in python?
<mwhudson> if you run the command with "BZR_PDB=1" you'll get a pdb at the point of the exception
<mwhudson> and then poke around
<chadmiller> mwhudson: I don't suppose so, no.  He knows gdb, though, and Python ain't hard.
<mwhudson> also
<mwhudson> what exactly command is he running?
 * mwhudson finds that his irc grammar is getting worse and worse
<chadmiller> mwhudson: "bzr branch bzr+ssh://ourserver/branchname bn"
<mwhudson> chadmiller: ok, can you get him to run it again with BZR_PDB=1
<mwhudson> and then type
<mwhudson> p self
<mwhudson> p self._format
<mwhudson> p self._format.workingtree_format
<mwhudson> ?
<chadmiller> I'll do so.  he's offline now, for sleep or something.
<chadmiller> (Lazy Swedes!)
<mwhudson> ok
 * mwhudson looks to see if the problem can be seen in the code
<mwhudson> chadmiller: oh, one more, what format is the branch hes getting in?
<chadmiller> mwhudson: "Repository branch (format: pack-0.92)"
<mwhudson> chadmiller: ok, ta
<mwhudson> hm hm
<mwhudson> i wonder if _format is the class object, when it should be an instance
<mwhudson> hey wee, i can reproduce
<mwhudson> which means... a rather bad miss in bzr's tests
<thumper> mwhudson: file a critical bug
<thumper> mwhudson: to make sure it is fixed for 1.6 release
<mwhudson> wth
<mwhudson> it only happened once :(
<thumper> weird
<mwhudson> chadmiller: fwiw, my experience suggests that if your work mate simply tries again, it will work for him :/
<chadmiller> mwhudson: Consider this a counterexample, then.
<mwhudson> oh good
<mwhudson> ah hurrah, i hit it in pdb
<Peng> Lazy import issue?
#bzr 2008-07-17
<lifeless> moin
<igc> hi lifeless
<igc> python figures for you lifeless: 346.5MB -> 181.4MB
<igc> OOo and mysql still going
<mwhudson> oh man, i which this was deterministic
<mwhudson> wish
<lifeless> mwhudson: which was?
<mwhudson> https://bugs.edge.launchpad.net/bzr/+bug/249256
<ubottu> Launchpad bug 249256 in bzr "bzr get fails in tree building ... sometimes" [Undecided,New]
<mwhudson> i'm getting somewhere now
<lifeless> igc: this is consistent; I am sure it can drop another 50% via the ordering work I had hoped to get done today
<lifeless> but sprinting on other more face2face things
<ChristopheT> Hi.  I am struggling to write some tests (in tests_http.py) with redirected web servers.  For 2 web servers it is done, but I'd like to test with 10 redirections.  Any pointers?
<mwhudson> lifeless: bzrdir.py
<mwhudson> line 1021
<mwhudson> tree_format = repository._format._matchingbzrdir.workingtree_format
<mwhudson> 'repository._format._matchingbzrdir' is the _class_ object
<mwhudson> and so 'repository._format._matchingbzrdir.workingtree_format' is the _property_ object
<mwhudson> hilarity ensues
<lifeless> mwhudson: sweet
<mwhudson> lifeless: i think (a) this is priority 0, (b) i'm not the best person to fix it
<mwhudson> i guess it's getting late for you though?
<lifeless> 0012
<tacone> sorry, how to get the last revision (with no .bzr files or stuff like that) ?
<lifeless> tacone: bzr export
<tacone> and without having to branch millions of revisions ?
<mwhudson> lifeless: so i guess you're not the best person to fix it either
 * mwhudson pokes poolie, spiv 
<tacone> lifeless: bzr export works only when I have already branched, right ?
<bob2> tacone: export can take a remote branch url
<lifeless> mwhudson: have you merged zr-search loggerhead ?
<lifeless> tacone: no, ou can export any branch
<mwhudson> lifeless: no, i reviewed it and had comments and then ... someone we know ... screwed up beuno's life :)
<lifeless> mwhudson: a certain celebrity?
<tacone> bzr export lp:~encompass/memaker/trunk --format=tgz gives: bzr: ERROR: Not a branch: "/var/www/aaaa/httpdocs/"
<mwhudson> lifeless: yeah
<tacone>  /var/www/... is my current directory
<lifeless> mwhudson: ergh
<lifeless> tacone: bzr export foo.tar.gz lp:~encompass/memaker/trunk
<mwhudson> i can probably make the fixes i requested myself, but it would definitely be quicker easier for beuno
<lifeless> (bzr help export should help you)
<lifeless> mwhudson: pls don't let it bitrot; thumper confirmed you have work time available at your discretion for this
<mwhudson> lifeless: it looks like today is a loggerhead day
<mwhudson> (when i can stop worrying about bzr.dev being broken anyway)
<beuno> mwhudson, lifeless, I'll try and get to those changes today or tomorrow
<lifeless> I have to halt()
<mwhudson> beuno: if you can just tell me which parts of the code need to change to do them, that'll probably be enough of a hint for me to be able to do them
<lifeless> I'll be doing gc stuff tomorrow; mail me if you have things for my attention, otherwise its headphones on and code away
<beuno> mwhudson, I'm wrapping some things up, if I don't fix them, I'll send you the hints
<mwhudson> beuno: cool beans
<beuno> and sorry for the lag
 * mwhudson changes location
<tacone> Thanks lifeless, works :-). good night
<thumper> I have a switch question
<thumper> anyone know that area well?
<thumper> There is a shared repo at ~/gnome-bzr/repos/metacity with some branches under it: "devel" and "some-other"
<thumper> in ~/gnome-bzr/src/metacity there is a lightweight checkout of ~/gnome-bzr/repos/metacity/devel
<thumper> if we are in the ~/gnome-bzr/src/metacity directory, I was told that `bzr switch some-other` would work
<thumper> but instead an error is returned: bzr: ERROR: Not a branch: "[stripped/home/tthurman/gnome-bzr/src/metacity/vectacity/".
<thumper> damnit
<bob2> it should switch to the sibling 'some-other' of the currently bound branch
<mwhudson> yeah, i thought that worked
<thumper> I was trying to nicely strip the home dir out
<mwhudson> new enough client bzr?
<thumper> I've asked the user
<thumper> ha, he is on 1.3.1
<thumper> newer bzr needed?
<mwhudson> hardy was released too early
<mwhudson> i don't exactly know, but it's a fairly new feature
<bob2> 1.4rc1
<thumper> bob2: thanks
 * mwhudson pokes poolie, spiv again
<spiv> mwhudson: hi
<mwhudson> spiv: https://bugs.edge.launchpad.net/bzr/+bug/249256 is critical
<ubottu> Launchpad bug 249256 in bzr "bzr get fails in tree building ... sometimes" [Undecided,New]
<mwhudson> spiv: please fix :)
<igc> ping markh
<markh> igc: hi ian
<igc> markh: re your cog.py patch, why the 'del sys.argv[0]' line?
<markh> IIRC, the new script is sys.argv[0]
<markh> so nuking that puts cog.py back in [0]
<markh> ie, so cog.py sees the same argv it would without the wrapper script
<igc> markh: so python magically self-repairs that dict?
<markh> list?
<igc> yes, list
<igc> ignore that
<igc> ok - brain working again :-)
<markh> :)
<igc> thanks markh :-)
<markh> np - thanks for looking at the patch :)
<markh> I actually screwed up the patch to the .cog itself, which I need to email about
<markh> ie, I used "out1" instead of "outl" in some cases - trailing "number one" versus "letter l" :(
<igc> :-(
<igc> markh: I'll approve and merge the cog.py patch now
<markh> as usual, a bit of a mad rush to clean up the patch before sending it off, then only testing one of the main "branches"
<markh> great, thanks.  I've got yet more to come soon, now that I've worked out how to include QBzr in the installer and have tortoise re-use that - but I'm still trying to get my life back into order since europython.
<igc> markh: now is a good time to clean things up. 1.6rc1 is pending
<markh> igc: were you in dubai?
<igc> markh: no. I can't travel just at the moment - health problems unfortunately
<markh> bugger - anyting too serious?
<igc> markh: how did your Bazaar talk go btw?
<markh> well - I think Steve was happy because Chris Withers said that due to my talk he would investigate bzr (I believe Chris and Steve are personal friends?)
<igc> markh: things could be better. See http://ianclatworthy.wordpress.com/2008/06/26/how-can-i-help/
<igc> markh: did you like steve's talk? it was partly based on a paper of mine
<markh> yes, I did alot and I saw reference to your paper which I'm yet to read.  I think its very interesting.
<markh> a nice "post xp" methodology
<markh> neo-xp? :)
<chadmiller> mwhudson: Thanks for filing that bug, #249256 .
<markh> post-modernism-in-xp? ;)
<mwhudson> chadmiller: i'm trying to encourage someone to figure out how to fix it properly :)
<markh> igc: damn - very sorry to hear about your health :(
<igc> markh: I doubt my paper will change the world as much as Kent Beck's paper on XP did but one can only hope!
<igc> markh: yeah - it's a bummer :-)
<chadmiller> mwhudson: I could normally sit on my hands, but a patch from this afternoon is essential for my team.  Grr.
<chadmiller> ^patch^patch to bzr
<mwhudson> chadmiller: the --weave thing?
<chadmiller> Yeah.
<mwhudson> chadmiller: let me see if i can hack
<mwhudson> hm, maybe it just takes 2 characters :)
<mwhudson> chadmiller: this seems to fix it for me: http://pastebin.ubuntu.com/27879/
<mwhudson> poolie: ^^
<mwhudson> argh
<igc> markh: so confirming, you're planning to resubmit your patch on 'optionally install tbzr ...'?
<markh> igc: yes
<igc> markh: I'm mark it as resubmit
<markh> thanks!
<mwhudson> oh ffs
<mwhudson> my repo on people.ubuntu.com is knits
<mwhudson> i thought pushing was taking a while
<mwhudson> poolie: http://people.ubuntu.com/~mwh/repos/bzr/create-tree-from-remote-branch-bug-249256/ contains the fix and some changes to the test setup
<mwhudson> poolie: but test_selftest fails
<mwhudson> chadmiller: any luck?
<chadmiller> mwhudson: I haven't tested it.  Sorry -- brain fried.  Need rest now.  G'night.
<mwhudson> chadmiller: ok
<chadmiller> I mailed my co-worker, who should be waking in not too long.
<chadmiller> mwhudson: Thank you!
<mwhudson> chadmiller: hope it helps!
<mwhudson> thanks for bringing it up!
 * mwhudson lunches, biab
<poolie> (back)
<poolie> mwhudson: i'm merging that not
<poolie> now*
<poolie> i mean for review, not yet to trun
<poolie> trunk*
<mwhudson> oh good :)
<poolie> did you upgrade it?
<mwhudson> well, moved my old repo away and made a new one
<mwhudson> so yeah, it's packs now
<mwhudson> poolie: i guess the getting of bzrdir format from the tree/repo should be pushed down another layer
<mwhudson> (and possibly given a more official sounding name than '_matchingbzrdirformat')
<mwhudson> oh and something equivalent should be on branches
<rick_h_> lifeless: ping
<poolie> and does that branch now pass everything but test_selftest?
<mwhudson> poolie: yep
<poolie> that patch looks reasonable
<poolie> would you like me to look at the selftest failures?
<mwhudson> yes, i'm not really sure how to fix them
<mwhudson> well, i can see a couple of ways
<poolie> i guess it's good this method is specifically tested
<poolie> mwhudson: so to state the obvious we need to pass it format descriptions in the form it expects
<poolie> i think passing strings to a function-under-test that is meant to get a different type of object
<poolie> because it just happens to pass through the current duck-typed implementation is a bit gross
<mwhudson> poolie: yes
<poolie> or at least, confusing to someone reading the test
<poolie> i've updated the formats_to_scenarios docstring a bit too
<poolie> sheesh
<poolie> or ints even
<mwhudson> alternatively you could say that it's a feature of the adapters that they treat the arguments as black boxes
<mwhudson> though, pff, that's a bit bogus i think
<poolie> um
<mwhudson> poolie: i think a stronger argument is that if bazaar is changing so that the bzrdir format is derived from other inputs rather than supplied separately
<mwhudson> the test suite should change to reflect that too
<poolie> right
<mwhudson> the problems of trying to fix bugs on release day :)
<igc> spiv: can you take a look at http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C4877E9ED.7020503@gmail.com%3E please? Would to be nice to get this into 1.6 if you're happy with it.
 * igc lunch
<poolie> mwhudson: i guess it's nice for python interfaces to not be over-particular about the interfaces of objects passed to them
<poolie> but the tests should actually adhere to whatever the code under test expects
<poolie> mwhudson: i'm going to change it to pass actual formats anyhow
<poolie> and see how that looks
<mwhudson> poolie: okidoke
<spiv> igc: I'll take a look
<poolie> mwhudson: something like this...
<poolie> http://pastebin.ubuntu.com/27890/
<mwhudson> poolie: that does make the tests look more realistic
<poolie> it is a little longer to write but fortunately the format objects do already have __eq__ methods
<poolie> so with the vfs
<poolie> so with the vfs_scenarios similarly changed that one test passes
<poolie> mwhudson: ok they're all fixed, i'll send it to the list
<poolie> maybe you could read it there?
<mwhudson> poolie: okidoke
<mwhudson> wow, tcp being useful -- my laptop was asleep in my bag for about 10 minutes there
<poolie> nice
<poolie> sadly many protocols on top or nat devices now have shorter timeouts
<poolie> mwhudson: so do you know what value of "sometimes" causes it to fail?
<mwhudson> poolie: no, i'm totally baffled by that
<mwhudson> poolie: i can only imagine i wasn't running the code i thought i was
<poolie> mwhudson: so i'm just writing the cover letter
<poolie> and can you explain to me _why_ you want to change the format list passed to these multipliers
<poolie> in some ways passing the bzrdir separately is cleaner
<mwhudson> well, because it was passing it separately that allowed the bug to land
<mwhudson> and if _every_ callsite is like "(f, f._matchingbzrdirformat)" that seems redundant
<poolie> right
<poolie> i agree
<mwhudson> that's all
<poolie> spiv, could you read my submission of mwh's fix?
<poolie> or igc
<beuno> mwhudson, updating search
<mwhudson> beuno: awesome
<beuno> should address all your comments, except the last two "optional" ones
<beuno> which, well, I promise I'll get to them soon
<beuno> :(
<beuno> Not allowed here
<beuno> Sorry, you don't have permission to access this page.
<beuno> You are logged in as Martin Albisetti.
<mwhudson> that's ok
<mwhudson> !?
<beuno> when trying to request another merge from that branch
<mwhudson> where's that?
<mwhudson> oh ffs
<spiv> poolie: ok
<beuno> https://code.edge.launchpad.net/~beuno/loggerhead/bzr-search_integration/+merge/480/+request-review
<mwhudson> beuno: oh, that's a known bug
<mwhudson> beuno: try again, i sneakily changed daniel.bueltmann's subscription
<beuno> mwhudson, I replied and approved it instead of requesting another review
<mwhudson> heh ok
<beuno> I still can't understand the merge request UI
<mwhudson> beuno: ah uh
<mwhudson> the onblur handling means you can't click on the suggestion :)
<mwhudson> because the focus leaves the box, the div disappears, then the click is processed
<beuno> damn, I knew it wasn't that easy
<mwhudson> (it seems, anyway)
<mwhudson> i guess hide the div a few tenths after the onblur?
<beuno> mwhudson, good idea, let's try that
<mwhudson> the other changes all look fine
<mwhudson> beuno: hm, the look if there are no suggestions is maybe a little odd
<beuno> mwhudson, right, it should probably say "no results"
<mwhudson> yeah
<beuno> mwhudson, pushed
<beuno> I wonder why we hide the users email, if it gets exposed in the revid anyway...
<mwhudson> beuno: the loading div still has different vertical padding to the suggestions
<mwhudson> beuno: but i'm not sure i care
<mwhudson> beuno: merge and push away!
<beuno> mwhudson, thanks  :)
<beuno> I promise I'll go back and give the UI some love
<beuno> I want it to look more polished
<beuno> I'm just a bit exhausted these days
<mwhudson> sure
<mwhudson> it's definitely good enough to land now
<beuno> mwhudson, does LH take some time to update in LP?
<beuno> hm, it took a bit under a minute to update my push
<mwhudson> beuno: it has to wait for the branch to be mirrored, which can take a minute yes
<beuno> lifeless, http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/revision/182
<mwhudson> the scanner seems busticated, we're looking at that now
<beuno> mwhudson, so you're not doing http anymore?
<mwhudson> beuno:
<mwhudson> ?
<beuno> mwhudson, accessing branches through http
<mwhudson> yes
<mwhudson> that only requires the puller run
<mwhudson> er, and something else
<beuno> oh, and those need mirroring too?
<mwhudson> but not the scanner
<mwhudson> possibly our guts are slightly too visible :/
<beuno> right, the scanner I can understand. LH is what I have a hard time understanding why it takes a minute
<mwhudson> because when you push over bzr+ssh you're not writing files to the same area accessing them over http reads
<beuno> aaaah, ok
<beuno> that's something I didn't know  :)
<beuno> I'm off to bed
<beuno> thanks for the review mwhudson
<mwhudson> g'night & np
<spiv> poolie: I've reviewed (and approved) that fix
<poolie> thanks spiv
<jkakar> How do I upgrade a knits repository to packs?  I've just tried running bzr upgrade but it's not happy.
<bob2> pastebin the error - 'bzr upgrade' should upgrade you to the default, which is packs
<bob2> unless your repository contains branches from svn
<jkakar> bob2: http://paste.ubuntu.com/27920/
<jkakar> Running bzr upgrade in the repository root results in: http://paste.ubuntu.com/27921/
<jkakar> Also, there are no branches from SVN.
<bob2> ah
<poolie> it's a pretty poor message
<bob2> 'branch' is trying to branch from a rich-root-pack repository into your regular pack repository, and giving you a crappy error message
<jkakar> Ah, okay.
<jkakar> So I need to upgrade to rich-root packs?
<poolie> yes
<jkakar> Is there any reason I might not want to do that?
<bob2> (or branch that jelmer's branch to another repository or standalone branch)
<jkakar> Right, thanks.
<Peng> Hmmm. Merge conflicts.
<Peng> Ohh. I previously merged this branch, backed it out, and then backed out the backout, so that probably has everything confused.
<igc> poolie: so I'm good to merge the stacking user doc as is?
<poolie> i'm merging it, with the comments on the list
<poolie> i'm trying to work out what to do about the thing i replied with
<igc> poolie: thanks
<poolie> igc, there are two tricky situations at the moment, kind of related to each other
<poolie> - branching from a stacked branch
<poolie> either within a single repository, or to a new locaiton
<poolie> to a new repository
<igc> spiv: thanks for reviewing and merging that patch of Adrian's
<poolie> spiv/igc, could you have a look at the incremental patch i just posted to the StackableBranch thread?
<igc> poolie: sure
<poolie> abentley: if that message indicates you're awake you could look at it too...
<spiv> poolie: the argument list of assertRevisionInRepository seems backwards, although that's not new in your branch.
<spiv> poolie: but it is highlighted by assertRevisionsInBranchRepository, which is the way round that you'd expect :)
<poolie> :)
<poolie> i can fix that then
<spiv> poolie: that patch looks ok to me, although it's the first stacking-related patch I've reviewed :)
<poolie> what do you think of the logic of the change, and aaron's comment earlier in the thread
 * Talden thinks... Man, with the list of stuff in NEWS already and more stacking, a new indexing model, compression, Win32 FindFirst, ... The next few releases are going to be huge leaps forward.
<spiv> I agree that we don't want to create a stacked branch unless the user explicitly said --stacked.
<jml> or they push somewhere with a stacking policy
<poolie> does python have a system facility to tell you of illegal characters?
<spiv> illegal in what sense?  Not encodable to some encoding?
<poolie> <>*,;:/|\ that kind of thing
<poolie> on windows
<spiv> Oh, right.  Illegal in filenames.
<spiv> No, there's no good way I know of.
<poolie> my question was kindof ambiguous
<spiv> Does modern windows still have issues with filenames like "CON:"?
<jml> poolie: it's also a little bit more complex on windows
<jml> spiv: yes.
<poolie> heh
<poolie> i don't know if it's still true but at one point even con.doc caused problems
<poolie> probably fixed now
<jml> I think it's just 'CON', without a colon.
<poolie> lifeless: ping?
<lifeless> hi
<poolie> lifeless: i have a patch up that changes branch so that branching from a stacked branch will not implicitly give you another stacked branch
<spiv> See also http://bugs.python.org/issue481171
<spiv> Which I filed in 2001 :)
<lifeless> poolie: h. was it doing that? sprout, used by branch, would have needed explicit instructions to preserve stacking
<poolie> spiv, what is ASX:PRN?  porn.com.au?
<poolie> :)
<poolie> lifeless: it was doing that, and there was even a test for it
<poolie> it might not have been your codeof course
<spiv> poolie: heh
<spiv> I can't remember why I encountered that bug, come to think of it.
<spiv> But it probably was something to do with ASX:PRN :)
<poolie> you say so in the bug
<poolie> a junior miner apparently
<spiv> Oh, right.
<spiv> Apparently I can't read my own bug reports :)
<poolie> though in 2001 they could well have been both a junior miner and a dot com :)
<poolie> glad to see you did take tim's advice and get a real OS :)
<spiv> :)
<lifeless> poolie: oh it was preserving with a test that it did? hmmm
<lifeless> I think perhaps I thought 'bzr branch traunk --stacked local; bzr branch local morelocal
<poolie> that cause raises some serious questions
<poolie> well, some of which i wrote about
<lifeless> I can look at that when I hit the office if you like
<lifeless> thumper: lol; irony
<pygi> lifeless, poke
<lifeless> hi
<pygi> lifeless, you have a moment for pm?
<lifeless> sure
<thumper> lifeless: I fixed the problems with the pqm queue-abstraction branch
<thumper> lifeless: and merged that into queue-abstraction-2
<thumper> lifeless: the second one will most likely conflict with any other branches
<thumper> lifeless: as it moves all the code around
 * thumper is away for dinner now
<thumper> have fun
<lifeless> thumper: well the first conflicted hugely; thats why I put up a branch that resolved it
<lifeless> :)
<thumper> lifeless: yeah, but I didn't look at yours as you said the tests were failing :)
<thumper> mine works :)
<thumper> now I'm really gone
<lifeless> thumper: nope, I said tests were passing in mine
<lifeless> th	they were failing on yours :). have fun
<lifeless> I'll cross-compare the two branches today
<poolie> lifeless: i'd like to do another beta or rc before i finish today
<lifeless> poolie: sounds good
<poolie> maybe  i should just merge this
<lifeless> this being ?
<poolie> the --stacking patch
<lifeless> roght, well I'll have it revied for you in < 1 hour; heading to do teeth then walk over now
<poolie> also, i need to automatically pick a new format
<poolie> so that should give you time to do your stuff
<lifeless> ~
 * igc dinner
<jml> lifeless: Please take a look at https://code.edge.launchpad.net/~jml/bzr-loom/switch-aliases when you get the chance
<jml> I'd request a review, but there's a bug in Launchpad stopping me (which I'm fixing now)
<poolie> jml, 1.6b3 is up with stacking inside
<jml> poolie: sweet.
<poolie> :) yum dogfood
<poolie> i'm going to log off for a bit
<bob2> haha
<jml> poolie: I won't be able to land the bzr upgrade for a day or so.
<jml> poolie: but will do it asap
<lifeless> james_w: jelmer: Odd_Bloke: I'm in bouvet
<lifeless> jml: the merge proposal mail should say 'lp:~jml..' don't you think?
<jml> lifeless: I didn't get the email I think.
<jml> lifeless: I got an exception when I hit submit. Please forward me the email so I can triage appropriately.
<lifeless> jml: done
<awilkins> jam: Has that fast walkdirs thing been merged into dev?
 * awilkins looks
<awilkins> Apparently not. I could benefit from that that, I have some monstrous trees here (34,000 files in one)
<awilkins> Anyone want a win32 installer of 1.6b3?
<Peng> That fast walkdirs thing is for Win32; what's the situation on other OSes?
<Peng> Are they already very fast or do they not offer the same APIs or what?
<awilkins> Peng: I'd imagine it's already v.fast on Linux ; the 34,000 files tree I spoke of returns a status in less than a second on Linux
<Peng> So..this optimization is only necessary on Windows? Ok.
<awilkins> Peng: The win32 API is most definitely not the same as Linux VFS
<awilkins> Peng: Filesystem performance on Win32 in general is much slower than Linux
<awilkins> Peng: But obviously, a lot of the time they are comparing apples to oranges ; code that's performance tuned for Linux vs... the same code on Windows
<Peng> Okay.
<Peng> Thanks. :)
<Peng> Still, are there any opportunities for similar optimizations on other OSes?
<awilkins> Peng: I presume you mean "OS/X" ?
<Peng> I'm a Linux user.
<awilkins> I'm not sure ; I don't know how "close to the metal" the Python implementation of walkdirs is
<lifeless> awilkins: its posixish - e.g. slow :)
<lifeless> Peng: there is room to improve linux and mac os X yes
<Peng> lifeless: Is anyone going to do it, or is it "good enough"?
<lifeless> Peng: I hope to be focusing purely on performance and the odd killer-feature over the next 6 monthsw
<awilkins> Is there an "eradicated test errors on win32" effort anymore?
<lifeless> yes
<fullermd> Does that include the bit-o-both that "new inventory stuff so log {-v,$FILE} doesn't make me want to kill myself"?
<lifeless> jam is running on win32
<jelmer> beuno, ping
<awilkins> Well, clearly he's not optimizing win32 for jollies
<lifeless> :)
<Peng> beuno: This is unrelated to the ping you just got, but now that LH's bzr-search_integration branch has been merged into the trunk, is it done? Should I stop pulling it?
<mwhudson> lifeless: bzr-search_integration got merged
<lifeless> mwhudson: awesome
<mwhudson> well, maybe
<mwhudson> i told beuno to merge it, don't know if he did
<mwhudson> yeah, he did
<Peng> mwhudson: See the question I just asked beuno?
<igc> awilkins: the fast walkdirs isn't in bzr.dev yet because it's not fully approved
<igc> awilkins: one pyrex file stills needs a review. Do you know pyrex by any chance?
<igc> I'd certainly love to see that change make it into 1.6, even though it missed 1.6rc1
<awilkins> igc: Alas, I don't really know Pyrex very well. I can confirm it builds on windows though ;-)
<igc> awilkins: are you or markh doing the windows 1.6rc1 installer?
<igc> I guess we could always consider including it in there if that file gets reviewed in the next few hours
* Peng changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | please test 1.6beta3 | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | http://blogs.mysql.com/kaj/2008/06/19/version-control-thanks-bitkeeper-welcome-bazaar/
<Peng> (1.6b2 -> 1.6b3)
<awilkins> jam: Which toolchain are you building that pyx on (mingw or msvc?)
<igc> yep, I meant 1.6b3, not 1.6rc1 sorry
<igc> awilkins: I believe he is using mingw
<awilkins> Hmm, I think there are good reasons to use msvc
<awilkins> 1) Python is built with MSVC
<jelmer> 'morning igc, Peng, awilkins
<awilkins> I suppose it doesn't matter too much depending on how many what your deps are built on
<igc> hi jelmer
<jelmer> igc, thanks for the review
<awilkins> For example, bzr-svn pretty much has to be built on msvc for win32 because it has deps that are msvc flavoured
<Peng> jam: With the push-and-update plugin and bzr.dev, as of a few days ago, the "This transport does not update the working tree" message no longer gets swallowed.
<Peng> jelmer: Good morning. :)
<jelmer> hi Peng (-:
<igc> jelmer: np - sorry it took so long. Been less than healthy so my reviewing has been on hold lately
<lifeless> Peng: I think future bzr-search loggerhead foo will be microbranches off trunk
<Peng> lifeless: Okay. :)
<lifeless> abentley: so, what do you need info wise for the squid instance of bb
<awilkins> igc: If you trust me, you can have a 1.6b3 installer (with/without fast walk)
<igc> awilkins: I trust you. The main issue is coordinating with markh. I know he's been making changes to the installer so that TortoiseBzr is an optional install. It would be nice to have that IMO.
 * markh 's ears prick up :)
<igc> I also know those installer changes didn't make it into bzr.dev
<igc> markh: hello!!
<igc> markh: poolie has released 1.6b3 tonight
<markh> I'm yet to catch up on your discussion, but it seems likely I will build the 1.6 binary for windows
<markh> damn poolie - hasn't he anything better to do ;)
<markh> awilkins: I agree msvc should be used
<igc> awilkins was offering to do the windows installer. He and I are interested in including jam's fast walkdirs patch in the windows installer but it still needs a bit more review by someone familiar with pyrex
<markh> I believe many of the developers would like to ensure the binaries can be built with cygwin though, even if just for their own personal use
<awilkins> markh: I have a 7.1 build environment (using the MS 2003 C++ toolkit, which had the optimizing compiler - they've since pulled it of the web)
<markh> I believe poolie is keen to get the current state of tbzr out too
<markh> I'm using the full retail version of that compiler
<poolie> hello markh
<poolie> yes i am :)
<lifeless> markh: I don't care about cygwin per se; I do care that a completely free toolchain works
<igc> markh: *lots* of us are keen for that!
<awilkins> markh: It's more the case that some things that gcc 4 series allows, MSVC (even 9.0) can't cope with
<markh> hi poolie :)
<poolie> lifeless: bb was performing ok for me a while ago
<poolie> hm but apparently not now
<awilkins> markh: And also some of dependencies are built with msvc 7.1 ; in the case of bzr-svn you just can't link to them if you build using mingw
<lifeless> I clicked on merge requests, 15 seconds to dispaly :{
<awilkins> markh: Also, mingw is still on gcc 3.4 which can't cope with some of the C99 isms anyway
<markh> awilkins: so these things msvc doesn't support - do we really care?
<awilkins> markh: But I agree, completely free toolkit compatibility is not an optional feature
<jelmer> abentley, ping
<awilkins> markh: Had to patch a load of that stuff out of the new svn bindings in bzr-svn
<markh> I think it prudent to build everything using the official compiler for the python version we allow
<markh> s/allow/release with/
<awilkins> markh: In that case it was just sugar - convenient struct initializers
<markh> I've been meaning to look at the svn plugin for the binary release - still finishing qbzr at the moment.  So the problem is that msvc is struggling with the svn plugin?
<awilkins> markh: Not anymore.. but jelmer would have to tell you how well it works, I've been sending him test logs but not really using it
<markh> so what are we discussing? ;)
<awilkins> Which compiler to build releases with ?  :-)
<markh> I'm happy for someone else to build binaries, but that will require a little pain to bet tbzr working
<jelmer> awilkins, Any chance you can rerun that btw?
<jelmer> awilkins, There should be a fair number of errors fixed now
<awilkins> jelmer: Sure, I was just gearing up for it :-)
<markh> but that was due to it appearing I would be building things de-facto
<markh> um - my assuming I would build the binaries was due to that...
<awilkins> I've not got bzr.exe building yet because I don't use it
<awilkins> What are the deps for tbzr?
<markh> awilkins: so you have the svn plugin building as part of the binary build process, or you have a binary version of the svn plugin installed that you pick up?
<awilkins> markh: I build the bzr-svn pyd extensions myself
<markh> not much in the way of external deps - pywin32 is about all - but a number of patches to the build process that aren't yet in bzr.dev
<markh> and py2exe just finds and packages the plugin for you?
<awilkins> markh: Ahahahahaa
<awilkins> markh: Hang on... no, I'm not using py2exe
<awilkins> markh: I'm building python_installers
<markh> but you are talking about making binaries?
<markh> right...
<markh> ok, I'm with you!
<markh> I'm talking about stand-alone binaries
<igc> night all. have fun packaging 1.6b3 . It's looking like 1.6 is going to be a pretty impressive release!
<markh> you are talking about distutils installers?
<markh> 'night ian!
<markh> awilkins: bdist_wininst?
<awilkins> markh: I'm talking about 1) binary extensions (pyd) for bzr-svn 2) The win32 installers are (I presume) distutils ones - the ones that are a small exe / zip archive
<markh> right - how do you build that exe?
<jelmer> ToyKeeper, ping
<awilkins> markh: "make python-installer"
<markh> ahh - I didn't know about that target ;)  lemme look...
<awilkins> markh: The tricksy bits were configuring distutils to use the correct compiler environment for the pyd extensions
<markh> yeah - bdist_wininst!
<markh> so cool, we are talking about different things and not overlapping at all.
<awilkins> Groovy
<markh> but we appear to have a terminology issue ;)
<awilkins> I'm not building the the installer that installs bzr.exe because I don't use it (wanting to use bzr-gtk n'all)
<markh> yup - that is what I'm talking about - but will be bundling qbar instead of bzr-gtk it would seem :)
<markh> qbzr
<awilkins> Does that use qt4?
<markh> yep
<awilkins> Ah.
<markh> looks slick too
<awilkins> I think tbzr should be working to rip off as much as possible as of the TSVN UI
<awilkins> Because it's very mature and frankly, very good
<markh> not quite as advanced as bzr-gtk yet, but tons of potential ;)
<markh> yes, I agree tsvn has real world experience we can't even start to try and re-invent
<awilkins> A generic "TortoiseVCS" shell would be great for bzr, git, monotone, anything ; you need some new idioms for _D_VCS but other than that, it's great
<markh> yeah - that would be perfect - but I need to ensure we don't get distracted from ensuring the no 1 priority is tbzr.  But I'd love for the other vcs people to leech off the work I'm doing ;)
<markh> I plan on leaching off the qbzr project as much as possible - the more we steal, the more we all win ;)
<markh> that's why I love this industry ;)
<markh> (with their approval and support of course ;)
<awilkins> Agreed, it's nice working for a .gov.uk as well ; I have no worries about stupid commercial lawyer crap
<ToyKeeper> jelmer: ?
<awilkins> My current project has been fertile ground for OSS projects ; I've submitted patches to three or four on the back of it.
<jelmer> ToyKeeper, Never mind, just sent review feedback to your bzr viz diff panel patch
<markh> awilkins: nice :)
<fullermd> jelmer: By the way, when/why did viz stop letting me resize the columns?
<ToyKeeper> fullermd: IIRC, around r500 or r490
<ToyKeeper> That's one other thing I was thinking of fixing.
<jelmer> fullermd: Not sure, I don't think that was an intentional change
<fullermd> Mmm.  496.2.1, looks like.
<ToyKeeper> jelmer: BTW, I discovered the bitlbee-otr branch today.  Any idea if that's something which might get merged into trunk?
<jelmer> ToyKeeper: I don't think that's likely to be merged into trunk
<jelmer> ToyKeeper, it was pretty intrusive iirc
<ToyKeeper> It seems like an easier and more complete encryption solution than doing each protocol individually, but I don't know the details.
<ToyKeeper> The US is a scary place to talk unencrypted lately.
<markh> awilkins: do you happen to use bzr with password protected ssh keys?
<jelmer> ToyKeeper: That sort of thing should rather be done as a plugin, but I'll defer for wilmer for the decision on that
<ToyKeeper> jelmer: Okay, just curious.  I only discovered it today, and it was definitely not a trivial merge.
<awilkins> markh: Yes, I do
<awilkins> markh: I use pageant to hold onto them
<markh> awilkins: do you need to set BZR_SSH?
<markh> and do you have ssh.exe on your path?
<markh> (I understand you don't use ssh.exe - but it may still exist)
<awilkins> markh: If you install paramiko 1.7.3 it works without ; setting BZR_SSH to "plink" also works if you have plink on your path
<markh> yes - I'm particularly interested if you *do* have a copy of ssh.exe on your path as well though
<awilkins> markh: "ssh" appears to be an alias of plink on this machine (never tried that before)
<markh> right - damn :(
<awilkins> Aha.
<markh> no problem - it just means I need to do more testing ;)
<awilkins> I think it's because darcs for win32 rips plink off and renames it ssh.exe
<jelmer> ToyKeeper, reading the attached bugreport, it seems the general opinion is that otr should be in your irc client rather than bitlbee
<jelmer> since bitlbee may be on a remote host, etc
<markh> I *think* that if you have a regular (eg, cygwin) ssh.exe on your path, things may not work as desired, even with paramiko, without setting BZR_SSH
<markh> as I *think* ssh will end up preferred, and therefore not use pageant
<ToyKeeper> jelmer: For public servers, yes.  But for private ones it's not a problem.
<awilkins> markh: AFAIK cygwin do not recommend plopping the cywin bin on the path
<markh> (paramika does pageant even without plink)
<awilkins> markh: I use gnuwin32 for my *ix satisfaction (but I also have cygwin installed)
<jelmer> ToyKeeper: Still, it seems sensible to have that support in the IRC client rather than in the proxy
<markh> I have it set at my terminal sessions, not globally
<ToyKeeper> Having OTR in the client would make logging on the server pretty much impossible, if I understand correctly.
<markh> my global path I keep clean, and just have a "dev" environment in the dos boxes
<markh> (well, thats not strictly true, but the intent ;)
<awilkins> markh: You're tidier than me then :-)
<markh> I always answer "no" when someone offers to set my global environment - even the MS dev tools ;)
<awilkins> They come with a perfectly good ENV batch file
<ToyKeeper> Every bitlbee user I've talked to runs their own instance, and generally connects to it via openvpn or ssh.
<markh> exactly :)
<awilkins> markh: Besides, once you've gone through the pain of setting it up once, you forget less easily
<ToyKeeper> Anyway, off topic.  :)
<jelmer> ToyKeeper, Yes, but BitlBee doesn't log anyway
<abentley> jelmer: pong
<jelmer> abentley, I've updated my BundleBuggy but now it's broken :-)
<jelmer> abentley, Missing table "project"
<ToyKeeper> Ah, but dirproxy/bip/etc do, and they'd be logging encrypted junk.
<abentley> jelmer, downgrade.
<abentley> I haven't written an SQLite migration yet.
<jelmer> abentley: hmmok
<jelmer> abentley, I was actually thinking - if it was possible to do that migration, I could take my instance offline altogether
<jelmer> abentley: (migration of voters)
<abentley> jelmer: I already gave you the ability to create voters.
<jelmer> abentley: I wasn't aware of that, sorry
<uws> The .bzr/repository/obsolete-packs directory uses a lot of space in my repo
<uws> what use is it?
<abentley> jelmer: seejhttp://bundlebuggy.aaronbentley.com/project/bzr-gtk
<abentley> That should have a "add voter" link
<abentley> jelmer: You previously said that the ability for you to add voters was a prerequisite for switching.
<jelmer> abentley: Ah, thanks
<jelmer> abentley, Yep
<jelmer> abentley, I wasn't aware it'd been added in the mean time
<jelmer> Now I just need to figure out if there's no merge requests that're missing from your bundlebuggy
<abentley> Yeah, I was going to announce it, but I've been busy and sick.
<abentley> lifeless: I'm not sure what kind of info you mean.
<jelmer> abentley, Anyway, thanks for that. I'll keep mine down then.
<ToyKeeper> I wonder why hasattr swallows exceptions.
<markh> I'm not yet familiar with the release processes - but I don't understand why I can't see a lp:bzr/1.6?  Where does 1.6b3 live?
<awilkins> 1.6b3 is a revision of trunk
<awilkins> Is it tagged?
 * awilkins goes and looks
<awilkins> Hah, no tags at all
<markh> ToyKeeper: it kinda means "would getattr() work?"
<fullermd> It's usually around -rc1 that a branch gets created for a release.
<markh> not that I'm justifying the behaviour ;)  I think later version of Python only hide BaseExceptions, or something like that...
<awilkins> How do you chaps know which revision you tarballed up as b2 b3 etc ?
 * fullermd thinks "we don't" is the answer.
<ToyKeeper> markh: I always figured it reduced to something like "return (name in obj.__dict__)", but apparently not.
<markh> problem is the types have a C implemented "slot" for getattr - so it is closer to "return ob->tp_getattr(ob, name)==0;"
<markh> obviously that is an incredible over-simplification ;)
<Odd_Bloke> abentley: http://bundlebuggy.aaronbentley.com/project/pqm/request/%3C20080717114939.35d304df@lapbert%3E should have Superseded http://bundlebuggy.aaronbentley.com/project/pqm/request/%3C20080717112642.32820ec6@lapbert%3E (I believe).  The problem seems to have been caused by sending the second one before BB had received the first.
<markh> in so many ways
<markh> __dict__ is just what a number of those type slots use as implementation
<LarstiQ> markh: hmm, betas are new to me, I only ever did rcs
<LarstiQ> (release process wise)
<markh> hi LarstiQ!  How was the fesitval?
<lifeless> abentley: I hope you are feeling better
<lifeless> abentley: I mean, 'is it ready to roll if people send bundles'
<lifeless> uws: it helps in the presence of unreliable file systems
<abentley> lifeless: It's ready to accept bundles, but for now, only registered voters can vote.
<lifeless> uws: and it will be auto-cleaned as you make commits etc
<abentley> lifeless: I've set you up as the project admin, so you can add voters if you like.
<lifeless> abentley: cool thanks
<abentley> I've done the DB patch to enable random people to vote, but I haven't written the code yet.
<markh> so from a process POV, awilkins and I should just continue to use bzr.dev to build binaries?
 * markh prepares to show more ignorance...
<markh> so - does lp:bzr/1.5 have a formal relationship to bzr.dev?  "bzr info" doesn't seem to show one
<markh> and why can't I see tags for any older versions in bzr.dev?
<Peng> markh: For whatever reason, there aren't any tags.
<Peng> markh: And, release branches are branched off of bzr.dev, and usually merged back in a bit later.
<markh> but the branches don't show a relationship?
<markh> or am I not asking the right question? :)
<Peng> markh: Release branches are branched off of bzr.dev -- they're totally related.
<fullermd> He means in the stored branch locations.
<fullermd> There wouldn't be; they get push'd up there, never manipulated directly.
<Peng> Oh.
<LarstiQ> markh: great! Although I slep through parts of it, the location is rather incredible and I saw some really good acts.
<markh> Peng: so how do I get bzr to tell me about that relationship?
<markh> LarstiQ: anyone I would have heard of?  I quite like electronic music
<uws> lifeless: Ah, so the wasted space will be freed when I start working on this code?
<lifeless> uws: yes
<uws> Ok, thanks.
<uws> How do I change a repository from "create trees by default" to "create no trees by default" ?
<lifeless> owplease file a bug on bzr saying reconfigure should allow this
<lifeless> also, touch .bzr/repository/no-working-trees
<LarstiQ> markh: http://konemetsa.net/?c=2 is the full list
<awilkins> offtopic : MOo!  https://bugs.launchpad.net/launchpad/+bug/56125
<ubottu> Launchpad bug 56125 in apt "apt-get moo doesnt look like a cow" [Wishlist,Confirmed]
<LarstiQ> markh: I'll recommend a couple of those later when I have more cycles
<abentley> jelmer: If you try with Vincent again, it shouldn't prompt you for a username or password.
<jelmer> abentley: I was using a different email addres from him, that's why it was prompting me for a username+password
<awilkins> markh: I've not been using bzr.dev, I've been using release tarballs
<jelmer> abentley, or are you saying it should be fied now?
<abentley> jelmer: I know.  I've associated that email with his user now.
<jelmer> s/fied/fixed/
<jelmer> abentley, ah, ok
<markh> bbiab
<ToyKeeper> jelmer: Okay, the diff can be put at the bottom now.  Let me know if you like it.
<markh> LarstiQ: bugger, only DCOM rings a bell, but I'm pretty sure that isn't a band I'm thinking of :)
<markh> a couple of pointers would be nice though!
<markh> awilkins: that should work for me once the build changes to bzr.dev land and stabilize
 * awilkins has his first cup of tea of the day, finally
<lifeless> jam: good morning
<jam> hi lifeless, good afternoon to you
<jam> I'm trying to investigate further, but it would appear that 'bzr status' time has regressed in bzr.dev
<jam> then again, maybe its just because I'm off wall power right now
<awilkins> jam: Yeah, those crazy processorons need high voltage to accelerate them properly.
<awilkins> jam: I've seen misconfigured SpeedStep slow machines down even though they were plugged in.
<jam> Well, changing my laptop from "Performance Optimized" to "Max Power" changes the "bzr status" time
<jam> from 12s
<jam> down to 4s
<jam> And with my changes from 2s => 0.8s
<awilkins> Did you repeat with Perf op again?
<jam> So about 2-3x in 'bzr status' time
<jam> awilkins: yeah, it is reproducible
<jam> I just switched back to not kill the battery
<awilkins> Nasty
<jam> I don't know whether it is CPU or disk, but yeah, big difference there
<awilkins> Disk should be the same
<awilkins> I'm not aware of anything that changes spin speed and seek times on different power settings
<awilkins> The difference surprises me
<lifeless> I've seen it too
<awilkins> It's larger than I would expect, I would expect a linear scaling and I've never seen power management drop CPU speed to less than half, let alone less than 1/4
<lifeless> on linux at least its latency involved in some manner
<jam> real    0m1.226s
<jam> user    0m0.000s
<jam> sys     0m0.045s
<jam> Not a lot of cpu there
<jam> There is a "Power Usage" field
<jam> "Performance, System Temp, Fan Sound, Power Usage" are the individual tweak
<awilkins> Actually, do your changes reduce the number of Disk IOs?
<jam> awilkins: Well, my changes switch from calling FindFirstFile() on *every* file in the filesystem, to just iterating over each directory.
<jam> It wouldn't *have* to hit disk for it
<jam> but I don't know whether it does or not
<jam> Anyway, lifeless, no regression :)
<awilkins> I suspect that once it's read the MFT once it wont bother
<awilkins> jam: Your walk_files won't work on win98, but who cares....
<awilkins> jam: You have a comment # Some reserved stuff here   - don't you need to declare those fields, or does Pyrex take care of that?
<Odd_Bloke> thumper: Do you have any more work building on your queue-abstraction-2 branch?
<jelmer> awilkins, thanks for the updated log
<jelmer> I've fixed the issue with the separator being wrong in ignores
<awilkins> jelmer: You're welcome
 * awilkins pulls
<jelmer> One sec, haven't pushed yet :-)
<jelmer> I'm not quite sure what's going on with the "file already versioned" errors
<Peng> BTW, you guys all rock, and are doing an amazing job on Bazaar, bzr-svn, Launchpad, Loggerhead, and everything else.
 * Peng goes to bed.
<lifeless> night Peng
<awilkins> jelmer: Hmm, maybe I'll have a look at that then, being closer to the platens as it were
<awilkins> jelmer: I know all these "can't delete the temp folder" errors are annoying
<jelmer> abentley, Any chance you can add "lp:bzr-gtk" to the list of valid branch urls for bzr-gtk?
<philn> hi
<jelmer> hi philn
<philn> i upgraded bzr to 1.6 beta 3 this morning and bzr visualize doesn't work anymore
<jelmer> awilkins: Any clue as to why those "file already versioned" errors are occurring would help a lot I think
<jelmer> philn: What error do you get?
<jelmer> philn, and what version of bzr-gtk are you using?
<abentley> jelmer: okay, but I think it's better to use the real URL.
<jelmer> it's quite nice to be able to use "bzr send lp:bzr-gtk"
<philn> http://pastebin.com/m5e375dc4 bzr-gtk 0.93.0-1
<jelmer> philn, you'll need the trunk of bzr-gtk probably
<pickscrape> We're imminently going to be migrating from svk to bzr, and a colleague just asked me a question that I can't properly answer myself
<lifeless> pickscrape: shoot
<pickscrape> When checking out a working tree, he's under the impression that it will build up all files using the diffs from the bugingging of time, which to me sounds a little off :)
<jelmer> abentley, Any particular reason lp:bzr-gtk should be considered bad?
<pickscrape> beginning
<abentley> jelmer: It's not a real url.
<lifeless> pickscrape: no, we dontdo that :)
<jelmer> philn, yeah, you need to run bzr-gtk trunk
<philn> jelmer: lp:... ?
<lifeless> pickscrape: it would scale hrribly :)
<jelmer> philn, yeah, lp:bzr-gtk
<jelmer> abentley, bzr send could expand it (-:
<pickscrape> lifeless: yeah, I didn't think so. How does it work then? I know that svn store shole versions occasionally, but I'd imagine this is even more clever
<philn> then, can it run uninstalled?
<pickscrape> whole
<jelmer> philn, yes
<jelmer> though I guess directory services need public/private url support for thats first
<lifeless> pickscrape: we have a delta compression layer
<lifeless> pickscrape: in packs and knits this is just forward deltas, with a snapshot every time the delta chain sums to the size of the full text
<lifeless> pickscrape: so its capped at reading a total of the size of each file uncompressed
<abentley> jelmer: Yes.  That would probably be best.
<abentley> jelmer: Well, if bzr send expanded it for you, it would expand to bzr+ssh...
<pickscrape> Gah, compiz just threw my #bzr window off the screen in a wobbly fit :(
<abentley> And that's not a publically-accessible url.
<pickscrape> I'll wait for the logs to catch up to see what I missed.
<jelmer> abentley, Yeah - directory services would need public/private url support for thats first
<philn> jelmer: cool, works
<philn> thx, new bzr-gtk looks nice
<mars> hi all.  I just upgraded to bzr1.6b3, and I noticed that is goofed up my $PS1 prompt.
<lifeless> mars: hi, wop
<lifeless> woops
<mars> it activated /etc/bash_completion/bzrbashprompt.sh, and now $PS1=\u@\h:$(__prompt_bzr)\W\$
<philn> kthxbye
<lifeless> elisa - http://elisa.fluendo.com/download/
<lifeless> lp:elisa <- :)
<mars> lifeless, the neat trick is that it overriding what I have in .bashrc.  A new terminal gets the messed up prompt.
<lifeless> mars: yeah, I've marked our bug critical
<lifeless> now we need someone that knows bash prompt foo to fix it
<lifeless> *your*
<mars> lifeless, cool, thanks
<lifeless> mars: did you install the deb ?
<lifeless> mars: or get the tarball ?
<mars> lifeless, deb
<Odd_Bloke> abentley: BB doesn't seem to be processing requests.  The final email in http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/43992 doesn't seem to have been picked up.
<abentley> Odd_Bloke: A look at the mail queue suggests it's waiting to be processed: http://bundlebuggy.aaronbentley.com/mail/queued/msg.G5fC
<Odd_Bloke> abentley: Ah, didn't realise that you could look at the queue.  Thanks. :)
<pickscrape> What is the correct way to remove a working tree from a branch?
<jam> awilkins: So.. the Pyrex cdef stuff is just to let pyrex know that there are some members that you can address, and what type they are so it can do the conversion. It doesn't actually declare a struct in the C code, it assumes that it is declared in the included header.
<jam> awilkins: so no, you don't need to declare the reserved fields
<jam> And yeah, I thought about win98, and was going to point that out to bialix
<jam> Do you know if FindFirstFileA exists on Win98?
<Odd_Bloke> pickscrape: bzr remove-tree
<lifeless> jam: I believe it is\
<pickscrape> Odd_Bloke: excellent, thanks
<jam> lifeless: though probably as a plain "FindFirstFiles" I would guess... and not something *I'm* willing to code
<jam> but if someone wants to do it, I can point them in that direction
<jam> My big thought was to just make the code fall back to non-optimized if it isn't available.
<lifeless> jam: yes
<jam> mwhudson: Are you around? I just got an email saying I won a UK lottery, and I was wondering if you could pick it up for me
<jam> Odd_Bloke: Maybe you could?
<jam> :)
<jelmer> I thought mwhudson was in .nz these days?
<Odd_Bloke> jam: Sure, but I'll need Â£200,000 of processing fees.
<Odd_Bloke> Which you'll need to deliver to my associates in Nigeria.
<lifeless> jam: mwhudson is in NZ :)
<awilkins> jam: The docs I'm looking at now don't have a specific FindFirstFileW, but they do use TCHAR for strings (which equates to WCHAR on unicode platforms)
<jam> lifeless: yeah, I forgot he moved again :(
<jam> awilkins: If you look closer on the MSDN site, they start off by just talking about FindFirstFile and then later on say it will be FindFirstFileW for unicode
 * awilkins is in the UK, but I'd need a 2% processing fee to pick up your lottery win
<jam> awilkins: 2% is a lot better than the  Â£200,000 Odd_Bloke wants :)
<Odd_Bloke> awilkins: Whereabouts in the UK are you?
<jam> heh, I guess it is the same
<jam> apparently I won 1M
<awilkins> Western suburbs of manchester
<jam> Contact Mr. Pinkett for the claim of Â£1,000,000 pounds which youhave won in UK NATIONAL LOTTERY. Provide your Names, Address,Age,Occupation,Tel,Country Send: claimsoffice1@btinternet.com
<jam> Like... who would actually *believe* that? There isn't even any colored HTML to make be believe they come from a real scammer
<jam> *cough* lottery
<awilkins> Anyone who believes that a lottery hands out prizes to people without tickets is a bit dim, to be honest
<awilkins> But then again, they are only a little worse than the lottery itself
<awilkins> Both exploiting the same disease, just with different degrees of virulence
<jam> awilkins:  And state approval
<jam> At least in the US, most lotteries have to be state sanctioned
<awilkins> So do tobacco sales
<awilkins> The UK National Lottery does of course, give large amounts of it's profits to charity.
<awilkins> But it's telling that one of our better-liked tycoons offered to run the whole thing on a non-profit basis and was turned down.
<jam> awilkins: Well, I was always told that the lottery is just an extra tax on people that are bad at math
<jam> As I understand it, most state lotteries do make a decent amount of extra money
<jam> whether that goes to charity, etc.
<awilkins> jam: Yeah, I detest gambling ; I'm always amazed that people don't drive into Vegas, take a look around, say "hang on, how do they pay for all this glitz?" and then promptly drive out again
<jam> It depends on the level of gambling. I don't do it much, but when I do, I basically go in expecting to spend my $XX and be entertained for a while.
<jam> If you look at it as a simple entertainment expense, rather than a "I could win big $$" then it is a lot more manageable
<awilkins> jam: I can see the attraction from that sort of perspective ; I do enjoy it when I do it. But that supports the side of it that takes more than disposable income
<jam> yeah, the cyclical trap of "if I can just get back to even" ...
<awilkins> PLaying poker with buddies is probably fine. Playing with casinos is not, because the casino has no incentive to stop - presumably your buddies will stop taking your money if they suspect you can't afford it
<jam> awilkins: depends on your buddies :)
<awilkins> Well, a casino doesn't want you destitute either ; but that's so you can come back and lose some more
<jam> But yeah, playing in a semi-controlled environment
<Odd_Bloke> Also your buddies aren't systematically taking the money of people who can't afford it.
<Odd_Bloke> I hope.
<awilkins> Loius Theroux did a very good Vegas documentary
<awilkins> They have these guys who are just there to make high rollers feel welcome
<awilkins> Watching the guy on the phone negotiating to get this guy $3,000 on a casino gift card was astounding.
<awilkins> Presumably, that's $3,000 _value_ and not cost
<awilkins> And the man was a few tens of thousands down.
<jam> My wife visited vegas with a friend from out of the country who had some $$ to spend
<jam> And they really treat you well when you are willing to lose :)
<jam> Complementary meals, lodging, all kinds of stuff
<awilkins> Yeah, this guy was staying in a suite with more floor area than my house
<awilkins> And all on the casino
<awilkins> The real estate must have been very cheap in the beginning ; just a patch of desert
<awilkins> Maintaining it must cost a ton ; water, AC, pretty lights, etc.
<awilkins> Someone should work out how environmentally unfriendly Vegas is
<lifeless> it is the city of sin
<Odd_Bloke> Where's Al Gore when you need him?
<awilkins> http://green.thefuntimesguide.com/2007/04/las_vegas_energy_use.php
<awilkins> Ouch. So, that's 20 MWh of electric per resident, whereas 'mercans use 10MWh per HOUSE on average.
<awilkins> (hotel resident)
<awilkins> Or maybe residential residents
<uws> Can I remove files in .bzr/repository/obsolete_packs, lifeless?
<uws> They seem not to get removed after committing
<uws> 974M	.bzr/repository/obsolete_packs/
<uws> almost 1G
<pickscrape> A colleague is getting this error when trying to checkout: "org.freedesktop.DBus.Error.Spawn.ExecFailed: Failed to execute  dbus-launch to autolaunch D-Bus session". Anyhting obvious I should be looking at?
<uws> pickscrape: the bzr-dbus plugin perhaps
<uws> pickscrape: try unsetting DBUS_SESSION_BUS_ADDRESS or DISPLAY and see if it persists
<james_w> pickscrape: if they are on Debian or Ubuntu then installing dbus-x11 might help.
<pickscrape> james_w: thanks, I'll ask him to try that
<lifeless> uws: the first autopack will trigger removal
<beuno> abentley, http://paste.ubuntu.com/28043/
<abentley> beuno: What were you voting on?
<awilkins> bzr viz
<awilkins> oops
<beuno> abentley, http://bundlebuggy.aaronbentley.com/vote/%3C20080717133839.GA30741@vernstok.nl%3E
<beuno> http://bundlebuggy.aaronbentley.com/request/%3C20080717133839.GA30741%40vernstok.nl%3E
<abentley> beuno: The error message looks accurate to me.  You're not a voter on the Bazaar project, and that merge request is for the Bazaar project.
<abentley> If you change the request to be a bzr-gtk merge request, then you can vote on it.
<beuno> abentley, that fixed, thanks
<uws> lifeless: but can I remove the contents of that directory manually? I need the disk space. now! :)
<lifeless> uws: yes, leave the dir behind though
<pickscrape> uws: That fixed the problem for him, thanks! I'll document accordingly...
<GaryvdM> Hi luks
<GaryvdM> I've got qdiff to load 1 diff at a time, and update the ui.
<beuno> lifeless, is bzr in LP extremely slow for you too by any chance?
<GaryvdM> I'm now trying to move the loading to a thread.
<GaryvdM> I copied the ProxyToMainEvent class and to_main method from mb picard.
<luks> GaryvdM: please don't, threads will not help in python at all
<GaryvdM> But I can't get the event to call.
<GaryvdM> My code is at lp:~garyvdm/qbzr/diff-images
<luks> it will run only in one thread at a time, and since bzrlib is all python it will use all the cpu anyway
<luks> the beauty of python's gil :(
<GaryvdM> I'm hoping you can help me out.
<luks> I can take a look, but I'd really rather not see threads there
<luks> can't see anything obvioust from the diffs, I'll try it later
<GaryvdM> The reason I wanted to us a thread is that I can't call QtCore.QCoreApplication.processEvents() in the middle of loading a large file. so the ui locks.
<GaryvdM> *use
<luks> GaryvdM: but using threads will not help that much
<luks> due to the GIL it will keep switching between the GUI thread and the loading thread
<luks> which will result in blocking as well
<lamalex_2> hey guys, I have two branches that do not have a common ancestor, is there a way to merge them? they contain many of the same files, One is an upstream project we forked
<GaryvdM> Maybe we don't need it.
<GaryvdM> Ok - no thread...
<awilkins> jelmer: Ping?
<GaryvdM> luks: I think rather leave it. Scrolling is a bit slow when loading a large diff - but not bad...
<GaryvdM> I call QtCore.QCoreApplication.processEvents() after each file...
<luks> GaryvdM: I'll try it, but I don't think a thread will help with that
<LeoNerd> bzr diff | diffstat   <== any way I can use my .bazaar/bazaar.conf  to automate that?
<james_w> I think there is a diffstat plugin
<james_w> you could also use a shell alias
<james_w> but no, there's no way to do that with bazaar.conf
<GaryvdM> luks: I agree now  - threads won't help much - so I have dropped that idea
<GaryvdM> I've push a working version that does not use thread to lp:~garyvdm/qbzr/diff-images .
<lifeless> beuno: seems fine
<GaryvdM> I want to squash some regressions and then look at merging to trunk.
<beuno> lifeless, it seemed to be something else locally, thanks  (bzr 1.6rc in PPA screwed my shell)
<GaryvdM> Regressions are: no line under file info, and no interline diffs.
<luks> yep, on my todo list
<luks> the lines seem to be tricky
<GaryvdM> How were they done before? in the paint event?
<luks> yes
<luks> but I wanted to move that to the document, to make copy/paste work on file info
<GaryvdM> I think I found a way.
<bkor> jelmer: are you sure you mean bug 242787 ? there is no info in that bugreport
<ubottu> Launchpad bug 242787 in buglog-data "[testbug] auto-created by python-launchpad-bugs" [Undecided,Invalid] https://launchpad.net/bugs/242787
<beuno> jelmer, BB keeps insisting that your patches are for bazaar and not bzr-gtk
<beuno> see: http://bundlebuggy.aaronbentley.com/request/%3C20080717121324.GD1834%40vernstok.nl%3E
<pickscrape> The work done on bzr-gtk looks very interesting. When is a release expected, or does that depend on 1.6?
<strk> how do I create a branch w/out working tree again ?
<strk> bzr help branch doesn't say
<lifeless> strk: is controlled by the repository; if you want to do it manually you can by 'bzr init foo; bzr remove-tree foo; bzr pull -d foo SOURCE'
 * HarryR wonders if bzr-svn supports 1.6 yet :/
<strk> lifeless: what's 'foo' and what's 'SOURCE' ?
<lifeless> foo is the branch to create; SOURCE is the branch to make it from
<lifeless> strk: but the answer you had in #gnash is already correct :)
<abentley> jam: around?
 * strk continues on #gnash :)
 * HarryR downgrades to bzr 1.5 instead
<lifeless> abentley: ping
<abentley> lifeless: pong
<lifeless> HarryR: yes bzr-svn does, but there is no build of it in the ppa
<lifeless> abentley: BB - did it notice my woo 2 test ?
<HarryR> ah
<abentley> lifeless: Yes: http://bundlebuggy.aaronbentley.com/project/squid/request/<1216300191.2781.110.camel@lifeless-64>
<abentley> God, do I hate these "friendly" urls.
<abentley> lifeless: A reply was sent by Bundle Buggy, but it's being held for moderation.
<lifeless> abentley: Ah, I missed that it was from me so noone else could see it :)
<abentley> I tried to set up bundlebuggy@aaronbentley.com as a subscriber, but that apparently didn't take.
<abentley> lifeless: I really don't like using email for things like that.
<lifeless> <things like that> ?
<abentley> manipulating mailing list subscriptions.
<abentley> I can has web UI?
<abentley> It
<abentley> has been 3 days since I confirmed that I wanted that address added.  No response yet.
<awilkins> jelmer: Looks like it's trying to add a file - it starts with SVN:r1 but when it gets to SVN:r2 it thinks it's a brand new file (even though it's a modify), and gives it a new file_id
<jelmer> awilkins: but earlier on in that function it deletes the file from the inventory
<jelmer> so I wonder why that's failing
<awilkins> jelmer: Meh? this is in the middle of a sprout
<jelmer> awilkins: it's being raised from the close() function in fetch.py, right?
<awilkins> jelmer: Looking at the log of the svn repo, the operation it's trying to do is the edit of hosts in r2
<lifeless> abentley: meh, suqid dev list mgmt is a bit silly IMO
<awilkins> jelmer: Yes, the first such error in the log
<awilkins> bzrlib.plugins.svn.tests.test_branch.WorkingSubversionBranch.test_fetch_replace
<awilkins> jelmer: The error is occurrring on r2 in trunk, not r6 in the branch
<awilkins> jelmer: The extensions are calling add_file instead of open_file and then apply_textdelta (I think)
<jelmer> awilkins: that's kinda weird
<awilkins> jelmer: I presume it doesn't do this on your OS?
<jelmer> awilkins: in the case of that particular case it does
<awilkins> You can stack dump the proper trace by inserting "assert file_id != '2@6f95bc5c-e18d-4021-aca8-49ed51dbcb75:trunk:hosts'" at line 314 of fetch.py
<awilkins> That revid should never exist, there is never a new file called hosts at r2
<awilkins> Not screwed up the order of svn_delta_editor_t or something have I?
<awilkins> Hmph, looks fine
<HarryR> yay finally, `bzr branch` on a svn tree works after downgrading bzr, subversion & neon
<jelmer> awilkins: there is - there is a replace action happening at that point, no?
<awilkins> jelmer: No, this is revision 2 of the repository
<awilkins> jelmer: It's a modify
<awilkins> jelmer: The replace is in revision 6
<awilkins> jelmer: I'm looking at the repo log - because of the windows tempfile bug, the repo is still there
<jelmer> awilkins: ah, you're right
<jelmer> it doing an add there is definitely wrong
<thumper> Odd_Bloke: the queue-abstraction-2 branch on LP is as far as I have got right now
<jam> abentley: sorry I missed your ping, what's up?
<abentley> I think you're moving PlanMergeVersionedFile in the wrong direction.  It was turning into a VersionedFiles implementation, and you seem to be turning it back into a VersionedFile implementation.
<jam> abentley: for which part?
<jam> the add_rev stuff in the test suite?
<abentley> get_parent_map
<jam> That is just because it is *far* easier to do
<jam> I don't believe I touched get_parent_Map
<jam> abentley: I'm curious for more info. The problem *I* ran into is that most of PMVF uses tuple keys
<jam> but self.get_lines() uses plain revision ids
<abentley> Well, I got a conflict there the first time.
<abentley> Maybe I misinterpreted why.
<abentley> jam: I agree that get_lines is annoying.  Our merge code should move to using the VersionedFiles API anyhow, though.
<jam> abentley: Is it because of Jelmer's VirtualVersioned files code?
<jam> PVMF.get_parent_map() certainly looks like it is using keys
<jam> The only question is the NULL_REVISION issue
<jam> Is this correct:
<jam> if parents == ():
<jam>     result[key] = (revision.NULL_REVISION,)
<jam> Or is it supposed to be:
<jam> if parents == ():
<jam>     result[key] = revision.NULL_REVISION
<awilkins> jelmer: Are the parameters in ra.c:992  right?
<jam> Certainly there is confusion earlier:
<jam> if revision.NULL_REVISION in keys:
<jam>     keys.remove(revision.NULL_REVISION)
<jam>     result[revision.NULL_REVISION] = ()
<awilkins> jelmer: Stabbing in the dark a bit :-(
<abentley> I'm in the middle of overhauling get_parent_map so the answer is always (('null:',),)
 * jam no likey our current NULL_REVISION issues
<jam> Good
<abentley> jam: I'm starting to think that it would be a good idea to record that in the indices.
<jam> abentley: well, it would lead to less friction
<jam> but it makes me sort of wonder why we add it to the graph anyway
<abentley> jam: That would give us a way to distinguish between "no parents" and "I don't know what the parents are".
<jam> abentley: I thought we never had a "I don't know what the parents are" case
<jam> because we just didn't record the node if we didn't know
<abentley> jam: reconcile.
<abentley> jam: We've had the NULL_REVISION as a concept for a very long time.  Instead of sometimes having it and sometimes not, I think it makes sense to have it all the time.
<jam> abentley: I thought we introduced it because we had difficulties with representing ghosts, but I think we have that sorted out a bit better now, and I'm not sure what it really gives us.
<jam> I agree it should be all or nothing though
<jam> the current apis cause me grief
<abentley> jam: The concept of a null revision was part of the Bazaar design from the very beginning.
<abentley> I think it's very useful.  It's a revision that all projects have as a common base.
<abentley> It's a revision against which even your first commit can be a delta.
<abentley> jam: Spelling it 'null:' was more recent, and that let us use None for other things.
<jam> abentley: I suppose. As long as we solve the ancillary issues
<jam> Like is the parent of ('file-id', 'rev-id') => ('null:') or is it ('file-id', 'null:')
<jam> And the current mismatch
<jam> that you can get a parent of XX
<jam> but if you try to get the text for XX
<jam> it fails
<awilkins> jelmer: Performing the same operation (switch from url@1 to url@2) on teh command line works.
<awilkins> Phooey
<jam> And that accessing the parent_map has to filter to translate between the disk form and the memory form
<jam> etc.
<jam> Anyway, as it is a somewhat artificial construct
<jam> it hasn't been clear how it should be propagated throughout our apis
<jam> Also, there is a small benefit to being able to loop until you get no more entries
<jam> rather than looping until you hit NULL
<awilkins> Special class for the null: instance?
<jam> Like Graph and tsort both assume the graphs end with an empty set
<jam> which sort-of works with NULL, because *its* parents are empty
<awilkins> jelmer: You know you can simplify this code, switch works in all cases (I don't know if there are any performance problems with that)
<abentley> jam: The parents of ('file-id', 'rev-id') are (('null:',),)
<jam> abentley: so all revisions, inventories, file texts, and branches decend from the same object?
<jam> That doesn't sound quite right
<abentley> Well, I discussed it in #bzr, and that's what we came up with.
<abentley> And really, if the object represents nothing, and these things came from nothing, it doesn't seem far wrong to me.
<mtaylor> gaaaaahhhhhhh
<mtaylor> bzr-svn: Depends: bzr (< 1.4~) but 1.6~beta3-1~bazaar1 is to be installed
<mtaylor> sigh
<mtaylor> is there an up-to-date-with-current-bzr bzr-svn apt repo around?
<wingo-tp> good evening!
<wingo-tp> my bzr repository is corrupted: https://bugs.launchpad.net/bzr/+bug/239499 . i imagine other people that have imported from baz or arch might be in the same situation whenever it is that they upgrade repo formats. anyone want to poke that bug? :)
<ubottu> Launchpad bug 239499 in bzr "corrupt knit index on an old arch-imported bzr repo" [Medium,Confirmed]
<jam> mtaylor: not yet, unfortunately, jelmer hasn't had time to keep the archives up-to-date so it sort of lagged behind
<abentley> poolie: ping
<mwhudson> abentley: pretty darn early for poolie
<abentley> mwhudson: Yeah, though not for lifeless...
<mwhudson> lifeless is a special case
<mwhudson> in many ways :)
<lifeless> mwhudson: thanks I think
<mwhudson> lifeless: in good ways, yes
<mwhudson> :)
<mwhudson> lifeless: did you manage any groupcompress hacking today?
<lifeless> sadly no
<lifeless> but see my RFC
<awilkins> jelmer: Fixed that bug
<jam> http://jam-bazaar.blogspot.com/2008/07/this-week-in-bazaar_17.html has been released
<awilkins> But first I have to fetch a pint of milk to keep the wifelet happy.
<lifeless> jam: errata : 20GB of data
<lifeless> night all
<jam> lifeless: that is all?
<jam> There was a single pack file at 16GB
<poolie> abentley: hi
<poolie> hello lifeless and jam too
<abentley> poolie: Hi.  I had a question about some code you wrote.  Lemme just find it again.
<abentley> poolie: knit.py:2688 is that "if True" deliberate?
<LaserJock> if I install bzr from bzr.dev will it conflict with installed bzr packages?
<LaserJock> do I need to install bzr.dev to a different directory?
<wingo-tp> if you have bzr.dev and want to keep the installed package, don't install bzr.dev
<wingo-tp> just run it from the source repo
<poolie> lifeless: are you still here
<LaserJock> hmm
<poolie> i guess not
<LaserJock> I was wanting to install some related packages in Ubuntu, but they depend on bzr
<LaserJock> so I wondering if there is a common solution for that kind of case
<poolie> LaserJock: there is a way to tell dpkg 'pretend i have $foo installed'
<poolie> i don't recall it off hand
<poolie> alternatively, just install the system bzr and put your bzr into ~/bin or something
<LaserJock> I think I need to maybe re-evaluate why I'm using bzr.dev in the first place :-)
<LaserJock> I think perhaps I've gone down a rabbit trail I don't need to
<GaryvdM> luks: I've fixed all qdiff regressions that I am aware of. Any objections to merging to trunk?
<LaserJock> poolie: why is bzr 1.6 beta in the bzr PPA?
<LaserJock> poolie: shouldn't it be in the bzr-beta PPA?
<poolie> LaserJock: ah, because i mistyped :)
<poolie> or really, because i mindlessly copied from the checklist
<poolie> abentley, jam: i'm wondering if before 1.6 we should either
<poolie> a- rename development1 to a supported format or
<LaserJock> poolie: so is it really 1.5?
<poolie> b- make --stacked automatically give you this format
<poolie> i feel a bit strange about doing b and not a
<poolie> LaserJock: i don't understand
<LaserJock> poolie: the version in the bzr PPA says: 1.6~beta3-1~bazaar1
<LaserJock> is that really what it is or is it 1.5 mislabeled
<abentley> poolie: I think we should do "a".
<abentley> I'm not aware of any format considerations that would prevent it.
<abentley> I don't think we should make people use a "development" format to get advertised features.
<LaserJock> so .... what's going to happen with the bzr PPA?
<pickscrape> Did I read somewhere a while back about per-file commit comments being added?
<radix> WOO HOO
<poolie> abentley: and then b?
<poolie> radix: hi?
<poolie> pickscrape: yes, but in a plugin iirc
<radix> poolie: I am celebrating the release of a version of bzr with stacked branches :)
<radix> should I switch back to the non-beta PPA?
<mwhudson> radix: it's only 1.6b3, no release yet
<radix> well yes
<radix> whatever it's called, there's something I can apt-get
<mwhudson> indeed
<pickscrape> poolie: thanks, I was trying to figure out why I couldn't find it myself :)
<poolie> no, i should put it in the right ppa
<abentley> poolie: Doing 'b' is fine with me, but 'a' is the one I really care about.
<poolie> ok
<poolie> then i guess we should do both
<poolie> i was hoping to talk about it with robert
<poolie> i think he said it's ok with him to make it a released format
<jam> poolie: so... the only effect of the format right now is to enable stacking?
<pickscrape> Does anyone know of an example command (core or plugin) that takes a subcommand?
<jam> As in, it doesn't introduce rich roots, or btree indexes, or really anything else?
<jam> pickscrape: 'bzr shelf ls'
<jam> Plugin is bzrtools
<jam> poolie: it seems a bit much to require 'bzr upgrade' and only get stacking, when we have so many other things in the queue
<jam> Though I agree that it should probably be a fully supported format, just not a recommended upgrade until we get some more bits in.
<pickscrape> jam: Ah, yes I'd completely forgotten that shelf does it. Thanks fort he reminder!
<libwilliam> I was in here a week or so ago asking about this and someone helped me but I didn't implement it right away and forgot. So I am back for help. I am trying to test and see if a valid bug fixed argument is valid...
<libwilliam> Current I am getting a TrackerRegistry instance then calling get_instance("lp", branch) on it and it keeps returning bzrlib.errors.UnknownBugTrackerAbbreviation: Cannot find registered bug tracker called launchpad on BzrBranch6('file:///home/will/bzr/bzrtest/')
<libwilliam> whoops, I mean bzrlib.errors.UnknownBugTrackerAbbreviation: Cannot find registered bug tracker called lp on BzrBranch6('file:///home/will/bzr/bzrtest/')
<libwilliam> lp instead of launchpad.... the first one was a different test.
<libwilliam> So is this the right way to check and I am just not using the proper syntax or am I doing something completely wrong?
<poolie> jam, i'll check that but i believe it's just stacking
<GaryvdM> libwilliam: i you can remember when it was, the irc logs are here: http://irclogs.ubuntu.com/
<jam> libwilliam: I wonder if you need to do "import bzrlib.plugin; bzrlib.plugin.load_plugins()" before you do that
<libwilliam> Garyvdm, jam: thanks, I am scrolling through the logs right now to see if I can find it. If not I am going to try the load_plugins()
<igc> morning
<jam> igc: good morning
<colbrac> Is there a method that returns the rev_no of a remote branch? (Like a branch on launchpad)
<bob2> bzr revno url
<colbrac> no from a brzlib remote branch instance
<mwhudson> b.last_revision_info() ?
<bob2> revno does Branch.open_containing(location)[0].revno()
<colbrac> yay .last_revision_info does the trick. :) Thanks!
<spiv> jam: thank you very much for the reviews!
#bzr 2008-07-18
<jam> spiv: Yeah, trying to clear out my inbox generally has good results for others :)
<jam> abentley: BB doesn't seem to be noticing my reviews, nor is it giving me the automatic :approve for patches from me? Can you tell why?
<abentley> jam: The mail queue is pretty deep: http://bundlebuggy.aaronbentley.com/mail
<jam> ah, ok
<jam> I guess me landing 5 patches in bzr.dev doesn't help
<jam> According to your earlier comments
<abentley> yeah.
<jam> abentley: also, some of them are pretty old: Tue Jul 15 04:50:37 2008
<jam> That is about 2 days?
<jam> ah, maybe that is 'frozen'
<abentley> The ones in the 'frozen' list will not be processed without my intervention.
<colbrac> Jelmers bb:approve messages on the bzr-gtk list today are also not coming through
<abentley> jam: I've tweaked the branch scanner to run set membership tests to find out whether a request was merged, as you suggested.  Much faster!
<FallenPegasus> is there a way to configure bzr to say something like "warning: you are about to push with uncommitted changes"
<jelmer> FallenPegasus, not at the moment afaik
<jelmer> if you think that is a useful feature, please file a bug
<colbrac> jelmer: Any idea how to fix that push PushResult problem?
<jelmer> colbrac, this appears to be a bug in bzr itself
<jelmer> colbrac, I see one implementation of pull() that doesn't return a PullResult
<jelmer> while the API clearly states that it should
<colbrac> doh..
<jelmer> Sorry, my bad - it's actually inside of a try so I missed it
<jelmer> I'm not quite sure what causes it then
<jelmer> though it seems like a bad idea to work around unexpected behaviour while it's unknown what's causing that unexpected behaviour
<colbrac> Which one of those BrzBranch#'s in bzrlib/branch.py is used you think?
<colbrac> LP page of the branch says format 6.. so I'd assume BzrBranch6 :P
<colbrac> hum.. I give up.. way too much abstractions for this time of night
<jelmer> colbrac, shouldn't be too hard to figure out if you use pdb
<colbrac> jelmer: you mean, after I learn to use pdb? :)
<jelmer> (-:
<colbrac> jelmer: That will be for another day. The dialogs took more time than I expected already.
<jelmer> colbrac, k
<jelmer> colbrac, thanks for those changes, btw. I'm really happy to see that happen
<colbrac> jelmer: The main window GUI will be more like removing a bandaid though... :o)
<colbrac> jelmer: One quick big pull
<colbrac> changing way too many lines in __init__
<colbrac> jelmer: But I'll wait till I have some comments on the changes I made to the locationbar location and the Bookmarks appearance
<jelmer> ok
<colbrac> jelmer: One more thing before I go: There were some approved merges on the vernstok BB that are not in the new BB. Will you merge them or must they first be resend to this BB?
<jelmer> colbrac, please resend them
<colbrac> jelmer: Tomorrow.. or like.. after some sleep :o) G'night all
<jelmer> :-)
<jelmer> weltrusten
<Peng> Hmmm.
 * igc lunch
<Peng> On Ubuntu with the PPA 1.6b3, bzrbashprompt.sh is running and making my shell slow, even though I'm not using it.
<jam> Peng: It seems the debian system auto installs everything in contrib/bash to /etc/bash....d/
<jam> you can rm the one file
<jam> and I think the packaging is going to be updated.
<Peng> If I rm it, it will be reinstalled next time I upgrade bzr, right?
<Peng> I replaced it with an empty file. All is right in the world now. :)
<jam> Peng: well, the next bzr version should *not* install that file anymore.
<jam> We didn't intend it to be installed, but didn't realize the installer said "install contrib/bash/*"
<jam> which used to just install a path-completion stuff
<Peng> jam: Ah.
<Grantbow> I'm getting the feeling that instead of using the CVS $Id:$ trick I have to do something like bzr version-info --python and check it in - am I getting warm?
<mwhudson> this doesn't look very happy: http://pastebin.ubuntu.com/28180/ :(
<mwhudson> bzr log --short over the hpss is broken?
<GaryvdM> Is it possible to add an option to a builtin command from a plugin?
<GaryvdM> I want to fix Bug 241889
<ubottu> Launchpad bug 241889 in qbzr "show merge --preview in qdiff window?" [Undecided,New] https://launchpad.net/bugs/241889
<GaryvdM> bzr merge --qpreview
<mwhudson> GaryvdM: yes
<mwhudson> unfortunately i don't really know the best way how...
<GaryvdM> Do you know of some where else that it has been done?
<mwhudson> https://bugs.edge.launchpad.net/bzr/+bug/249690
<ubottu> Launchpad bug 249690 in bzr "bzr log --short broken over hpss" [Undecided,New]
<Verterok> GaryvdM: xmloutput (0.4 series) adds --xml option to status, etc. It's not the best way to do it, but it seems to work ok.
<mwhudson> GaryvdM: i did this once: http://pastebin.ubuntu.com/28183/
<GaryvdM> Ok - that would work
<GaryvdM> Thanks mwhudson. I was able to do it.
<mwhudson> GaryvdM: cool
<jml> poolie: I've encountered an issue with the stacking stuff.
<jml> poolie: can I call you about it?
 * spiv ducks out for an hour
<lifeless> poolie: ping
<poolie> jml, sure
<poolie> lifeless: pong
<poolie> i fall off irc and everyone wants me :)
<jml> we always want you poolie
<igc> GrantBow: yes
<jml> poolie: skype or pots?
<lifeless> poolie: we have about 50 tshirts left; how do you feel about us giving them out at LRL
<poolie> lifeless: go crazy
<lifeless> thanks
<lifeless> erm wtf http://bazaar-vcs.org/ZoomQuiet
<lifeless> it doesn't seem quite spam
<lifeless> but its surely not topical
<lifeless> poolie: also, any feedback on the RFC: review support and partial commits would be nice
<lifeless> (doesn't have to be deep feedback)
<lifeless> ZoomQuiet is also doing japanese translations of bzr wiki pages. *blink*
<poolie> jml, let me reply to vila first
<jml> poolie: ok
<poolie> jml, call me? pots?
<jml> poolie: sure.
<kiorky> jelmer (and others): hello, i have strange segfault error on bzr-svn and i cant figure out why it comes. (li. 675 in ra.c seems to be problematic for me (where the segfault seems to appen). But i run in a special env. (all underlying libraries are compiled with prefix) and i want t be sure that it is not the env rather than bzr which is in fault. How can i debug efficiently that ? With gdb (then how?)
<kiorky> jelmer: what i want to do is just "import pdb;pdb.set_trace()", C way
<kiorky> jelmer: http://www.friendpaste.com/xjJTVvNv i get that as a start, must go out to work, seeya.
<lifeless> kiorky: hi, jelmer will be around in an hour or two; its early morning here in the UK
<kiorky> lifeless: one hour less from me :p (france)
<kiorky>    /B 29
<poolie> lifeless: ping
<poolie> lifeless: do stacking branches still actually require supports_external_lookups in the repository?
<poolie> i'm guessing yes, so that check knows it's ok for them to have outward-pointing references?
<lifeless> poolie: yes
<poolie> so to make stacking a non-development feature, we need a non-development repository format too
<poolie> with that set
<lifeless> poolie: yes, branch and repo format both
<lifeless> you can just take the development one and rename/tweak it if you want the shortest path. Ideally though you'd add another format, marked stable, and leave the devleopment one as is until 1.7 when it can be removed
<lifeless> poolie: did you see the rfc on review support in bzr?
<fullermd> Is there a reason not to pull the rich-root switch at the same time?  I thought that was targetted to 1.6 originally anyway...
<lifeless> fullermd: aaron said to me last week there were about 2 bugs remaining
<fullermd> Ah.  That's a good reason   :)
<lifeless> -> checkout
<poolie> lifeless: i did
<poolie> when i read it last night i was a bit averse to putting it in the core
<poolie> but, i guess it depends on whether you mean 'shipped with bzr' or 'getting its fingers in everywhere'
<lifeless> well
<lifeless> putting implementation aside
<lifeless> did it sound nice, would you use it
<poolie> it seems like it would integrate in an interesting way with content filtering, doesn't it?
<lifeless> would it be easy to use
<poolie> so 'the convenient form of this file has these extra hunks but pretend you can't see them'
<poolie> it does sound pretty nice
<poolie> i had a case for this just the other day with the pdb stuff in selftest
<poolie> i guess i could have made it into a loom thread
<poolie> i agree with you that the git index is interesting but the wrong way around imo
<lifeless> back after I checkout
<lifeless> back
<lifeless> poolie: so I want to preserve the 'what diff shows you is what is committed' assertion
<lifeless> I don't know that content transformation is a good fit with hunk marking
<jelmer> 'morning
<awilkins> Morning
<awilkins> I see win32 became a first-class beta citizen
<awilkins> A shame that configuring it to compile those extensions is such a PITA
<jelmer> hi awilkins
<awilkins> jelmer: So, bzr-svn ; my thoughts are that 1) Update is redundant, because switch also works within a branch as well as across branches ; 2) Replay is probably easier once you get the path remapping working
<awilkins> BUt you've probably got my mail already :-)
<jelmer> awilkins: replay can only be used if the server has svn >= 1.4
<awilkins> jelmer: True, I wonder how many servers have not been upgraded. I think svn has been at 1.4 for some time.
<awilkins> jelmer: I suppose getting switch to work well and then implementing replay stops you ignoring bugs in the switch implementation :-|
<jelmer> awilkins: There's quite some out there
<awilkins> I suppose the last 1.3 release was only last June
<awilkins> I upgraded specifically for replay ; the bosses wanted a redundant backup server, so it mirrors to a second box using svnsync after every commit.
<jelmer> yeah, that's not something we can rely on unfortunately
<awilkins> Phhoey. Anyway, dis you test my patch? Does it produce a similar dramatic drop in bug count on Linux?
<jelmer> awilkins: No, that patch isn't required on Linux
<jelmer> I also couldn't find any indication that that was necessary in the Subversion headers
<awilkins> jelmer: This svn 1.5 or 1.4.6?
<jelmer> both
<awilkins> Hmm.
<jelmer> so I suspect there's something else going wrong
<awilkins> Ok, I'll shelve it and maybe we'll find something else wrong.
<uws> What is the fastest bzr repository format? rich-root-pack is deemed the smallest, but is it also the fastest?
<lifeless> well, gc-plain is the smallest, but its alpha today
<uws> Rebasing 3 revisions I have (3 minor patches) on top 4 newly added ones in the upstream tree takes like a few minutes
<lifeless> it should end up being the fastest too ;)
<lifeless> uws: please file bugs on performance things; generally you souldn't need to worry about formats.
<uws> lifeless: I wouldn't know what to say
<lifeless> uws: rich-root-pack is the best format to be using _today_ for bzr-svn branches
<lifeless> uws: 'I rebased and it was slow'
<lifeless> uws: :) - givint the branch url for what you rebased would help, and the command you ran
<uws> lifeless: I'm using bzr-svn branches indeed. pulling from svn is quite slow as well, but rebasing is bzr only right?
<lifeless> uws: I don't know if it is or isn't bzr only :)
<uws> the bzr-svn branch I'm using is NOT online :(
<uws> I've mirrored WebKit trunk
<uws> and launchpad doesn't have it in the vcs-mirror
<lifeless> uws: ah, thats ok. Just filing a bug is sufficient to start with
<uws> it took me a few days to build this branch
<lifeless> whee
<uws> I'll happily share it with launchpad if they want to
<uws> I can upload/bzr push, pas de probleme
<lifeless> uws: you could just push it to the bzr playground, or launchpad or ..
<uws> yeah, but having the "official" webkit mirror seems better
<uws> but the conversion hasn't been trivial :)
<lifeless> is webkit in gnome svn?
<uws> lifeless: can I push my ~1GB .bzr to launchpad? :s
<uws> lifeless: No, webkit svn
<lifeless> uws: sure
 * AfC recalls the 2 days it took to build the initial gtk+ branch...
<lifeless> uws: what was the command you ran? 'bzr rebase ... ...' ?
<uws> lifeless: "bzr rebase" ;)
<proppy> Hi, is there a way to convert a mercurial repository to bzr
<uws> lifeless: I'll explain my setup
<uws> repo  in webkit/
<proppy> (one way for importing the code to launchpad)
<uws> the .bzr/ dir in there is ~1GB
<lifeless> proppy: I think there is an hg fastexport frontend
<uws> 2 branches:   webkit.trunk  (without tree, parent is upstream svn+http url, I use this to pull upstream)
<lifeless> proppy: so the bzr fastimport plugin is the best way to do a one-shot conversion
<uws> other branch is webkit.uws, which is branch of the webkit.trunk branch
<uws> I have 3 small patches in webkit.uws. when I update webkit.trunk, I run "bzr rebase" in webkit.uws to stack my own patches on top of the upstream trunk version
<proppy> lifeless: ho just noticed there is also an hg convert to GNU arch
<uws> gnu arch is dead, proppy ;)
<proppy> :)
<proppy> googling for fastimport
<AfC> For what it's worth: I ran some experiments with rebase a few weeks ago. While it "works", the form of the command line UI seems to be very different than the rest of the code bzr commands. I kept getting tripped up as to what would happen to which branch.
<AfC> (and instead settled on good old `bzr merge -r X..Y` for cherry picks)
<uws> AfC: I think of "rebase" as a "shelve away all my own commits, then pull the other branch, and unshelve all my own commits"
<AfC> uws: yeah, I sorta got that at the end.
<uws> I want my patches to be on top of upstream, so that I can keep then in sync (and attach to bugzilla blah blah)
<AfC> uws: I think matters were complicated by the fact that I was also trying to cherry pick selected revisions at the same time. It made a loud splat noise.
<lifeless> uws: so, leaving aside the philosophical 'why rebase at all' discussion :) -
<uws> not sure what happens once they commit one of my patches upstream
<AfC> lifeless: :)
<lifeless> uws: all you run is 'bzr rebase', no arguments at all ?
<uws> lifeless: (I rebase because my patches need to be on top of trunk to keep them clean for upstream submission)
<lifeless> uws: you don't need to rebase to achieve that :)
<lifeless> uws: is http://svn.webkit.org/repository/webkit/trunk the url you bzr-svn'd ?
<AfC> Just merging trunk into your branch and then `bzr diff -r branch:../trunk` (?) should do it, no?
<lifeless> AfC: its the loom use case really, one thread per patch, serial merges
<lifeless> AfC: with a flatten operation at the final commit to trunk, for folk that want that
<AfC> lifeless: you say so :)
<uws> lifeless: Yes, that's the url.
<lifeless> AfC: I do!
<lifeless> uws: how many files do your patches change?
<uws> lifeless: all three of them just touch 1 file (3 different files in total).
<proppy> lifeless: what is bzr fastimport frontend for mercurial
<uws> all <5 line changes
<proppy> front-end | bzr fast-import -
<lifeless> proppy: yes; http://modular.math.washington.edu/home/mhansen/fast-export/hg-fast-export.txt has some stuff about hg-fast-export
<lifeless> proppy: fast-export is a standard for exporting and importing between many different VCS systems
<proppy>  These front-ends are bundled in the exporters/ directory of bzr-fastimport.
<proppy> :)
<proppy> ../bzr-fastimport/exporters/hg-fast-export.py -r ../protobuf-test/ | bzr fast-import -
<proppy> done thanks :)
<AfC> There are two possibilities, then: either the one shipping with bzr-fastimport is tweaked and fixed, being specific to Bazaar, or the one available from [someone in the] Mercurial [community] is newer and better, being from the foreign system who perhaps know their own system better.
<lifeless> uws: I have filed a bug
<uws> lifeless: CC me please, uws+launchpad@xs4all.nl
<uws> lifeless: I'm currently trying to push my webkit.trunk mirror to lp:~uws/webkit-open-source/webkit.trunk
<uws> wonder whether it'll work, and how long it'll take ;)
<lifeless> :>
<uws> at least I'm on 100MBit for the rest of the day :)
<uws> I created the branch in launchpad using the web page, and I had to supply --use-existing-dir to bzr push
<lifeless> yes, I think this is ugly :)
<uws> Hmmm. "copying inventory texts 2/5"
<awilkins> jelmer: I might be prepared to disagree with you on this "set_path" thing ; can you show me where the API says you _don't_ have to describe the revisions of every path?
<proppy> importing to lp done, thanks lifeless and AfC
<awilkins> jelmer: Of course, if the tests work on Linux, it's clear that something is behvaing differently ; but still, I can't find anything that says "if you don't pass any paths, it assumes that everything is revision N"
<lifeless> proppy: cool
<lifeless> uws: you are copied now
<uws> lifeless: Hm?
<uws> lifeless: ah, cc on the bug
<uws> lifeless: I'm at "copying content texts 3/5" for my webkit.trunk push ;)
<uws> but the repo is ~1GB ;)
<LeoNerd> It's likely been asked a hundred times before, but... Why-oh-why do I have to give a 'push' URL the first time I push a branch..? Can it not default to the parent, the place I branched it from..?
<LeoNerd> Similar for missing/pull/update/etc...
<luks> that's not always the place you want to push to
<LeoNerd> Not always, no. I suppose I could consider various other use-cases. But every time I've ever done it, that's what I've done. I imagine that's the most likely place.
<luks> I think in most open source projects people branch over http
<LeoNerd> OK... So just apply the default to the missing/pull/update case then...
<LeoNerd> bzr branch http://foo/bar. ... wait a few days... bzr missing => "bzr missing: no URL specified"
<LeoNerd> It would be nice if it just filled that in by default... even if I had to do the push one myself
<fullermd> Don't forget the location aliases abentley put in for 1.6...   very nice.  I just wish they were documented somewhere other than NEWS.
<jelmer> beuno, ping
<awilkins> jelmer: I'm trying to test bzr-svn on Linux and it just says "Aborted"
<jelmer> awilkins, what version of python?
<awilkins> 2.5.2
<jelmer> hmm, not sure then
<thumper> hi jelmer
<jelmer> any chance you can run it inside a debugger to see what it is aborting on?
<jelmer> thumper: Hi
<thumper> can bzr-svn import subtrees as branches?
<thumper> jelmer: I'm thinking of kde
<jelmer> thumper: yeah
<awilkins> jelmer: You'd have to give me a quick pointer as to how
<jelmer> awilkins: "make gdb-check" should do that for you
<thumper> jelmer: any idea on how it would perform with 750K revisions (kde has one big repo)
<thumper> jelmer: any given subtree will only have a fraction of those
<jelmer> thumper, apparently it does work - some people have used it, but the building of the cache takes a long time apparently
<jelmer> there has been work on allowing bzr-svn to not even look at the rest of the repository
<jelmer> but that's not finished yet
<thumper> jelmer: how long will it take?
<thumper> no pressure ;-)
<awilkins> jelmer: My installed bzr is not compatible with bzr-svn now, should I edit the makefile to point at my bzr.dev?
<jelmer> thumper, Not sure, it's not one of the highest things on the list
<jelmer> awilkins: yeah
<thumper> jelmer: where's the list?
 * thumper waves the priority wand :)
<jelmer> thumper, It's the bugs list in lp :-)
<jelmer> awilkins: Or just export the BZR environment variable to point at your bzr.dev
<thumper> jelmer: is the cache reusable across multiple subtree imports?
<jelmer> yes
<thumper> ok, not so bad then
<jelmer> It's about 2 gig though, from what I've heard
<thumper> memory or disk?
<awilkins> jelmer: Yup, figured that ; I'm now at a (gdb) prompt
<jelmer> awilkins, just run
<thumper> jelmer: thanks, gotta go now
<thumper> jelmer: I may well be in touch again later :)
 * awilkins pines for GUI debuggers
<jelmer> thumper: ok
<awilkins> I think I may need to install some more symbols
<jelmer> awilkins: There's a good GTK+ based one now I think
 * jelmer tries to remember the name
<awilkins> lots of "no debugging symbols"
<lifeless> LeoNerd: push is normally *not the place you branched from; at least IME
<awilkins> It's stopped in libc.so.6
<lifeless> LeoNerd: its only the single-developer case that you *can* push back to the place you branch from
<awilkins> Yes, doing these things "raw" makes you a real man... I'd rather be wimp with a cyborg exo-suit than a real man naked in the desert....
<lifeless> ;)
<awilkins> jelmer: Are you testing on x86_32 or x86_64 ?
<jelmer> I'm on 32bit
<awilkins> I'm on 64
<awilkins> I'm also trying to find th right debug symbols
 * awilkins installs the debug python interpreter
<awilkins> Well, that seemed to remove all the "no symbols" errors
<awilkins> Still about as clear as mud
 * awilkins has been spoiled by working in environment where the debugger just shows you the code that's busted :-)
 * awilkins installs insight and ddd
<jelmer> bug 127945
<ubottu> Launchpad bug 127945 in bzr-svn "Integrate creating new branch functionality into standard push/branch" [Low,Triaged] https://launchpad.net/bugs/127945
<jelmer> lifeless, ^
<colbrac> jelmer: What are the chances of you merging the OliveGui? :)
<jelmer> colbrac, I'd like to at least wait for phanatic to comment
<colbrac> jelmer: Ok.. at least it stills merges without conflict to the new trunk
<colbrac> colbrac: The pending 'status for folders' and 'fix for broken symlink' will cause conflicts me thinks
<colbrac> jelmer: ^ (doh.. stop talking to myself :P)
 * colbrac needs more coffee: 'fix for broken symlink' is already merged. 
<colbrac> jelmer: Could the 'sort bookmarks by title bundle' be merged? I promise I will remove the code duplication (which is present already) after the merge of OliveGui.
<jelmer> re
<jelmer> colbrac: You're yourself also free to merge changes into trunk (if they have been approved)
<colbrac> wow! Didn't know that about that. So you change your stance from resubmit to approve?
<jelmer> colbrac: If I voted resubmit I'd like to see a new submission to the list :-)
<jelmer> tweak means I'm fine to see the bundle go in iff the indicated changes in my review are made (without the need for further review)
<jelmer> I think I would actually like to see that one resubmitted
<colbrac> jelmer: Did you read my reply on the list about this? I still think adding another helper function now, while the whole duplication between _load_left / refresh_left will be removed soon is not really useful.
<jelmer> colbrac: I guess I could live with it then
<colbrac> k thx :)
<jelmer> colbrac, any chance you can review http://bundlebuggy.aaronbentley.com/project/bzr-gtk/request/%3C20080717123155.GA14537@vernstok.nl%3E?
<colbrac> jelmer: Will take a look at it, but it's unknown territory for me
<jelmer> It's a relatively trivial change
<colbrac> still.. I can't even figure out how to open that 'Search revisions' dialog :P
<colbrac> or is it that list that opens on the history button in olive?
<jelmer> colbrac, you need to have bzr-search installed
<jelmer> and that, in turn, needs bzr.dev or one of the 1.6 betas
<jelmer> mvo, hi
<colbrac> jelmer: The dialog doesn't disappear for me :/
<colbrac> jelmer: add .destroy() somewhere
<matkor> Is any transport faster thatn sftp: ??
<matkor> it takes minutes do update checkout with few lines changes ...
<lifeless> matkor: what project?
<matkor> lifeless: mine
<matkor> just I have big lattency link (crowded vpn)
<matkor> but it is still long time I think .. I wonder perhaps ssh+bzr: would be better choice ?
<mvo> hey jelmer! you pinged me earlier?
<jelmer> mvo: Yeah, I was trying to find some way to retrieve "Vcs-*" fields from the apt cache using python-apt
<jelmer> mvo: Is it correct that that's not possible atm?
<mvo> jelmer: give me a minute, I should be able to sent you a example
<lifeless> matkor: should be about the same usually; however latency hurts :(
<mvo> jelmer: you are right, its currently not accessable because there is no way to access the full record. let me add it to the python-apt source
<jelmer> mvo, Cool
<mvo> jelmer: I can put a new version into my ppa, do you need hardy or intrepid debs?
<jelmer> mvo: I'm actually on sid but I guess hardy is most useful for me at this point :-)
<jelmer> colbrac, are you sure you meant resubmit rather than tweak?
<colbrac> :) hum, yeah you are right.. I trust you can handle this without further review :o)
<jelmer> mvo, where is the main python-apt branch?
<mvo> jelmer: my development tree is at http://people.ubuntu.com/~mvo/bzr/python-apt/mvo/
<colbrac> I installed bzr 1.6b3 from the bzr-beta ppa but now I seem to have a bzr prompt as soon as I start a gnome-terminal for every folder I enter :/
<colbrac> that's a nice *feature* people :P
<Odd_Bloke> colbrac: I _believe_ that's an issue with the packaging.  Look in /etc/bash.d, perhaps.
<mvo> jelmer: I have a pbuilder sid environemnet here, I can build you a package if that is more convenient
<Odd_Bloke> ubottu: paste
<mvo> jelmer: I added a "Record" attribute to the PkgSrcRecord that gives you the full record
<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)
<colbrac> thanks to etckeeper I know it's done in /etc/bash_completion.d/bzrbashprompt.sh
<jelmer> mvo: Thanks
<Odd_Bloke> ja1: I'm getting http://paste.ubuntu.com/28287/ when I attempt to send you mail.
<jelmer> mvo: A sid package would be quite nice if it's not too much trouble :-)
<jam> Odd_Bloke: odd.. can you try sending directly to john@mail.arbash-meinel.com?
<jam> Love to put that in traceback ... ugh
<jam> anyway
<jam> try it
<jam> Odd_Bloke: I know I have a greylist which requires messages to be re-sent the first time they come through
<jam> but 550 doesn't look like the right error for that.
<jelmer> mvo: nevermind, bzr builddeb also seems happy with your branch
<Odd_Bloke> jam: I got http://paste.ubuntu.com/28288/ in my logs when I sent the email to john@mail.arbash-meinel.com.
<Odd_Bloke> jam: Though it's deferred (rather than bounced as previously) so I may have just hit the greylist for that.
<jam> Odd_Bloke: sounds like.
<jam> You can send again in a couple minutes
<jam> or just wait for it to retransmit
<Odd_Bloke> jam: I'll wait. :)  The initial error seems weird though.
<jam> yeah the 550 you were getting seems bad
<jam> I know I have a private mail server, and domainpeople just relay it to me
<jam> as a backup
<jelmer> mvo, The Vcs-Bzr fields still appears to be missing
<jelmer> mvo:while it does contain other fields such as Maintainer and Homepage
<jelmer> mvo, e.g. Cache()["bzr"].installedRecord["Maintainer"] works but Cache()["bzr"].installedRecord["Vcs-Bzr"] doesn't
<TejasPP> hi, is there any tutorial on how to write a plugin/hook? both user reference and user guide doesn't contain many information. they both say "look at the builtins.py". having a tutorial would be great
<NfNitLoop> TejasPP: I think you just volunteered to write one?  ;)
<mvo> jelmer: right, the vcs-bzr information is only available in the source package record, that is slightly more work to extract
<TejasPP> first I should figure it out! :D
<colbrac> exactly! :) That's what I did before I added info about giving back for bzr-gtk on the bzr wiki
<mvo> jelmer: http://paste.ubuntu.com/28291/ is a example, its rather primitive compared to the interface that works with binary packages
<TejasPP> so, there is no documentation on this other than user guide/reference and writingplugins page
<jelmer> mvo, Ah, my bad
<colbrac> jelmer: If I was going to try to move some import statements to the top of files in bzr-gtk and I find licence-less py files (like window.py), should I add a licence?
<jelmer> mvo, Thanks, that seems to work
<jelmer> mvo, that returns the data from the latest known version?
<jelmer> since Lookup() seems to return only a single object, rather than multiple
<mvo> jelmer: its a bad interface, you can run Lookup() multiple times and it will return multiple records (it will return false when there are no records left)
<mvo> jelmer: /usr/share/doc/python-apt/examples/sources.py is a example
<mvo> jelmer: on how to use it (this code predates my involvement with the project :)
<jelmer> mvo: Heh, ok
<jelmer> mvo, Thanks
<mvo> cheers! let me know if you need anything else
<jelmer> I'm fine for now... "bzr branch deb:<package-name>" seems to work
<lifeless> ooooooo
<TejasPP> do you know any example plugin which is well commented and easy to understand? or which functions I should look in builtins.py
<jelmer> TejasPP: any particular sort of plugin you're looking to implement
<jelmer> ?
<jelmer> TejasPP: New command, push hook, etc?
<TejasPP> jelmer: actually I'm trying to write a hook to indent files before commit
<TejasPP> but it would be good opportinuty for me to learn writing plugins
<TejasPP> jelmer: I'm reading docs and codes since last night and all I can is that: http://pastebin.ubuntu.com/28293/
<TejasPP> /all i can/all i can do
<jelmer> TejasPP, If you would like to do it pre-commit, you may want to add a start-commit hook
<jelmer> TejasPP, see http://pastebin.ubuntu.com/28294/
<mvo> jelmer: oh? that bzr branch deb:stuff is a plugin that looks for the vcs- header?
<mvo> jelmer: if so, where can I download the plugin :)
<jelmer> mvo: yeah - it works in a similar fashion to lp:
<mvo> (or bzr get it) :)
<mvo> that sounds *very* cool!
<jelmer> mvo: I've implemented it as patch to bzr-builddeb
<jelmer> http://people.samba.org/bzr/jelmer/bzr-builddeb/directoryservice/
<jelmer> mvo: ^
 * mvo bzr gets
<mvo> jelmer: works for me, that is hot stuff :)
<jelmer> cool :-)
<TejasPP> jelmer: I've wrote that: http://pastebin.ubuntu.com/28297/
<TejasPP> I think I need a list of files which is modified
 * lamont has a randomly-strange use case...  bzr update against a tree that has had an uncommit fails (for good reasons).  I want to force it to do the uncommit here as well.  is that doable short of rm -rf .bzr and re-branch?
<awilkins> That fast-wak-win32 patch is awesome
<awilkins> *walk
<awilkins> Status on a 28,469 element tree - 2 seconds
<lifeless> bit slow
<awilkins> :-P
<awilkins> Yeah, I'm doing this java thing that eats am XML model and spits ASP pages ... it's IO bound... well, it is on Windows
<awilkins> On Linux it takes the same time whether you output to RAM disk or real disk
<awilkins> And 1:35 instead of 2:30
<lifeless> jelmer: ping
<lifeless> jam: ping
<awilkins> I don't think jam is even here
<lifeless> lamont: for mirrors, don't use update; use a normal branch and pull --overwrite && bzr revert
<lamont> lifeless: cool
<lifeless> (I told Ng already)
<lamont> yeah
<lamont> fixing it is so much easier than teaching people to not use bzr uncommit on a published branch. :(
<lamont> and do I really not have a way to have per-branch hook scripts?
<liw> http://www.reddit.com/info/6sf0l/comments/
<awilkins> lamont: You could do a hook script that examines the revid of the first revision in the branch
<lamont> awilkins: I want diff hook scripts for diff repos, and don't want to have to change the hook script each time...
<lamont> I'd be more inclined to have a hook script that examined .bzr/$MUMBLE and ran it if it was there.
<lifeless> lamont: exactly
<liw> (interesting question on that reddit page, nothing interesting in the answers yet)
<lifeless> lamont: for instance, bzr-email checks for a email_to configuration item
<lamont> because lack of per-branch hook scripts is something that even clearcase didn't do.
<lamont> lifeless: that's a good place to start
<lifeless> lamont: which will pickup from  branch.conf or locations.conf or bazaar.conf automatically
<lifeless> la	don't conflate 'per branch' with 'code is instanlled locally'
<lifeless> damn, I mean globally. damn australian saturated email link fuckage
<lamont> lifeless: what I really want is something to bolt into uncommit that says 'no, you already published this, you ninny'
<lamont> lifeless: one of these days I'll take the time and corner the right people/docs to figure out how to get my use model in bzr:  one directory, lots of branches and switch between them when I want.  this one directory-per-branch thing offends my sensibilities.  (while I recognize that many people prefer that)(
<lamont> so yeah, what I really mean is "per repo" :-)
<lamont> and _that_ is conflation at its finest
<lifeless> lamont: so why should that *not* work on every branch? just check the public_ocation of the branch and if it is nothing cancel, otherwise try to connect and check
<lifeless> lamont - or better yet, record the last revision pushed in a hook, and then you can check locally
<awilkins> lamont: Make a no-trees repo, make a subfolder for the branches, put branches in it. Then make a checkout folder, and use `bzr switch` when you please
<lamont> awilkins: concept understood.  about 20% of the words in that sentence obviously require recursion...  hence "sometime when I'm not at work" :)
<lifeless> lamont: and yes, as awilkins says, we *totally* support lots of branches and switch
<lifeless> lamont: it is :
<lifeless> $bzr init-repo foo --no-trees
<lifeless> bzr branch THING foo/branch1
<lifeless> bzr branch foo/branch1 foo/branch2
<lifeless> ...
<lifeless> bzr checkout --lightweight foo/branch1 place-to-edit-source
<lifeless> cd place-to-edit-source
<lifeless> hack
<lifeless> bzr commit
<lifeless> bzr switch branch2
<lifeless> etc
<lamont> ah, and --no-trees means that it doesn't create a foo/branch1 directory mess under $CWD
<lifeless> no-trees means that 'bzr branch' does not give you the source code to edit in the branch directoy
<lamont> and can place-to-edit-source be "."?  (I expect not)
<awilkins> You still have a branch1 directory but it has no sources in it
<lifeless> lamont: yes it can be .
<lamont> ah, ok
<lamont> I'll play later, and hug my scrollback
<lifeless> lamont: (but I would tend not to use . because you wouldoften want several working trees with different CFLAG options etc
<lamont> those go in the exported source tree, which has .bzr nuked...
<lamont> and then sbuild chroots into the right place and does the build for me
<lifeless> right, well - give it a play
<lifeless> file bugs as appropriate
<lifeless> you'll prbably mneed to ignore foo if you have the checkout above it :)
<VSpike> If I want to split a source file into two smaller parts, is there any way to tell bzr of this?
<liw> that reddit thread makes it pretty clear already that people using cvs and svn really hate branching and merging
<liw> (news at 11)
<liw> VSpike, I was going to suggest "bzr copy" but it doesn't seem to exist, hmm
<LarstiQ> lifeless: speaking about copy, how are path tokens or a replacement scheme doing?
<VSpike> liw: I can't see any commands that apply, but yeah copy would make sense if it existed
<Odd_Bloke> liw: :D
<liw> VSpike, yeah, I'm thinking you should just start a new file and "bzr add" that as if it were completely new
<liw> VSpike, but you may want to wait a bit in case one of the people who actually know bzr wake up
<Odd_Bloke> AFAIK, it's not possible ATM.
<Odd_Bloke> The things LarstiQ mentioned would be ways of making it possible.
<LarstiQ> last time I paid attention there were concerns about troublesome copy semantics, but that was a while ago.
<liw> Odd_Bloke, I see you on that thread!
<pickscrape> Yesterday I accidentally upgraded to 1.6b3 because of it being accidentally uploaded to the wrong PPA, but now I can't get 1.5 to install again
<pickscrape> I uninstalled bzr, but reinstalling it just brings in the hardy version (1.3.1)
<pickscrape> I still have the PPA in my sources.list
<pickscrape> Oh wait...
<pickscrape> 1.5 isn't in the PPA for hardy
<pickscrape> That explains it. :) Anyone know when 1.5 for hardy will be uploaded to the PPA again?
<james_w> pickscrape: you could check /var/cache/apt/archives/ to see if it has the 1.5 version
<james_w> Martin seemed to hint that he was going to re-upload 1.5 to ~bzr and put 1.6b3 in ~bzr-beta-ppa
<pickscrape> james_w: unfortunately not :(
<pickscrape> We're going to be migrating from svk to bzr within the next week. Scary.
<awilkins> To be honest, I've used both and svk is much scarier than bzr
<pickscrape> Oh, I don't mean that bzr is more scary than svk
<awilkins> No, the conversion!
 * awilkins fears
<pickscrape> It's just a big change, and most of our developers really don't care about version control at all.
<awilkins> I'm having to teach bzr to a team of business modellers who've only ever used MKS (which is a sort of eveil propritary hybrid CVS) but automated via a huge lump of Java
<awilkins> Currently their tools sit still for 10 minutes every time you open them synching their files to MKS
<awilkins> Contrast this to about 10 seconds doing a bzr pull and they start to care about version control
<awilkins> I mean, the other team I work for had been contemplating for 2 years whether to use VSS or CVS, so I converted them to SVN in my first two weeks of employment and was accused of "having made the single greatest contribution to production quality on the project"
<awilkins> TortoiseSVN taking most of the credit for making it understandable to mere mortals
<pickscrape> nice
 * awilkins is a bit of a VCS geek
<pickscrape> Right now I'm struggling to get everyone to even have a play with bzr using the demo migration I've already performed for them.
<pickscrape> no doubt when we actually bite the bullet they'll then complain that they don't know how to use it
<awilkins> Any like-minded "pathfinders" in the group?
<pickscrape> You mean people who actually care? :)
<pickscrape> There are a few, yes
<awilkins> It took me a few days to get my head round it, and I've been admin-ing SVN and VSS for years, but it was less painful than learning to merge in svk
<awilkins> Concentrate on the few, not the many. A choir sings better than a soloist
<awilkins> better/louder
<pickscrape> svk has become unscalable for us. The depot size is now 12GB. pulling some branches is now impossible because it exhausts memory. Syncing some revisions also becomes a massive memory drain that people struggle to complete.
<awilkins> svk was a major improvement for me because I could take work home in a version-controlled way
<awilkins> Ouch
<pickscrape> Our main draw to svk was for the merge tracking.
<awilkins> Yes, I found that SVK really, really ate CPU for no discernible reason
<pickscrape> I even contributed to the SVK book a few years back.
<pickscrape> My name's still on it I think
<pickscrape> It just seems to have died though
<awilkins> I mean, it's pulling deltas from the server which it should be able to just shove back into your local depot raw ; why does it eat so much CPU?
<pickscrape> Yes, that confuses me too. And it seems to have got much worse of late too, inexplicably.
<awilkins> Esp. the Linux builds which actually work when using replay API
<pickscrape> The best thing though is that when you add, say, an image to trunk, that image gets duplicated every time you pull trunk to a branch
<awilkins> Replay doesn't save much though, it just means you don't have to report when you start a transaction
<pickscrape> One of the reasons why our depot got to 12G :)
<awilkins> That's... yuck
<pickscrape> Can you imagine the fun we have setting up a new developer? :)
<awilkins> How big is your converted bzr repo?
<pickscrape> We haven't imported history: too much chaff. the shared repo of the import of HEAD takes up about 79M, spread over a few separate repositories
<awilkins> I think my biggest repo is still under 2GB, but people are working on it, they keep checking in huge trees of XMLSpy documentation output and the like
<awilkins> If I can get the tip of 0.4 working properly in windows, I'll convert it over using bzr-svn and see where it goes from there
<pickscrape> following over 40k revisions of doing it wrong, we figured we'd start afresh and do it right :)
<awilkins> Any ideas about why that problem is occurring, jelmer?
<awilkins> pickscrape: Depends on how many branches you are supporting actively in the old depot I suppose
<pickscrape> awilkins: I think I need to migrate about 20 at the moment.
<Percept> Hi, can anyone direct me to some information how to use bzr (or any other CVS for that matter) with webprojects which have a database like MySQL?
<Percept> since the database is always located at another place then the folder with my files
<Percept> realises this is prolly a stupid question)
<Odd_Bloke> Percept: Normally you would only keep your database schema in version control, with something else to take care of backing your database up.
<Percept> Odd_Bloke: ah so it's not common practice to have the DB with content in version control then?
<Percept> Odd_Bloke: doesn't sepperating the db-backup from vc make the whole thing less managable? I'm really new to VCS but I really need to learn
<Percept> I read the user guide ... seems easy enough just didn't get how to deal with databases
<Percept> getting your database under VCS http://www.codinghorror.com/blog/archives/000743.html and http://www.martinfowler.com/articles/evodb.html
<jam> Percept: well, that also sounds like it is someone selling a product :)
<jam> I would generally always keep the schema under VCS
<jam> It sort of depends on how critical the *data* in the database is
<Percept> jam: the ccomments are interesting :)
<jam> Most DB's I've seen the database itself should be backed up, but the actual *data* wasn't something I would version
<Percept> which referred me to the second lin
<Percept> link*
<jam> Just like I would version the program I'm writing
<jam> but I wouldn't version the generated output
<jam> Reading the comments, they seem to be saying approx the same thing
<Percept> jam ok sounds logic (now ... was really lost on how people managed their DB's)
<jam> that it is the *schema* that they care about
<jam> The DBs I worked with had everything written in .sql files, and some python scripts to load that into the DB, and take care of stuff like upgrading.
<jam> I know Launchpad even has stricter rules for versioning. In that patches that make changes to the schema can only be landed at certain times, etc.
<Percept> I read something about luanchpad in the user docs but I don't really kno what it is yet
<Percept> gotta start ith the basics first :)
<Percept> with*
<LaserJock> is there a way to branch a specific range of revisions?
<LaserJock> I want to branch everything up to a certain revision
<cody-somerville> LaserJock, -r
<LaserJock> that only gets a specific revision
<beuno> LaserJock, -r ..X?
<LaserJock> wait no, cody was right
<LaserJock> the documentation messed me up
<TejasPP> jelmer, recently I saw your shell-hooks plugin and it's great
#bzr 2008-07-19
<daugustine_lap> hello, i want to set up a bazaar server with public checking out but then authenticated committing... is this possible? and if so, how do you set up the users, can they be the users already on the os?
<Peng> daugustine_lap: Usually you would use http for anonymous checkouts, then bzr+ssh for. committing.
<daugustine_lap> alright... and that uses the current system users cause it goes through ssh?
<Peng> Yep.
<daugustine_lap> alright, thanks
<alex-weej> is there something like giggle/gitk for bazaar?
<dato> alex-weej: `bzr viz` from bzr-gtk
<alex-weej> oo
 * alex-weej checks it out
<awilkins> Right, I'm off on my holidays, back in 2 weeks
<ozzloy> i want to push to a windows 2k3 server.  what's the minimum stuff i need to install to do that?
<ozzloy> on the win 2k3 server that is
<ozzloy> it doesn't even have ftp installed right now
<ozzloy> and if i can, i'd like to avoid.  is there a way to use bazaar itself to listen for connections?
<bob2> you can use ssh/sftp/webdav(experimental), too
<bob2> not sure if bzr:// itself has any auth yet
<ozzloy> bob2: what if i'm ok that it doesn't have auth?
<ozzloy> how do i make it so i can go bzr push bzr://192.168.1.100
<bob2> then you can just run 'bzr serve' to allow read-only access
<ozzloy> oh, so bzr:// without auth won't write
<ozzloy> ok then.  i'll see aboutsome other method
<bob2> no, bzr help serve
<bob2> I just don't really want to suggest something so insecure :)
<ozzloy> it's insecure, yes.  but i'm only doing it because my boss doesn't understand that every copy of the repo is completely functional
<ozzloy> and so having it on 5 or so computers isn't enough backup
<ozzloy> it has to be on the server that gets "backed up"
<ozzloy> aha, bzr serve will probably do
<ozzloy> thanks
<daugustine_lap> how do you get svn+ssh to work..., if anyone could help me out or point me to the right place, i'd appreciate it bunches, i'm having the damnedest time
<antoranz> Hi, Guys!
<antoranz> Have you heard that bzr has problems running on 64-bit boxes?
<bob2> no
<bob2> are you having a problem?
<antoranz> Today I saw the same kind of problem on two different boxes... one running SLES10 (unpathced, I think) and the other an OpenSuSE 10.2 (pathed... I think)
<antoranz> patched, i mean
<antoranz> I'll get the logs on monday and submit a bug then
<antoranz> There were no problems besides those two on the two boxes.... they were both Turion Boxes.
<bob2> I've not had any issues in 10 months running it on amd64, and I'm pretty sure the whole test suite has to pass on amd64 for every commit to trunk
<antoranz> could it be a distribution problem then?
<antoranz> what ditro do you use?
<bob2> debian and ubuntu
<antoranz> me two.. and I haven't seen the kind of problem I saw today
<antoranz> (ubuntu, mostly, by the way)
<antoranz> anyway.. I'll get the logs on monday and tell you how it was
<antoranz> (post a bug report, anyway)
<cody-somerville> bzr check shows:      1 inconsistent parents
<cody-somerville> should I do a bzr reconcile?
<Peng_> cody-somerville: That will fix it, but it's not like it's a big deal.
<spiv> cody-somerville: yeah.  Although it's not a very serious problem.
<Peng_> If you've gone to the effort to run check, you might as well reconcile.
<cody-somerville> Peng, well, I've noticed a performance loss lately and my branch is 46mb while if I export it, the actual stuff only takes up 1.4mb
<cody-somerville> Well, 2.4mb to be correct.
<antoranz> but export will only export a revision
<antoranz> that's not the repository per se
<Peng_> cody-somerville: One inconsistent parent is not going to give you bad performance.
<Peng_> cody-somerville: You're using packs, right?
<cody-somerville> I just upgraded tonight from knit
<cody-somerville> my branch only has 100 some commits but it has quite a bit of branch merging
<spiv> After an upgrade you might have a bit of junk in .bzr/repository/obsolete_packs.  You can save some space by emptying (not deleting!) that directory.  That won't make any difference to performance though.
<Peng_> cody-somerville: You might as well run reconcile, then. I don't think it will take long.
<cody-somerville> spiv, that'll improve initial branch times, no?
<pickscrape> Weird. My bash prompts is suddenly slower and shows bzr branch details if I'm in a branch directory.
<cody-somerville> pickscrape, mine too :(
<pickscrape> Something new in 1.6?
<cody-somerville> wow!
<cody-somerville> I
<cody-somerville> After doing the reconcile, bzr branch flew! :)
<Peng_> pickscrape: Yeah. It was an accident that it got installed.
<Peng_> pickscrape: Delete /etc/bash_completion.d/bzrbashprompt.sh to get rid of it if you want to.
<pickscrape> It's would actually be a pretty cool feature if it didn't cause such a drag on general bash performance
<Peng_> Agreed.
<pickscrape> Anyone know if 1.5 for hardy will make it back into the PPA before Monday? We're about to migrate to bzr so that's a complication I wasn't planning on having to deal with :)
<pickscrape> I suppose they could just try specifying feisty in sources.list
<Peng_> pickscrape: Well, using 1.6b3 shouldn't cause any problems (except with plugin compatibility.)
<pickscrape> And constantly complaining about getting the server upgraded :)
<Peng_> Heh, that too.
<spiv> cody-somerville: no, it won't affect initial branch times, the obsolete_packs are basically ignored by everything.
<cody-somerville> Peng_, spiv: Well, regardless, now that I've done the reconcile the branch took 43 seconds (and that included me entering my password) in comparison to 941.563 seconds
<Peng_> What took 941 seconds?
<cody-somerville> Peng_, initial branch
<cody-somerville> from launchpad
<Peng_> Ooh.
<docgnome> I'm have a bzr repo on my desktop that I keep all my emacs settings in. mostly I'm using it like a glorified rsync. I want to whack that machine though. If I unbind one of my checkouts on another box, rebuild my desktop machine and do a checkout on it, can I tell my other checkouts to rebind to the new place?
<bob2> as long as you remember to commit and update
<docgnome> on the checkout?
<bob2> commit on the desktop
<bob2> and udpate on the other machine
<docgnome> ah yeah.
<cody-somerville> How do I revision control bzr hooks if they exist under .bzr?
<Odd_Bloke> cody-somerville: You want the hooks to be part of the branch's history?
<cody-somerville> Odd_Bloke, well, I want the hooks to be downloaded with the branch so that they're always run
<Odd_Bloke> Well, off the top of my head, I'm not sure of a good way to do that.
<Odd_Bloke> I'd suggest posting something to the ML or asking a question on LP.
<pickscrape> I think there are security implication with that
<Odd_Bloke> As it's 3:30am here, I'm going to bed. :)
<Peng_> You can set up something so "make hooks" or whatever installs them.
<Peng_> And tell people to run it.
<Odd_Bloke> That seems reasonable.
<Odd_Bloke> *GONE*
<Peng_> Odd_Bloke: Good night.
<docgnome> /part/part
<docgnome> ...
<docgnome> fail
<Peng_> I love when people fail to exit. It gives you a chance to get a last word in.
<alfonsodg> Hello
<alfonsodg> i have a problem....
<alfonsodg> when i try to push a content in a new branch with: bzr push bzr+ssh://alfonsodg-pe@bazaar.launchpad.net/~alfonsodg-pe/edukt/main
<alfonsodg> i receive a message: bzr: ERROR: Transport operation not possible: readonly transport
<alfonsodg> any ideas?
<Yurim> Hi, I just shot myself in the foot with bzr. Is there anybode awake willing to help me reanimate my branch?  After some hours of work, i moved files from a subdirectory into the parent directory, removed the subdir and got now "ERROR: exceptions.AssertionError: Could not find target parent in wt: w3mimg/fb"
<Yurim> now i can't branch from this dead branch and "bzr st" raises an exception. how do i get the last revision?
 * Yurim sighs.
<Peng_> Yurim: This isn't great, but if you rename .bzr/checkout/, bzr should forget that you have a working tree.
<Peng_> Yurim: (Don't delete it though.)
<Peng_> Yurim: Are you using bzr 1.5 or 1.6b3?
<Yurim> @peng: ah, somebody listening. bazaar 1.3.1 from ubuntu
<Yurim> i can reproduce the bug
<Yurim> mkdir -p test_repo/subdir1; touch test_repo/subdir1/file1; cd test_repo; bzr init .; bzr add .; bzr commit -m "initial commit. 1 subdir, 1 file"; rm subdir1/file1; bzr rm subdir1; bzr st
<Peng_> Yurim: I can confirm that with bzr.dev. You should file a bug, if there isn't one already.
<Yurim> ok, i'll do that immediately
<Peng_> I think I remember hearing about something like that a few months ago.
<Yurim> @Peng_ Thank you very much. Removing .bzr/checkout was the thing i needed.
<alfonsodg> sorry .... any ideas about my problem?
<Peng_> "bzr branch" stopped working too? I wonder why it cares about the working tree?
<Peng_> alfonsodg: Err.
<Peng_> alfonsodg: Sorry, I hadn't noticed your question. If you're sure you're using bzr+ssh, I dunno.
<Peng_> alfonsodg: Are you using a modern version of bzr?
<alfonsodg> bzr 1.3.1
<alfonsodg> Peng_: included with ubuntu hardy
<alfonsodg> Peng_: i must to upgrade, right?
<Yurim> right, "bzr branch" stopped working too. that was the first thing i tried and after i saw the exception i began to panik
<Peng_> alfonsodg: It would be a good idea to upgrade, but I don't know if it will help here.
<bob2> have you tarred up the whole thing now so fddling won't break it further?
<Peng_> alfonsodg: (You can use the apt repo -- https://launchpad.net/~bzr/+archive )
<Peng_> Does the PPA seriously not have a version of bzr for Hardy right now? Oops.
<alfonsodg> Peng_: updating.....
<alfonsodg> Peng_: sure... i will install from sources.....
<Yurim> @bob2 sorry, i didn't see your question. no i haven't but after copying the whole directory and removing .bzr/checkout i could branch from this new directory and copy my changes from the old one. everything's back to normal again
<alfonsodg> Peng_: nothing... still the problem.......
<Peng_> alfonsodg: Can you push anywhere else? Are you sure you aren't accidentally using http? What's the exact command you're running?
<alfonsodg> bzr push bzr+ssh://alfonsodg@bazaar.launchpad.net/~alfonsodg/edukt/main/
<alfonsodg> bzr: ERROR: Transport operation not possible: readonly transport
<alfonsodg> Peng_: with this works: bzr push sftp://alfonsodg@localhost/~/example_dok
<alfonsodg>  bzr push sftp://alfonsodg@bazaar.launchpad.net/~alfonsodg/edukt/main/
<alfonsodg> bzr: ERROR: Permission denied: "/~alfonsodg/edukt/main": [Errno 13] mkdir failed
<Peng_> alfonsodg: Can you push to any other branches on Launchpad?
<Peng_> Ah-ha!
<Peng_> alfonsodg: That's a mirrored branch. Push to your server, not Launchpad.
<Peng_> alfonsodg: https://code.launchpad.net/~alfonsodg/edukt/main says it's a mirror of http://cosperu.com/EduKT , which doesn't exist. If you didn't intend to make it mirrored, it's easy to change.
<alfonsodg> Peng_: thanks.... in fact, the problem was in the launchpad side.....
<lifeless> moin
<Peng_> Good morning.
<Jc2k> moin
 * Peng_ wonders why a pull of bzr.dev has been running for a couple minutes.
<Peng_> Still going . . .
<Peng_> If I'm DoSing bazaar-vcs.org, well, it's your fault. :P
<Peng> Oh, good, it exited with "No revisions to pull" after 1030.762 seconds.
<Peng> Man, Mercurial's really got you guys beat. :P
<RAOF> That seems to be unusually poor performance for a noop.
<Peng> Yes, yes it does.
<RAOF> Oh, I'm pulling from launchpad, which may make a difference, but mine is 17s
<Peng> I know it's weird. It's usually only a few seconds.
<bob2> is your local branch the same format as /bzr/bzr.dev?
<lifeless> Peng: wtf
<lifeless> Peng: can you grab your ~/.bzr.log for the session and file a bug?
<fullermd> Pshaw.  hg isn't THAT much faster.  Why, it took me almost 10 seconds to pull 3.5 months worth of mutt changes.
<Peng_> Haha, "wtf" is a good reaction.
<Peng_> I just tried again. It took 3.081 seconds.
<Peng_> lifeless: I was kinda pulling 4 things at once, so my .bzr.log is messy.
<fullermd> I did have a bzr.dev pull go off into the weeds once a month or two back.  It spent several minutes using no CPU and doing no network transfer.  Killed it, restarted, and it ran normally.
<fullermd> I marked it up to "bizarre network crap".
<Peng_> Heck, I can't even tell which is which. .bzr.log should include the CWD.
<Peng_> fullermd: Yeah. It was probably something like a connection died and it took forever to time out.
<bob2> could pull trigger a local repack even if nothing is pulled?
<fullermd> I don't think so...
<Peng_> I doubt it.
<Peng_> If it would, it would've repacked last time it added revisions.
<Peng_> Also, it didn't trigger one.
<lifeless> uws: rebase bug fixed in a branch for you
<lifeless> jelmer: bug is fixed
<Peng_> Ooh, what bug?
<jelmer> lifeless: which bug ? :-)
<lifeless> jelmer: rebase slow
<jelmer> EMISSINGBUNDLE
<Peng_> Nice.
<jelmer> :-P
<lifeless> jelmer: EATTACHEDTOBUG
<lifeless> :P
<jelmer> at least lp didn't mail me about anything being attached to that bug...
<lifeless> https://bugs.edge.launchpad.net/bzr-rebase/+bug/249823
<ubottu> Launchpad bug 249823 in bzr-rebase "speed ftw" [High,In progress]
<jelmer> ah, it's a branch
<jelmer> malone doesn't appear to email if a  branch is attached
 * jelmer files bug
<lifeless> -> conf
<lifeless> jelmer: where is commit-notify?!
<LarstiQ> lifeless: bzr-gtk?
<kiorky> jelmer: any chance, you around?
<ChristopheT> Hi.  One can use "bzr ci --fixes x:id".  And then what?  It is visible with "bzr cat-revision" but can it be searched upon (to answer the question "in which revision was bug x fixed?")?
<bob2> ChristopheT: not sure if it is exposed by the bzr ui, but launchpad can use it (and maybe trac etc)
<Peng_> Launchpad uses it. Trac certainly *could*, but who knows if it does.
<kiorky> jelmer: it seems the progress function is bugged somehow
<kiorky> jelmer: i putted a "return;" at first statement in ra.c:py_progress_function as the first statement and then i was able to check out something
<uws> lifeless: rock on
<alfonsodg> Peng_: ping
<Peng_> alfonsodg: Pong.
<Peng_> peng ping pong
<alfonsodg> Peng_: in reference to https://bugs.launchpad.net/bzr/+bug/250022.... what's the procedure for fix a bug?... i found the problem but is my first bug with bzr /launchpad
<ubottu> Launchpad bug 250022 in bzr "bzr crashes after directory removal" [Undecided,Confirmed]
<Peng_> alfonsodg: Branch bzr.dev, start hacking?
<Peng_> But that might be a big one for someone new...
<alfonsodg> Peng_: nope...... the code is really easy.... great work... by the way... joining to bzr.dev
<Peng_> :)
<Peng_> You shouldn't direct that at me; I'm hardly a developer.
<Peng_> I fix the occasional typo in the documentation but that's it.
<alfonsodg> Peng_: ok.... but at least...... need some guides...
<Peng_> Well, there's http://bazaar-vcs.org/Documentation and the ./doc directory in the source tree.
<alfonsodg> Peng_: looking.... right... thanks
<alfonsodg> Peng_: i think that the bug was for bzr-gtk which doesn't have enough information.....
<alfonsodg> Peng_: my mistake
<colbrac> In bzrlib: I have a workingtree object and want to merge from a bundle. For a branch you use wt.merge_from_branch(branchobject). Where is the merge_from_bundle? :)
<beuno> Verterok, mornin'.   If you don't have anything fun to do today, you may want to try upgrading knits -> packs on xmloutput: https://code.launchpad.net/~guillo.gonzo/bzr-xmloutput/trunk
<Verterok> beuno: mornin'
<Verterok> beuno: ups, I already upgraded it, but only xmlrpc branch :P
 * Verterok upgrading trunk
<beuno> Verterok, :)
 * beuno is on a crusade to upgrade knits -> packs everywhere
<Verterok> beuno: bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format.
<beuno> Verterok, are you upgrading using sftp?
<beuno> (you can only upgrade through sftp)
<Verterok> beuno: bzr upgrade --pack-0.92 lp:bzr-xmloutput/0.4
<beuno> Verterok, bzr upgrade sftp://guillo.gonzo@bazaar.launchpad.net/~guillo.gonzo/bzr-xmloutput/trunk
<Verterok> ok, thanks
<beuno> we should really warn people when trying to upgrade via bzr+ssh...
<Verterok> indeed :)
<Verterok> beuno: done, the upgrade just finished. thanks for the tip.
<beuno> Verterok, cool, one down, 12 to go
<Verterok> :D
<Verterok> good luck
<bialix> luks: ping
<pygi> I see you're pushing KDE to bzr :)
<lifeless> hola
<Jc2k> lo
<Mecha25> Anybody here have time to help with debugging a BZR upload?  my client says it's uploaded properly, and launchpad says it has the structure, but that the directories are empty
<Mecha25> I tried reuploading, but it said all files were up to date, even though they're not there
<Mecha25>  anybody out there?
<Mecha25> 115 people in the room and everybody's afk
<Mecha25> jeez
<cody-somerville> I
<cody-somerville> I'm not afk.
<Mecha25> do you have time to help me debug an upload?  I've spent 2 weeks working on a plug-in for Gnome-do, and it'll be for nothing if I can't upload it
<lifeless> Mecha25: sure
<lifeless> Mecha25: run 'bzr info URL -v" where URL is the place you uploaded to
<Mecha25> URL including the LP: at the front?
<lifeless> yes
<Mecha25> standalone branch, format unnamed
<Mecha25> and gives me a location
<Mecha25> I uploaded the code before, it says it worked, but launchpad lists the branch as empty
<lifeless> Mecha25: whats the branch ?
<Mecha25> there's 2, I'll give you the simple one, I'll do the complicated one later
<Mecha25> lp:~mechaphoenix25/do-plugins/Grep-Plugin
<lifeless> Mecha25: have you done 'bzr commit' ?
<Mecha25> no
<Mecha25> bzr commit ï»¿lp:~mechaphoenix25/do-plugins/Grep-Plugin ?
<lifeless> Mecha25: if you haven't committed there is nothing to upload :)
<lifeless> Mecha25: three key commands:
<lifeless> Mecha25: bzr st
<lifeless> bzr diff
<lifeless> bzr commit
<Mecha25> ok
<lifeless> st shows you what will be added/deleted/renamed/altered etc
<lifeless> diff shows you the content changes of each file
<Mecha25> I've never used a version control system before, I know how to use diff though.  Thanks, it's been really confusing so far
<Mecha25> so I need to   ï»¿bzr commit ï»¿lp:~mechaphoenix25/do-plugins/Grep-Plugin ?
<Mecha25> from the directory containing the code?
<lifeless> just 'bzr commit'
<lifeless> after you use 'bzr st' and 'bzr diff' to be sure its going to commit what you want committed
<lifeless> after teh commit, you can do 'bzr push'
<Mecha25> ok... did the commit, and it threw me into vim
<lifeless> right
<Mecha25> exit it?
<lifeless> write a message describing your commit
<Mecha25> alright, then bzr st
<Mecha25> and bzr push lp:... etc
<Mecha25> ?
<lifeless> yes
<Mecha25> alright, one sec
<Mecha25> it says it pushed the revision
<Mecha25> ok, now what does a commit actually mean?
<lifeless> a commit records a directory structure and the content fo the files within it
<lifeless> a bit like a tar file
<Mecha25> ok, then what does bzr add do?
<Mecha25> I had to do that first I think
<lifeless> bzr add selects files to have them be recorded
<lifeless> files that have not been added are 'unknown' to thbzr
<lifeless> *bzr8
<Mecha25> ok
<Mecha25> so I create the branch, add the files, commit the tree, then push it?
<lifeless> yes
<lifeless> and then you can make further changes
<Mecha25> um... I did the push, it's still showing up as empty
<lifeless> commit the tree again and push again
<lifeless> Mecha25: run bzr log URL
<lifeless> Mecha25: where URL is the lp url
<lifeless> and look http://bazaar.launchpad.net/~mechaphoenix25/do-plugins/Grep-Plugin/
<Mecha25> says it uploaded, has my message
<lifeless> its all operating as normal
<Mecha25> um.... it still says empty on my end
<lifeless> Mecha25: what do you mean
<lifeless> uws: please let me know if the performance issue in rebase is better
<Mecha25> refreshing the page says it's still empty, but the link you sent me worked
<Mecha25> weird
<Mecha25> your link is what I'm viewing, and it says it's empty when I view it normally, and working when I view it from your link
<Mecha25> odd
<lifeless> what do yo umean 'view it normal'
<Mecha25> no, wait, you're on bazaar.launchpad, I'm on code.launchpad
<Mecha25> I mean go in from my launchpad profile
<lifeless> code.launchpad.net takes a few minutes to update its history listing normally
<Mecha25> d'oh
<Mecha25> alright then, I can wait
<lifeless> there is a issue right now I think, something backlogged
<lifeless> but it has worked
<Mecha25> wahoo!  I'll upload the other one, and chuck it on the mailing list
<Mecha25> thanks a ton, this open source development thing is finally paying off
<Mecha25> peace
#bzr 2008-07-20
<dvheumen> Hi, just a quick question, is there and if so what is the difference between having a branch and doing a commit and having a checkout and doing a local commit?
<cody-somerville> If you do a checkout and do a local commit, it doesn't push to the server.
<dvheumen> true, but if you branch from a server and do a commit then it also doesn't push to the server
<dvheumen> so that behavior doesn't seem so different (except from the default action)
<cody-somerville> dvheumen, yup.
<dvheumen> so the choice depends mostly on what you would like to do most of the time? If you'd like to work mostly centralized (for example at the office) then you'd do a checkout and when you're on the plane temporarily commit locally. And if you would like to work decentralized you'd branch and commit (locally) and only push once the piece is done
<cody-somerville> yup
<cody-somerville> There is a guide on the wiki for more info.
<dvheumen> Yeah I know, the problem is that the small differences between a branch, a checkout and a repository aren't that clearly described
<dvheumen> ow wait... on the wiki you say... I'm actually talking about the documentation on the website
<dvheumen> the reference guide and such
<dvheumen> ah, the website is a wiki, so now we're talking about the same thing again :P
<dvheumen> anyways, thanks again, that was all I needed to know :P
<Mecha25> anybody know why my bazaar.launchpad.net page has gotten my committed revisions and my code.launchpad.net page hasn't?  it's been over an hour since I pushed it
<Mecha25> hello?
<Mecha25> 113 people everywhere and not a voice is heard
<Mecha25> anybody out there?
<Odd_Bloke> ubottu: weekend
<ubottu> It's a weekend.  Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question.  Please be patient, wait longer than you normally would, or try again during the working week.
<Odd_Bloke> Mecha25: ^
<Mecha25> hey, finally somebody
<Mecha25> cool
<Odd_Bloke> Mecha25: I don't know, #launchpad is a better bet.
<Mecha25> thanks
<jelmer> kiorky, pong
<jelmer> hmm
<kiorky> jelmer: yep
 * Yurim nods.
<kiorky> with shared repository, do  the branches isinde the repo have .bzr directories?
<kiorky> I have understood the contrary with http://bazaar-vcs.org/SharedRepositoryTutorial
<lifeless> Keltia: they have .bzr directories, but the .bzr for each branch only has 'branch' not 'branch and repository'
<kiorky> ok
<kiorky> lifeless: do you know the status of nested trees support
<kiorky> i didnt find much doc on it
<kiorky> it seems to be implemented since .15rc1
<lifeless> I believe it is beta quality in larsiq's branch
<lifeless> core capabilities are done in the code base but not the UI
<kiorky> not in bzr.dev or one of the 1.6 beta's ?
<lifeless> no changes have been made to nesting uspport recently :(
<lifeless> I must go - breakfast awaits
<kiorky> have fun :)
<scippio> hello
<scippio> I have a problem with bazaar via webdav
<scippio> bzr: ERROR: Unsupported protocol for url "http+webdav://scippio:pass@repo.example.com/bbb"
<scippio> :-/
<Odd_Bloke> scippio: Are you trying to use the webdav plugin?
<pygi> isn't webdav plugin a bit broken atm?
<scippio> Odd_Bloke: yes .. i have this plugin
<Odd_Bloke> pygi: vila's fixed it up recently.
<pygi> while I have no idea who that is, good news
<Odd_Bloke> scippio: What version of bzr are you using?
<scippio> Odd_Bloke: 1.5
<Odd_Bloke> scippio: Ah, the webdav plugin requires 1.6.
<Odd_Bloke> That said, the only reason for that is that vila hasn't tested it with 1.5 enough.
<scippio> Odd_Bloke: hmm ... ok I  trying it... thanks
<Odd_Bloke> scippio: You could try just editing the requirements in the plugin and see if it'll work with 1.5.
 * Odd_Bloke --> breakfast
<scippio> Odd_Bloke: hmm and where is the version in webdav plugin?
<scippio> Odd_Bloke: hmm still unsupported protocol on 1.6b3
<bob2> bzr selftest bzrlib.plugins.webdav
<bob2> maybe just 'bzr plugins' will show if it is installed or not
<scippio> webdav plugin is installed ok
<scippio> [scippio@jerry bzr]$ bzr plugins
<scippio> launchpad  Launchpad.net integration plugin for Bazaar.
<scippio> webdav  Implementation of WebDAV for http transports.
<scippio> hmm ... webdav plugin is unusable :(    i must use ftp :/
<Odd_Bloke> scippio: Did you try running 'bzr selftest bzrlib.plugins.webdav'?
<scippio> yes
<Odd_Bloke> What was the outcome?
<scippio> [scippio@jerry bzr]$ bzr selftest bzrlib.plugins.webdav
<scippio> testing: /usr/bin/bzr /usr/lib/python2.5/site-packages/bzrlib (1.6b3 python2.5.2)
<scippio> ----------------------------------------------------------------------
<scippio> Ran 0 tests in 0.001s
<scippio> OK
<scippio> tests passed
<Odd_Bloke> OK, that suggests you don't have the plugin installed correctly, as I get 11 tests running.
<scippio> hmm
<Odd_Bloke> Wait, when and from where did you get the webdav plugin?
<scippio> from launchpad ..
<scippio> but maybe i install bad ....
<scippio> its my first plugin ..
<Odd_Bloke> OK, I get a different string in 'bzr plugins'.
<scippio> first: bzr branch lp:bzr.webdav
<scippio> second: i copy webdav.py to .bazaar/plugins/
<Odd_Bloke> scippio: Ah, no, you want the entire directory in ~/.bazaar/plugins/.
<Odd_Bloke> So 'bzr branch lp:bzr.webdav ~/.bazaar/plugins/webdav'.
<scippio> i mean ~/.bazaar/plugins/
<scippio>  ~/.bazaar/plugins/webdav.py
<Odd_Bloke> Yeah, you want the entire directory which it branches in there.
<scippio> i have it in
<Odd_Bloke> OK, try running 'bzr selftest webdav'.
<scippio> [scippio@jerry plugins]$ bzr selftest webdav
<scippio> testing: /usr/bin/bzr /usr/lib/python2.5/site-packages/bzrlib (1.6b3 python2.5.2)
<scippio> ----------------------------------------------------------------------
<scippio> Ran 0 tests in 0.001s
<scippio> OK
<scippio> tests passed
<scippio> [scippio@jerry plugins]$ ls /home/scippio/.bazaar/plugins/
<scippio> webdav.py  webdav.pyc
<Odd_Bloke> OK, remove both of those files.
<Odd_Bloke> And run 'bzr branch lp:bzr.webdav ~/.bazaar/plugins/webdav'.
<scippio> [scippio@jerry plugins]$ ls ~/.bazaar/plugins/webdav
<scippio> __init__.py  NOTES  setup.py  tests  TODO  webdav.py
<Odd_Bloke> OK, now try running 'bzr selftest webdav'.
<scippio> yes
<scippio> [scippio@jerry plugins]$ bzr selftest webdav
<scippio> testing: /usr/bin/bzr /usr/lib/python2.5/site-packages/bzrlib (1.6b3 python2.5.2)
<scippio> ----------------------------------------------------------------------
<scippio> Ran 11 tests in 0.074s
<scippio> OK
<scippio> tests passed
<Odd_Bloke> OK, now try using it for whatever you were trying to use it for before.
<scippio> excellent!
<scippio> Odd_Bloke: thank you!
<scippio> :)
<Odd_Bloke> scippio: Glad I could help. :)
<kiorky> uhm, in bzr world, what's the tip or head equivalent to designate the most up to date revision ? last:1 , isnt it ?
<Odd_Bloke> kiorky: In what context?
<kiorky> Odd_Bloke: i want to get the head 'explicitly' from a bzr repo, so -r last:1 seems nice
<Odd_Bloke> kiorky: -r-1 also works.
<kiorky> ok
<Peng_> -N is exactly equivalent to last:N, right?
<luks> yes
<kiorky> jelmer: so finnaly, i got it working, nice work !
<kiorky> jelmer: i may submit you a patch for compilation stuff when you didnt install your things in standart locations
<kiorky> jelmer: i would be interrested to know more on the problems with server side subversion server < 1.5 and the properties that bzr sets up. I ve read somewhere that it can be problematic. Because on our production server, the svn is pretty old (1.3 i think, the one on debian stable)
<kiorky> jelmer: uhm 1.4, but with have some repo on a sarge server, so it's 1.1 :p
<j1mc> hi all - just a quick question.  will 'bzr uncommit -r 3686' revert the branch to version 3686, or will it revert 3686 revisions?  i would prefer the former.
<nevans> upgrading to bzr 1.6beta3... what's the safest branch of bzr-svn to use?
<nevans> j1mc,  bzr revert -r 3686 will do what you want, IIRC
<j1mc> nevans: thanks
<nevans> actually...
<nevans> uncommit might also do it...
<Peng_> uncommit doesn't revert the working tree.
<Peng_> j1mc: Bazaar's -r arguments always do the same thing.
<nevans> Peng, thanks... I knew there was an important distinction
<j1mc> Peng_: what would i want to use then if i wanted to revert the working tree?
<Peng_> j1mc: Um, what do you want to do? Remove revisions from your history or revert the working tree?
<radix> j1mc: if you want to actually delete the history from the branch, then do "bzr uncommit -r X; bzr revert". If you just want to bring the working tree to the state that it was at a particular revision, use "bzr revert -r X".
<j1mc> basically, i pushed a small change up to LP, but had an error in it, and just want to revert the change up on LP to the prior revision.
<radix> j1mc: the difference is whether you want to delete it from history, or add a new revision which brings it back to the old state.
<j1mc> delete it from the history
<radix> then use uncommit
<j1mc> thanks
<Peng_> j1mc: You should just fix it and make a new commit.
<techII> i want to use bzr with a huge svn repository, but i don't want to wait for the history to download, any suggestions?
<Peng_> Time machine?
<Peng_> BTW, be careful. Unless you're using a dev version of bzr-svn and/or svn 1.5, it'll probably leak massive amounts of RAM.
<uws> techII: checkout perhaps?
<uws> techII: or wait ;)  (my webkit conversion took ~2 days)
<techII> ok, i need something between a lightweight and regular checkout/branch, that only has a partial history of a project, but can be branched from without going over the network
<uws> techII: Yeah, I would like that as well
<uws> techII: e.g. lightweigh checkout that caches all history ever requested from te master branch
<Peng_> That'll be a large portion of the history...
<uws> Peng_: Well, just the diffs you requested, and subsequent updates after the initial branching
<lifeless> uws: have you tried the new rebase ?
<uws> lifeless: I tried your branch from the bug report but it requires bzr > 1.5
<Odd_Bloke> techII: Stacked branches are on their way, which allow you to only download the history you need.
<Odd_Bloke> techII: I'm not sure of their exact status though.
<Peng_> "Merged into bzr.dev"?
<Peng_> They require the development1 format though.
<Odd_Bloke> Most of it is, but I don't know if everything is there.
<Peng_> Main thing, policies, docs. That's definitely most of it, but I don't know if it's all either.
<Odd_Bloke> techII: Basically, that use case should be fully supported in 1.7 (I think).
<uws> btw, is bzr's on disk format roughly the same size as git's on disk format?
<uws> (with rich root pack)
<Peng_> uws: No.
<Peng_> There's currently work on making indexes much smaller, and I'm sure there will be other stuff next.
<Peng_> Repo size benchmarks are complicated. Git, hg and bzr are all good enough, IMO.
<lifeless> uws: yes it does
<lifeless> uws: by default bzr is smaller than git, but common wisdom amongst git users is to run a 'repack' with large window and depth, and that makes it smaller than bzr
<lifeless> uws: like Peng_ says though, we have a better compressor on the way
<uws> lifeless: does it have impact on read performance?
<lifeless> the new compressor? untuned its about the same
<uws> lifeless: no, the repacking and window size
<lifeless> its complex :) - depends on the operation etc.
<uws> diff and log lookups are the most common methinks
<lifeless> however, git is gast either way (speed is not a problem of git) (well, except http pulls perhaps but that doesn't affect most users)
<Peng_> lifeless: What do you think of xdelta?
<lifeless> uws: could you try rebase with 1.6b3 ? I'd like to know that I've fixed the bug and I don't have enough info to be completely sure...
<lifeless> Peng_: good, I may end up using it for groupcompress, if I can. But I suspect i can't
<Peng_> Why can't you?
<lifeless> for performance I need to preserve compressor state as additional documents are added
<lifeless> its a streaming compressor like e.g. gzip
<lifeless> xdelta is a binary compressor - 2 in, one out
<uws> lifeless: will do, but not now. will have to wait for a bunch of commits on webkit.trunk first
<lifeless> uws: no worries
<lifeless> uws: let me know if its not snappy and I'll look at it more. I'll need another callgrind naturally.
<Peng_> lifeless: Oh.
<lifeless> Peng_: so if xdelta's interface is suitable I will be able to essentially [ab]use it, but if its not I'd need a custom version
<uws> lifeless: sure
<lifeless> uws: thanks
<Peng_> lifeless: Well, good luck. :)
<uws> lifeless: are you the bzr marketeer these days? ;)
<lifeless> uws: I think igc has a much better marketing feel than I :)
<lifeless> uws: I'm happiest doing deep hacking or understanding user issues :)
<uws> lifeless: your conversations sound like salesmen buzzword technobabble, in which everything is possible
<lifeless> uws: LOL
<uws> but in your case most things are actually real
<Jc2k> lifeless: i have a technical question :-)
<lifeless> Jc2k: shoot
<lifeless> Jc2k: also, are you still hung over ? :)
<uws> like "what does gnome need?"  [xyz]  "ok, will fix it"
<Jc2k> lifeless: there was no drinking for me, i came home after my talk
<Jc2k> :(
<lifeless> uws: well zeenix had some that were trickier - largely about the fact we use python AFAICT
<lifeless> Jc2k: shame; I would have bought you a beer or something :)
<Jc2k> lifeless: hehe
<Jc2k> how much longer are you in the UK?
<Jc2k> anyway, nzjrs (conduit dev) has been trying to get started with the playground
<Jc2k> he has a branch in jstowers/conduit/devel
<lifeless> Jc2k: I fly out tomorrow
<lifeless> ok
<Jc2k> he's trying to merge in http://johnstowers.co.nz/bzr/conduit-gio/
<Jc2k> he encounters fail
<Jc2k> about things been missing
<lifeless> pastebin ?
<Jc2k> one sec while i recreate :p
<Jc2k> http://pastebin.com/d38d71f4d
<Jc2k> he tried to create a bundle, but that seems to refer to a local branch so its useless to me
<lifeless> ah
<lifeless> so two tings
<lifeless> the send ui seems to confuse people
<lifeless> jam and I are discussing with abentley how to tackel that
<lifeless> basically you want to bundle against trunk always, then it refers to a branch people have in common
<Jc2k> i suspected his bundle was just fail, aye
<Jc2k> but im not sure why the merge is fail
<lifeless> that looks like he is missing data?!
<lifeless> bzr check <URL> going now
<lifeless> deifnitely
<lifeless> robertc@lifeless-64:/tmp$ bzr branch http://johnstowers.co.nz/bzr/conduit-gio/
<lifeless> bzr: ERROR: Revision {john.stowers@gmail.com-20080607075424-nebves9oo6tiry7z} not present in "1252@1811c9d2-c306-0410-a128-ae57aa55c946:trunk:conduit%2Fmodules%2FGoogleModule%2Fgdata%2Fmedia".
<lifeless> I'd like to know his bash history, did he rsync things around, that sort of thing
<lifeless> basically, its 'missing ref'
<Jc2k> he's in NZ so when you are synced back to local time correctly you'll be better set to talk to him :)
<lifeless> its 8:40am for him
<lifeless> but yes
<Jc2k> he has no online presence right now :)
<Jc2k> but i'll tell him to get his butt in here with his bash history
<lifeless> k
<Jc2k> i know that he's encountered stuff like this before and his solution is to bundle and merge it into a fresh branch
<nekohayo> hey there, could someone try using http://ecchi.ca:8000/spec-merge/specto-ULTIMATEMERGE/ as a base, and bzr replay http://ecchi.ca:8000/spec-merge/specto-woutcR2/ from revision 2?
<nekohayo> it does not seem to work on my end
<nekohayo> even though the contents are strictly equal
<lifeless> nekohayo: hi
<nekohayo> hoy lifeless
<lifeless> nekohayo: what you say doesn't work, what do you mean?
<nekohayo> hmm lemme try
<nekohayo> lifeless: 16 conflicts encountered.
<nekohayo> but I shouldn't have any conflicts, the contents are exactly equal, no?
<lifeless> well, replay applies patches
<lifeless> so you can have conflicts yes
<lifeless> but I'm pulling it now
<nekohayo> lifeless: because the goal is simply to stitch the history of those two branches together
<lifeless> nekohayo: es, I assumed so
<nekohayo> lifeless: oops, I think the specto-woutcR2 branch is the wrong one though
<lifeless> nekohayo: they have no common history at all
<nekohayo> wait a sec
<lifeless> heh, not even same repository type :)
<nekohayo> lifeless: http://ecchi.ca:8000/spec-merge/specto-woutc/ is the one, not specto-woutcR2
<nekohayo> lifeless: so if I try to replay from -r2.. , I get 16 conflicts. If I try from -r3.. , I get 28 conflicts!
<lifeless> nekohayo:  bzr merge ../specto-ULTIMATEMERGE/
<lifeless> bzr: ERROR: Repository KnitRepository('file:///tmp/specto-woutc/.bzr/repository/') is not compatible with repository KnitPackRepository('file:///tmp/specto-ULTIMATEMERGE/.bzr/repository/')
<nekohayo> lifeless: are you using bzr 1.5?
<nekohayo> but I'm not using "merge" here, but "replay"
<lifeless> nekohayo: 1.6b3  :) Point is you have apparently disconnected branches
<lifeless> nekohayo: one is from svn
<lifeless> nekohayo: one is from a local import
<nekohayo> yeah they are. that's why I'm trying to use replay?
<nekohayo> yeah
<lifeless> nekohayo: replay works on file ids - the inode abstraction
<nekohayo> but the code is the same, darnit
<lifeless> nekohayo: the conflicts you are getting is because bzr *thinks* the files are different files with conflicting file names
<nekohayo> so what if I replay, bzr resolve, and then.. uh what would happen?
<nekohayo> and should the replay be done starting at revision 2, or 3?
<lifeless> if you replay, resolve, commit, replay the next one etc; when you are done you should be able to continue forward
<nekohayo> the contents from "ultimatemerge" last revision === contents  from specto-woutc revision 2
<lifeless> then you would start from 3
<lifeless> but I have a suggestion for you
<nekohayo> ... I need to do that for ~80 revisions?!
<nekohayo> o_o
<lifeless> replay it a bit more by hand :(
<lifeless> bzr branch ULTIMEATEMERGE working
<lifeless> cd working
<lifeless> bzr diff ../specto-woutc -r 2..3 | bzr patch
<lifeless> bzr commit
<lifeless> (and copy log message)
<nekohayo> x_x
<lifeless> its a bug that we don't have a good conflict resolver for file-path conflicts; it makes the particular pattern of use that you have made frustrating
<lifeless> you could try http://spacepants.org/src/bzrgraft/
<lifeless> but AIUI its not up to date with current bzr
<nekohayo> well yeah, it kind of depresses me that bazaar is claimed to be smarter with merges or even stitching history
<nekohayo> when in the end it comes down to manually committing everything o_o
<lifeless> nekohayo: why did you start a new branch ?
<nekohayo> it wasn't me :(
<lifeless> (as in from-scratch, rather than branching from svn in the first place ?)
<lifeless> oh
<nekohayo> aw shoot, it's a shame graft is unmaintained
<kiorky> yo
<kiorky> when doing bzr branch foo bar
<kiorky> i think i dont understand something
<kiorky> when i do local changes/commits, then i want to push back my things
<kiorky> why do i need to precise the "from location" again the first time and bzr do not remember it ?
<Odd_Bloke> kiorky: Because it's fairly rare that a user will want to push back to the location from which they branched.
<mwhudson> kiorky: it does, or at least should, remember
<lifeless> gnight all
<bob2> 'night
<kiorky> mwhudson: the first time, i need to precise agi the from location, after that it remembers
<bob2> perhaps push should default to the parent if a push location isn't set
<kiorky> bob2: 'xactl
<kiorky> bob2: 'xactly
<kiorky> this behaviours seems natural for me
<Odd_Bloke> Again, often it's not what people intend to do.  If you've branched from a trunk which you can push to, you don't necessarily want to push to it when you forget that you haven't specified the correct location yet.
<Odd_Bloke> For example, I do "bzr branch pqm.dev foo", *HACK*, 'bzr push bzr+ssh://me@there.com/bzr/foo' so people can access my changes.  I wouldn't want my changes pushed to pqm.dev by accident, because that will affect other people (theoretically).
<kiorky> Odd_Bloke: thats the default on many dvcs :p, just an habit
<MatthewWilkes> Hey, is there a record for longest time spent trying to install bzr-svn?  Just wondering how much longer I have to take before I get my certificate
<Odd_Bloke> MatthewWilkes: What problems are you having?
<thumper> MatthewWilkes: :)
<MatthewWilkes> Odd_Bloke: Using OSX, svn 1.4.5 managed with macports.  Trying to get to a version that bzr-svn supports is proving very difficult, I don't care enough about wanting to try bzr to replace my system python, subversion and py-svn, then patch setup tools as macports wants me to, so trying to muddle though doing part of it
<mwhudson> oh os x
<mwhudson> install ubuntu in parallels, use that
<mwhudson> (only about half joking)
<MatthewWilkes> mwhudson: I have ubuntu in a vm, and I could play there, but then that would be all I ever did with bzr
<mwhudson> MatthewWilkes: you could just do the bzr-svn requiring stuff in the vm
<Ng> 139
<kiorky> jelmer: why does svn+http://s cache my credentials but https:// does not ?
<Ng> bah
<kiorky> jelmer: i mean the svn credentials
<mwhudson> if you push from the vm to your os x install, you can use that there without bzr-svn, then push back to the vm so you can push back to bzr-svn
<mwhudson> MatthewWilkes: not ideal, obviously
<mwhudson> are there svn 1.5 os x binaries yet?
<MatthewWilkes> mwhudson: Everything would require it, I'm in a company infrastructure that only supports svn, and it will only ever support svn unless it becomes easy
<mwhudson> Ng: hi :)
<Verterok> MatthewWilkes: Hi, I'm using bzr-svn on OS X (10.4), tell me if I can give you a hand to get it working :)
<kiorky> MatthewWilkes:  show bundlebuggy to your workmates
<Ng> mwhudson: hey :)
<MatthewWilkes> Verterok: Thanks, how are you managing svn?
<Verterok> MatthewWilkes: I'm using the DMG from collabnet, but I think the macports version should be fine
<MatthewWilkes> kiorky: If the features were all that mattered, no problem, but if it doesn't work, it's useless
<Peng_> You only have to convert everyone from svn once. Then it won't be an issue anymore! :D
<Peng_> </useless>
<pygi> MatthewWilkes, you mean unless hosting bzr branches becomes easy? :p
<Verterok> MatthewWilkes: and bzr-svn trunk (0.4.11)
<MatthewWilkes> pygi: No, I mean working with all the other repositories people have to deal with ;)
<pygi> MatthewWilkes, aha, ok, sorry :P
 * pygi just plugged himself in, so :)
 * MatthewWilkes knows of 1 bzr formatted repository that houses code relevant to his work
#bzr 2009-07-13
<garyvdm> igc: I would like to recommend that you reuse the error handling infrastructure from qbzr in bzr-explorer.
<garyvdm> I'll put the details in a mail.
<igc> garyvdm: do you mean something more than the try/except at the app level?
<igc> garyvdm: thanks
<garyvdm> Yes - you need a sys.excepthook to catch everything.
<jml> lalala, releasing bazaar
<garyvdm> igc: No mailing list for bzr-explorer :-(
<garyvdm> Can I create one?
<igc> garyvdm: sure. Another option is the bzr-desktop mailing list I proposed a few weeks back (but I don't recall getting feedback on)
<garyvdm> Ok
<garyvdm> igc: is it ok to import from qbzr in bzr-explorer?
<igc> garyvdm: absolutely. explorer reuses lots of stuff from qbzr including i18n support
<garyvdm> igc: cool
<garyvdm> igc: Did you go on vacation? How was it?
<igc> garyvdm: restful thanks
<garyvdm> Thats good!
<igc> garyvdm: being the middle of Winter here, we had the beach pretty much to ourselves :-)
<jml> Installed Bazaar version 1.16.1 is too old to be used with plugin
<jml> "Bzrtools" 1.17.0.
<jml> :(
<jml> I guess I'd better get releasing
<jml> igc, welcome back!
<igc> hi jml - thanks!
<fullermd> Seems like everybody makes that mistake on their vacation...   it's all going so well, and then they end it.
<igc> fullermd: indeed
<jml> I don't see anything in the NEWS file about fixing 2a bugs.
<jml> there are quite a few nice performance things though.
<fullermd> igc: Quick!  Uncommit leaving the beach before you get more revs on top of it!
<jml> HPSS calls: 45 (17 vfs) SmartSSHClientMedium(connected=False, username=u'jml', host='bazaar.launchpad.net', port=None)
<jml>  :\
<spiv> jml: which operation?
<jml> spiv, pushing a new, stacked 2a branch
<spiv> Ah ok.
<lifeless> with tags?
<jml> yeah, one tag.
<jml> without (new) tags is HPSS calls: 43 (17 vfs) SmartSSHClientMedium(connected=False, username=u'jml', host='bazaar.launchpad.net', port=None)
<lifeless> whats the backtrace of the vfs trigger?
<lifeless> or, have we landed the patch that disables that :(
<jml> there are two of them.
<lifeless> (I really think folk should either not care about hpss calls, or care about vfs triggers)
<igc> hi lifeless, spiv
<spiv> igc: good morning!
<jml> http://paste.ubuntu.com/216536/
<spiv> Yeah.  tags causing vfs calls is pretty high on my hit list.
<lifeless> spiv: are you open to being convinced to keep vfs triggers tied to -Dhpss?
<spiv> lifeless: no, not really
<spiv> lifeless: they irritate *me* :)
<spiv> lifeless: but more importantly, it means that other people have started turning off -Dhpss
<jml> why are they displayed, rather than logged?
<RenatoSilva> how to list the remebered locations?
<spiv> So if someone on the launchpad-dev team gets unexpected bad performance, and I ask for the -Dhpss log, they'll have to re-run the slow, painful operation before they can give me an answer.
<spiv> Which is I think is a net loss compared to making the vfs triggers in-your-face.
<lifeless> spiv: are they still logged to ~/.bzr.log with the patch that stopped showing them?
<lifeless> spiv: because I think its still a net loss if we don't get the trigger
<spiv> lifeless: I'm not sure, poolie did that patch.  I'm fine with them still being logged.
<spiv> (even though that makes debugging test failures more irritating, that only really affects me)
<jml> RenatoSilva, 'bzr info'
<RenatoSilva> jml: thanks
<ircleuser> Hi I just installed Bazaar and in the $HOME/.bazaar directory the only file is "ignore"
<lifeless> jml:  please file two bugs
<jml> spiv, lifeless: anyway, I only mention it because it's something of a regression from the glory days of 8 or 9 hpss calls & no vfs ops.
<lifeless> jml: a) your scenario writes tags twice
<lifeless> jml: b) writing tags causes _ensure_real
<spiv> jml: yeah.  life was better when bzr.dev had no tags ;)
<jml> lifeless, the pasted stack traces were from pushing a branch that has no new tags.
<ircleuser> I was expecting bazaar.conf - any ideas what causes this?
<spiv> jml: no new tags != no tags, unfortunately.
<jml> (and the branch was launchpad)
<garyvdm> ircleuser: If you do bzr whoami "User Name <user@tld.com>" it will create it.
<jml> spiv, wow, that sucks.
<garyvdm> Ebro ^^^
<mwhudson> jml: pushing a new launchpad branch has never had no vfs ops
<jml> mwhudson, really? maybe it was only 1 or 2 then
<Ebro> sweet! Thanks!
<mwhudson> jml: pushes between existing branches are still 0 vfs
<mwhudson> (i think, anyway)
<jml> mwhudson, nope
<mwhudson> oh
<jml> $ bzr push lp:~jml/launchpad/test-branch-47-2
<jml> No new revisions to push.
<jml> HPSS calls: 14 (2 vfs) SmartSSHClientMedium(connected=False, username=u'jml', host='bazaar.launchpad.net', port=None)
<lifeless> jml: please file the bugs ;)
<jml> lifeless, yeah, that's what I'm doing.
<jml> although they'll probably be crappy bugs.
<mwhudson> jml: pull is 0 vfs at least, it seems
<mwhudson> anyway, i'm not here right now
<spiv> jml: there's a cheap optimisation in push atm where if you have 0 local tags it doesn't even need to read the remote tags, let alone write any tags.  But as soon as there are any tags that obviously doesn't work...
<jml> spiv, makes sense
<poolie> hello
<lifeless> hai
<poolie> karmic is booting again, yay :)
<lifeless> poolie: your patch to mute -Dhpss on vfs events
<lifeless> poolie: does it make the trace get logged to ~/.bzr.log?
<poolie> it moves the existing code to a different debug flag
<poolie> so if it was not unconditionally logging them before, it's not doing it now
<lifeless> poolie: I would like, and I think spiv would do, if someone has -Dhpss, those events should get captured *somewhere*
<poolie> why not just set the other flag?
<lifeless> poolie: because otherwise they have to reproduce the event
<poolie> who?
<lifeless> the person reporting
<lifeless> the reason we added that flag was to get more data in bug reports
<poolie> so we're talking about people who do have hpss set in their config options?
<lifeless> yes
<poolie> but they can't be told to set the other flag?
<poolie> well, ok
<lifeless> setting the other flag means they have to reproduce it again
<lifeless> rather than grabbing their log and attaching
<poolie> i can see a lot of lp people probably do have Dhpss set, and it would be annoying to do it all over again
<poolie> i don't really object, please yourself
<lifeless> ok
<poolie> it's just that spewing it to stderr was way too much
<lifeless> I did that on the basis that noone would have Dhpss set unless they were working on the network stack
<poolie> yeah
<lifeless> however it seems we have a bunch of voyuers ;)
<poolie> a reasonable assumption but not actually true :)
<poolie> i like having it on for background awareness
<poolie> 'care about networking' is not precisely 'working on networking right now'
<lifeless> its kind of like the big display in  windows defrag programs
<poolie> hm
<spiv> Perhaps we have voyuers, but also we frequently ask bug reporters and psuedo beta testers (like people on the lp team) to use it.
<poolie> maybe a bit more useful than that
<poolie> like i did actually use the trace while testing stacking against launchpad to see what it was doing
<lifeless> spiv: sure, the point is that if they have it set by default rather than on-request.
<poolie> but that's not the same as looking for new things to fix
<lifeless> spiv: I'm not arguing against the change thats been made; I'm arguing for capturing sufficient data in a reasonable place.
<spiv> lifeless: right.
<poolie> actually maybe that's the difference, are you looking for trouble in the sense of open to being told about new things to improve
<poolie> anyhow by all means capture it
<poolie> even capture it unconditionally if you like
<poolie> two other ideas re bug reporting:
<poolie> one is, maybe we should record the reason why plugins failed to load and show it from 'bzr plugins'
<poolie> at least the actual error message
<poolie> i think at the moment failed ones are not shown at all
<lifeless> I think of the VFS trace as being the same as the HPSS trace; they are both showing whats going on. I appreciate that the noise was too much
<poolie> and as a further step maybe don't show anything to stderr, just put it in there
<poolie> and the second was, maybe have a global weak dict of open repositories etc
<poolie> and show it in the error reporting tb
<poolie> so we don't need to go back and ask for bzr info
<poolie> hm
<poolie> possibly that could be subsumed by just getting a full traceback through something like apport
<lifeless> I'm not keen on the word global there
<lifeless> I like the idea about plugins
<poolie> i guess rather than being global we could look for things on the relevant stack
<poolie> i might file a bug for that at least then
<poolie> spiv, how's your stuff today?
<poolie> thanks for the knockon errors review
<RenatoSilva> what was that prefix you put in bzr selftest <?>:plugin ?
<RenatoSilva> bzr selftest -s <prefix>:plugin
<lifeless> foodink
<lifeless> back
<jelmer> mwhudson: hi
<mwhudson> jelmer: hi
<mwhudson> jelmer: i was going to ask about the python2.4 subvertpy bug
<poolie> hello jelmer
<igc> hi poolie, jelmer
* jml changed the topic of #bzr to: Bazaar version control system | 1.17rc1 released 13th July, 2009 -- please test it! | 1.16.1 released 26th June, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/
<jelmer> 'moin mwhudson, poolie, igc
<jml> g'day jelmer
<jelmer> hey jml
<lifeless> hi jelmer
<jelmer> lifeless: hi
<jelmer> mwhudson: Not much news yet, but I'm pretty sure I'll have it fixed before the end of the week
<jml> I've made this diff after merging the 1.17 branch into trunk: http://paste.ubuntu.com/216582/
<jml> can someone quickly sanity check that for me
<jml> please
<lifeless> .
<lifeless> .
<lifeless> looks good to me
<jml> thanks.
 * jml pqm-submits
<spiv> poolie: good, I have literally only two issues left on my todo list for the inventory-deltas streaming branch.
<poolie> cool
<spiv> poolie: 1) two tests failing with pack already exists error when an autopack happens on a 2a repo (maybe bug 382463 ?), 2) making a new get_stream verb so that old clients won't receive inventory-delta records they can't handle (and arrange for deltas not to be streamed via the old verb, of course).
<ubottu> Launchpad bug 382463 in bzr "'bzr pack' of an already packed dev6 or 2a repo fails with Pack exists" [Medium,Triaged] https://launchpad.net/bugs/382463
<spiv> Oh, and I'd like to do a bunch of manual testing, but that can happen concurrently with the code being reviewed.  Once I fix 2) I'll make the merge proposal.
 * igc lunch
<lifeless> spiv: 382463 occurs on fully packed repos
<lifeless> spiv: it shouldn't ever happen on autopack
<lifeless> spiv: do you perhaps have an empty pack?
<lifeless> thats unlikely as we have guards for it
<lifeless> spiv: also we want to push verbs
<lifeless> spiv: sorry rephrasing. Could you add 3) a new insert_stream verb, please.
<spiv> I don't think the pack is empty, as the name changes from test run to test run, which implies content.
<lifeless> ack
<spiv> It's triggered by the self.target_repo.pack call in _locked_insert_stream
<lifeless> oh
<lifeless> I bet I know
<lifeless> you've one stream right?
<lifeless> and a new repo?
<spiv> If you grab lp:~spiv/bzr/inventory-delta and selftest test_fetch_parent_inventories_at_stacking_boundary_smart you'll see it.
<lifeless> spiv: I'll give you a couple of hints now. If they don't help ping me later and I'll push stack and look at it with you
<lifeless> I suspect the following conditions are occuring:
<lifeless>  - you upload a single pack
<spiv> Off the top of my head, I think one stream + new repo is true.
<lifeless>  - the pack is sufficiently simple that the sort order for its contents are the same as the upload order happened to generate
<lifeless>  - the group splitting heuristics happen to line up at the same boundaries
<spiv> It's also likely that this is a code path that wasn't being hit before (because InterDifferingSerializer was covering this case).
<lifeless> -> collision, with the same content.
<lifeless> so this is natural.
<spiv> Yeah.
<lifeless> some possibilities to avoid id:
<spiv> FWIW, if I replace the raise with a return the offending tests are happy.
<spiv> (unsurprisingly)
<lifeless>  - deliberately send in a slightly different order, to force the pack to do it in a different order
<lifeless>   (ugh)
<spiv> Yeah, I don't like the sound of that one.
<lifeless>  - fix the long standing 'genuine collisions error rather than checking the content is the same' bug
<lifeless>    (note that this needs to also check the indices are the same, I *think* the bug notes that)
<spiv> That sounds like the right fix, but I'd be happy for someone else to do it ;)
<lifeless>  - make the pack(hints...) method pass a flag down that means the repo can recognise that it just repacked pack FOO and got FOO and back it out rather than actually replacing at all.
<lifeless> I think the third will perform best
<spiv> Hmm.
<spiv> Can you elaborate on that third option?
<spiv> I'm not really sure what the hint does (I haven't dug very deeply into this yet).
<lifeless> the hint says 'repack these specific packs'
<spiv> I think it's just a "hey I just added this new data, so just focus on packing that bit" arg?
<lifeless> its allowed to be ignored if the repo can't do partial packs or whatever.
<spiv> Ok, thanks.
<lifeless> Doing that pack-with-hints is what stops a delta inserted into a 2a repo from being GB's in size ;)
<spiv> lifeless: btw, the branch already adds a new insert_stream verb.
<lifeless> spiv: cool
<lifeless> spiv: scratch 3) then :P
<poolie> hey spiv
<poolie> thanks for the update
<mwhudson> jelmer: cool
<mwhudson> jelmer: it looks like launchpad on 2.5 is going to take a little longer than we would like, so fixing the bug would be really nice :)
<lifeless> \o/ 24/27 inventories fail to error when the path is mismatched with the parent id
<GungaDin1> How can I check what revision I'm on in a branch?
<lifeless> bzr revno
<GungaDin1> thx
<igc> bbiab
<igc> jml: when adding the empty sections to NEWS at the start of a release, ...
<igc> I think "Internals" belongs later, e.g. after "API Changes"
<jml> igc, I think you're right.
<igc> jml: I'm about to tweak and land the Upgrade Guide
<igc> jml: so I'll tweak that while I'm at it
<jml> igc, thanks.
<jml> the 'releasing' guide should be updated to say 'add empty sections to the NEWS file' and probably should include a template for doing so.
<jml> I'll file a bug for that.
<poolie> hello igc, welcome back!
<poolie> well done on the release jono
<poolie> and welcome back too
<igc> hi poolie!
<poolie> lifeless: intercepting http proxies are not the answer, 'no' is the answer :)
<jml> lifeless, where's your whitepaper on interface testing?
<jml> poolie, thanks.
<jml> pygi, g'day
<pygi> good morning jml :)
<lifeless> jml: I should update. Its on people.ubuntu.com.
<lifeless> poolie: they may be the cause though :P
<jml> lifeless, I find myself having to describe the concept increasingly often. An updated version would be nice.
<lifeless> jml: its time has come!
<lifeless> I want to add prose about balancing costs and fragility
<lifeless> ok, EOD for me, a bit late (don't ask when I started :P)
<lifeless> currently fixing tree.apply_inventory_delta to not corrupt dirstate with duplicate file ids.
<vila> hi all
<poolie> hello vila
<poolie> writing a post about 2.0 and beyond
<vila> great
 * igc dinner
<anywho> is it possible to do a diff against the previous revision without knowing the revision number? like something like bzr diff -r -1 ?
<mwhudson> yes
<mwhudson> but -r -1 means the most recent revision
<mwhudson> anywho: you probably want diff -r -2
<mwhudson> (that'll be the difference between the most recent but 1 commit and the tree as it is now)
<anywho> that works but so what is the purpose of -1 in this case? it would never work, right?
<vila> anywho: It will show you the difference between the last committed revision and your working tree, i.e. the changes that are not yet committed
<Kinnison> anywho: Basically -1 == HEAD
<anywho> got it
<anywho> thanks
<poolie> good night all
<sabdfl> night poolie
<awmcclain> Anyone know why branch we create on our remote repository are created without group write? I have umask 022 in my /etc/profile, am I missing something?
<awmcclain> *branches
<AfC> awmcclain: 1) maybe you meant umask 0002 and 2) you probably want sticky group bit on the remote repo directory?
<awmcclain> AfC: Yeah, I _just_ realize that about the umask, and the sticky bit is set.
<awmcclain> Thank you.l
<awmcclain> realized.
<awmcclain> Ug, one of those typing days.
<awmcclain> Hrm... do I need to restart a daemon for that /etc/profile change to happen?
<awmcclain> Hrm... no, i have umask set to 0002 now, and I'm still getting the same permissions problems.
<awmcclain> Does bzr not use /etc/profile?
<maxb> awmcclain: It is not bzr's job to use or not use /etc/profile. That is up to the shell
<awmcclain> maxb: Ubiquitous!
<maxb> :-)
<awmcclain> maxb: So, PAM is...what, a kernal module? My linux-fu is quite poor, I'm unfamiliar.
<Kamping_Kaiser> pam came from solaris ;)
<awmcclain> maxb: So, if I'm reading the man page correctly, I'm going to add a line to my /etc/pam.d/login to alter the umask?
<maxb> awmcclain: Doubtful that "login" has anything to do with ssh-based connections
<LeoNerd> login  is for the 'login' binary.. which is used by getty et.al. for virtual consoles
<Kinnison> If you're using ssh+bzr or bzr+ssh or whatever it's called, then surely it's up to your shell's non-interactive startup to set umask?
<jam> morning all
<homy> Hi! With which bzr command can I find out which files in the Working tree are version-controlled?
<Tak> homy: bzr ls --versioned â½
<maxb> wow, it's not often you see an interrobang used in conversation :-)
<homy> Talk: thanks.I didn't find that in the Bazaar User Guide http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html.
<Tak> maxb: it is when I'm around :-P
<abeaumont_> i want to create a branch from a repo that includes all but some intermediate revisions, e.g., r1..100 and r105..200, which is the best way to do it?
<abeaumont_> s/best/proper/
<Tak> abeaumont_: branch in the normal way, then merge out those revisions?
<Tak> or maybe branch the first revision group, then merge in each successive group
<Adys> Hi all. Is there a mailing list where I can post a feature proposal (and possibly work on it)?
<Milo-> Any launchpad staff here at the moment? I have a question that regards launchpad ignoring my mail address during registration
<amanica_> Adys: there is just the main development mailinglist: https://lists.ubuntu.com/mailman/listinfo/bazaar
<Adys> amanica_: is it better to write a blueprint about it, or an email first?
<amanica_> Adys: maybe mail first
<Adys> Ok
<amanica_> Adys: sometimes feature requests are submitted as wishlist bugs, but blueprints sounds better
<amanica_> Adays: btw. put [RFC] as the start of your mail
<amanica_> subject
<Adys> Ok, thanks a lot :) Ill send it tonight
<amanica_> cool
<SamB> jelmer: you have an interesting definition of "four"
<jelmer> SamB: hmm?
<SamB> jelmer: bzr-svn also adds four new commands to Bazaar:
<SamB>  - bzr svn-import
<SamB>  - bzr svn-layout
<SamB> For more information about bzr-svn, see the bzr-svn FAQ.
<jelmer> oh, right
<jelmer> two were integrated into bzr
<jelmer> SamB: fixed, thanks
<SamB> hmm, you might want to mention those on that page because they're probably particularly useful for SVN repositories?
<LarstiQ> jelmer: I'm trying to narrow an exception down in bzr-svn that occurs on our repo if you start without a cache
<LarstiQ> jelmer: I think it is because layout.get_tags(self, from_revnum, project) returns []
 * LarstiQ files bug with traceback
<Adys> amanica_: Ok. sent the mail. I gotta run for a couple of hours now. thanks again :)
<LarstiQ> jelmer: bug 398908
<ubottu> Launchpad bug 398908 in bzr-svn "branching results in: ValueError: need more than 3 values to unpack" [Undecided,New] https://launchpad.net/bugs/398908
 * LarstiQ prepares to go home
<jelmer> LarstiQ: is this also with current bzr-svn ?
<jelmer> LarstiQ: since I fixed an issue like that recently
<jelmer> LarstiQ: yeah, I'm pretty sure this one is fixed
 * LarstiQ checks
<kfogel> What's ETA for 1.17, or is that an annoying FAQ that does not have an answer?
<jelmer> kfogel: Usually the release manager posts a timeline for the release cycle before it starts, not sure if that happened for 1.17
<LarstiQ> jelmer: timemachien yay :)
<jelmer> kfogel: I can't find anything, but usually it's about a week or so after the rc
<jelmer> kfogel: barring any release critical bugs that would require a new rc
<jelmer> SamB: They just happened to be commands that were hard to integrate into Bazaar, I don't think that's a valid reason for listing them there.
<kfogel> jelmer: right
<jelmer> SamB: for the record, these two commands were svn-push and svn-set-revprops (now: push and reconcile)
<SamB> jelmer: ah.
<SamB> svn push doesn't really need listing there, true
<LarstiQ> jelmer: was that revno 3097?
<SamB> and I guess reconcile neither
<SamB> though I'd never have guessed that it altered revprops in the SVN repository -- you do have that in the FAQ somewhere?
<SamB> and I'm also not sure how svn push works when you've a complicated tangle of Bzr revisions to push -- what branches do they all get pushed on?
<LarstiQ> jelmer: applying 3097 to 0.6.2 fixes it for me, cheers!
<jelmer> SamB: it does a similar thing to what reconcile does in bazaar repositories - fix revision metadata; in this case that revision metadata happens to be stored in revisin properties
<hsn_> why bzr st sometimes reports file names with '*' at end? it breaks my scripts
<verterok> hsn_: * means a change in the executable bit
<Skoorbulous> Hi all. I am new to bzr and have a basic question: I have a branch that I have run the "bind" command on to convert to a checkout, but when I got to try to edit a file it is locked.
<Skoorbulous> What is the correct process to follow so my branch is unlocked and editable?
<Skoorbulous> thanks
<LarstiQ> Skoorbulous: could you provide a bit more information?
<Skoorbulous> It is a website and I am trying to starty with a simple bzr model whereby I simpy bind a branch to convert to checkout, make edits, unbind, commit
<Skoorbulous> not sure if that makes sense but I do not want to create a whole local copy of it to make changes
<LarstiQ> Skoorbulous: what specifically do you mean with 'it is locked'?
<Skoorbulous> it is locked by root so when I try to edit it with a text editor it tells me I do not have write priveleges
<Skoorbulous> I thought that bzr probably locked everything up
<LarstiQ> Skoorbulous: could you please pastebin a transcript of the command you run and it's output? (http://pastebin.com)
<Skoorbulous> I am trying to edit with a text editor on my mac - so there is not really a command that I can paste
<LarstiQ> Skoorbulous: as is you are leaving out the information from which to determine what is going on
<LarstiQ> Skoorbulous: and this text editor has bzr integration?
<LarstiQ> Skoorbulous: or what is the message it comes up with?
<Skoorbulous> no its just a standard text editor. Can I not use standard software to edit my files if I use bzr?
<SamB> jelmer: wow, SVN uses a dumb protocol ...
<LarstiQ> Skoorbulous: are you just having regular unix permission problems?
<LarstiQ> Skoorbulous: yes you can, but now I think your issue has nothing to do with bzr
<Skoorbulous> It says "Are you sure you want to unlock entry.php that doucment is owned by "root""
<jelmer> SamB: ?
<Skoorbulous> I did not have permission problems until just now when I added bzr
<SamB> jelmer: oh, maybe it's not quite as dumb as it looks ... but this server is being silly, at least:
<SamB> Transfer-Encoding: chunked
<SamB> Content-Type: text/xml; charset="utf-8"
<LarstiQ> Skoorbulous: well, why is entry.php owned by root?
<Skoorbulous> I guess I must have been in root when I added the directory to bzr - would that have done it?
<SamB> hmm, I wonder why the SVN client doesn't send an Accept-Content-Type header?
<LarstiQ> Skoorbulous: I wouldn't think so
<Skoorbulous> hmm
<Skoorbulous> thanks for your help - this is a stupid question, but how do I convert everything back to ownership by a different user?
<SamB> jelmer: I don't suppose it would be possible for bzr-svn to pipeline it's requests?
<jelmer> SamB: it is, see the bug report about replay in bzr-svn's bugtracker
<SamB> ah
<SamB> that's nicer than I somehow expected
<SamB> though it's obviously feasible from the protocol POV, at least for the HTTP protocol
<SamB> !bugs bzr-svn
<ubottu> Sorry, I don't know anything about bugs bzr-svn
<SamB> aww.
<LarstiQ> Skoorbulous: chown user -R
<jelmer> SamB: https://launchpad.net/bzr-svn/+bugs
<SamB> jelmer: ah, thanks
<SamB> would be nice to have a bot command for that or something though ;-)
<jelmer> SamB: svn isn't "standard" http, it uses REPORT to fetch revision delta's
<SamB> jelmer: I can see it does that
<SamB> I just happened to catch some of it's requests in wireshark when I was looking for something else
<RenatoSilva> any bzrtools deveoper here?
<SamB> jelmer: afaik, HTTP pipelining is possible iff you can make multiple requests on one connection, and that's sure what seems to be happening here
<RenatoSilva> s/eo/elo
<jelmer> SamB: sorry, I should rephrase. with replay pipelining should not be necessary afaik
<SamB> jelmer: ah
 * SamB wishes he could profile bzr-svn's heap traversal ...
 * jelmer wishes he could, too
<SamB> I would think it had a space leak if it didn't keep swapping that stuff back in
 * SamB wonders how impossible it would be to actually implement such a thing
<SamB> I mean, it's not actually impossible
<SamB> ... you could do something with valgrind ...
<hsn_> verterok: it breaks bzr-eclipse too
<SamB> (in a new skin, of course)
<verterok> hsn_: ?
<SamB> ... but you might need to hook Python's allocators in some fairly nasty ways to get memory objects sufficiently segregated to actually notice when one is used for the first time in a while
<amanica_> Adys: cool, I saw. I like your idea and am also tempted to contribute.
<verterok> hsn_: a change in the executable bit?
<jelmer> SamB: yes
<SamB> I guess whatever cachegrind's approach is would allow doing it without allocating each Python object on it's own 4k page, at least
<SamB> of course, you'd also want to take snapshots of the arrangement of the heap like that tool that was introduced on the bzr list...
<SamB> hmm. you might need to deactivate/delay deallocation due to refcounts reaching zero, too ...
<SamB> (I assume Python still has refcounts?)
<jelmer> yeah, ther'es refcounts
<SamB> ... otherwise, you'd not be able to get any sense out of accesses to objects that were both allocated and deallocated between one snapshot and the next ...
<SamB> ... I guess you'd probably want to deactivate the access logging while running the cycle collector, too
<LarstiQ> SamB: CPython does
<LarstiQ> Skoorbulous: did that help
<LarstiQ> Skoorbulous: ?
<SamB> LarstiQ: yeah, I was talking about CPython
<SamB> using valgrind to profile a program running under Jython would probably be rather useless
<LarstiQ> SamB: there are way more Python implementations than those two :)
<SamB> or PyPy, or IronPython, or ...
 * LarstiQ nods
<LarstiQ> personally I need/want to look at Stackless soonish
<SamB> guess I should have used an 'e.g.'
<SamB> I think Stackless doesn't really count as different from CPython for my purposes
<SamB> I mean, about the profiling thing
<LarstiQ> fair enough
<LarstiQ> SamB: so how about that bzr memory profiler you mentioned earlier? That has worked for us
<SamB> LarstiQ: I just want to see what bzr-svn is keeping so much stuff in RAM for
<SamB> and, worse, apparantly using it
<LarstiQ> SamB: then I can recommend it
<jelmer> SamB: which version of bzr-svn is this specifically?
<SamB> jelmer: did you improve it recently wrt that?
<jelmer> SamB: yeah
<SamB> what was the issue caused by?
<jelmer> multiple copies of a file kept in memory
<SamB> how recently?
<SamB> oh, and why did you remove the branching schemes help topic?
<SamB> oh, apparantly I had the latest code before I told you about that incorrect use of "four" in the help
<SamB> ... no, wait
<jelmer> SamB: it was fixed since 0.6.2
<SamB> confusingly, bzr pull -v lists changes *in order*
<SamB> not reverse order as one would expect
<jelmer> SamB: I removed the branching scheme help topic because it's only relevant for people who are doing interoperability with bzr-svn 0.4.x
<jelmer> SamB: and there's no way to hide help topics in bzr atm
<SamB> jelmer: eh?
<jelmer> SamB: ?
 * SamB reads the patch ...
<SamB> jelmer: oh, how do you find branches now?
<jelmer> SamB: repository layouts
<SamB> jelmer: oh!
<SamB> missed the part where there were too versions of the concept with different names
<SamB> ;-)
<jelmer> well, it's not exactly the same concept
<SamB> well, no
<SamB> I did say "versions"
<jelmer> right, sorry
<SamB> er. and I should have said "two" rather than "too", shouldn't I have ;-)
 * SamB is relieved, considering that he had to put something in .bzr to get anything sensible for the repository that contains PuTTY 
<SamB> jelmer: oh, speaking of which, it might be usefull if you would do full globbing of branch paths in ~/.bazaar/subversion.conf
<SamB> you know, with ? and [abc] in addition to *
 * SamB wonders if the japanese have a wide copyright symbol ...
<SamB> ... nuts. they don't seem to :-(.
<SiDi> Hello people
<SiDi> Does anyone know if there are IRC commit bots for bzr branches hosted on LP, by chance ?
<SamB> jelmer: hmm, bzr doesn't much like being killed mid-branch, does it?
<RenatoSilva_> verterok: hi
<Adys> amanica_: cool, glad to hear :) if you got any suggestion do tell on the mail
<verterok> RenatoSilva_: hi!
<amanica_> Adys: ok, hope I get round to it
<RenatoSilva_> verterok: hi, I've sent you a replacement for the log view fix. The fix was generalized to solve another problem, the one I thought it was related to JSDT. I also added another fix to iirc revno which was sending a non-ascii file:// URL to bzr which was causing an error in error view. These changes are in my branch bzr-java-lib/encoding-fixes. I also changed xmoutput's code to make xmlannotate work with non-ascii paths (this is
<RenatoSilva_> verterok: This change is in bzr-xmlouptut/encoding-fixes (which was previously merged).
<verterok> RenatoSilva_: oh, cool!
<verterok> RenatoSilva_: I'll take a look to the merge proposal(s) tonight
<Skoorbulous> LarstiQ: I tried the chmod -R * and it still reports that the files are owned by root
<RenatoSilva_> verterok: I detected the xmlannotate issue while running bzr-eclipse tests. Now there are only 3 test failures, all regarding path comparison. The one expected is like a\b\c but it is returned a/b/c. As they're not literal values, I wasn't sure about which one was correct so that I could try fixing it. So I'm just telling you.
<LarstiQ> Skoorbulous: you did supply the correct user to chown to?
<verterok> RenatoSilva_: bzr-eclipse or bzr-java-lib?
<RenatoSilva_> verterok: sorry, bzr-java-lib
<LarstiQ> Skoorbulous: oh, and chown, not chmod
<LarstiQ> Skoorbulous: so, in my case: `chown larstiq -R .`
<verterok> RenatoSilva_: oh, ok. I'll take a look to the while doing the review
<RenatoSilva_> verterok: there are some test failures in xml-output too. One tries to find a python/executable entry in xmlversion, however in my case it is returned a python/dll (bzr built-in)
<verterok> RenatoSilva_: oh, bzr.exe, right?
<verterok> RenatoSilva_: I'll change the test to be bzr.exe friendly
<RenatoSilva_> verterok: It was like assertEquals(1, count(pythn/executable)), then I tested a change...
<verterok> RenatoSilva_: could you file a bug about this and the failing tests in bzr-java-lib? that will help us to keep track of this issues
<RenatoSilva_> verterok: assertEquals(1, count(python/executable) + count(python/dll))
<RenatoSilva_> verterok: the other failure is an XML parser error for a weird non-sense non-ascii char inside the output of some command (I can't recall which one)
<RenatoSilva_> verterok: I couldn't find where that char came from, it didn't even make sense in the XML
<verterok> RenatoSilva_: weird... if you can reproduce the error, please save the traceback
<RenatoSilva_> verterok: let me see
 * SamB wonders if bzr branch shouldn't repack revisions every so often in mid-branch rather than waiting until the end
<RenatoSilva_> how to avoid searching all plugins in selftest?
<LarstiQ> RenatoSilva_: -s bp.<pluginyouareinterestedin>
<RenatoSilva_> LarstiQ: oh dot, I was trying semi-colon
<LarstiQ> RenatoSilva_: bp. is actually a shorthand for bzrlib.plugins.
<RenatoSilva_> LarstiQ: what does bp stands for
<RenatoSilva_> LarstiQ: ah ok
<LarstiQ> RenatoSilva_: so it is the python identifier for the containing module
<LarstiQ> RenatoSilva_: some of those we use so frequently, they have shorthands, like bp for plugins or bt for tests
<LarstiQ> sorry, bzrlib.tests, to be complete
<RenatoSilva_> FYI, bzrtools delivered with bzr 1.16-1 has a test failure, it tries to load a test module which does not exist
<hsn_> verterok: if bzr st reports filename* then bzr-eclipse doesnt see it as changed
 * RenatoSilva_ tried right now run it at work, many more failures: http://pastie.org/544640.txt
<verterok> hsn_: oh, good catch :)
<verterok> hsn_: would you mind to file a about this?
<Skoorbulous> LarstiQ: it worked! Thanks so much. Now my problem is when I run bzr annotate file it spits everything out apparently in one long string without crlf - it is so messy I can't make anything of it
<LarstiQ> Skoorbulous: does the file actually contain more than 1 line?
<Skoorbulous> it is a php file and it apparently does when I open in a text editor
<SamB> Skoorbulous: what does wc -l say ?
<RenatoSilva_> verterok: http://pastie.org/544652.txt
<Skoorbulous> it says "0 batch_production.php"
<jelmer> SamB: patches to support more kinds of globbing are welcome as long as they come with sufficient tests
<SamB> Skoorbulous: I guess you're hosed -- you seem to be depending on word wrap
<LarstiQ> RenatoSilva_: FAILED (failures=35, errors=1) is what I get for bzrtools
<Skoorbulous> it definitely has multiple lines I guess there is an encoding compatibility problem or something
<RenatoSilva_> verterok: the error if for the weird char, the failure is for the python dll instead of executable
<SamB> Skoorbulous: ... it didn't originate on a Mac, did it?
<jelmer> SamB: it's fairly independent of the rest of the code
<Skoorbulous> yes it is on a mac
<SamB> Skoorbulous: ah.
<Skoorbulous> and probably originated from a mac
<RenatoSilva_> LarstiQ: you mean it's normal?
<hsn_> verterok: you want output of bzr xmlstatus?
<jelmer> SamB: bzr branch does indeed fail if you break it, see a recent discussion between lifleless and me on the mailing list for details
<SamB> Skoorbulous: oh. it probably uses only CR as the line seperator...
<gioele> helo
<Skoorbulous> so I should just find a way to convert all cr to crlf?
<verterok> hsn_: no, not needed, just to keep track that the decorator isn't handled the change of the executable bit
<SamB> jelmer: I'm talking about what it leaves behind
<gioele> what is more correct: "ghost revision" or "revision ghost"? I'd say ghost revision
<verterok> RenatoSilva_: ok, looking
<LarstiQ> RenatoSilva_: ideally, it wouldn't be. But I have no idea about bzrtools development
<SamB> jelmer: oh, and breaking was insufficient
<SamB> I had to ^Z and kill it
<LarstiQ> RenatoSilva_: it doesn't seem to be a problem specific to your computer if that is what you're asking
<verterok> hsn_: that info is in xmlstatus, it's just bzr-eclipse not using it :/
 * SamB looks, however
<LarstiQ> SamB: that, shouldn't be needed
<SamB> it wouldn't have been if the first ^C didn't start it trying to repack
<jelmer> SamB: ^C always works for me
<SamB> which was thrashing awfully
<SamB> I only have ~512 MiB of RAM
<jelmer> SamB: but yeah, the recent mailing list thread should explain most of the reasoning
<jelmer> SamB: it should probably just remove the directory,
<SamB> jelmer: yeah
<SamB> at least when there isn't a repository in it
<SamB> dunno about if there is
<RenatoSilva_> s/if for/is for
<RenatoSilva_> LarstiQ: at home when I try just selftest it stops in bzrtools while loading a non-existing test module
<SamB> jelmer: so what's the subject of this thread?
<LarstiQ> RenatoSilva_: that I don't get
<verterok> RenatoSilva_: I need to debug this, so I'll push it for later, still at work
<LarstiQ> RenatoSilva_: do you know which one?
<RenatoSilva_> LarstiQ: I don't think 'ideally'
<RenatoSilva_> LarstiQ: which module? I can't recall
<Skoorbulous> LartiQ: so I should just find a way to convert all cr to crlf?
<LarstiQ> Skoorbulous: that would be a workaround
<LarstiQ> Skoorbulous: (and something I'd personally do anyway)
<RenatoSilva_> LarstiQ: I guess it's test_fetch_ghosts
<jskulski> I have a module I am working on that I keep in a bzr repos that I branched into a svn project and I wanted to push back some changes
<jskulski> but when I do bzr segfaults saying the svn repo is locked (which it is). however after i svn cleanup, and try to push again bzr is doing the locking
<RenatoSilva_> verterok: bug 398997, bug 399000
<ubottu> Launchpad bug 398997 in bzr-xmloutput "Test failures and errors on Windows" [Undecided,New] https://launchpad.net/bugs/398997
<ubottu> Launchpad bug 399000 in bzr-java-lib "Test failures on Windows" [Undecided,New] https://launchpad.net/bugs/399000
<jskulski> i dont want bzr to do anything with .svn besides ignore it
<lifeless> moin
<RenatoSilva_> verterok: with all these changes in bzr-xmloutput, bzr-java-lib and redstone xmlrpc, I could run bzr-eclipse pretty fine in Galileo :)
<RenatoSilva_> verterok: I mean, with non-ascii paths
<jelmer> jskulski: uninstall bzr-svn
<jskulski> jelmer:: anything less drastic?
<jskulski> i need bzr-svn for other projects
<jelmer> jskulski: you can specify --no-plugins, which will disable all plugins including bzr-svn
<jskulski> jelmer:: thank you
<Skoorbulous> is there simple version control software I can use? I feel like bzr is a little complex and hard to use for simple mortal beings like myself
<dash> Skoorbulous: !
<dash> Skoorbulous: bzr is the easiet vcs i've ever used :)
<dash> Skoorbulous: what difficulties have you had?
<Skoorbulous> well shoot I am an idiot then
<dash> Skoorbulous: or maybe i'm just too used to svn
<Skoorbulous> well for example now I'm going to have to find a way to convert all the cr in all my files to crlf
<Skoorbulous> I'd prefer not to have to learn unix just to control the versions of my website
<RenatoSilva_> verterok: BTW, https://bugs.eclipse.org/bugs/show_bug.cgi?id=282226
<ubottu> bugs.eclipse.org bug 282226 in CVS "CVS feature abstraction" [Enhancement,New]
<dash> Skoorbulous: not sure what that has to do with version control?
<SamB> jelmer: so ... what was the subject line on this email thread ?
<jelmer> SamB: I'm not sure exactly
<SamB> jelmer: date?
<Skoorbulous> exactly - it has nothing to do with version control so it would be nice not to have to do all these things just to be compatible with bzr
<jelmer> I think it was in a thread about being able to resume bzr-svn branches
<jelmer> SamB: it was in the last 30 days
<Skoorbulous> my website doesnt seem to mind that I have cr in my docs
<SamB> gee that helps a lot :-(
<lifeless> Skoorbulous: you don't need to convert your files to use bzr on them
<Skoorbulous> well for example I can't use annotate because it sees everything in the file as one line
<dash> Hm
<dash> what version of bzr are you using?
<Skoorbulous> me? I'm using the latest version. Just installed yestereday
<verterok> RenatoSilva_: thanks for the bugs :)
<verterok> RenatoSilva_: that's great! you did most of the work ;)
<verterok> RenatoSilva_: oh, that would be excelent (https://bugs.eclipse.org/bugs/show_bug.cgi?id=282226)
<ubottu> bugs.eclipse.org bug 282226 in CVS "CVS feature abstraction" [Enhancement,New]
<lifeless> Skoorbulous: that is true. However we're currently working on annotate to improve it; when thats been done it will be able to annotate files with other End-Of-Line formats.
<RenatoSilva_> verterok: I can't wait for new releases of bzr-java-lib and xmloutput :)
<verterok> RenatoSilva_: as soon all this fixes land in trunk, new version..maybe a big jump to 0.9
<Skoorbulous> Lifelss: can you suggest a way that I can convert my docs to an end of line symbol that will work with bzr and continue to fuction on my mac web server?
<RenatoSilva_> verterok: the only problem is xmlrpc, I will still need a patch to make it work
<verterok> RenatoSilva_: why?
<RenatoSilva_> verterok: because it was the ExPat error, do you remember? It is caused by redstone client declaring utf-8 in XML to send, but sending platform default bytes. Then I did that patch, but they need to release it right?
<verterok> RenatoSilva_: oh, I completely missed that \o/
<verterok> RenatoSilva_: I can bundle whatever version of redston xmlrpc we need
<verterok> in bzr-eclipse
<RenatoSilva_> verterok: what do you mean
<verterok> RenatoSilva_: your patch to the redstone xmlrpc guys, I missed that
<RenatoSilva_> verterok: it is being watched in the xmloutput bug
<RenatoSilva_> verterok: I can bundle whatever version of redston xmlrpc we need --> what do you mean?
<lifeless> Skoorbulous: for each file do 'cat file | tr \\r \\r\\n > file.fixed'
<RenatoSilva_> verterok: however redstone guys didn't give any feedback yet
<verterok> RenatoSilva_: if bzr-eclipse needs a patched redstone-xmlprc, I can make the build with the "fixed" redstone-xmlrpc
<RenatoSilva_> verterok: ok, nice
<verterok> RenatoSilva_: as it's just a dependency in bzr-java-lib pom.xml, and I already provides a maven repository with all the depdendencies, I cound push a new jar to the maven repo ;)
<Skoorbulous> lifeless, can I do cat * | tr \\r \\r\\n ?
<RenatoSilva_> verterok: you could just add the patch file with the bug number somewhere, then _during the buid_ you patch the diff, so that you can use updated versions of redstone library...
<Skoorbulous> i.e., can I just use a wildcard?
<verterok> RenatoSilva_: I'm not building redstone-xmlrpc during the build of bzr-eclipse, just using the jar available in the maven repository.
<RenatoSilva_> verterok: ah ok
<RenatoSilva_> verterok: but that maven repo, it is self-made right?
<verterok> RenatoSilva_: right, I can use a patched version from the maven repo ;)
<RenatoSilva_> verterok: and you put the lib there right, so you'd get the source and patch the fix and build the custom lib and put int the repo right?
<verterok> RenatoSilva_: yes
<verterok> RenatoSilva_: but I don't know if I can call it redstone-xmlrpc...you know licenses, etc
<RenatoSilva_> verterok: ok I just mean to keep the source of the custom lib as {source + patch}, and the resulting build as {compile source + apply patch }, instead of {pacthed source} -> {compile patched source}. I think it's a better approach, just a suggestion.
<verterok> RenatoSilva_: I agree, just that including that in the build of bzr-eclipse is overkill
<RenatoSilva_> verterok: ok
<RenatoSilva_> verterok: the patch is pretty simple. There is an encoding in some .properties file. It is used in XML header, but not in the actual bytes (new String(bytes)). I just changed the content to new String(bytes, readEncodingFromProperties).
<RenatoSilva_> verterok: note: the patch in sf itself is out-dated (can't be updated), because it uses hard-coded "UTF-8". Then one attached in launchpad is ok, it gets from preferences.
<verterok> RenatoSilva_: do you remember the bug number?
<lifeless> Skoorbulous: no - tr outputs to std out
<lifeless> so you need to translate each file to a temp name and then mv the output back over the original file
<lifeless> Skoorbulous: there are probably scripts on the web that will do groups of files for you
<RenatoSilva_> verterok: bug 300300, in SF: http://sourceforge.net/support/tracker.php?aid=2816563
<RenatoSilva_> verterok: sorry, bug 388300
<ubottu> Launchpad bug 300300 in expect-tcl8.3 "multixterm doesn't work, expectk missing and cannot be installed" [Undecided,New] https://launchpad.net/bugs/300300
<ubottu> Error: <Bugtracker.plugin.Sourceforge instance at 0x574cc20> bug 2816563 not found
<ubottu> Launchpad bug 388300 in bzr-xmloutput "Encoding problems in xmloutput: non-ascii URLs and ascii decoding of non-ascii strings" [High,Confirmed] https://launchpad.net/bugs/388300
<verterok> RenatoSilva_: thanks!
<RenatoSilva_> verterok: the up-to-date patch is attached in lp (If you're going to create the custom lib): http://launchpadlibrarian.net/28683665/xmlrpc_fix.diff
<verterok> RenatoSilva_: great!
<verterok> RenatoSilva_: we can use the patched xmlrpc, but I'll try to contact the redtone devs
<RenatoSilva_> verterok: ok
<RenatoSilva_> RenatoSilva_: what do you mean with 0.9, xmoutput?
<RenatoSilva_> verterok: ^
<verterok> RenatoSilva_: the version number, currently it's 0.8.4 and trunk is 0.8.5
<RenatoSilva_> verterok: ah ok, I tought for a moment it was 0.9.4 or so
<RenatoSilva_> verterok: trunk 0.8.5? so the commit comment on that means its development is starting? I thought it means it was actually released...
<verterok> RenatoSilva_: I was this >< close to release 0.8.5, and then you came and filed a lot of bugs, so I just ignored 0.8.5, and targeted all this fixes to 0.8.6 ;)
<verterok> RenatoSilva_: btw, thanks a lot!!
<RenatoSilva_> verterok:hehehe, sorry for interrupting 0.8.5 :)
<verterok> RenatoSilva_: at all, great work! :)
<RenatoSilva_> verterok: thank you, thanks for helping
 * RenatoSilva_ is away
<verterok> RenatoSilva_: seeya later!
<jml> good morning Bazaar!
<jkakar> Good morning jml. :)
 * RenatoSilva_ is gmt -3, 7pm
<poolie> good morning
<RenatoSilva_> good night
<RenatoSilva_> ctcp verterok TIME
<lifeless> hi p obst
<lifeless> bah
<lifeless> hi poolie
<lifeless> sorry obst, mistyped
<poolie> hey
<gioele> will a property set with propset -R be inherited by new directories?
<SamB> lifeless: I don't understand your excuses about interrupted "branch"es
<gioele> (sorry, wrong VCS :))
<SamB> gioele: I didn't think bzr supported those (yet?)
<lifeless> SamB: what don't you understand?
<SamB> lifeless: well, it might have to do with the fact that I'm trying to branch from a multi-thousand-rev SVN branch
<lifeless> SamB: Thats a very different use case than interrupted branches of bzr to bzr
<SamB> true
<lifeless> SamB: bzr-svn does everything incremental anyway
<SamB> it doesn't update the branch heads during a "bzr branch" incrementally
<lifeless> thats true
<SamB> on a slightly different note, I'm wondering why "bzr branch" is waiting until all revisions are pulled to start repacking any of them
<lifeless> generally we don't repack any
<igc> morning
<SamB> oh. maybe I need to ask jelmer about that ?
<lifeless> its only when data conversion is needed that any repacking will occur (or an autopack, but thats orthogonal to fetching data - its db maintenance)
<SamB> still, it doesn't seem like it would kill you to do a checkpoint every thousand revisions or so?
<SamB> hmm, I switched back, didn't I?
 * SamB can't seem to hold just one conversation at a time lately
<lifeless> SamB: bzr fetching doesn't move data topologically or chronologically
#bzr 2009-07-14
<lifeless> SamB: so yes, it would kill us.
<SamB> lifeless: how does it move the data?
<lifeless> we'd have to figure out a lot more structure than we do, which would push memory usage up, processing time up, and increase network traffic - in pathological cases by thousands of times.
<SamB> tarball?
<lifeless> we send the delta compressed data as-is
<lifeless> with the minimum edits to its storage to meet user expectations about when data propogates
<SamB> right.
<SamB> is that how it works when pulling between formats?
<lifeless> depends on the formats
<SamB> examples?
<lifeless> I don't mean to be rude, but I've a tonne of code to write
<lifeless> unless this is more than academic, can I encourage you to look at the various formats in repoformats/
<SamB> what code should I read, then?
<SamB> oh, repoformats
<lifeless> which define constraints like needing topological insertion, atomic transactions etc
<poolie> lifeless: bug 390563 is marked in-progress, should it be marked assigned to you
<ubottu> Launchpad bug 390563 in bzr "absent factory exception from smart server when streaming 2a stacked branches" [Critical,In progress] https://launchpad.net/bugs/390563
<lifeless> cross format fetching is parameterised by the RepositoryFormat objects + the stream behaviour / InterDifferingSerializer (streaming is for network, IDS for local)
<lifeless> SamB: we try to do the least work at any time when copying data
<lifeless> its the whole background theme to all this code
<lifeless> poolie: no
<SamB> mmmhmm.
<lifeless> poolie: jam has a branch to land
<poolie> thanks
 * SamB settles for running bzr branch with -rsvn:1000, then bzr pull with -rsvn:2000 etc.
<SamB> (for the moment)
 * SamB keeps expecting "bzr revert" to ask him hunk-by-hunk for some reason ...
<GungaDin> I installed bzr from the source... how do I uninstall it?
<lifeless> delete it ;)
<GungaDin> it installed like a million files in different directories
<lifeless> it should have written the bzr script, and a single directory 'bzrlib' in your python site-packages directory
<lifeless> jam: around?
<GungaDin> I'm running bzr (1.16 or 1.17rc1) froma Fedora 11 installed inside VirtualBox, and it always hangs around 1054K or 1060K when checking out a branch...
<GungaDin> any ideas why?
<mwhudson> GungaDin: how long have you left it to conclude that it's hung?
<GungaDin> hours?
<GungaDin> It succeeds from other machines
<poolie> SamB: i fully support getting better api docs, but filing bugs on every class without them, if that's where you're heading, is probably not the most efficient way to do it
<poolie> how about if for instance you put up a branch containing your guesses at better descriptions or the answers people give to your questions about the api?
<mwhudson> GungaDin: oh ok
<mwhudson> GungaDin: no idea then really :(
<poolie> hello mwhudson
<mwhudson> hi poolie
<GungaDin> yeah, weird.
<MT-> Can somebody explain the correct way to merge two branches with the same ancestory?
<GungaDin> are there any logs I can check?
<garyvdm> MT-: bzr merge BRANCH-B
<lifeless> GungaDin: you can look in ~/.bzr.log
<lifeless> GungaDin: and/or use strace or lsof to see whats going on
<MT-> garyvdm: I was confused because I would do that and then get a message when I tried to commit the merge about no changes having been made
<MT-> garyvdm: I added --unchanged to the commit and it seems to have worked - thanks
<fullermd> Er.  If commit said there were no changes, there probably were no changes...
<fullermd> (and if there were, and commit wasn't seeing them, --unchanged probably didn't make it start)
<MT-> fullermd: that's why I was so confused
<fullermd> I suspect merge's output will be more enlightening.
<MT-> http://bzr.pastebin.com/m1d9af2f9
<MT-> exactly like I'd expect
<SamB> poolie: I wasn't going to do it for every class, no
<SamB> for starters, I'm skipping all the ones whose names begin with _ ;-P
<poolie> there probably should be some better way to track this
<poolie> it just doesn't map well to bugs
<SamB> poolie: yeah
<SamB> but I couldn't think of any other thing to do that wouldn't get completely lost
<SamB> and honestly I don't really have any but the vaguest guesses what it's for ...
<mwhudson> http://starship.python.net/crew/mwh/bzrlibapi/undoccedSummary.html
<mwhudson> (not linked to or very useful though)
<SamB> lots of things might be clearly-enough named/subclassed that a docstring would, in fact, be redundant
<SamB> I'm not planning to file bugs against those
<lifeless> I think its reasonable, when something confuses you, to ask for help on it
<lifeless> if you write a docstring and submit a merge as a result of the help, a bug is kindof wasteful
<lifeless> OTOH if you don't  plan to submit a patch yourself, a bug is accurate, but perhaps its unlikely anyone will work on it
<poolie> agree
<poolie> i think one can be kind of usefully provocative by asking the question and then turning it into the patch
<SamB> lifeless: I agree, but to do that ... wouldn't I have to have understood what you said about InterDifferingSerializer ?
 * SamB does a lastlog to see if he mentioned it more than once?
<lifeless> jml: did my inventory checks stuff get into 1.17rc1?
<jml> lifeless, I don't know.
<SamB> jelmer: what the heck is a "native foreign revision"?
<GungaDin> lifeless - how would lsof or strace help me to understand what's going on?
<SamB> GungaDin: well, it might end up telling you that something was actually happening
<SamB> or at least give you an idea where they go wrong
<GungaDin> How can I uninstall a version installed from the source?
<jelmer> SamB: where is that mentioned?
<SamB> jelmer: bzrlib.foreign
<lifeless> GungaDin: as I said before you need to delete it
<SamB> GungaDin: one way would be to install it from the source again, and take note of all the files installed
<SamB> and then delete them
<GungaDin> why don't you supply an uninstall option??
<spiv> GungaDin: python's distutils don't (currently) provide any mechanism to do that.
<spiv> There's a proposal on python-dev atm that would address that, I think.
<jelmer> SamB: revisions that were not roundtripped from bzr
<GungaDin> alright.
<GungaDin> thx
<SamB> jelmer: yeah ... that was my eventual guess
<spiv> GungaDin: if I'm installing something system-wide from source I usually use stow, mostly because it means I can always uninstall it later.
<SamB> jelmer: now to figure out how to say that without using an oxymoron
<GungaDin> hmmm... never used stow.
<GungaDin> never even heard of it, to be honest.
<spiv> GungaDin: http://www.gnu.org/software/stow/
<spiv> Although it's probably packaged for Fedora, which I think you said you are using?
<GungaDin> yeah, it is.
<GungaDin> justed yummed it :P
<SamB> GungaDin: tastey, is it?
<GungaDin> missing a bit of salt.
<SamB> hmm, what column should comments be wrapped at?
<SamB> more or less
<jml> 79
<SamB> would it make sense to wrap a bit sooner if it puts a >40 char parenthetical on it's own line?
<SamB> well, let me just paste ...
<SamB> okay, here it is: http://paste.ubuntu.com/217434/
<SamB> which of those comments is better wrapped?
<lifeless> the first
<SamB> okay, next question: does jelmer like the comment?
<garyvdm> jml: why 79 and not 80? Does that apply for all code?
<jml> garyvdm, 79 is what pep8 says for general code wrapping.
<jml> garyvdm, I don't know whether it's binding on bzr (I suspect it isn't)
<jml> garyvdm, but if someone asks a wrapping question about a Python project, you need a good reason to say anything other than 79 :)
<jml> (pep 8 actually recommends 72 for comments & docstrings, but that's pretty silly, since none of the editors on my system will do that automatically)
<garyvdm> jml: I was just under the impression that it was 80 not 79.
<SamB> garyvdm: Emacs displays an \ and wraps if you go over that
<jml> (under SamB's configuration)
<SamB> (with an 80-character-wide terminal, or the default window size)
<SamB> jml: not just mine
<garyvdm> Ah - the -1 is for the \
<SamB> that's, of course, the *default* default
<SamB> garyvdm: yeah
<fullermd> Historically, some terminals had Issues(tm) with drawing characters in the last column of the last line, which is one reason to go with 79 over 80.
<fullermd> (probably none of them have been USED in a long count of years, but I probably have one in my closet   :P)
<SamB> well, depends how you define issues
 * garyvdm changes editors edge line from default of 80 to 79
<SamB> there are some terminfo/termcap flags to specify standard "issues" terminal type has
<SamB> jml: also, my editor seems to have somehow been given the impression that like 72 is good for comments in Python ...
<SamB> +something
<fullermd> I sometimes wonder how many of those flags still work with modern apps.
<fullermd> I was looking through termcap the other week and reflecting that, "Gee, 'xterm' is used all the time, and 'vt100', and probably a few others like 'cons25', but I'll bet 98% of these entries haven't been used in 20 years."
<SamB> fullermd: could be, but some of these flags *apply* to xterm and/or some of it's ilk
<SamB> (oh, and better not forget "linux" and "screen")
<fullermd> Yeah.  But then there are all these comments about "I don't know what this entry is for, there's no model number or attribution", with timestamps in the early 80's.
<SamB> yeah, probably those ones aren't really used much ;-)
<lifeless> jml: I routinely use all 80
<lifeless> because the bottom right character works these days
<SamB> lifeless: vi-using jerk!
<lifeless> :P
<fullermd> Yeah.  And all these entries for homebrew terminals...
<fullermd> Including (at a spotcheck) some that call for tabset files the system doesn't even include   :p
<SamB> what files ?
<SamB> anyway, a lot of these flags are basically used by curses + screen
<fullermd> Beats me.  I'm not insane enough to have learned termcap that deeply.
<SamB> as far as I can tell
<fullermd> I learned enough to trick screen into doing some insane things and mess with VT10x and such.  That was quite enough for me.
<SamB> I only try to learn it when something isn't working right
<jml> test_transport_implementations has been renamed to per_transport?
<lifeless> jml: sounds plausible
<mwhudson> jml: i have a branch fixing that
<jml> mwhudson, oh cool. anything I can do to get it landed?
<mwhudson> jml: i'll ask you to review it
<GungaDin> my bzr always hangs on "Fetching revisions:Get stream source"
<GungaDin> ....
<GungaDin> any ideas why?
<lifeless> look at it with strace or lsof
<GungaDin> how do I look at it with lsof?
<GungaDin> lsof just tells me what files are open.
<lifeless> thats right
<lifeless> its data about whats going on
<lifeless> just as strace would b e
<igc> back
 * igc hits the review queue
<GungaDin> when I do strace on the process, the output is: read(6,
<GungaDin> what does that mean??
<lifeless> it means its waiting for IO
<lifeless> on fd 6
<GungaDin> so why isn't any IO coming? :)
<lifeless> well, I don't know
<lifeless> lsof can tell you what fd 6 is
<GungaDin> are there any open source projects that use bzr?
<lifeless> yes, lots
<GungaDin> such as?
<lifeless> mysql
<lifeless> I appreciate you're having some trouble, and I'd like to help
<lifeless> you need to gather data though
<GungaDin> I don't know how really...
<GungaDin> I think fd 6 was just a pipe.
<GungaDin> apart from that there's nothing much I can say...
<GungaDin> checkout works on oher machines.
<lifeless> what url scheme are you pulling from?
<lifeless> (bzr+ssh? http? ...?)
<GungaDin> bzr+ssh
<lifeless> that should just work really
<SamB> and you can SSH out from that VM fine?
<lifeless> is it a very big project or some such?
<GungaDin> yup
<GungaDin> it's quite big
<GungaDin> but it shouldn't hang like this
<lifeless> so the client is waiting for data from the server
<lifeless> do other clients work on the same project ok?
<GungaDin> yup
<GungaDin> that's what I said: the checkout works on other machines
<lifeless> to answer your other question more fully - http://bazaar-vcs.org/WhoUsesBzr - lists /some/ of the open source projects using bzr
<GungaDin> cool
<lifeless> there are more (based on people asking for support)
<GungaDin> I'll try checking out from one of those project
<GungaDin> we'll see how it goes
<lifeless> theres something like 20K projects on launchpad with branches
<lifeless> all of ubuntu is imported, for instance
<GungaDin> imported into bzr?
<lifeless> yes
<GungaDin> from cvs? svn?
<lifeless> depends on the thing
<lifeless> most of the ubuntu packaging branches are imported from the dpkg source packages
 * wgrant points over to https://code.launchpad.net/ for lots of branches.
<lifeless> there are also thousands of svn/cvs/git imports
<lifeless> GungaDin: I also suggest you file a bug to provide a place we can gather systematic data about your problem
<GungaDin> I don't know if it's a bug.
<lifeless> something is wrong somewhere
<lifeless> it may be system config
<lifeless> or a bug
<lifeless> either way, having a place to record notes about the problem is a good idea
<lifeless> and we usually do that in our bug tracker
<GungaDin> hmmm... seemed to work with https on alltray.
<GungaDin> how can I checkout using bzr+ssh from an open source project on launchpad?
<GungaDin> or somewhere else.
<GungaDin> I'd like to see that the exact scheme works with a different project.
<lifeless> setup your ssh keys in launchpad
<garyvdm> GungaDin: you need a lp user name with a ssh key set to use bzr+ssh on lp
<garyvdm> then bzr branch lp:PROJECTNAME
<lifeless> then turn http:// into bzr+ssh://USERNAME@ in any of the http urls
<GungaDin> *sigh*
<GungaDin> doesn't seem like it's working
<GungaDin> where do I check the branches of each project on lp?
<spiv> The "code" link for a project will show the branches.  e.g. https://code.launchpad.net/bzr
<poolie> i'd like to say just ssh://host...
<GungaDin> well, if I bzr+ssh://myaccount@code.launchpad.net/bzr/trunk - it hangs forever...
<poolie> i know there's a bug for it
<lifeless> poolie: that still really squicks me
<poolie> sorry but i think you'll just have to cope
<poolie> you don't have to use it :)
<lifeless> as long as we don't drop support for bzr+ssh I'll deal
<lifeless> but I really think its liable to lead to trouble down the track
<GungaDin> lifeless - I can't bzr+ssh the way you mentioned.
<lifeless> GungaDin: what happens
<GungaDin> nothing
<lifeless> no error?
<poolie> like the onion or someone said
<GungaDin> I tried: bzr co bzr+ssh://myaccount@code.launchpad.net/bzr/trunk
<poolie> "why don't we have _optional_ gay marriage?"
<GungaDin> eventually I get a timeout error from ssh
<spiv> GungaDin: branches are on bazaar.launchpad.net
<lifeless> GungaDin: bzr+ssh://myaccount@bazaar.launchpad.net/bzr/trunk
<poolie> does that really still time out?
<poolie> that's lame
<spiv> GungaDin: e.g. bzr+ssh://myaccount@bazaar.launchpad.net/~bzr.dev/bzr/trunk
<poolie> i thought the firewall was changed a long time ago
<lifeless> GungaDin: actually spiv has it right
<poolie> maybe it regressed
<lifeless> poolie: I don't follow the onion ref
<spiv> GungaDin: if you use "bzr launchpad-login" you can just do "bzr co lp:bzr" and it will look up the right bzr+ssh URL for 'bzr' for you.
<poolie> nm, it's a joke
<lifeless> poolie: I'm concerned that url handlers in firefox are going to end up fighting with ssh: urls
<lifeless> poolie: in a way that won't happen with what we do today
<poolie> as if all the people objecting to gay marriage were afraid they personally would have to gay marry
<poolie> i'm not saying you're being that silly
<lifeless> poolie: and further that we're adding ambiguity that doesn't need to exist
<poolie> or indeed that they are
<lifeless> poolie: I could care less what individuals use as local scheme aliases; things that are liable to make the ecosystem more fragile are something I do care about.
<GungaDin> spiv - I get an error saying it's not a trunk
<poolie> we could possibly apply a kind of 'be strict in what you emit' here
<poolie> and just treat them as a shortcut on input
<GungaDin> sorry..
<GungaDin> I mean "not a branch"
<poolie> i think bzr rejecting somebody typing the url is too pedantic
<spiv> GungaDin: oh sorry
<spiv> GungaDin: .../~bzr/bzr/trunk
<spiv> GungaDin: that's what I get for typing from memory!
<spiv> GungaDin: like I say, I usually just use "lp:bzr"
<lifeless> spiv: however that can use http
<GungaDin> better
<lifeless> spiv: and I don't think it tells the user
<GungaDin> thx
<lifeless> spiv: which is why I suggested explicitness here for debugging
<spiv> lifeless: I'm not disagreeing :)
<lifeless> ;)
<lifeless> poolie: bzr does tell the user what url they should be using.
<lifeless> poolie: if bzr were to nag that its altering the url to be bzr+ssh and translated, well that might be ok. But I think its pragmatically bad to start emitting ssh:// urls ourselves, or encouraging people to put them in app handles
<poolie> ah
<poolie> i'd forgotten it gave a suggestion in the message
<poolie> let's discuss it if/when somebody actually starts on it
<lifeless> I'd actually like to put this to bed permanently someday
<lifeless> its a bit of a recurring nightmare
<lifeless> unless we embed a terminal in bzr
<poolie> it's a URL
<poolie> it locates a resource
<poolie> it doesn't need to say everything about what to do with the resource
<lifeless> if you click on  a ssh url in a browser, what should happen?
<poolie> presumably it'll go through the 'what app do you want to use for this' function?
<poolie> of course at present: nothing happens afaict
<poolie> to me this seems reasonable
<poolie> what do you think should happen?
<lifeless> As a user I'd expect the sshshell (there is a gui ssh shell colin walters has been working on - its really nice) to fire up by default
<lifeless> with no questions
<poolie> k, that sounds good then
<poolie> what's not to like?
<poolie> if the web page wants to say "open this in bzr" there should definitely be a syntax for that
<poolie> hm
<poolie> i mean really it should be something like handwavey ssh://example.com::bzr/some/dir
<poolie> ssh there *and then what*?
<poolie> just pointing to the directory on the host doesn't really mean a lot
<poolie> maybe this is in the ssh url spec
<poolie> if any
<lifeless> this is a bit of a weakness in std66
<lifeless> and AFAIK the only workaround at the moment is in the scheme
<lifeless> I'll note that bzr+ is less letters than ::bzr :P
<spiv> lifeless: you just need a keyboard with a :: key ;P
<spiv> You could maybe adapt a keyboard with a -- key for tla ;)
 * lifeless shudders
<poolie> i shall treat that trolling with the respect it deserves
<lifeless> pragmatically, web browsers dispatch off three things:
<lifeless> embedded controls where a plugin is invoked
<lifeless> the scheme
<lifeless> and the mime type
<GungaDin> How big is the the trunk of bzr?
<GungaDin> around 68147K?
<lifeless> GungaDin: about 70MB
<GungaDin> seems like my bzr hangs again
<GungaDin> strace shows the same thing
<GungaDin> read(6,
<spiv> GungaDin: and I guess if you strace the ssh subprocess it's stuck in a recv or a select on a socket?
<GungaDin> yeah, select.
<spiv> GungaDin: but it's managed to download 68147kB to .bzr ?
<GungaDin> seems like it.
<GungaDin> apparently it always hangs at the end.
<GungaDin> like with my repo.
<spiv> I wonder if you have a broken plugin installed?
<spiv> Can you try sending SIGQUIT to your bzr process?
<spiv> That will drop it into the Python debugger.
<lifeless> or -Dhpss perhaps
<spiv> Then type "bt" and pastebin the result.
<GungaDin> kill -?
<spiv> kill -QUIT
<GungaDin> well.. I already stopped it with CTRL-C
<spiv> Or hit Ctrl-\ in the terminal.
<spiv> Ah.
<GungaDin> any other smaller repo?
<spiv> Did it give a backtrace (or did it leave one in ~/.bzr.log)?
<lifeless> GungaDin: you can use the one you were having trouble with earlier, if thats smaller
<spiv> ~jml/testtools/trunk on the same server is quite small.
<GungaDin> ok
<GungaDin> brb
<spiv> GungaDin: another test to try would be to add --no-plugins to a command that hangs.
<GungaDin> tried that already
<GungaDin> it didn't help
<spiv> Ok.
<lifeless> igc: I have more inventory delta stuff
<lifeless> igc: I'll be updating the merge request this avo
<lifeless> igc: I'd love if if you could tell me if it sucks perf wise
<igc> lifeless: shall do. I want to get through some more reviews then I'll make some measurements ...
<GungaDin> I sent a SIGQUIT to bzr... what do you want to do now, spiv?
<igc> lifeless: I'm all for safety first but ...
<igc> lifeless: we need to be sure we don't throw away all the recent gains accidentally
<lifeless> for sure
<lifeless> the reason this has taken a week is I've been looking and thinking carefully about every change
<lifeless> I'm sure there will be fallout, but I'm also sure it will be much less than the gains we've made by better disk structure
<spiv> GungaDin: type "bt" and pastebin the traceback that makes
<spiv> GungaDin: that will tell us where in bzr it is stuck, which might help diagnose what's going wrong.  (Even though it's almost certainly not bzr's fault)
<lifeless> jml: so, can code auto update diffs please?:) at the moment, clicking superseded and aking a new review seems to me to be *more* work for lp...
<jml> lifeless, you're asking the wrong person.
<lifeless> thumper isoffline
<jml> lifeless, well, I think Launchpad should auto-update diffs too
<lifeless> ok cool
<lifeless> speaking of which
<lifeless> how does one do the superceded dance?
<lifeless> I get an error about an existing proposal
<lifeless> EOD (started at 6:30 :P)
<lifeless> igc: updated thingy submitted
<lifeless> poolie: I'll get to your patch early tomorrow
<igc> lifeless: thanks
 * spiv makes a late lunch
<lifeless> igc: I think (I still have to do a careful audit) that I now have complete coverage of things that make deltas go wrong
<lifeless> igc: which means that once I've done that audit I can get onto iter_changes again and be protected
<igc> lifeless: and in theory, my patch will fail, right?
<igc> i.e. be trapped by your new tests
<lifeless> igc: your tests won't, but I can construct cases using the regular command line that will make it generate bad deltas
<lifeless> and those would be caught
<lifeless> anyway, as I promised I'm going to fix iter_changes itself
<lifeless> theres no need to layer on it when iter_changes is, itself, broken
<lifeless> for instance, a simple example is
<igc> lifeless: thanks. I still never got why my stuff was wrong so I'm looking forward to understanding that soon
<lifeless> init; mkdir a, touch a/b
<lifeless> commit
<lifeless> mv a c
<lifeless> mkdir a touch a/b
<lifeless> commit a/b
<lifeless> this sort of situation would turn up after merging parallel imports, for instance.
<lifeless> igc: the layering approach isn't /wrong/ in a correctness sense; its wrong in a performance sense because of the full-iteration being done under the hood. Thats tolerable.
<lifeless> the correctness wrongness is that you have to spider out upwards just like we do downwards
<lifeless> in what we include
<lifeless> and that may have further implications (e.g. a spider down impact) that I haven't yet thought all the way through
<lifeless> it was while I was thinking it through that I realised our delta sanity checks were totally insufficient to protect us against mistakes
<lifeless> anyhow, I'm really done for today.
<lifeless> see you all tomorrow
<igc> lifeless: sure, seeya tomorrow
<GungaDin> spiv: http://pastebin.com/d5fb72ec7
<spiv> GungaDin: hmm, so it's stuck while waiting to receive a response to a get_stream request (i.e. the big request that fetches all the data)
<GungaDin> but why????
<spiv> Yeah, that's the question.
<poolie> lifeless: let's talk more when it's a bit closer to the top of my stack
<spiv> I mean, I can fetch branches from Launchpad via bzr+ssh just fine.
<GungaDin> I tend to think it could be a problem with one of the VM drivers.
<GungaDin> I can fetch it fine from other machines as well.
<spiv> So if the response isn't making it through to you I'd guess at network weirdness, like a bad MTU setting or something.
<spiv> I would have expected that to show up slightly differently, but perhaps not.
<spiv> There's certainly nothing particularly special about get_stream, except that it tends to send lots of data fairly quickly...
<GungaDin> well, svn works fine...
<vila> hi all
<poolie> hello vila
<vila> hey poolie, I will on and off a bit today, it's national holiday here
<poolie> oh right
<poolie> bastille day?
<vila> yes :) That one, heads on spikes and so on
<Kamping_Kaiser> ah, happy days :p
 * jml has eats some cake to celebrate it
<loxs_> Folks, is there some easy way allow multiple (system) users to commit to the same repository?
<spiv> loxs_: create a system group, and chown the repo to that group and set the perms to be group writeable.
<spiv> oh, and set the perms to make sure that new directories/files in that repo are also group writeable.
<loxs_> spiv, seems like I'll go with access control lists
<fullermd> If those'll propogate correctly to new files, it would probably work.
<fullermd> bzr will do the work of propogating g+w to new files/dirs; with ACL's, the system itself would have to do so.
<fullermd> (and yes, 'propagate' is one of those words I ALWAYS misspell, even though I KNOW I misspell it...)
<poolie> just reviewing aaron's merge -i patch, that's very nice
<jml> fullermd, you can support a door, or you can prop a gate!
<jml> (maybe that's terrible enough that you'll remember it forever)
<poolie> eww
<jml> I remember a sign or banner or something in my grade 1 classroom that said "Smell _a rat_ when you _separate_"
<jml> never ever had a problem with smelling that word! :P
<poolie> my favourites are "weird is weird" ie doesn't follow the weak "i before e" rule
<poolie> and "its is like his" ie doesn't have an apostrophe
<poolie> neither of them are particularly amusing though
<igc> vila: happy "heads on stakes" day :-)
<vila> Yeah, stakes, spikes, whatever, they were rather unsophisticated you know :-)
<vila> It's raining like in November though so for fireworks.... :-D
<jml> "Bastille Day was the day that France declared independence. It was a remarkable achievement, coming only ten days after America invented freedom."
<RAOF> jml: Heh.  Link?
<jml> RAOF, sadly that's all I've managed to make up so far.
<RAOF> Boo!
<lifeless> fullermd: lp:libcpuinfo has language bindings now
<lifeless> fullermd: you might like to let us know if it builds still on BSD :P
<fullermd> lifeless: In a quick test, autoreconf gets all uppity about AC_PROG_SWIG and AC_PYTHON_DEVEL and bails.  Don't have time to look more closely right now.
<pfctdayelise> hi... is there a way to do a 'bzr branch' to an existing directory?
<mwhudson> --use-existing-dir
<pfctdayelise> bzr: ERROR: no such option: --use-existing-dir
<fullermd> Don't think that'll be released 'till 1.17.
<fullermd> (I think it's in 1.17, but I'm not actually sure)
<pfctdayelise> hm, push has such an option
<fullermd> Yeah, push has had it for ages.  branch just hasn't until very recently (like, last week recently, I think)
<pfctdayelise> hm
<pfctdayelise> i think i have version 1.5. 1.17 is the latest?
<lifeless> fullermd: it needs autoconf-archive
<fullermd> Not yet, no.  1.17 won't actually be released until late this week or early next, I believe is the plan.
<lifeless> fullermd: and swig - both are doc'd in INSTALL.txt
<fullermd> 1.16.1 is the current release.
<fullermd> lifeless: Hm.  I thought I had swig installed...   maybe I didn't put it on this machine.
<lifeless> its the autoconf-archive i bet though
<pfctdayelise> gah. so I pretty much have no choice but to upgrade?
<pfctdayelise> or if i move my existing dir, let bzr create it, and then move the other things back, might that work?
<fullermd> Well, you always have choices   :)
<fullermd> Well...   what's the use-case for having a dir with stuff already in it, and THEN branching?  --use-existing-dir is more aimed at existing _empty_ dirs, I tend to think...
<spiv> pfctdayelise: what fullermd said... this sounds like a weird thing to want.
<pfctdayelise> well I don't even know if I really want to branch, is the case any different with checkout? I just want to get a copy of the code, not necessarily develop on it
<lifeless> you could just bzr branch <src> newdir
<lifeless> mv newdir/.bzr ./
<lifeless> bzr revert
<lifeless> rm -rf newdir
<fullermd> Leaving aside the existing dir/files bit, it's probably something like 6 of one, half a dozen of the other, whether you branch or co there, at least in isolation.
<spiv> Either way, why do you want to get a copy of the code into an existing, non-empty directory?  Generally you'd do "bzr co URL somedir". (or "bzr branch ...")
<pfctdayelise> I am working on a web app, and i didn't put the framework into my bzr source control
<pfctdayelise> so i work on it on my home machine, pushed to lp, now trying to get a copy on my web host server
<pfctdayelise> is it such a weird set up?
<pfctdayelise> lifeless: i might try that :) ta
<spiv> What makes it weird I guess is that it mixes unversioned and versioned data.
<fullermd> If all the framework files are in their own dir, it's probably easier to "bzr branch lp:foo newdir ; cd newdir ; mv ../framework/dir ./framework" or the like.
<pfctdayelise> hm, well the "unversioned" data is probably controlled by its own svn co
<lifeless> pfctdayelise: for publishing it I recommend 'bzr upload'
<lifeless> pfctdayelise: its designed for deploying web sites
<spiv> The use case you just described doesn't sound weird, the part where it's apparently necessary for you to mix the bzr working tree with an existing tree of files still sounds weird to me :)
<fullermd> (lifeless's solution would probable be simpler if there were a ton of files scattered all over the place.  But if there are existing dirs shared, be prepared for that to cause conflicts in the revert too)
<pfctdayelise> lifeless: bzr: ERROR: No help could be found for 'upload'.
<lifeless> pfctdayelise: its a plugin - bzr-upload
<spiv> pfctdayelise: https://launchpad.net/bzr-upload
<lifeless> ciao
<spiv> lifeless: g'night
<pfctdayelise> hm... looks interesting
<pfctdayelise> so I install this on my 'dumb server'?
<svqyqb> http://tinyurl.com/nkypfa
<spiv> pfctdayelise: no, on the client, I believe.
<pfctdayelise> spiv: as in, my web host? because surely I can't install it at LP. I can install it at my web host or my personal (dev) machine.
<fullermd> pfctdayelise: The idea with upload is that you install it on your personal machine, and it takes care up uploading the files to the web host.
<pfctdayelise> ah ok
<spiv> pfctdayelise: the README might help: http://bazaar.launchpad.net/~bzr-upload-devs/bzr-upload/trunk/annotate/head%3A/README
<fullermd> (just the working files, not VCS data like you'd copy up with 'push')
<pfctdayelise> right
<pfctdayelise> wow, this is perfect. thanks everyone
<pfctdayelise> and i just went to the hassle of installing bzr on my web host. oh well, I am sure I'll use it another time :)
<spiv> :)
<GungaDin> The bzr problem I had earlier also happens in an Ubuntu guest os.
<Keybuk> so, how do I use "bzr join" ?
<Keybuk> every invocation I try produces errors
<LarstiQ> Keybuk: bzr branch foo somebranch/subdir; bzr join somebranch/subdir ?
<Keybuk> LarstiQ: "Cannot join somebranch/subdir.  Trees have the same root"
<LarstiQ> Keybuk: aha.
<LarstiQ> Keybuk: those branches were created before a rich-root format then. I don't know what the correct way to make their tree roots unique is.
 * LarstiQ knows how to do it with bzrlib, but that might be breaky
<Keybuk> can I not just use "merge" ?
<Keybuk> no, apparently not due to file conflicts :-/
<LarstiQ> Keybuk: pfoe, you could try that, if you `bzr init --something-rich-root ../newroot; bzr merge -r 0..-1 ../newroot`
<LarstiQ> Keybuk: oh merge the two branches?
<LarstiQ> Keybuk: yeah, you can do that, if you say in the the subdir branch move everything to be under subdir/ first
<LarstiQ> provided they have a common ancestor
<LarstiQ> which is sort of disjoint with the usecase for `bzr join`
<Keybuk> I can just merge -r 0..-1 if they don't, right?
<LarstiQ> Keybuk: yes
<Keybuk> cool
<Keybuk> I think have a branch that works ;)
<LarstiQ> good :)
<LarstiQ> Keybuk: I hear jml say that you've done some wicked things to test upstart, is there a writeup available about that, or should I look at the source?
<Keybuk> I've done the odd talk about it
<Keybuk> basically it's a set of C pre-processor macros that expand to common test constructs
<Keybuk> and let me do things like "run a block of code, count the malloc() invocations, then loop over it that many more times failing each malloc() in turn"
<Keybuk> as well as all the usual things like "TEST_EQ" and stuff
<LarstiQ> maybe I'm just not good enough in C macros to see how to do some of that :)
<spiv> LarstiQ: e.g. http://bazaar.launchpad.net/~scott/libnih/trunk/annotate/head%3A/nih/test_alloc.h
<Elleo> Hi; is there anyway to completely remove a file from a bzr pack? We had a rather large file in our repository that has since been deleted; but we'd like to remove it completely
<Elleo> otherwise our repository is about 50mb instead of 5 and makes branching a somewhat slow and bandwidth heavy operation
<vila> Elleo: You can't. But even if you could, that would mean fixing all existing branches (that's what distribution is about, everybody has its own copy of the history)
<vila> Elleo: May you want to look at stacked branches ?
<Elleo> well we pretty much one have the one main branch at the moment (just shifted over from svn)
<Elleo> s/one/just/
<vila> Elleo: yet you want to keep the history ?
<Elleo> yeah
<vila> Elleo: the history includes that large file....
<Elleo> yes and unfortunately it was commited right near the beginning of the project; sot here's a lot of commits after it
<Elleo> oh well, we can work around it; it's just annoying
<vila> Elleo: You may try looking at fast-import to re-create an history starting after the file has been deleted... I think recent versions allows that kind of thing (or it's planned, I don't know exactly, I' don't use it myself)
<vila> Elleo: Another way is stacked branches and/or shared repositories so that you don't pay for the bandwidth each time
<Elleo> right, I'll take a look; thanks
<jam> ping jml, abentley
<jam> morning vila
<vila> hey jam !
<abentley> jam: pong
<jam> abentley: I just noticed that +activereviews doesn't seem to include Approved merge proposals anymore
<jam> Where am I supposed to go to see what is ready for me to land?
<jam> to be explicit, this page: https://code.edge.launchpad.net/bzr/+activereviews
<jam> is no longer showing this merge request
<jam> https://code.edge.launchpad.net/~jameinel/bzr/1.18-switch-branch/+merge/8469
<jam> And I'm not sure what other proposals I have Approved
<jam> so that I can make sure to land them all
<abentley> jam: I'm not sure it ever did.  Marking them approved gets them out of the review queue.
<jam> abentley: I'm sure I used to use it for that
<jam> but regardless, it is something I need
<jam> is it just not available?
<abentley> jam: are you sure you don't mean the requested reviews?
<jam> (it may just have been people marking the review as approved, but not the merge)
<abentley> jam: https://edge.launchpad.net/~bzr-core/+requestedreviews for example
<jam> abentley: well, I've never gone to +requestedreviews before :)
<jam> anyway, it is possible that I used to see things that were "review approve" and *not* "merge approve"
<jam> but regardless
<jam> how can I find a list of things that have been submitted for review
<jam> and have been approved
<jam> so that I can go land them
<jam> I see this: https://code.edge.launchpad.net/~jameinel/+approvedmerges
<jam> for just me
<jam> is there something for all bzr requests?
<jam> I guess this: https://code.edge.launchpad.net/bzr/+approvedmerges
<jam> though it seems to fit with the "these are reviews that need to be done, and these are reviews that are approved and need to land"
<jam> I'm not sure why it has to be 2 pages
<abentley> jam: I don't think there's anything that directly provides what you're asking for.  I've asked for similar things, too.
<abentley> jam: I think "merges I need to work on" and "merges I should land" should also be included on that page.
<jam> sure
<jam> is there a bug for it?
<abentley> jam: dunno.
<jam> k
<jam> I'll look into it
<JNRowe> Hi guys, is there any way to figure out why my clone times are so slow.  I've tried wget'ing a dirstate file to test the network speed and I'm getting ~30k/s, but for a bzr get I appear to be averaging ~6k/s
<jam> sidnei: ping (are you using kerguelen ?)
<sidnei> jam: not ATM
<jam> sidnei: k, I went to log in, and there are already 2 connections
<jam> ATM they both seem to be Administrator
<jam> and one had the buildbot stuff in a terminal and vim
<jam> sidnei: do you always log off when you are done?
<sidnei> jam: last i logged in was more than a week ago
<jam> k
<sidnei> jam: yes, unless the connection died at the time, i can't remember
<jam> sidnei: so at some point, I'll need you to walk me through how to actually build things with the new layout :)
<jam> for now, I'll do 1.17rc1 with the old way
<sidnei> jam: ok. i saw ian's comment about adding some documentation
<jam> sidnei: I'm a bit surprised he landed it without stuff like fixing the PYTHON26 issue...
<sidnei> jam: but basically 'make installer-all' from the top-level
<sidnei> jam: is it landed already? too bad then :( i will make a follow up branch with docs and fixing that
<jam> sidnei: it is in bzr.dev
<jam> It isn't in 1.17 AFAICT
<jam> sidnei: I also wonder if we should build a newer svn, I think there is a 1.6 out somewhere
<jam> looking forward to a patch :)
<sidnei> jam: running 'make installer-all' from bzr.dev would work fine, it will checkout the version specified and build that, it doesn't build the current directory. in fact, i was thinking if all of this should be moved out of the tree and be managed separatedly.
<jam> sidnei: potentially, but we still have to update lots of versions since you targeted 1.15 with your original buildout.cfg
<sidnei> jam: thats how we do it for the Plone installers, since you usually have to make changes to the scripts that generate an installer after the final release is made.
<jam> sidnei: sure. A goal of mine would be to have the change made in the rc1 release, and then *not* have to change it again for the final :)
<sidnei> jam: thats a nice goal yeah. so if you build the installer the normal way, just let me know the versions you used (or I could look at the versions in kerguelen myself) and i will update to use those
<jam> sidnei: I'll try to submit the change to build_release.py back to bzr.dev as well
<sidnei> jam: awesome!
<jam> sidnei: right now I'm working with: http://paste.ubuntu.com/217999/
<jam> I'll update you if that has any problems
<sidnei> jam: thank you
<jam> I don't know that bzr-svn 0.6.3-win32-1 is officially in bzr-svn source, I had to do it manually as a workaround for a bug
<jam> it was the follow up bug to bug #384813
<ubottu> Launchpad bug 384813 in bzr-svn "bzr-1.15-1 Windows standalone claims " Unable to look up default port for ssh" for sftp connections" [High,Fix released] https://launchpad.net/bugs/384813
<jam> jelmer had fixed it in a way that broke in a different way
<jam> sidnei: the installer is failing right now anyway
<jam> We moved a script
<jam> and then tried to make it work by updating an env variable
<jam> but that variable is different on windows...
<jam> PYTHONPATH=.:$PYTHONPATH
<jam> versus
<jam> PYTHONPATH=.;$PYTHONPATH
<jam> (semicolon versus colon)
<jam> anyway, I'll need to do something to get it working
<jam> I'll let you know
<sidnei> jam: ok
<jam> sidnei: lp:~jameinel/bzr/1.17-build-updates
<jam> wasn't terribly tricky (yet) :)
<kenichi> hi, can one "switch" a branch?  it would seem, no...
<kenichi> as i understand it, one just needs to create a new branch from the new desired parent.  is that correct?
<Tak> you mean "switch" in the git sense, or in the svn sense?
<kenichi> bzr has a switch command too, but it's only for COs.
<kenichi> i suppose i mean in that sense, which is analogous to the svn sense.
<Tak> yeah - it doesn't really make sense to switch unbound branches, because you can push to or pull/merge from anywhere you want
<kenichi> that's what i thought, thanks for the confirmation though :)
<SamB> okay, what does bundle buggy key off of to notice merge directives?
<vila> SamB: Use lp merge proposals instead :D
<RenatoSilva> bug 399398, bug 399392
<ubottu> Launchpad bug 399398 in launchpad "Diff highlighting in mail body" [Undecided,New] https://launchpad.net/bugs/399398
<ubottu> Launchpad bug 399392 in bzr-email "HTML Support" [Undecided,New] https://launchpad.net/bugs/399392
<SamB> vila: what's the command for that? ;-)
<vila> SamB: bzr lp-open
<vila> SamB: and then clicety-click
 * SamB supposes this will involve creating a silly branch
<vila> SamB: If it's worth merging, it's not silly
<SamB> well, it just seems kind of silly since I probably won't use it ever again ...
<mgedmin> can I view two closely-related branches at once with bzr vis?
<mgedmin> apparently I can, awesome!
<vila> SamB: no problem, it will be stacked by default so very small
<mgedmin> uh, oh, no I can't, internal error blah blah blah: KeyError: 'svn-v4:866e43f7-fbfc-0310-8f2a-ec88d1da2979:trunk/Pyflakes:17692'
<vila> SamB: But, yes, you may want to use a unique name (we tend to prefix with the bug number a lot :)
<mgedmin> bummer
<vila> mgedmin: sounds like a ghost problem, file a bug, in the mean time, try with qlog too
<SamB> vila: there is no bug number
<SamB> it's just a rewrite of a 2 line comment
<vila> SamB: file one first ;-D
 * SamB decides to just use the date
 * mgedmin reports https://bugs.launchpad.net/ubuntu/+source/bzr-gtk/+bug/399405
<ubottu> Error: This bug is private
<vila> mgedmin: do you really need to make it private ?
<vila> mgedmin: you are seriously limiting the number of people who can fix it....
<SamB> vila: why did lp-open put me on edge?
<mgedmin> it wasn't me, honest! it was apport! I didn't know :)
<vila> mgedmin: :)
 * mgedmin made it public as soon as ubbotu told him about the privateness thing
<vila> SamB: because you can :)
<SamB> because I can *what*?
<vila> go on edge, can't you ?
<SamB> can some people not?
<vila> only lp-beta-testers can !
<SamB> ... how did I get to be one of those ?
<vila> SamB: ok, you lost me here, why did you ask in the first place ? :-D
<vila> AIUI, if you're not a beta tester, edge.lp.net should redirect you to lp.net, so you shouldn't even know edge exist
<SamB> well, maybe I am
<SamB> but I don't know how I became one!
<mgedmin> ok, thanks for the moral support, and bye!
<vila> SamB: what is you lp ID ?
<SamB> naesten
<vila> Right, so you're not part https://edge.launchpad.net/~launchpad-beta-testers
<vila> but if you click on the link above, where do you end up ?
<SamB> https://edge.launchpad.net/~launchpad-beta-testers
<SamB> and it says "This site is running pre-release code. Please report all bugs."
<vila> Meh
 * SamB suspects that vila may have gotten confused about which way the redirection goes
<vila> Oh ! Yes, in the little grey bar, gee, I'm so used to it I don't see it anymore
<vila> Anyway, may be things have changed...
<SamB> where do you end up if you go to https://launchpad.net/~launchpad-beta-testers ?
<vila> But I recently discussed lp-open and the edge/lp.net thing with jml (the lp-open author) so you may want to check with him
<vila> https://edge.launchpad.net/~launchpad-beta-testers
<SamB> ah, see, you get ridirected vanilla->edge
<vila> and that's expected
<SamB> I don't get redirected at all
<vila> That's not expected :)
<SamB> why not?
<SamB> it doesn't say anything about the other direction on that page!
<vila> And if you delete the edge in the url ?
<SamB> jml: so ... why doesn't lp-open send you to vanilla?
<SamB> vila: I still don't get redirected
<SamB> I land on vanilla
<SamB> no dark grey bar, no request to report all bugs
<vila> jml told me that the redirection was fixed to avoid very bad errors for people pointed to edge... May be that was fixed and the redirection cancelled, in that case jml may have to revisit his heuristic...
<lifeless> moin
<kfogel> huh, why does bzr merge say "Contents conflict..." for some files and "Text conflict..." for others?
<mwhudson> they're different kinds of conflict
<mwhudson> though i admit, i never remember what a content conflict is
<mwhudson> kfogel: 'bzr help conflicts'
<mwhudson> content conflict == conflict in a file bzr doesn't think is text
<kfogel> mwhudson: thanks
<jml> poolie, we still good for squash tomorrow?
<poolie> jml, hi, yes we are, at 5
<jml> cool, thanks.
<garyvdm> Hi all
<poolie> hello gary
 * poolie reads the build-updates patch
<poolie> jml, did you see https://code.edge.launchpad.net/~jameinel/bzr/1.17-build-updates/+merge/8753
<poolie> it wants to merge to 1.17
<jml> poolie, no, I didn't.
<poolie> just making you aware; you don't have to read it
<jml> poolie, ok. thanks.
#bzr 2009-07-15
<lifeless> poolie: review done
<lifeless> poolie: I haven't made a vote as such, I'll leave it up to you. I would consider it needs-fixing if I were to vote
<poolie> k
<poolie> is this the same one ian reviewed?
<lifeless> yes
<lifeless> I didn't comment on the stuff he caught
<poolie> k
<poolie> i'm going to try to close mail soon and do that
<lifeless> I'm going to look at this mv a b; mv b a; fail bug
<lifeless> as I have dirstate paged in currently
<lifeless> then onto commit via deltas
<kenichi> i need help understanding the difference between rebase and merge --remember.  the situation is 3 unbound branches, A, B, C.  C was branched from A, A got merged to B, and C wants to get all of B's changes from now on.
<LeoNerd> It's about tree topology
<LeoNerd> merge joins two branches of a tree back together
<LeoNerd> rebase pretends there wasn't a branch at all
<kenichi> IIUC, rebase would make C look like it branched from B *today* and replay all of C's changes after that.
<LeoNerd> Yup
<kenichi> and merge --remember would apply the changes and set parent_location for future use.
<LeoNerd> merge:   -----<======\----
<LeoNerd> rebase: -------\_________
<LeoNerd> (by terrible ASCII-art)
<lifeless> poolie: when thinking about testing
<kenichi> s/terrible/awesome/
<lifeless> poolie: do remember that running the whole stack is very expensive
<lifeless> poolie: I hope that many easy bugs are best tested via tweaks to existing tests rather than new tests
<kenichi> LeoNerd: thanks
<MT-> any ideas what this error means? bzr: ERROR: bzrlib.errors.NotLefthandHistory: Supplied history does not follow left-hand parents
<poolie> lifeless: running the whole stack in the sense of run_bzr?
<lifeless> yes
<lifeless> we say somewhere in our testing notes
<poolie> mt-: um, it depends on the context
<poolie> yes i do remember that
<lifeless> that best practice for blackbox tests is to use the low level API for setting up the scenario
<lifeless> and only use the full stack when we're testing it
<MT-> poolie: http://paste.ubuntu.com/218399/
<MT-> poolie: somebody else is doing that. It works fine when I do it :S
<poolie> lifeless: yes, that's pretty much what i said in my mail
<igc> morning all
<poolie> i'm not ignorant of that
<lifeless> poolie: ok cool
<poolie> i'm just questioning whether it is worth trading some of that off against having:
<poolie> better illustrations of what happens
<igc> hi poolie, lifeless
<poolie> and easier approachability for people writing tests
<poolie> casually
<poolie> whether the second would actually happen enough to be worthwhile is uncertain
<poolie> hello igc
<lifeless> I am skeptical. We have lots of contributors that have wafted up and cloned tests very successfully
<poolie> MT-: that would seem to be a bug, perhaps provoked by something in the source branch
<lifeless> hi igc
<poolie> MT-: the first thing i would try is going to a more recent bzr
<MT-> poolie: I'll try that, thanks
<lifeless> poolie: https://bugs.edge.launchpad.net/bzr/+bug/395556 - you say in there you'll merge some tests. Have you?
<ubottu> Ubuntu bug 395556 in bzr "bzr mv (rename in place) causes commit to fail depending on specific filenames" [High,Confirmed]
<poolie> so, we also have lots of contributors who balk at writing a test
<poolie> possibly they would do that even if testing was zero effort at all
<lifeless> we can test this cheaply
<lifeless> by writing the tests ourselves, but *not* fixing up fallout
<lifeless> by cheaply I mean, without inventing infrastructure that might not be used.
<poolie> that's a factor too
<lifeless> if the contributors don't follow up and fix the regressions we find, then its pretty certain they wouldn't test that will regardless
<poolie> will?
<lifeless> e
<poolie> anyhow, yes
<poolie> it may be that in fact they've put up a patch that doesn't actually work
<poolie> i'm just trying to think of some answer to "testing is too hard" beyond "suck it up"
<poolie> :?
<poolie> also, in reviewing aaron's patch, i do think it's suboptimal that there is no clear demonstration of how it actually works
<lifeless> I agree with that
<poolie> like the idea that lp should put screenshots of the proposed fix on bugs
<poolie> heh, the analogy is interesting
<poolie> because testing by comparing to screenshots is pretty sucky
<lifeless> we do have the ability, in run_bzr, to provide inputs to commands
<poolie> as a stdin stringio?
<lifeless> poolie: the tests for bug 395556, did they land? and where can I find them -  are they XFAIL's?
<ubottu> Launchpad bug 395556 in bzr "bzr mv (rename in place) causes commit to fail depending on specific filenames" [High,Confirmed] https://launchpad.net/bugs/395556
<poolie> i'll check, was talking to someone :-P
<lifeless> poolie: yes, though I think we provide glue to make it easier to use than that
<poolie> i think i submitted them
<poolie> yes, there are knownfailure tests in trunk
<poolie> grep for that bug number
<lifeless> thanks
<kenichi> LeoNerd: i went with merge --remember, but the parent_location of the branch did not change upon commit... what am i misunderstanding?
<poolie> one way to look at it is i'm suggesting more or higher-quality glue
<poolie> input as blah(... stdin="y\n\n\n\r\n") is not so easy to review
<poolie> improving that can be done stepwise
<poolie> without going away from the other things that are good in our test suite
<poolie> and i think not at a terribly high cost
<poolie> spiv, re https://code.edge.launchpad.net/~mbp/bzr/391411-reconfigure-stacked/+merge/8527
<poolie> would making RemoteRepository be a Repostiory subclass be very traumatic?
 * jml -> chatswood for breakfast.
<spiv> poolie: not sure.  Well, I'm sure there was a reason why it wasn't done like that initially.
<spiv> Perhaps a good starting point would be to create a new common base class for RemoteRepository and Repository, and gradually move things into that?
<spiv> Perhaps we'll be able to collapse that base class and Repository fairly rapidly.
<poolie> heh, that's what i was doing
<poolie> lifeless didn't like it :)
<spiv> Heh.
<poolie> but maybe with a comment it would get by
<spiv> It is a little odd to me that we have Branch and BzrBranch, but no similar split for Repository.
<GungaDin> Has anyone here used bzr from a virtual machine?
<lifeless> so
<lifeless> I don't recall any good reason for them being different
<lifeless> I think it is worth doing a test run with RR as a subclass of Repository
<lifeless> it will answer the question much faster than speculation
<lifeless> its true that there is potential for confusion, having a proxy object subclass the thing it proxies
<lifeless> but that shouldn't be worse than with Branch
<lifeless> spiv: we do have a split in the repository classes
<lifeless> spiv: Repository is the abstract interface - we have wildly different subclasses
<lifeless> GungaDin: yes, people have used bzr from vms
<lifeless> GungaDin: some of the core developers do so regularly.
<GungaDin> and they're able to checkout stuff without problems?
<GungaDin> with bzr+ssh?
<lifeless> yes and yes
<lifeless> I really encourage you to file a bug so that *all* the developers can help you, rather than just the ones that see what you type here.
<GungaDin> I also installed Ubuntu in VirtualBox... and the problem persists.
<GungaDin> btw.. I was able to checkout with https... but not with bzr+ssh.
<GungaDin> well, I can't be sure it's a bug.
<GungaDin> at least not necessarily in Bazaar.
<lifeless> thats fine
<lifeless> bug trackers are a place to discuss problbems
<lifeless> there is no requirement that everything in them be known to be a bug prior to putting the thing in the bug tracker
<lifeless> if there was such a requirement, very few bugs would ever be put in bugtrackers
<GungaDin> ok
<GungaDin> I don't think it's bzr...
<GungaDin> now for the first time it's gone past this stage...
<GungaDin> and it'sa ctually building the tree...
<lifeless> its happening to bzr
<GungaDin> what the hell is going on...
<GungaDin> ?!
<lifeless> even if its not bzr we'd like to know whats going on
<MT-> I have a section of a bug tracker that's almost entirely used for discussions and notes..
<lifeless> so that we can advise other people if they have these symptoms
<GungaDin> lifelfess - I'd like to file as much as i can... but it's happening at my work... so I'm a bit limited getting all the info.
<lifeless> or perhaps we can come up with a change to bzr to reduce this happening
<lifeless> GungaDin: I can appreciate that
<GungaDin> what would you have me do, then?
<lifeless> file a bug :)
<lifeless> tell us what you can
<lifeless> this will let folk that are not here right now chime in
<lifeless> it sounds like it just worked for you though?
<GungaDin> ok, I filed a bug report.
<GungaDin> yes, now it just worked....
<lifeless> well thats some good news:)
<poolie> see? isn't filing bugs good? :)
<GungaDin> anyway, thanks for your help.
<garyvdm> Hi igc - I'm finished everything I wanted to on the TreeWidget. Any thoughts on what to tackle next?
<lifeless> igc: I've pushed all my inventory delta prophylactic code btw
<igc> hi garyvdm!
<garyvdm> Hi Ian
<igc> garyvdm: the next thing I was hoping you'd work on was ...
<igc> a better revision widget
<igc> or was it a better branch widget? I forget
<igc> anyhow, one or both of them given ...
<garyvdm> branch widget?
<igc> numerous q* commands use those
<igc> garyvdm: I'd need to look over my notes but ...
<igc> I think the main issue was being able to select a merge directive, not just a directory
<garyvdm> Ok - Let me look at the revision selector.
<igc> garyvdm: thanks. I suspect it was far more important than the branch one
<igc> garyvdm: there were also some small qbzr issues that someone (perhaps you?) could fix soon:
<igc> 1. the compatibility with bzr-pipeline issue
<igc> 2. qinfo working on a shared repo
<igc> 3. qrevert dropping pending merges
<garyvdm> igc: if you have a chance - please try out lp:~garyvdm/qbzr/newwtlist
<igc> garyvdm: I'll take a look at those next week say if no-one gets to them
<igc> garyvdm: I need to focus on some 2.0 stuff this week but I promise I'll take a (another) look this weekend say
<garyvdm> igc: Np - I understand.
<igc> (my nights are pretty full this week with family stuff)
<garyvdm> igc: For no. 3 - I posted a mockup to the bug. How does that look?
<igc> garyvdm: that looks good
<garyvdm> Cool - I get that done.
<garyvdm> First - a itch scratch - Spell checker suggestions in qcommit :-)
<igc> garyvdm: also, did you see the comments from lifeless re register_lazy_decorated?
<igc> garyvdm: I'm reviewing that now btw
<igc> garyvdm: if you're in agreement with Robert's comments, I'll defer my review till you've done those changes
<garyvdm> Yes - but unfortunately - that won't really help to solve the bzr-pipeline compatibility problem. It's a bit more complex.
<igc> garyvdm: so pipeline and qbzr are both overriding the merge command from what I've been told
<igc> garyvdm: if that's right, why does qbzr need to?
<garyvdm> qbzr adds merge --qpreview
<garyvdm> which shows the preview in qdiff
<jml> poolie, thanks for the prompt & clear metronome response
<poolie> thanks for the metronome
<poolie> also for the "these people are wrong" :-)
<jml> so, I'm thinking of not RMing 1.17+1
<jml> I'd really like to get back into actually writing code.
<igc> garyvdm: so I think we need to rethink qdiff launching actually
<garyvdm> qdiff or qpreview?
<igc> garyvdm: I like qdiff but sometimes I really want to use meld for a period of time, e.g. when doing a complex review
<igc> garyvdm: if I configure meld as a diff tool, then qcommit (say) still launches qdiff but then let's me launch meld from there IIUIC
<igc> garyvdm: I kind of think it should just launch meld directly
<garyvdm> igc - You can make meld the default. Then if you click on diff in any of the qbzr windows, if will open meld
<igc> garyvdm: also, maybe "merge -qpreview" is better as "merge --review --using qdiff" or something like that
<igc> garyvdm: I tried that and it didn't seem to work for me. I'll try again soon
<garyvdm> igc - yes
<garyvdm> igc - it won't (go straight to meld) if you just run bzr qdiff - so we probably need to make things like bzr explorer aware of the qdiff config.
<igc> garyvdm: what about making qdiff smarter and getting it to launch the right default diff tool?
<igc> garyvdm: I can make epxlorer smarter but those smarts need to also go into ...
<igc> TortoiseBzr, qbzr-eclipse, etc.
<igc> garyvdm: seems better to just make qdiff Do The Right Thing IMO
<garyvdm> igc - 1. If you do that, and you make some other tool the default, how do you get into qdiff?
<garyvdm> Maybe add a option to qdiff: bzr qdiff --usingconfigdefault
<garyvdm> 2. - err forgot what 2 was.
<igc> garyvdm: 1. not sure. Adding an option would work fine (either way).
<dash> hm
<dash> I did 'bzr uncommit' and now I regret it. however, the revision id that uncommit gave me has scrolled off my terminal. is there any way to get it back? :)
<garyvdm> dash: install bzrtools plugin
<dash> done
<garyvdm> dash: run bzr heads --dead
 * igc lunch then back onto reviewing apply-inv-delta patch from lifeless
<dash> ach. this is branched from SVN
<dash> and i'm getting an error from the svn server as a result of that command
<dash> (not a checkout, not a lightweight checkout, a branch)
<garyvdm> dash: sorry - not sure then.
<dash> pretty weird =/
<dash> thanks for the pointer anyway
<dash> heh, ran some of the code from the heads plugin mnually
<dash> got it back :)
<dash> hooray for bzr.
<poolie> lifeless: why remove the branches? because they're no longer playing the same role of being canonical and primary?
<lifeless> poolie: several reasons; its faster to pull from lp; lp has a branch viewer; we don't point people at the directory anyway - we have a wiki page listing the urls
<poolie> this seems like a reason to change the wiki not remove them
<lifeless> changing the wiki is implicit
<lifeless> by which I mean the wiki page should point at the primary location
<poolie> is bug 399540 the guy who was talking to you before here?
<ubottu> Launchpad bug 399540 in bzr "bzr works strangely in a virtual machine guest" [Undecided,New] https://launchpad.net/bugs/399540
<poolie> what a weird bug
<lifeless> I think so
<poolie> igc, i've updated the spreadsheet, review it at your convenience
 * poolie crosses off another item
<igc> poolie: thanks
<poolie> lifeless, spiv, igc, i'm out for a bit, online again after 5
<lifeless> poolie: I'll be gone by then; ciao.
<igc> ok
<lifeless> so, 3 bugs fixed.
<lifeless> sent up for review.
<lifeless> ciao y'all
<vila> hi all
 * spiv ducks out to shops
<jelmer> mwhudson: hey
<jelmer> mwhudson: Are the git revisions imported one-by-one by launchpad?
<mwhudson> jelmer: no
<mwhudson> well, what do you mean?
<jelmer> mwhudson: I'm subscribed to the samba branch, and woke up to find 750 new emails waiting for me...
<mwhudson> jelmer: the emails are done one by one and the import was broken for a few weeks
<mwhudson> jelmer: there's nothing special about git imports here
<mwhudson> (we should probably avoid this sort of flood somehow though)
<jelmer> mwhudson: that'd be nice
<jelmer> mwhudson: does this also happen for "native" bzr branches, if somebody pushes multiple revisions to them?
<mwhudson> jelmer: yes
<phurl> hi all
<phurl> i have a launchpad branch i would like to merge to
<jelmer> mwhudson: ah, ok
<jelmer> mwhudson: It's just a temporary thing then I guess, since this branch got "unbroken" because of the new bzr-git
<mwhudson> jelmer: right
<mwhudson> jelmer: it makes rebasing a bit interesting!
<phurl> what is the syntax of that? do i got to my existing branch and say bzr merge ******
<jelmer> phurl: bzr merge lp:~username/projectname/branchname
<phurl> thanks
<jelmer> mwhudson: did something just land that makes sure the cache is kept?
<jelmer> mwhudson: I was a bit surprised to see the samba branch working now
<mwhudson> jelmer: yes
<jelmer> mwhudson: \o/
<johnskulski> can anyone point me to documentation about keeping one bzr branch in another?
<johnskulski> say I have project1/ and module1/  and I want to keep a copy of module1 within project1
<johnskulski> is this a vendor branch
<jml> johnskulski, the feature is known as 'nested trees', and it's not implemented in Bazaar (yet)
<johnskulski> jml:: i see. is there a workflow without using 3rd party tools?
<LarstiQ> johnskulski: with bzr-scmproj
<johnskulski> have you all used either that or config-manager? are they solid?
<jml> johnskulski, it depends on what you mean by 'third party tools' and what you're exact use case is. You can do a pretty good job with symlinks & a couple of simple shell scripts
<LarstiQ> johnskulski: I've used scmproj, but most people get by without anything of the sorts
<johnskulski> hm ok
<asabil> oui ?
<asabil> sorry wrong window :)
<jml> johnskulski, I haven't used config-manager directly, but I'm told that the Launchpad development team use it.
<johnskulski> thanks for you advice.
<johnskulski> it would be great to push back changes from individual projects
<johnskulski> jml:: what would the shell scripts do?
<johnskulski> generate and apply patches?
<jml> uhh, they'd reimplement config-manager :)
<johnskulski> hehe
<jml> or as much of it as you actually need for what you want to do.
<johnskulski> jml:: i'm confused on what commands would accmplish what I'm trying to do
<johnskulski> (new to bzr)
<jml> johnskulski, what are you trying to do?
<johnskulski> project/ is a bzr repository, module1/ is a bzr repo, i would like to have project/module1/ be a branch of module1 such that i can add it to the project repos (so another branch will have that) and push changes back to module1/ (bug fixes, the module is shared among other projects)
<jml> wow... getting acf locally!
<johnskulski> acf?
<jml> johnskulski, not related to our conversation, but related to the channel more generally :)
<jml> (I'm multitasking a little atm)
<johnskulski> ah
<johnskulski> no worries :)
<jml> johnskulski, so, what you'd do is have a script or a make step or something in project/ that run 'bzr branch central-copy:module1'
<jml> johnskulski, that is, there'd be no tightly defined relationship between project/ & module1/ in bzr itself, it would be a part of your build scripts.
<johnskulski> jml:: i am not sure what central-copy: means
<johnskulski> i am not find it in the docs
<jml> there's going to be a canonical location for module1 right?
<jml> on one of your servers or launchpad or whatever
<jml> the thing that's 'trunk' for that module.
<johnskulski> yeah this will all be on a local filesystem
<johnskulski> right
<jml> johnskulski, is it just you working on the project?
<johnskulski> something liek /var/bzr/shared/module1
<johnskulski> jml:: no about 12 of us
<johnskulski> all diferent projects
<johnskulski> usually sperately
<jml> why are you sharing a filesystem?
<johnskulski> central dev
<jml> can't you afford hard drives?
<jml> anyway, that's off topic
<johnskulski> we have a centralized development server
<johnskulski> same machine
<jml> you can't run the project on your local machines?
<igc> night all
<johnskulski> jml:: it doesn't matter :)
<jml> so, as I was saying, you'd have something in your build scripts that says, 'bzr branch file:///var/bzr/shared/module1'
<jml> or a variation on that.
<johnskulski> let me tyr this, thanks!
<jml> I work on Launchpad. We have a bunch of dependencies that we manage in branches. We pull those from a server using a script, and then whenever we create a branch locally, we run another script to symlink those branches into that new branch.
<jml> (because we tend to have one branch per feature/bugfix)
<johnskulski> jml, do you work with applications?
<jml> johnskulski, I don't follow. I work on Launchpad itself. :)
<johnskulski> my set up is: we are a webapp shop and generally we work on 8-10 projects at a time all based off a standard framework, on top of that we have modules that we would like to include in each projects. it would be a great win if say i'm working a project and could push back changes to the framework or module
<johnskulski> maybe another set up is more appropriate
<johnskulski> launchpad itself? the webapp?
<jml> johnskulski, yes.
<fullermd> I tend to just merge in modules that I use in multiple places.  That doesn't work well for the case where you want to work ON the module in the context of a given project, and then push those module changes back upstream though.
<fullermd> But I don't do that very often, so dealing with it manually in those cases works well enough for me.
<johnskulski> jml:: we don't do builds, which may be something we could switch to
<johnskulski> fullermd:: so if you fix something in the module, you generate a patch and apply it to it manually?
<fullermd> johnskulski: In one form or another, yah.
<fullermd> Most of the time I just work on changes directly in the module though (and the ones that make that hard, I have on my list to improve so that it's not)
<LarstiQ> johnskulski: seriously, have a look at scmproj
<fullermd> Yah.  The 'by-reference' style nested tree work will be most like what you want, and scmproj is a variant of that.
<johnskulski> LarstiQ:: yes this looks great
<johnskulski> thanks
<johnskulski> this channel proves helpful everytime, thanks!
<eyda|mon> can someone remind me what plugin is required to get the webserve thing going?
<vila> loggerhead ?
<eyda|mon> yes, thanks
<eyda|mon> how do I use this thing?
<eyda|mon> how do I see what plugin commands are avail?
<luks> bzr plugins
<eyda|mon> luks: that tells me what plugins are available, not what the commands are
<spiv> eyda|mon: bzr commands, although that will list builtin commands.
<luks> oh, sorry, I misread the question
<spiv> But will include the plugins too :)
<eyda|mon> luks:  no worries
<luks> bzr help commands
<spiv> Er, sorry: bzr help commands
<eyda|mon> so there's no specific command to just list the ones for a specific plugin
<luks> bzr help commands | grep PLUGINNAME :)
<eyda|mon> I'm trying to use the loggerhead but there are no instructions on their site
<LarstiQ> bzr help plugins/<plugin> ?
<eyda|mon> grep works :)
<luks> that shows you the help page, not a list of commands
<LarstiQ> luks: sure, but it is probably more helpful
<LarstiQ> luks: seeing as loggerhead doesn't feature in commands, but does mention how it works in the plugin help
<LarstiQ> luks: to be fair, eyda|mon asked the wrong question ;)
<luks> I know nothing about loggerhead, just answering questions :)
<LarstiQ> eyda|mon: found the `bzr serve --http`?
<eyda|mon> LarstiQ: to be fair, eydaimon didn't know what question to ask because the plugin setup isn't obvious
 * LarstiQ nods at eyda|mon 
<eyda|mon> LarstiQ: yes, thanks
<spiv> eyda|mon: also, the README file might help: http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk-rich/annotate/head%3A/README
<LarstiQ> eyda|mon: asking the right question is not easy to do
<eyda|mon> I was after what I thought would be a common interface on how to use plugins
<eyda|mon> or to find out their usage anyway
<spiv> Plugins can do quite a wide variety of things :)
<LarstiQ> eyda|mon: I usually look at the README
<eyda|mon> that's why I think it would be nice if I could just do bzr plugins PLUGIN and it would tell me the avilable commands
<spiv> Some add commands, some extend existing commands, some add hooks, some add new formats, etc...
<LarstiQ> eyda|mon: but I think stressing something useful in the online help system is a good idea
<eyda|mon> and that includes extending, adding, hooks etc :)
<eyda|mon> ok
<eyda|mon> LarstiQ: are you suggesting I file a ticket?
<spiv> eyda|mon: that's "bzr help plugin/<foo>" at the moment.
<LarstiQ> eyda|mon: I didn't yet, but yes please :)
<spiv> Perhaps "bzr plugins" should suggest that, it's not particularly discoverable at the moment.
 * LarstiQ nods at spiv
<fullermd> There is no help plugin/XYZ...
<fullermd> There's plugin_s_/XYZ, but that just gives the 1-liner.
<spiv> fullermd: sorry, typo.  Thanks
<spiv> fullermd: try plugins/svn or plugins/gtk
<LarstiQ> or plugins/loggerhead
<spiv> fullermd: it's not necessarily a one-liner.
<fullermd> Sure, but that's only if the plugin lists it.  bzrtools frex tells you nothing.
<spiv> File a bug on bzrtools :)
<eyda|mon> you guys are missing the help plugins :)
<eyda|mon> seems like something so useful as loggerhead should be included in bzr
<spiv> eyda|mon: yeah, that's been discussed occasionally.  I don't recall the outcome, though.
<fullermd> Well, once you add up all the so-useful-to-$PERSON's, you end up with a real big tarball  ;)
<eyda|mon> fullermd: I'm more important than others so, my useful-to-eydaimon should be considered very carefully
<spiv> I know we would like to make it easy to do something like "bzr serve --http" to run up a quick and simple bzr+http smart server with loggerhead.
<spiv> eyda|mon: :)
<eyda|mon> yeah, like mercurials
<fullermd> eyda|mon: Oh, I didn't realize it was YOU.  Carry on.
<eyda|mon> nothing fancy, but it works
<eyda|mon> fullermd: there we go :)
 * eyda|mon wonders when people will start to grasp his importance
<fullermd> Probably not 'till after they give up on their screwed up sleep schedules and just synchronize with mine.
 * fullermd still vaguely wishes to be able to sufficiently flexibilate URL handling on bzr+http.
<fullermd> (and flexibilate is totally a word.  You can look it up.  In my brain.)
 * eyda|mon makes a new port for SimpleTAL since macports doesn't have one.
<eyda|mon> feels like I'm ALWAYS making new ports
<fullermd> Hey, welcome to MY life...
<hmeland_> I've had a look at one of the 'easy' open bugs, namely #72227 -- but I am unable to reproduce the problem with the current bzr (1.17~rc1+4531+117 from the nightly ppa).
<hmeland_> Does anyone know if the problem still is present?
<fullermd> bug 72227
<ubottu> Launchpad bug 72227 in bzr "should avoid loading modules from working directory" [High,Confirmed] https://launchpad.net/bugs/72227
<fullermd> Seems like I heard it mentioned just last week or so, biting somebody.
<LarstiQ> ehm, that one is not actually easy
<fullermd> Hey, paramiko moved to git...
<LarstiQ> hmeland_: it certainlly still happens. Do you have access to Windows?
<hmeland_> LarstiQ: Yes, I can install Bazaar in my XP virtualbox.  Is the problem only happening on Windows, though?
<LarstiQ> hmeland_: no, it happens everywhere
<LarstiQ> well, maybe not everywhere then
<hmeland_> A transcript of (one of) my attempts at reproducing it can be found here: http://pastebin.ubuntu.com/218919/
<hmeland_> Where am I going wrong?
<LarstiQ> hmeland_: some but not all python installations add '' to the path
 * LarstiQ looks for one of the duplicates
<hmeland_> According to http://docs.python.org/library/sys.html#sys.path , the '' stuff should only happen if "the script directory is not available".
<hmeland_> Are you saying that some Python versions are getting this wrong, or is it stuff that some distributions of Python get wrong (e.g. in their site.py)?
<LarstiQ> hmeland_: https://bugs.edge.launchpad.net/bzr/+bug/304891
<ubottu> Ubuntu bug 304891 in bzr "bzr doesn't work in parent directories of python packages with certain names (dup-of: 72227)" [Undecided,New]
<ubottu> Ubuntu bug 72227 in bzr "should avoid loading modules from working directory" [High,Confirmed]
<LarstiQ> hmeland_: one of those I guess
<eyda|mon> alright, port submitted
<eyda|mon> now to continue on with the installation of loggerhead :)
<LarstiQ> hmeland_: I personally can't get it to reproduce on Lenny either
<LarstiQ> hmeland_: but I've witnessed it in the past
<LarstiQ> eyda|mon: thanks :)
<LarstiQ> hmeland_: you could ask wgrant
<eyda|mon> LarstiQ: it was the port for simpletal. I guess I could make for loggerhead too
<LarstiQ> eyda|mon: is that MacPorts?
<eyda|mon> LarstiQ: yes
<eyda|mon> argh!
<eyda|mon> the loggerhead tarball untarred a bunch of files in the extract dir
 * eyda|mon whines
<eyda|mon> it does have a setup.py though. that will make it easy to install at least the libs
<wgrant> LarstiQ: I'm confused - I know nothing about that bug, so why am I suggested?
<LarstiQ> wgrant: eek, sorry :/
<wgrant> LarstiQ: 'tis no problem. I'm just intrigued as to why me. But I'm half asleep, so I'm also intrigued as to why I'm not in bed yet.
 * wgrant goes to bed.
<LarstiQ> wgrant: because in my memory it was you, and I glossed over the reports name starting with a W but being different
<fullermd> All then W's look alike to me...
<eyda|mon>  bzr serve --http
<eyda|mon> bzr: ERROR: No module named config
<eyda|mon> You may need to install this Python library separate
<eyda|mon> any idea what's missing here?
<eyda|mon> it's not listed in depenency for loggerhead
<LarstiQ> eyda|mon: could you pastebin the backtrace from .bzr.log?
<eyda|mon> ok
<eyda|mon> http://pastie.org/546808
<LarstiQ> woo, that is not supposed to happen
<eyda|mon> heh
<LarstiQ> eyda|mon: is there a 'loggerhead' directory in your cwd?
<eyda|mon> no
<LarstiQ> ah
<LarstiQ> eyda|mon: how did you install loggerhead? It looks you might have one layer of hierarchy too much in ~/.bazaar/plugins/loggerhead/loggerhead/
<LarstiQ> eyda|mon: if ~/.bazaar/plugins/loggerhead/ only contains the loggerhead directory, move that one up
<eyda|mon> ok
<eyda|mon> let me wipe it and start over
<eyda|mon> maybe the port installed another one
<LarstiQ> how I would install it: `bzr branch lp:loggerhead ~/.bazaar/plugins/`
<eyda|mon> yeah, but I'm making a port since I'm at it
 * LarstiQ nods
<LarstiQ> eyda|mon: in that case, the right location is probably bzrlib/plugins/
<eyda|mon> can I find that path out from running some bzr cmd?
<LarstiQ> eyda|mon: `bzr --version` should tell you
<eyda|mon> meh, I'll need to parse that output with tcl
<eyda|mon> who chooses tcl.. gree
<eyda|mon> grr
<eyda|mon> i don't suppose loggerhead itself knows where to install itself
<eyda|mon> oh, there's a gtk port
<eyda|mon> I can see how they did it
<fullermd> There's probably a bzrtools port too, which may be quicker to read.
<eyda|mon> there is
<eyda|mon> doesn't look like it does anything special to install.. maybe it's setup.py takes care of it for it.
<fullermd> Yah, setup.py does all that fiddling...
<eyda|mon> but it doesn't do that for loggerhead
<eyda|mon> same with gtk
<LarstiQ> so where does gtk end up then?
<eyda|mon> bzrlib/plugins
<eyda|mon> I have to go. I guess I will resume this later.
<LarstiQ> eyda|mon: ah, I think it might be the packager_dir/packages pointing to bzrlib.plugins?
<LarstiQ> eyda|mon: k
<jnz_> Hi, when I type `bzr send -o ~/filepath' there's are some errors: http://www.nopaste.com/p/aoIFcyzjab
<vila> jnz_: wow, 'bzr version' , 'bzr info' please
<jnz_> 1.14.1, http://www.nopaste.com/p/ajijogjifb
<vila> jnz_: hmm, sorry,  'bzr info -v'
<jnz_> http://www.nopaste.com/p/afSnRrj2cb
<vila> jnz_: anyway, the warnings are ugly enough, file a bug,
<vila> jnz_: Can you try to upgrade to a more recent version of bzr ?
<vila> jnz_: Also, have a look in .bzr.log, there may be more detailed info there
<jnz_> ok, I'll try. If I still have the problem, I should open a file? where? (sorry I'm new to bzr)
<vila> https://bugs.launchpad.net/bzr/+filebug
<vila> jnz_: np, welcome on board :)
<jnz_> ah right
<jnz_> thanks :)
<_gpg_> hello
<_gpg_> is it possible to have the latest release (and updates) for ubuntu 8.04 ?
<luks> use the ppa?
<vila> _gpg_: https://edge.launchpad.net/~bzr/+archive/ppa and take your pick
<_gpg_> vila, thank you
<_gpg_> vila, i have seen it just before your post :)
<jnz_> ok, I've resolved upgrading to 1.16.1 :>
<cellofellow> I'm trying to push a bzr branch to an svn repository. The bzr branch has about five revisions that need to be pushed. I got this error: bzr: ERROR: Operation denied because it would change the mainline history. Set the append_revisions_only setting to False on branch "http://runningmethod.com/svn/runningmethod/mrc/trunk" to allow the mainline to change.
<cellofellow> Is there a way to push my changes as one svn revision?
<jelmer> cellofellow: yes, set the append_revision_only setting to False
<jelmer> cellofellow: as the error message indicates :-)
<cellofellow> where's that setting?
<jelmer> cellofellow: in locations.conf, subversion.conf or bazaar.conf
<cellofellow> ok, added to bazaar.conf
<fullermd> I didn't know you COULD pivot the mainline history in svn...
<cellofellow> :/
<cellofellow> can I wrap up all my revisions into one somehow?
<Luke-Jr> jelmer: why does bzr-svn never seem to work for anything other than the simplest stuff? :Ã¾
<jelmer> Luke-Jr: what's not working?
<Luke-Jr> pushing a merge
<jelmer> Luke-Jr: what about it is not working?
<Luke-Jr> bzr: ERROR: exceptions.AssertionError: path: path/to/THIS/branch, 197 â¥ 471
<jelmer> Luke-Jr: what version?
<Luke-Jr> bzr: ERROR: exceptions.AssertionError: path: path/to/THIS/branch, 197 >= 471
<Luke-Jr> bzr 1.15.1; bzr-svn 0.6.1
<jelmer> Luke-Jr: please try 0.6.2 or the 0.6 branch, if that doesn't work please file a bug
<Luke-Jr> -.-
<Luke-Jr> tell bzr overlay guy to update? :Ã¾
<jelmer> Luke-Jr: it might just be that the existing data in your repository is broken and that's continuing bzr-svn to break
<Luke-Jr> better not be :Ã¾
<Luke-Jr> this isn't even the same repository that was giving me problems before
<jelmer> does the other repository work now?
<Luke-Jr> using 0.6.2, get a different error
<Luke-Jr> no idea
<Luke-Jr> bzr: ERROR: Tags not supported by SvnBranch('svn+https://svn.openmethodscorp.com/svn/SoftPhone/Harte-Hanks/CTI/Cvlan-Server'); you may be able to use bzr upgrade.
<Luke-Jr> err, ignore the paths in that of course âº
<Luke-Jr> jelmer: so am I just not allowed to tag things? :Ã¾
<jelmer> Luke-Jr: that one isn't a bug
<jelmer> Luke-Jr: your local branch has tags but bzr-svn doesn't know where to store the tags in the svn repositories
<Luke-Jr> neither do I
<Luke-Jr> I don't see a push option to omit tags
<jelmer> Luke-Jr: there isn't one
<Luke-Jr> so how do I get past this?
<Luke-Jr> ideally without losing my local tags
<jelmer> Luke-Jr: remove your local tags
<Luke-Jr> :/
<Luke-Jr> seriously?
<jelmer> Luke-Jr: or modify your configuration to indicate where the tags are in svn
<Luke-Jr> nowhere :Ã¾
<Luke-Jr> can't it just be lossy in that regard?
<jelmer> Luke-Jr: bzr would need infrastructure for that first
<jelmer> Luke-Jr: this is unrelated to bzr-svn
<Luke-Jr> sigh
<Luke-Jr> fine, how do I make it put them in a tags dir?
<jelmer> Luke-Jr: set the tags option in the configuration
<Luke-Jr> what configuration?
<jelmer> Luke-Jr: subversion.conf or locations.conf
<Luke-Jr> <.<
<Luke-Jr> [svn+https://svn.openmethodscorp.com/svn/SoftPhone/Harte-Hanks/CTI/*Server*]
<Luke-Jr> tags = svn/SoftPhone/Harte-Hanks/CTI/Server-tags/*
<Luke-Jr> still does the same thing
<jam> hey jelmer how's it going?
<jelmer> hey jam
<jelmer> jam: pretty good, hanging out in Madrid
<jam> sounds like fun
<jam> I was wondering if you had a chance to look at the small patches to bzr-svn and bzr-rewrite to get them to work properly with bzr 1.17 (especially when bundled for windows)
<jelmer> Luke-Jr: try running "bzr svn-layout" on that URL, that should tell you where it will store the tags
<jelmer> jam: I already applied an alternative fix to the bzr-svn one
<jelmer> not sure about bzr-rewrite
<jam> jelmer: did you make a release?
<Luke-Jr> bzr: ERROR: Not a Subversion branch or repository.
<jam> I didn't see a new release on Launchpad at least
<Luke-Jr> -.-
<jam> mwhudson: I have a partial fix for bug #393366. There are some edge cases it doesn't quite handle, so I was wondering if you could determine how often those edge cases occur
<ubottu> Launchpad bug 393366 in bzr "KeyError in knit.simple_annotate running annotate on a stacked branch" [High,Fix committed] https://launchpad.net/bugs/393366
<jam> (bug #399884)
<ubottu> Launchpad bug 399884 in bzr "get_record_stream(..., 'topological', True) in pre 2.0 formats does not preserve topological sorting across stacking boundaries" [Low,Triaged] https://launchpad.net/bugs/399884
<Luke-Jr> Repository root: svn+https://svn.openmethodscorp.com/svn/SoftPhone
<Luke-Jr> Layout: CustomLayout(['Harte-Hanks/CTI/Cvlan-Server'],[])
<Luke-Jr> Branch path: Harte-Hanks/CTI/Cvlan-Server
<Luke-Jr> Project: Harte-Hanks/CTI/Cvlan-Server
<Luke-Jr> bzr: ERROR: Layout CustomLayout(['Harte-Hanks/CTI/Cvlan-Server'],[]) does not support custom branch paths.
<Luke-Jr> jelmer: â¦
<jelmer> jam: no I haven't made a release yet
<Luke-Jr> jelmer: poek
<jelmer> Luke-Jr: the URL you're specifying should be the URL of the repository
<Luke-Jr> yes, I did that, see above?
<Luke-Jr> [13:32:44] <Luke-Jr> Repository root: svn+https://svn.openmethodscorp.com/svn/SoftPhone
<Luke-Jr> [13:32:44] <Luke-Jr> Layout: CustomLayout(['Harte-Hanks/CTI/Cvlan-Server'],[])
<Luke-Jr> [13:32:44] <Luke-Jr> Branch path: Harte-Hanks/CTI/Cvlan-Server
<Luke-Jr> [13:32:44] <Luke-Jr> Project: Harte-Hanks/CTI/Cvlan-Server
<Luke-Jr> [13:32:44] <Luke-Jr> bzr: ERROR: Layout CustomLayout(['Harte-Hanks/CTI/Cvlan-Server'],[]) does not support custom branch paths.
<jelmer> so what did you set exactly?
<Adys> Hmm
<SamB> hmm ... is there someone I could ask for the "~/.bzr.log" for a consistantly failing mirrored branch?
<Adys> Getting this on anything I do in my repo: bzr: ERROR: Cannot lock LockDir(file:///home/adys/src/bzr/sigrie/.bzr/checkout/lock): Permission denied: "/home/adys/src/bzr/sigrie/.bzr/checkout/lock/drthu03p89.tmp": [Errno 13] Permission denied: '/home/adys/src/bzr/sigrie/.bzr/checkout/lock/drthu03p89.tmp'
<jelmer> SamB: I think the .bzr.log file is provided on the website
<SamB> jelmer: really?
<jelmer> yeah, there should be a link to view the log
<SamB> I don't see anything on https://code.launchpad.net/~dvc-dev/dvc/main :-(
<Luke-Jr> jelmer:
<Luke-Jr> [svn+https://svn.openmethodscorp.com/svn/SoftPhone/Harte-Hanks/CTI/*Server*]
<Luke-Jr> tags = Harte-Hanks/CTI/Server-tags/*
<Luke-Jr> branches = Harte-Hanks/CTI/*Server*
<Luke-Jr> override-svn-revprops = svn:date
<jelmer> Luke-Jr: that's not the repository root
<Luke-Jr> ?
<jelmer> Luke-Jr: [svn+https://svn.openmethodscorp.com/svn/SoftPhone/Harte-Hanks/CTI/*Server*]
<Luke-Jr> jelmer: meaning?
<jelmer>  is not the repository root
<Luke-Jr> ok?
<Luke-Jr> it only applies to those paths
<Luke-Jr> svn+https://svn.openmethodscorp.com/svn/SoftPhone/Harte-Hanks/CTI/foobar could be entirely different
<djahandarie> Hello... I'd like some opionios on how to structure our bzr repo. I've already read the section on this in the intro guide.
<djahandarie> Basically, I'm working with a web application. Therefore local 'compiling' is worthless at this point.
<djahandarie> I have three servers currently: 'development', 'testing', and 'production'.
<djahandarie> Would it be best to have branches of these? A central repo? Hooks?
<djahandarie> I'm new to bazaar so anyone's opinion would be great!
<Luke-Jr> djahandarie: not sure, you might try asking in an anime channel
 * djahandarie stabs Luke-Jr 
<Luke-Jr> XD
<mwhudson> jam: how can i do that?
<jam> mwhudson: for branches which are failing, run that code with "bzr annotate $PATH"
<jam> mwhudson: you're on your own for figuring out what was failing, :)
<mwhudson> jam: probably a bit of a fiddle to do automatically, i'll see what i can manage
<mwhudson> (after i've finished getting up :)
<Luke-Jr> jelmer: so what SHOULD I be putting?
<jam> mwhudson: well, I made it work for the one you mentioned
<jam> I don't know about others
<jelmer> Luke-Jr: the repository root as reported by e.g. bzr info
<mwhudson> right
<djahandarie> So, anyone got any ideas as to how to format the centralized repository to handle my 3-tiered server install?
<Luke-Jr> jelmer: ok, I'll ignore the obvious problems with that for a minute-- it still doesn't work
<Luke-Jr> [svn+https://svn.openmethodscorp.com/svn/SoftPhone]
<Luke-Jr> tags = Harte-Hanks/CTI/Server-tags/*
<Luke-Jr> branches = Harte-Hanks/CTI/Cvlan-Server
<Luke-Jr> Repository root: svn+https://svn.openmethodscorp.com/svn/SoftPhone
<Luke-Jr> Layout: WildcardLayout(['Harte-Hanks/CTI/Cvlan-Server'],['Harte-Hanks/CTI/Server-tags/*'])
<Luke-Jr> Branch path: Harte-Hanks/CTI/Cvlan-Server
<Luke-Jr> Project: Harte-Hanks/CTI/Cvlan-Server
<Luke-Jr> bzr: ERROR: Layout WildcardLayout(['Harte-Hanks/CTI/Cvlan-Server'],['Harte-Hanks/CTI/Server-tags/*']) does not support custom branch paths.
<djahandarie> Luke-Jr, pastebin
<djahandarie> -_-
<jelmer> Luke-Jr: that looks right, except for that last bit
<djahandarie> I feel like I'm going to have to abandon the practice of making a seperate repo for every feature, because every time I push to that repo I'll need to merge it with the dev repo as well to actually test it.
<Luke-Jr> djahandarie: why would it be any different from normal software production?
<Luke-Jr> jelmer: so... :/
<djahandarie> Luke-Jr, well, you can compile locally when normally working. But now you'll have to upload all your changes to the testing server every time to test something.
<Luke-Jr> djahandarie: rsync works well
<djahandarie> rsync what?
<djahandarie> The central repo to the server?
<Luke-Jr> rsync ./ devserver:/var/www/bla/htdocs/â¦/ -av
<djahandarie> Luke-Jr, uh, so I'd end up having files on the server that have nothing to do with the central repository?
<djahandarie> This is for a team enviornment
<Luke-Jr> djahandarie: guess you shoudl setup local webservers
<djahandarie> Luke-Jr, can't.
<djahandarie> I was thinking about making the central repo have 3 branches: 'development', 'testing', 'production'.
<jelmer> Luke-Jr: not sure what that's about, I'll go check
<djahandarie> And then you'd merge your change locally into the right branch, commit to the central repo, and then the central repo would have a hook to automatically update the servers.
<Luke-Jr> djahandarie: pretty sure bzr doesn't support such hooks
<djahandarie> Luke-Jr, it does.
<Luke-Jr> and you should really test things before committing
<djahandarie> Luke-Jr, the point is that testing it is impossible.
<Luke-Jr> nah
<jelmer> Luke-Jr: Sorry, this doesn't seem to be implemented yet for WildcardLayout
<jelmer> Luke-Jr: for CustomLayout it should work without problems
<jelmer> Luke-Jr: I *think*
<Luke-Jr> â¦
<Luke-Jr> meaning?
<jelmer> Luke-Jr: layout/standard.py:344
<Luke-Jr> from an end user perspective?
<jelmer> Luke-Jr: I don't think this works yet, unfortunately so please file a bug
<djahandarie> The only annoying part about how I'm doing this is that when a change is made in a feature branch, you'd need to 1. save the file 2. merge the feature branch with the development branch 3. commit the development branch 4. check
<djahandarie> So feature branchs would be a huge hassle until you actually push the changes to testing, and then production.
<djahandarie> But if I didn't do feature branchs, then I'd have to cherry-pick the correct things into the testing/production branches, which would suck even more.
<Luke-Jr> djahandarie: s/push/merge
<djahandarie> Yeah, sorry, merge*
<Luke-Jr> djahandarie: seems to me your development model is inherently flawed
<djahandarie> Luke-Jr, yes, because of the fact you can only test it in one place.
<djahandarie> So a DVCS is hard to work with/
<djahandarie> But trying to do crazy merging with SVN sucks so I stayed away from that
<fullermd> I've occasionally taken contracts that required working on code that could only be worked on in one place.  I've never done so and not regretted it, though...
<Luke-Jr> djahandarie: "only test it in one place" is inherently bad
<djahandarie> Ideally, the solution for this would be that 'feature branchs' automatically merge into the 'development' branch.
<djahandarie> Luke-Jr, I know, but that's the environment I'm working with here, so stop making me feel even worse about it, alright?
<fullermd> If every commit has to be made and then stuck in dev before it can even be tested, it would be a lot easier to just eschew feature branches and work right in dev, I'd think.
<fullermd> I mean, you're basically talking about making a commit at a time, and merging them individually before moving on to the next one anyway.  So you're not in essence using another branch ANYway.
<djahandarie> fullermd, right, but then how would I push the feature to testing/production?
<djahandarie> Without cherry-picking
<fullermd> Presumably, the same way you would've yanked the feature from the feature branch to dev, with a merge.
<djahandarie> fullermd, wait, I thought you just said to scrap feature branches?
<fullermd> Hence "would've" rather than "did"   :p
<djahandarie> fullermd, ah.
<djahandarie> But then I would have to move ALL of development into testing/production
<djahandarie> Not the 'parts that work'.
<djahandarie> i.e., totally ruining the whole point of using Bazaar
<fullermd> Ah.  Well, there's no getting around 'take it all' or 'cherrypick'; Excluded Middle.
<djahandarie> Actually, does anyone know if a hook would be able to automatically merge the branch if the name of the branch isn't in [x,y,z]?
<djahandarie> Because that would solve the problem.
<djahandarie> It's just that the hook would have to be on every developer's local repo.
<djahandarie> Hmmmm
<fullermd> Well, with feature branches, you'd still have cherrypick issues, unless you started each branch from a GCA of the 3 dev/test/prod.  And that's just going to be an ever-increasing nightmare scenario, even before taking into account the huge overhead your process imposes on feature branch work anyway.
<djahandarie> GCA?
<fullermd> I'd start by semi-eliminating the test/prod split, by making production be pull'd from test at "stable" points (that being the point of test).  That at least drops you to 2 nightmares instead of 3...
<fullermd> The latest common node in their combined DAGs.
<fullermd> (DAGen?  DOG?)
<djahandarie> fullermd, well, then how would I do bug fixes on production?
<fullermd> Well, the theory is that nothing ever goes to production until it's been vetted in test...
<djahandarie> Testing is just to make sure feature X works with the rest of the system outside of the development enviornment.
<fullermd> So you'd bring bugfixes into test (however you do that), and when it's solid, pull test over prod.
<djahandarie> And there are always bugs even after the code is tested.
<Luke-Jr> jelmer: so how do I get CustomLayout
<djahandarie> Considering it's only going to be tested by the people here...
<djahandarie> And we might miss something
<Kobaz> so i have a strange problem
<Kobaz> conflicts: Contents conflict in ViewerCdrs.fcgi
<Kobaz> # bzr revert ViewerCdrs.fcgi
<Kobaz> bzr: ERROR: Path(s) are not versioned: ViewerCdrs.fcgi
<djahandarie> Bah, why does this have to be so complicated. -_-
<fullermd> Well, my conception of such arrangements is that test is a staging area for production.  In that case, having production be a [often out-of-date] mirror of test makes perfect sense, since it makes the VCS structure mirror the procedure.
<Kobaz> how can i have a conflict in a file that's not versioned
<fullermd> Well, obviously because (a) you have straitjacketish developmental constrants, and (b) you're trying to use a VCS as a deployment solution  :p
<djahandarie> fullermd, well, how would you recommend doing a bug fix on production when it's out of the VCS?
<djahandarie> Because testing might have new features in it by that point
<fullermd> Well, I don't, because I don't put up with dev structures like that  :p
<fullermd> I deploy a trunk, and other work is in a feature branch (or a degenerate version of such) until it's presumed ready for trunk.
<djahandarie> Well, the thing is the feature branches can't be tested locally...
<fullermd> Yeah, that's why I'm not working with you   :)
<djahandarie> -_-
<djahandarie> Well, is there any other way to VCS a web application?
<fullermd> Your problem is in trying to build a workflow around that.  And however you do it is gonna suck.
<fullermd> I tend to think it may be easier to NOT try and make the VCS handle part of that workarounding.
<fullermd> Can, for instance, it REALLY only be tested in that one _place_, or can it be tested on that one _server_?
<djahandarie> The server.
<fullermd> OK.  So, couldn't each dev get their own little sandbox on the server, in which they can setup their feature branches and work there on them, until they're ready to land?
<djahandarie> How would I hook that into everything else?
<djahandarie> I'm a bazaar and in general DVCS noobie, so I might be missing something
<fullermd> Well, you wouldn't necessarily.  That's where the D comes in  :)
<djahandarie> Well, I somehow need the local repo to get to files on the server
<fullermd> Each dev would have their 1 or 2 or 10 feature branches in ~/work/damntheseconstraints/{one,two,tree,etc}, and work on them until they're ready to land.
<fullermd> Then merge them into their ~/work/trunk/ checkout, or some such process.
<lifeless> moin
 * Luke-Jr mutters
 * SamB discovers that launchpad is apparantly not very good at preserving multiple spaces in the web rendering of a bug...
 * fullermd suspects LP is preserving them just fine, the SGML engin^W^Wcrapsoup parser in your browser just isn't.
<SamB> bug 399942 looks awful :-(
<ubottu> Launchpad bug 399942 in bzr-svn "HTTP 403 during svn transport probe causes bzr to give up entirely" [Undecided,New] https://launchpad.net/bugs/399942
<SamB> fullermd: well, bad at instructing the browser to do so, then ...
<SamB> not sure
<SamB> might just be the browser ...
<lifeless> it looks fne to me
<lifeless> though very long :)
<SamB> lifeless: yeah, I guess cgitb will do that ;-)
<SamB> but for me the spaces between the line numbers and their code are all collapsed into one
<lifeless> what browser?
<SamB> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.11) Gecko/2009061212 Iceweasel/3.0.11 (Debian-3.0.11-1)
<lifeless> what font too
<lifeless> might be a prop/non-prop thing
<lifeless> I' using epiphany
<SamB> it's showing in a fixed-width font
<SamB> I have no idea how to get mozilla to tell me exactly what font
<SamB> I looked for an add-on for that once, I think
<SamB> couldn't find one :-(
<lifeless> jam: if you're still around, I fixed three small dirstate/commit bugs yesterday
<lifeless> jam: would love a rubberystampy
 * SamB quits iceweasel in the hopes that starting it again cold will make it notice that he downgraded firebug again
<jam> lifeless: I'll try to give them a look
<jam> investigating the absent-content-factory w/ bundles issues right now
<lifeless> jam: they are all ~ 1 line fixes
<jam> lifeless: well, they aren't all 1-line diffs. :)
 * SamB wishes qemu supported reasonable acceleration
<lifeless> I know, which is why I'm telling you something diffstat doesn't ;)
<SamB> ECHAN
<jam> lifeless: what are you calling "forward edits" ?
<lifeless> when something moves
<lifeless> and something thats deeper in the old iterator gets changed by processing the item in the new iterator
<lifeless> we then encounter the thing that moved again in the old iterator, but we were seeing the moved item, rather than the original old-state
<lifeless> thats why 'mv b a' broke but not 'mv a b'
<jam> so is it better to deepcopy the old iterator, or to copy the items themselves before we mutate them?
<jam> the later seems to require less copying
<lifeless> but more complex code
<lifeless> I think we should do the simpler thing and then usertest to find out if it really matters perf wise
<SamB> maybe you should stop mutating shit so much ;-)
 * SamB <- Haskeller
<lifeless> heh
<lifeless> so it might find this easier to do
<lifeless> but we're updating a table
<lifeless> by walking the table and a tree in parallel
<lifeless> it would be arguably nicer to transform the new inventory into a delta against the old inventory and apply that
<lifeless> but I am concerned that that might be slower
<lifeless> without care
<lifeless> so I wanted to fix the bug, and come back later and look at deleting a tonne of code; particularly if we can just remove callers to this method
<lifeless> thanks jam!
<jam> lifeless: while your head is in this code, I've noticed times where the auto-remove still fails if you delete the parent directory of a file
<jam> (foo/bar/baz/bing, all of bar/baz/bing have been deleted)
<jam> I'm pretty sure there is an open bug on it
<lifeless> in commit?
<jam> yeah
<jam> if you do "bzr rm" then commit works
<jam> but if you just "rm -rf foo/bar; bzr commit" it blows up
<jam> I thought you looked a while ago about removing the strict ordering requirement
<lifeless> I think thats bug 187207
<ubottu> Launchpad bug 187207 in bzr "Inconsistent deltas created when commiting and an implicit delete has happened" [High,Fix committed] https://launchpad.net/bugs/187207
<lifeless> I'll have a look for a bug
<lifeless> unversion doesn't have a strict ordering requirement
<lifeless> in fact, it setifies its inputs immediately
<jam> lifeless: for  https://code.edge.launchpad.net/~lifeless/bzr/bug-187207/+merge/8800
<jam> the big change is to only discard when it isn't already absent/renamed?
<lifeless> right
<lifeless> discardin the id stops us unversioning it again
<lifeless> so we only discard when we actually unversion it
<lifeless> finding it at an old path before we find it at a new path doesn't actually count as discarding
<jam> lifeless: so since we were skipping , we leave the id around
<jam> to be unversioned later?
<lifeless> yes
<lifeless> thats inside the code for deleting an entire block
<eyda|mon> I've got two repos, A and B. B is a branch of A. I change file F1 and F2 in branch B. F1 has one comitt message, and F2 has commit message. I then merge to branch A, but then I revert the changes made to file F2 before I commit to branch A.  bzr log will still show the commit messages made for file F2. Is that supposed to be like that? Those changes were just not part of  branch A at all, but they still
<eyda|mon> show up.
<lifeless> where a subtree has been deleted
<dash> eyda|mon: revert just changes the working copy
<dash> eyda|mon: merge brings in the entire history
<fullermd> eyda|mon: That's what merge does.  (also, you don't (well, you may, but it's not relevant) have two repos, you have two branches)
<lifeless> eyda|mon: thats normal yes; if you do a merge, and then change the merge to be different, then commit, bzr doesn't know the /meaning/ of the change you made
<dash> eyda|mon: so the result is that the merge revision undoes the changes to F2
<eyda|mon> dash:  but that still results in a very misleading log
<dash> eyda|mon: well don't do that then :)
<lifeless> eyda|mon: if you made separate commits, you can do something like 'bzr merge -r -2 B' in A
<lifeless> which will merge all but the last commit
<eyda|mon> i normally dont, but I was pushing changes to production, and I didn't want all those changes to production.
<eyda|mon> lifeless: i see, ok, interesting
<jam> lifeless: I think I have a basic handle on bug #393349
<ubottu> Launchpad bug 393349 in bzr "exceptions.AttributeError: 'AbsentContentFactory' object has no attribute 'get_bytes_as'" [Critical,Triaged] https://launchpad.net/bugs/393349
<jam> basically, the bundle code doesn't ensure the same state in a stacked branch
<jam> that the fetch code does
<lifeless> jam: might want to move all the dicussion to that bug :)
<lifeless> jam: 390563 is the iter_interesting_changes bug
<jam> so I was wondering what your thoughts might be about the proper fix
<jam> is it a limitation of the bundle *generator*
<jam> or the bundle *inserter*
<jam> (or both :)
<lifeless> I think the inserter should error-or-fix-on-the-fly
<lifeless> thats for robustness
<lifeless> it shouldn't fail late
<lifeless> (maybe it isn't)
<jam> it is failing during "check diff" which I think is later than it should be erroring
<lifeless> but as the source isn't guaranteed to be around, if the best the inserter can do is error [without the source], then clearly we need to change the creator.
<lifeless> so, sounds to me like the inserter can be improved
<lifeless> I think we should make sure we're not creating partial rev inventory data etc as a priority
<lifeless> and perhaps a fixup tool for existing damaged branches (tied into fetch perhaps - bzr fetch --ghosts <...>)
<lifeless> and then move onto getting enough data sent in the first place
<jam> hmm... at least here it is failing on "self._ensure_root()" which would say that the root chk isn't present at all...
<lifeless> :>
<lifeless> but the inventory is
<jam> lifeless: there are 0 chk pages in the final result
<lifeless> thats fairly corrupt
<jam> yep
<jam> lifeless: so the bundle generator code seems to directly access the inventory data
<jam> and include it in the bundle
<jam> but it *doesn't* include the chk data
<jam> so it neither upcasts to an XML inventory
<jam> nor includes chk
<jam> so bundle generator w/ chk... completely broken
<lifeless> heh
<lifeless> I'm sure then that we want to make the inserter more paranoid
<lifeless> and the generator fixed (perhaps upcast to XML for existing formats, and add a delta based one)
<jam> lifeless: so I'm pretty sure that whatever I do, the new bundles won't be compatible with older bzr
<jam> and if that is true
<jam> then I'm thinking it may be time to change how we deal with bundles
<jam> and go the full route into making them just a transport for a stream
<lifeless> I think if you upcast to xml and did the existing bundle code, that will work with older bzr; could be wrong
<lifeless> I'm pro doing the full mccoy
<jam> lifeless: the existing code will try to insert those XML texts *into* repository.inventories
<jam> as is
<lifeless> hmm
<jam> it doesn't go through Serializers at all
<lifeless> so two things
<lifeless> what about xml bundles from people using 1.9-rr to someone using 2a
<lifeless> well, one thing really;)
<lifeless> back shortly
<jam> lifeless: ok. so it seems the existing code says "if serializer.format_num == bundle_serializer.format_num: _install_mp_records_keys"
<jam> otherwise it assumes that it can apply the mpdiff directly to the parent inventory
<jam> text
<jam> ah, because it grabs the Inventory, then serializes it in the  source format
<jam> then reads it back in as a string
<mwhudson> jelmer: https://code.edge.launchpad.net/~vcs-imports/openlibrary/trunk <- submodules!
<lifeless> bah, my bug 395556 bugfix isn't complete. I'm going to have to look deeper.
<ubottu> Launchpad bug 395556 in bzr "dirstate.set_state_from_inventory is broken with forward-edits." [High,Fix committed] https://launchpad.net/bugs/395556
<lifeless> The other two should be fine
<lifeless> (395556 causes fallout)
<SamB> abentley: shouldn't bundle buggy provide a link to the superseding bundle if a bundle has a Status of Superseded ?
<SamB> I'm looking at http://bundlebuggy.aaronbentley.com/project/bzr/request/%3CE1MRCZb-0007ee-Kn%40hydrogen%3E and wondering what in the world it picked up as superceding that
<SamB> oh ... I guess it picked up http://bundlebuggy.aaronbentley.com/project/bzr/request/<E1MQZOB-0003MV-Id%40hydrogen> ?
 * SamB was given to understand that bundle buggy didn't take bundles with [PATCH] prefixes
<abentley> SamB: It should, but it doesn't.
<SamB> abentley: did you just add support for [PATCH] prefixes or something?
<SamB> or was bundle buggy down for a long while ?
<abentley> SamB: It was down.
<SamB> ah.
<SamB> and whoever told me about that I needed [MERGE] was wrong ;-)
<KhaZ> Hello.  I'm contemplating an idea, and I'm curious if other people can shoot holes in it.  At work we use Perforce, but I was thinking it would be nice to run a bzr depot locally to allow me to do multiple 'checkins' locally, and possibly share with other developers similary set up (via push/pull).  I'd treat 'syncs' from Perforce as 'checkins' to bzr.  Would this scheme break down fast, or would it give me the benefit of local changes, and pot
<mwhudson> KhaZ: your message got truncated there
<KhaZ> mwhudson: What'st he last bit you received?
<KhaZ> *what's the?
<thumper> KhaZ: line limits for irc
<mwhudson> "nges, and po"
<KhaZ> potentially the ability to 'share' code with other developers?
<KhaZ> thumper: Weird.  I would've figured irssi would've caught that for me.  Oh well.  Pardon me.
<lifeless> KhaZ: I know of other people that do roughly what you describe; I don't know the details though
<mwhudson> KhaZ: nothing about that sounds too insane
<KhaZ> Hrmm.  I might give it a shot.  Maybe it'll give some adoption to other devs anyhow.  I'm really sick of Perforce outages and slow syncs. :/
<mwhudson> KhaZ: the area you might have problems is when the changes you make in bzr end up in perforce and then you sync from perforce, you might get conflicts
<lifeless> KhaZ: If I may be nosy, what organisation do you use p4 at?
<SamB> KhaZ: it's nondeterministic, or something
<SamB> the line-limit thing
<SamB> I've seen the same text truncated to different lengths when sent twice in a row
 * SamB isn't sure if it was by the same person or not, though -- that would make a difference
<KhaZ> lifeless: Well, in this case it's a company called Propaganda Games.  But most gaming companies I've worked at use Perforce.
<KhaZ> SamB: What is non-deterministic?
<KhaZ> Oh, the line-limit thing.
<lifeless> KhaZ: interesting :) - thanks for satisfying my curiosity.
<SamB> I'm not sure if it is really nondet or not
<SamB> but it acts like it to the naive observer ;-)
<KhaZ> lifeless: No worries.  Mind if I ask what made you curious about it?  Sitting on this channel as you do, I'm sure you don't ask everyone what company they're at? :)
<KhaZ> Right, makes sense SamB.
<lifeless> only people that use p4 ;)
<KhaZ> Hah.  What's so curious about p4?  I'd be more interested in knowing who's still using VSS!
<lifeless> more seriously, if you were at one of the companies that I know people that use bzr w/p4 I would have tried to get you talking to a colleague.
<KhaZ> lifeless: Ah, fair enough.
<lifeless> but I couldn't ask them if they were happy to share the name immediately, and you were here ;)
<KhaZ> Makes sense!  Thanks for satisfying *my* curiousity. ;)
#bzr 2009-07-16
<james_w> "This is an easy way to check out a particular version without having to make up a name for the new branch. You can still create a new branch (or tag) for this version later if you decide to."
<james_w> BUT HOW DO I DO THAT???
<lifeless> james_w: context?
<james_w> git
 * SamB suspects jelmer of knowing the answer
<lifeless> james_w: oh, fail ;)
 * SamB suspected that even without context
<SamB> james_w: are you talking about vanilla git or bzr-git?
<james_w> just git
<SamB> oh, well, first of all, why not ask in #git?
<SamB> secondly I believe it's just "git checkout -b branchname sha1" if you want to check out this new branch
<lifeless> because its not as entertaining?
<james_w> I wasn't asking so much as venting
<igc> morning
<mwhudson> hey, if someone will tell me if my diagnosis in https://bugs.edge.launchpad.net/bzr/+bug/400003 is correct, i'll fix the bug
<ubottu> Ubuntu bug 400003 in bzr "readv(directory, ...) blows up in strange way" [Undecided,New]
<lifeless> mwhudson: shallowly, it seems ok to 'fix' it by implementing seek
<mwhudson> lifeless: when you say shallowly do you mean simply "i haven't thought about it hard" or "if i thought about it hard i have this niggling feeling i'd have a different answer" ?
<lifeless> I'm curious why its blowing up here and not other places we might use it
<lifeless> and I haven't thought hard or even looked at the code to try to answer that
<lifeless> If I knew *why* I might be able to answer ehther I'd have a different answer or not
<mwhudson> fair enough
<poolie> mwhudson: when you file bugs please mark them confirmed and have a stab at setting the priority
<poolie> it avoids roundtrips
<poolie> even if we sometimes want to change the prioritiy
<poolie> i realize not every team does it that way
<mwhudson> poolie: ok
<mwhudson> i don't think i can set the priority
<poolie> oh that sucks a bit
<poolie> you can join ~bzr if you want though?
<mwhudson> i guess i should
<mwhudson> poolie: i think you need to add me?
<poolie> ok
<poolie> i'll warn you, you will get more bug spam
<poolie> but probably less than you get from lp
<poolie> or should i say regarding lp
 * igc kicks off performance test to check whether proposed inv-delta checks make much difference or not
<igc> lifeless: ^^^. I'm still going over the dirstate.py and inventory.py changes in your patch. All the rest is ok by me.
 * Luke-Jr_ spams jelmer with https://code.launchpad.net/~luke-jr/bzr-svn/0.6-WildcardLayout-get_tag_path-basic/+merge/8858
<lifeless> igc: thanks
<poolie> mwhudson: oh also, not to be picky, but you can do better as far as titles
<mwhudson> poolie: probably
<mwhudson> i actually had a far more specific title at first, and then tried to step back to describing the problem, not my presumed solution
<poolie> but great work on the bug number :)
<mwhudson> :)
<spiv> Ok, I think I have no test failures finally.
<poolie> nirvana :)
<mneptok> nammo tassa bhagavato arahato sammasambuddhasa :)
<igc> bbiab
<lifeless> fooding
<spiv> poolie: inventory-delta branch sent to lp for review.  If you would like something to occupy your afternoon... ;)
<lifeless> spiv: hai; I can has review then?
<igc> lifeless: some feedback re your patch ...
<lifeless> igc: yup
<igc> on OOo, simple commit time goes from 1.8s to 3.3s
<lifeless> ah, apply-delta
<igc> 2. the test suite is failing too
<lifeless> I ran the full suite on ec2 :(
<lifeless> could you get me the failing test names?
<spiv> lifeless: sure, but after I get some lunch!
<lifeless> igc: so, that could be in create_by_delta *or* in dirstate's update_basis_by_delta, both of which change
<lifeless> igc: is the 'simple commit' adding a file or just changing something?
<igc> lifeless: http://pastebin.com/d7954f8c6
<igc> lifeless: changing a committed file
<igc> lifeless: the test suite hung completely btw in test_get_nested_trees
<igc> lifeless: I'll try it again
<lifeless> I'll see if I can get a handle on it; but I may need you to get an lsprof of the commit time before and after
<lifeless> to see which of the appliers is regressing
<lifeless> heh those deltas are bogus
<igc> lifeless: thanks. I haven't tried to see how reproducible the issue is
<lifeless> if the applier were to choose to apply the second component first it would end up deleting
<lifeless> so - thats good to know, its an existing bug I suspect, and really quite a bad one ;)
<igc> lifeless: long live defensive programming!
<igc> lifeless: some other quick feedback ...
<igc> the while in update_minimal will loop forever?
<igc> the messages in dirstate._apply_removal ...
<igc> 1. should the first 2 be exactly the same text?
<igc> 2. "wrong has wrong id" in the 3rd message
<igc> man I *hate* reviewing dirstate changes :-(
<lifeless> igc: perhaps those three are best done via a pastebin of the diff with notes
<lifeless> or a reply to the merge proposal
<igc> sure
<igc> lifeless: also http://pastebin.com/d35918166
 * SamB wishes somebody would vote for http://bundlebuggy.aaronbentley.com/project/bzr/request/%3CE1MQZOB-0003MV-Id%40hydrogen%3E -- perhaps jelmer?
<igc> lifeless: commit of whole tree with one file changed
<igc> commit of a single file is 73+ seconds
<igc> SamB: jelmer is having a life this week IIUIC - attending some concert event or something like that
<lifeless> igc: yup, thats what we're aiming at to fix;)
<SamB> igc: noooo! that's impossible!
<SamB> you killed my father!
<igc> SamB: I am your ... - um, no I'm not
 * SamB thinks yoda ought to have warned anakin about self-fulfilling prophecies ...
<JoaoJoao> howdy
<JoaoJoao> Does --no-trees and lightweight checkouts work flawlessly on Windows?
<lifeless> poolie: ciao, see you tomorrow
<lifeless> igc: I'm essentially waiting on lsprof before-after for the bad case to progress that branch.
<spiv> lifeless: did you see my approve for ~lifeless/bzr/bug-216541, btw?
<igc> lifeless: ok. I'll collect some data for you
<lifeless> spiv: thanks
<spiv> (i.e. fire it at PQM kthxbye :)
<lifeless> doing now :)
<lifeless> then going for the day (\o/ starting at 6:30)
<lifeless> hmm, technically I'm finishing late as per :P
<lifeless> igc: to be clear, I'll fix the test fallout, but I don't know where to go with the perf overhead as there are two delta applications made, and in theory a new file should be slower than a mutation to an existing :)
<igc> lifeless: I'll dig and add the profiles to the associated bug
<lifeless> igc: thanks
<vila> hi all
<igc> hi vila!
<igc> lifeless: done
<spiv> Wow PQM is slow these days.
<spiv> It's been on the same branch for nearly two hours, I think.
<spiv> (and making progress)
<dash> maybe it's making /real sure/
<spiv> Oh, there we go, one of my branches passed.  I guess it was already onto the second branch.
<spiv> So probably it's "only" an hour for a branch to land.
<spiv> Ah well.
<lifeless> spiv: argh; NEWS conflict with your branch :(
<spiv> lifeless: :(
<spiv> lifeless: that's what you get for taking credit for your work!
<spiv> lifeless: fwiw, the branch of mine currently playing on PQM doesn't add a NEWS entry (it's pretty trivial)
<lifeless> good to know thanks
 * igc dinner
<spiv> If PQM showed the diffstat of merges in its queue it might help people spot potential conflicts... *handwave*
<awilkins_> Offtopic : can you mount a subfolder of a filesystem?
<awilkins> e.g. - I have a FS that is a "home" folder, but I want to mount a subfolder of it on another system - a softlink isn't working 100% well because when applications are in the folder they see the path through the mountpoint and not the softlink
<fullermd> awilkins: You may find it under the heading of 'nullfs'.
<awilkins> fullermd: Aha, that sounds rather like something useful, ta
<fullermd> (an additional way of faking it if performance/quirks/etc aren't fatal is via NFS mounting it over loopback)
<lifeless> awilkins: what os?
<awilkins> lifeless: Ubuntu Jaunty
<lifeless> so you have (say) /home as a fs, and want to mount /home/foo at /bar?
<lifeless> or are you actually talking about network sharing?
<awilkins> lifeless: I have an external HD with an home folder in it and I currently link a subfolder of that to the same subfolder in my desktop home folder at home
<awilkins> I boot from the external HD and work from it when I'm in the office
<awilkins> The problem is that Eclipse adds projects with a path of "/media/tachikoma-home/adrian/...." instead of "/home/adrian/....." when I'm using it via the softlink
<lifeless> ok
<lifeless> so on your home machine
<lifeless> rather than symlinking
<lifeless> do a bind mount
<lifeless> mount --bind olddir newdir
<awilkins> Aha, yes, that's just what I want
<lifeless> (after mounting it)
<awilkins> I'm disappointed that didn't show up for googling "mount subfolder of filesystem"
<lifeless> you should blog about it
<lifeless> so that it can
 * fullermd adds that to his mental list of 'other names for nullfs'.
<awilkins> Excellent, not as automatic as a softlink but it actually works properly
<awilkins> Hate to say it, not as easy as Windows drive letters (although I usually need a drive-letter manager service for similar reasons)
<lifeless> you should be able to hook it into the automount stuff
<lifeless> patches++
<maploin> hi! Is there a way to undo an `unshelve` command?
<spiv> maploin: only by doing shelve again.
<spiv> So if the change you unshelved is mixed up with other changes you'll have to manually pick them apart again.
<maploin> yeah, that's what I was afraid of :(
<maploin> thanks, spiv
<abentley> jelmer: ping
<awilkins> Hhm, since shelve is based on tree transforms now, there's no reason why you couldn't have an "undo shelve" option
<awilkins> It calculates tree transforms and persists them when you shelve stuff, therefore it could also persist treetransforms that it was unshelving, so you could reverse them if required
<pdragon> is tortoisebzr supposed to work on mapped drives in windows? I have a branch on a mapped drive and when I right click to bring up the menu, I have none of the bzr options
<pdragon> just get the Help, Settings, About options
<pdragon> nothing else
<awilkins> pdragon: By default it's configured not to examine .bzr folders on network drives, for performance reasons
<awilkins> pdragon: You can change that in the settinsg
<pdragon> ahh ok
<pdragon> awilkins: thanks, that was it
<pdragon> and i see what you mean :)
<awilkins> pdragon: I confess I don't use it ; I'm happy enough just using a Powershell and spawning the qbzr dialogs from there if I want them
<awilkins> I've actually uninstalled it because I have some horrific bzr trees on my drive and it thrases rather
<pdragon> yeah, well, I'm introducing version control to a place where it's never been used before
<pdragon> so trying to start out one something very easy
<awilkins> I know the feeling
<awilkins> :-)
<pdragon> just version controlling different websites in different folders
<pdragon> no branching or anything.
<awilkins> As long as it isn't visual sourcesafe
<awilkins> TortoiseSVN is very mature and usable by the nontechnical
<pdragon> oh nope... will be all bzr
<awilkins> I can understand that
<pdragon> i've been using tortoisebzr for my own project for a while, learning how to use it
<pdragon> finally had some crap happen at work where i've got them convinced version control is a good idea :)
<pdragon> but, need to keep it stupid simple to start
<awilkins> Heavyweight checkouts and a central server :-)
<pdragon> yeah, i'm starting even simpler. just version controlling our local copy of the website
<pdragon> it's only 3 people
<pdragon> will work up to checkouts later :)
<awilkins> Editing live websites can only lead you to ruin :-)
<pdragon> oh it's not editing it live
<pdragon> it's editing our local copy
<pdragon> which then gets pushed to the server
<pdragon> i versioned our local copy
<awilkins> Ah, this is the folder on the network share
<pdragon> yeah
<jam> pdragon: sorry, I'm back. Wireless failure...
<jam> so much pain... :)
 * fullermd makes a note to buy jam some wires for Christmas.
<awilkins> Does LP accept/work well with --2a branches?
<pdragon> woo... got the web developer using it and he likes it :)
<awilkins> There's a fairly awesome git/ruby-on-rails video that demonstrates branching that might impress him more...
<awilkins> But I can't find it
<pdragon> oh trust me... branching is more than these guys want to deal with now since it's such a small team
<pdragon> they're just interested in a file change history at this point
<pdragon> our problem is our website is hosted by a third party that does a lot of the behind the scenes stuff on their end since they host all our data (real estate company)
<pdragon> they're not "supposed" to touch our stuff without talking to us first. but they keep doing it. and they will not share their versioning history with us. so now, we've got a way to keep track of all changes
<pdragon> it's a shitty system, yeah, but it's what we've got to deal with :/
<pdragon> thanks for the help awilkins. later
<cody-somerville> oh hai
<cody-somerville> I broke bzr
<jave> hello
<jave> I'm having a problem with following the emacs bzr repos, which is experimental
<jave> now I get: bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.
<jave> how can I extract the changes I made to a branch in a patch?
<jave> my local branch is called xwidget
<awilkins> ls
<fullermd> . ..
<_oggy> hi all. i need to version control a PHP script. it's part of a project whose repository directory is outside of Apache's DocumentRoot. obviously i'd like to track the "live" version of the script instead of copying back and forth. is there a way to do that?
<rockstar> _oggy, well, ideally, you aren't making "live" changes, so you can just push of upload.
<rockstar> _oggy, but sometimes you need to.  I push the branch to a neutral location, and have the document root be a checkout of the branch.  Then I update and commit as needed.
<_oggy> rockstar: perhaps i didn't explain very clearly. the PHP script is on my box, so it's not "live" in a "deployment" sense, rather "live" in the sense of "i can see the effects of changes i make"
<_oggy> however i'd like to make it a part of a (mostly non-PHP) repo which lives outside of DocumentRoot, so i can share it with other people
<rockstar> _oggy, symlinks.
<_oggy> rockstar: doesn't bzr then just track the symlink, instead of file contents?
<rockstar> _oggy, put the symlink in your documentroot, have it pointing to the file in your branch.
<rockstar> Sorry for the ambiguity.
<fullermd> Why would you want it to be part of something that [I assume, from it being elsewhere] isn't part of the same project?
<_oggy> rockstar: yeah, but i have to set up PHP (or Apache? forgot which) to allow execution outside the DocumentRoot
<_oggy> rockstar: not that it wouldn't work, i was just hoping for something more elegant :)
<rockstar> _oggy, just set up up to follow symlinks.
<rockstar> As long as it knows to follow the symlink, you shouldn't have any problems with where the file actually is.  Apache won't differentiate between an actual file in DocumentRoot and a symlink to a file outside DocumentRoot.
<_oggy> fullermd: it is a part of the project, but the project is mostly non-PHP, so it doesn't make sense to put it inside of DocumentRoot
<_oggy> rockstar: yeah, i know. thanks. i was just hoping there was a way to tell bazar to track the symlink directory content instead of tracking the symlink itself
<fullermd> Well, I always just use Makefiles to deploy into docroots.  But that's deployment, for dev I always just have symlinks into the working branch anyway.  's simpler.
<_oggy> fullermd: yeah, it probably makes more sense that way anyhow
<asabil> hi all
<pygi> hi asabil
<asabil> hey pygi
<pygi> how are you doing enemy?
<asabil> enemy ?
<pygi> that's a joke
<asabil> :)
<jave> is there some way to extract all changes to a branch as a patch?
<awilkins> jave: bzr diff -r ancestor:../my-pappa
<jave> the ancestor is corrupt
<awilkins> jave: You need to know the revision it was branched from them
<awilkins> bzr diff -r n..  # where n is the revision
<jave> the branch was merged several times from upstream
<awilkins> jave: It'll be the last merged revision then
<awilkins> jave: Assuming you didn't cherrypick
<jave> no cherrypicking
<jave> is it really "bzr diff -r n.." ? cant find that syntax in the manual?
<awilkins> bzr help diff ; bzr help revisionspec
<jave> Thanks
<awilkins> Hmm, I could be wrong about the range part
<mgedmin> how can I ask bzr from a shell script whether my working tree is clean?
<flacoste> anyone aware that the bzr nightly packages are not installable on hardy?
<asabil> mgedmin: bzr status ?
<mgedmin> it returns the same exit code in both cases
<flacoste> they depends on python-central >= 0.6.7 and 0.6.5 is available in hardy
<mgedmin> I could play with grep, but I'm afraid of misundestandings
<fullermd> Well, depending on exactly what you mean by 'clean', it should have NO output at all.
<mgedmin> good idea
<mgedmin> I probably want to stop if there are unversioned files
<fullermd> An alternative would be using version-info
<mgedmin> bzr version-info --check-clean is what I was looking for, thanks!
<zsquareplusc> is there a restricted shell like thing to install as shell for an user, so that he can only do bzr+ssh? or maybe something similar to mercurial-server
<rocky> jelmer: is there anyway to instruct bzr-svn to not try and figure out the tags/branches layout of an svn repo?
<garyvdm> zsquareplusc: bzr shell from plugin "bzrtools"
<zsquareplusc> garyvdm: thanks. now that's a name that is easy to search in google ;-) heh
<lifeless> moin
<zsquareplusc> hm. but bzr shell -> ls shows all files on the disk. not really "restricted"
<jelmer> rocky: why would you want to do that?
<rocky> jelmer: because this particular svn repo i'm dealing with doesn't have tags/branches folders and blocks access further up which means bzr-svn barfs with 403
<fullermd> bzr shell isn't anything restricted, it's just a shortcut for running commands.
<fullermd> You can limit what commands can be run with various ssh keys somehow...
<jelmer> rocky: I'd argue that bzr-svn sould handle the 403
<jelmer> rocky: you can also specify a manual repository layout
<rocky> well i'm not really arguing anything, but i do think it's a little odd that bzr-svn depends on finding a svn layout
<jelmer> rocky: what's odd about that?
<jelmer> rocky: the alternative is requiring users to specify a repository layout manually always
<rocky> i guess
<rocky> jelmer: how do i do it manually btw?
<lifeless> jam: could I bother you for https://code.edge.launchpad.net/~lifeless/bzr/bug-395556/+merge/8857 again please
<jam> lifeless: you are doing "from copy import deepcopy" but it doesn't look like you are using it
<jam> lifeless: and you update the comment, but again, it isn't accurate now
<jam> lifeless: weird, the code review page you linked doesn't actually give me the ability to review it....
<jam> maybe because of a text conflict?
<jam> or maybe the ui just changed
<jam> since it still has the "review or comment" link, I guess
<emmajane> poolie, ping?
<lifeless> jam: oh doh, thanks for the catch on th ecomment
<lifeless> and import
<jam> lifeless: I've got a bit more
<jam> sending it as a real review
<lifeless> thanks
<lifeless> this at least passes all commit tests
<lifeless> the other win shoved a different test out
<lifeless> s/win/one
<jam> lifeless: review sent
<jam> you also have ".decode('utf')" in the new tracing code
<jam> rather than 'utf8'
<jam> etc
<lifeless> blah, thats shoddy of me
<jam> and a code comment that says "we update an iterator" when you are popping an entry out of the list
<jam> I don't see anything done to an iterator
<mwhudson> jam: you have seen my lazy-import aware pyflakes?
<jam> mwhudson: other than hearing a while back that it existed, I haven't really done anything with it
<mwhudson> jam: just because you said
<mwhudson> As near as I can tell, you don't use deepcopy anymore so you don't need to import it
<mwhudson> +from copy import deepcopy
<jam> mwhudson: :) but does it work on patches I read via HTTP?
<mwhudson> jam: ah, no
<mwhudson> you could probably write a thing that automatically reported flakes on proposed reviews using the api...
<KhaZ> This is a bit of an odd question, but I'm finding bzr st to be pretty slow on my system (cygwin on WinXP).  I do have a lot of files in this depot however, so I'm not sure if there's much that can be done, but I'd be interested to hear if there's any 'tricks' to speed it up?
<jam> KhaZ: don't use cygwin
<jam> use the win32 port directly
<zsquareplusc> KhaZ: did you compare with a native python + bzr?
<jam> last I checked it was ~2x faster
<jam> cygwin adds a *lot* of per-path overhead
<KhaZ> Huh, OK.  I'd like to try that.  Would it make a difference if I call the native binary from within cygwin?
<jam> and status has to hit every path in your tree
<jam> KhaZ: I do it all the time
<KhaZ> Ah, I see.  So perhaps even running within cygwin would be slow.
<jam> no
<jam> native win32
<KhaZ> Really?  but running the native app within cygwin; wouldn't the same pathing routines be called?  Well, maybe not now that I think about it.
<jam> doesn't have to ask the cygwin.dll to translate the path
<KhaZ> I guess it calls win32 api's directly rather than cygwin's emu layer.
<jam> yep
<KhaZ> Right.  OK, I'll see about switching.  I don't need to re-init my depot, do I?
<jam> nope
<KhaZ> Alright.  I'll just wait for this crazy slow commit to finish.
<jam> the only thing that might effect you is if you were using symlinks or executable bits
<KhaZ> Nope.  this is a windows app, so I'm "lucky" that way.
<jam> KhaZ: "time /bin/python bzr st" on my machine is 1.5s, "time bzr st" (native) is 0.421s
<jam> Not perfectly apples-to-apples
<jam> but > 2x
<poolie> hello emmajane, hello jam
<emmajane> poolie, hey :)
<emmajane> poolie, have you got a minute or two for a PM?
<poolie> sure
<emmajane> cool
<KhaZ> Oh, neat.  And I don't need a native version of bzr, but a native version of python?  Is that right?
<jam> KhaZ: there are a lot of ways to do it, but if you have the native  python executable you can run from there
<lifeless> jam: how much longer are you around?
<jam> however, it also sounds like you might not be running with the compiled extensions
<jam> which is another big win
<jam> lifeless: just about to leave
<jam> If you want, we can talk via phone
<lifeless> jam: I am hoping to land this patch is all
<lifeless> jam: I've replied to the review
<lifeless> I need about 5 minutes to make the last tweak I realised that would make it better
<KhaZ> What would you call the different methods of talking to remote bzr depots?  'transports'?  (I'm talking about things like bzr+ssh, etc).
<KhaZ> I'm trying to look up the different tyeps to pick the best one for my sitaution.
<KhaZ> Man, my typing is swill today.
<lifeless> bzr help urlsepec
<lifeless> bzr help urlspec
<KhaZ> Ah; thanks.
<fullermd> lifeless: BTW, I got a few minutes to try fiddling with libcpuinfo build...
<fullermd> I had to make some tweaks I don't entirely understand to configure.ac to get it as far as running configure.
<lifeless> fullermd: thanks
<fullermd> How do I test the language bindings?
 * fullermd doesn't see a counterpart to the bin/p_count
<fullermd> lifeless: http://paste.ubuntu.com/220120/
<fullermd> (LT_* just got passed straight through as text, which blew up when running ./configure.  automake got cranky without the AC_PROG)
<lifeless> what version of libtool and autoconf do you have?
<fullermd> Looks like it would be using ac 2.62, am 1.10.1, lt 1.5.26
<lifeless> I think it needs lt 2* for the new syntax
<lifeless> which builds a lot faster
<fullermd> Mmm.  Not even a port for lt 2.
<lifeless> ?!
<lifeless> seriously? its up to 2.2.x these days
<fullermd> Nyet, only 15.
<lifeless> feel like some yak shaving?
<fullermd> Whoops, afk, I have to clean my hair and rearrange my underwear drawer.
<lifeless> lol, ciao
<igc> morning
<KhaZ> Alright, can anyone recommend the easiest urlspec to use with Windows users who prefer stuff to 'just work'?  I'm thinking of something like samba shares and just file://.... Is that rife with problems?
#bzr 2009-07-17
<lifeless> KhaZ: should be fine, if you're talking about a place to push and pull from
<KhaZ> Aye.  Alright, I'll give that a shot.  Thanks.
<lifeless> best performance would be to use bzr+ssh
<lifeless> if you only have LAN's though file:// is fine
<KhaZ> Yeah.  We'll see; maybe I'll switch over to installing SSH on Windows sometime; but I'll try out samba for now.
<lifeless> the bzr install comes with bzr+ssh support, you just need pageant
<lifeless> (I think)
<KhaZ> Right; but it doesn't set up a server, does it?
<KhaZ> i.e., if I have two fresh windows boxes, and I use the bzr installer, it won't set up an svn server such that I acn push/pull between the two, I think?
<lifeless> s/svn/bzr/ ? :P
<lifeless> no it won't, but samba implies that you have a unix machine there anyway ;)
<lifeless> unless you meant SMB rather than Samba.
<KhaZ> Sorry, I should mention, "Windows Sharing", not samba.
<KhaZ> Yeah; SMB, rather.  I just always spell out samba.
<KhaZ> My bad.
<lifeless> np
<KhaZ> *spell it out as Samba, implying they're the same when they're not.
<lifeless> igc: so, CHKInventorypath2id is doing much more work than needed
<lifeless> igc: I'm fixing it.
<igc> lifeless: thank-you, thank-you, thank-you
<igc> lifeless: lots of performance hot spots will be improved by doing that I suspect
<lifeless> igc: its this todo:
<lifeless> # XXX: Todo - use proxy objects for the children rather than loading
<lifeless> # all when the attribute is referenced.
<lifeless> however, I'm not going to do the todo, for now I'm just going to fix path2id directly
<lifeless> igc: for reference, just double clicking on the path2id node in the profile shows it doing 300 IO's
<lifeless> igc: which gives a hint that its doing more work than needed :P
<igc> lifeless: in kcachegrind? That doesn't work for me? What panel?
<lifeless> igc: callee map
<lifeless> igc: the tree - double click on the path2id bzrlib.inventory:1993 line
<lifeless> s/line/node
<lifeless> actually, its not the callee map, the UI confused me
<lifeless> its the 'call graph'
<lifeless> I'm just testing the fix now
<lifeless> igc: rev 4544 should be good
<lifeless> igc: all review feedback applied; bugs fixed, path2id hopefully faster
<igc> lifeless: cool. I'm wrapping up a patch and have a medical appointment after lunch. I'll take a look after that
<lifeless> igc: cool. it would be great if we can get this assessed before ~3, when my day ends.
<lifeless> (I'm still being woken up silly-early by neighbours :( )
<igc> lifeless: my medical appt is 2.40 so I suspect before 3 is unlikely sorry
<lifeless> ah well
<lifeless> monday then
<lifeless> fullermd: ping :) where should I file a bug about lt2.x ?
<pattern> according to this tutorial http://doc.bazaar-vcs.org/latest/en/tutorials/using_bazaar_with_launchpad.html#publishing-your-changes
<pattern> i can push my changes to launchpad via: "bzr push lp:~team-name/project-name/branch-name"
<pattern> but what if my project is not part of any team?
<lifeless> replace team-name with your name
<lifeless> (lp usercode actually)
<lifeless> lunching
<pattern> sorry, i don't understand the last two lines of what you said
<pattern> lp usercode?  lunching?
<pattern> was that meant in answer to my question?
<pattern> or were you anouncing you were going out to lunch? :)
<garyvdm> pattern: I think so
<spiv> pattern: he's going out to lunch :)
<pattern> ok... just checking :)
<garyvdm> so I would push to lp:~garyvdm/qbzr/.///
<spiv> pattern: but his 2nd last line was to you :)
<garyvdm> so I would push to lp:~garyvdm/qbzr/....
<spiv> pattern: i.e. I generally push to lp:~spiv/bzr/branch-name
<pattern> got it
<pattern> thank you everyone
<spiv> The ~name at the start controls who Launchpad grants write access to.  If it's a team, the whole team can update the branch.  If it's just a person, then only that person.
<jml> (for now)
<pattern> so how can people submit patches to projects that aren't part of a team?
<pattern> (assuming they don't control the branch)
<garyvdm> pattern: They can request a merge
<garyvdm> by the person that does
<garyvdm> They do that by pushing to a branch in their own name
<garyvdm> If you do have more than one person that needs to push to the mainline of a project, it's easy to get a team created.
<pattern> my project is very small right now
<pattern> i don't think i need a team
<garyvdm> jml: You got me to bite - tell me more...
<pattern> just trying to understand how i can get contributions from others
<mwhudson> garyvdm: i think jml is talking about package branches
<mwhudson> where it will become a bit more subtle for the official branches
<jml> what mwhudson said.
<spiv> pattern: they can email you with the contribution.  There's a "bzr send" command that will even make a mail with the new bzr revisions as an attachment for you.
<spiv> pattern: or you could "bzr merge" (or "bzr pull") from their branch if they've published it somewhere (e.g. on Launchpad).o
<spiv> pattern: Launchpad has a merge proposal tracker as well, so you could ask contributors to use that to submit patches.
<spiv> pattern: basically, the two questions are "how do you want contributors to contact you about their contributions?" (e.g. email to a particular address) and "how do you want to receive the contributions?" (e.g. a bundle in an email from bzr send, or by using a branch they've published somewhere, etc.)
<pattern> that merge proposal tracker sounds interesting
<pattern> where can i find out more about it?
<spiv> pattern: https://help.launchpad.net/Code/Review is probably a good starting point.
<garyvdm> pattern: https://help.launchpad.net/,  https://help.launchpad.net/Code/Review
 * spiv also goes to lunch :)
<pattern> thank you very much
<lifeless> jml: I think its really really clear as it is today
<lifeless> jml: When you look at DACL in windows and posix they are generally a lot more complex and harder to understand
<igc> lifeless: initial benchmarking looks much better thanks
<jml> lifeless,
<lifeless> igc: cool
<igc> lifeless: I'll run the full benchmark over lunch (it takes 90 minutes)
<lifeless> jml: (just saying)
<igc> thanks to the 'speed' of branching outside a repo
<jml> lifeless, yeah. it _is_ less clear to have people with implicit write permissions, but it's something the distro community really really want, and we think the loss of clarity is worth it.
<lifeless> jml: for the distro official branches I totally agree
<lifeless> well
<lifeless> I totally get the need, and that we need to support that
<lifeless> I'm not 100% on board the particular way to address that
<lifeless> that said, one way to phrase it would be that distro official branches have an implicit per-branch team that we just elide from the namespace
<lifeless> which is...roundabout
<jml> yes.
<lifeless> oh, ETA?
<jml> difficult to say.
<jml> it's a one or two day patch, and my highest priority task.
<jml> so probably in two or three weeks time.
<lifeless> Actually, I meant you, at my place.
<lifeless> I'm assuming that the changes for the distro are either not applicable, or at least optional, for other branches ;)
<jml> ~6:30pm?
<lifeless> sure, earlier is fine if you like; later and I'll be climbing up the walls in search of food
<jml> I'll try to get there earlier, but I doubt it'll happen -- there's a lot to do before then.
<jml> lifeless, bug 397705 is targeted to 1.17. Is there still more stuff to land for 1.17?
<ubottu> Launchpad bug 397705 in bzr "inventory delta consistency checks are missing known problems and not universally applied." [Critical,Fix committed] https://launchpad.net/bugs/397705
 * RenatoSilva is thinking about suggesting his boss to leave CVS and start using Bazaar...
<lifeless> jml: there is more on that branch
<lifeless> jml: it doesn't have to go in 1.17; its waiting review at the moment.
<lifeless> jml: It probably speeds up a bunch of things (while slowing down others just a data, and becoming faster at the same time)
<jml> lifeless, I don't grok the bit in parens.
<jml> spm, how does bazaar's pqm spell the name of the 1.17 branch?
<spm> jml: do you mean: https://code.edge.launchpad.net/~bzr-pqm ?
<jml> not quite
<jml> merge http://bazaar.launchpad.net/~jml/bzr/1.17-build-updates lp:bzr/1.17
<jml> Command failed!
<jml> All lines of log output:Sender not authorised to commit to branch lp:bzr/1.17
<jml> that's what I get when I try to land a branch to 'lp:bzr/1.17'
<spm> ah right, one sec
<igc> lifeless: starting the full benchmark now. Still issues with the test suite btw - see the associated bug for details.
 * igc lunch & medical stuff - bbl
<spm> jml: bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/1.17
<jml> spm, thanks.
<lifeless> igc: thanks
<lifeless> jml: or http://<same>
<lifeless> igc: thanks
<lifeless> igc: I've switched context to another bug but I'll fix those up later
<lifeless> igc: I'm sure any other changes won't have performance implications
<lifeless> jam: abentley: could you please move the conversation out of bug 390563? That bug is for a totally different cause, and *still* hasn't had all its code changes landed.
<ubottu> Launchpad bug 390563 in bzr "absent factory exception from smart server when streaming 2a stacked branches" [Critical,In progress] https://launchpad.net/bugs/390563
<abentley> lifeless: I don't want to disrupt the conversation.
<lifeless> abentley: I'd be happy to copy over the last few posts to the correct bug if that would help
<lifeless> its a shame malone doesn't provide facilities to remix bug conversations
<abentley> lifeless: Nevermind, I can drag it to the list if I have more questions for jam.
<lifeless> abentley: I don't want to prevent important discussions; I'm just worried that its making it harder to have the discussion about delta generation thats also on the same bug :(
<abentley> lifeless: I understand.
<jml> committing a tarball of bzr to a bzr branch
<jml> no irony at all
<lifeless> jml: buildout?
<jml> yeah.
<lifeless> I'm very unconvinced
<garyvdm> Can any one word this more elegantly:
<garyvdm> "You are reverting all changed files. Are you sure that you don't also want to revert pending merges?"
<garyvdm> Warning for when a user tries to revert all file, and not pending merges from qrevert.
<lifeless> perhaps
<lifeless> "You are reverting all changed files but leaving some pending merges. Do you want to [also revert the merges] [revert the changed files] [cancel the revert]"
<lifeless> tweaking
<lifeless> "You are reverting all changed paths without also reverting pending merges. Do you want to [also revert pending merges] [revert all changed paths without merges] [cancel the revert]"
<garyvdm> "You are reverting all changed paths without also reverting pending merges. Continue?" [Yes] [No]
<garyvdm> The ability to chose the other option is provided by the dialog: http://imagebin.ca/view/nys-K4s.html
<garyvdm> Thanks lifeless. - That sound much better.
<lifeless> my pleasure
<garyvdm> Morning amanica. Up early!
<amanica> garyvdm: morning, couldn't sleep.
<amanica> you too btw. wasn't gonna say something
<garyvdm> I'm working night shift - then I hack after work and sleep during the day.
<amanica> I blame lifeless, for complaining about stuff I did :)
<amanica> ah ok
<amanica> once your mind keeps on drafting that mail, its over
<davidstrauss> All the Bazaar-nics should appreciate this: http://www.chapterthree.com/blog/josh_koenig/project_mercury_preconfigured_drupalvarnish_ec2_ami
<davidstrauss> It's a Drupal-based AMI that auto-updates using Bazaar
<lifeless> sweet
<lifeless> oh wow
<lifeless> don't you love OMG bugs
<poolie> mm, sometimes
<poolie> lifeless: did you want to talk about anything in particular wrt hpssvfs?
<lifeless> no, I was making a meta comment; that the patch is trivial enough to just land, but if discussion is sought perhaps the list works better. I don't know - still tossing ideas around
<lifeless> I have a rathole bug at the moment
<lifeless> revert -> tree transform -> iter_changes -> find_ids_across_trees
<poolie> ah ok
<poolie> will let you back to it
<poolie> going into code myself if i'm lucky...
<lifeless> abentley: are you around still? Do you have an opinion on tree.has_id for missing paths?
<lifeless> \o/ got that bug fixed
<lifeless> amanica: you may be interested in https://bugs.edge.launchpad.net/bzr/+bug/129880
<ubottu> Ubuntu bug 129880 in bzr "Can't bzr rm a directory that contained a modified+emigrated file" [Medium,Confirmed]
<vila> hi all
<amanica> lifeless: thanks, sure, I'll append it to my evergrowing todo list
<amanica> good morning vila
<vila> amanica: Hey !
<igc> back
<igc> hi vila!
<vila> igc: hi
 * spiv -> gone
<vila> amanica: ping
<amanica> vila: pong
<vila> I see you wanted to work on bzr mv again, so I wanted to talk a bit about some problems I encoutered on OSX and that seem to be related
<vila> amanica: roughly, If unicode paths are used and BzrMoveFailedError and derived classes are used, things go wrong
<vila> amanica: So if you touch that code again, make sure to add tests with unicode paths, and if you can test that on OSX, that would be even better, but I don't know if you have that available :)
<jml> lifeless, leaving now.
<amanica> vila: I'll make a note, thanks. I only have ubuntu
<vila> amanica: ok, thanks :)
<lifeless> jml: cusoon
 * igc dinner
<jelmer> mwhudson: hi
<jelmer> mwhudson: do you have any remaining failing imports from git?
<mwhudson> jelmer: i had one that failed because of submodules
<mwhudson> jelmer: i guess i should be systematic about it at some point
<mwhudson> not at 2100 on a friday tho
<jelmer> :-)
<asabil> jelmer: I have a failing bzr branch with for a git repo
<jelmer> asabil: what git repo?
<jelmer> asabil: and what's the error?
<asabil> git://github.com/280north/cappuccino.git
<asabil> invalid revision None
<asabil> couldn't get a complete traceback
<asabil> bzr: ERROR: The branch git://github.com/280north/cappuccino has no revision None.
<asabil> that's the exact error
<jelmer> asabil: I can reproduce it, please file a bug
<asabil> jelmer: ok will do thanks
<asabil> jelmer: any idea about why bzr-rebase would fail with this:
<asabil> NoSuchRevision: KnitPackRepository('file:///home/asabil/main-1.14/.bzr/repository/') has no revision ('stian.selnes@tandberg.com-20090610132048-1mk36vuwwxv7zz0c',)
<jelmer> asabil: not without context
<asabil> jelmer: just rebasing a branch on top of another one
<asabil> nothing really specific
<asabil> bzr check and bzr reconcile are running fine
<asabil> jelmer: here is the traceback: http://bzr.pastebin.com/d5186bfe2
<LarstiQ> jelmer: I notice you released bzr-svn 0.6.3 but I didn't see a release mail, want me to write and send it to bazaar-announce?
<jelmer> LarstiQ: please do
<jelmer> LarstiQ: and thanks for doing so
<LarstiQ> jelmer: ETA tonight or tomorrow noon/afternoon
<jelmer> LarstiQ: np, thanks again
 * jelmer waves from DebCamp
<LarstiQ> jelmer: ooh, say hi to Dato
<LarstiQ> and maybe more when I figure out they're there ;)
<mgedmin> so, bzr can't handle non-ascii content, or what?
<mgedmin> https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/400670
<ubottu> Ubuntu bug 400670 in bzr "bzr log -p UnicodeDecodeError" [Undecided,New]
<jelmer> LarstiQ: will do, if I can figure out who dato is :-)
<fullermd> mgedmin: Works fine for me.
<mgedmin> newer bzr?
<spiv> lifeless, jml: hooray for testresources!
<mgedmin> fullermd: did you try with lp:zodbbrowser?
 * spiv -> zzz
<fullermd> Exactly the branch and rev in the bug.
<mgedmin> which bzr version?
<lifeless> fullermd: so, up for some yak shaving?
<lifeless> spiv: thanks
 * mgedmin checks if he still has a copy of bzr trunk
<jml> spiv, thanks :)
<fullermd> The error message says it's trying to convert it to ascii, which suggests bzr isn't liking your locale.
<abentley> jelmer: Am I right thinking that bzr-git doesn't support submodules and won't support them until Nested Trees works?
<jelmer> abentley: yep
<fullermd> (though you are a few versions back, and there may have been a bug fixed...   none comes to mind)
<fullermd> lifeless: I left my clippers in my other pants.
<fullermd> Too much work and errands today to have time for much...
<mgedmin> uh oh the progress bar hints that I'll wait a long time to get an up-to-date bzr.dev ...
<mgedmin> unless it's not a progress bar but a simple spinner that looks like it's a progress bar stuck at <5%
<fullermd> It'd certainly be quicker to grab a tarball of something (the 1.17rc maybe).
<lifeless> fullermd: (where should I record 'FreeBSD doesn't have autoconf released in the last year-or-two')
<fullermd> lifeless: The PR form is at <http://www.freebsd.org/send-pr.html>.
<lifeless> fullermd: will it be better if you file it?
<fullermd> Probably not.  ade@ is the main person who handles autotools-related stuff, but I haven't seem him pipe up in a few months.
<lifeless> http://lists.freebsd.org/pipermail/freebsd-ports/2009-May/054515.html
<lifeless> oh wow... "Thank you for the problem report. You should receive confirmation of your report by electronic mail within a day."
<lifeless> fullermd: ok, http://www.freebsd.org/cgi/query-pr.cgi?pr=136867
<lifeless> fullermd: if you have anything to add that would be great
<mgedmin> nice, launchpad somehow managed to create the bug twice, with different numbers, and they're already marked as duplicates
<fullermd> It likes some bugs so much, it makes a backup.
<amanica> lol
<mgedmin> and yes, the bug is gone in bzr.dev
<pygi> yay
<pygi> roundup now kinda support bzr
<pygi> :D
<jelmer> pygi: \o/
<pygi> not tested, and probably doesn't work with my buggy code, but oh well :P
 * hey bzr or cvs, that's the question
<pygi> lol
<pygi> jelmer, when will we complete what we started at UDS?
<jelmer> pygi: at some point :-P
<pygi> aha, so we'll do it during next sprint? xD
 * jelmer is at DebCamp at the moment, trying to get some Samba packages into the right shape
<ronny> sup
<jelmer> hey ronny
<ronny> jelmer: europython was a blast, but the 2 weeks since it have been very unproductive for me
<Kobaz> ie: what i really want to know... say i have a million rows in a table with a view on it, with no WHERE conditions.... i select from the view, with a WHERE.... will it take forever, and do a select all, and then apply the where later... or does it do it all at once, and make use of the indexes, and all that
<Kobaz> er
<Kobaz> wrong window
<pattern> i've been reading about how to use bazaar with launchpad and i have some questions..
<pattern> let's say i just created my own project on launchpad, then did "bzr init" on my own local machine, and added and committed some source to it...
<pattern> then i "bzr launchpad-login me" and "bzr push lp:~me/myproject/mybranch"
<pattern> then, when i make some changes on my local copy of the code and type "bzr commit", will those changes automatically be uploaded to my branch on launchpad?  or will i have to do another push to get them there?
<jpds> pattern: You always have to push.
<pattern> i see
<jpds> This way, you can commit multiple changes to a branch (for a completely new feature for example) and then push it all to a new branch for merging.
<pattern> that makes sense
<pattern> now, on another subject.. let's say someone else has copied my branch from "lp:~me/myproject/mybranch" and made some changes, then pushed it to "lp:~him/hisproject/hisbranch", and notified me that he'd like to merge the changes in my project
<pattern> how would i actually go about doing that?
<jpds> bzr merge lp:~him/hisproject/hisbranch
<pattern> that would merge with the code on my machine?
<jpds> Yep.
<pattern> i see
<pattern> cool
<jpds> And if there are any conflicts, bzr will tell you.
<pattern> a nice and elegant way to do it
<pattern> thanks for your help, jpds
<jpds> pattern: No problem.
<lifeless> pattern: you need to do a commit after the merge to record it
<lifeless> jpds: I find the above is worth mentioning when people first encounter merge :)
<jpds> lifeless: Ah, yes. :)
<pattern> thank you
<pattern> that's good to know
<fullermd> lifeless: Funny...
<fullermd> lifeless: http://lists.freebsd.org/pipermail/freebsd-ports/2009-July/055841.html
<fullermd> So I guess lt2 is already in test.
<lifeless> fullermd: oh cool
<lifeless> fullermd: (care to test ? :P)
<fullermd> Hey, just 'cuz I run the development head of my OS and window manager and version control system, doesn't mean I'll try ANY old bleeding edge  :p
<lifeless> :P
<lifeless> I just want to know if libcpuinfo builds
<lifeless> I could generate a make dist tarball for you
<fullermd> Well, with those hacks to get along with lt 1.5, it does.
<lifeless> ok cool
<lifeless> that should be totally innocuous then
<fullermd> Yah.  I wouldn't be blown away by shock if the lt switch caused breakage, but I would be a little surprised.
<lifeless> jam: if you're still here; .. a quick eyeball on https://code.edge.launchpad.net/~lifeless/bzr/bug-367632/+merge/8928 would be great
<jfroy> The 1.17 branch's version is set to 1.18dev :/
<pattern> when i do a push from a branch on my machine to launchpad, will a record of every revision i've committed (and the associated log messages) go with it?
<pattern> or does launchpad just get the delta between the last pushed revision and the newly pushed revision?
<fullermd> pattern: Those revisions are what push pushes.
<lifeless> pattern: bzr only sends new data
<lifeless> pattern: but you end up with all the revisions on launchpad
<pattern> i see
<pattern> thanks again
#bzr 2009-07-18
<pattern> is it necessary to specify a branch name when doing a push to launchpad, or is "bzr push lp:~myname/myproject" enough to push it to the trunk?
<lifeless> pattern: specify the branch
<lifeless> pattern: if you pass --remember, bzr will remember the branch and you can then just 'bzr push' after that
<pattern> ah, ok
<pattern> thank you
<bob2> hm, bzr-git overrode co and makes it fail "bzr: ERROR: Push is not yet supported for bzr-git. Try dpush instead."
<lifeless> for everything?
<bob2> hm, seems to happen if cwd is inside a git checkout (however deep)
<lifeless> file a bug
<bob2> yeah, just reproducing in /tmp
 * SamB wonders if it's possible to run bzr under gud/Emacs
<Toksyuryel> Well, from my understanding it's turing-complete, so it should in theory be possible
<jml> conflict behaviour wrt pyc files in otherwise empty to-be-removed directories sucks.
<wgrant> jml: That confused everyone in my team when we moved to bzr.
<wgrant> Took a while to work out what was going on...
<jml> yeah.
<jml> it's a pain.
<RAOF> I suspect bzr-git isn't supposed to consume 2GiB memory when dpushing.
<LarstiQ> I suspect your'e right :)
<jelmer> bob2: are you perhaps branching into a git repository?
<ndurner> Hi
<DaffyDuck_> So, have I understod bazaar correctly: Parents know nothing about theit child branches -- only the children know who their parent is?
<LarstiQ> DaffyDuck_: yes, but parents can be replaced.
<LarstiQ> DaffyDuck_: all branches are equally independent, multiple different relationships can exist (submit, parent, push, public, etc)
<DaffyDuck_> LarstiQ: So you essentially tell the child branch to "re-attach" to another parent?
<LarstiQ> DaffyDuck_: yes, although "attached" gives impression of a stronger bond then there is.
<LarstiQ> DaffyDuck_: it's just the default location for several operations, like pull.
<DaffyDuck_> I understand.
<DaffyDuck_> Is there a concept of "switching" a branch from one to another, you check out the code to a new directory?
<DaffyDuck_> (I may be confusing people with my terminology, but I'm new to bazaar, so be patient with me).
<ndurner> What's the "best" reasonably stable storage format?
<LarstiQ> DaffyDuck_: switching a working tree between branches you'd do with `bzr switch`
<LarstiQ> DaffyDuck_: personally I prefer just cding around in the filesystem
<SpinachHead> when I used revert to go back to say -r 1  it still shows the files from the newer versions when I export the files....    I don't know why that is.  How would I revert to a previous version and then export it in the state it the project was in in version 1?
<SpinachHead> oh, wait I guess when I revert to an older version I need to issue commit ...
<lifeless> export doesn't export the current stuff on disk
<lifeless> it exports the current commit
<lifeless> so you want export -r <X> ...
<SpinachHead> okay, thanks
<wildfire> Hi, I am trying to configure a repository to send email everytime a commit occurs
<wildfire> but am not succeeding
<wildfire> bzr plugins list email as being installed
<wildfire> but how do I configure the address that should be sent to?
<LarstiQ> wildfire: post_commit_to iirc, if `bzr help email` doesn't mention, have a look at its README
<wildfire> LarstiQ, the readme says 'post_commit_to' but where / how do I configure that setting is what has me confused
<LarstiQ> wildfire: ah, ok
<LarstiQ> wildfire: one of several places, depending on what you want to accomplish
<LarstiQ> wildfire: I use ~/.bazaar/locations.conf to manage that, but ~/.bazaar/bazaar.conf or .bzr/branch/branch.conf are other candidates
<LarstiQ> wildfire: also see `bzr help configuration`
<wildfire> LarstiQ, thanks - will check those out
<LarstiQ> wildfire: locations.conf is good for pattern matching whole hierarchies of branches
<wildfire> LarstiQ, thanks for you help, have now got it working
<LarstiQ> wildfire: cool
<LarstiQ> jelmer: bzr-svn 0.6.3 uploaded to bzr-beta-ppa, I'll copy them over to bzr-ppa tomorrow if I don't see any complaints
<LarstiQ> jelmer: https://edge.launchpad.net/bzr-svn/0.6/0.6.3 doesn't exist yet, but I don't have access to create it
<jelmer> LarstiQ: I wonder what contact I need to change for that
<LarstiQ> jelmer: don't know if it would help, but I'm not in ~bzr-svn
<jelmer> LarstiQ: you are now >-)
<parolang> Hello, are any of the developers here?
<jelmer> parolang: hi
<parolang> Hey, I wanted to know if you guys were interested in the documentation being in texinfo format?
<parolang> Personally I would like, and would help with that, but only if you guys were interested.
<jelmer> parolang: Perhaps better ask on the mailing list ? I would expect there to be some interest in having the docs available in texinfo, but there aren't a lot of developers around at the moment.
<parolang> Yeah, I'll try that.  Right now it's in some python format isn't it?
<jelmer> yeah, it's in restructuredText
<parolang> The main advantages to texinfo are two: better pdf/printed output, and a conveniant reader within emacs.
<parolang> Do you know if that outputs in texinfo?
<jelmer> parolang: no idea, sorry
<parolang> okay, thanks anyway
<ronny> jelmer: have you seen the stuff about the pythonic fs api's? (there was a talk on europython)
<ronny> jelmer: i intend to use that as api for accessing revisions/building commits in anyvc, so i'll probably end up inventing it for a set of vcs's
 * SamB wonders where to get a recent bzr-gtk deb
<jelmer> SamB: unstable has one
<SamB> jelmer: ah, nice
<jelmer> ronny: no, haven't seen that
 * SamB hadn't looked very hard yet
 * SamB wishes aptitude wouldn't thrash so much
<jelmer> ronny: is there a pep or something like that?
<ronny> jelmer: currently they are a separate set of api's, not yet proposed for inclusion in python
<ronny> the key part is, the api looks reasonable and can be implemented independ of the base lib
<ronny> http://eagain.net/blog/ is a good starting point i think
<ronny> brb, forgot to feed the rabbit
<ronny> re
 * SamB wonders what kind of support debian packaging has for running tests
<jelmer> SamB: how do you mean?
<SamB> jelmer: well, it would be nice if the tests for e.g. subunit were run as part of the build, so that e.g. having a wrong XS-Python-Version: in debian/control would be caught ...
<jelmer> SamB: In this particular case that wouldn't help. python2.3 isn't installed by default
<SamB> hmm.
<SamB> jelmer: hmm. true, not in the build-deps...
 * SamB wonders what to blame this on
<jelmer> SamB: You have python2.3 installed and subunit is currently setup to be pre-compiled for all python versions that are installed on the system
<jelmer> SamB: I'm uploading a new version that will only do so for python 2.4 and later
<SamB> jelmer: btw, you don't need the python-all-dev dependancy in debian/control, according to http://wiki.debian.org/DebianPythonFAQ
<SamB> which would make it easier for some of us to contribute merge requests ;-)
<jelmer> SamB: fixed now as well
<jelmer> SamB: how do you mean?
<SamB> jelmer: for the packaging, I mean
<SamB> it would be irresponsible to send you a patch that I hadn't tested, wouldn't it?
<SamB> and it's nicer not to have to reinstall python 2.4 just to satisfy some overzealous build-dep
<jelmer> SamB: yes, but nothing stops you from removing that unnecessary dependency as well >-)
<SamB> true
<jelmer> anyway, both should now be taken care of
<SamB> I was about to ask if there's a way to commit just some of the changes in a file to that end, actually ;-)
<SamB> but then I saw what you'd said about how running the tests at build time wouldn't have helped
 * SamB is a bit amused that he apparantly doesn't have what it takes to satisfy the "automake" build-dep, given what he sees when he types automake<TAB> ;-)
<SamB> actually, I'm almost surprised there *is* an automake package
<SamB> why not just have packages for each major.minor?
<SamB> I mean, that's almost exactly what we have anyway ...
 * SamB wonders why bzr builddeb is alarmed that he can't sign a package as jelmer
 * SamB wishes something would run "bzr selftest" with all the Debian bzr packages installed, regularly
<SamB> (at least "bzr selftest --list" would be good)
<SamB> bzr-builddeb's tests are importing something that does not even exist
<jelmer> SamB: I posted a patch to the bzr list recently that should be the first step towards that
<jelmer> SamB: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20090513223140.GB13847%40vernstok.nl%3E
<lifeless> jelmer: hi, I just reviewed the patch I just saw, it looks like a step backwards, to our 2003 loading code or so
<jelmer> lifeless: a step back in what sense?
<lifeless> likelyhood of bugs, strange interactions, and the ability to clearly describe what goes on when corner cases exist.
<lifeless> we used to use find_module and imp_module
<lifeless> it was very complex
<lifeless> now we just import
<lifeless> much simpler
<jelmer> yeah, but that makes it impossible to load individual modules..
<jelmer> s/modules/plugins/
<lifeless> 'import bzrlib.plugins.foo'
<lifeless> there, loaded.
<jelmer> lifeless: it doesn't allow you to specify a path to a plugin, for example
<jelmer> (which is what I'm after)
<lifeless> Ah! well thats a totally different thing, isn't it :)
<SamB> ... in what context would this import appear?
<lifeless> SamB: at the moment there is a loop in the function that 'loads all plugins' that well, loads all the ones it found
 * SamB is pretty sure he doesn't have a config file with 'import bzrlib.plugins.svn' in it anywhere ;-)
<jelmer> lifeless: yeah, sorry. I knew what I meant but that's not what I said :-)
<lifeless> I'd like us to add a filter to that, which allows saying 'only load svn' or 'load all but svn'
<jelmer> s/said/wrote/
<jelmer> man, this is complicated :-P
<jelmer> lifeless: I'd like to be able to load plugins from arbitrary paths
<lifeless> I'm totally pro that, because: we say to people 'don't load that plugin and see if things get better'
<lifeless> jelmer: what name would you give the plugin in this arbitrary path?
<SamB> lifeless: presumably the name would either come from the last component of the path, or be given along with the path
<lifeless> SamB: jelmer's code, I'd like jelmer's answer :P
<SamB> I thought he hadn't written that bit yet
<jelmer> lifeless: Either the user should specify the name, or perhaps we could e.g. use bzr_plugin_name from setup.py if nothing was specified.
<lifeless> jelmer: but setup.py is for uninstalled plugins!
<SamB> what is this setup.py you speak of ?
<jelmer> lifeless: well, perhaps if we end up putting that data in an info.py file or something.. :-)
 * SamB would think __init__.py would be the place
<lifeless> jelmer: nearly-arbitrary paths are supported by BZR_PLUGINS_PATH already; why do you need to be more specific than that?
<jelmer> lifeless: that's the parent path of the plugin
<lifeless> SamB: thats a race condition, can't get data out of __init__.py without loading it
<lifeless> jelmer: yes, it is.
<lifeless> jelmer: *why isn't it specific enough for you*
<jelmer> lifeless: it means I have to create a parent plugin directory with a symlink every time.
<lifeless> every time what?
<lifeless> Users install plugins pretty rarely
<SamB> lifeless: and you can get data out of some submodule without loading it?
<jelmer> lifeless: every time I want to run the testsuite of a plugin
<lifeless> maybe 0.0001 of the times they install plugins
<lifeless> SamB: I think you've lost track of the discussion :)
<SamB> lifeless: maybe you should just use a text file?
<lifeless> SamB: plugins are imported into bzrlib.plugins.NAME
<SamB> lifeless: I know *that*
<SamB> I've seen enough tracebacks to have figured that out by now, I think ;-)
<lifeless> SamB: so, we can't use __init__ to figure out NAME :P
<SamB> lifeless: ah. point.
<lifeless> if the plugin even has a directory
<SamB> just require that ;-)
<lifeless> thats unpythonic
<SamB> but where would they put the README if they didn't have a directory?
<lifeless> at the moment, and we worked hard to get it, bzr plugins are 'just python packages/modules in bzrlib.plugns'
<lifeless> SamB: in the module docstring
<SamB> and, uh, how do you create a bzr branch which just stores a file ?
<lifeless> SamB: you probably don't, but thats a different discussion; people do create trivial single file plugins.
<lifeless> jelmer: so, I think the problem is, you're saying 'how do I load an arbitrary python module/package without changing the python path'
<lifeless> jelmer: and the answer is you don't.
<SamB> well, just taking the name from the last component of the path, if the user doesn't specify one, should still work okay shouldn't it?
<lifeless> so we either need to change the identity that "bzr plugins are 'just python packages/modules in bzrlib.plugns'"
<lifeless> SamB: If that would work, setting BZR_PLUGINS_PATH + --only-plugins=svn, would work.
<SamB> lifeless: ... or use import hooks to resolve their locations?
<lifeless> SamB: that is indeed another possibility
<jelmer> lifeless: I don't follow what the particular problem is with that though
<lifeless> jelmer: which 'that'
<lifeless> too many recent subjects
<SamB> yeah ;-)
<jelmer> lifeless: with loading an arbitrary module/package without changing the python path.
<jelmer> lifeless: Are you concerned about the readability of the code, the ui, other issues?
<naoki> Hi
<naoki> I tried "bzr init-repo --git .git" "bzr pull git://git.sourceforge.jp/gitroot/msgpack/msgpack.git"
<naoki> bzr pull stopped with "NotCommitError"
<jelmer> naoki: you'd probably want "bzr branch git://git.sourceforge.jp/gitroot/msgpack/msgpack.git"
<jelmer> naoki: otherwise the behaviour would be the same as "git clone git://git.sourceforge.jp/gitroot/msgpack/msgpack.git .git"
<naoki> I want to try to pushing local git->remote git  with bzr-git.
<naoki> "git clone git://git.sourceforge.jp/gitroot/msgpack/msgpack.git" works fine.
<jelmer> naoki: in that case, probably try creating a local git branch first
<jelmer> "bzr init --git foo; cd foo; bzr pull git://..."
<jelmer> naoki: pushing between git repositories should generally work with bzr-git but probably isn't one of the best tested code paths. if you hit any issues, please file bugs.
<jelmer> lifeless: still there?
<lifeless> jelmer: I'm worried about conceptual clarity; code reuse; debuggability; compatibility with eggs and other extensions; documentation
<jelmer> lifeless: ok
<lifeless> all of where issues when we had a very path focused loader in the past
<lifeless> I _really_ don't want to go back to those days
 * SamB wonders how to get http://bundlebuggy.aaronbentley.com/project/bzr/request/<E1MQZOB-0003MV-Id%40hydrogen> fully-approved ...
<SamB> and, hey, aren't <> banned from URLs?
<lifeless> they are in the escape set, yes
 * SamB wonders why mozilla unescaped them
<lifeless> perhaps I'm wrong, std66 will say
<SamB> std66 won't tell me why mozilla does this or that foolish thing ...
<lifeless> it will tell you whether < can be unescaped in a URL :P
<lifeless> its not in unreserved
<lifeless> so nor is it a delimiter
<lifeless> it must be escaped
<jelmer> lifeless: thanks for clarifying. I'm not totally convinced, but I also don't think this is a particularly useful feature for a lot of users other than me so perhaps it's better off in a plugin.
<lifeless> jelmer: You could create a plugin that acts as a symlink, replacing itself on load :P
<lifeless> jelmer: While I understand the use case, I still don't understand why its needed - I don't seem to have the problem you do
<jelmer> lifeless: When I work on plugins I tend to work in feature branches, and I often work on multiple features in parallel.
<lifeless> jelmer: do you use bzr switch?
<jelmer> lifeless: no, I'm not a big fan of lightweight checkouts because I have to change directories to manage branches
<lifeless> jelmer: what do you mean?
<lifeless> serious question - we have this big UI angst at the moment, and switch seems to be a key component in addressing a bunch of issues
<lifeless> if its worse for heavy users like you, thats a problem
<jelmer> lifeless: sorry, was taking a moment to think about what the core of the problem is for me
<lifeless> thank you ;)
#bzr 2009-07-19
<jelmer> lifeless: I think it comes down to two things: in order to do branch management when using a lightweight checkout you have to change directories (since the branches are in a different location, you have to "cd ../branches && bzr branch branch-foo branch-bar && cd ../wt && bzr switch branch-bar" and "bzr switch" is too slow
<lifeless> jelmer: ok
<lifeless> so the former - heres what I do
<lifeless> bzr init-repo --no-trees proj
<lifeless> cd proj
<lifeless> bzr branch/init trunk
<lifeless> bzr checkout --lightweight trunk working
<lifeless> ln -s $(pwd)/working ~/.bazaar/plugins/proj
<SamB> hmm, isn't there a "bzr switch -b" or something lately added?
<lifeless> SamB: yes
<lifeless> today though, I use
<lifeless> bzr push ../new-branch; bzr switch new-branch
<lifeless> so its not ideal, but it is pretty easy
<SamB> not bad
<jelmer> lifeless: ah, I hadn't considered "bzr push"
<lifeless> jelmer: well, can also spell 'bzr branch . ../new-branch'
<lifeless> or bzr branch ../trunk ../new-branch, if I want to be absolutely sure about provenance
<jelmer> lifeless: but (now that we're talking about UI) I still consider this a big hassle compared to colocated branches
<lifeless> jelmer: switch _should_ be very fast. please file bugs if its slow
<lifeless> jelmer: typing .bzr/branches/new-branch would be equally awkward, I should think.
<lifeless> jelmer: I think the big UI win of colocated branches isn't the colocation, its the search-path and location glue
<lifeless> this isn't to say I don't like colocated branches/git style branches; just that I'm trying to really understand what makes things good
<jelmer> lifeless: yeah, perhaps git style branches is a better description than colocated branches.
<jelmer> lifeless: the setup you did is nontrivial (more than one command)
<jelmer> lifeless: and the combined action of creating and switching to a new branch is more than one command
<lifeless> so, we're trying to plan a better UI before making many random changes
<lifeless> jelmer: but have you seen jam's switch -b feature?
<jelmer> lifeless: it breaks looms :-/
<SamB> lifeless: please contribute any tips to GitStyleBranches ;-)
<jelmer> lifeless: but no, I hadn't. That does indeed make the second bit easier
<lifeless> jelmer: I'll fix looms up monday
<lifeless> I wonder if perhaps it should be in switch --new or something
<jelmer> lifeless: Yeah, --new would probably be more intuitive to new users
<lifeless> did it get into 1.17?
<jelmer> lifeless: -b does remind me of the git argument, but other than that it doesn't make much sense
<jelmer> lifeless: as far as I can tell it's only in  bzr.dev
<jelmer> lifeless: it's not in rc1 at least
<SamB> jelmer: well, the long name can be meaningful
<SamB> short names are often pretty crazy, so probably won't bother people
<lifeless> I don't think thats a good reason to use a crazy short option
<SamB> well, it's not quite crazy either ...
<SamB> it actually *does* do a "bzr branch" under the covers, doesn't it?
<lifeless> bzr branch?
<lifeless> yes
<SamB> so how is -b a crazy short name for the flag?
<lifeless>      branch --branch
<lifeless> would be the long version, if -b stands for branch
<SamB> eh?
<SamB> I thought it was "switch" we were talking about, sorry
<lifeless> for switch I proposed --new
<lifeless> in a loom you probably want a new thread
<lifeless> in a pipeline a new pipe at the current place {like looms}
<SamB> who should I talk to about bzr-fastimport?
<jelmer> SamB: ianc
<SamB> hmm, is there some command-line equivalent of BZR_PDB=1 ?
<bob2> jelmer: yes, branching into a dir inside a git repo
<jelmer> SamB: not that I'm aware of
<SamB> 'twould be useful for running bzr under gud, I think
<jelmer> bob2: that's the equivalent of trying to push from bzr into git, which doesn't work yet
<jelmer> SamB: gud?
<SamB> jelmer: basically, s/gud/emacs/
<SamB> gud is the bit that integrates debuggers into the UI
<SamB> so, like, you'd see stuff in the left margin
<bob2> jelmer: cd gitmanageddir/something/somethingelse ; bzr co /brbranch ?
<lifeless> SamB: what do you mean command-line equivalent?
<SamB> lifeless: I mean, an argument
<SamB> that is, a flag
<lifeless> no
<SamB> for some reason M-x pdb doesn't like it if I enter an environment-variable setting before the command to run :-(
<mtaylor> lifeless: question on MOTU process...
<mtaylor> lifeless: there are two different processes, one for packages that are in ubuntu already, and one for ones that aren't... do packages that are auto-imported from debian but have no truly ubuntu specific package count as the former or the later?
<lifeless> uhm
<lifeless> there aren't really two processes
<lifeless> or I don't know what you mean
<lifeless> are you talking about new packages, or changes to an existing package
<mtaylor> lifeless: well, that's the question - if the package is in but only via automatic debian import, and I want to upload a version to ubuntu - does that count as changes to an existing package, or as a new package?
<lifeless> its a change to an existing package
<mtaylor> ok
<lifeless> but the process is the same
<lifeless> which is why I don't really know what you mean
<mtaylor> so - there was this place that said changes to existing packages shouldn't use revu, but instead should attach debdiffs to bug reports against the package
<mtaylor> lifeless: https://wiki.ubuntu.com/SponsorshipProcess ... linked to from https://wiki.ubuntu.com/MOTU/Packages/REVU
<lifeless> ok
<lifeless> so uhm, I guess thts a different process
<lifeless> but the basics: review the delta, universe-sponsors-queue, upload, are the same
<lifeless> regardless of new package or change to existing
<mtaylor> sure...
<mtaylor> but my process to request review as an external-n00b-luser is quite different
<lifeless> and in fact, REVU is meant to be replaced by lp code reviews eventually ;)
<mtaylor> k
<SamB> jelmer: nice, that subunit you uploaded actually works ;-)
<SamB> I mean, not only can I use it, but dpkg stops uselessly trying to compile the code for Python 2.3 and is now *aware* that it works ;-)
<SamB> (oddly enough, I could actually use it even before that :-)
<jml> jelmer, http://code.mumak.net/2009/07/unittest-it-aint-broke-lets-fix-it.html
<mrooney> Anyone know how to use the bzr pager plugin?
<mrooney> I figured I could just install it and then a command like "bzr cdiff" would just do the right thing and go to less with more than a screen of output
<mrooney> But apparently that isn't right.
<Jesse1> hi
<jelmer> hi jml
<jelmer> hi Jesse1 I mean :-)
<jml> jelmer, hello :)
<jml> I'll take your greeting as it stands.
<Jesse1> i'm new to irc
<Jesse1> and bzr
<Jesse1> i'm thinking of using bzr to track wikipedia entries
<Jesse1> so as to reduce the load on wikipedia servers
<Jesse1> but i don't know how i can manipulate the revision ids a la bzr-svn
<Jesse1> i'm not a registered freenode user, so i'm not sure if what i said was heard at all...
<ndurner> We hear you :-)
<Jesse1> sweet
<Jesse1> as i understand, bzr-svn does the rev-id manipulation at SvnBranch level, so branching from a svn repo already gets the cooked rev-id's
<Jesse1> but what i want to do doesn't sound as complicated as that
<Jesse1> s/what/what if/
<Jesse1> ouch that was wrong
<Jesse1> so i'm thinking if i can generate revision ids for wikipedia entries e.w.o/w/foo&oldid=1234
<Jesse1> as en.wikipedia.org-foo:1234
<Jesse1> and stuff such a revision in the repo?
<jelmer> Jesse1: yes, but you'll probably have to do the same sort of thing as bzr-svn to do so
<Jesse1> they subclassed bzrlib.branch.Branch
<Jesse1> wait, "they" is actually you
<jelmer> Jesse1: alternatively, you could create a Python script that just does an import from wikipedia into a bzr branch
<Jesse1> a silly etiquette question: shall i prefix my messages with the intended recipient?
<Jesse1> and how do i massage the revision ids?
<jelmer> Jesse1: you can't change revision ids after the revision has been added, but when creating a new revision from within the bzr API you cna specify the new revision id
<spiv> Jesse1: perhap you can generate a fast-import file of your data and import that?
 * spiv isn't really here...
<Jesse1> i recalled parent revisions can be changed?
<Jesse1> jelmer: so i can specify the new revision id when creating new revision?
<jelmer> Jesse1: parent revision ids can't be changed either
<jelmer> Jesse1: yes, when creating a new revision you can specify the new revision id (but only from the API, this is not exposed on the command-line)
<Jesse1> suer i understand
<Jesse1> WorkingTree.commit() doesn't seem to have a place for revision id?
<jelmer> Jesse1: it does, IIRC it's called "rev_id"
<Jesse1> since bzrlib.workingtree.WorkingTree doesn't have docstring on commit()
<Jesse1> i can only guess from the argument names
<Jesse1> and i guess rev_id is parceled in *args?
 * jelmer nods
<Jesse1> what's the triple star in front of your name? (sorry i'm such a newbie)
<jelmer> oh, it indicates an action
<Jesse1> oic
<Jesse1> thx
<Jesse1> undocumented *args is eveil...
<ronny> moin
<Jesse1> thanks jelmer jml & spiv
<jelmer> moin ronny
<Jesse1> i'll look more into the docs and try
<jml> Jesse1, I didn't do anything :)
<Jesse1> oh really
<Jesse1> there's never too much gracias
<Jesse1> bye
<Muttley> hi, I'm using bzr-svn to push my bzr branch up to the wordpress svn server and I've just realised it's trying to download the revision info for the entire repository
<Muttley> did i screw up somewhere or is that just how it works
<LarstiQ> fsvo download, that is how it works
<Muttley> basically I had my bzr branch that I work in and just did: bzr push http://svn.wp-plugins.org/myplugin/trunk/
<LarstiQ> but the revision info getting of the entire repository bzr-svn needs to do, it caches, and is pretty fast
<LarstiQ> Muttley: which version of bzr and bzr-svn?
<Muttley> it's windows release (don't hate me) 1.16.1
<Muttley> not sure the plugin version
<LarstiQ> Muttley: don't worry, we won't hate you fot using Windows.
<LarstiQ> Muttley: `bzr plugins` will tell you, but bzr-svn is pretty strict in which versions of bzr it works with
<Muttley> hehe, I'm actually a linux guy but I've been doing this dev in windows
<LarstiQ> so that is probably 0.6.2
<LarstiQ> Muttley: don't hate yourself then? ;)
<Muttley> 0.6.3dev
<Muttley> LarstiQ: hehe
<LarstiQ> Muttley: I imagine the wp-plugins repository is huge? (Ie, where is bzr-svn's progress bar at?)
<Muttley> just the wordpress plugin repository is quite big
<Muttley> progress bar about 25%
<Muttley> been going about an hour
<Muttley> I'm out in asia at the moment so it's going between 5 and 10 K/sec
<Muttley> up to 20meg so far
<Muttley> is there anyway around it or am I just in for a long night? :)
<LarstiQ> Muttley: could you paste the line it is showing? It has multiple phases and I'd like to be sure it is at the phase I think it is at
<Muttley> [####/               ] http    20435KB    13KB/s | fetching svn revision info 3
<Muttley> I think that 3 is actually more like 3xx or 3xxx
<Muttley> just it cut of at the useful 80 char cmd promt limit
<Muttley> my plugin trunk was created a few hours ago and was revision 136629
<LarstiQ> ah
<Muttley> so it could be 3xxxx that it's currently on
<LarstiQ> Muttley: no way around this fetching svn revision info, but it is resumable, and will happen with any operation against that repository
<LarstiQ> evening AfC
<Muttley> ok, so if I kill it and start again tomorrow it'll at least continue from where it left off?
<LarstiQ> Muttley: yes
<Muttley> ok
<Muttley> thanks
<LarstiQ> Muttley: do you know if you have tdb or sqlite?
<Muttley> umm, pass
<LarstiQ> Muttley: bzr-svn grew a capability to use tdb for caching this info, which is way way faster
 * LarstiQ wonders what the installer uses
<LarstiQ> Muttley: ok :)
<Muttley> yeah, I was tempted to go the whole route of grabbing the dependences and source but in the end it seemed easier to just get the all-in-one installer ;)
<LarstiQ> aye
<Muttley> thanks for the help
<LarstiQ> np
 * AfC waves to LarstiQ
<LarstiQ> jelmer: do you know if python-tdb is available on windows?
<jelmer> LarstiQ: No, tdb hasn't been ported to windows (yet)
<LarstiQ> jelmer: ok, so Windows users are stuck with sqlite then
<jelmer> LarstiQ: yep, at least for now
<LarstiQ> k
<alex-weej> can someone tell me how i enable nautilus integration of bzr? i have bzr-gtk installed but nothing fancy happens when i open a repo folder
<jelmer> alex-weej: you need to have python-nautilus installed
<alex-weej> jelmer: i do have it installed
<alex-weej> on ubuntu 9.04 btw
<Raim> how can I let bzr forget my lp-login? already deleted ~/.bazaar/authentication.conf, but it seems like it gets it again from somewhere else
<james_w> Raim: ~/.bazaar/bazaar.conf
<Raim> james_w: ah... thanks, too obvious ;)
<thewrath> how do i checkout a specific revision from bzr
<LarstiQ> thewrath: -r <revision>
<thewrath> bzr -r <revision> <locationtoputitinto> ?
<LarstiQ> -r to the bzr command
<LarstiQ> thewrath: say, `bzr branch url/to/source -r <revision> destination`
<LarstiQ> thewrath: could you elaborate on the task at hand a bit more?
<thewrath> just trying to copy a certain revision to another location
<LarstiQ> thewrath: for what purpose?
<LarstiQ> thewrath: for say making a tarball, you'd want `bzr export`
<thewrath> i am modifiying a joomla education build and i want to have two  locations to have the same stuff
<thewrath> one like for hte live site and one for the dev site
<LarstiQ> thewrath: if I interpet that correctly, your original question was for how to deploy to the live site, right?
<thewrath> does that make ense
<thewrath> i wanted to createe another directory with the information from a certain revision
<thewrath> so i guess yes
<LarstiQ> thewrath: that sounds like something I would do with the bzr-upload plugin
<LarstiQ> thewrath: as I wouldn't do any development on the live site, only deploy
<thewrath> right
<thewrath> i had my dev site set up as i wanted to do for my live site so all i had to do was essentially move it over
<LarstiQ> right
<thewrath> wat does the bzr-upload-plugin do, does it come standard with bzr?
<LarstiQ> it doesn't come standard with bazaar, but is easy to install (will go over that in a bit)
<LarstiQ> thewrath: it creates the files in your working tree in a remote location, but doesn't store all the history
<LarstiQ> thewrath: and it is smart enough to only update it with the changes
<LarstiQ> thewrath: not the entire set of files again each time
<LarstiQ> thewrath: it is designed to work well for deployment on web application development
<thewrath> nbice
<LarstiQ> thewrath: you can either run `bzr upload` manually when you want to deploy something (optionally with -r to select a specific revision)
<LarstiQ> thewrath: or turn on automatic mode where it will upload on each commit
<LarstiQ> thewrath: how did you install your copy of bzr?
<thewrath> i am in windows so the msi beileve
<thewrath> *msi installer
<LarstiQ> ok
<LarstiQ> thewrath: does `bzr plugins` list the upload plugin?
<thewrath> no it does not when i run bzr plugins
<LarstiQ> ok
 * LarstiQ isn't too experienced with the windows installer, so let's see how it goes
<thewrath> ok,
<thewrath> worst comes to worst i can just reinstll it
<LarstiQ> thewrath: `bzr --version` should have a 'Bazaar configuration' directory listed
<LarstiQ> thewrath: sure
<thewrath> ok yes it does along with others
<LarstiQ> thewrath: right, so if you cd there
<LarstiQ> thewrath: and then `bzr branch lp:bzr-upload upload`
<LarstiQ> thewrath: you'll get a copy of the upload plugin from Launchpad
<LarstiQ> thewrath: after which it should show up in `bzr plugins`
<thewrath> yeap its there now
<LarstiQ> thewrath: ok, so the usage is, for the first time, `bzr upload LOCATION`, and afterwards just `bzr upload`
<LarstiQ> thewrath: see `bzr help plugins/upload` and `bzr help upload`
<LarstiQ> thewrath: and/or the README file inside the plugin dir
<thewrath> ok
<thewrath> can i change that for each different bzr project?
<LarstiQ> thewrath: ah right, sorry, it remembers it for a specific branch
<LarstiQ> thewrath: so yeah, each different bzr project is independent in its upload location
<thewrath> so each bzr init remembers its own?
<LarstiQ> thewrath: `bzr init` is only used to start a new project, but if you mean each branch, yes
<LarstiQ> though you should be able to configure it for multiple branches in one sweep with locations.conf
<dvheumen> hi, I've written a "patch" (it's childishly simple, but at least to learn something about python and bzr), how should I proceed to upload it? Just add it in a message to the bug? (https://bugs.launchpad.net/bzr/+bug/84659)
<ubottu> Ubuntu bug 84659 in bzr ""serve --allow-writes" allows more than you might think" [Medium,Triaged]
<thewrath> yea LarstiQ that is wat i meant
<LarstiQ> dvheumen: do you intend for it to be merged? Then `bzr send`ing it to merge@code.launchpad.net would be the thing to do
<LarstiQ> dvheumen: attaching it to a bug is possible but not something we do often
<dvheumen> LarstiQ: well it's a first for me, so I'll do what's the most common practice
<dvheumen> LarstiQ: so if you say that bzr sending is the best, i'll do that
<LarstiQ> dvheumen: it is
<dvheumen> LarstiQ: okay, thanks for the info
<LarstiQ> dvheumen: if you expect a lot of discussion, you could also send it to the mailing list with a subject prefixed with [RFC]
<LarstiQ> but if it is childishly simple, probably not :)
<dvheumen> LarstiQ: Well, it's basically a call to 'note' with a warning message, so I doubt it actually :D
<dvheumen> (tagged as 'easy')
<LarstiQ> dvheumen: good :)
<LarstiQ> dvheumen: as a result of your `bzr send`, it should show up in https://code.launchpad.net/bzr/+activereviews
<dvheumen> LarstiQ: ah, thanks, that's a good remark, I didn't know
<dvheumen> LarstiQ: I'm curious, how do they match my patch with the bug report?
<dvheumen> because I made this patch based on lp:bzr
<LarstiQ> dvheumen: ah, maybe I should have instructed you more carefully :)
<dvheumen> If there's some FAQ to read, just point me to it ... I don't mind ... but I have no idea of how to approach submitting a patch to bazaar/launchpad
<dvheumen> I expected to just post the patch file with a comment in the bug report
<dvheumen> until I heard your approach :P
<LarstiQ> dvheumen: mention the bug in the subject, say 'add a warning for foo (#84659)'
<alex-weej> can someone tell me how i enable nautilus integration of bzr? i have bzr-gtk installed but nothing fancy happens when i open a repo folder
<dvheumen> okay, I'll be back in about half an hour and I'll give it a try, tnx
<LarstiQ> alex-weej: does the README of bzr-gtk mention anything?
<LarstiQ> dvheumen: k, see you then
<alex-weej> LarstiQ: probably?
<LarstiQ> alex-weej: sooo?
 * LarstiQ doesn't use a desktop environment
<alex-weej> hardcore
<alex-weej> it just said i need to install python-nautilus to use nautilus integration
<alex-weej> i already have that
<LarstiQ> not really, I just am hopelessly ineffective in them
<alex-weej> oh wait there is more actually, i need to symlink something to enable it
<LarstiQ> alex-weej: right
<alex-weej> hm, nautilus needs proper plugin management :/
<alex-weej> thanks
<alex-weej> LarstiQ: actually, turns out the plugin is just missing from the deb :/
<LarstiQ> alex-weej: d'oh
<LarstiQ> alex-weej: which deb/distro is that?
<alex-weej> ubuntu 9.04
<LarstiQ> ho hum
<alex-weej> no wait, i found it! it's bundled in with the rest of the bzrlib for some reason
<alex-weej> even though it's a nautilus plugin
<alex-weej> :F
<LarstiQ> alex-weej: mind filing some bugs on Ubuntu? :)
<alex-weej> packaging error, yeah will do
<alex-weej> nah still doesn't work, ImportError: cannot import name cmd_gannotate
<alex-weej> i guess it has bitrotten :(
<LarstiQ> alex-weej: that is possible. Where does it try to import gannotate from? It is, or used to be, part of bzr-gtk
<alex-weej> bzrlib.plugins.gtk
<jelmer> alex-weej: that's fixed in bzr-gtk trunk
<Pilky> hey all, anyone around who's pretty well versed with how bzrlib works?
<Pilky> I'm trying to understand how authentication works when accessing servers. I've found the code to do various commands in bzr, found the code that seems to get the password or prompt the user but I can't find the code that links the two
<Pilky> if anyone could point me in the right direction it'd be much appreciated :)
<LarstiQ> Pilky: have you found credential stores?
<Pilky> yeah, I've found the stuff in config.py
<LarstiQ> good
<Pilky> it's more a case of I can't find where commands like push and commit etc access those
<LarstiQ> Pilky: bzrlib/transport/
<LarstiQ> Pilky: that is, commands don't do that, they try to connect to a location, and the underlying transport takes care of authentication
<Pilky> right
<Pilky> what I'm wanting to do is hijack the authentication prompt really
<LarstiQ> Pilky: for comparison, have a look at lp:hitchhiker, which builds on bzr transports
<Pilky> so instead of prompting for a password on the command line, I can pass in a password given to me by the user in a GUI
<LarstiQ> Pilky: in what way? Is it just because you want to prevent a UI.. right
<Pilky> yeah
<LarstiQ> Pilky: look at bzrlib/ui
<LarstiQ> Pilky: you want a UIFactory implementing get_password
<LarstiQ> Pilky: for a comparison of _that_ you could look at qbzr for a Qt UIFactory
<Pilky> ok cool
<Pilky> so that would allow me to stop it from prompting the user in the UI and I can just return my own password
<LarstiQ> Pilky: how you phrased your question at first I didn't know if I knew enough bzrlib, but I'm glad you just asked your question :)
<Pilky> heh
<LarstiQ> Pilky: if you so wish, though that might not be the right approach if I understand you correctly
<LarstiQ> Pilky: it is the way to not get prompting on the cli
<Pilky> well basically I'm building an Objective-C API
<LarstiQ> Pilky: but if you have something more of a CredentialStore, that api would be better
<LarstiQ> Pilky: I know :)
<Pilky> I want to be able to get the password from the Mac's keychain
<Pilky> authentication is the one thing that kills any project trying to tie into bzr using the CLI interface
<LarstiQ> Pilky: bzr-svn might already do something like that
<Pilky> well I'll have a look into bzr-svn and qbzr
<LarstiQ> Pilky: iirc jfroy added support for keychain authentication
<jfroy> Indeed
<jfroy> onnnne second
<Pilky> ah that would be useful
<jfroy> it is :)
<Pilky> if I can just write to keychain to set up authentication and get bzr to read from there it'd make things a LOT easier
<jfroy> at least for bzr-svn
<Pilky> jfroy: is it in your branch of bzr-svn or in the trunk?
<jfroy> neither
<Pilky> where is it then?
<Pilky> jfroy: ?
<jfroy> working on it :p
<jfroy> Cleaned it up a bit, pushing to LP
<Pilky> ah cool
<dvheumen> hey, how can I "update" (in svn terms) to a previous revision? I've found 'revert -r #' but it leaves modifications (of newer revisions) behind.
<jfroy> dvheumen: you can't
<jfroy> bzr doesn't support doing that
<jfroy> your only option is to lightweight checkout to the revision you want
<dvheumen> hmmmm...
<jfroy> e.g. bzr co --lightweight -r FOO some_directory
<Pilky> dvheumen: you can try clean-tree
<dvheumen> but I probably could do: bzr remove-tree; bzr co -r #
<jfroy> And yes it's silly, and the bzr developers don't seem to think so
<jfroy> dvheumen: yes, that should also work
<dvheumen> Pilky: nothing to delete
<Pilky> that should remove unknown files
<Pilky> dvheumen: try bzr clean-tree --detritus
<jfroy> Huh, hitting a ERROR: bzrlib.errors.IllegalUseOfScopeReplacer exception
<jfroy> Pilky: hold on :p
<Pilky> lol
<Pilky> I swear I'm going to regret taking this project on :p
<Pilky> at least I'm only committing a day a week to it at the moment
<jfroy> apparently, this is bad: from bzrlib.plugins.keychain import _keychain
<jfroy> (_keychain is an extension module in the plug-in, the plug-in itself is bzr-keychain (and the package name is keychain))
<dvheumen> Pilky: thanks, but it's too late :P
<Pilky> wasn't giving plugin names a bzr- prefix deprecated?
<abeaumont> is it possible to tell bzr svn to do a branch from a certain revision (like git svn does?), without importing whole history
<garyvdm> jfroy: if you have a project named bzr-xxx, it's directory in ~/.bazaar/plugins should just be xxx
<jfroy> garyvdm: that's what I have
<jfroy> I think the lazy imporer is using _foo for import foo
<jfroy> and so dies if trying to import a module actually named _foo
<garyvdm> jfroy: Ok - sorry - I miss understood you
<Pilky> jfroy: you know if this works then it could simplify my code a huge amount
<Pilky> I could do it all using NSTask and NSXML*
<jfroy> oh it does work
<Pilky> which also simplifies the licencing
<jfroy> I use it all the time at work to interface with svn repositories
<jfroy> I licensed it under BSD
<Pilky> cool
<jfroy> garyvdm: urg no that's not it
<jfroy> what the heck is going on :|
<Pilky> my issue before was I'd have to hook into bzrlib directly so I'd need to make part of my code GPL licensed, but then the developer facing API would be MIT licensed and talk to the backend via distributed objects
<Pilky> basically, not very pretty :P
<jfroy> Is this valid inside lazy_import.lazy_import?
<jfroy> from bzrlib.plugins.keychain import cKeychain
<jfroy> where the plug-in package is indeed keychain, and is named as such in the plugins directory
<jfroy> Pilky: I don't think that's a good idea...
<jfroy> bzr is GPL, so you should make your tool GPL as well.
<jfroy> DOs will make things way, way more complicated
<LarstiQ> jfroy: what is cKeychain, a class?
<jfroy> If you use the bzr CLI, I guess it would be fine
<jfroy> LarstiQ: an extension module in the package
<LarstiQ> jfroy: ah
<Pilky> jfroy: I don't want to make it GPL as I want the GUI to be MIT licenced
<jfroy> zohar:keychain bahamut$ pwd
<jfroy> zohar:keychain bahamut$ ls
<jfroy> LICENSE      README       __init__.py  __init__.pyc build        cKeychain.c  cKeychain.so setup.py
<jfroy> thanks IRC...
<jfroy>  /Users/bahamut/.bazaar/plugins/keychain
<Pilky> plus then my lib could be used by closed source projects
<LarstiQ> jfroy: could you try importing bzrlib.plugins.keychain (maybe as mod_keychain or such) and working off of that?
<jfroy> LarstiQ: sure
<jfroy> Is there an issue with lazy import that I should be aware of (for future reference and edification)
<LarstiQ> jfroy: a couple, they really should be written down somewhere.
 * LarstiQ looks for it
<LarstiQ> jfroy: from HACKING: While it is possible for ``lazy_import()`` to import members of a module when using the ``from module import member`` syntax, it is recommended to
<LarstiQ> only use that syntax to load sub modules ``from module import submodule``.
<LarstiQ> This is because variables and classes can frequently be used without needing a sub-member
<jfroy> well the issue is just that importing that sub-module outright dies
<LarstiQ> jfroy: right, which isn't mentioned
<LarstiQ> jfroy: so I'm not aware of that being a limitation
<LarstiQ> jfroy: can I use the keychain plugin on non-OSX?
<jfroy> No :p
<jfroy> I think it's a case of the stupids
<jfroy> one moment...
<jfroy> yup
<jfroy> didn't refactor the module name in the C extension file >.<
<jfroy> OK no it still dies
<jfroy> IllegalUseOfScopeReplacer: ScopeReplacer object 'cKeychain' was used incorrectly: Object already cleaned up, did you assign it to another variable?: _factory
<jfroy> (for from bzrlib.plugins.keychain import cKeychain)
<LarstiQ> jfroy: that is a lazy import error
<jfroy> doing the import in the module itself (the plug-in's __init__ module) works fine
<jfroy> that's OK
<jfroy> worked around ot
<jfroy> *it
<jfroy> def lazy_import_cKeychain():
<jfroy>     global cKeychain
<jfroy>     cKeychain = __import__('bzrlib.plugins.keychain.cKeychain', globals(), locals(), [], 0)
<jfroy> :P
<jfroy> innteresting, that seems broken too
<LarstiQ> ahem :P
<jfroy> did I do something stupid?
<jfroy> :/
 * LarstiQ has a look at the code
<jfroy> cKeychain = __import__('cKeychain', globals(), locals(), [], 1) did the trick
<jfroy> uh-ho
<jfroy> converted the branch to 2a
<jfroy> And now bzr pack is giving me bzr: ERROR: Pack '3dcf256d8340362428db62217ca32a0d' already exists in <bzrlib.repofmt.groupcompress_repo.GCRepositoryPackCollection object at 0x1018d9490>
<LarstiQ> doesn't that mean you don't need to pack?
<LarstiQ> scarily worded
<Pilky> jfroy: that's your own fault for using a crappy VCS, use subversion! ;)
<jelmer> jfroy: which version of bzr are you using?
<jfroy> LarstiQ: does it?
<jfroy> 1.17rc1
<jfroy> Pilky: apologies for the delay
<jfroy> https://launchpad.net/bzr-keychain
<Pilky> jfroy: a short delay for the amount of time you could save me is a small price to pay ;)
<Pilky> still trying to push?
<jfroy> I did
<jfroy> should be on LP
<Pilky> ah
<Pilky> it must not have registered it in the UI yet
<jfroy> ah huh hold on
<jfroy> haven't set a development focus yet
<jfroy> there, done
<jfroy> bzr branch lp:bzr-keychain keychain
<jfroy> jelmer:  LarstiQ  you can grab the branch to check that pack issue if you want
<jelmer> jfroy: this is a known bug, but I thought it had already been fixed
<jfroy> I see
<jelmer> jfroy: if a 2a repository is already packed then "bzr pack" will generate the exact same file
<jelmer> jfroy: and thus you get this error
<jfroy> gotcha
<jelmer> jfroy: this situation should probably be special cased or something
<jfroy> Pilky: that being said, maybe the DO approach is not so bad
<jfroy> As bad as it is, using NSTask is even worse
<Pilky> jfroy: your setup script doesn't seem to work
<jfroy> the cost is launching the Python interpreter is non-trivial
<jfroy> Pilky: oh?
<Pilky> from: can't read /var/mail/distutils.core
<Pilky> ./setup.py: line 27: import: command not found
<Pilky> ./setup.py: line 29: syntax error near unexpected token `name='bzr-keychain','
<Pilky> ./setup.py: line 29: `setup(name='bzr-keychain','
<LarstiQ> Pilky: run it with python
<LarstiQ> jfroy: add a hashbang ;)
<Pilky> bah *headdesk*
 * jfroy follows Pilky 
<jfroy> pushed >.>
<jfroy> *ahem*
<jfroy> Pilky: DO guidelines: 1) ONLY use async messages 2) ALWAYS wrap ANY DO message with try {} catch {}
<jfroy> Should be fine beyond that.
<Pilky> hmm
<jfroy> sync messages WILL lead to deadlocks
<jfroy> it's almost inevitable
<jfroy> from experience
<Pilky> yeah I was going to do everything asynchronously
<jfroy> try {} catch {} because any DO message can throw an exception if the other end is gone for some reason (crash, etc.)
<Pilky> I'm assuming that your plugin doesn't save to the keychain, only reads?
<jfroy> We had amusing bugs much earlier on in [REDACTED] Leopard where mach ports would die for no reason. Caused havoc in DO apps that didn't guard properly :p
<jfroy> it only reads, correct
<jfroy> the credential store API in bzr doesn't have write AFAIK
<jfroy> or does it....
<LarstiQ> jfroy: when were you gettting cKeychain errors?
<jfroy> LarstiQ: when lazily importing it
<jfroy> using a "from bzrlib.plugins.keychain import cKeychain" in the lazy import list
<jfroy> Pilky: in practice I've found this to be fine
<Pilky> ok, so for example if I wanted to store my ssh password for launchpad I'd create an internet keychain with the url and password needed?
<jfroy> connecting once to the svn repository using Safari or svn will add the credentials to the keychain
<jfroy> Ah, there is *no need* for the plug-in for ssh
<jfroy> I don't think credential stores are even queried for ssh
<jfroy> Mac OS X since 10.5 integrates the sshkey agent with Keychain
<jfroy> it Just Worksâ¢
<Pilky> oh really?
<jfroy> yup
<jfroy> it's also lazily started by launchd
<jfroy> (the key agent is a launchd agent, e.g. per-user session)
<jelmer> write support to keychain/gnome keyring in bzr would be nice
<jfroy> I don't think it's big deal, actually
<jfroy> most people use anon http or ssh
<jfroy> the only common case for authenticated http is bzr-svn.
<LarstiQ> Pilky: for openssh, the thinking is that credentials are best left up to openssh not bzr
<jfroy> IIRC ssh is special cased
<jfroy> the credential stores are not used
 * LarstiQ nods
<LarstiQ> jfroy: it works when I do `bzr plugins`
<LarstiQ> oh, but I didn't compile..
<jfroy> it won't build on non-Mac OS X, since it uses the Keychain C API :|
<LarstiQ> yeah
<LarstiQ> jfroy: I would probably try 'import bzrlib.plugins.keychain.cKeychain' myself at first
<jfroy> that probably will work, but then how do I use cKeychain
<jfroy> If I know my Python at all, I think I'd have to use the full import name in code
<jfroy> which is... long :|
<LarstiQ> bzrlib.plugins.keychain.cKeychain.find_generic_password, which is indeed pretty long
<LarstiQ> do you need to import it lazily?
<jfroy> No, but it's always a good idea to be as lazy as possible
<jfroy> bzr launch times are already bad as it is
<jfroy> I worked around the issues and rolled my own lazy import with __import__
 * LarstiQ noticed
<jfroy> it's a small plug-in, and the C module is only used in one place, so it's acceptable
<LarstiQ> jfroy: I'm wondering what makes it problematic though, will any C extension go wrong?
<jfroy> dunno
<jfroy> jelmer might have some ideas
<jfroy> since his svn bindings used to be bundled with bzr-svn
 * jelmer didn't really follow
<jelmer> what's the question?
<LarstiQ> gosh, is my upgrade of bzr.dev to 2a going slowly
<LarstiQ> jelmer: jfroy ran into some errors with lazyimporting bzrlib.plugins.keychain.cKeychain, which is a C extension
<LarstiQ> jelmer: so I wondered what made it problematic, did lazy importing subvertpy when it was part of bzr-svn give any trouble?
<jelmer> LarstiQ: I don't think I ever lazy imported it
<LarstiQ> jelmer: that calls for experimentation I guess! :)
#bzr 2010-07-19
<GungaDin> when I'm trying to checkout a branch on Windows, I get "exceptions.NameError: global name 'readline' is not defined... any ideas?
<AfC> Has locking been removed to the point where Bazaar is safe over NFS now?
<mwhudson> AfC: i don't think working trees on nfs are a particularly good idea yet
<mwhudson> (not sure though!)
<AfC> mwhudson: [yeah, I've been searching docs and not finding advice either way]
<AfC> I was vaguely mostly wondering about branches & repositories.
<mwhudson> i think that ought to be ok
<AfC> hm
<AfC> Branches on a file:/// at a NFS mount, or bzr+ssh:///
<lifeless> bzr+ssh
<lifeless> nfs will work its just a bad idea
<AfC> lifeless: fair enough
<AfC> thanks
<AfC> [my suspicion was that revisions locally is better than asking NFS to ship them around and being blocked on network to get them into host cache]
<lifeless> think of it like 'is running sqlite, or access, or postgresql, on nfs a good idea'
<lifeless> bbiab
<vila> hi all !
<poolie> hi vila
<poolie> vila, can you be pp this week?
<vila> that was quick :)
<vila> poolie: yes, until thursday
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | bzr 2.2b4 has gone gold, build those installers
<poolie> hi vila
<vila> poolie: hey !
<poolie> thanks for the reviews!
<vila> poolie: more to come ;)
<poolie> you're ok to pilot?
<poolie> thanks, i was slack at it last week
<poolie> i think i had a good excuse
<vila> poolie: sure, I'm already doing it, just wanting to remind you that I'll stop Thursday
<poolie> np
<vila> jelmer: welcome back !
<jelmer> 'morning vila
<poolie> hi jelmer
<jelmer> vila: thanks :-)
<jelmer> hi Martin
<poolie> wish you'd been here, it was a great sprint
<jelmer> I bet, I wish I could've made it too :-(
<vila> jelmer: feel free to ping me about https://code.edge.launchpad.net/~vila/bzr-svn/525571-minimal-atomic-write-bazaar-conf-files-2.1/+merge/29439 when you want, your fix on bzr-svn trunk is based on a fix that will not land on bzr trunk for a little while so you may have to tweak a bit
<james_w> hi vila, hi jelmer
<vila> hey james_w
<jelmer> hi James
<jelmer> vila: I'll have a look this evening - thanks
<poolie> jam so the followon i https://code.edge.launchpad.net/~mbp/bzr/32669-2.0-symlink-branch/+merge/30241
<poolie> apparently not passing yte
<poolie> vila, i was just talking to jam about fixing bugs in 2.0
<jam> hi vila
<vila> hi ajm
<vila> meh, hi jam
<poolie> and the agreement, which is not super surprising, is that we should merge things that are either small fixes and at least a medium bug, or a critical bug with the smallest sufficient fix
<vila> right, so your last symlink fix is ok or not ?
<poolie> so these things for symlinks are probably only for trunk
<vila> the add SYMLINK/FILE that is
<vila> ha, good, I feel better this way too
<poolie> good :)
<vila> not that the fixes sound risky, but changing the behaviour there... has its own risks
<poolie> right
<poolie> these dependent branch things are not as good as they could be
 * vila breathes again, running the full test suite in 3 hours was a pain :-(
<fullermd> Long time to hold your breath, too   :p
<vila> fullermd: only a week working my underpowered laptop, good practice for scuba diving :p
<vila> wow scuba *is* an acronym...
<fullermd> Everything's an acronym if you get creative enough  ;>
<vila> fullermd: how about superfragilisticexpialidocious
 * vila won't hold his breath there :-D
<fullermd> Sustained Underwater Peristalsis through Extremely Ribald Falsetto Ringtones And Gyrating Intersteller Longranger Interferometric Seismic Tortoise Interloping Calling Enough Xylophonic Porpoises for Inter-Alia Licorice In Destructive Obsequious Cacophanies Intersperced with Obviously Ultimate Sequins
 * fullermd gasps for breath.
 * vila googles acronymizer
<fullermd> That would be cheating.
<vila> right, google didn't find yours...
<vila> ...yet
<vila> :)
<Glenjamin> hi guys, i'm trying to set up a basic authenticating server using ssh
<Glenjamin> so far i've got a ssh shell wrapper that forces a directory, but i can only see to capture the bzr serve call, there's no information about which branch is being requested
<Glenjamin> so my question is - can I check which branch is being accessed somehow?
<Glenjamin> my script so far is pretty much http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/annotate/head:/contrib/bzr_ssh_path_limiter
<mandel> quick question here to see if I understand correctly, if a do "bzr add dir/" all the contents of the dir should be added, am I right?
<Glenjamin> except those that match ignore patterns, yes
<mandel> Glenjamin, which are present in .bzrignore, right?
<mandel> Glenjamin, can they be found somewhere else?
<mandel> I'm working on windows and wanted to add a folder with a subfolder with  binnaries to a branch and all the binnaries have been ignored from the nested folder , and I was wondering if that was a feature
<Glenjamin> does anyone know roughly where in the code the bzr client runs the SSH command to start up the server for the bzr+ssh:// transport?
<Glenjamin> i'm trying to add in an environment variable to provide details of what the server connection is for.
<LeoNerd> Doesn't it use paramiko these days, and hence doesn't -actually- run /usr/bin/ssh at all..?
<Glenjamin> not a clue, all i know is the server receives bzr serve --directory=/
<Glenjamin> and i'd like to try and pass more information there
<vila> Glenjamin: bzrlib.transport.ssh ?
<mgz> ...the easiest way to add an envvar is just to add it to the environment you're running bzr in, not fiddle with the ssh code
<mgz> they get passed along to child processes
<mgz> I see jam's done the review on the ~nmb branch I collapsed before posting last night, so that's one less job
<mgz> there's one other existing error class that defines a similar __str__ method and should probably be changed as well
<Glenjamin> mgz: would that add the env var to the remote ssh connection?
<cr3> is there a way to get a log between given timestamps?
<Glenjamin> i want to send the command line bzr was given to the ssh wrapper that accepts the connection - for permission checking
<mgz> ah, I hadn't read closely enough. easiest to fiddle with the default environment of the remote user, then?
<Glenjamin> if i do "bzr push bzr@bzr.server.com/project/branch" i'd like to set BZR_COMMAND=push and BZR_PATH=/project/branch on the initial SSH connection.
<Glenjamin> or something along those lines
<mgz> oh, so you don't really need a different env, you just want to look at the logging
<mgz> see .bzr/log on the server, it will have all that and more
<Glenjamin> oh
<Glenjamin> interessant
<mgz> $BZR_HOME/.bzr.log
<Glenjamin> surely the command string is in the _client's_ bzr log?
<mgz> depends what you mean by command
<mgz> what you type on the terminal is in the client's log
<mgz> what smart operations actually run are in both.
<Glenjamin> yeah, this is part of the problem - i'm using a script like http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/annotate/head:/contrib/bzr_ssh_path_limiter
<Glenjamin> the ssh shell thing just gets the bzr serve command, and then the actual command is sent through a different medium
<Glenjamin> there's a program called bazitis, which does the remote permissions by replacing the file:// handler. I was trying to something simpler
<mgz> okay, reading further back in the log I now understand even less
<Glenjamin> yeah, i'm not convinced i'm being entirely clear, i'll go back to the problem - not my perceived solution
<mgz> you're trying to do a more complicated authentication scheme than just user permissions?
<Glenjamin> sort of
<Glenjamin> i'm doing it like gitosis, where you have a single user, and each key auth uses a different shell
<Glenjamin> which is a program that does a check against SSH_ORIGINAL_COMMAND
<Glenjamin> the whole repo is owned by the "bzr" user, and auth is handled separately
<Glenjamin> this work fine in git, because the command sent contains the full path - but doesn't in bazaar because of the way the smart protocol works
<Glenjamin> the reason for doing it this way, is to avoid giving everyone full ssh accounts
<Glenjamin> and to enforce the repos all being in the same place
<cr3> using bzrlib, how can I get a branch object from a path already created as a branch?
<Glenjamin> cr3: http://doc.bazaar.canonical.com/bzr.2.1/developers/integration.html should be what you need
<mgz> okay. trying to work this with bzr+ssh seems perverse to me, but copying what some git thing does explains why at least.
<cr3> Glenjamin: awesome, thanks!
<vila> Glenjamin: keep in mind though that, unlike git, the repository may not be at the same place that the branch
<Glenjamin> my intention was to force everything through this same script, so I can enforce things like central repository layout
<Glenjamin> so, given that this has probably been the wrong way to approach this
<Glenjamin> what's the recommended way to handle a central repository with user-based permissions in a corporate environment?
<vila> Glenjamin: using bzr+http may be a bit more setup for the server itself, but then, it provides many solutions to define/authenticate the users
<vila> Glenjamin: from there defining specific .htmlaccess files becomes the easiest I think
<vila> Glenjamin: but there is also contrib/bzr_access which AIUI does what you want
<Glenjamin> bzr access only supports global permissions, since it wraps the initial ssh connection - which has no knowledge (nor really cares) what it's being opened for :(
<vila> Glenjamin: but you can still use different keys, i.e. one by project if really needed
<vila> Glenjamin: how many projects are you trying to handle or how many teams if they work on the same projects ?
<Glenjamin> vila: to begin with, it's just going to be one project with maybe 5 devs, but i hate the git setup we have atm, so ideally i'd want to replace our gitosis setup with this
<vila> Glenjamin: for a given project, it makes sense to define groups for read and write operations for all the branches in the repository, what feature is missing for you ?
<Glenjamin> i was hoping to manage multiple projects using a single key for each user
<vila> Glenjamin: bzr_acess finds its config file in the repository, so you can specify different access rights for a given user at this level
<vila> bah, I meant, for the same user, each repo defines the access rights, that gives you rights by project
<Glenjamin> but bzr serve always receives --directory=/
<Glenjamin> and then the protocol itself requests the full path
<vila> Glenjamin: but it will receive --allows-write or not and will not be called if the permission is denied, at least that's how I read the script...
<vila> Glenjamin:
<Glenjamin> my understanding is that each line in the authorized_keys file has to match a unique key, and the command string on that line is the only place you can tell bzr_access which repo to look at
<vila> doh
<Glenjamin> i sorta want to be able to hook into the SmartClientMedium
<Glenjamin> but there's no entry point
<vila> Glenjamin: indeed, hmm, the next simplest thing would be define a user by project on the server :-/
<vila> Glenjamin: I think you should talk with spiv then, he should be able to give you the most detailed answer
<vila> Glenjamin: I think he's travelling right now but he should resume his online presence in AU tz soon
<Glenjamin> i've come up with a silly hack that involves hooking into http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/annotate/head:/bzrlib/smart/request.py#L171 :D
<jam> vila: poke
<jam> looking into the python2.7 compatibility issues
<vila> jam: :)
<jam> it looks like the problem is in how we are poking at xmlrpclib so that it can support proxies
<jam> it seems that xmlrpclib wants an httplib.Response object, and we are giving it a _urllib2_wrappers.Request object
<jam> the main difference from what I can see
<jam> one has 'def getheaders'
<jam> the other has
<jam> 'def get_header'
<jam> (sorry, both are singular)
<jam> the difference is in the underscore
<vila> jam: from the top of my head, can't they both use .headers instead ?
<jam> vila: I can't change the stdlib
<jam> unless you *really* want to hack stuff
<jam> look at http://docs.python.org/dev/whatsnew/2.7.html
<jam> it mentions that xmlrpclib now supports keep-alive, etc
<jam> which means it checks headers
<jam> which means it breaks vs our work-around for proxies
<vila> jam: what seems suprising is that one gets a response when the other get a request...
<jam> vila: yep
<jam> vila: I may not have followed the traces enough yet
<jam> the bug mentions this fails: if response.getheader("Content-Encoding", "") ==  "gzip":
<vila> urgh, who is playing with content-encoding ?
<vila> jam: bug $ again ?
<vila> jam: bug # again ?
<jam> vila: bug #605574
<ubot5> Launchpad bug 605574 in Bazaar "lp-registration is not compatible with python-2.7 (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/605574
<vila> thks
<vila> ha right, urgh, addinfourl is an ugly hack...
<jam> vila: sure, but I think it is masking the real thing
<jam> vila: specifically, python2.6.5 doesn't ever call getheader
<jam> python2.7 does
<vila> jam: sure
<vila> so, are you reproducing that right now ?
<jam> both to check the "Content-Length" header, and to check "Content-Encoding"
<jam> vila: yeah, no problem reproducing
<jam> vila: /usr/local/bin/python2.7 bzr info lp:bzr
<jam> fails in the xmlrpc lookup of 'lp:bzr'
<vila> oh,, cool, let me try that
<poolie> jam, can you find michael hope and talk about release process, if you're not busy?
<vila> meh, no py27 for lucid ? :-/
<poolie> vila there's a ppa i think
<jam> vila: nope
<poolie> maybe that's only maverick
<jam> poolie: barry is sort of looking at it
<vila> poolie: will check
<jam> but doko only built for maverick
<jam> poolie: I don't know who that is, but otherwise I would be willing
<vila> ha, time for new babune slave then :->
<jam> vila: yeah, I built from source to test this
<vila> jam: hmm, so for a short answer: if get_header or getheader should be added to _urllib2_wrappers class this shouldn't to hard, I more or less remember getting away from addinfourl objects though so I'm a bit surprised to see one in the traceback
<vila> may be I just wrap it very late and I never put the headers there since they were not needed
<vila> jam: but for context: why are you looking at this ? I didn't thought 2.7 was urgent, is there a chicken-and-egg problem for someone here ?
<jam> vila: maverick would like to include 2.7 as an installable package
<jam> it can't unless they can build all python packages for both 2.6 and 2.7
<jam> also
<jam> 2.7 is out
<jam> it would be good to be compatible with it
<jam> and barry is here to work with :)
<vila> jam: ok, makes sense, say sorry and hi to Barry from me then :)
<jam> vila: barry says hi, and enjoy your evening
<jam> vila: first thing when trying to use the original transport... itgets a 302 redirected error and basically just dies ... :)
<vila> ..and fallback to a bzr one ?
<jam> vila: I hacked out the XMLRPCTransport code so that I could try to figure out what object it is actually getting
<vila> wow, qblame confirms I wrote this class, it looks weird, this smells like: "OMG, let's try to minimize even if it ends up ugly:-/"
<vila> jam: did you try to run the associated tests ?
<jam> vila: test suite doesn't run either, for other reasons
<jam> unittest._WritelnDecorator no longer exists
<jam> barry is working on that one
<vila> umpf
 * vila sings ha ha ha ha, shaving the yack, shaving the yak (on the Saturday's Night Fever music)
<jam> looks like the class just moved somewhere, we can grab it from there
<jam> shaving the yaaaaaa-aaaaaaa-aaaaaaaa-aaaaaaak
<lifeless> lets just drop the WritelnDecorator use :)
<jam> lifeless: unittest.runner printErrors calls self.stream.writeln()
<jam> lifeless: so it isn't in our code, unless we can override such things in our runners, etc
<lifeless> we could stop calling that :)
<jam> vila: basically, XMLRPCTransport is no longer compatible with xmlrpclib.Transport
<jam> we found a test suite failure
<jam> from xmlrpclib....close
<jam> it wants a '._connection' attribute (presumably to close it)
<mgz> ah, the 2.7 bugs
<jam> mgz: yeah
<jam> which is also good for Barry to know about, because it directly impacts the chance that 2.7 can be put into the next Ubuntu release
<mgz> I'll do the testing one if depending on a newer version of testtools is an acceptable solution
<jam> lifeless: the test suite is also failing if lazr.? is not installed
<jam> *sigh*
<jam> it looks like barry has launchpadlib, but not necessarily the full dependency stack on his 2.7 vm
<mgz> what's the rules on where to fix things currently? should I be branching 2.2 or just staying with dev or what?
<jam> mgz: branch the thing where you want it to land :)
<mgz> does 2.2 want to work with 2.7?
<jam> 2.2 is feature/api-frozen
<jam> 2.2 is targeted for Maverick, and we'd like to have 2.7 in Maverick
<jam> at this point we would *like* it
<jam> Subject to the tastefulness of changes to get it
<jam> poolie has the final say IMO
<vila> wow, installing maverick from the daily build is a breathe, I'm impressed (*again*)
<vila> hmpf, boot seems to be even faster than lucid
<vila> jam: XMLRPCTransport was meant to be a minimal replacement, it's not surprising it's not compatible anymore
<vila> jam: if this becomes too hard to maintain, we may want to switch to launchpadlib instead, I don't know if it has been ported on all platforms though
<jam> vila: it is on windows
<jam> the main problem is that it is *dog slow*
<poolie> hi jam, where did you get off to?
<jam> as it does stuff like downloading the WADL definition, extra round trips, etc
<vila> jam: good, the hardest part is done then :)
<jam> poolie: currently in Mozart 2
<jam> w/ barry
<poolie> jam/mgz: my main thing for 2.2 is that we should not break plugins that are updated to work with 2.2b4,
<poolie> and that we should not break ourselves :)
<Meths> Is there a proper way to remove a checkout from my local repo?  Just rming the dir leaves info in the .bzr directory doesn't it?
<mgz> okay, one issue down, two more exposed
<mgz> ha, second one is less horrible than I thought, but.... man lifeless is going to hate this
<maxb> Meths: Yes, but there's no way to get rid of that, currently.
<maxb> So just rm the dir
<mgz> okay, this is problematic
<mgz> bzrlib and the new unittest in 2.7 seem to have different ideas about the arguements to load_tests functions
<Meths> maxb: Okay, thanks.
<mgz> down to two failures on bt.test_selftest and a bunch of extra spew at the end
<vila> mgz: load_tests is specific to bzrlib so we can change it if needed
<mgz> well, the problem is it's not any more, likewise other unittest extensions
<mgz> there are similar but incompatible implementations of various bits in 2.7
<mgz> trying to file bugs for a few bits that can be handled later, but launchpad isn't playing along.
<vila> testtools should be fixed then, not bzrlib :->
<mgz> well, bzrlib.selftest and bzrlib.TestUtils implements a lot of stuff testtools doesn't
<vila> hmm
<mgz> is there a way past the +filebug search through all existing bugs?
<mgz> because having that timeout on me is just annoying
<vila> mgz: on .edge ?
<mgz> all I want to do is fill in a few text fields and it doesn't wanna let me
<vila> mgz: try disabling the redirection
<vila> mgz: prepare everything in your editor and *then* copy/paste :)
<mgz> that had a thingy saying it should only be used by "the Launchpad Beta Testers team"
<mgz> which I'm pretty sure I'm not in
<maxb> there's a sort of cheeky workaround. Keep the summary box blank, click Next, and *then* fill it in
<mgz> ah, I'll try that, thanks.
<mgz> "There is 1 error." "A summary is required."
<vila> mgz: does the host says 'edge' anywhere ? If yes, then you are part of the beta testers team ;)
<vila> mgz: go the lp home page and you should be able to disable the redirection for 2 hours
<mgz> ah, just a space then will do.
<mgz> okay vila, as long as you promise no one will yell at me :)
<vila> hehe, I can yell now so you can continue with that done if you want :)
<lifeless> mgz: *sigh* testtools
<lifeless> mgz: the thing will timeout because fti is doing terrible queries
<lifeless> mgz: on edge it will take 14 seconds to timeout, which is better than prod
<mgz> does your job change mean I can now direct my launchpad whines at you personally? ;)
<lifeless> yes
<lifeless> it also means I get to wave my hands and say 'thats not architectural nyah nyah nyah'
<mgz> ehehhee
<vila> lol
<lifeless> mgz: I am interested in whinges and praise.
<lifeless> they inform me about the things we need to make easier to fix, and the things we're successful at.
<mgz> oh, reminds me - the bug I wanted you to point the launchpad notifications guy at, he might have got the wrong one
<mgz> he triaged a minor unrelated one I filed, but I found an existing bug for the email notifications that I commented on
<mgz> ...well, it's also minor to be fair, just annoying for inbox management
<vila> mgz: like using "My Name <bug#@lp.net>" instead of "My Name <myemail>" when sending a mail to *me* ?
<mgz> like that, though that particular doesn't wind me up too much
<mgz> what tag should I use for Python 2.7 related issues?
<lifeless> python2.7?
<mgz> dots are okay?
<lifeless> I think so
<mgz> I will try.
<mgz> seems so.
<lifeless> jml: I just found out fuzzyman mangled the load_tests protocol
<lifeless> jml: I am feeling infuriated
<mgz> such things are only ever discovered after the final release :)
<poolie> hi there mgz
<mgz> hey poolie.
<mgz> poolie: I'm always a little nervous about triage-as-I-file because there's a not-insignificant number of bugs that only I see, so having someone else confirm them makes me feel happier :)
<poolie> mgz i know what you mean but i think you'll be right often enough that it's worthwhile over all
<poolie> it's just as easy for us to change a bug from confirmed->incomplete or low-> high or high->low as it is from new->something
<poolie> anyhow, bed time here
<poolie> good nih
<poolie> night*
<mgz> night!
<doug> http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-git-users.html says "Bazaar allows branches to have nicknames, and provides commands to switch branches for you."
<doug> what commands are those?
<doug> what i want to do is totally a git staple: branch+switch to a throwaway branch to attempt some experimental refactoring
<beuno> that would be "bzr switch", although I haven't used it enough to walk you through it
<doug> dunno, that doesn't seem to be in wide use or implemented quite like i'd expect
<mkanat> doug: Yeah, switch.
<mkanat> doug: I use it all the time.
<mkanat> doug: I think you might also be thinking of the word "branch" in git terms that don't make sense in bzr.
<mkanat> doug: You might want "shelve" instead.
<doug> yeah, that might do it.
<maxb> doug: The key difference between bzr and git here is that whilst a git branch can just be a name within an existing .git directory, a bzr branch is always identified by an actual user-visible filesystem directory
<maxb> a couple of sentences before the one you quoted, in fact :-)
#bzr 2010-07-20
<mwhudson> has anyone implemented du that works over a transport?
<lifeless> mwhudson: repository info used to, I think. It was terrible.
<mwhudson> ah yes, i think you're right
 * mwhudson tries to remember why he asked
<vila> hi all !
<spm> heya vila!
<vila> spm: hey there :)
<spm> vila: nice shirt i noticed you wearing in some of the sprint photo's. something about google and to ask you instead. :-)
<vila>  huh ? This got public ? OMG :-D
<spm> hahaha
<spm> I'll refrain from pointing out that you were walking around in public with that on....
<vila> spm: for your enjoyment, you can try shuffling the words too, there are some interesting variations there :)
<spm> quite possible
<spm> possibly too even!
<MAfifi> I've made a fatal mistake.
<MAfifi> I've two projects on launchpad, namely listInstalledRPM and downloadRPM. I've, by mistake, pushed the trunk tree of the latter to the former.
<MAfifi> Now I can't fall back.
<poolie> MAfifi, did you do a push --overwrite?
<poolie> or had you only pushed one of them
<MAfifi> poolie: No it was just my first push to that project, so I normally used just push.
<poolie> Mafifi ok so just push --overwrite what you do want to have there
<MAfifi> poolie: Thank you, I used push --overwrite and it fortunately did exactly what I wanted.
<poolie> great
<jml> lifeless, I saw the bug report. ensaddening.
<vila> jml, lifeless: who is 'he' ?
<poolie> hi there vila
<vila> poolie: hey
<lifeless> vila: fuzzyman
<poolie> how are you? what fabulous adventures will you have today?
<poolie> lifeless,  this is your load_tests thing?
<lifeless> yes
<lifeless> he fairly casually, AFAICT, implemented a different protocol, breaking everyone using the bzr one.
<poolie> ffs
<james_w> rockstar: can you run the failing command again under "strace -o /tmp/strace.txt" and then send me that file?
<spiv> yes, very ensaddening :(
<rockstar> james_w, sure, one sec.
<lifeless> I may be exaggeratig, I don't know the story behind the change.
<lifeless> anyhooo
<vila> on the -let-s-try-to-be-positive, 'pattern' can be said to be as arbitrary as 'module', in fact, I'm pretty sure both should be put in the loader letting any load_tests() function defines a new one for submodules if needed (or specialize whatever(
<vila> s/(/)/
<vila> hmm, not sure this sed command wont bring nasty comments...
<rockstar> james_w, http://pastebin.ubuntu.com/466360/
<Meths> vila: like "That isn't the sed command you're looking for..."?
<vila> Meths: this comment is ok :-)
<james_w> rockstar: and that run gave the same error?
<rockstar> james_w, yup.
<james_w> rockstar: it's very odd
<rockstar> james_w, yes, yes it is.
<vila> poolie: I'm setting up a maverick slave to help jam/barry
<poolie> in babune, running 2.7?
<poolie> that sounds useful
<vila> yeah, first step is: running default python, then py2.7
<james_w> rockstar: it's looking for /home/rockstar/Projects/repos/tarmac/tarmac_0.3.2.orig.tar.gz but I think you are running the command in /home/rockstar/Projects/tarmac/packaging ?
<rockstar> james_w, oh man.  Yeah, I've got lightweight checkouts setup.
<vila> long term, I think we want a dedicated job to track python-trunk, at least the 2.x series
<james_w> rockstar: then you have found a bug sir
<james_w> rockstar: please to be filing with details of your setup
<rockstar> james_w, indeed, and you have found a workaround for me.
<vila> that would have helped detect this load_tests() issue far sooner, may be even in time to yell when it broke testtools/bzr
<rockstar> james_w, thanks.
<vila> poolie: well, when I said first step, I should have said 'next' :-) There were many small steps before to setup the new VM but it went pretty smoothly. I'm not ready to automate that though :)
<vila> poolie: the nice thing is that I seem to have fixed an old bug there where some vms were failing to connect to dhcp and led to spurious failures in babune, so even less maintenance for me :D
<vila> jam, lifeless: first run on babune for maverick/py26: http://paste.ubuntu.com/466370/
<vila> subunit faliing to parse a date ? Rings anyone bell ?
<poolie> spiv, do you know anything about automatic changelog merging?
<poolie> vila that looks like stderr and stdout are getting mixed together badly
<poolie> or something similar
<jml> jam, https://devpad.canonical.com/~jml/no-accel-tree.gz (also -2, -3)
<vila> poolie: subunit and testtools were out-of-date, dunno exactly why... retrying
<vila> meh, this laste paste is bogus, where are my EOL gone ??? :)
<spiv> poolie: bzr-builddeb registers a hook that does that, it seems to work quite well
<poolie> ok, thanks
<poolie> so that's one thing fixed from scottk's list
<knittl> hi. is there a way i can print bazaar repository files?
<knittl> hg has debug*
<knittl> git has cat-file and ls-tree
<LeoNerd> bzr cat $URL  ?
<knittl> url?
<knittl> no, i mean local repository
<knittl> showing raw changelogs, indices, trees, blobs
<LeoNerd> Oh.. Poke at the internals? No...
<LeoNerd> For that, see /bin/cat  ;)
<knittl> yep, internals
<knittl> human readable if possible
<knittl> so, not really raw
<poolie> cat-inventory
<knittl> git ls-tree also uncompresses the files :P
<poolie> cat-revision
<poolie> sorry that's just 'inventory'
<LeoNerd> The internals aren't really meant for people to go prodding at
<poolie> or open a python shell and poke at it
<knittl> LeoNerd: but i need to :P
<knittl> poolie: ok, that may help
<poolie> for curiousity?
<knittl> gotta go now, lunch time
<knittl> poolie: no, for my bachelor's degree
<poolie> i would use python
<poolie> easier to script examination of ti
<vila> spiv: http://babune.ladeuil.net:24842/job/selftest-maverick/3/ any chance you can produce a maverick version of your paramiko package
<vila> ?
<spiv> vila: sure
<vila> spiv: great ! I thought you were asleep :)
<spiv> I wonder what happened to my merge proposal for getting that patch added to ubuntu
<spiv> vila: will be soon, most likely :)
<spiv> vila: https://code.edge.launchpad.net/~spiv/+recipe/paramiko-test/+build/340
<vila> spiv: you rock !
<spiv> vila: I just pressed a button :P
<spiv> vila: hmm, build failed apparently.
<spiv> In some obscure (to me) way.
<spiv> Possibly it's just trying to tell me that the build-deps aren't right?
<spiv> Hmm, I guess I am trying to build the lucid version on maverick with that recipe, so I suppose that's not so surprising.
<vila> :-/
<spiv> I'll make a new recipe tomorrow.  Hopefully I can figure out a way to use one recipe to apply the same patch to multiple distro series.
<vila> spiv: ok, thanks
<knittl> can i delete .bzr/obsolete_packs directory safely?
<poolie> the contents of it
<knittl> ok
<knittl> thx
<poolie> pack --delete-obsolete-packs does this
<knittl> i don't want to repack again ^^
<knittl> i only find a description of knit pack repositories
<knittl> i know there exist several more formats
<knittl> maybe not repo formats, but also branch formats
<knittl> where can i find them?
<knittl> and there is really no easy built-in way to have a look at bzr's internals?
<poolie> use ipython
<poolie> works very well
<knittl> what is python?
<knittl> just a python-shell?
<lifeless> ipython
<lifeless> its an interactive python shell with tab completion
<knittl> docs.bazaar.canonical.com tells me to ask here :D
<knittl> i don't want to write a lot of python â¦
<jml> what's the constant for "null:"?
<lifeless> revision.NULL_REVISION
<lifeless> or something
<lifeless> knittl: if you want to use bzr without writing python you can:
<lifeless>  - use the xmlrpc server
<jml> thanks.
<lifeless>  - use java via jython or the xmlrpc server using bindings
<knittl> i prefer not writing anything
<lifeless>  - shell script it
<lifeless> I don't know what you mean by that
<knittl> the other dvcses all support some sort of debugprinting of repository structure
<lifeless> there is a repositorydetails plugin
<lifeless> or something-like-that
<knittl> ok, i'll google it
<knittl> hm no, statistics is not what i want
<vila> knittl: there is no out-of-box solution for what you want, the plugin lifeless metioned will give you the best basis to write your own, which will be warmly welcomed
<knittl> vila: ok, i'll have a look
<knittl> although i'm _a little_ behind schedule :D
<vila> knittl: giving a more precise explanation of what you want may help people help you find it
<knittl> vila: i'm comparing different dvcs for university
<knittl> and write about storage model, etc.
<knittl> mercurial has debugindex and friends
<knittl> git has cat-file commit, ls-tree and cat-file blob
<knittl> bzr has nothing comparable. at least i could not find it easily
<vila> knittl: great, you know hg and git, but here people knows bzr but not this level of detail about hg and git
<knittl> ppl here know bzr, so i thought i'd ask
<jelmer> knittl: I generally just use the Bazaar Python API
<james_w> there's dump-btree, but not a complete suite of such tools I don't think
<vila> so speaking about hg/git commands is not really enliHGtning
<knittl> james_w: ok, that sounds better
<knittl> although it segfaults here
<knittl> vila: you asked what i wanted to do, and i told you what i did in git and hg to give a comparison of what i've already done and which worked
<knittl> those were just examples. i want to view the storage model and write about it
<knittl> types of objects, interactions, references, compression, etc.
<vila> knittl: and I try to explain why you didn't get answers, if I failed, I'm sorry :)
<knittl> vila: i can't really find good documentation on bzr's storage model
<knittl> with google at least
<knittl> reading source code seems like an endless adventure
<knittl> but dump-btree suggests some form of binary tree
<vila> knittl: *today* it's either reading the code or asking precise questions which requires some basic knowledge
<vila> dum-btree will tell you which pack files are active for the repository
<vila> repodetails will give you more entry points and how to access them
<knittl> vila: i found my question rather precise
<knittl> but i'll have a look at repodetails for that matter
<poolie> knittl, ipytho
<poolie> run ipython
<knittl> before continuing complaining ^^
<poolie> from bzrlilb.bzrdir import BzrDir
<vila> knittl: my point is to explain why it wasn't precise enough to give you the answers you're after
<poolie> bd = BzrDir.open('.')
<poolie> then poke around in that object and follow links
<poolie> repo= bd.open_repository()
<knittl> vila: let's try this way: what objects uses bzr for storage of: commits, trees, files, tags, branches?
<vila> knittl: start here: http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief
<knittl> ok. thanks
<fullermd> Well, that's not gonna tell much about storage models  :p
<vila> knittl: continue there: http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInLength
<knittl> poolie: thanks to you too
<vila> fullermd: it will give him the right words :)
<vila> fullermd: and the entry points
<vila> I'm not going to write the doc about the bzr data model right now and here :)
<poolie> knittl, if you write docs and post them to the list we can correct them
<vila> knittl: and keep in mind that bzr has used different formats with slight variations about the data model so you'd better focus on the last one: 2a
<knittl> vila: yes, i know that there were different formats
<knittl> but i can only find information on how to convert a repo, not about the exact differences between them
<knittl> but now i'll read those wiki pages
<knittl> thx
<vila> I think jam blogged about the most important points in 2a
<vila> knittl: chk maps and group compress
<knittl> btw, are there any books about bzr?
<knittl> the last time i looked i couldn't find a single one
<jelmer> knittl: There are no books yet
<knittl> jelmer: ok. bad for me :(
<vila> jam: ping
<jelmer> knittl: Yeah, we should fix that at some point :-(
<jam> hi vila
<vila> hey jam, I thought you mentioned a ppa with a python-2.7 from barry but I can't find it
<vila> jam: I have a maverick slave setup on babune on the test suite ~passing there
<jam> vila: ppa:doko/toolchain
<jam> has maverick I believe
<jam> and one of barry's starts making python2.7 as part of 'python-defaults'
<jam> I don't really know the state
<jam> so something like
<jam>  sudo add-apt-repository ppa:doko/toolchain
<jam> sudo apt-get update; sudo apt-get install python2.7
<jam> vila: ^^
<vila> jam: almost done
<vila> I need python-2.7-dev too I presume
<vila> jam: I fixed 2 of the 3 failures on maverick if you want to review the patch ;-)
<vila> hmm, default python is still 2.6.5+ but python2.7 is in the path
<jam> vila: right, python-defaults describes what pythons are *available* as well as which is default
<jam> the goal for maverick is 2.7 available-but-not-default
<jam> vila: already reviewed the http one
<vila> sure, I wasn't sure what the ppa was doing
<jam> 3 times
<vila> jam: cool, argh, sry for the second one then :)
<vila> jam: so, since I override BaseHTTPServer, I closely followed what was done there, specifically the atttributes are used only by this method so putting them far away... make them *less* discoverable
<jam> vila: though it doesn't conform to *our* style guide, which makes it harder for me as a bzr-hacker
<jam> (not positive what style says, but we do avoid local class members)
<jam> certainly it can be a bit tricky to recognize the ident level
<vila> jam: inherited design
<vila> jam: since we don't define the base class it's hard to follow *our* rules
<vila> I can *delete* them even if that's make you more happy
<jam> vila: it is *our* code...
<jam> vila: ultimately, I'll let you decide.
<jam> I just saw that and noticed that I find that kind of code hard to read.
<vila> jam: try the base class for fun :-/
<vila> jam: the responses attribute is the last one defined in the class after all existing methods and attributes
<vila> gee, lp is... capricious today
<jam> vila: what's up for you?
<vila> landing the fixes and running the test suite with py27
<jam> vila: I mean what is going wrong with lp for you
<vila> timeouts on mps
<vila> but transient ones
<vila> argh, no pyrex...
<vila> jam: what's the status across bzr/testtools regarding unittest._WritelnDecorator ?
<jam> vila: we dropped some timeouts in the lp code
<jam> vila: lifeless mentions "can you please file a bug including the OOPS info"
<jam> (from 17+s down to ~12s)
<vila> I didn't get OOPS, only 'try again later'
<jam> you're in the beta tester team, right? (edge urls not regular ones)
<vila> yup
<jam> vila: there should have been an "OOPS-XXX" string in the try-again-later page
<ubot5> https://lp-oops.canonical.com/oops.py/?oopsid=XXX
<jam> but if you missed it that is ok
<jam> mentioning that mp's are timing out is still useful
<vila> jam: the pages are long gone
<jam> vila: sure. Robert is pushing hard on lp performance, and trying to get that into the culture
<jam> so expect some teething
<vila> I thought the OOPS were reported to devs anyway, I didn't think I should poke especially for transient ones
<lifeless> vila: for future ref' please make sure there is a bug with the oops number in it.
<jam> vila: they get 100s of oops per day
<lifeless> robots cause oopses
<jam> unfortunately
<lifeless> but robots don't file bug
<lifeless> s
<vila> lifeless: ok
<jam> having poked at the code recently
<jam> there are quite a few bits that are doing big scans and pulling out only a row or two
<jam> which after the data is in memory, aren't that bad
<jam> which are hard to push hard on
<jam> btw vila, thanks for giving me access to saw, it means I can test meliae on a 64-bit platform easily :)
<vila> jam: keep in mind I'll shut it down Thursday
<jam> vila: for good? or just for a while?
<jam> anyway, probably heading out to dinner now. Have a good evening
<vila> jam: just during my vacations :)
<vila> jam: you too !
<adiroiban> Hi, any idea why I get - "wpad://": No host component
<adiroiban> this is on a bzr-svn branch
<adiroiban> and yesterday I was able to work on that branch
<jelmer> adiroiban: Hi
<jelmer> adiroiban: That's odd - can you paste a traceback?
<jelmer> adiroiban: is "wpad://" part of a URL you're working with?
<adiroiban> no
<adiroiban> the url is http://adi@svn.roiban.ro/project
<Meths> On windows?
<adiroiban> i tried bzr push http://adi@svn.roiban.ro/project
<adiroiban> but same result
<jelmer> adiroiban: a backtrace would be useful - if you don't get one on the command-line -Derror should help.
<adiroiban> http://paste.ubuntu.com/466561/
<adiroiban> I am now on Karmic with python 2.6 as default python version
<jelmer> Any proxies involved?
<lathiat> I am guessing that you have set a proxy in the Ubuntu settings
<lathiat> which gets imported into the shell variables, go
<lathiat> export -a |grep wpad
<lathiat> sorry just
<lathiat> export|grep wpad
<adiroiban> jelmer: yep.
<adiroiban> not sure who has defined that variable
<lathiat> if you set it in ubuntu proxy settings theres something in the gnome session thing that sets it
<adiroiban> thanks for the help. That was the problem. Web Proxy Autodiscovery Protocol was somehow set in gnome.
<jelmer> makes for one hell of a confusing error though :-/
<lifeless> hey jelmer, thanks for your note.
<lifeless> are you back home ?
<jelmer> hi lifeless
<jelmer> lifeless: yep, got back late on Sunday
<lifeless> cool
<jelmer> are you still in Europe or just jetlagged ? :-)
<lifeless> #launchpad-dev on this network might be worth adding to your joinlist
<lifeless> in prague
<jelmer> lifeless: I'm there actually, as rinze
<lifeless> why not as jelmer ?
<jelmer> I use two different IRC clients these days, in an attempt to keep work and private stuff separate
<lifeless> ah
<GaryvdM> Hi lifeless and jelmer
<lifeless> hi GaryvdM
<GaryvdM> How was the sprint?
<jelmer> 'evening Gary
<lifeless> GaryvdM: great
<GaryvdM> lifeless: Good to hear.
<GaryvdM> Hi mgz.
<alkisg> Hi, can I tell bzr to ignore *.dcu but still clear them with bzr clean-tree?
<GaryvdM> alkisg: Use bzr clean-tree --ignore ?
<GaryvdM> sorry bzr clean
<GaryvdM> sorry bzr clean-tree --ignored
<alkisg> Thank you GaryvdM, that looks to be what I want.
<mgz> hey GaryvdM if you're still up. I'll give your 2.2b4 installer a go.
<stupenrose> Hi everyone.  I'm migrating some svn stuff to bzr using bzr-svn.  I'm running into a problem with a few of my svn branches.  Basically, I get an error like so:
<stupenrose> stu@ruth:/home/stu# bzr branch http://my-svn-server.com/project-name/trunk
<stupenrose> bzr: ERROR: The branch http://my-svn-server.com/project-name/trunk has no revision None
<stupenrose> Anyway, I found some old bugs that seemed to match my symptoms, but they appear to have been fixed.  https://bugs.launchpad.net/bzr-svn/+bug/233964  https://bugs.launchpad.net/bzr-svn/+bug/295284 https://bugs.launchpad.net/bzr-svn/+bug/364416
<ubot5> Launchpad bug 233964 in Bazaar Subversion Plugin "The branch FOO has no revision None. (affected: 0, heat: 0)" [High,Fix released]
<stupenrose> running "bzr --version" gives:
<stupenrose> Bazaar (bzr) 2.1.1
<stupenrose>   Python interpreter: /usr/bin/python 2.6.5
<stupenrose>   Python standard library: /usr/lib/python2.6
<stupenrose>   Platform: Linux-2.6.33.5-rscloud-x86_64-with-Ubuntu-10.04-lucid
<stupenrose>   bzrlib: /usr/lib/python2.6/dist-packages/bzrlib
<stupenrose>   Bazaar configuration: /root/.bazaar
<stupenrose>   Bazaar log file: /root/.bzr.log
<stupenrose> Copyright 2005-2010 Canonical Ltd.
<stupenrose> http://bazaar-vcs.org/
<stupenrose> bzr comes with ABSOLUTELY NO WARRANTY.  bzr is free software, and
<stupenrose> you may use, modify and redistribute it under the terms of the GNU
<stupenrose> General Public License version 2 or later.
<stupenrose> Bazaar is part of the GNU Project to produce a free operating system.
<stupenrose> Anybody else run across this?
<mgz> if noone who knows bzr-svn shows up shortly, file a bug with the full traceback from .bzr.log and a link to your svn server if it's public
<stupenrose> ok.  I'm working through the 'file a bug' wizard now.
<jelmer> stupenrose, hi
<stupenrose> howdy!
<jelmer> stupenrose: what version of bzr-svn?
<stupenrose> lemme see...
<stupenrose> according to 'bzr plugins': svn 1.0.2
<knittl> how are revids in bzr calculated
<jelmer> knittl: They're globally unique per revision
<jelmer> knittl: How they're generated depends on the way the commit is created
<jelmer> knittl: if they're native commits made by "bzr commit" they're pseudorandom (formed from email-address, timestamp and randomized string)
<toabctl>  i downloaded a package with "bzr branch lp:ubuntu/xf86-input-wacom" , changed the package to a new upstream version and want to push th package now back to launchpad and send a merge request. how can i push the package to launchpad?
<jelmer> knittl: commits imported from bzr-svn for example use the branch path, repository uuid and revision number
<knittl> aha. ok
<knittl> so no hashing?
<knittl> like 'identical' commits will give the same revid
<jelmer> knittl: Hashes for each revision are stored but they are not used to address the commit
<jelmer> only for integrity checking
<jelmer> (hashes are bound to a particular serialization of commits)
<knittl> i see. thanks
<stupenrose> mgz: you mentioned including the full traceback from ."bzr.log" ... I'm not seeing such a file.  In my case, it fails before the branch is fully created, so there isn't really a .bzr directory.  I do have an assosciated repo dir, but I don't see such a log there either.  What am I missing?
<mgz> <stupenrose>   Bazaar log file: /root/.bzr.log
<stupenrose> ah, I see.  thanks.
<mgz> if you don't have write access to that location, set BZR_HOME to somewhere you do, and run the attempt again
<mgz> though, jelmer is the right person to talk to if you can get his attention again
<stupenrose> roger that.
<stupenrose> jelmer: should I file a bug for this one?
<jelmer> stupenrose, does your repository contain any revisions created by bzr-svn?
<stupenrose> I believe so.  If you're asking whether I've pushed commits out to svn using bzr: yes.
<stupenrose> If you're asking whether my /bzr/ repository hosts bzr-svn branches, the answer is also yes.  Though, as far as that goes, I've tried branching these problem branches without using my bzr repo, and the result is the same.
<jelmer> stupenrose: please file a bug
<stupenrose> ok.  will do.  thank you for your help.
<jelmer> stupenrose: it would be useful to have the full backtrace though, that might require commenting out some code in bzrlib/builtins.py
<stupenrose> does this look like it is full enough?:
<stupenrose> Tue 2010-07-20 16:29:03 -0400
<stupenrose> 0.038  bazaar version: 2.1.1
<stupenrose> 0.038  bzr arguments: [u'branch', u'http://svn.cmaxdev.com/fortress/trunk', u'test1234']
<stupenrose> 0.044  looking for plugins in /root/.bazaar/plugins
<stupenrose> 0.044  looking for plugins in /usr/lib/python2.6/dist-packages/bzrlib/plugins
<stupenrose> 0.133  encoding stdout as sys.stdout encoding 'UTF-8'
<stupenrose> 0.168  bzr-svn: using Subversion 1.6.6 ()
<stupenrose> 1.808  Traceback (most recent call last):
<stupenrose>   File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 853, in exception_to_return_code
<stupenrose>     return the_callable(*args, **kwargs)
<stupenrose>   File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 1055, in run_bzr
<stupenrose>     ret = run(*run_argv)
<stupenrose>   File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 661, in run_argv_aliases
<jelmer> stupenrose: please don't paste lots of lines of text but use pastebin instead next time :-)
<stupenrose> sorry: I be IRC newbie.
<jelmer> stupenrose: In particular the full error message - the actual revision id rather than "None"
<stupenrose> (it all comes through on one line with jabber)
<stupenrose> I've got builtins.py up in vim: any hints as to what needs to be commented-out?
<jelmer> in the cmd_branch class, there should be a place where we catch NoSuchRevision
<jelmer> and instead we raise a different revision (BzrCommandError I think)
<jelmer> just re-raise the original exception
<stupenrose> ok
<jelmer> s/different revision/different exception/
<stupenrose> ok.  I think I did it right.  this look better? http://pastebin.com/hNuLCDDi
<LeoNerd> Anyone happen to know if bzr-git supports 'bzr branch URL' from any branch other than the head?
<LeoNerd> I'm finding docs rather thin on the ground, also
<jelmer> stupenrose, yep, thanks
<stupenrose> cool. okey doke, I'll include that with the bug.  thanks again!
<jelmer> LeoNerd: It does, but bzr doesn't have a UI for addressing such branches yet
<LeoNerd> Ooh... hmmm.. I thought I'd try   bzr branch http://.../foo.git/branchname   but that didn't work
<LeoNerd> Any way to abuse it into doing so, or am I ought of luck here?
<jelmer> LeoNerd: http://.../foo.git,branchname should work in the future (bzr 2.3 hopefully)
<LeoNerd> Ahhh
<stupenrose> FYI, bug entered: https://bugs.launchpad.net/bzr-svn/+bug/607986
<ubot5> Launchpad bug 607986 in Bazaar Subversion Plugin "bzr-svn: The branch http://my-svn-server.com/project-xyz/trunk has no revision None. (affected: 1, heat: 6)" [Undecided,New]
#bzr 2010-07-21
<cjmason> so, is this a good place to ask questions specifically about bzr-svn?
<cjmason> specifically, if the cache format recently changed?
<spiv> This is a good place, yeah.
<parthm> i am trying to write a unittest which creates a file. however the file gets created in the dir where ./bzr selftest is run ( http://pastebin.com/Krchr7LA )
<parthm> so self.assertFalse(os.path.isfile(get_filename())) fails on the second run. how do i create the file in the temporary test dir?
<spiv> parthm: base your test case from TestCaseInTempDir (or one of its subclasses)
<spiv> Then when your test method is run the cwd should be the temp dir
<parthm> spiv: ah. thanks. i will do that.
<spiv> So do that and then simply make sure you write the file relative to the cwd.
 * spiv is off for the day
<lifeless> moin
<parthm> lifeless: hi
<MTecknology> so... I just screwed up about an hours worth of work.. Is it possible to change the commit message for a whole lot of commits?
<MTecknology> That's actually the only thing I screwed up
<spm> uncommit, commit?
<MTecknology> spm: can I uncommit a few changes and then apply the commit message to each commit that I just unrolled?
<lifeless> if you haven't done a merge, yes, by shelving at each step
<spm> maybe depending on how much faffing around you do; sure. at worst you create a diff up front for each commit since the busted and then reapply the lot. painful, there may be easier.
<MTecknology> at some point I need to learn how to shelve..
<MTecknology> I should have tagged these as I went too
<MTecknology> alrighty, thanks
<m3ga> for bzr-git, what happens to tags in the git version?
<m3ga> can i branch from and merge from a git tag?
<parthm> i was curious about the deprecation policy of bzr api. if something gets marked "deprecated in 2.2" ... is it removed in 2.3, 2.4 or later?
<parthm> i couldn't find this info in hacking.txt
<lifeless> whenever its really annoting
<parthm> so for e.g. re_compile_checked is deprecated_in((2, 2, 0)) ... will it be removed in 2.3?
<lifeless> if its really annoying by then
<lifeless> its an individual choice
<lifeless> fast removal == leaner code, worse for plugin authors
<lifeless> slow removal == fatter code, nicer for plugin authors
<parthm> lifeless: so the preference is to keep it around for a few releases if its not a very annoying. ok. makes sense. thanks for clarifying.
<mgz> ha, parthm
<mgz> you free to be distracted?
<parthm> mgz: hi
<mgz> you've been messing with regexps, might you know the cause of these failures?
<mgz> http://float.endofinternet.org/xmlbin/dev_r5355_non_per#bb.test_log.TestLogErrors.test_log_bad_message_re
<mgz> http://float.endofinternet.org/xmlbin/dev_r5355_non_per#bt.test_globbing.TestGlobster.test_bad_pattern
<parthm> mgz: re.compile is supposed to be lazy. looks like its not being lazy in this case.
<parthm> i think i saw something similar even on linux and forced lazyness for a test case. let me dig that up.
<mgz> you had a test problem recently with it becoming un-lazy part way through the run didn't you?
<mgz> did you track that down?
<mgz> ...you might be able to tell I'm a little overwhelmed by bzr email currently, I know bits of lots of what's going on but don't remember any of it clearly :)
<parthm> :)
<parthm> mgz: basically in lazy_regex we now catch re.error and throw errors.InvalidPattern instead. so in this case it looks like re.compile is compiling immediately.
<parthm> hence, re.error is not caught and gets thrown instead of InvalidPattern.
<mgz> okay, so I guessed the cause right, and you are the right person to bug about this as well?
<parthm> mgz: i am unable to locate where if faced this issue (it was some test case). as it was just a test case i could get away with calling lazy_regex.install_lazy_compile()
<parthm> :)
<parthm> mgz: what platform is this on?
<mgz> says at the top of the page :)
<parthm> ahh :)
<mgz> okay, so you fixed the symptom by making a test that needed laziness (re)install the lazy, but you didn't track down which case was unlazying and not cleaning up after itself?
<parthm> mgz: yes. you can say that :P
<parthm> mgz: test_osutils.TestReCompile.test_re_compile_checked_error
<mgz> I see.
<parthm> interestingly thats the only case for which i saw this problem and re_compile_checked function is deprecated so i seemed ok to do that. looks that all tests see this on win32.
 * mgz bops parth on the head for cheating like that
<mgz> yeah, the platform varience does seem a bit odd
<parthm> mgz: i can try to look into this. though i am not sure whats causing this ... could be lazy_regex or maybe something to do with the test suite.
<mgz> I'm on it.
<mgz> ah, okay, I understand this now.
<parthm> mgz: its weird. i am interested in knowing whats causing this. thanks for looking into this.
 * parthm needs to be more careful with his tests
<mgz> tests don't generally *require* lazy regexp
<mgz> in fact, the test_lazy_regexp makes sure to clean up after itself
<mgz> your nicer error messages thing *does* require laziness, which then means those tests you changed should do the same
<parthm> mgz: are you saying that the test setup specifically disables laziness?
<mgz> no, but previously no test actually needed it it seems
<mgz> and as it gets turned *off* by test_lazy_regex that's a good thing
<parthm> mgz: so test_lazy_regex turns if off but never turns it (lazyness) on again.
<mgz> right, but that's not actually the problem
<mgz> the problem is with your change, if selftest is run through the bzr script, it does:
<mgz> # instruct bzrlib/__init__.py to install lazy_regex
<mgz> sys._bzr_lazy_regex = True
<mgz> but if it's *not* run through the bzr script, you've now got tests that fail because they silently assume the lazy
<mgz> so, really both your changed tests and these old lazy ones should cope with either state cleanly
<parthm> mgz: ah. maybe behavior of lazy_regex module should be lazy always unless the called explicitly disables laziness or calls _real_re_compile?
<mgz> maybe just self.overrideAttr(re, "compile", lazy_regexp.lazy_compile)
<mgz> in tests that need the lazy now.
<parthm> mgz: updating the tests would definitely work but the module behavior being somewhat unpredictable in terms of laziness seems a little odd.
<mgz> well, the problem is it's a monkey patch parth, the point is you can't really rely on it
<mgz> currently, someone running the bzr script will have it, but someone importing bzrlib won't
<mgz> so, I guess the remaining question is whether any of the bits of bzrlib code you've changed now break if re.compile is eager
<FryGuy-> is the guy that did bzr-tfs in this channel?
<parthm> mgz: i would think that if anyone is using g=Globster(patterns) ; g.match  sequence directly would be impacted by this (won't get InvalidPattern)
<mgz> so, should the Globster code be changed to use lazy_regex.lazy_compile directly?
<parthm> mgz: won't it be better to just do this at bzrlib level.
<mgz> you tell me! :)
<parthm> mgz: i think it may be better have  lazy behavior by default at bzrlib level. at the moment InvalidPattern gets raised only in globbing.py and lazy_regex.py but in case there is some other function there gets updated to handle this and give a custom message there may be a problem.
<mgz> I'm trying changing bzrlib.globbing now
<mgz> ...guess I ought to file a bug here, there are some non-obvious choices to be made
<parthm> mgz: lazy_regex.LazyRegex._real_re_compile catches re.error and raises InvalidPattern. ... so anytime _real_re_compile is bypassed we will get this.
<parthm> filing a bug sounds like a good idea
<mgz> oh boy that's some bad naming
<parthm> mgz: which one specifically :)
<mgz> _real_re_compile is both a module global containing the real re.compile, and a method that thunks
<parthm> mgz: ahh. yes. i noticed that.
<mgz> I couldn't parse your sentence till I worked out you were talking about the *method*
<parthm> mgz: maybe we should be monkey patch the non-lazy re.compile also to raise Invalid pattern. so irrespective of the lazyness status bzr always shows the clean error message.
<mgz> meh, no.
<mgz> I think we should make places in bzrlib that care use lazy_compile directly.
<parthm> mgz: in that case i think doing it at bzrlib.globbing level may work fine.
<mgz> the failure in bb.test_log is worrying me currently
<mgz> where's the exception raised by the invalid pattern meant to be caught?
 * parthm looks at the stack trace again and starts opening files
<mgz> I don't really understand how that exception is propogating at all, run_bzr should catch everything...
<parthm> mgz: is laziness being set in this case?
<mgz> no. it's the plain re.compile
<mgz> sre_constants.error is a subclass of Exception, so it should get caught...
<parthm> mgz: so run_bzr just logs the exception? is selftest failing in this case?
<mgz> well, it should convert it to a failure return code, which that top line is expecting...
<mgz> darn blackbox tests, pain to debug
<mgz> ah, I see it. bzrlib.commands.run_bzr_catch_user_errors is pickier than run_bzr_catch_errors
<mgz> might mean it's not a regression from your changes, I'll run these tests against a bigger history
<parthm> mgz: ok. so would you be patching bzrlib.globbing for installing laziness?
<mgz> I'm going to propose that, it's maybe not the smartest alternative though
<mgz> okay, need to get these tests running then file bug, then commit changes
 * mgz beavers
<parthm> mgz: thanks for looking into this.
<mgz> okay, looking at the diff of r5339 now I get it.
<vila> hi all !
<vila> mgz: hey
<mgz> morning vila!
<vila> mgz: why not: test passing, commit, file bug ?
<vila> just curious
<mgz> --fixes
<vila> OIC
<vila> I do: file bug, branch bug#, test, hack, test, commit :-P
<mgz> right, I should have filed the bug a long time ago, but I thought this was a shallower issue than it was
<mgz> like, change a couple of setup lines in some tests, rather than actual logic
<vila> yeah, I have that bad habit to file bugs too late :-0
 * mwhudson is using a packs branch for a change
<mwhudson> some things have definitely gotten better :-)
<mgz> oo, vila, vila: can you try Python 2.7 again?
<vila> mgz: same branch ?
<mgz> I left a note last night about what went wrong the first try
<mgz> yeah, bzr is unchanged, need to fiddle with testtools though
<vila> mgz: I just read that, but it's unclear about which *previous* testtools version you're talking about
<mgz> move a closing bracket left a bit :)
<mgz> ah, er, well, either 0.9.2 or the one line patch for the linked bug
<vila> ok, one-liner aplied, launching a run
<vila> hu ho
<vila> I left 2 VMs running yesterday blocking the whole process :-/
<vila> mgz: here is yours: http://babune.ladeuil.net:24842/job/selftest-maverick/8
<vila> mgz: http://babune.ladeuil.net:24842/job/selftest-maverick/8/consoleFull shows some weird stuff, looks like subunit leaks in the wrong stream
<vila> or testtools :-/
<vila> I wonder if my setup is a bit screwed when it comes to take source changes from the master to a slave...
<vila> argh, yes
<vila> or not
<vila> python use .py if it finds it more recent than .pyc right ? Especially when it can't write the .pyc ?
<mgz> right.
<mgz> not just more recent, any mtime difference
<vila> with the one embedded in the .pyc, ok
<vila> mgz: the setup for slaves os to use testtools and subunit from an automounted read-only fs, I got weird results yesterday after an update, if the results are too weird for you run I may just re-try it before worrying
<vila> mgz: it seems to be stucked anyway which qualifies as weird :)
<mgz> yeah, give it another bash.
<mgz> parthm: looking at this some more, I'm not really sure the bug I just filed is seperable from yours
<vila> mgz: http://babune.ladeuil.net:24842/job/selftest-maverick/9/
<vila> hmm, still leaking
<mgz> any fix I attempt here is going to be clashing with your follow up, and really the hard decide-y bits need to be done in the design of your error wrapper
<mgz> vila: might be 2.7 related... there are a bunch of changes in unittest and logging, one of them might have upset something
<vila> mgz: it seems that skipped tests only have their reason leaking
<vila> or their log
<vila> but definitely skipped only so far
<parthm> mgz: yes. there is a fair amount of overlap.
<mgz> I'll compare the exception class definitions
<mgz> parthm: what you need to choose I think, is 1) what to use when you want an eager, user-error rasing re.compile like log needs, and 2) whether Globster should be raising from the constructor or from the method call if given invalid pattersn
<vila> mgz: reason. log. traceback, the whole shebang, some excerpts here: http://paste.ubuntu.com/466825/
<mgz> gah, I can't multitask at all
<vila> mgz: sorry for the very long lines :-/
<vila> mgz: sheesh, have some coffee :)
<mgz> good advice :)
<vila> mgz: and now it seems the whole stream is diverted somehow :-/
<vila> mgz: starting there: http://paste.ubuntu.com/466826/
<mgz> can we get subunit out of the mix for the moment?
<mgz> doubt anyone has even tried it with 2.7 yet.
<parthm> mgz: i would say the api user should be able to choose between lazy/eager compile. e.g. compile_p = lazy_regex.compile_lazy() vs compile_p = lazy_regex.compile()
<parthm> e.g. the is_pattern_valid API introduced in https://code.launchpad.net/~parthm/bzr/300062-2.2-bad-pattern-error-part-2/+merge/29949 requires eagerness
<parthm> so it ends up doing p = re.compile() ; p.match( "")
<parthm> i have seen the same pattern in re_compile_checked.
<parthm> osutils.re_compiled_checked.
<parthm> so, as a user one can be sure of lazy vs eager.
<vila> argh, ff blowing up trying to catch up with the far-too-big stream :-.
<vila> mgz: and finally the run aborted with: 'ERROR: Failed to archive test reports' which sounds fully related
<vila> parthm: Are you ok with marking https://code.edge.launchpad.net/~parthm/bzr/300062-2.2-bad-pattern-error-part-2/+merge/29949 WIP ?
<parthm> vila: sure.
<vila> parthm: thanks ! I've also added a comment there
<parthm> vila: thanks for reviewing this. when you say 'regular keys' do you mean user lower case or something else?
<vila> I mean strings instead of the indirection via symbols to get ints
<parthm> vila: ah. ok. sounds like a good idea. i will do that.
<vila> parthm: but more importantly, grouping the attributes instead of having several arrays/dicts all over the place
<vila> parthm: some functions may still want to have some local dicts for special purposes though
<parthm> vila: yes. i will try to clean that up ... maybe a string->tuple dict.
<vila> or may be the key should become an attribute of an extended regexp object... I haven't dig the code enough to say
<vila> parthm: yup  string->tuple dict may be a good start and present things in a cleaner way
<vila> and that may be enough, you'll see
<parthm> vila: i agree with you point about making it easy for plugins to add their own pattern types. once this patch it done it may be possible to provide an api to do that.
<vila> parthm: excellent, I wanted to do that for a long time but never managed to find the time :-/
<mgz> okay, coffee obtained.
<vila> parthm: bzr-upload is such a plugin, so I'm not talking about an hypothetic (sp?) case here
<parthm> vila: oh. thanks for letting me know. i wasn't aware that bzr-upload does this. i will look at it and try to understand the requirement better.
<vila> parthm: the use case for bzr-upload is that we want to exclude some paths to be processed (substitute process by add for bzr, roughly)
<parthm> vila: ok.
<mgz> vila: not sure I see that marking the selftest 2.7 branch WIP was needed
<poolie> hey there vila, mgz
<vila> hey poolie
<poolie> barry is talking in prague about 2.7 ! :)
<poolie> one interesting change, deprecationwarning off by default
<mgz> there seem to be various other 2.7 issues, but the only change wanted in response to jam's review is making an evil one liner more readable
<vila> mgz: I explained it in a later comment: this can't be landed as is and requires some dependencies so I'd like that to be sorted out
<vila> mgz: and switching to WIP makes it more obvious when a branch needs to be re-reviewed
<mgz> it could be landed... it's just possibly not sufficient
<vila> mgz: no, the run doesn't even finished cleanly
<mgz> but... that's subunit! :)
<vila> mgz: now if you can demonstrate it comes from testtools/subunit, I'd be happy to reconsider
<vila> hehe, exactly my point ;)
<vila> mgz: That's why I said: 'this is clearly going in the right direction' :)
<mgz> poolie: is it the kind of talking that gets recorded anywhere?
<vila> mgz: OMG no ! You should not even knows about it, we'll need to kill you now !
<poolie> hm i don't know
<vila> joke aside, no, I don't think it's recorded, but it would be nice
<poolie> it could be
<poolie> i can ask him to put his slides up at least
<vila> poolie: that would be awesome
<mgz> vila: working out what to blame for that babune issue is why I was asking about if you could try a run without subunit
<mgz> as in, just bzr selftest and pipe to a file or something
<vila> mgz: marking it WIP doesn't mean I won't run as many times as you asked for
<vila> mgz: I'm running you fix against testtools on all slaves currently, just to make sure
<poolie> vila i was thinking perhaps the texinfo docs should say on the title page
<poolie> "this was converted using a beta rst->texinfo converter, the links are wrong"
<poolie> or something similar
<poolie> to avoid roundtrips of people reporting it
<vila> poolie: excellent
<mgz> was just trying to understand the reasoning - if the branch was borked on 2.6 I'd not have questioned the flip, just wasn't sure if that was the case
<poolie> and to put the blame on the convertor not us :)
<mgz> the testtools change should be fine, but it's not the kind of thing that gets tickled unless there are failures
<vila> poolie: on the other hand, we don't produce the '.info' files right now, so people can't see them, they have to create them from the '.texinfo' themselves
<mgz> and the testtools suite *passes* on 2.7, but it does have holes so don't think I want to go as far as vouching for it...
<vila> mgz: http://babune.ladeuil.net:24842/job/selftest-hardy/lastFailedBuild/console
<vila> mgz: it's a bit unclear to decide if it's related
<vila> but 'Ran 1892 tests in 52.523s' is worrying
<mgz> urk, yeah, died part way through
<vila> and the last test before that was.... : ERROR: bzrlib.tests.per_transport.TransportTests.test_put_file_unicode(FtpTransport,UnavailableFTPTestServer)
<vila> hello unicode...
<vila> _StringException: lost connection during test 'bzrlib.tests.per_transport.TransportTests.test_put_file_unicode(FtpTransport,UnavailableFTPTestServer)'
<vila> mgz: the gentoo one succeeded though...
<mgz> I'm NODEP on (FtpTransport,UnavailableFTPTestServer) locally
<vila> mgz: and the freebsd one just succeeds too
<vila> mgz: now that you mention it....
<vila> I would have swear hardy was NODEP too on ftp server...
<vila> mgz: right, hardy is NODEP too
<vila> mgz: that won't be the first time NODEP and SKIP have a common failure mode
<mgz> okay, I could understand a problem there for 2.7 but this is back to default python, right?
<vila> right
<vila> but with your patch on testtools (may be unrelated but the window is quite narrow: I updated testttols/subunit yesterday so I'm running trunk for both)
<mgz> grepping the last hardy success log seems to have "... ok" though for that test
<mgz> shouldn't it print nodep if it's lacking it?
<vila> mgz: because a fake server is provided to trigger a skip... err, wait
<vila> hmm, from memory, there is a trick there
<vila> something like TestSkipped raised during setUp, I'm pretty sure I fixed something in the past but testtools may behave differently
<mgz> karmic failed the same way.
<mgz> so, something real is clearly borked.
<vila> bad bad bad
<vila> re-trying hardy
<mgz> poolie: test regression present for you too, which I also need to file a bug for
<mgz> http://float.endofinternet.org/bzrcst/clasregr/5191
<mgz> http://float.endofinternet.org/bzrcst/clasregr/5192
<mgz> http://float.endofinternet.org/bzrcst/clasregr/5228
<mgz> it's confusing, but related to renaming fancy_rename and directories
<vila> mgz: what is the problem with http://float.endofinternet.org/bzrcst/clasregr/5191 ?
<mgz> that's the known-good
<vila> ha ok :)
<mgz> flick between that and the one after to see the coloured dots change :)
<vila> mgz: hardy succeeded on retry... \o/ or >-/ ?
<mgz> >_<
<vila> lol
<poolie> am i being trolled by ben?
<mgz> on the list? /me reads
<mgz> ...yes
<poolie> it annoys me that his proposed patch was deleting whitespace
<poolie> i realize people need to get a toe in the water but that is the smallest possible toenail sliver
<poolie> thanks mgz
<poolie> vila i'll try to let you land the texinfo thing today
<vila> poolie: ok, I will look at adding a warning about the links in a few minutes (but I'm a bit worried about fallouts for tests)
<mgz> I take is os.rename(existing_dir_a, existing_dir_b) on nix just fails neatly?
<poolie> i think it renames it to a/b
<mgz> because fancy rename really gets its knickers in a twist on this...
<poolie> vila how about if you put the build product on the web somewhere?
<poolie> preferably even as .info?
<poolie> you're worried about test fallout if we land the texinfo change?
<vila> poolie: no, fallouts if had a generated boilerplate
<vila> poolie: no, fallouts if I had a generated boilerplate
<vila> meh
<poolie> really?ok
<vila> poolie: no, fallouts if I add a generated boilerplate
<poolie> it's just an idea
<vila> hehe, I had already implemented ignoring a boilerplate, so that should be trivial if the generated boilerplate is readable in the end result
<vila> poolie: done, only one test needed to have the boilerplate duplicated which is perfect since it will fail when we remove it
<poolie> mgz i'm kinda tired today but i don't understand which rev caused which regression
<mgz> ah, sorry, I'm still trying to work out the right behaviour with directory renaming to file the bug
<mgz> <poolie> i think it renames it to a/b <- not even that... seems that a just replaces b *if* b is empty, otherwise fails with errno 39
<mgz> r5192 is the regression, but it's not totally obvious what the right fix is from the diff
<mgz> hence trying to file a bug that makes sense
<mgz> and I got you to change a lot of 5192 already which complicates things, but I missed these tests till now
 * mgz not doing job of being annoying well enough
<vila> mgz: it's a tough job :)
<poolie> really babune should be doing it
<vila> poolie: that's what I said :)
<poolie> machines can be much more annoying than most humans ever can
<poolie> underline fail
<mgz> okay, looking at the *right* diff this time, maybe it is just os.rename->osutils.rename fallout
<poolie> wow that's a while ago
<poolie> I was wondering what i changed in rename recently
<mgz> see, very lax.
<mgz> at least I got round to looking my test output before the release though :)
<poolie> ouch
<poolie> well, thanks
<poolie> the difference in rename behaviour is annoying
<poolie> maybe we should explicitly specify what behaviour we want
<poolie> like rename(target_exists='error')
<mgz> it's annoying, in this case, os.rename(a, b) could just be os.remove(b); os.rename(a, b) and would do roughly what nix does
<mgz> but trying the renaming dance means it breaks down horribly
<poolie> oh, especially for case changes
<poolie> i suggest the kwarg because having it vary depending on whether you call transport.rename, os.rename, osutils.rename would be insane
<poolie> vila istm this sphinx code does not really belong in bzrlib
<vila> poolie: the main problem is that I'm not confident enough (yet) that we won't need special cases, so I'd like to have a fully working solution before proposing the texinfo builder/writer upstream
<vila> poolie: and then there is the problem of having the right sphinx deployed
<poolie> mm it may be the most pragmatic thing
<vila> poolie: one worthy goal might be to separate the docs from the core so we better control how to produce them (possibly on babune) for every platform/distro
<vila> poolie: but we are not there yet, one important pre-requisite step being to switch to sphinx officially (and really :)
<vila> poolie: 'most pragmatic' being starting in bzr-core or submitting upstream ?
<vila> poolie: also, I'd like to add more sphinx related tests so knowing how to write builder/writer is a good path towards this goal
<vila> poolie: tests like: did we get all our references right ? (identifying internal and external references for example)
<vila> poolie: we currently don't use the right kind of references for that and we already have wrong references
<vila> poolie: it's very easy to mistype a reference...
 * vila is a typo expert
<poolie> in the bzr tree seems pragmatic
<poolie> checking internal links would be cool
<poolie> so, do it!
<poolie> can you do two followons for me?
<poolie> put the rendered .info file on the lp download site
<poolie> and blog about it, with a link
<poolie> done
<vila> I was about to write an email with the script I use to produce the info fileSSSS
<vila> poolie: 223 files are produced today
<vila> poolie: and that's only for the english version
<poolie> sheesh, 223 info files?
<poolie> i don't remember them normally being that many
<vila> poolie: I want to group them into bigger info files but this is blocked by 1) a full switch to sphinx 2) being able to translate the refernces correctly since this require defining a layout
<vila> poolie: so a reference to a source document can be translated into a reference to the target document which has a different path that the source should not be aware of
<vila> poolie: we currently use references to the produced .html files (and there should be ~223 of them)
<vila> poolie: that's why I want to land this branch first or the submission will become un-readable with all these reference fixes
<mgz> okay, filed bug 608096
<ubot5> Launchpad bug 608096 in Bazaar "Windows transform regression with directory renaming (affected: 1, heat: 6)" [High,Confirmed] https://launchpad.net/bugs/608096
<mgz> should probably be targetted at 2.2 but I'll leave that for now, as it looks like a pain to fix in the Right Way
<mgz> anyone seen this for 2.2 trunk?
<mgz> TypeError: create_workingtree() got an unexpected keyword argument 'accelerator_tree'
<mgz> wait, no, that's my old bzr, probably a long-fixed bug
<poolie> i think so
<poolie> igc says hi to everyone
<mgz> hey igc.
<mgz> ...trying to update my bzr.dev branch on my old nix box to test this change has set loose the OOM reaper...
<mgz> will it work out bzr it to blame, or will it just keep killing apache repeatedly...
<poolie> mgz i wouldn't count on it, it's not all that smart IME
<poolie> vila, so shall i submit that?
<vila> poolie: what ?
<poolie> the texinfo branch
<vila> I submitted it after your approval, I'm finishing an email explaining how to generate the info files
<vila> AAAAARGH
<vila> pqm doesn't support looms :-(
<mgz> okay, this is like, my fourth attempt to use bzr to get this code on my nix box. one restart later, now using http transport and avoiding smartness like the plague
<mgz> if this one dies, I'm using frekin' rsync
<vila> mgz: you're not trying to update bzr using itself right ?
<mgz> nope, it's just an old box.
<mgz> %CPU %MEM    TIME+  COMMAND
<mgz> 99.3 62.3   4:09.16 bzr
<mgz> made it!
<lifeless> vila: it just needs a newer package
<lifeless> vila: release looms! get jelmer to do a package update and file an RT. (these are not serialised)
<jelmer> lifeless, EAMBIGUOUS: "release looms"
<mgz> just spent something ridiculous like two hours confirming that a change I was pretty sure was safe on nix actually is
<mgz> next time I need to remember to not use smart protocols, or pick a faster box
<vila> mgz: where is the smart server ?
<mgz> I tried it both ways.
<vila> mgz: :-/
<parthm> vila: anytime you have a spare moment https://code.launchpad.net/~parthm/bzr/300062-2.2-bad-pattern-error-part-2/+merge/29949 no hurry.
<mgz> hm, was exagerating, only one hour
<mgz> anyway, merge proposal up now, so can leave in peace.
<lifeless> jelmer: 'do a release of loom trunk'
<jelmer> lifeless: ah, ok :-) I thought "release looms" sounded a bit dark...
<maxb> Hrm. bzr-builder's source tree contains a plugins directory containing a builder symlink to ..
<maxb> This makes it impossible to use bzr multi-pull :-(
<jelmer> maxb, several plugins do, bzr-svn and bzr-git create such a directory as well
<maxb> builder's is actually checked into bzr
<maxb> Maybe I should teach multi-pull to avoid infinite recursion
<jelmer> that'd be awesome, it's the only reason I don't use it at the moment
<maxb> jelmer: btw, is https://code.edge.launchpad.net/~maxb/bzr-svn/fetch-svn-rev-info-progress-bar on your list for when you get time to review?
<jelmer> maxb: Somewhat. I'm a bit hesitant to change that code without tests, as we've gotten it wrong a couple of times in the past.
<maxb> On the plus side, it's only a progress bar :-)
<spiv> jml: btw, please talk to poolie if you have any opinions on goodness/badness of maintaining NEWS as file fragments
<parthm> mgz: ping
<jam> hi vila, just figured I'd say hello while we're still in the same TZ before you leave
<vila> jam: hi :-D
<mgz> parthm: pong, though I've lunch coming up in a bit
<mgz> parthm: one thing we've not explictly stated on the re.compile front so far - what we're worrying about only really matters for patterns supplied by the user
<mgz> so, though there are a lot of instances of re.compile most of those have constant str patterns that are known valid, so either lazy or eager works fine
<LaserJock> is it possible to downgrade the format of a shared repo?
<jelmer> LaserJock: Yes, provided the target format has all the features required to hold the repository's data
<LaserJock> jelmer: k, do you know what this format is: "repository: Packs containing knits without subtree support"
<LaserJock> I'm trying to get rid of these annoying upgrade notices when I pull from LP
<LaserJock> it looks like it doesn't like me using 2a for the repo format
<jelmer> LaserJock: it's not possible to just upgrade the remote repository to 2a as well?
<jelmer> I would recommend that as 2a is significantly faster and smaller than older formats.
<LaserJock> jelmer: sure, but I don't own any of these
<LaserJock> I'd rather not go hunting down random people asking for them to upgrade their repos
<LaserJock> is there any command that would set up the repo+branch just as it is on LP?
<jelmer> LaserJock: no, we don't have anything like that.
<LaserJock> k
<maxb> jelmer: btw, the current lp:bzr-svn does not work - the name atomicfile is referenced but not imported.
<jelmer> LaserJock: I think "Packs containing knits without subtree support" means pack-0.92 though
<LaserJock> ah, OK
<jelmer> maxb: Fixed!
<jelmer> maxb: (I already had a fix for that locally)
<maxb> I like this response time :-)
<LaserJock> darn, it won't let me go from 2a to pack-0.92, oh well, I'll just rebranch
<jelmer> LaserJock: Yeah, 2a has rich roots which are not supported by pack-0.92
<jelmer> LaserJock: There is an option somewhere to make the warning go away
<LaserJock> jelmer: oh yeah? that'd be useful too :-)
<m4n1sh> can anyone tell me what all options bzr serve --protocol=ARG takes
<maxb> Is anyone else noticing that progress bars are not cleanly being cleared from the terminal in 2.2beta?
<rellis> Hi everyone. I'm seeing this email from the bzr-email-notifier. Anyone know how to fix? NameMapper.NotFound: cannot find 'branch_name'
<rellis> seeing this message*
<maxb> Is there any incantation for "copy one file from another branch, including file-id" ?
<jelmer> maxb, there is "bzr add --file-ids-from"
<fullermd> You can [ab]use merge.
<idnar> hmm, I should make an alias for "bzr merge -r before:ancestor:trunk.. branch"
#bzr 2010-07-22
<sproaty> how come directories don't have the same revision ID as its children? e.g. I just commited to the dir "whyteboard" and it's last updated on january, rev 170 whereas its contents are at 305. I'd expect the dir to be at 305 too?
<sproaty> http://bazaar.launchpad.net/~sproaty/whyteboard/development/files
<spiv> sproaty: I think for directories the web viewer only shows when the directory entry itself last changed
<spiv> sproaty: so when it was created, or last renamed
<spiv> sproaty: I suspect it does that because it's cheaper to calculate than the last revno that any of its contents last changed.
<sproaty> yeah true, I guess a  large project with several hundred sub-dirs would take a while to generate the root page :)
<Phoenixz> I have a bzr branch with a number of tags. I want my WT to reflect the state of a certain tag, and after that I want the WT to be again in the latest version. How do I do this? I thought bzr switch, but that seems different
<fullermd> update
<Phoenixz> fullermd: bzr update tag 1.0.3 ?
<fullermd> bzr update -r<whatever>
<Phoenixz> fullermd: so I cannot specify a tag?
<Phoenixz> that would have been sweet :)
<fullermd> -rtag:1.0.3 (or possibly just -r1.0.3 in recent enough versions assuming you don't have a revno 1.0.3)
<fullermd> (which I don't THINK is possible...  I think the middle number is always natural)
<Phoenixz> fullermd:  bzr: ERROR: branch has no revision sven@fs-ex-20100714193341-nxxm4776w97sbaip
<Phoenixz> bzr tags shows the 1.0.8 tag to be revision 171.1.142
<Phoenixz> bzr update -r171.1.142
<Phoenixz> gives same kind of error
<maxb> Are you sure? I would expect a quite different error?
<Phoenixz> maxb: its whats on the screen.. dunno what it means though
<fullermd> Mmm.  That seems to be a bug in 2.1.x....  it works with bzr.dev.
<Phoenixz> fullermd: crap.. No way around
<Phoenixz> ?
<fullermd> It's getting all cranky about revs that aren't on the mainline.
<fullermd> Yeah, that's a 2.2 fix.
<fullermd> You could use bzr.dev or a 2.2 beta.
<Phoenixz> fullermd: now that I have you "on the line" anyway.. do you know a solution to this? I have a framework in a bzr branch, from there I created two other branches that use that framework to create a web system. Works flawless all but for one major problem
<fullermd> You could also use 'revert', though that has various uglier sides.
<fullermd> Eep!
 * fullermd gets off the line!
<Phoenixz> fullermd: I created this design because at various times we find bugs in the framework in the projects using that framework. So we fix the framework bugs in that project, so that we later can merge those fixes back into the branch that only contains the framework
<Phoenixz> fullermd: problem is, the merge from the project to the framwork branch will also copy all changes that are specific to that project to the framework branch, and I dont want those.. Up until now, I used "bzr revert" to kick out those changes, but it gets a bit labourous.. isnt there a better way to fix that?
<fullermd> Yes, that's ugly.  Doing that 'revert' has a lot of ugly side effects.  For one thing, you may not have the files in that new rev, but they're all in the history.
<fullermd> For another, that means the next merge of that framework up into the project will delete all the files too.
<fullermd> Ideally, you'd do it initially in the framework branch, then merge up as needed.
<fullermd> Of course, in practice that ends up impractical a lot of the time.
<Phoenixz> fullermd: yeah, so I've noticed.. once I start merging to the project again, it starts deleting all specific project files that I reverted in the merge to the framework
<fullermd> So your next best bet it to just cherrypick back the fixes, not do full merges.
<Phoenixz> fullermd: yeah, that is VERY impractical....
<Phoenixz> fullermd: would take up lots of extra hours, lots of human errors.. dont even want to think about it
<Phoenixz> fullermd: isnt it possible to have a merge filter in place, that would only merge those things NOT in the filter?
<Phoenixz> fullermd: so that it transparently will skip those directories that are specific to one project
<Phoenixz> ?
<fullermd> The short answer is "no"
<Phoenixz> Thats not really the answer I was waiting for... :)
<fullermd> Cherrypicking back the actual revs that fix stuff in the framework code is the rightest (or least-wrong) option in practice.
<fullermd> It may lead to a few blips of spurious conflicts when you merge back, but that's manageable.
<fullermd> Well, OK, there's the other answer, which is "use darcs"  ;p
<Phoenixz> fullermd: THAT is a surpise answer... :)
<Phoenixz> fullermd: and why not "Lets implement that in bzr"? :P
<Phoenixz> fullermd: thing is, I got BZR control finally implemented in a development library here.. from the site I can do commits, with library version updates, etc... saves lots of time.. just re-wrote it from SVN.. would hate having to make another one for DARCS now :)
<Phoenixz> and truth be told, I kinda like BZR :P
<fullermd> Well, because in a fundamental-world-model sense, there are two classes of VCS's; there's darcs, and there's everyone else.  And this sort of thing (arbitrary subsets of revisions) is basic to the darcs worldview, and anathema to everyone else.
<fullermd> I was being rather more facetious than serious   :p
<Phoenixz> fullermd: hehehe.. okay, but what are my options here then? I dont want to have to work on 2 projects at the same time, testing for bugs in one, and then fixing them in another.. thats rather.. horrendous..
<fullermd> Do it in the downstream and then cherrypick back just that one rev.
<fullermd> (and then immediately re-merge it, to dispose of the potential conflict if necessary right away when it's simple)
<Phoenixz> fullermd: eh, sorry, lots you.. downstream is... where? and cherrypick, how would I interpret that ?
<fullermd> Downstream would be your app using the framework.
<Phoenixz> fullermd: okay, but so.. how would I cherrypick back then?
<fullermd> Cherrypicking is [in this case] the act of [pseudo-]merging back just a single rev.
<fullermd> e.g., `bzr merge -c345 ../downstream`
<fullermd> (where -c does NOT mean cherrypick)
<Phoenixz> -c would be revision?
<fullermd> -c means "change".  It's basically a shortcut: "-cX" is shorthand for "-rbefore:X..X"
<fullermd> What actually makes it a cherrypick is that the ancestries you're merging aren't fully connected.  So bzr doesn't (can't) record an actual merge.
<Phoenixz> could I do bzr merge -c345 346 348 for example?
<fullermd> The 'merge' degenerates to being just a smart form of "diff | patch"
<Phoenixz> fullermd: mmmmm, so basically, bzr branch on the framework side would not know that the changes came from, say, multiple changes on the project brnach?
<fullermd> No.  You could do a series of merges (using --force to convince it to let you merge into an unclean WT), which may or may not work out well.
<fullermd> Right.  It can't, unless you share all the history.  And you don't want that.
<Phoenixz> fullermd: BZR is my "its complicated" on facebook at the moment.. :)
<Phoenixz> So I guess I'll have to be cherrypicking then..
<fullermd> Yeah.  "Real" cherrypicking is what you'd want in the ideal case anyway, so an approximation of it is the heir apparent.
<Phoenixz> fullermd: okay, I'll start experimenting a bit to get the hang of it.. meanwhile, if I've been doing the whole merging back thing before, that wouldnt be a problem, right?
<fullermd> Well, it means the whole history (up to the "latest" point anyway) of all your downstream projects is sitting around in the history of your framework.
<Phoenixz> fullermd: so best would be to just start with a clean import again? to make sure that all history is gone?
<fullermd> With all the history-size and sensitive-info complications that brings.
<fullermd> Well, or just back up to before you started merging downstreams in.
<fullermd> Depending on how much comes after that, either redoing them piecemeal or just splatting the current state over.
<fullermd> Some care would need to be taken with any new files etc. to be sure they have appropriate identities, otherwise you set yourself up for more ugliness in the future.
<Phoenixz> fullermd: By the way, upgraded to bzr 2.2 nightly build, same error...
<Phoenixz> fullermd:
<Phoenixz> bzr: ERROR: branch has no revision sven@fs-ex-20100714193341-nxxm4776w97sbaip
<Phoenixz> bzr update --revision only works for a revision in the branch history
<fullermd> What's the version/date of the build?
<fullermd> Hm.  I think NEWS is cracked on exactly when the bugfix came in, but it was in April anyway.
<spiv> We need to fix bzr to fetch the revisions of tags as well as the tip when you fetch a branch.
<spiv> There's a bug about that.
<fullermd> spiv: No, I'm pretty sure this is the "update -r blows chunks when given non-mainline rev"
<spiv> Oh, ok.
<fullermd> Which is mis-attributed in NEWS.
<fullermd> Maybe.  It's hard to tell...
<fullermd> The 2.2b1 tag doesn't seem to be in bzr.dev or bzr-2.2's ancestry.
<Phoenixz> fullermd: one sec, running the export and frankly, my laptop is dying with workload, one sec.
<Phoenixz> fullermd: Bazaar (bzr) 2.2.0dev1
<Phoenixz> fullermd:  thats the bzr I found in ubuntu repos.. Im gussing I'll have to build this one for being way to new..
<fullermd> That sounds oldish...   more recent would be 2.2b<something> or at least a higher dev#.
<Phoenixz> fullermd: yeah, my guess too.. but that means building from source
<fullermd> If you have the appropriate stuff (like pyrex) installed, that's pretty easy.
<fullermd> You don't have to _install_ the bzr; you can just run it out of the source tree.
<fullermd> (and actually, you don't strictly _need_ the pyrex or other build stuff even)
<Phoenixz> fullermd: well, I'll think about it.. for now, I have a project to deliver first :)
<fullermd> Oh, how dearly I'd love to not understand what you mean...
<rom1> salut
 * spiv does the install-ubuntu-on-new-laptop dance
<lifeless> \o/
<vila> spiv: woohoo ! specs ?
<spiv> vila: "not 3.5 years old" is the important one ;)
<spiv> Thinkpad T410 with a random selection of options ;)
<vila> CPU, memory size, SSD/HD size ?
<vila> screen size, weight
<spiv> Yep, it has a CPU.
<spiv> ;)
<vila> jam is disgusted :)
<spiv> i7-620M, 4GB RAM, 320GB HDD, 14", not as heavy as my previous.
<spiv> To a large extent I really don't care about any of that.
<vila> ha ha, no SSD then...
<spiv> The main things I cared about were the VT extensions for happy kvm and, well, that's about it ;)
<vila> but 4 threads... welcome to --parallel=fork heaven :)
<spiv> I'm essentially satisfied with the computing power of my old laptop, it's just the lack of battery life and functioning keyboard that's the problem :)
<vila> yeah, keyboard helps
<spiv> I suspect it's nearly impossible to buy a laptop that's crummier than something 3.5 years old except perhaps by getting a netbook... and even then it's probably a near thing.
<spiv> (A relatively cheap laptop from 3.5 years ago, too)
<vila> spiv: don't forget to use tmpfs for /tmp and /var/tmp, AFAICS that's still not the default for maverick
<spm> spiv: have you looked towards 2nd hand? the laptop I use for taking away is such; light, not too powerful; but good enough.
<spiv> spm: not really, I'm trying to own less electronic crap rather than more ;)
<spm> heh
<spiv> spm: it's not a bad idea, but really after my previous laptop with 9-cell battery + separate keyboard this one will seem pretty light :)
<spiv> No need to get myself used to unreasonable luxury...
<spm> ha!
<spm> fwiw, I got mine via recompute.com.au. I wouldn't say I'm entirely *thrilled* with their service (they delivered without the promised internal wireless, and convincing them of same was a pita), but not too shabby. dealt with worse.
<spiv> ta!
<spm> damn!  	IBM ThinkPad T43 Laptop $329!
<spiv> Hee :)
<jam> spiv: have a good night
<spiv> jam: thanks :)
<james_w> jam: https://code.launchpad.net/~ubuntu-branches/ubuntu/maverick/cuyo/maverick-201007212128/+merge/30582 https://code.launchpad.net/~ubuntu-branches/ubuntu/maverick/libsmbios/maverick-201007211814/+merge/30567 https://code.launchpad.net/~ubuntu-branches/ubuntu/maverick/cloud-init/maverick-201007211812/+merge/30566
<james_w> jam: collisions detected overnight, possibly due to the change to diff
<aj-dneg> hellos! i am using bzr-svn to push commits onto my company's giant svn repo, but i am getting an error when i try to push my changes now "ERROR: These branches have diverged."
<aj-dneg> i suspect it's because there have been commits to the repo elsewhere that have bumped the revno or something?
<jelmer> aj-dneg: there are changes on the same branch that you're pushing to
<jelmer> aj-dneg: changes that are not present in the local tree that you're trying to push
<aj-dneg> i'm the only one pushing to it though!
<jelmer> aj-dneg: try running "bzr missing <url>"
<aj-dneg> bzr missing svn://blablabla?
<jelmer> yep
<aj-dneg> oh f&Â£#, my bad
<aj-dneg> i pushed it somewhere else and then did an svn mv from one location to another
<aj-dneg> the revision i'm missing is "moved the code"
<aj-dneg> however shall i fix this?
<aj-dneg> i tried doing bzr merge but it just whinged about something...:
<jelmer> you can either rebase your local tree onto the remote one ("bzr rebase <url>") or simply ignore the fact that extra revision is present remotely ("bzr push --overwrite <url>")
<aj-dneg> hm, might try rebase
<aj-dneg> what would you do? :)
<aj-dneg> aw i couldn't rebase: different rich-root support
<aj-dneg> same as if i try to merge
<aj-dneg> ok --overwrite worked a treat, thanks
<aj-dneg> anyone know how to save username/password for bzr svn?
<dash> does the bzr-eclipse guy hang out here? :)
<jelmer> dash: He is verterok
<verterok> jelmer: hi :)
<verterok> dash: hi
<dash> verterok: first, thank you for making life with eclipse easier ;)
<dash> verterok: any thoughts on what it'd take to make bzr work with the 'team synchronizing' feature?
<verterok> dash: thanks :), sadly it's been a while since I got enough time to work on bzr-eclipse :(
<verterok> dash: not offhand
<verterok> dash: but I would take a look to the egit implementation (I read somewhere they just added support for it)
<dash> sounds good
<dash> thanks. :)
<verterok> dash: or the mercurial plugin, don't know if the support 'team synchronizing'
#bzr 2010-07-23
<jelmer> spiv: around?
<spiv> jelmer: starting to be :)
<jelmer> spiv: Have you ever seen anything like this: http://pastebin.com/t0te7wCQ ?
<spiv> jelmer: yes, I think it's due to something (e.g. a thread) trying to mutter after the TestCase has torn down the logging/trace setup.
<jelmer> spiv: ahh!
<jelmer> spiv: Thanks, that also explains why the number of tests that failed in this way varied
<spiv> You're welcome :)
<Chaorain> I recently heard about Bazaar and have a question. I heard that it will allow me to make a personal branch of a project. For example, I want to start writing a major update for Blender but I don't have write access to the svn server, can I make a branch that only I can write to? I currently have a local linux server that manages a private svn server for me.
<jelmer> Chaorain, yes
<Chaorain> ok cool. I saw how to install it but how would I go about doing what I want?
<Chaorain> here is what I found, http://ubuntuforums.org/showthread.php?t=916132
<Chaorain> oh nvm just saw "bzr init
<Chaorain> thanks for your help
<jelmer> spiv: Any idea how to figure out what code is doing that muttering?
<spiv> jelmer: hmm, not off the top of my head :/
<spiv> jelmer: instrument mutter to emit a traceback to stderr on ValueError, perhaps?
<Stavros> hello
<Stavros> can anyone tell me why bzr does a light checkout when i cp -R my repo?
<spiv> Stavros: I think I'm missing some context.  You mean you run a bzr command after cp -R'ing your repo, and you get a lightweight checkout when you don't expect one?
<Stavros> i'm doing cp -R repo/ repo2/; bzr info; and i see "lightweight checkout"
<Stavros> shouldn't that be a full branch?
<Stavros> i mean, how much fuller can it get?
<spiv> Well, what does 'bzr info' in the original repo/ report?
<Stavros> also lightweight checkout
<Stavros> what the hell?
<Stavros> how can that be lightweight? i can commit fine locally
<Stavros> checkout of branch: .bzr/branches/trunk
<Stavros> i have no idea what's going on :/
<spiv> Are you using the bzr-colo plugin, perhaps?
<Stavros> ah, i am
<Stavros> is there some way i can remove it?
<spiv> This would just be an artefact of how it works, I think.
<Stavros> and convert to a full checkout?
<spiv> You can probably use 'bzr reconfigure --tree'.  You might need to remove/disable bzr-colo first, I'm not sure.  Ideally bzr-colo's docs would cover this.
<spiv> Although, if it's not causing you any problems, why change?
<Stavros> because i can't commit to my other branch without this branch refusing to do anything unless i update :/
<spiv> Ah ok.
<Stavros> the command you gave me seems to have worked, let me check
<Stavros> yep, that works, thanks!
<spiv> Hooray, my new laptop can run the bzr test suite in under 10 minutes, and I haven't even tried running it in a tmpfs yet.
<mlh> spiv: what's your new lappy? (am looking at  buying one too)
<mlh> pm if you like
<spiv> mlh: Thinkpad T410, so far so good.
<spiv> Of course, I'm running maverick on it, so any issues could be blamed on that anyway ;)
 * spiv -> food
<mlh> ta
 * spiv finishes up for the evening.  It's EOD time plus a headache seems to be coming on :(
<spiv> On the plus side the new laptop is running smoothly and has all my old crap configured.
<spiv> See you all on Monday!
<rjek> Afternoon.  Is there any support for keyword-like expansion in bzr?  (ie, I want to include revision information in a file.)  While I could just have my build system query bzr, that doesn't work so well with tarballs produced with bzr export.
<jelmer_> rjek, see the keywords plugin
 * rjek was kinda hoping to avoid plugins.
<rjek> And I can't find it on http://wiki.bazaar.canonical.com/BzrPlugins :)
<Kinnison> jelmer_: Do you mean http://doc.bazaar.canonical.com/plugins/en/keywords-plugin.html ?
<rjek> My only concern with using plugin to do it is that my experience is that if I then try to build somewhere without that plugin, it'll either silently fail and I'll get strange builds, or I'll get an explosion with a python backtrace I don't understand.
<jelmer_> Kinnison: yep
<jelmer_> rjek: alternatively you can use "bzr version-info" to generate output, it's not really the same thing though
<jelmer_> Kinnison: Yep
<rjek> jelmer_: yeah, but as I said, that doesn't work for people building from a tarball created with bzr export.
<rjek> (In that I'm assuming they don't have bzr if they want to use the tarball.)
<rjek> Also, it looks like that plugin can only have the rules that describe what files to process globally, not in a checkout, which is a bit nasty.
<jelmer_> right
<jelmer_> It'll work as long as whoever runs 'bzr export' has the plugin installed though
<jelmer_> I'm not aware of any alternatives unfortunately
<Kinnison> Could a branch can't define a hook to run on export which could be used to update the file?
<Kinnison> s/can't//
<rjek> Can the rule files described by "bzr help rules" be placed in a branch, rather than global?
<Kinnison> Unfortunately it looks like whoever wrote bzrlib/rules.py never finished it properly
<Kinnison> :-(
<poolie> it was ian
<poolie> probably
<Kinnison> I wonder who reviewed it and didn't spot that RULES_TREE_FILENAME is defined as ".bzrrules" but then never used anywhere :-(
<rjek> Can I have that feature, please? :)
<rjek> Only having rules globally and not version controlled is... nasty :)
<Kinnison> Aye, it has rules stacking in it already, but no way to activate them
<Kinnison> boggle
<Kinnison> Also with all of rules.py's external interfaces starting with an underscore, I'm not impressed
 * Kinnison doesn't have the time to make a patch right now though :-(
<jenkins> hi, I am getting this error when doing bzr pull or commit bzr: ERROR: Could not acquire lock "/home/luke-jennings/Projects/lucid-e2/.bzr/checkout/dirstate": [Errno 11] Resource temporarily unavailable. does that mean there is a problem with launchpad or my computer?
<jenkins> I fixed it by getting a new branch
<aj-dneg> quick q, how do i check out the previous revision?
<aj-dneg> in-place of my workign copy
<GaryvdM> aj-dneg: bzr update -r -2
<aj-dneg> ah of course. i knew that. thanks :)
<aj-dneg> is there any way to save bzr svn username and passwords other than in the URI for it svn://uname:pass@server/branch
<aj-dneg> i know it's plain text in my branch config in any case, but it sucks that it shows it to the console!
<mgz> does bzr-svn work with authentication.conf?
<mgz> see no reason it shouldn't.
<jelmer> it should
<mgz> aj-dneg: in your bazaar configuration directory, open authentication.conf and add your details there
<mgz> run `bzr version` if you're not sure where the dir is.
<aj-dneg> mgz: i don't already have one of those files
<aj-dneg> what format?
<mgz> really? I thought it got created automatically.
<mgz> run `bzr help authentication` for the full run down.
<aj-dneg> i found this http://doc.bazaar.canonical.com/latest/developers/authentication-ring.html
<aj-dneg> thanks
<aj-dneg> mgz: perhaps bzr svn doesn't create it...
<schlangen_> hi, I want to checkout a repo and have to use win vista. It fails cause win does not support symlinks. Is there any flag or workaround or so to get the checkout done?
<mgz> use cygwin, or branch on nix, delete the symlinks, commit, and branch that on win.
<mgz> also, bug the project to not version symlinks it's nearly always a bad idea anyway.
<schlangen_> normally I use ubuntu but currently I've only internet with win
<schlangen_> I just want to check out a project and get the code
<mgz> yeah, I have often had a similar problem.
<mgz> there have been a few discussions about a better solution, but there's no easy fix.
<schlangen_> so there is no flag to replace symlinks on win with normal copies or so?
<mgz> no. file a bug with the project, they're probably only using them for someting stupid anyway.
<schlangen_> hm, ok
<jelmer> aj-dneg: bzr itself doesn't create it either
<mgz> which reminds me, I should have bugged someone here about lazr while the launchpad event was on.
<aj-dneg> i just get a crash when i have svn defined in authentication.conf :(
<mgz> they've got an unbranchable project due to symlinks, and another bug I filed a merge proposal to fix that's been ignored for months
<mgz> might have been someone at the event they could have kicked in person.
<mgz> aj-dneg: pastebin the traceback (I presume you mean python threw and exception rather than 'crash')
<mgz> -d
<aj-dneg> mgz: it created a crash dump for me
<aj-dneg> mgz: i will deal with this later, supposed to be working :)
<aj-dneg> thanks
<mgz> apport thingy?
<mgz> pastebin that if it's plaintext.
<GaryvdM> Hi mgz
<mgz> hey gary
<GaryvdM> mgz: I can't find your pastebined patch for the py2exe optimize improvement
<mgz> http://paste.ubuntu.com/460272/
<mgz> third in my browser's history :)
<mgz> it's only a guess, haven't tested.
<GaryvdM> mgz: Ok - let me spin a build of that...
<mgz> your 2.2b4 looks good, fixed all the stuff we worked on, though found some new issues that need handling before release
<GaryvdM> http://lkml.indiana.edu/hypermail/linux/kernel/9809.3/0957.html
<GaryvdM> A description of bitkeeper from 1998 - I did not realise that it was so old...
<mgz> we're all getting old gary ;_;
<jaxdroid> hi anyone here have experience in using the bzr plugin for eclipse?
<maxb> Some. Which plugin, though? There are two.
<jaxdroid> http://verterok.com.ar/bzr-eclipse/update-site/
<maxb> I tried that for a bit, but decided that it was sadly too immature and buggy to be of practical use
<jaxdroid> bizzare
<dash> jaxdroid: i use it
<jaxdroid> happen to have name to other plugin
<dash> maxb: which is the other one?
<maxb> qbzr-eclipse - which is a bit of an odd one, because it's not an Eclipse team provider
<dash> aaah.
<dash> not a team player
<jaxdroid> thx
<maxb> It's a rather different way of working - but it seems overall to have fewer rough edges than bzr-eclipse
<maxb> Unfortunately the sad truth is that bzr doesn't have anywhere near as good eclipse support as mercurial
<rioch> when I do bzr status, one of the items has a * by it. what does that mean?
<rjek> "bzr help status" suggests the file has the executable bit set.
<rioch> ahhh thanks
<GaryvdM> mgz: https://dl.dropbox.com/u/4494367/bzr-2.2b4-optimize-setup.exe
<GaryvdM> mgz: 6 kb smaller :-)
<mgz> compressed?
<GaryvdM> mgz: yes
<GaryvdM> busy testing if it works with plugins installed from source with old style help strings.
<mgz> appears to have worked
<GaryvdM> mgz: Do you how can you get a cold cache on windows with out restarting?
<mgz> can't unfortunately, and with new version of windows can't even always get it *with* restarting :)
<mgz> library.zip is ~2.5MB smaller as planned, and the exe is creating non-docstring-stripped files
<mgz> ^if you have a externally connected spinning rust hdd you could try that for a coolish start
<GaryvdM> mgz: Maybe using cacheset, reduce the max cache size, and then put it back...
<GaryvdM> http://technet.microsoft.com/en-us/sysinternals/bb897561.aspx
<mgz> just murdering your memory does sort of work, but takes longer than simply restarting
<mgz> get deep into paging death and takes ages to recover from
<mgz> ah, that's not the util I thought it was going to be, but might suffer from similar issues
<GaryvdM> mgz can see if you run an qbzr command from that install. I'm getting an error.
<mgz> wfm.
<GaryvdM> http://pastebin.org/413603
<GaryvdM> mgz: qlog?
<mgz> yup.
<GaryvdM> Works?
<mgz> yup.
<mgz> can you do qversion? not being able to import Qt probably means you're totally hosed.
<GaryvdM> mgz: I can do qversion
<GaryvdM> can't do qlog, qbrowse, and explorer.
<mgz> you should get qversion to print where it's getting Qt from/
<GaryvdM> Yes
<GaryvdM> Ah - I happens with a old version of qbzr (0.18dev) and a new installer with less qt dll's.
<GaryvdM> * It
<mars> Hi everyone, I have a testing question for the room
<GaryvdM> Hi mars
<mars> Hi GaryvdM
<mars> so, the question: I presume that bzr tests command-line script output, which means the suite has to work with STDOUT somehow
<mars> If so, how do you do it?
<GaryvdM> mars: Most of the tests test the api. But there are some blackbox test.
<mgz> assigning to sys.stdout
<mgz> or using a subprocess.
<lifeless> mars: self.run_bzr and self.run_bzr_subprocess
<mars> interesting
<lifeless> mars: the former uses apply_redirected to run the CLI layer with string io objects
<lifeless> the latter reinvokes bzr to actually do an end to end test, which is only rarely (like, 3-4 times) needed in a full test run.
<lifeless> mars: if you're writing a CLI layer, I'd suggest looking at the testrepository code, its a reimplementation of what bzr has, with the lessons learnt applied and some new ideas thrown in.
<lifeless> mars: better yet, don't write a CLI layer, use bzr's.
<lifeless> mars: lp-tools and commandant both have examples of reusing bzr's core handling to do stuff, and then you can use bzr's test cases to do self.run_... :)
<mars> lifeless, interesting idea.  I'll look into it.  It would be nice to find a common ground between the bzr "command language" way and the *nix "small sharp tools" way.  I'm sure there is something.
<mars> thanks everyone
<GaryvdM> mars:
 * mars pauses
<GaryvdM> mars; for cli opts and args parseing, there is a python libaray
<GaryvdM> looking for it...
<mars> GaryvdM, yep, I am familiar with it
<mgz> there are issues with both those methods in the bzr suite, but they're pretty esoteric
<mgz> run_bzr screws up debugging tests with pdb
<GaryvdM> mars: oh ok.
<mars> mgz, heh, that's good to know.  I rely heavily on the 'drop to PDB' features of various testrunners
<mgz> and run_bzr_subprocess doesn't handle being invoked from non-standard scripts
<mars> mgz, non-standard?
<lifeless> mars: bzr is small sharp tools :)
<lifeless> mars: testrepository has more of a flavour of that though, if you want that.
<mgz> as in, it's got special casing for a py2exe'd bzr.exe but anything else would break
<lifeless> mars: dropping to pdb is great, but you never need to do that in a blackbox test - if you do you're not isolating your tests anywhere near enough.
<lifeless> mars: layers man, layers.
<lifeless> mars: it annoyed me in bzr about 2 times a year; I know how to fix it, just 'meh, when it annoys me twice in a row'
<mars> lifeless, yes, but learning where the layers are best drawn is the challenge for me - "when do I test the boundaries?  How?  How much?"
<mars> heh
<lifeless> mars: if you're testing CLI *rendering* or *arg marshalling*, blackbox is the way.
<lifeless> anything else, should be domain objects and narrower non-CLI-blackbox tests.
<lifeless> IME, etc etc
<mars> lifeless, makes sense - "test double MockFormatStdOutput.printBranch() should be called X times"
<mars> and then black-box test printBranch() or something-or-other
<lifeless> by blackbox I mean bzr's apply_redirected/run_bzr test methods, which actually exercise the full stack
<mars> right
<lifeless> but its quick, so we're not too worried about it - and we only have a few such tests (under 1K I think)
<GaryvdM> mgz: I'm going to submit that patch as a mp. I think we need to make moving the py2exe stuff out of setup.py a priority.
<mgz> a mp to bzr?
<mgz> rather than bzr-windows-installers?
<GaryvdM> mgz: right now to bzr
<mars> lifeless, I guess I'll start looking at testrepository.  It has the infrastructure, but not so much code that it is difficult to find a starting point
<GaryvdM> thats why moving the py2exe is important.
<lifeless> mars: commandant might be better as its designed to be a intermediate library
<mgz> okay, this is officially driving me nuts
<mgz> in what circumstances is inserting the right dir as the first entry on sys.path not sufficient to get a module imported from there rather than elsewhere on the path on nix...
<mgz> ...when the module is already somehow imported... but... how ;_;
<mgz> modules shouldn't survive fork+exec right?
<mgz> okay, I'm officially just an idiot.
<lifeless> sure
<lifeless> :P
<lifeless> (why?)
<mgz> debugging code I'd added earlier was importing the module
<mgz> the code's still borked, but not for the reason I just spent all that time chasing
<mgz> oh man, and that's the real killer. the fix I already put up a merge proposal *was* correct, I just tyoped it when putting it on the other machine...
<mgz> if it didn't take so long to branch from here to there I'd have not spent the last hour trying to discover out why it didn't work...
<lifeless> and ciao
<micahg> can we have per branch whoami's?
<jelmer> micahg, yes
<jelmer> set email in .bzr/branch/branch.conf
<jelmer> or in the relevant section in ~/.bazaar/locations.conf
<Ken69267> is there a way to specify what ssh key bzr uses for launchpad? I do not use the default named key
<micahg> jelmer: thanks
<Ken69267> or if I must map it with .ssh/config what is the true url to launchpad that lp: hides
#bzr 2010-07-24
<maco> is bzr case insensitive?
<maco> like, i cant have a directory and a file with the same name where one is capitalised and the other isnt?
<maco> cuz it's getting unhappy at me when i try, and this is annoying
<dash> on what OS?
<maco> ubuntu
<maco> i had a dir named gally and did  "bzr mv gally Gally" then wanted to rename Gally.py to gally so tried "bzr mv Gally.py gally" (so my executable has a nice lowercase name with no extension) and bzr is angry
<maco> $ bzr mv Gally.py gally
<maco> bzr: ERROR: Could not move Gally.py => Gally: Gally is already versioned.
<maco> i thought maybe i needed to commit the first mv before i could do it, but i did that and it still gives this error
<spiv> maco: bzr should work just fine with files that differ only by case, if the filesystem allows it.
<spiv> maco: e.g. I just tested 'bzr mv Foo.txt foo.txt' in a fresh branch locally and it DTRT.
<poolie> hi spiv
<spiv> Good evening poolie
<lvh> hello
<lvh> is this the right place to ask for stuff about bzr-eclipse?
<lvh> I'm trying to move to eclipse from emacs but so far the bzr support is really confusing me
<lvh> I can get it to work when everything behaves like a single branch, but I'm used to (and I suspect most people are) single repo + many branches
<lvh> I don't understand how to import such a layout (eg; Twisted/ (this is the repo) with Twisted/twisted (trunk), Twisted/mypatch-whatever, ...)
<spiv> lvh: this is a good place to ask (but unfortunately I personally don't have any experience with bzr-eclipse)
<spiv> I suppose if there's a #eclipse they might know something too.
<lvh> spiv: from what I heard the person convincing me to try eclipse copped out and moved back to svn
<lvh> spiv: I'll try #eclipse, thanks :)
<lvh> (in his defense, svn support in eclipse is probably about the best in the world)
<lvh> apparently the trick is to not use bzr integration in eclipse
<lvh> (keep a terminal open instead)
<lvh> http://laurensvh.be/dump/bzr/Screenshot-Event%20Details%20.png
<lifeless> poolie: I'm going to head off, I'm a bit over enclosed rooms and its all gnunet for the rest of the afternoon
<poolie> heh
<poolie> where are you now?
<lifeless> ro your right
<lifeless> near the door
<poolie> for a clean getaway
<lifeless> duh duh duh daaaaaaaa
<poolie> hm
<poolie> block diagrams
<poolie> nice people though
<lifeless> \o/
<lifeless> yes
<lifeless> you'll be ok ? :)
<poolie> want to see stevea tomorrow?
<poolie> i'll cope
<lifeless> would love to
<poolie> i think in retrospect i would have made more talk more concrete
<lifeless> 20/20
<mgz> heh, communicating where you are in the same room over irc?
<mgz> lifeless: just to double check something I vaugely remember you telling me, is it your intention that TestCase instances should be gc-ed after being run now?
<maco> spiv: right i managed doing one step of that. now try "bzr mv blah Foo.txt" so you're moving something into where the old name was... it doesnt like htat
<rockstar> spiv, I've reproduced her bug.  It does look like some sort of case-insensitivity issue.
#bzr 2010-07-25
<lifeless> moin
<lifeless> poolie: so stevea details organised ?
<poolie> lifeless, no ack from him yet, i'll send an sms
<michealh> Hey Silasle
<michealh> Ask away!
<Silasle> Ok, tried to push my source to an branch whit these commands: http://paste.ubuntu.com/468850/ and got the message "bzr: ERROR: Transport operation not possible: readonly transport ", whats the problem?
<fullermd> Sounds like you're trying to push over http.
<michealh> Ahhh Silasle Goto out Team bzr and copy what the command says about pushng
<Silasle> michealh: There it is written "You cannot upload to this branch. Members of Cinematic Maintainers can upload to this branch."
<Silasle> fullermd: And that means?
<poolie> Silasle, are you meant to be a member of this team?
<michealh> Silasle: You ARE a member ;/
<poolie> Silasle, please pastebin the traceback from ~/.bzr.log
<michealh> Silasle: Your launchpad is silas isnt it?
<Silasle> poolie: I am in the member list but i still get an message whit "You are not a member of this team."
<fullermd> Wouldn't a bad team membership or the like give a "can't write this file" sorta error, not a "readonly transport" one?
<poolie> you'd think o
<poolie> *so
 * fullermd will stick with his 'http' answer, 'cuz it'll make him look real smart if it proves out correct.
<Silasle> michealh: No i am not, i'm silas-lenz
<michealh> Man
<michealh> Silasle: You are a member
<poolie> you just added him? or he just joined?
<poolie> try again?
<michealh> poolie: I added him... It is a restricted team
<Silasle> And it works (Created new branch. )
<fullermd> Ah well, I do seemingly get that error in such cases.  Random Launchpad Black Magic(tm).
 * fullermd wishes there were a freakin' 'lp-resolve' command.
<michealh> #
 * michealh goes away and leaves Silasle to it.
<Silasle> But the branch seems to be empty
<poolie> Silasle, looking at it how?
<Silasle> poolie: I think i got it to work now
<cjao> is there a way for me to put the .bzr directory elsewhere (such as ~/bzr/project1.bzr)?
<luks> if you mean the whole .bzr directory, then no
<luks> but you can move the repository/branch and have only a lightweight checout
<cjao> my problem is that i don't have write access to the directory with source files, but i still want to check in those files to a bzr repository (kind of a convoluted situation, i know)
<luks> you can create a separate checkout of the repository
<luks> hm, actually, if you don't have access to the dir at all it won't work
<luks> still, you can move the branch/repository elsewhere
<luks> and let the person who has write access to create a lightweight checkout there
<luks> that way you can write to the repository from a different location
<luks> and the person can update the source files in the working tree from the repository when they want to
<luks> http://doc.bazaar.canonical.com/latest/en/user-guide/using_checkouts.html#getting-a-lightweight-checkout
<cjao> what if the dir doesn't contain a branch / repository? there's nothing to check out from...
<GaryvdM> cjao: I don't think there is a way to do this. :-( . Might it be possible for someone who has write permission to create a .bzr that you have write permissions to?
<GaryvdM> Or a symlink to somewhere where you have write permissions?
#bzr 2011-07-18
<spiv> Good morning
<poolie> hi spiv, all
<RenatoSilva> what's the purpose of bzr PPA if there's bzr available in ubuntu already?
<poolie> RenatoSilva: a few things
<poolie> basically they have later bzr releases than you would get from ubuntu
<poolie> eg there's a nightly ppa
<poolie> also there are ppas with updated bzrs for historic ubuntu releases
<RenatoSilva> so just a matter of most updated versions?
<poolie> pretty much
<poolie> you can get the current stable release, the current beta, or a nightly
<poolie> also the corresponding plugins
<poolie> whereas historic ubuntu releases will only get bugfix updates
<poolie> (and even there there is some lag as they're qa'd before getting into -updates)
<RenatoSilva> ok thanks, will deactivate the PPA for now
* vila changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila
<vila> hi all !
<spiv> Hey vila
<vila> _o/
<poolie> hi vila, spiv
<maxb> Morning all :-)
<maxb> spiv: As you may have seen from u-d-d@, when I went to revert append-revisions-only I discovered it was trapping a genuine case of concern :-/
<poolie> hullo maxb
<maxb> Hi poolie
<poolie> did i understand your point?
<spiv> maxb: yeah, I saw
<poolie> i didn't get around yet to looking at the specific failures to see how they line up
<spiv> maxb: makes me a little happier that I did it ;)
<maxb> On a different matter, I reopened bug 524173
<ubot5> Launchpad bug 524173 in Ubuntu Distributed Development "package-import uses james_w credentials" [High,Confirmed] https://launchpad.net/bugs/524173
<poolie> i saw
<poolie> i can't win :/
<poolie> i havent' gone back to it yet
<maxb> Third time's the charm? :-)
<maxb> I think it'll really be dead this time
<maxb> I think you did understand what I was saying about append-revisions-only - to paraphrase, it's not right that 0.1.2ubuntu1 revisions start showing up in Debian branches unless they're actually in the changelogs uploaded to Debian
<maxb> vila: I've now worked through my backlog of PPA uploads :-)
<vila> maxb: \o/
 * maxb ponders backporting natty's debhelper to maverick and lucid in the support of reduced deltas in the daily-ppa
<poolie> could be good
<poolie> it should perhaps go in a more general purpose ppa?
<poolie> i wonder if someone already did it actually
<jelmer> g'morning poolie
<poolie> hi there
<maxb> https://launchpad.net/ubuntu/+ppas?name_filter=debhelper  --> 221 results
<maxb> of which bzr-builddeps is the first :-)
<jam1> morning all
<jelmer> hey jam
<mrevell> ning
<vila> hey jam, don't forget to write a pp report email
<jam1> ugh, still called jam1
<jam> vila: can you try to ping again
<vila> hey jam, don't forget to write a pp report email
<jam> yay
<jam> vila: I'm spinning up ec2 now to build the 2.3.4 installers
<jam> vila: technically, I was only assisting Riddell for doing PP
<vila> jam: oh right, keep assisting him then :)
<vila> hey Riddell, don't forget to write a pp report email
<vila> :D
<jam> I don't think Riddell is online yet
<spiv> Hmm, my attempt at a concise description of the conditions for bug 806348 still ended up as a screenful of text :/
<ubot5> Launchpad 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] https://launchpad.net/bugs/806348
<spiv> jam: If you have the time, I'd love it if you can look at that bug and my comments and tell me if there's an obvious fix I'm failing to se
<spiv> *see
<jam> spiv: off-hand the big question I have is why can we fetch "[D, A]" rather than always having to do "[D, (A,C)]"
<spiv> What's the (A,C) notation mean there?
<jam> well, I assume [D, A] is fetch D excluding A
<spiv> Ah, no.
<jam> so it would be Fetch D excluding C and A
<spiv> It's a list of heads
<spiv> Ah, actually, it's a list of revs in this context :)
<maxb> Is it significant that various of the UDD BzrCheckErrors refer to different kinds of missing keys?
<jam> maxb: different kinds? probably. missing texts is a very different issue than missing chk pagse
<jam> at least, very different logic involved (usually)
<jam> Morning Riddell
<spiv> (In the case of the [D,A] example the initial set of heads to fetch is also the set of revisions fetched from the first stacked repo)
<jam> spiv: I'm not quite sure how you get a "fetch [D, A]" because of tags?
<spiv> jam: right
<Riddell> good morning jam
<jam> spiv: so does this not happen without your tags logic?
<jam> Riddell: vila would like to remind you to write a Patch-pilot summary email
<Riddell> actually I'm just starting my patch pilot week
<jam> Riddell: well, you and I worked on it a bit last week, and I went ahead and scheduled vila for this week, because he's gone again next week
<spiv> jam: I have a suspicion this can also happen without starting with multiple heads, not only out of general paranoia rather than evidence
<jam> but you can partner with him.
<jam> spiv: "but only" ?
<spiv> jam: yes, sorry :)
<jam> spiv: I'm just suspicious because we didn't really see this before your patch landed. We saw it for bzr-svn but because bzr-svn was rewriting inventories.
<spiv> Right.
<jam> and we saw it when chk pages collapsed, because one of our "optimizations" accidentally forgot to actually rewrite the tree
<spiv> Like I say, no evidence, so I'm happy to discount the possiblity for now: if it does happen, it's clearly not happening much.
<jam> spiv: so in reading your write-up, it isn't clear to me what the content is in various branches, where the stacking boundaries are, etc.
<spiv> (But at the same time, I feel like the theoretical foundations of the logic used here aren't as solid as they should be, hence my general suspicion.)
<jam> also, yeah, we could certainly have edge cases in the fetch code, that are just being provoked by new fetch requests.
<spiv> jam: ok, in that case perhaps skip the English and read the failing test in the branch :/
<spiv> It's bzrlib.tests.per_repository_reference.test_fetch.TestFetchFromRepoWithUnconfiguredFallbacks.test_parent_inventories_with_identical_contents(RemoteRepositoryFormat-default) that fails.
<spiv> maxb: FWIW, I think at least some of those bugs are the same, or at least closely related, possibly even including the missing texts
<spiv> maxb: the simplest way to find out is likely to be fix the test that's failing in lp:~spiv/bzr/stacked-fetch-same-chks and seeing how many failures that fixes :)
 * spiv -> EOD
<poolie> cheerio spiv
<jam> maxb: python-bzrlib.tests got installed, btw
<jam> have a good night spiv
<jam> poolie: I was bringing up desolation again, and I was thinking, how do we know how much data we're using in S3? It seems a bit confusing since everything gets stored as 100s of 10MB chunks.
<jam> so while I deregister old AMIs that we don't want to use anymore
<jam> I don't know if that actually frees the S3 space
<poolie> the short answer is that in the last few months the usage has cost so little i have not bothered claiming it
<poolie> something like $8/m
<poolie> including run itme
<poolie> *time
<jam> actually, looking at ec2.bazaar-vcs.org it looks like we have "desolation-2010-07-27" still on there.
<poolie> when it was running continuously it was more significant
<jam> poolie: yeah, I've been pretty good about not even letting it run overnight
<poolie> thanks for that
<jam> as I can bring it up, bootstrap it, build and shut it down
<poolie> jam, re "caught before production deployment" etc, see my later mail with the timeline from robert
<poolie> it was a bit confusing before
<jam> yeah
<jam> and as you say, it does, indeed, cost almost as much to break in QA as it does in prod
<jam> at least human-time wise
<jam> I guess, rolling back appservers takes more losa time
<jam> since they have to kick off a script to rollback each one
<jelmer> jam: evolution has recently started displaying your emails as only having a signature and an empty body. has something changed in your setup recently?
<jelmer> As in, the last couple of days.
<jelmer> If not, perhaps I've hit a bug in evolution in oneiric
<jam> jelmer: nothing changed on my Laptop, a couple times I respond via my phone, but that wouldn't have a signature
<jam> I think you have a bug in oneiric
<jelmer> I'll report it - thanks for confirming
 * jam => lunch, bbiab
<gour> morning...i plan to contribute to github project using bzr-git...i did a small test...forked repo, pulled from it with bzr branch, edit, commit, dpush back and it looks ok...is bzr-git adequate for such a work where i'd fork, make small change, dpush back and launched 'pull request' to upstream?
<jelmer> gour: yeah, I've been doing that with dulwich itself for a while
<gour> jelmer: cool...i'm really hesitant to use git (it's way too complex for my taste distracting from the main work)..btw, thanks a lot for bzr-git...what would be required for 'git push'? lot of work?
<jelmer> gour: you mean 'bzr push' to a git repo?
<gour> jelmer: yep
<jelmer> gour: we need to be able to represent all data that is present in the bzr branch in git
<jelmer> so file ids, revision properties, etc need to all be stowed in the git revisions somewhere
<gour> will 2.4 help in that regard?
<jelmer> gour: this wouldn't require any bzr changes, just bzr-git changes
<jelmer> there is some initial work done in bzr-git towards this, but it's unfinished
<gour> jelmer: ok...otoh, for the above scenario, bzr-git is great...much better than forcing oneself to git
<gour> bzr-hg is behind git plugin?
<jelmer> gour: behind in what sense?
<gour> jelmer: functionality...is it possible to use 'bzr dpush' ?
<jelmer> gour: ah
<jelmer> gour: it's possible, but more experimental in bzr-hg
<gour> ok
 * jam => back
<vila> Riddell: If you want to keep co-piloting this week, I'm happy to help
<Riddell> vila: maybe we could pair on it tomorrow?
<vila> Riddell: perfect
<jam> vila: poke with a blunt stick
<jam> question about: https://code.launchpad.net/~jameinel/bzr/2.4-no-open-master/+merge/67689
<jam> does it need a test before we can land it?
<jam> I'm not 100% sure how to write one easily
<odony> Hi everyone, I'm trying 2.4b5, and so far so good, except now I'm trying to push on an existing LP branch, and this single commit push is taking ages and uploading lots of stuff
<odony> it's saying "Fetching revisions:Inserting stream:Estimate 12467/12570" and the max numbers keeps increasing... any way to find out what's happening?
<odony> with 2.3 pushing to that branch was always very fast, the repo/branch format did not change AFAICS... bzr push -v does not give me any more info
<vila> jam: my concerns here are two-folds: 1) You get read of the remote access, a test should guard that we don't regress
<vila> 2) by not doing the access you open the url-slightly-broken cases we encounter in that other bug
<spiv> odony: 2.4 pushes revisions named by tags (if they aren't already present)
<spiv> odony: perhaps you have some strange tags?
<jam> odony: yeah, I'm guessing you have tags in the branch that are meant to be present in the development focus branch
<odony> hmm yes that might be the case
<odony> out CI system tags build failures, and this is the dev focus branch indeed
<spiv> jam: or potentially even irrelevant tags from a failed 'bzr merge' from an unrelated branch :/
<odony> is there a way to disable this? I'm concerned of locking our main dev branch for so long... been uploading for 30+ minutes uninterrupted
<jam> odony: this only happens once, but no, there isn't a specific way to disable it.
<odony> any idea how much overhead we are talking about here? this branch has a few thousands revisions, but probably only a few hundreds of them have tags
<jam> odony: the specific issue is that we fetch revisions which were tagged, that were not already present.
<jam> it sounds like you might have a tag that points at unrelated history.
<odony> last time I killed it upload had stalled after 50Mb+
<jam> eg, a bzr-svn branch that has a tag pointing at a bzr revision
<odony> jam: I think I see what you mean... is there an easy way to find out if that's the case? I don't think we have any imported revisions
<jelmer> odony: if "bzr tags" reports revisions with "?" as the revision
<spiv> It might be an interesting little project to write a plugin to identify which tags are least related to your current tip.
<jelmer> odony: any revisions with a revision number reported by "bzr tags" are part of the tips ancestry
<odony> jelmer: thanks, let's see...
<spiv> Legitimate tags can be like that, e.g. tags of releases.
<spiv> (When the release branch diverged at least a little from the trunk)
<jelmer> ah, sorry - yes
<spiv> But certainly any tag with a revno is definitely ok :)
<jelmer> odony: What I described will report any revisions that are now tagged that previously weren't, not necessarily only revisions that are unrelated to your current branch
<odony> "bzr tags|wc -l"  gives 1758 tags, and  "bzr tags|grep '?$' |wc -l" 146 tags
<odony> jelmer: I'm not sure I'm following, many of the ? tags are release tags coming from other branches, and some look like valid tags added by our QA system, but still they don't have a revision
<jelmer> odony: they will only have a revision if they are part of the history of your current branch
<jelmer> if they are related but not in the history they will still show "?" because you can't use a revision number to refer to them
<odony> jelmer: I see, but why would they be in the branch if they're not related to its history? Is that because it's the dev focus branch?
<jelmer> odony: the tags would be pulled in by e.g. a "bzr merge" which was reverted, or manual "bzr tag" commands for revisions that weren't in the history
<odony> jelmer: oh I see, merges that were reverted are probably common patterns here.. didn't know that would leave unused tags in your branch
<jelmer> odony: it's a bug in bzr that that happens, but it's pretty hard to fix with the current way tags work (since tags are unversioned)
<odony> jelmer: alright, makes sense now :-) so I guess removing all those tags with bzr tag --delete would be safe? (assuming they're not bound to any revision, they're mostly useless?)
<jelmer> odony: they're bound to a revision, but that revision can't be addressed using a short revno
<spiv> You can see the revision-id with 'bzr tags -v'
<jelmer> odony: you can indeed safely remove them, "bzr tag --delete" only deletes tags, never history
<spiv> er,
<spiv> bzr tags --show-ids, anyway :)
<odony> spiv: ah yes, --show-ids works, great
<spiv> But yes, if you don't think the tags should be on that branch, then removing those tags from that branch sounds like a good idea :)
<odony> spiv: well, they're not very important, but I'd rather keep them if it doesn't help speeding up the push ;-)
<odony> so jam was saying that these tags might further slow the push? that's because they need a long revision id to work, so possible require the upload of a side branch along with the main one?
<odony> s/possible/possibly
<jam> odony: the most likely issue is that these revisions are present on your local machine (for whatever reason)
<jam> but never got  pushed into the dev focus's repository
<jam> so *right now* you are pushing them there, correct?
<jam> at which point, all future branches based off of this dev focus
<jam> won't try to include them
<jam> (as they'll already be in the dev focus)
<odony> jam: I'm not supposed to have any of these tags only on my machine, because they're mostly added by our QA system externally
<odony> so if they're somewhere, it shouldn't be on my machine only... I almost never manually tag
<odony> does that make sense?
<odony> (btw, my current branch is part of a shared repo with other branches, don't know if they are shared between them)
<jam> vila: http://paste.ubuntu.com/646517/
<jam> we should have had effort tests long ago
<jam> that is "bzr switch --create-branch -d checkout new-feature"
<jam> which, in theory, should open checkout, and then create new-feature, and switch to it.
<jam> It calls "Branch.open()" for checkout 10 times
<jam> master 2 times
<jam> and feature 3 times
<jam> ugh
<jelmer> ouch
<vila> hehe, err :-/
<jam> my patch reduces that a bit
<jam> and, of course, you can't pdb in run_bzr... :(
<vila> yeah, painful
<vila> Last time I suffered from this I wondered if it may possible to patch pdb to use sys.stdin/sys.stdout (the original) to stay immune from redirections
<jam> vila: we explicitly patch sys.stdin/stdout. I think we could instead have a "run_bzr(no_redirect=True)" or something like that
<jam> to avoid the monkeypatching
<jam> hmm... it seems we do legitimately open the master branch, because we want to check if the local heavyweight branch has any commits that aren't in master, before we let you switch away (and lose them, in theory)
<jam> (i'm not 100% sure about the validity that we would lose them...)
<jam> I suppose the test is if this is heavyweight
<jam> and you are going to point it at another branch
<jam> you don't want to lose commits you had locally, that hadn't been pushed to master
<jam> since you can 'bzr switch' bound branches.
<jam> anyway
<jam> I'm guessing we're also running into caching issues. As in, master branch is supposed to be cached, but isn't because we don't lock things correctly.
<jam> anyway, I don't need to fix all of that right now
<vila> no, no, we don't want no_redirect, at least almost never, but python keep track of the originals somewhere and pdb should use them (unless we want to have pdb redirected for a given test)
<jam> I can still assert that my patch is better than it was
<jam> vila: I mean "no_redirect" as a way to debug manually
<jam> not something you leave in the test suite
<jam> but somethingthat "I just want to debug this"
<vila> jam: I've tried patching the redirection a few times to debug, never worked well :-/
<jam> well, that I don't doubt
<jam> you can't make assertions about the output if we don't collect it
<jam> etc
<vila> yup
<vila> jam: I'm happy for you to land with this test added
<vila> jam: as a rule, I'd prefer an ugly test revealing issues than no test at all, and here, the test doesn't look ugly (the result on the other hand... ;)
<vila> jam: I thought branch provides different transports including one with at the branch base which may avoid the double strip
<vila> user_transport as opposed to control_transport or something ?
<jam> vila: it is certainly possible to avoid creating a new SSH connection, etc. In fact, master_branch is cached as a Branch attribute
<jam> but caches only live as long as the branch is locked
<jam> and creating 10 Branch.open() of 'checkout' indicates we are probably not sharing branches where we think we are
<jam> jelmer: did you update the bzr-rewrite plugin to not use "bzrlib.trace.info" ?
<jam> I'm getting "ImportError: cannot import name info" on the latest bzr
<jam> of course, my plugin is called "rebase" so it is probably really old
<jam> (yeah, I think the latest version is fine)
<jam> jelmer: do you have time to chat about :https://code.launchpad.net/~jameinel/bzr/2.5-up-to-date-609187/+merge/67844
<jam> specifically the ~ubuntu-branches stuff
<jam> because if we use a short URL, we won't see "~ubuntu-branches",but also the package importer doesn't always use ~ubuntu-branches
<jam> (At least, there was a recent thread about people making their own branch the official package import, which the importer would then overwrite as needed.)
<jam> which may be a bit wonky
<jelmer> jam: one sec, let me check (wrt bzr-rewrite)
<jam> (bzr-rewrite seems to be correct now, I'm not getting the warning with trunk, i was just being lazy)
<jelmer> jam: are you pulling from lp:bzr-rewrite?
<jelmer> jam: Ah, cool
<jam> jelmer: yeah, just an old 'bzr-rebase' branch.
<jelmer> jam: also, I'm happy to chat about 2.5-up-to-date-609187 now or later, whatever works best for you
<jelmer> I think it would be really confusing to get warnings on branches that the importer doesn't take care of
<jelmer> jam: how/where would we setup things to allow pushing to a different branch?
<jelmer> I imagine we would still have to set up launchpad to know what the canonical branch is, if it's not the ~ubuntu-branches branch
<jam> jelmer: so I don't really know. I'm going off of what i've gleaned from conversations in the past
<jam> but AIUI, "lp:ubuntu/foo" may not be "lp:~ubuntu-branches/ubuntu/oneiric/foo/oneiric"
<jam> though in most cases it is.
<jam> anyway, I would be fine changing the regex to...
<jam> *if* there is a ~, then it must match ~ubuntu-branches
<jam> otherwise don't warn
<jelmer> jam: I guess it would be another roundtrip to check if the branch that was specified is the canonical packaging branch?
<jam> jelmer: is that good enough for your concern?
<jelmer> jam: that's fine with me
<jam> jelmer: something like that. I'm not really sure how to do the query.
<jelmer> jam: Anyway, nice work on that one. Sorry we didn't end up pairing on it.
<jam> yeah, you were out of town, and I made some headway, so  I figured I'd push it through
<odony> thanks jam, jelmer, spiv: I finally managed to finish pushing my branch, after deleting many ? tags and being more patient :-)
<jam> jelmer: you have: <<<<<<< TREE
<jam> * Fix i18n use when no environment variables are set. (Jelmer Vernooij, #810701)
<jam> in bzr.dev
<jam> but it shows up in bzr-2.4.txt
<jelmer> hhh/win 81
<jam> shouldn't it be in bzr-2.5.txt?
<jam> (It just conflicted trying to merge lp:bzr/2.4 into lp:bzr, and I wanted to understand why)
<jelmer> jam: ah, thanks
<jelmer> yep
<jam> jelmer: I'll clean it up and land it
<jam> I just wasn't sure whether you meant to land it on lp:bzr/2.4, etc.
<jam> Its easy to do
<jam> and certainly NEWS/release-notes is a pain point in genreal
<jam> general
<jelmer> 2.5 is fine I think - thanks for doing the cleanup
<jelmer> I wonder if we should file a bug about making fetching all revisions referred to by tags optional
<jelmer> for 2.4, that is
<odony> I have another interesting issue when pushing a (different) branch with 2.4: ErrorFromSmartServer: Error received from smart server: ('error', "Internal check failed: Cannot add revision(s) to repository: missing referenced chk root keys: [StaticTuple('sha1:32b5964d29924e611fc4b50e92ca0aeed58c2cea',)]")
<jelmer> odony: that's a known bug, let me find the bug
<jelmer> was this a branch imported with bzr-svn?
<odony> jelmer: I don't think so
<jelmer> it could be bug 718723 ?
<ubot5> Launchpad bug 718723 in Launchpad itself "fetch from merge directive to stacked branch unable to fill in chk pages" [Critical,Triaged] https://launchpad.net/bugs/718723
<odony> jelmer: I was reading it, but it's not clear... it happened during a regular push of a single commit, something that I used to do on that branch everyday with 2.3
<jelmer> odony: please file a bug, that sounds worrying
<odony> it somehow seems to be related with 2.4 (perhaps the uploading of tagged revisions, as that was another branch with hundreds of tags)
<odony> jelmer: I clicked on "report problem" when the crash report came, so I think apport may have created it on launchpad (but not sure where)
<odony> jelmer: hmm no of course "this is not a genuine Ubuntu package", so apport didn't report it, I will do it manually
<jelmer> odony: thanks!
<odony> jelmer: FYI, that's bug 812385 ;-)
<ubot5> Launchpad bug 812385 in Bazaar "[2.4b5] push sometimes fails with "missing referenced chk root keys"" [Undecided,New] https://launchpad.net/bugs/812385
<jelmer> odony: thanks again
<jezuz> how do i pull from a readonly source?
<jezuz> its telling me it cant lock it but it shouldnt be trying to
<jelmer> jezuz: hi
<jezuz> hello
<jezuz> im having trouble :(
<jelmer> jezuz: is the branch you are trying to pull into perhaps bound?
<jezuz> bound?
<jelmer> jezuz: ("bzr info" should tell you)
<jezuz> ok
<jelmer> if it was created with "bzr checkout", it will be bound
<jezuz> what am i looking for?
<jezuz> it says checkout
<jezuz> i did change the location in the config to bzr+ssh
<jezuz> i did this before, but i cant remember what i did
<jezuz> since it was an http transport before...
<jelmer> jezuz: if you're trying to update a bound branch (a checkout), use "bzr up" rather than "bzr pull"
<jezuz> is there a flag to overwrite local changes too? or is that default?
<jelmer> local changes in the working tree?
<jezuz> yeah
<jelmer> you can use "bzr revert" after the "bzr up" command
<jezuz> k
<jezuz> thanks
<quotemstr> Is there an equivalent to git commit --amend?
<luks> bzr uncommit
<luks> bzr commit
<poolie> hi all
<poolie> o/ maxb
<maxb> hello
<poolie> i think i'll file a bug for doing the package imports in topological order and then we can see if it's feasible to change
<quotemstr> Say I've made commits A, B, and C.  How can I go back, change A to A', then apply B and C again?
<quotemstr> bzr uncommit will destroy B and C, yes?
<maxb> More like "remove from this branch's history" than "destroy", but essentially yes
<quotemstr> Basically, something like quilt(1) would be nice.
<maxb> There's a couple of options, branch A, B, C to another temporary branch, uncommit, commit A', then merge B, commit, merge C, commit
<quotemstr> Won't those then show up as merge commits instead of real commits?
<maxb> Or, bzr-rewrite has a 'bzr replay' command for doing mostly that with less typing
<maxb> They wouldn't show as merge commits if you were effectively cherrypick merging them
<maxb> i.e. bzr merge -c-2 ../temp-branch
<quotemstr> Ah.
<quotemstr> That works.
<quotemstr> Hrm, loom looks interesting too.
#bzr 2011-07-19
<GungaDin> hi
<GungaDin> if a parent branch has been moved, does anything have to be configured or rebound in the child branch?
<jelmer> GungaDin: yes, you can use "bzr bind" to do so
<poolie> spiv, hi
<poolie> what's next with bmp expanders?
<poolie> i think the prerequisite has now merged
<quotemstr> Where can I find the "bzr branches" command? It's not present in my bzr 2.3.1
<quotemstr> Was it introduced in 2.4?
<bob2> bzrtools
<quotemstr> Thanks.
<spiv> poolie: the next step is me finishing it I think!
<spiv> poolie: danilo did a really good review
<poolie> great
<fullermd> Why does `bzr check --repo .` wander off down into branches in the dir instead of just checking the repo?
<poolie> i don't know fullermd, that sounds like a bug
<mwhudson> which reminds me, meld trunk no longer tries to run bzr check on your branch before opening it...
<fullermd> It's already kinda irritating how the obstinate the searching is on check anyway, when it finds the branch's repo, then walks all the branches inside it in what seems like the slowest possible fashion...
<fullermd> But it's double terrible this time, since there's an [unversioned and ignored] symlink in one of the branches, which leads to a dir, under which is a self-referential symlink...  which means the check blows up and never checks anything.
<poolie> :/
<poolie> so spiv, do you need a hand landing that branch?
<poolie> should i just send it or do you need any further tweaks?
<poolie> i refer to the bmp expander branch
<spiv> poolie: I'm working on the review points atm
<poolie> oh thanks
<poolie> i can feed it up when you're done
<vila> hi all !
<poolie> hi there vila
<vila> _o/
<jam> morning all
<vila> jam: \o_
<vila> jam: did it ring ? ;)
<jam> yep
<vila> \o/
<poolie> hi there jam
<poolie> so much semaphore today
<jam> -o \o  |o  \o  o/  o
<jam> /  /     \ /  /   / |
<jam> yeah, flag semaphore doesn't work very well on IRC
<jam> (that was hi vila, according to http://en.wikipedia.org/wiki/Flag_semaphore)
<jam> but you need a fixed-width font
<vila> lol
<jam> poolie: It turns out I can't be invited to google+ on my standard email, because it is a google-app-for-custom-domain, and it isn't supported. :(
<poolie> huh
<poolie> well, if you have an alternative address i could invite you there
 * fullermd . o O ( using semaphore in IRC is kinda a red flag... )
<maxb> OK, I'm confused..... why would a launchpadlib api call be happening during 'bzr ci' ?
<maxb> (I can see an HTTP error in my ~/.bzr.log)
<jam> morning Riddell, we're on mumble
<jelmer> maxb: maybe a hook?
<jam> maxb: do you happen to have bzr.dev 6033 ?
<jam> I just added a hook when looking at lp:ubuntu/* branches
<jam> to see if they are up to date
<jam> (bug #609187)
<ubot5> Launchpad bug 609187 in Ubuntu Distributed Development "users are not warned when branching ubuntu:foo (or lp:ubuntu/foo) and the package import of foo is out of date" [High,Triaged] https://launchpad.net/bugs/609187
<jam> but it shouldn't trigger for things that don't look like "ubuntu" or "debian" branches hosted on Launchpad.
<maxb> jam: hmmm...
<maxb> yes, I do
<jam> maxb: I'm working with the lp guys to figure out why the query dropped from 150ms last week to 900ms this week. Seems to be an SSL handshake issue.
<maxb> jam: I've just noticed you've got an assumption about the ubuntu-branches team in that code - that's not valid, not all package branches are ~ubuntu-branche
<maxb> s
<maxb> Hmm, nope, that mysterious http exception can't be from the new stuff, because that uses urllib2, and the exception was a httplib2 one
 * maxb shrugs and heads afk
<jam> maxb: you could pastebin the traceback if you have one
<poolie> jelmer: http://people.canonical.com/~ubuntu-archive/pending-sru.html
<Riddell> vila: ready when you are
<vila> Riddell: ok
<vila> poolie: just checked pending reviews for udd, bzr-builddeb and bzr-builder, all empty, did you have another one in mind ?
<poolie> nup, if that's all clear that's fine
<poolie> i reviewed some from max and saw some others, but i didn't check the page during the call
<poolie> could someone help https://answers.launchpad.net/launchpad/+question/165193 ?
<Riddell> poolie: looking
<poolie> thanks
<poolie> Riddell: the user experiencing it is in #launchpad
<jelmer> Riddell: I think I know what the problem is, please let me know if I should follow up
<poolie> ok, good night
<jelmer> have a nice evening poolie
<poolie> thanks
<poolie> i think the udd identity switch is now complete\
<poolie> we'll see
<Riddell> jelmer: go ahead if you want, I'm doing patch pilot now with vila
<jelmer> Riddell: will do, thanks
<vila> poolie: \o/
<vila> poolie: good evening
<maxb> jam: No traceback, just a HTTP 400 response. It's quite annoying. I get the same in UDD importer local tests - yet everything still seems to work!
<poolie> hi maxb
<maxb> Hello
<maxb> I guess I need to get httplib2 to log all requests or something
<poolie> httplib2.debug=1 or something like that
<poolie> woo
<poolie> https://tbe.taleo.net/NA3/ats/careers/requisition.jsp?org=CANONICAL&cws=1&rid=308
<marvin2> Hi, I have a local version of the branch lp:original-code; I need the some specific changes made to a fork of that branch located at bzr branch lp:forked-code. What is the most efficient way for me to incorporate those specific changes to my local bzr repo?
<jelmer> hi marvin2
<jelmer> marvin2: "bzr merge lp:forked-code"
<jelmer> Riddell: thanks for the review
<marvin2> jelmer: I need only specific changes from lp:forked-code
<jelmer> marvin2: after the merge you should be able to revert the changes you don't need
<marvin2> jelmer: OK, was looking for a more efficient way.
<jelmer> marvin2: alternatively, you can generate the diff between the two branches and edit that to contain the changes you need
<marvin2> jelmer: Exactly -> to generate a diff between the two branches, I'd have to have two separate repos on my local system - one for lp:original-code and one for lp:forked-code - is that correct?
<jelmer> marvin2: not necessarily, you can diff against a remote branch
<jelmer> bzr diff --new=lp:forked-code I think
<marvin2> jelmer: That becomes painful when lp:original-code is several revisions ahead of lp:forked-code
<jelmer> marvin2: why does that become painful?
<marvin2> jelmer: lp:forked-code is a fork to fix a bug, but hasn't been merged into lp:original-code yet. I'd like to manually bring it in to my local fork of lp:original-code.
<jelmer> marvin2: That's what "bzr merge" does; maybe I don't understand the full use case?
<marvin2> lp:original-code is at revno 10; lp:forked-code forks and adds bugfixes to it, and stagnates. Meanwhile lp:original-code keeps updating without incorporating lp:forked-code's fix.
<marvin2> jelmer: I'd like to keep up to date with lp:original-code, while manually merging in the fix from lp:forked-code
<marvin2> jelmer: Keep in mind original-code is "huge".
<jelmer> marvin2: I don't see how merge is inappropriate here
<marvin2> jelmer: lp:forked-code still contains code that has been updated by lp:original-code.
<marvin2> jelmer: I don't want to lose the changes made in lp:original-code.
<marvin2> jelmer: I hope I make sense.
<jelmer> marvin2: Sorry, I don't think I follow
<jelmer> marvin2: a merge of lp:forked-code won't overwrite changes made in lp:original-code
<jelmer> it'll try to merge the changes and create conflicts if there were any
<marvin2> jelmer: There'd be a lot of conflicts as lp:forked-code stays at revno 11, while lp:original-code move ahead to, let's say, 25...
<marvin2> jelmer: I'd like to figure out the most efficient way of dealing with this. I don't want to go around resolving 100s of conflicts I expect would show up. I just need the diff for a specific subset of files.
<jelmer> marvin2: why would there be a lot of conflicts? Is lp:forked-code changing the same chunks of code
<jelmer> ?
<jelmer> marvin2: generating a diff for forked-code and applying that would generate the same number of conflicts as merge, if not more AFAIU
<marvin2> jelmer: I think I'm wasting your time here. Let me get back to you with a proper example. Thanks for the help!
<marvin2> jelmer: I won't be generating a diff for the whole tree - just a subset of the files.
<jelmer> marvin2: but have you changed any of the other files in lp:forked-code?
<marvin2> jelmer: No...
<jelmer> marvin2: then there shouldn't be any risk of getting conflicts in them
<marvin2> jelmer: Oh...
<jelmer> marvin2: perhaps it's worth giving merge a try? As long as you don't commit, you can revert it without it ending up in your history.
<marvin2> jelmer: Yeah, I'll try that. Thanks!
<marvin2> jelmer: Given lp:original-code and lp:forked-code, how do I figure out the revno in which forked-code was forked from original-code?
<jam> marvin2: bzr log -r ancestor:lp:original-code -d lp:forked-code
<jam> though that may give a different answer if forked-code has then merged original-code again
<marvin2> jam: Great, thanks!
<jelmer> marvin2: there shouldn't be a need to specify a revision(if I understand your use case)
<marvin2> jelmer: Pure for academic purposes.
<marvin2> *Purely
<marvin2> jam: Complains about "-d"
<jelmer> marvin2: the -d isn't necessary
<vila> marvin2: 'bzr qlog original forked' (qlog is provided by the qbzr plugin) is another way to look at it
<marvin2> jelmer, vila: Thanks again.
<vila> jam: ping, did you get my pm ?
<jam> vila: just got back to my desk
<lifeless> jam: bug 813017 looks fun
<ubot5> Launchpad bug 813017 in loggerhead "DatabaseError: database disk image is malformed" [Critical,Triaged] https://launchpad.net/bugs/813017
<mwhudson> sqlite aiming for feature compatibility with bsddb?
<poolie> hi all
<jelmer> g'morning poolie
<poolie> hi there
#bzr 2011-07-20
<spiv> Good morning.
<poolie> hi there spiv
<poolie> hm jubany might be a bit jammed, i'm going to investigate
<poolie> spiv so is the bug you're working on the likely cause of the BzrCheckErrors in http://package-import.ubuntu.com/status/ ?
<spiv> I think so.
<poolie> what number?
<spiv> https://bugs.launchpad.net/udd/+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]
<spiv> Although there other BzrCheckError bugs that I suspect have the same root cause.
<poolie> thought so, thanks
<poolie> i'll add it to the categorization
<spiv> Thanks!
<AuroraBorealis> so....is there a reason why bzr explorer on mac doesn't have a dock icon?
<AuroraBorealis> isn't it just like a ...one line call?
<sameerynho> hi, i'm completely new to bzr , does bzr is a distributed vcs like git or hg?
<spiv> Yes
<spiv> Very much like those.
<sameerynho> spiv: so my local repo can be a stand alone repository and others can push to or pull from it, am i right?
<spiv> Yes.
<spiv> (Although others can only push directly to your repo if you grant them write access to your local repo somehow.)
<sameerynho> spiv: is there any script or anything like that for running a bzr server easily? like gitolite or gitosis for git?
<spiv> I'm not familiar with those, but you can serve bzr repositories quite easily over HTTP, SFTP, TCP, or SSH.
<spiv> For providing write access, SSH (the bzr+ssh protocol) is most common method.
<spiv> There are docs about those methods at http://doc.bazaar.canonical.com/bzr.2.3/en/admin-guide/
<sameerynho> spiv: thanks alot man
<spiv> Or if it's an open source project, you could use a free hosting service like Launchpad :)
<sameerynho> spiv: i see thanks
<jam> morning all
<jam> hey spiv
<jam> (just good to see you around)
<spiv> Hey :)
<poolie> hi there spiv
<poolie> s//jam
<poolie> maybe i'll land my patches before it's too late...
<jelmer> vila: Is there any way I can use babune to run the testsuite from the 2.3.4 SRU ?
<poolie> o/ jelmer
<jelmer> hey poolie, how's your day ?
<poolie> i don't know if you can do that without vila's help, but it would definitely be good to get it set up
<poolie> making a new schroot should be pretty cheap and easy
<poolie> we had a talk about how to do it a few weeks ago
<poolie> great thanks
<jelmer> ah, cool
<jelmer> I realized all my machines are on oneiric now, perhaps I should've held one back..
<poolie> i installed the natty proposed version
<poolie> it hasn't broken yet
<poolie> :)
<poolie> in fairly light use though
<poolie> how's oneiric today
<vila> jelmer: there is a way but it doesn't fit the babune model very well so far (a job want a bzr branch to test and here we want to test the installed version)
<jelmer> poolie: apart from mumble+bluetooth still being flaky together, it's doing well
<poolie> couldn't we have a job that's not related to a branch and that just fires on demand?
<vila> testing SRUs *can* be done but with a dedicated schroot and a dedicated job
<vila> poolie: yup
<poolie> that would be nice to set up
<poolie> or, fires ever 24h or something
<vila> yup
<vila> http://babune.ladeuil.net:24842/view/%20High/job/selftest-hardy/ is another kind of job that is not well supported so far
<vila> (see description there)
<jelmer> vila: thanks for the review of help-location-special-chars
<vila> jelmer: I could find a better way to express that that your proposal documents the actual behavior and still mentions the related issue that url encoding is not user-friendly (which we don't want to address for now)
<vila> grr
<vila> s/could/couldn't/
<jelmer> vila: Yeah - I agree with your comments, but was wondering if there's anything specific you'd like me to change to make it clearer?
<vila> jelmer: make the explanation more detailed to nail it good
<vila> specifically: bzr url-encode paths, use encoded URLs if you know better
<vila> which was the key thing (for me) in our Dublin discussion
<jelmer> ah, ok
<jelmer> that makes sense, I think
<vila> that gives us a good set of rules for devs
<jelmer> but perhaps it would be good if you can have another look after I fix it?
<vila> a bit less good for unaware users
<vila> jelmer: sure, just ping me
<poolie> vila, right, i guess we probably want a set of jobs, that can run on the existing schroot builders, for previous series
<vila> poolie: almost, I think we really want different schroot to start
<poolie> oh i was talking about testing 2.3 on hardy
<poolie> for ppa tests, i agree we need more schroots
<poolie> could i give you a task for setting them up? maybe after your break
<poolie> we can possibly do them more cleanly using snapshot-based schroots
<poolie> i'd be happy to pair on that with you
<vila> yeah, I'm thinking about union-based chroots, pairing welcome, I was planning to give babune some love today
<vila> but it's late for you
<poolie> i have a little more time
<poolie> so i think you remember how we bootstrapped the existing ones
<poolie> the main thing i think you should try is using aufs or something else to make a snapshot-based image
<vila> yup, and I have a python script to create the new ones
<poolie> which is explained a bit in the schroot manpage
<vila> yup
<poolie> then it will discard the changes after each run
<vila> the main issue I'd like to address is getting rid of the babune HOME mounting if only to get rid of the possibility that a job remove anything vital there
<poolie> mm
<poolie> that would be good
<vila> yeah, getting rid of the changes will probably works well for -proposed
<poolie> why does it need it?
<vila> because for jenkins the job runs on the master and the tested branch is checked out there
<poolie> but that shouldn't be an issue in this case as we're installing it from a package
<vila> indeed, hence the need for  a different chroot (at least for the config part which specifies the mounts)
<jml> mgz: around?
<mgz> aha, I was considering pinging you
<mgz> I've got an idea that might help some of the assertThat issues
<mgz> how about just putting the Mismatch object in the AssertionError rather than stringifying it? avoids a bunch of __str__ vs __unicode__ issues
<mgz> also puts the formatting entirely in the hands of the Mismatch rather than printing the Matcher at all
<mgz> I don't think there are any bad side effects from having a non-string type argument to an exception
<mgz> jml: anything in particular?
<jml> mgz: oh huh
<jml> mgz: just wanted your feedback on a bug
<jml> mgz: https://bugs.launchpad.net/testtools/+bug/675323
<ubot5> Ubuntu bug 675323 in testtools "assertThat style gives overly verbose output" [Wishlist,Triaged]
<mgz> how would you feel about just printing the "Difference" portion and none of the rest?
<mgz> in cases like assertThat(something_long, DoctestMatches(pattern, doctest.REPORT_UDIFF)) that'll be much better anyway
<mgz> and trivial things like assertEqual(1, 2) are clear anyway without being explicit about what the Matcher and matchee are
<jml> mgz: basically, that's my plan.
<jml> mgz: maybe adding a verbose option to assertThat to print its current output
<jml> mgz: patch up.
<jml> mgz: regarding your earlier comment, you mean doing something like 'raise AssertionError(mismatch)' and relying on AssertionError to call __str__ (and thus, describe)
<mgz> I do.
<mgz> Then we can get the logic right on the Mismatch classes, and avoid the python version variations on exception instances
<jml> Hmm.
<jml> mgz: That would change the API for mismatches, not sure that would be a problem.
<mgz> In which respect?
<jml> we don't currently insist on inheriting from Mismatch
<jml> and we don't currently use mismatch.__str__
<jml> so third-party mismatches that don't inherit will break
<mgz> hm.
<jml> where 'break' means, "<testtools.matchers.Mismatch object at %x attributes=%r>" % (id(self), self.__dict__)
<mgz> the other option is raising an AssertionError subclass on some python versions.
<mgz> which is also a tricky api change.
<jml> well, we could _always_ raise an AssertionError subclass
<jml> that would only break people who were expecting an exact class
<jml> but would still go alright w/ 'except AssertionError' or isinstance() checks
<jml> mgz: in some ways, I wouldn't mind raising a specialized exception for assertThat anyway. I think it would be nice to attach the matchee & matcher objects explictly and make them programatically available
<mgz> that sounds reasonable.
<jml> hmm.
<jml> I guess the break there is that if someone sets failureException, assertThat failures become errors.
<jml> I think that's as unlikely to be a problem in practice as third-party mismatches that don't inherit from Mismatch.
<mgz> nice unreadable failure with py3k on trunk testtools: http://paste.ubuntu.com/648412/
<Buttons840> i am leaving my current company, we have two programmers, and the other programmer will not use any version management, but i have tracked my changes with bzr; since they dont actually know how to use bzr, is there a way i can generate a pretty report to show the changes i've made that is independent of bzr?
<Buttons840> i think it would be nice to say, "here are the changes i've made, and why" -- they company has been good to me, so I want to be helpful as I can be
<mgz> just the forward slashes in test from gassy-failure-660852 branch I think, amusing commit message, "Oh man I hope this works."
<mgz> Buttons840: I'm not clear what the setup you were working from is
<mgz> if you imported the existing code somehow, then segregated your commits from imports of the trunk, you could get diffs of all of your commits and present those
<mgz> if you just committed your stuff and his stuff without demarkating them, that would be a bit more annoying to resolve
<mgz> Buttons840: put a post on the mailing list with some detail of how exactly you were working and what output you want, and you're likely to get useful responses
<jml> mgz: just saw #660852
<jml> mgz: which Python?
<mgz> ...wrong bug?
<jml> mgz: your comment is on the MP: https://code.launchpad.net/~jml/testtools/gassy-failure-660852/+merge/66470
<mgz> it's some weird merge issue.
<jml> mgz: yeah. I did a weird criss-cross merge in that branch. I had thought that it was merged into trunk alright though.
<jml> mgz: and since the tests pass in trunk for me, I am justified in thinking so.
<mgz> os.sep is "/" for you
<jml> mgz: oh, I see.
<mgz> test_traceback_formatting is bogus basically, I'm just trying to work out where it came from, it's not in the review diff
<mgz> or... I'm blind and it was.
<jml> mgz: it *is* in the review diff
<jml> mgz: that's the branch that added that test.
<mgz> okay, so it's not a merge thing, it's just a test copying a (previously removed) test style and confusing me
<jml> mgz: so it's "just" that we're broken on Windows?
<mgz> yup, that and DoctestMatches makes it impossible to tell what the issue is *grr* *grr*
<jml> mgz: I get better error messages from DoctestMatches than you do.
<jml> mgz: I think.
<mgz> the REPORT_UDIFF thing isn't as bad, and will be better again with your new proposal
<jml> hmm. do I don't.
<mgz> currently you *four* copies of a traceback are printed, and working out which is which is a nightmare
<jml> heh heh
<jml> I'd like to make REPORT_UDIFF the default. Thought I did, tbh.
<Mkaysi> Hi, I have problem with bzr. Every time when I am trying to bzr branch something I get this error (traceback) http://pastebin.com/hUNbZxg0 . What should I do? I have tried removing and installing all bzr packages.
<jml> mgz: can you please test this patch on windows? http://paste.ubuntu.com/648434/
<jml> mgz: also, I've put down a todo item to get jenkins up and running. I'd like to get proper testing across supported Pythons and OSes.
<mgz> looks like the right thing
<jml> mgz: looks can be deceiving :)
<jml> Mkaysi: weird.
<jml> Mkaysi: what OS are you using?
<Mkaysi> jml: Ubuntu 11.04
<mgz> jml: does pass, go ahead and push
<jml> mgz: thanks.
<jml> mgz: fixed in trunk. Thanks for catching that.
<jml> Mkaysi: that's just weird.
<jml> Mkaysi: which version of Bazaar do you have installed?
<Mkaysi> jml: How do I see it? I was using latest from Ubuntu repos, but when that problem came I moved to Daily PPA
<Mkaysi> (just because I noticed that there is daily PPA)
<jml> Mkaysi: $ dpkg -s bzr | grep ^Version
<Mkaysi> jml: Version: 2.4.0~bzr6033~ppa3957.3940~natty1
<jml> Mkaysi: ok. try this
<jml> Mkaysi: run python on the command line
<jml> Then do...
<jml> >>> import bzrlib
<jml> >>> bzrlib.__file__
<jml> '/usr/lib/python2.7/dist-packages/bzrlib/__init__.pyc'
<jml> >>> bzrlib.version_info
<jml> tell me what __file__ and version_info print.
<Mkaysi> '/usr/lib/pymodules/python2.7/bzrlib/__init__.pyc'
<Mkaysi> Traceback (most recent call last):
<Mkaysi>   File "<stdin>", line 1, in <module>
<Mkaysi> AttributeError: 'module' object has no attribute 'version_info'
<jml> Mkaysi: ok, thanks.
<jml> Mkaysi: I'm guessing it's a bug in the daily build
<Mkaysi> jml: But this happened while I was using latest version from Ubuntu repos too.
<jml> I'm not sure how that's even possible.
<jml> Mkaysi: I can't think of how to progress further. Sorry.
 * jml is off home
<Mkaysi> Is there any way to download .zips or .tar.gzs from LP?
<mgz> yup, from the downloads page. you might have luck just purging the package then not using the daily.
<Mkaysi> Ok
<Mkaysi> Thanks
<lamalex> hi, i can never remember the syntax to just revert the changes from a single commit
<LeoNerd> merge -rafter..before
<lamalex> when i do that, it shows MANY more changed files than were changed in the commit i'm trying to undo
<lamalex> so i want to revert commit 666
<lamalex> i would do bzr merge -r 667..665?
<luks> no, it should be 666..665
<fullermd> No, 666..665
<luks> or, bzr merge -r666...before:666
<luks> which correctly handles non-mainline revisions
<luks> er, only two dots
<fullermd> Unless it's life or death, then you want -r666...___...665   8-}
<lamalex> :{
<lamalex> :P
<lamalex> thanks
<awilkins> the log widget in qbzr has a convenient reverse-cherry-pick this revision option
<Buttons840> i can i see commit diffs 1 through 10 excluding 5 (for example)?
<poolie> hi all
<jelmer> g'day poolie
<jelmer> hi amanica
<amanica> hi jelmer! :)
<jelmer> poolie: I think you mean s/Jelmer/vila/ in your email?
<maxb> jelmer: Hi. The bzr-beta PPA is now completely installable except for bzr-svn. Do you think you might be making a 2.4-compatible snapshot soonish?
<poolie> hi, i did, just a typo
<poolie> hi maxb
<dOxxx> I'm wondering what to do about the QBzr release that bialix just made for bzr 2.3 series, since I've already built the installer with an older version.
<poolie> hi dOxxx
<poolie> maybe rebuild with a further dot revno?
<poolie> or, save it for a later 2.3.x?
#bzr 2011-07-21
<dOxxx> poolie: I think maybe a -2 build
<poolie> that could be good
<poolie> the next 2.3 release is probably about a month away, so it'd be good to get it out there
<jelmer> maxb: hi
<jelmer> maxb: unfortunately that's blocking on a bug: bug 803353
<ubot5> Launchpad bug 803353 in subvertpy "segfault during iconv close from ra cleanup" [High,Triaged] https://launchpad.net/bugs/803353
<RenatoSilva> verterok: hi verterok
<RenatoSilva> verterok: are you there?
<dcrane> hi, when I try to make do bzr branch on another hard drive, all of the file permissions are changed, so it shows up as every file being modified, with bzr diff showing "(properties changed: -x to +x)" for every file. Is there a way around this?
<bob2> is this because you copied it to/from a fat32 filesystem?
<dcrane> no
<dcrane> erm, yes
<poolie> spiv, hi, your inline diff branch landed
<poolie> well, i guess you saw
<spiv> poolie: oh good, thanks!
<poolie> but it's not on qas yet
<spiv> Unfortunately I've been spending most of the day lying down with a nasty headache :/
<poolie> sorry for the false alarm
<poolie> :/
<poolie> nice weather for it
<spiv> Heh.
<poolie> if it deploys i will have poke at it for you
<spiv> Thanks!  The main thing for QA I think is to see that without the feature flag it doesn't break the branch merge proposal page (I'm sure it'll be fine),
<poolie> there's a separate bug saying it would be nice if devs could edit them directly on qas
<spiv> and then if the feature flag is set (maybe just for canonifolk or beta-testers?) that the expanders exist and work on that page.
<spiv> Yeah, that would be nice
<poolie> hi vila
<vila> poolie: :)
<vila> not there yet, coffee time
<fullermd> Hmmwhut?  Coffee?
 * fullermd perks up.
<vila> poolie: dunno what happened with rypple, I still had the lp URL I pasted in the comment in my clipboard...
<poolie> vila, rms asks that you mention bzr is a gnu package in every release announcement
<poolie> you should probably mention Canonical too
<poolie> and use your real name, unless there's some compelling reason not to
<vila> real name ?
<poolie> From: vila <v.ladeuil+lp@free.fr>
 * vila nods at GNU & Canonical, it's so obvious to me I forget to mention them
<poolie> i know
<poolie> and this is just a minor update
<poolie> perhaps put it at the bottom
<poolie> that is to say, after the text about the purpose of the release, before your sig and the mail
<fullermd> vila: Don't worry, we all already know about your shameful past anyway.  The assumed name isn't fooling anybody   :p
<vila> fullermd: hehe, quite the contrary in fact, it's a well known fact from companies and political parties that changing names works, people have a bad memory
<fullermd> Hah, I bet those 17 nuns and 23 schoolchildren remember all too well!
<vila> fullermd: what's the previous name of Accenture ?
<lifeless> enron ? :P
<fullermd> Oh, you were responsible for THAT, too?  No wonder you changed your name...
<vila> no, seriously, how many people still remember the old name ?
<fullermd> Nobody even remembers the current name.  That's what google is for.  Memory is SO 20th century.
<poolie> vila, rm, how would you feel about having just one set of release notes per whole of 2.5
<poolie> rather than splitting per beta
<poolie> my sense is that it's really the main releases that matter now
<poolie> perhaps not enough people look at them for it to be worth changing
<vila> poolie: I'd rather stick with one per release if only to stay in sync with lp and make it easier to diagnose
<vila> bugs or other feedback from beta testers
<poolie> oh because they're split out on lp
<poolie> fair enough
<poolie> i should read your RM tweaks
<vila> that would be good
<vila> I'm not sure reading the diff only makes sense though,
<vila> but as I said, I've read this doc far too much
<poolie> maybe you could build it and put up the html?
<poolie> i think that helps for doc changes
<poolie> also helps catch markup errors
<vila> I did check locally with 'make docs' and 'make docs-sphinx' and firefox, will put a sphinx version online, justasec
<vila> done at http://people.canonical.com/~vila/
<vila> -doc is the regular one, -sphinx is the.. sphinx one
<vila> doesn't match doc.bazaar.canonical.com though, missing dependencies probably
<vila> hmm
<vila> I think generating them locally is easiest :)
<poolie> diff --using meld helps too
<vila> oooh, using the remote branch you mean ? Or with the reviewed branch already pulled locally ?
<poolie> ok done
<poolie> thanks for doing all that work
<poolie> i pulled it, but i guess i could have done it remotely
<poolie> boy i'm tired
<vila> meh, given 2.3.4-0ubuntu1 and 2.3.4-0~bazaar1~natty1 available, shouldn't the former be considered more recent than the later ?
<vila> oh, priorities between their archives
<vila> here we go, dandling /etc/apt/preferences :)
<Riddell> good morning bazaar
<vila> _o/
<jam> morning all
<vila> jam: good morning !
 * jelmer waves
<jelmer> vila: I've updated the special-chars doc a bit: http://pastebin.ubuntu.com/648943/
<jelmer> vila: comments welcome - does this address your concerns?
<vila> jelmer: excellently :)
<vila> jelmer: thanks a lot for your patience !
<jelmer> vila: thanks for the reviews :)
<jelmer> next, I'll have a look at updating the colocated support branch
<bialix> jam: hi
<jam> hi bialix
<bialix> jam: today I've made releases of QBzr and Explorer for bzr 2.4. I've updated windows-installer metadata, I hope this branch can be landed before bzr 2.4 final: https://code.launchpad.net/~bialix/bzr-windows-installers/qbzr-explorer-for-2.4/+merge/68649
<bialix> jam: due to my mistake with ~bzr membership I'm not able to push directly to windows-installer branch, so I have to create MPs instead
<jam> no problem, I'm landing that one know
<jam> now
<bialix> I don't know what must I do now
<bialix> jam: ok, thank
<maxb> bialix: jam could put you into ~bzr ?
<bialix> maxb: I think so
<jam> bialix: I'll check
<jam> bialix: you're added
<bialix> thank you jam
<jam> I think it is still reasonable to make mps, just to track the changes, but it isn't critical
<maxb> Oh, jelmer is no longer away. I should pick up the discussion on merging ~bzr-core into ~bzr
<jelmer> maxb: hey, what's up?
<maxb> Hi
<maxb> I'd been looking at what it would talk to get rid of all of ~bzr's structural subscriptions such that there would no longer be a reason to split ~bzr-core
<maxb> Most of them seemed fairly reasonable, except that ~bzr includes ~bzr-git, and ~bzr-git has some structural subscriptions for bzr-git
<maxb> er
<jelmer> I'm happy with changing the subscriptions for ~bzr-git
<jelmer> to match what we do for other plugins
<maxb> or at least, I thought that was what the problem was, but my old email is contradicting me
<maxb> Oh, whoops
<maxb> When I said ~bzr-git, I meant ~bzr-gtk in this case
<jelmer> ah, ok
<maxb> https://launchpad.net/~bzr-gtk/+structural-subscriptions
<jelmer> I have the same opinion for bzr-gtk, though we'd probably have to check with some other people too
<maxb> The other teams that contribute structural subscriptions to ~bzr are ~bzr-upload-devs (vila) and ~qbzr-bugs (garyvdm)
<bialix> what's about ~bzr-bugs?
<bialix> what's about ~qbzr-bugs?
<maxb> Per my email of June 14th, there does not appear to be any consistent pattern to which plugins do or do not get included in ~bzr's subscriptions
<bialix> do you need just remove it?
<maxb> bialix: ~qbzr-bugs has ~bzr as a member to give ~bzr members bug supervisor rights over qbzr, but it also has a structural subscription to qbzr's bugs
<maxb> The issue is that I don't think ~bzr membership should imply defaulting sending people much, if any, email
<bialix> maxb: right now only ~bzr-qa is member of ~bzr-bugs
<bialix> maxb: yep
<maxb> ~bzr is a member of ~bzr-qa
<bialix> weird
<bialix> maybe at the past it sounded reasonable to have more bug mails for qa/bug supervisor teams
<maxb> Basically it comes down to it really never making sense  to use the same grouping of people for access control as for sending email
<bialix> I don't see any value in ~qbzr-bugs team today
<bialix> ~qbzr-bugs group only can triage bugs, IIRC
<maxb> So, in short, my plan is to attempt to get agreement in removing all subscriptions from ~bzr-gtk, ~bzr-upload-devs and ~qbzr-bugs, then proceed to removing bug subscriptions from ~bzr, and then proceed to a final proposal to merge ~bzr-core into ~bzr, ending the confusion
<jelmer> maxb: +1
<bialix> I'll be happy to remove ~qbzr-bugs team as well
<jelmer> vila: ^
<maxb> bialix: Remove the team?  Or just remove its bug subscription?
<maxb> I assume the team exists to manage bug supervisor permissions on qbzr
<bialix> maxb: main QBzr developers team is ~qbzr-dev
<bialix> maxb: I think so
<maxb> Right - so ~qbzr-bugs exists to allow you to permit non-developers to have bug triage access
<bialix> maxb: right, but I think nobody but ~bzr-dev and poolie has done that
<bialix> sorry, I meant ~qbzr-dev
<vila> jelmer: +0, I don't have issues (almost) with lp mail, so I don't feel qualified to comment there. It may change the day I *miss* mails, but that doesn't seem to be the case with the proposal
<bialix> if removing subscription means mute bug mails -- I'm ok
<jelmer> vila: you can always personally subscribe to those projects
<bialix> today the number of bzr mails I got is way too much.
<jelmer> vila: thanks to the new bug subscription work by the lp team
<jelmer> (I think that's what prompted maxb's proposal?)
<vila> yeah, I'm unclear about why all these teams changes are still required...
<vila> I'm all for *reducing* the number of teams anyway
<maxb> vila: The work done by the LP team means it's possible to opt out of inherited subscriptions. It doesn't make it easy or convenient
<maxb> Also, I don't think defaulting to sending ~bzr bugmail about stuff actually makes sense
<jam> vila: as the current PP, care to look at: https://code.launchpad.net/~jameinel/bzr/2.5-verbosity-knob-812928/+merge/68559
<jam> I know Barry thought the changes were good, I'd like at least someone else's opinion.
<jam> jelmer: a question about bzr-svn and tags
<jam> I just poked at lp:gcc-linaro, and it has 2626 tags that are not in the repository.
<jam> Is this because svn creates a new commit when creating a tag
<jam> and bzr-svn then imports that as a separate commit.
<jam> ?
<jam> So *most* bzr-svn converted repositories are going to have 90%+ of their tags not in the main trunk history?
<maxb> igh
<maxb> ish
<maxb> bzr-svn does the right thing if the tag is a "simple copy" made via a url-to-url copy, or a copy from a svn wc that is at a single revision
<jam> maxb: what is slightly worse is that because bzr-2.4 is going to start copying those tags by default, anyone using a shared repository locally that has those revs, is going to start pushing them up to all of their stacked branches.
<jam> maxb: http://paste.ubuntu.com/649052/
<maxb> However, if the svn tag was made by copying from a svn working copy that was at mixed revisions, bzr-svn attempts to represent this as an off-trunk revision
<jam> maxb: so if you just "tag" your local checkout, it re-creates the layout as a tagged rev?
<maxb> In practice, this isn't really what most people would want, and I have an idea that bzr-svn ought to do more checking of the nature of the tagged tree, and possibly intelligently pretend the tag is on trunk, if that won't affect the tree content
<maxb> jam: exactly
<jam> maxb: well, the cat-is-mostly-out-of-the-bag since changing the scheme creates a different set of revs, right?
<maxb> I think we could just pretend otherwise in this case
<maxb> We'd only be changing the logic that says what revid a tag points to, not the data in any revision itself
<jelmer> jam: sorry, just got back from lunch
<jam> jelmer: np
<jam> I was hoping the new fetch behavior would make bug #388269 less problematic, because we would be seeding lots of search points.
<ubot5> Launchpad bug 388269 in Bazaar "many get_parent_map calls during walk to common revisions when branching into empty repository" [High,Confirmed] https://launchpad.net/bugs/388269
<jam> but... they are all ghosts...
<jelmer> jam: svn tags are basically copy operations, and bzr-svn only tags them on the mainline if they don't have any additional changes
<jelmer> jam: some people will create tags for e.g. a release that make a trivial additional change, like the equivalent of setting 'final' in the version string in bzr
<maxb> Yes - though there's a class of additional change which are essentially no-ops, which I think bzr-svn ought to ignore
<jelmer> maxb: what sort of changes?
<maxb> If the tag is made from a mixed revision svn working copy, svn will record all the mixed revisions. But, if in fact the working copy could have been "svn update"d to the newest revision involved in the tag without actually causing any tree changes, it would be nice if bzr-svn could recognize that as a simple tag
<jelmer> maxb: can you give an example of ta tag where that has happened?
<jam> jelmer: well, out of 2690 tags in lp:gcc-linaro, only about 64 are actually present in the repository
<maxb> Pretty much any tag made by the maven-release-plugin, so I should be able to find an example in the apache repo
<jam> so whatever trick is "common" apparently happened there a lot
<maxb> http://paste.ubuntu.com/649064/
<vila> jam: sorry, just got back from lunch
<maxb> jam: Wait, are these ancient tags dating back to cvs days?
<jam> maxb: not sure, I see svn ones when I poke at it briefly
<maxb> jelmer: So, in my paste, you can see a tag constructed via a copy from 701933, and a subtree replace of 701941. But, by checking the history of the copy source, we can see that the resultant tree is exactly the same as a direct copy from 701941.
<jam> vila: long lunch :) no problem
<maxb> Representing the tag as a direct copy from 701941 is clearer and closer to the user's intent, and avoids the extra revision
<jelmer> maxb: the file changed in between, in 701934
<maxb> jelmer: Yes, but the tag incorporates this change
<vila> jam: yeah, had some shopping to do, it's amazing how it always took longer with girls...
<maxb>    R /maven/plugins/tags/maven-antrun-plugin-1.3/pom.xml (from /maven/plugins/trunk/maven-antrun-plugin/pom.xml:701941)
<maxb> That particular file is promoted to a revision after the change, in the tag
<jelmer> maxb: I'd consider that a svn bug
<jelmer> maxb: analysing history to figure out that sort of thing can become really complicated
<maxb> Well, less of a bug, and more a complete failure to design for what users actually want.
<maxb> And yes, producing a nicer conversion by history analysis is definitely complicated
<maxb> It would, however, lead to nicer user experience of bzr and bzr-svn, and a more faithful representation of the original intent in bzr
<jelmer> maxb: this can get really complex (and time consuming) on some tags if a lot of history is involved
<maxb> Yes, this might turn out to be too complicated to be actually worth doing in bzr-svn
<jelmer> maxb: I don't think this is worth considering until bzr supports versioned tags
<maxb> However, it's definitely worth doing if bzr-svn ever grew support for doing extra work in a one-time conversion mode
<jelmer> vila, Riddell: if you are still patchpiloting, did you see https://code.launchpad.net/~jelmer/bzr-loom/fix-record-entry-contents/+merge/68426 ?
<vila> jelmer: approved, which a question :)
<jelmer> vila: dankuwelmerci
<vila> hehe
<vila> bhaa
<vila> with a question (that my browser didn't want to send for unkown reasons 8-/)
<vila> jelmer: In what context was the test failing and why not sooner ?
<vila> jelmer: location-commas also approved
<jelmer> vila: I'm not entirely sure why it didn't fai earlier; perhaps we didn't use the parent inventories in record_entry_contents before in some cases?
<jelmer> vila: posted the backtraces
<vila> jelmer: LeYSME ? Isn't tmpfile funny sometimes :)
<jelmer> vila: I had nothing to do with that, promise :)
<jelmer> vila: thanks for the location-commas review
<jelmer> vila: I'll also wait for John, as he is one of the heavy users of comma's in names
<bdestefanis> anyone else having trouble opening bazaar explorer?
<bdestefanis> i'm getting a key error '\x00'
<bdestefanis> in commands.pyo and most recent call is in pickle.pyo
<bdestefanis> more details here: https://bugs.launchpad.net/bzr/+bug/814151
<ubot5> Ubuntu bug 814151 in Bazaar "bazaar explorer no longer opens" [Undecided,New]
<bdestefanis> does bazaar use windows domain certificates for anything?
<mgz> bdestefanis: delete $BZR_CONFIG/explorer/history.dat
<mgz> bzr version will tell you where the config dir is
<mgz> on windows it's probably %APPDATA%\bazaar\2.0\explorer\history.dat
<bdestefanis> i think i may have caused this problem.
<bdestefanis> by trying to unversion a directory.
<mgz> possibly.
<bdestefanis> now the main branch has a lot of unresolved conflicts
<mgz> but it's a bug in explorer whatever
<bdestefanis> that i can't seem to revert
<bdestefanis> let me try what you suggested
<mgz> if you could find the file, and upload it to the bug, that might make things clearer
<mgz> you may want to check it for personal info first (it's a binary format though)
<bdestefanis> wow. deleting the history.dat file fixed it.
<bdestefanis> thanks! :)
<bdestefanis> this new version of bazaar seems to be a bit faster too :)
<mgz> bdestefanis: if it's still in your recycle bin, uploading it to the bug might help us work out what caused the problem in the first place
<bdestefanis> i renamed it to history.backup
<bdestefanis> i will attach it to the bug
<mgz> thanks!
<bdestefanis> on other thing you guys are probably already aware of
<bdestefanis> for whatever reason....anytime i perform an operation in bazaar explorer ...it takes about 60 seconds or more to become responsive after the operation is completed.
<bdestefanis> the window goes into the "Not Responding" state
<bdestefanis> and if you wait long enough you can use Bazaar Explorer again
<bdestefanis> this is on Windows 7 64-bit
<mgz> that doesn't sound typical, would be good to find out what it's doing during that minute
<bdestefanis> yeah, i'm using a path like \\ip.address.goes.here\c$\www\bzrversioneddir
<bdestefanis> but it doesn't seem to make a difference if i use http
<bdestefanis> i have wireshark i suppose i could see if anything is happening on the wire
<bdestefanis> i have no idea what my boss did to the repository ...but now i have all this garbage and i can't revert it. i think i'm going to killl myself.
<bdestefanis> from wireshark
<bdestefanis> it looks like it is using SMB to iterate over all of the paths in the bzr versioned directory
<bdestefanis> these are requests from the server to my machine
<bdestefanis> i'm sorry
<bdestefanis> reverse that
<bdestefanis> they are requests from my machine to the server
<awilkins> I wonder if his boss did a checkout on the server
<awilkins> That causes things to REALLY slow down
<awilkins> But it looks like it was a checkout anyway
<awilkins> Hmm
<DonDiego> hi
<DonDiego> bzr rebase moved a few of my commits into limbo (after stumbling over a merge i think)
<DonDiego> is there something like "git reflog" in bzr that i can recover them with?
<DonDiego> googling hasn't provided answers...
<jelmer> DonDiego: there isn't anything like reflog, but you can use "bzr heads --dead" to find bzr revisions that exist but do not have anything pointing at them
 * jelmer runs off to dinner
<DonDiego> jelmer: thanks, that helped
<jo-erlend> In 11.04, I installed bzr-gtk. Didn't that use to come with a gui for bazaar where you could see files, diffs, etc?
<lxsameer> hi, my connection lost in middle of a cloning , how can i resume cloning? ( .bzr dir exists )
<LeoNerd> http://www.pastie.org/2250474  <== wtf did that just do.. and how do I undo it?
<LeoNerd> I think I've branched history somehow.. do not want.
<maxb> LeoNerd: you bzr upped in a bound brach with commits ahead of the bound location
<LeoNerd> Yes...
<LeoNerd> It used to fail-and-die when I did that. I want that behaviour back
<maxb> accordingly bzr fetched the new commits, and moved the local commits to a pending merge
<LeoNerd> Yeah.. I reeeally dislike that behaviour
<maxb> so, just committing the pending merge should be fine
<LeoNerd> I don't want it to appear as a merge, though
<maxb> why not?
<LeoNerd> Because I dislike the unneatness that'll appear in the history
<maxb> it *is* a merge, stop trying to pretend otherwise :-)
<LeoNerd> It should'nt be
<LeoNerd> It should appear as a strict new revision
<maxb> delph wants to know if you're still at work :-)
<LeoNerd> Athome
<maxb> he's leaving the pilot now
<LeoNerd> Hrm.. remind me again how I update back to a dead head... It's complaining it doesn't exist.. :/
<LeoNerd> Oh.. bah. I wanted pull
<LeoNerd> There we are. bzr heads --dead-only.. find revid. bzr pull -r revid:...; bzr push
<LeoNerd> And now my history is linear again :)
<RenatoSilva> verterok: hi
<verterok> RenatoSilva: hey
<RenatoSilva> verterok: did you see the new proposal? the conflicts were simple to solve...
<verterok> RenatoSilva: yes, will review it asap. thanks!
<RenatoSilva> verterok: thanks too
<verterok> RenatoSilva: fyi, I'll be moving the project to tycho (maven 3)
<verterok> RenatoSilva: that way anyone can build the thing easily
<verterok> RenatoSilva: and execute the tests without configuring everything in eclipse
<RenatoSilva> verterok: I've heard of it on some merge and thought it was just a plugin, not the codename to maven 3
<verterok> RenatoSilva: it's a plugin, but it requires maven 3
<RenatoSilva> verterok: ah ok
<RenatoSilva> verterok: how about those old encoding problems in bzr-xmloutput heh... no volunteer to fix them :(
<verterok> RenatoSilva: are still there :(
<RenatoSilva> verterok: (required to cut some edges in bzr-eclipse)
<verterok> RenatoSilva: I thinking in moving it out of the command based approach
<RenatoSilva> someone please bzr-eclipse needs help! (and hence bzr-java-lib/bzr-xmloutput)
<verterok> RenatoSilva: to use a real rpc
<verterok> RenatoSilva: basically stop using commands, it's a lot of work and not even started with it :/
<RenatoSilva> verterok: I somewhat remember one of our discussions on calling bzrlib directly, but it would require some other project to evolute enough or something... can't recall
<verterok> RenatoSilva: yes, jython
<verterok> RenatoSilva: jython isn't there yet
<RenatoSilva> verterok: is it by any chance the lack of C-implemented python modules?
<RenatoSilva> verterok: which is required by bzrlib?
<verterok> RenatoSilva: ctypes
 * RenatoSilva thinks is required
<RenatoSilva> verterok: so jython hasn't implemented ctypes yet? bah
<verterok> RenatoSilva: only a small part
<RenatoSilva> does bzrlib use stuff which requires native code or is it made by native code too?
<verterok> RenatoSilva: it requires some platform specific stuff
<RenatoSilva> verterok: do you remember the other option of porting bzrlib to Java? Not sure if it's insane and which one would be harder (this or completing ctype)
<verterok> RenatoSilva: that's a lot of work (the porting of bzrlib)
<RenatoSilva> and the syncing
<RenatoSilva> brb
<vila> finally: http://babune.ladeuil.net:24842/job/selftest-chroot-natty-proposed/32/testReport/
<vila> 2.3.4-0ubuntu1 installed in a natty chroot
<poolie> hi vila, jelmer
<jelmer> hi poolie
<poolie> spiv: alive?
<spiv> poolie: yes, and apparently over a degree cooler than yesterday.
<poolie> you are?
<poolie> hm i guess that's good
<poolie> the bmp stuff should now be live on qastaging, so i was going to see which one of us should test it
<spiv> Ah, cool, I'll poke at it.
<poolie> in some ways having someone else test might be better?
<spiv> Well you can too :)
<poolie> if you're ready now we can ask the losas to turn it on
<jelmer> g'morning spiv
<jelmer> spiv: I added some feedback to bug 718944, sorry for not noticing it earlier
<ubot5> Launchpad bug 718944 in bzr-builddeb "bzr-builddeb merge sorts the changelog by version order, rather than preserving existing ordering" [High,In progress] https://launchpad.net/bugs/718944
<spiv> jelmer: ooh, thanks for the links to the other bugs!
<spiv> I guess I'll merge that today then, the feedback on the list was (cautiously) positive too.
<jelmer> cool, that'll make quite a few ubuntu devs happy(ier)
<jelmer> have a good day
 * jelmer gets some sleep
<poolie> sleep tight
#bzr 2011-07-22
<poolie> hi maxb
<poolie> spiv i'm trying to qa 813349
<poolie> i turned off the importer for now
<maxb> Hi poolie
<maxb> And, no, I don't know why I'm still awake
<poolie> hi max :)
<poolie> i'm glad you are; it's good to have a second pair of eyes
<poolie> spiv is sick
<poolie> but i hope you get to bed eventuall
<poolie> you're right, perhaps we should just run from a checkout
<poolie> maxb we're on 2.3.4 now
<lxsameer> my connection lost in middle of a cloning, how can i resume cloning? (.bzr folder created)
<bob2> is it in a shared repository?
<lxsameer> bob2: like lp ? yeah
<wgrant> spiv: Around?
<wgrant> Ah, sick, I see.
<vila> hi all !
<wgrant> spiv: On the off chance you are watching, inline MP diffs are now switched on on production for ~launchpad.
<vila> wgrant, spiv : soooo nice
<wgrant> The styles are a bit off for me, but it works!
<spiv> wgrant: sweet
<spiv> wgrant: I am around today, but working pretty slowly :/
<spiv> Hmm, the "loading diff" message could use the little spinner icon.
<spiv> And rendering huge diffs makes firefox struggle a fair bit :)
<wgrant> spiv: Yeah, but those are tiny tweaks :)
<spiv> wgrant: right, incremental improvement FTW :)
<jam> morning all
<jam> spiv: I thought links that expanded inline were supposed to be green? They are blue on my page.
<jam> And yes, a spinner would be nice, I just went to: https://code.launchpad.net/~vila/bzr/rm-tweaks/+merge/68274 and it took quite a while to bring up the diff.
<jam> (I'm guessing that is primarily loggerhead loading the cache for the first time of a new branch, which I have fixes for, but all a bit blocked. :)
<vila> jam: I just pushed some corrections, may be it made it worse ?
<jam> vila: I'm not talking the whole diff, I'm talking SPIV's sexy new "show me the diff of this subset of the changes"
<jam> though yes
<vila> me too :)
<jam> loggerhead will rebuild the history from scratch if the tip changes
<jam> which again... fixes available :)
<jam> very nice spiv!
<spiv> jam: thanks :)
<spiv> jam: hmm, yeah, the something about the CSS must have changed.
<spiv> Ideally details like showing a spinner and the right style for the expander link will be mostly part of the standard expander.js infrastructure
<spiv> Possibly they already are and I'm just not using it quite right.
<vila> haa, I just got a slow load, all previous ones were fast, jam, may be you loaded them before me populating the cache ?
<jam> vila: right. When loggerhead sees the tip change, it starts from scratch, and walks the whole ancestry
<vila> in any case, that would make reviews of intermediate changes far easier (and doable online)
<vila> mail reviewers may not benefit from it though...
<vila> poolie: The inline diffs should make it easier to re-review rm-tweaks, care to give it a go ?
<poolie> hi vila
<poolie> what a great idea!
<jam> vila: I know there are plans in abentley's head to change the process to be able to send updated diffs along with updated comments
<jam> (via email)
<jam> but certainly, short term this is good stuff
<jam> vila: for the config stuff and verbosity knob
<jam> this was actually originally targetted at 2.2
<vila> oooh
<jam> I'm not sure if we should be thinking about backporting it or not
<jam> poolie: any thoughts on "out-of-date" messages?
<jam> vila: my first thought is that we should target Natty
<jam> since that is where people are writing code for Oneiric
<vila> jam: yup, that what I thought too, 2.4
<poolie> jam i liked the phrasing in your current diff
<jam> vila: isn't natty 2.3?
<jam> poolie: thanks. Though the question was meant to be, where should we be trying to get it landed?
<vila> jam: oh, right, then no, I think 2.4 is good enough
<poolie> i would say 2.4 at first
<jam> sure "at first", and maybe Oneiric will be out soon enough we won't backport. But wouldn't 2.3 make sense?
<Riddell> good morning all
<poolie> spiv, vila, wow, that works very well
<vila> poolie: isn't it ? :)
<poolie> it depends a bit how confident you are it cannot cause any regressions
<poolie> is the option now guaranteed to switch it all the way off?
<poolie> vila, oh, i see http://babune.ladeuil.net:24842/view/SRUs/job/selftest-chroot-natty-proposed/
<poolie> i assume those previous broken builds are due to you futzing with it?
<vila> yeah, I finished too late yesterday to write an email
<vila> hehe
<vila> indeed :)
<jam> poolie: it still runs a regex check before it reads the config setting, but otherwise config == 'off' is a shortcut to exiting the hook
<vila> I will clean this up today and re-run as a final test and to get a proper history
<poolie> ok
<poolie> ok
<jam> vila: on a different tack, I don't really think branch config is ideal here, vs just a global setting. what do you think?
<poolie> if i had to choose, the announcement is more important than having pretty history
<poolie> i think global would be ok; we can always refine it later
<vila> I think by default we shouldn't restrict to a global setting only, let the user decide
<vila> I can imagine some branches where I damn well know I'm out of date and don't want to be nagged endlessly
<vila> poolie: you're right, writing the emails now
<jelmer> hi jam, poolie, vila
<vila> _o/
<jelmer> vila: is the upload to lucid-cat of bzr 2.3.4 still necessary?
<vila> I wanted 2.4b5, but since we went back to 2.3.4, this will have to wait
<vila> jelmer: up to you, but 2.4.0 is not that far away
<poolie> hi jelmer
<poolie> vila, uh, maybe you should mention the sru jobs?
<poolie> also, could we get them to run every 24h or so?
<vila> poolie: separate mail for srus
<poolie> ok
<jelmer> vila: ok
<vila> poolie: what would be the point ?
<poolie> following up to that 'critical' mail, could someone investigate whether jubany's more happy now, or what needs to be done to get those branches ok again?
<poolie> i need to go soon
<vila> if we want to automate, I can look into checking the package version
<poolie> oh, the point of running every 24h?
<vila> yeah
<poolie> well, it means there's a fair chance there will be something up to date when i go to look at it
<poolie> rather than there being a guarantee i need to ask for a new build
<poolie> also, it's probably easier than scripting it?
<vila> hmm
<vila> right, let's start with every 24h
<vila> tweaked
<jam> poolie: we have 179 current failures with the associated bug.
<jam> However, I don't know what (if any) of the packages you restarted
<vila> yeah, we need some log for imports restarted on demand to communicate better there
<maxb> Does anyone see a problem with just retrying the entire 179 on the new bzr version and seeing what happens?
<vila> no, as long as you start with one or two first maybe ?
<jam> maxb: as long as it doesn't set them as always-retry-this-failure
<jam> so "retry these, but don't set it as a retry-able failure mode"
<jam> vila: other topic, so, switching to use a stack-based config doesn't seem like it adds much, and it makes it harder to backport in the future.
<jam> also, I'm not very happy with the config name
<jam> but I don't think switching to just "launchpad" is quite right, either
<jam> I guess "bzr." is reserved for core bzr ?
<vila> jam: not switching means adding tech debt on trunk
<jam> vila: barely any, tbh
<vila> no, we get rid of 'bzr.' entirely
<jam> I don't really see why Branch.get_config() can't return ConfigStack(self)
<vila> hehe, just try :)
<jam> vila: where are the docs for the naming scheme, because somehow I missed them completely
<jam> vila: I realize it doesn't implement the same api today, but if you are worried about tech debt, it doesn't seem to be adding really anything new
<jam> it certainly looks amenable to a regex-based fixup later
<maxb> requeued anjuta, let's see what happens
<vila> jam: http://doc.bazaar.canonical.com/devnotes/configuration.html
<jam> vila: Bazaar itself defines all its constants as bzr.option_name or bzr.topic.option_name, in short, the bzr. prefix is reserved for bzr core/bzrlib itself,
<jam> quoted from that file
<vila> jam: well, if nobody tries the stack-based design, it will never be deployed, I expect special cases to appear while migrating the existing options
<maxb> hmm, UDD concurrency is currently set to 1 ?
<jam> i do see your mention of dropping bzrlib.plugins
<vila> jam: meh, where ?
<jam> vila: "package based"
<jam> where it says that "Bzr." should be used for core config, and plugins should just use "<plugin>."
<vila> jam: read a bit more
<vila> 'topic based' and then 'topic based name seems to provide the best compromise'
<vila> patches welcome to clarify the wording
<jam> might I suggest the PEP style of writing, which puts "possible alternatives" into a different section so that it is obvious they aren't the recommendation ?
<jam> vila: "collisions are detected at registration time..." I don't see a registration time
<jam> (grepping for the word "register" in config.py)
<jam> I believe I remember reviewing some code about that in the past, though
<jam> I guess maybe "config.Option" which *I* find confusing vs option.Option
<jam> not only that "option.Option" is referenced later in the file as "commands.Option" because of a spurious import coincidence
<vila> meh, are we talking about your proposal or do you want to file bugs ?
 * maxb raises jubany max_threads back to 8
<vila> maxb: any idea who is setting it to 1 ?
<maxb> no
<jam> vila: I'm trying to make sure I'm understanding everything and things aren't lining up in multiple ways
<maxb> I assume it was from smoketesting the change to 2.3.4, but it seems fine
<poolie> jam, i have not requeued any packgase
<poolie> i set it back to 1
<poolie> i'm happy to have it go back up
<poolie> ideally with someone keeping an eye on it
<maxb> Now we wait and see whether any of what I've requeud fail
<vila> jam: Go has an interesting discussion about name spaces: http://goneat.org/doc/effective_go.html#package-names
<jam> maxb, poolie: Would we have a good mailing list (udd perhaps) for just posting "I made these changes on Jubany"
<jam> as an audit-log of what-and-why things have changed?
<maxb> And worry about whether this tag-fetching thing is a mistake :-/
<poolie> udd
<poolie> that's what i tried to do today, though perhaps not in enough detail
<poolie> (like not mentioning the max threads thing)
<jelmer> vila: is it possible to see which version was installed on babune in the new -proposed jobs?
<poolie> i think probably user-type discussion should be on ubuntu-devel and ops/development on u-d-d
<poolie> you guys should all join u-d if for some reason you have not already
<vila> jelmer: it's displayed at the *end* of the job console
<jam> poolie: I have not, but I'm a bit concerned it will just be a bunch of emails that I don't read
<vila> jelmer: http://babune.ladeuil.net:24842/view/SRUs/job/selftest-chroot-natty-proposed/lastSuccessfulBuild/console and scroll down
<jam> I get plenty of those from being in ~launchpad as it is
<maxb> So far we have numerous successes, but one failure with "missing text keys"
<jelmer> vila: but that output happened *before* the tests ran?
<poolie> jam, it's not that much
<vila> jelmer: yeah, blame jenkins stderr handling, I'll change it to try to get it at the *start* of the output
<vila> jelmer: but that won't be as good as having it displayed more pro-eminently (I have some ideas but need some tests)
<jelmer> vila: it's not a big deal, I'm just surprised :)
<vila> jelmer: do was I ;-)
<vila> s/do/so/
<vila> jelmer: are you using a script to mark the sru bugs verification-done ? Or do you do that manually ?
<jelmer> vila: I'm doing it manually.
<vila> k
<Riddell> vila: should we do some more patch pilot today?
<vila> Riddell: my plan for today is to write the summary mail before leaving (I'm out next week)
<vila> Riddell: did you have a specific item to discuss ?
<Riddell> vila: no, I just haven't looked at any since we did it on tuesday so I don't know if there are more patches to pilot
<vila> ok, I haven't seen any  requiring pp (imbw)
<Riddell> imbw?
<vila> I May Be Wrong
<vila> I always can ;)
<maxb> Looks like 2.3.x has effectively fixed all of the BzrCheckErrors on jubany (though the queue is still draining)
<jelmer> maxb: I guess that's a relief and worrying at the same time :-/
<maxb> It does strongly suggest we should be considering making the fetch-tags behaviour optional in 2.4
<jelmer> maxb: I agree we should make it optional
<jelmer> maxb: it would be nice to actually fix the underlying problem though
<maxb> Well, sure
<maxb> Unfortunately the complexity of this underlying problem exceeds my current knowledge of bzr internals :-/
<vila> jelmer, maxb : I agree with making tag fetching optional in 2.4, 2.4.0 freeze is planned for 2011-08-04, time is running short :-/
<jelmer> ah, hmm
<jelmer> we should at least make sure we have bug reports about these issues
<spiv> maxb: you only need to understand how stacking works in the context of repositories with unconfigured fallbacks in the smart server and how that supports O(changes) fetches and a rough idea how CHK maps work :P
<jam> vila, jelmer: bug #806348 is a fairly large regression for bzr2.4 vs bzr-2.3
<ubot5> Launchpad 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] https://launchpad.net/bugs/806348
<jam> if we can't fix it, we need to back it out, disable-it-by-default
<jam> spiv: yeah, the interactions of stacking + everything else has never been much fun
<spiv> Just ban tags that are in the ancestry of tip ;)
<jam> adding that RemoteRepo acts differently than local Repo is not good
<jam> I think we should make it so that Local stacked repositories don't proxy, and see what falls out.
<vila> spiv: what's your gut feeling about being able to fix it for 2.4.0 ?
<vila> well, for 29/07 even :)
<spiv> :)
<vila> ':)' is a good gut feeling, I feel relieved :-p
<spiv> I'm hoping there's a cheap fix or at least mitigation we can do.
<spiv> It feels like the sort of thing we might be able to recover from more gracefully than just giving up with a BzrCheckError
<jam> spiv: add a config variable, default it to false?
<spiv> jam: well, that's a good fallback option
<spiv> (and also helps with the 'unrelated tags cause bloated fetches' bug/feature)
<spiv> But in principle the client knows what is missing, and knows where to find that data
<Lo-lan-do> Hi all :-)
 * Lo-lan-do is back to haunt jelmer *again*
<spiv> It could and probably should do something more helpful than "sorry, I only got 99.9% of the data I need, I'm gonna barf."
<Lo-lan-do> Same context as usual, we did a release of FusionForge, and the discussion is again coming to whether we should switch to git or not.
<spiv> (Funnily enough it already does more-or-less that when it doesn't initially receive the parent inventories needed to make a viable stacked repository...)
<Lo-lan-do> So, jelmer, do you have any light to shed on the whenabouts of "bzr push" to git repositories?  Or how to work with bzr (and plenty of local braches) when the main repository is git?
<jelmer> hi Lo-lan-do
<jelmer> Lo-lan-do: we've been making some progress on support for colocated branches and accessing colocated branches in git
<jelmer> Lo-lan-do: not so much on support for "bzr push" to git repositories, I haven't been able to spend much time on it, mainly focussing on fixing bugs
<Lo-lan-do> 'kay.  But if I have local branches in bzr, how hard/disruptive will it be to push them upstream?  Will I need horrible amounts of rebasing?
<jelmer> Lo-lan-do: that really depends on the workflow - is there going to be a gatekeeper, is everybody going to push patches directly on the mainline, or are you going to merge things into the mainline?
<Lo-lan-do> The workflow is I have several bzr branches for clients.  For the sake of this discussion, I'm their only user.
<Lo-lan-do> When one of them is stable, I rebase it onto upstream (svn currently) and push it to trunk.
<Lo-lan-do> It occurs to me that there's already some rebasing needed, so maybe my worries are not really justified.
<jelmer> Lo-lan-do: I think it would be about the same amount of rebasing as you would if you used git
<Lo-lan-do> The upstream repository is shared between all developers.
<jelmer> Lo-lan-do: would they push merges into the upstream repository when landing a branch, or rebase branches they land onto trunk?
<Lo-lan-do> No idea.  Maybe both :-)
<Lo-lan-do> Other question: can I push from a bzr branch into a git branch other than the "master" branch?
<jelmer> Lo-lan-do: not yet (that's what the bug fix work related to colocated branches is about)
<Lo-lan-do> Ah, I see.
<Lo-lan-do> jelmer: Any rough idea of when?
<jelmer> Lo-lan-do: I'm a bit hesitant to give estimates; this work had been stalled for a while and we've just resolved one of the blockers. It touches some pretty core routines though, so I'm not sure what else we'll hit.
<Lo-lan-do> No problem.
<Lo-lan-do> I guess I can live with only using master for a while anyway (we don't plan on branching again right away).
<Lo-lan-do> I haven't followed everything, but is bzr-git updated regularly in sid or do I need to track upstream?
<jelmer> Lo-lan-do: semi-regularly, I'm not sure how up to date the current version in git is
<Lo-lan-do> 'kay.  Thanks for the info :-)
<lxsameer> my connection lost in middle of a bzr branch process how can i resume that?
<jelmer> lxsameer: if you branched into a repository then you can just remove the branch and restart; I think it'll continue where it left off
<lxsameer> jelmer: what do you mean? removing the directory cause all the downloaded data to be remove
#bzr 2011-07-23
<RenatoSilva> jelmer: hi
<jelmer> RenatoSilva: hi
<RenatoSilva> jelmer: hi. I've merge from trunk, tests passed ok. Just the diff a bit weird
<jelmer> RenatoSilva: sorry, I think I miss context?
<RenatoSilva> jelmer: sorry, https://code.launchpad.net/~renatosilva/bzr-email/mail-customization/+merge/68932
<jelmer> RenatoSilva: ah, thanks
<jelmer> I'll have a look tomorrow
<RenatoSilva> ok thanks
<aminpy> http://dpaste.com/575029/plain/ <- can anybody help me?
<aminpy> how can I run this command -> bzr branch lp:openerp <- with ssh?
<maxb> lp: Will automatically translate to ssh once you've set your launchpad username with "bzr lp-login"
<aminpy> maxb, how can I set my launchpad username with ...?
<aminpy> sorry I'm new in bzr
<maxb> Run 'bzr help lp-login'
<aminpy> maxb, I dont find anything, can you tell me what command should I use?
<aminpy> http://dpaste.com/575126/plain/ <- can anybody help me?
<spiv> aminpy: upgrade your bzr; there's a problem with an HTTP proxy, but upgrading bzr will avoid the issue.
<spiv> (As a tangent, you probably don't need to be running bzr as root)
<aminpy> spiv, how can I upgrade bzr in debian?
<aminpy> spiv, my bzr version -> 2.1.2
<vila> maxb: I just realized that 2.3.4 included the fix for NoFinalPath import failures
<vila> maxb: All the involved packages had a pending lock (almost all of them in their updates/.../oneiric branch) which I broke
<vila> maxb: I've requeued them all and they are processing right now
<vila> maxb: gnome-orca succeeded \o/
<vila> maxb: paramiko succeeded \o/
<vila> maxb: some failed with AppendRev..Violation, so it's a net progress anyway ;)
<vila> maxb: gwibber succeeded \o/
<vila> I can enjoy my vacations now :)
<AuroraBorealis> so, anyone know how to get bzr explorer working on lion?
<AuroraBorealis> or...bzr in general
<AuroraBorealis> https://bugs.launchpad.net/bzr-mac-installers/+bug/731391?comments=all fixes it if anyone is interested!
<ubot5> Ubuntu bug 731391 in Bazaar Mac Installers "bzr: ERROR: Couldn't import bzrlib and dependencies. Please check the directory containing bzrlib is on your PYTHONPATH. Traceback (most recent call last): File "/usr/local/bin/bzr", line 102, in <module> import bzrlib ImportError: No module named bzrlib" [Undecided,Incomplete]
<jelmer> hi AuroraBorealis
<AuroraBorealis> hello.
<jelmer> AuroraBorealis: have you tried the fix suggested by griker?
<AuroraBorealis> i did.
<AuroraBorealis> and it worked.
<jelmer> AuroraBorealis: any chance you can mention that on the bug report?
<jelmer> it seems like at least two people confirmed the issue and the fix, so I'll set the status back to confirmed
<AuroraBorealis> yeah i'll do that
<jelmer> I don't have a Mac OS X machine to verify, but hopefully this is enough info for d0xx to fix it.
<AuroraBorealis> still not sure what the issue is (that the default python version is different then 2.6?)
<AuroraBorealis> and just commented.
<jelmer> AuroraBorealis: it seems that bzrlib is installed to the python2.6 directory, while bzr uses the default python
<jelmer> and the default python has changed to python2.7 in lion
<AuroraBorealis> ah
<jimis> I have a huge diff that I want to commit little by little. Do you know of some tool to interactively pick the changes I want?
<jelmer> jimis: you can shelve the changes you don't want and commit bits at a time ("bzr shelve") ?
<jimis> jelmer: you mean apply the huge diff, shelve, and then unshelve selectively?
<jimis> how would I do the last part?
<jelmer> jimis: I'm not sure if you can selectively unshelve, I usually selectively shelve
<jimis> jelmer: in that case can I commit only the shelved bits, ignoring working dir state?
<jelmer> jimis: I don't think there is anything to do that at the moment
<jimis> ok
<jimis> I am now looking for some generic tool to cherry-pick changes from a diff
<jimis> VCS-independant
<LeoNerd> I wrote a tool for that at my first job.. A filter for a patch that outputs another patch. say yes/no per chunk.. It did some rewriting of line numbers too, to account for absent chunks
<LeoNerd> Sadly I didn't get to keep it though
<jelmer> jimis: perhaps there's something in diffutils
<maxb> I find (insert your favourite editor here) and recountdiff do just fine
<jimis> Is there a problem with launchpad vcs-imports?
<jimis> lp:gcc hasn't been updated for some time now
<jelmer> jimis: yes, it's being worked on
<jelmer> hi mgz
<vila> jimis: emacs diff-mode is the perfect match for the 'cherry-pick changes from a diff and VCS-independent'
<vila> jimis: you can split hunks, kill one, apply/revert one, you name it, with or without saving intermediate states into files
<jelmer> hey vila
<jelmer> vila: shouldn't you be on holiday ? ;-)
<vila> jelmer: ;) Don't tell my girlfriend she thinks I'm ....
<jelmer> :)
<vila> jelmer: I am, I just had a look on the NoFinalPath failures as a last juicy fruit ;)
<vila> And on that: bye all !
<jelmer> vila: Have a nice vacation!
<luks> jelmer: ping
<jelmer> luks: hi
<jelmer> sorry, didn't realize you were still in here too
<luks> jelmer: I'll merge the patch and move the project to ~bzr
<jelmer> luks: thanks
<luks> so that you guys have full access to it
<maxb> jelmer: Hi, could you push your latest bzr-fastimport upload to alioth?
<jelmer> maxb: done
<maxb> Thanks
 * maxb is reviewing recent Debian ACCEPTED emails for ~bzr ppa updates
<jelmer> aha
<lifeless> jelmer: I have to run, but for the lp patch, look at recipe manifests that capture the same data AFAICT
<jelmer> lifeless: thanks for the review
<jelmer> lifeless: that would be the SourceRecipeData table I think
<jelmer> (which can capture the branch and revision data)
<mgz> jelmer: I'm still mystified as to how you get the failure in the selftest-xfail-msg mp
#bzr 2011-07-24
<RenatoSilva> jelmer: hi
<jimis> emacs diff-mode is very interesting, thanks vila
<jelmer> rehi
<jimis> jelmer: thanks for working on fixing the lp:gcc issues! Any ideas why it's broken?
<jimis> is it just the hugeness of the tree that makes life hard for bzr?
<jimis> or something deeper?
<jelmer> jimis: it's the number of tags (and the fact that they are not on mainline revisions) in particular
<jimis> interesting :-)
<jimis> how many tags are we talking about?
<jelmer> jimis: I think it was a couple of thousand
<jimis> :-o
<jimis> doing even basic work with this tree had given me trouble in the past
<jimis> but all is well now with 2.4, at least for me
<jimis> ofcourse it could be faster, but at least it's fast enough to do some basic work :-)
<jelmer> yeah, jam did a lot of work to improve the performance on trees that are gcc-sized
<Anteru> Hi
<jelmer> hi Anteru
<Anteru> I'm trying to write a plugin, and I'm somehow can't get started.
<Anteru> I have created a plugins/binstore folder in my home
<Anteru> and put an __init__.py as wel as binstore.py in there
<Anteru> Which are completely bare-bones
<Anteru> bzr plugins -v tells me
<Anteru> No module named binstore
<Anteru> Unable to load plugin u'binstore' from u'C:/Users/Anteru/AppData/Roaming/bazaar/
<Anteru> 2.0/plugins'
<Anteru> err, that last line-break shouldn't be there
<Anteru> __init__.py is: http://pastie.org/2263571
<jelmer> Anteru: what's in the __init__.py file?
<jelmer> ah
<Anteru> binstore.py: http://pastie.org/2263572
<jelmer> Anteru: that looks like incorrect python syntax
<jelmer> what does "python __init__.py" say?
<Anteru> I have only python 3.2 installed, let me try anyway ...
<Anteru> ah I have 2.6 too
<jelmer> (the import on line 6 of __init__.py seems incorrectly formatted to me)
<jelmer> .bzr.log should also have some details
<Anteru> indeed
<Anteru> yeah, the import was wrong, now python __init__.py complains about missing bzrlib
<Anteru> Hm, bzr plugins -v doesn't work though
<jelmer> Anteru: any details in ~/.bzr.log ?
<jelmer> how does bzr plugins blow up?
<Anteru> just the error message
<Anteru> bzr log: http://pastie.org/2263596
<Anteru> encoding issue?
<Anteru> I don't understand what exactly is missing? binstore is a symlink under /plugins/, but that should be transparent for bzr ...
<Anteru> I'm on Win7/bzr 2.3.3 fwiw
<jelmer> it looks like you have invalid information in your version_info
<Anteru> hm?
<jelmer> Anteru: can you comment out version_info and try again?
<Anteru> new __init__.py: http://pastie.org/2263612 bzr.log: http://pastie.org/2263615
<Anteru> I also tried to replace binstore with blahstore to check if the from bzrlib.plugins. ... line is the problem, but it fails earlier
<jelmer> Anteru: have you tried with an empty __init__.py ?
<Anteru> hm, doesn't work either -- something is fishy here
<Anteru> Do I have to do anything besides putting a folder into my plugins directory?
<jelmer> putting it into the plugins directory should be sufficient
<jelmer> that said, I don't really have a lot of experience doing development on windows
<jelmer> are you using the python-based installer or the standalone installer?
<Anteru> I used the normal standalone installer
<Anteru> Everything "stock" as much as possible
<jelmer> Anteru: I think you might have to use the python based installer if you want to add plugins
<jelmer> IMBW
<Anteru> hm putting keywords there works
<Anteru> ah
<jelmer> ah?
<Anteru> hm
<Anteru> Well, I did a branch of lp:bzr-keywords to plugins and that works
<Anteru> after removing setup.py from there, it works still
<Anteru> if I copy and paste the __init__.py, I get the same error
<Anteru> So it's not my bazaar installation, but something specific to my binstore plugin
<Anteru> Ah
<Anteru> It does not work if binstore is a symlink
<Anteru> I.e. if I symlink something from elsewhere to plugins, bazaar can't find it
<Anteru> Uah, that's weird at best.
<Anteru> (me wonder what the heck bzr does that it breaks on symlinks on Windows)
<jelmer> Anteru: what do you mean by symlinks here?
<jelmer> Anteru: NTFS symbolic links?
<Anteru> the folder plugins/binstore was a symlink to V:/Dev/Current/Testing/binstore
<Anteru> Yes, NTFS symlink
<jelmer> Anteru: bzr just uses python's import
<jelmer> so presumably that has troubles with symlinks
<Anteru> yes but it somehow sees the folder "binstore" but fails afterwards.
<Anteru> Oh well, first hour of plugin development spent  :)
<Anteru> Thanks!
<jelmer> Anteru: yeah, that's annoying
<jelmer> Anteru: are you working on a big file store of some sort?
<Anteru> Yeah, the one I wrote on the mailing list
<Anteru> I'll be back in ~ 1.5 hours, gotta go
<jimis> how can I see a what changes a "bzr merge" will do, but without merging yet?
<jimis> or how can I "bzr diff" current branch with another branch?
<jelmer> jimis: bzr diff should work
<jimis> jelmer, I was expecting the following to diff "mytrunk" to current branch:
<jimis> bzr diff --old=mytrunk
<jimis> it outputs nothing
<jelmer> jimis: bzr diff -rbranch:mytrunk
<jelmer> though --old should do the same thing
<jelmer> it seems odd that mytrunk would be a subdirectory of the current branch though
<jimis> thanks jelmer
<jimis> -rbranch:mytrunk immediately reported that there is no such branch
<jimis> --old=mytrunk just returned silently, with 0 return value
<jimis> jelmer: Indeed mytrunk is a subdirectory of parent dir, but I thought it would find it :-)
<jimis> let's say I want to merge 5 commits from another branch, but I want to commit them separately using the same commit messages used in that branch.
<jimis> How can I do that?
<jelmer> jimis: bzr merge will preserve the commit messages
<jimis> jelmer: thanks, I understand now. The message that "bzr ci" requests after that, does not erase the separate messages
<jelmer> (if you merge and commit, it will show in e.g. "bzr qlog" or "bzr log -n0")
<Anteru> re
<Anteru> jelmer: Yes, I want to do this "store large files on the server only" thing
<Anteru> bye
<jimis> how can I commit selectively some of the changes I've made?
<jelmer> jimis: "bzr shelve" the changes you don't want
<jimis> jelmer: then the question is how to shelve selectively? :-p
<jimis> for example I have one file, changed in two places that I want to commit separately
<jelmer> jimis: shelve is interactive - it'l prompt you for what chunks to shelve
<jimis> hah! I just read the wishlist: http://wiki.bazaar.canonical.com/BzrWishlist
<jimis> bzr commit --interactive should run shelf's hunk-selection script.
<jimis> jelmer: that will do thanks
<jimis> should I submit some bug report? I'd be very interested in interactive commit feature
<jelmer> jimis: please file a bug about it
<jimis> will do, thanks
<jimis> was already there: https://bugs.launchpad.net/bzr/+bug/307285
<ubot5> Ubuntu bug 307285 in Bazaar "Support interactive commit" [Medium,Confirmed]
<jelmer> jimis: in that case, please use the "This affects me too" thing
<jimis> jelmer: I did, and posted a comment too :-p
<Anteru> hm, the content filter gets a chunk, where's the documentaton of what a chunk is?
<Anteru> can't find it in the bzrlib documentation
<jelmer> Anteru: it gets chunks
<jelmer> Anteru: which are basically strings which contain a part of the file. the size of each chunk varies (it depends on the way the file was stored)
<Anteru> oh ok, but its for one file?
<jelmer> in other words, "".join(chunks) will get you the full file content as a string
<Anteru> hm, that doesn't sound too good, as the return value is chunks, too. Which means I must have the whole file in memory once there if I want to have it in a single file.
<Anteru> Ok, I'll try using two files first then
<jelmer> Anteru: that's true - this is a limitation of the current API
<Anteru> i.e. foo.meta stores the hash, and when retrieved, it produces a foo file with the actual contents
<jelmer> and one of the harder challenges in adding support in bzr core for large files
<Anteru> which will require manually touching of foo.meta if you update foo.bin
<jelmer> you can have a post-commit hook of some sort that does that automatically
<jelmer> uhm, sorry, a pre-commit hook
<Anteru> and a pre-commit too which checks
<Anteru> yeah I wonder if that's not easier than a content filter?
<Anteru> i.e. have a pre-commit/post-commit hook which checks the file stamps and be done with it?
<jelmer> you'll need the content filter to create the file on checkout
<Anteru> pre-commit post-update
<jelmer> I'm not sure if there is a post-tree-update hook at the moment
<jelmer> other than the content filter stuff
<jelmer> but I wouldn't be surprised if there was one
<Anteru> hmpf
<Anteru> implementation wise, it seems pretty simple, but getting into actually into bzr is going to be fun :)
<RenatoSilva> how to run selftest in Ubuntu? it complains module testtools is missing
<mgz> aptitude install python-testtools
<RenatoSilva> mgz: ok, but shouldn't it come with bzr or bzrtools?
<RenatoSilva> mgz: it'll be a standalone installation now, related as orphaned package
<mgz> it's like a build-depend, as you don't actually need it to *use* bazaar, just to run the test suite, it's not in the dependancy list
<RenatoSilva> ok
<RenatoSilva> thanks
<jelmer> mgz: hi
<mgz> hey jelmer!
<jelmer> mgz: did you see my bug report about some of the other failures I was seeing?
<mgz> I've just commented on one that looked like it was about jml's latest testtools changes
<mgz> your first failure from the mp still mystifies me, it might help with that if you can set BZR_TEST_PDB and go up untill you get to the KnownFailure/_ExpectedFailure instance and have a look at it
<jelmer> ah, I must've missed that
<jelmer> mgz: the MP is about some different issues
<mgz> it was just this second, you may have not got the mail yet
<jelmer> mgz: still haven't seen it
 * jelmer looks at ze web
<whitelynx> is there any version of bzr-svn available that works with bzr 2.3.x? the newest i've been able to find only works with 2.2.x
<jelmer> whitelynx: only snapshots
<whitelynx> aah ok... could you point me at the bzr branch that has the latest? the one used by the bzr-svn-bzr package in AUR seems older than 1.0.4
<jelmer> lp:bzr-svn
<whitelynx> cool, thanks
<whitelynx> I get 'bzr: ERROR: Unsupported protocol for url "lp:bzr-svn"' when i try branching that... does that require an LP ID to branch?
<lifeless> no
<lifeless> but it does need the launchpad protocol
<lifeless> s/protocol/plugin/
<whitelynx> aah, ok... so --no-plugins is the issue
<whitelynx> sweet, it works now!
<whitelynx> jelmer, lifeless: thanks for the help :)
<spiv> Good morning folks.
#bzr 2012-07-16
<mgz> morning
<jelmer> sup mgz
<rafaelmartins> hi all. supposing that I have a repo 'X', published at lp, and a clone 'Y' of it, hosted on my own infra. I add a tag 'foo' to Y, and want to push some changes I did at 'Y' to 'X', is it possible to leave the 'foo' tag local to 'Y', without get it propagated to 'X'?
<jelmer> rafaelmartins: not really, at least not with the bzr cli
<rafaelmartins> jelmer, too bad. there's another way though?
<jelmer> rafaelmartins: you could probably script something using the Python API
<rafaelmartins> hmm
<rafaelmartins> thanks for the info, jelmer
<ccxCZ> how do I check in a script if there are any changes in a working tree?
<ccxCZ> something better than [[ $(bzr stat -VS | wc -l) -gt 1 ]] possibly?
<jelmer> ccxCZ: IIRC the exit code of 'bzr status' also changes if there are modifications in the working tree
<ccxCZ> doesn't seem so
<trkv> Hi all, can anoyone help me with bzr api, please?
<jelmer> ccxCZ: I guess checking the output of 'bzr status' or 'bzr diff' is the safest bet in that case
<ccxCZ> yeah, I went for [[ -n "$( bzr stat -SV)" ]] in the end
<jelmer> ccxCZ: another option is running
<jelmer> ccxCZ:  bzr version-info --check-clean | grep "clean: True"
<jelmer> hi trkv
<trkv> hi
<jelmer> trkv: what's your question? perhaps somebody here can help
<trkv> I want to write a plugin storing some info in the branch metadata during the commit (i.e. store one string with each commit)
<trkv> however looking to the info about hooks I see that I shouldn't modify future_tree or tree_delta during the pre_commit hook
<trkv> and I'm unsure how to modify the commit at the post_commit hook
<jelmer> trkv: you can't modify the tree during pre_commit, but you can modify it during start_commit
<jelmer> trkv: the branch and commit metadata is also not a part of the tree
<trkv> hm, so what should I do at start_commit stage? I thought there should be available modifiable Commit object at some moment :)
<jelmer> you can modify the tree in the start_commit stage I think
<trkv> jelmer: I've just looked at MutableTree and still have no idea how to access current commit from it :(
<jelmer> trkv: What do you mean with the current commit?
<trkv> the commit I'm going to perform
<jelmer> trkv: there is no information about the current commit in start_commit
<jelmer> only during pre_commit
<trkv> and during pre_commit I can't modify info... deadend >.<
<jelmer> trkv: during pre_commit you can't modify the tree, but you can modify the commit or branch metadata
<Noldorin> jelmer: hey there. what does bzr-bookmarks do, may i ask?
<Noldorin> i didn't find any real description online...
<jelmer> Noldorin: I think it provides shortcuts for URLs
<Noldorin> jelmer: oh it said you were the co-ordinator on lp :)
<jelmer> hello nz
<jelmer> Noldorin: huh, where does it say that?
<Noldorin> jelmer: sorry, i mean "top contributor" https://launchpad.net/bzr-bookmarks
<jelmer> Noldorin: ah, that's probably just because I triaged bugs
<Noldorin> i did not check, just assumed you were involved heh
<Noldorin> ah okay
<Noldorin> fair enough
<trkv> jelmer: It seems that when i modify local.repository.get_revision(future_revid).properties in pre_commit hook, nothing changes actually. Is it real to save my changes at that moment?
<jelmer> trkv: right, you need to change the properties of the Commit object
<jelmer> trkv: You shouldn't be able to make that call btw, because the revision doesn't exist yet
<trkv> oh, that was the first question I asked)
<trkv> how to obtain Commit object at the pre_commit
<jelmer> trkv: it should be one of the arguments to the hook
<trkv> yep, but it isn't
<trkv> (local, master, old_revno, old_revid, future_revno, future_revid, tree_delta, future_tree) are all the arguments
<trkv> and tree_delta, future_tree shouldn't be modified
<jelmer> ah, that actually happens after the commit is made but before the branch is updated
<jelmer> trkv: you want the Commit pre_commit hook, not the Branch pre_commit hook
<jelmer> hmm, except there is no such thing
<jelmer> trkv: Sorry, I don't remember where this is exactly and I don't have time to dig deeper at the moment
<trkv> ok, may be I can return and ask you tomorrow (or some day later if you have no time tomorrow)?)
<jelmer> trkv: you might want to ask on the mailing list, where your question will reach a wider audience
<jelmer> though I should also be around tomorrow during European working hours
<trkv> ok, it's bazaar@l.c.o, yep?
<jelmer> trkv: yep
<trkv> thanks, I'll won't bother you anymore)
<trkv> good night
#bzr 2012-07-17
<mgz> morning!
<jelmer> hey mgz
<mgz> bug 1025030
<ubot5> Launchpad bug 1025030 in Bazaar "[pipeline] bzr switch PIPENAME crashes with bzr: ERROR: exceptions.AttributeError: 'module' object has no attribute 'BzrBranch5'" [Undecided,New] https://launchpad.net/bugs/1025030
<mgz> looks like something in 2.6 borked loom?
<jelmer> mgz: https://code.launchpad.net/~jelmer/bzr-loom/branch5-move/+merge/115302
<mgz> jelmer: approved and etc
<AfC> I pushed a bzr branch to github, and saw my beautifully tracked renames get turned into removes and adds. Kittens are crying this night.
<LeoNerd> YYyyup
<LeoNerd> The Linux kernel source code rarely has to rename files, so Linus didn't consider renames a core feature in git
<LeoNerd> That's a sensible enough choice given that use-case. It just annoys me when people try to reuse git for all sorts of other things that do want to track renames
<AfC> The weird thing is that GitHub actually displays it as a "rename"
<AfC> anyway.
<jelmer> AfC: git infers renames at run-time, it doesn't store them
<AfC> jelmer: yeah
<AfC> [I know]
<AfC> like I said, think of the poor kittens
<AfC> jelmer: if I've gone and used dpush (which rebases, I now see), should I take the now git-v1: revisions as the "real" ones and accept that as a universal replacement for my existing branches?
<AfC> jelmer: [I didn't quite realize that sharing my code that way would imply having to rebase all my branches. I understand why it would be necessary, of course. Not sure what workflow makes sense, though]
<jelmer> AfC: I wouldn't do this with any existing branches, it will horribly break your existing users
<AfC> jelmer: ok
<AfC> jelmer: [just me at this point on this particular repo]
<AfC> jelmer: but no, I wouldn't want to do it for a major project! :(
<jelmer> AfC: you should be able to get back to the old tip by using 'bzr heads --dead-only'
<AfC> jelmer: no, it's cool, I have lots of versions of this branch around
<AfC> jelmer: I'm experimenting
<jelmer> AfC: ah, great
<AfC> but if I'm going to offer to share with people via github, that really locks me in to the rebase (and accepting their / those? revisions as authoritative
<AfC> is that correct?
<jelmer> AfC: yes
<AfC> ok
<jelmer> dpush is a useful tool, but mostly if you occasionally contribute a fix to a git-based project
 * AfC hms, afraid of the implications he hasn't seen yet
<jelmer> it's not really useful for working in bzr yourself and allowing others to work in git; for that, you really want roundtripping to work
<AfC> jelmer: I remember years ago we talked of being able to preserve metadata when pushing to [Subversion] it then was
<AfC> jelmer: round tripping ... as in keeping git and bzr locally, shuttling patches locally, and using git to shuttle from local to remote?
<AfC> or as in "use fast-export"
<jelmer> AfC: fast-export doesn't roundtrip
<AfC> oh
<jelmer> AfC: it discards revision-ids, renames, revision properties, etc
<AfC> oh
 * AfC has been blissfully isolated in bzr only land for the last 5 years, but I'm trying to be more ... accomodating.
<AfC> so {shrug} learning curve
<AfC> jelmer: [am I missing something? Do we *have* round trip capability?]
<jelmer> AfC: no, there is no roundtrip capability
<jelmer> AfC: enabling git users to contribute to a codebase in bzr doesn't work particularly well at the moment
<jelmer> AfC: the other way around works better; and git-bzr presumably also works reasonably well for git users who want to contribute to bzr
<AfC> jelmer: well the goal here is nothing original; would potentially like to host in github; no preference on my part [I host my own branches] but this particular community is github centric and I might be nice to make it easier for them.
<AfC> I could just keep using bzr [and self-hosted branches] only, but...
<jelmer> AfC: personally, if the community was github centric I would use git for this
<jelmer> AfC: it would be nice if things interoperated better, but unfortunately that's not the case at the moment
<AfC> jelmer: hey, it's awesome what we have now. bzr-git is fantastic.
<trkv> jelmer: hi, I've tried to implement thing we've spoken about last night. Could you give it a quick look and check if I've caught the idea how it's should be done? https://code.launchpad.net/~torkvemada/bzr/commit_hooks/+merge/115348
<dash> I'm getting "Tree transform is malformed" errors from 'bzr shelve'.
<dash> looks like this: http://dpaste.com/771792/
<dash> is this a known bug? anything i should do to work around it? :)
<mgrandi> missing parent?
<mgrandi> are you..missing the parent? =P
<dash> good question. how would I check? :)
<mgrandi> is the branch stacked or part of a shared repo?
<dash> nope, it's standalone
<dash> deryck: hmm wow, another bzr in birmingham? :)
<deryck> dash, near Auburn actually :)
<mgrandi> im not that familiar with teh bzr internals so im only guessing
<mgz> ga, why did people in the US have to be so unimaginative with place naming
<dash> deryck: hah ok :) i haven't been down there since shortly after I graduated...
<dash> mgz: americans came from england and brought their place names with them!
<dash> mgz: also Birmingham was founded as a steel town. so naming after an English steel town made sense. :)
<deryck> mgz, it's also not as if dash or I did the naming ;)
<mgz> dash: the likely cause is you're shelving the rename/deletion of a directory with an ignored file in it
<dash> mgz: hah! ok
<mgz> or something similarly finikity
<dash> mgz: I am most likely doing that.
<mgz> you should be able to just not do that.
<dash> yep
<mgz> dash: feel free to +affectsmetoo on bug 611739 if that was the issue
<ubot5> Launchpad bug 611739 in Bazaar "shelve problem on shelving directory with ignored file inside" [Medium,Confirmed] https://launchpad.net/bugs/611739
<dash> mgz: ah, thanks.
<lduros> is there a gratis place like github for Bazaar projects?
<mgrandi> launchpad, or github using bzr-git
<nessita> hello everyone! I was wondering if anyone would have a hint about how to "fix" a branch that is crashing on bzr st. Full traceback is: https://pastebin.canonical.com/70279/
<nessita> I'm running bzr   Installed: 2.5.1-0ubuntu2
<mgrandi> i dont have access to that pastebin? o.o
<mgrandi> paste it to http://bpaste.net/
<nessita> mgrandi: http://bpaste.net/show/wZE5C8kTsVdfug6caW0l/
<mgrandi> what command are you running on it?
<jf_> hi, I need help: I need to merge an already merged branch, because I mad some bad choices the first time.
<mgrandi> merge it into waht
<jf_> let me explain: in my branch b1 I did: bzr merge b2, I delete some good codes, commit, push, code,  commit, code commit, push
<nessita> mgrandi: bzr st
<jf_> a know I would like to resurect the good code
<jf_> and now*
<mgrandi> jf_: can't you just uncommit the commit that was the merge?
<mgrandi> and nessita yeah that shouldn't happen, some of the other more experienced developers should help you, as i cant figure out whats going on just in that stack trace
<jf_> mgrandi, why not I'm open ! but how ?
<mgrandi> if the merge was the last commit you made to the branch, you should just be able to do 'bzr uncommit
<jf_> the merge wasn't the last commit
<jf_> after my mistake I commited some good codes I don't want to loose
<mgrandi> hmm, this is more compliated now
<jf_> mgrandi, yes that's why I'm here !
<mgrandi> you might have to make a diff of the revisions that you want to keep
<mgrandi> and then uncommit the merge, and then reapply the diffs
<mgrandi> im not sure if you can shelve already commited changes
<jf_> palying with "bzr diff" and "patch" ?
<jf_> and how to uncommit the merge ?
<mgrandi> http://doc.bazaar.canonical.com/beta/en/user-guide/adv_merging.html#reverse-cherrypicking
<mgrandi> actually that might work
<mgrandi> (make a backup of your branch before you try any of these)
<jf_> ok thanks !
<mgrandi> i THINK this will put your branch back at like, revision 9 (in that example)
<mgrandi> but leave the stuff that is about to be commited into revision 10
<mgrandi> so you do that twice and then uncommit the merge i beleive
<mgrandi> also see http://doc.bazaar.canonical.com/beta/en/user-guide/undoing_mistakes.html
<mgrandi> i have to go eat now, brb
<jf_> thanks for your help
<Noldorin> http://pastie.org/4274394 -- anyone know what's up here??
<Noldorin> weird error
<fullermd> What's weird about it?
<Noldorin> fullermd: i have no prob pulling from lp normally :P
<fullermd> Well, it's all at the login level, so...
<Noldorin> why does it even need to login?
<Noldorin> for a simple co
<fullermd> 'cuz nobody's implemented anonymous ssh, I presume.
<Noldorin> oh
<Noldorin> heh
<mwhudson> actually i have, but it was a venomous hack and i didn't propose it for merging :-)
<jelmer> hah, there is an adjective I hadn't seen used in combination with "hack" before
<fullermd> Sounds like the sort you'd normally apply when talking about a person.  Behind their back, I'd hope...
#bzr 2012-07-18
<Noldorin> fullermd: in any caseâ¦ i have my ssh keys set up now, and it's still complaining :/
<Noldorin> this guy has the same issue:
<Noldorin> https://answers.launchpad.net/bzr/+question/190008
<Noldorin> jelmer: any thoughts?
<Noldorin> heeeeelp
<Noldorin> fullermd: ?
<fullermd> Well, if it's still complaining about ssh auth, your ssh keys aren't all setup  ;p
<Noldorin> fullermd: they clearly are
<fullermd> Try just ssh'ing in and track from there.
<Noldorin> heh
<Noldorin> fullermd: what do i ssh to?
<fullermd> I dunno.  The thing with the thing.  code maybe?
<Noldorin> fullermd: URL :P
<fullermd> bazaar.launchpad.net
<Noldorin> ok
<Noldorin> that's better. thanks
<Noldorin> fullermd: just get permission denied for some reason
<fullermd> That way you can toss some -v's into the process to see what's offered and refused and suchlike.
<Noldorin> okay
<Noldorin> fair enough
<Noldorin> fullermd: okay it's not offering my alternative ssh key for some reason :/
<bob2> == messed up ~/.ssh/config
<Noldorin> okay
<Noldorin> so i want a config file
<Noldorin> bob2: empty more like :P
<Noldorin> which is fine with id_rsa
<Noldorin> but not with my alternate i guess
<fullermd> Empty config file?  How silly.  Then you're just wasting the m4 invocation to generate it!
<bob2> what
<bob2> ssh isn't going to offer random keys that you didn't tell it about
<Noldorin> m4 huh?
<bob2> anyway
<Noldorin> bob2: i found two online posts saying all i had to do was put it in .ssh
<Noldorin> grr
<bob2> ssh -i .ssh/whocares bazaar.launchpad.net
<bob2> yeah, ignore forums
<Noldorin> evidently
<Noldorin> heh
<Noldorin> people don't know what they're talking about there
<fullermd> Yeah, you'll never get good advice on the internet.
<Noldorin> fullermd: except IRC of course :P
<Noldorin> bob2: get further now, except: http://pastie.org/4275243
<Noldorin> fullermd: does bzr require a special config or something?
<fullermd> No, bzr just calls ssh.  So if it does {,not} work with just ssh it will {,not} work with bzr.
<Noldorin> fullermd: you misunderstand. i mean the bzr servers
<Noldorin> on launchpad
<Noldorin> or in general
<Noldorin> i have Host, HostName, IDentityFile, User set in my config
<Noldorin> that should eb enough
<Noldorin> but i get "roaming not allowed"
<Noldorin> :/
<fullermd> That last paste you had had it trying the id_rsa key, and then nothing else.
<fullermd> (I think the "trying private key" line for id_dsa is what it says when a file doesn't exist...)
<Noldorin> fullermd: not true
<Noldorin> debug1: Found key in /Users/alex/.ssh/known_hosts:1
<Noldorin> fullermd: ^
<fullermd> That's the host key.
<fullermd> If I add
<fullermd> Host bazaar.launchpad.net
<fullermd> .   IdentityFile ~/.ssh/id_nonexistent
<fullermd> to my ssh config, I get
<Noldorin> hm
<fullermd> debug1: Next authentication method: publickey
<fullermd> debug1: Trying private key: /home/fullermd/.ssh/id_nonexistent
<fullermd> debug1: No more authentication methods to try.
<fullermd> Permission denied (publickey).
<Noldorin> i have
<Noldorin> Host LaunchpadBazaar
<Noldorin>         HostName bazaar.launchpad.net
<Noldorin>         IdentityFile ~/.ssh/alexreg-dev
<Noldorin>         User alexreg
<fullermd> Are you ssh'ing to LaunchpadBazaar?
<Noldorin> no to bazaar.launchpad.net
<Noldorin> hence the HostNAme
<fullermd> Well, there you go.
<fullermd> HostName determines what host ssh looks up to do the connection.
<fullermd> The host you give you ssh on the command line is matched to the Host line.
<Noldorin> http://nerderati.com/2011/03/simplify-your-life-with-an-ssh-config-file/
<Noldorin> how come that then?
<Noldorin> that has non- domain names for Host
<fullermd> He has "Host dev", and then he runs "ssh dev".
<fullermd> He doesn't run "ssh dev.example.com", and expect it to pick up that section.
<Noldorin> ok
<Noldorin> so what do i need it as for bzr to pick it up?
<fullermd> So just change your Host to bazaar.launchpad.net.
<Noldorin> k
<fullermd> (and drop the HostName.  Or not, I guess; it's redundant, but I don't think it'll hurt anything if it's present)
<Noldorin> ok
<Noldorin> fullermd: working now ta
<Noldorin> the ssh config stuff is slightly arcane
<Noldorin> but oh well
<fullermd> Eh, I never found it particularly so.  Though there are some impressive warts, like the stuff around IdentityFile.
<Noldorin> fullermd: it's poorly written. the english is obtuse and turgid, and far from practical in most cases
<Noldorin> but then, that's common to most unix man pages i've seen so far.
<Noldorin> it's rarely (if ever) to the point
<Noldorin> what can one expect, with programmers writing it though
<Noldorin> they're not hired for their literacy
<fullermd> Mmm.  I never tried reading it end to end.  I always just skimmed the list of directives to find something I wanted or get the details for one I knew.
<Noldorin> fullermd: that's fair enough. i can imagine they would be useful as a quick reference/reminder for something one already understands!
<Noldorin> just not to learn from...
<Noldorin> hmm
<Noldorin> why don't all commands appear in bzr help commands?
<lifeless> which ones are not ?
<fullermd> We use it to keep the hoi polloi out of the cool stuff.
<Noldorin> fullermd: ha!
<Noldorin> lifeless: lp-submit for example
<lifeless> its an alias
<lifeless> of lp-propose-merge
<Noldorin> oh okay
<Noldorin> my bad
<Noldorin> lifeless: is there any way to display all the commands for a givne plugin?
<lifeless> I don't think we preserve that structure, so no.
<lifeless> many plugins have good help though
<lifeless> bzr help plugins/launchpad
<lifeless> for instance
<Noldorin> fair enough
<fullermd> The info's there, since it has the tags on the end.
<Noldorin> yeah
<fullermd> Nothing in the ui to filter on 'em though.
<Noldorin> so what's the diff between bzr help launchpad and bzr help plugins/launchpad?
<fullermd> grep isn't really an answer; falls over and goes splat soon as things wrap.
<Noldorin> lifeless: also, you seem to preserve which command belongs to which plugin
<Noldorin> it seems a given command can be handled by multiple plugins though?
<Noldorin> hm
<lifeless> yes
<lifeless> possibly doable via a small patch
<lifeless> I'd show it in help plugins/XXXX
<Noldorin> indeed
<Noldorin> lifeless: or help commands [plugin] maybe?
<lifeless> nope :)
<lifeless> hmm
<lifeless> rephrase
<lifeless> you could
<lifeless> but it would be more code
<Noldorin> was "yes" to "we do preserve command-plugin mappings" or "a given command can be handled by multiple plugins" ?
<lifeless> and you'd be adding a new place for people to look to find tings
<Noldorin> lifeless: it would be more intuitive for me, perhaps :)
<lifeless> yes to both I think.
<Noldorin> i see
<lifeless> I've no objection per se to help commands plugin working
<Noldorin> so at the moment, if multiple plugins are responsible for command xyz, does help xyz merge their helps?
<lifeless> just noting that that thing itself won't be discoverable
<Noldorin> that's good.
<lifeless> depends on the way the plugins collaborate
<lifeless> they can introspect and merge
<Noldorin> thing?
<lifeless> or replace entirely.
<Noldorin> i see
<lifeless> thing -> help commands pluginname
<Noldorin> lifeless: it could be documentable in "help commands" maybeâ¦ but i see your point!
<Noldorin> like a one-line notice at the top
<Noldorin> *srug*
<Noldorin> *shrug*
<lifeless> question: how often do you notice one-liners ? :)
<lifeless> I mean, yes, you'd definitely want to point it there.
<lifeless> And like I say, I've no objection to it existing and working, but perhaps putting it in the current plugin help (bzr help pluginname which defaults to showing what is in bzr help plugins/pluginname) might be both sufficient and helpful
<Noldorin> lifeless: rarely when things behave how i want, but quite often when i'm "stuck" :)
<Noldorin> lifeless: actuall bzr help plugins/pluginname commands may make the most sense!
<Noldorin> oh yes. and what is the diff between help pluginname and help plugins/pluginname semantically?
<lifeless> help pluginname shows the first help topic from any of the help subject areas that matches the title
<lifeless> help plugins/pluginname selects plugins as the subject area.
<lifeless> For a plugin that doesn't have a command named the same as the plugin, nor a generic help text named the same, help pluginname and help plugins/pluginname will show the same thing.
<Noldorin> ah right
<Noldorin> lifeless: "commands", "topics", "plugins" being the three subject areas?
<lifeless> IIRC yes.
<lifeless> its extensible, of course.
<Noldorin> indeed
<Noldorin> as is everything in bzr ;)
<Noldorin> lifeless: help topics/foo doesn't work though hmm.
<Noldorin> commands/foo does though
<lifeless> lets see
<Noldorin> the section/term syntax is sensible, but the documentation on that is non-existent too alas
<lifeless> blame me for that
<Noldorin> heh
<lifeless> there are dev docs
<lifeless> api docs I mean
<Noldorin> indeed
<Noldorin> lifeless: so is the absence of bzr help topics/foo a slight oversight then?
<lifeless> neither
<lifeless> topics isn't a section provider
<lifeless> one sec
<Noldorin> neither :/
<Noldorin> ok
<Noldorin> sounds it like it should be though heh
<lifeless> bzrlib.help.HelpIndices
<Noldorin> ah right
<lifeless> >>> bzrlib.help.HelpIndices().search_path
<Noldorin> lifeless: so my proposal is 1) make topics and "help index", 2) document the bzr help index/foo syntax in `bzr help`
<Noldorin> you probably know better than me, but that's one way i would be happy with
<Noldorin> just to put it out there!
<lifeless> >>> bzrlib.help.HelpIndices().search_path[0].prefix
<lifeless> ''
<Noldorin> and 3) `bzr help plugins/foo commands` to list all commands exposed by a plugin
<lifeless> well index is also a command
<lifeless> from bzr-search
<Noldorin> ..
<Noldorin> lifeless: well, you have my 3 suggestions at least :)
<Noldorin> i must be off to bed now if i'm not to collapse...
<Noldorin> but i'll be around to discuss things!
<Noldorin> so yeah, you're welcome to ping me if i don't get around to it first
<Noldorin> night
<lifeless> Noldorin: I'd start with 3)
<lifeless> its the key thing you needed
<Noldorin> indeed
<lifeless> there are already links to e.g. plugins/launchpad
<lifeless> in the see-also
<Noldorin> the other two are semi-important convenience/doc features
<Noldorin> topics/foo needs to work though i think
<Noldorin> meh
<Noldorin> *drowsily wanders off*
<Noldorin> cheers for discussing though
<mgz> morning
<jelmer> hello
<ugo> hi all, I was wondering whether there's an equivalent for bzr checkout --lightweight for people who have only read access to a repo. (the goal is for them to download the tip only of the repo)
<mgz> get a tarball?
<ugo> getting a tarball is not really an option
<jelmer> ugo: lightweight checkouts should work if you have only read access
<ugo> jelmer: so this is not linking against the branch?
<mgz> they're simply as bad as getting a full branch unless both server and client (?) are on 2.5
<jelmer> ugo: it does link to the branch, why is that a problem?
<mgz> well, will error if they try to commit I guess.
<ugo> jelmer I thought it would fail if you don't have write access as it linked it
<ugo> mgz ok
<ugo> mgz what do you mean that there as bad as full branch? The lightweight option would pull only the tip, not the whole revisions, no? (anyway clients and servers should be 2.5 in my case)
<ugo> anyway, if it's working without write access, it's all I needed to know. Thanks a lot for your lightning fast help :)
<mgz> ugo: because this isn't rsync, you're assuming bzr just copies files, but that's not the case
<ugo> mgz a lightweight checkout of my tree takes 2min instead of 20 for full branching on my computer
<mgz> it accesses the repository, and over http that means to get just the latest files you'll end up downloading a large chunk (several times, if the repo doesn't fit in the 50MB cache) of all the data to get the latest bit of the history all the files
<mgz> with local disk access it's sensible.
<ugo> mgz the repo is on launchpad
<mgz> and with 2.5 some issues where it was assuming no one sane would be trying to do this remotely have been fixed, so it's less pathalogical
<ugo> mgz ok
<mgz> you're probably using bzr+ssh though, so not having the same experience as someone with read-only access over http
<ugo> ho ok
<ugo> yes using bzr+ssh
<ugo> Anyway, the guy who keeps pestering about bzr because branching the full tree is "stupid" will see that he's downloading tip only so that should be enough to make him happy ;)
<mgz> yeah, worth pointing out he can do that (though bug him about using 2.5 as well)
<ugo> will do
<ugo> thanks
<nessita> hello everyone! I was wondering if anyone would have a hint about how to "fix" a branch that is crashing on bzr st. Full traceback is: https://pastebin.canonical.com/70279/, I'm running bzr   Installed: 2.5.1-0ubuntu2
<jelmer> hi nessita
<nessita> hi jelmer
<nessita> jelmer: I'm not sure what went wrong with this branch, I was using pipelines in it, and when I run bzr pump --from-submit, the command finished with no errors, but next bzr st crashed
<jelmer> nessita: any chance you can repost that on pastebin.ubuntu.com, if it doesn't contain anything private ?
<nessita> sure
<jelmer> unfortunately 2 factor auth seems to be failing here ("No matching endpoint found..")
<mgz> it's a borked dirstate
<nessita> jelmer: http://pastebin.ubuntu.com/1098196/
<mgz> nessita: run `bzr repair-workingtree`
<mgz> you'll lose any pending file additions +x bit changes but otherwise it's harmless
<mgz> nessita: the entry in .bzr.log for the pump command might be interesting if that's what caused the issue (generally it's the filesystem screwing up due to poweroff, but this might be a pipeline bug)
<nessita> mgz: trying the fix and looking for the log
<mgz> `bzr version` will tell you where
<nessita> mgz: http://pastebin.ubuntu.com/1098211/. And bzr repair-workingtree says:
<nessita> bzr: ERROR: The tree does not appear to be corrupt. You probably want "bzr revert" instead. Use "--force" if you are sure you want to reset the working tree.
<nessita> shall I use (the) force?
<trkv> if someone is interested, I've written a little plugin-joke that takes user photo during commit and stores it in commit metadata: http://bit.ly/M8OvOs
<trkv> Code is available via lp:~torkvemada/+junk/bzr-cimage
<mgz> nessita: let me just check
<mgz> trkv: neat, will have a look in a sec
<trkv> mgz: it only requires my patch to hooks, that isn't merged to trunk yet
<mgz> so, bug 613066
<ubot5> Launchpad bug 613066 in Bazaar "IndexError in dirstate _process_entry when running bzr status" [High,Invalid] https://launchpad.net/bugs/613066
<trkv> lp:~torkvemada/bzr/commit_hooks â it can easy be applied to ubuntu's default 2.5.1 bzr
<mgz> is not encouraging, not normal dirstate corruption
<mgz> nessita: I'd make a copy of the dirstate file and try --force
<nessita> mgz: will do
<nessita> mgz: that seemed to work, and bzr st is not failing anymore
<nessita> mgz: thanks!
<jml> how do I set up locations.conf such that colocated branches will push to the right place by default?
<jml> e.g. For currently active $BRANCH in ~/src/$PROJECT, have bzr push go to lp:~jml/$PROJECT/$BRANCH
<jml> right now I do: bzr push ~jml/$PROJECT/`bzr nick` (manually entering the project). It's a pain, and makes things like lp-propose less useful.
<jelmer> jml: IIRC abentley added something that allows you to reference the local nick name in locations.conf
<jelmer> I'm not sure what happened to it, and whether it actually landed
<bob2> speak of the devil!
<nessita> jml: this is what I use since 2009 (perhaps is outdated?) https://pastebin.canonical.com/70335/
<jml> nessita: I think that's for branch-per-directory?
<nessita> jml: ah, yes. You want something more magical? :-)
<nessita> jml: if you find it, let me know! I would make good use of it
<jml> abentley: jelmer says you might be able to help me with setting up my locations.conf so that colocated branches are pushed to the right location
<jml> nessita: well, I use colocated branches
<nessita> jml: oh, and now I feel silly, cuz I have no idea what those are :-)
<jml> nessita: it's a not-quite-ready thing in bzr where there's one directory which contains the repo, a bunch of branches and a working tree for one active branch
<abentley> jml: We can't configure a particular colocated branch (yet), but we can configure a group of colocated branches.
<jml> abentley: how would I do that?
<bob2> group = all the colocated branches in a repo?
<abentley> jml: You use the {branchname} substitution variable.
<abentley> bob2: No, all the branches under a given location.
<jml> abentley: e.g. push_location = bzr+ssh://bazaar.launchpad.net/~jml/pkgme-service/${branchname} ?
<abentley> jml: right, but without the '$'
<jml> abentley: ta.
<abentley> jml: np
<jml> abentley: what version of bzr would I need?
<bob2> abentley, ah, thanks
<abentley> jml: let me see...
<jml> abentley: or rather, I have that and then 'bzr push' tries to push to literal ~jml/pkgme-service/{branchname} in bzr 2.5.1
<abentley> jml: So, I believe you need 2.6b1
<jml> is there a PPA w/ 2.6b1 in it? https://launchpad.net/~bzr/+archive/daily has 2.6.0~bzr6524.6234~ppa4038~precise1 â is that the same thing?
<jelmer> jml: I think that should work
<jelmer> 6524 is fairly recent
<jml> jelmer: thanks.
 * jml tries.
<jml> bzr: ERROR: Option branchname is not defined while expanding "bzr+ssh://bazaar.launchpad.net/~jml/pkgme-service-python/{branchname}".
<jml> that's different, at least.
<abentley> jml: I think it's actually b2.
<abentley> jelmer: I've looked into supporting colo branch configuration in locations.conf and it's a pain.  file:// urls in locations.conf get converted to paths, which discards branch names, of course.
<jelmer> abentley: the mixing of paths and URLs is confusing in the config :(
<jelmer> abentley: vila might have some thoughts on that
<abentley> jelmer: I think the only option is to canonicalize to file:// urls.  But this will change the way appendpath and location-based config vars work.
<abentley> jelmer: Doing colocated branches differently from the bzr-colo and pipeline plugin has some significant disadvantages, in that it needs special support and breaks old assumptions.
<abentley> jelmer: like the assumption that a file:// url converts losslessly to a path.
<jelmer> abentley: it was bzr-colo that did things differently from the core colocated branch support
<jelmer> abentley: the assumption that file URLs convert one-to-one to file paths is wrong anyway; there are several other bugs related to it in the config code
<abentley> jelmer: I was just using bzr-colo as an example of the approach.
<jelmer> abentley: I don't really see your point
<jelmer> abentley: bzr-colo needs special support from e.g. bzr-pipeline too
<abentley> jelmer: otp
<abentley> elmer: What I mean is: when colocation is implemented in the bzr-colo style, switch and switch -b just work, location.conf just works, nicknames just work, and all recent versions of bzr can access the branches.
<abentley> jelmer: ^^
<jelmer> abentley: it also duplicates control directories for each branch, doesn't support non-bzr colocated branches, or provide an API for colocated branches
<jelmer> abentley: switch and switch -b should work for the builtin colocated branches
<abentley> jelmer: Using the bzr-colo layout doesn't prevent you from having an API for colocated branches.
<jelmer> abentley: ... and it means branch URLs actually depend on format internals (/home/foo/.bzr/branches/bar)
<abentley> jelmer: Sure, switch and switch -b work *now*, and so do nicknames, but they all required special support.
<jelmer> abentley: bzr-colo style branches have a fair amount of overhead, especially when you have a nontrivial amount of branches
<jelmer> abentley: that makes them a bad idea to put into the core
<abentley> jelmer: Well, it's good to understand some of the advantages, because up to now, I couldn't understand why you'd taken that approach.
<nessita> help request involving pipes: I have a pipeline and I would like to remove a branch that already was merged into trunk, but when running bzr remove-pipeline, I get "bzr: ERROR: Branch is not connected to a pipeline". Full output, along with bzr pipes output, is here: http://pastebin.ubuntu.com/1098454/
<nessita> Any hints?
<abentley> nessita: try switching to highway-91 and running pipes again.  Does it still say it's connected to the others?
<nessita> abentley: nopes :-.
<nessita> :-/
<nessita> abentley: hum, shall I use switch or switch-pipes for that test?
<abentley> nessita: either should do.
<nessita> then no, is not connect3ed
<nessita> $ bzr pipes
<nessita> *  highway-91
<nessita> $
<abentley> nessita: So, the-devil-wears-prada.0 thinks it's linked to highway-91, but highway-91 doesn't agree.
<nessita> abentley: so, did I screw that up somehow? :-)
<abentley> nessita: Hard to say whether it's user error or a bug.  Did you try adding highway-91 to another pipeline or anything?
<abentley> nessita: Anyhow, the fix is to remove the reference to highway 91 manually.
<nessita> abentley: thanks, will do that then
<mgz> those are some amusing pipe names.
<nessita> mgz: some time ago, I've decided to use movie titles as branch names, but is not working that well... I thought it would be easier/funnier :-)
<abentley> nessita: I think this will work: bzr switch the-devil-wears-prada.0 && bzr configure --scope=branch prev_pipe=''
<nessita> abentley: running
<abentley> nessita: Oh, it'
<nessita> abentley: am I missing a plugin perhaps? bzr: ERROR: unknown command "configure"
<abentley> s "bzr config", not "bzr configure".
<nessita> ah!
<nessita> abentley: that removed highway-91 from the pipes listing, thanks!
<abentley> nessita: np.
 * maxb writes script to assess bzr PPA uptodateness; shudders in trepidation
<jelmer> maxb: ah, I take it you saw the email about hardy packages then?
<maxb> jelmer: no?
<mgz> ah... I wondered if that was in way of response as well
<maxb> I think I'm missing something
<maxb> I *sent* an email about hardy packages
<mgz> maxb: someone sent an email using launchpad to... ~bzr? asking for updated bzr in hardy ppa
<jelmer> maxb: somebody emailed ~bzr (using the contact team thing on Launchpad) about updated hardy packages in the PPA
<mgz> can forward it to you
<jelmer> maxb: yesterday, I think
<maxb> Subject: "bzr ppa advancement"? That was about lucid
<maxb> ugh, bzr.debian.org seems to have stopped responding to ssh
<jelmer> maxb: it will lock you out for a while if you fail to authenticate a couple of times
<maxb> hm... I'm not failing to authenticate, but it's probably not the first ssh key in my ssh-agent.
<maxb> I wonder if the ssh keys it tries on the way to finding the right one are counting against me
<mgrandi> try ssh -vvvv bzr.debian.org?
<mgrandi> tells you what its doing
<maxb> yeah, looks like it's a poorly written fail2ban thing
<Noldorin> hey jelmer.
<jelmer> hi Noldorin
<Noldorin> jelmer: just installed the bzr bash-completion plugin yesterday. noticed the project seems to be defunct.
<Noldorin> jelmer: maybe canonical could take it over though? i've got a fix for it already :)
<jelmer> Noldorin: there is a bash completion plugin in bzr itself
<Noldorin> jelmer: there is? :O
<Noldorin> who would ever know
<Noldorin> haha
<Noldorin> do tell
<jelmer> Noldorin: it's part of the main bzr code
<jelmer> Noldorin: bzrlib/plugins/bash_completion
<Noldorin> jelmer: okay nice. so that's the version of his that was merged in evidently...
<Noldorin> i just patched the original project
<Noldorin> oh well
<Noldorin> that should really ahve a notice :P
<jelmer> Noldorin: I'm not sure if what was merged in was the same project that you patched
<Noldorin> jelmer: yes, it is
<Noldorin> i am sure
<Noldorin> it says so in the README
<Noldorin> and it corresponds with the cut-off in activity of that project
<jelmer> okay
<Noldorin> jelmer: so it would be nice if this plugin were publicised more
<Noldorin> it's pretty esoteric at the moment
<jelmer> sure, no objection here
<Noldorin> jelmer: not sure how would be best, but yeahâ¦ :)
<Noldorin> doesn't turn up on google even. well, only the old/obsolete version does
#bzr 2012-07-19
<Noldorin> jelmer: hrmm. where is this 'contrib' dir that the README mentions?
<Noldorin> lifeless: hi
<Noldorin> no-one around? :(
<bob2> lots of people
<Noldorin> bob2: you don't know that ;)
<bob2> yes i do
<Noldorin> prove it
<Noldorin> exactly.
<bob2> what?
<Noldorin> ha
<lifeless> Noldorin: pong
<Noldorin> oh
<Noldorin> hi lifeless
<Noldorin> lifeless: read the README for the bundled bash-completion plugin earlier. i'm slightly confused
<Noldorin> especially w.r.t. http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/revision/5240
<lifeless> what about it ?
<Noldorin> i see you made that commit
<Noldorin> lifeless: readme suggest to use contrib/bash/bzr for lazy loadingâ¦but that loks like an old/obsolete version
<Noldorin> no longer rlevant
<Noldorin> certainly not included
<lifeless> I didn't write it
<lifeless> martin von gagern did the work
<lifeless> I just landed it
<lifeless> I've no memory of what was in it
<Noldorin> lifeless: oh okay
<Noldorin> lifeless: any thouhgts nontheless?
<lifeless> not really no :) sorry!
<lifeless> what are you trying to do ?
<Noldorin> lifeless: get lazy loading working for bash completion
<lifeless> ah
<lifeless> uhm
<Noldorin> lifeless: eval "`bzr bash-completion`" in my .bash_profile just does normal loading
<Noldorin> slows down my shell load time
<Noldorin> :(
<lifeless> I don't know enough about how bash completion works to offer advice sorry
<Noldorin> that's okay
<lifeless> bzrlib.commands is probably a key thing for doing lazy-inspection of stuff
<lifeless> it has a pretty solid incremental-use api
<Noldorin> yeahâ¦ i don't want to go messing with the code though
<lifeless> you might look at the deletion of the contrib script
<lifeless> it probably explains where its gone (e.g. bash upstream)
<Noldorin> lifeless: that commit is the deletion
<Noldorin> no mention there
<Noldorin> lifeless: incidentally, can bzr tell me the URL for a lp:foo branch?
<lifeless> yes, but I don't think its exposed to the command line
<Noldorin> ah
<lifeless> its an xmlrpc lookup though
<Noldorin> i see
<lifeless> not local
<Noldorin> right
<Noldorin> lifeless: the lp: prefix is built into the launchpad plugin though i guess. are there other prefixes?
<lifeless> yup
<lifeless> theres an address book one for instance
<Noldorin> oh?
<lifeless> its in a plugin
<Noldorin> what's the idea behind it?
<Noldorin> google doesn't find it
<lifeless> bzr-bookmarks
<Noldorin> oh :P
<Noldorin> you called it an address book
<Noldorin> but yeah
<Noldorin> i'm familiar with that
<Noldorin> hm
<Noldorin> lifeless: btw is von gagern still around?
<Noldorin> either here on irc or contactable via some other mes
<Noldorin> means*
<lifeless> I think so
<Noldorin> ok
<Noldorin> lifeless: btw why do colocated branches still use the ,branch= syntax? surely a simple , is good enough?
<lifeless> Noldorin: touch foo,bar; ls
<lifeless> Noldorin: or less snidely - the branch= syntax is std66 blessed
<lifeless> messing with it seems risky
<Noldorin> hah
<Noldorin> okay
<Noldorin> fair enough
<Noldorin> lifeless: are there any non-URL chars or char sequence that would work here?
<lifeless> given that branch urls are, by definition urls
<lifeless> no
<lifeless> but where is 'here' ? that you refer to.
<Noldorin> in the case of colocated branches :P
<Noldorin> lifeless: i mean a pseudo-url, but okay...
<lifeless> sure, but where in the UI ?
<lifeless> like, I'm sure we can pass separate options around and htings like that
<Noldorin> hmm?
<Noldorin> don't geto u
<lifeless> the ,branch= is the machine interface
<Noldorin> not talking about ui here
<lifeless> just like file:///home/username/branches/foo is the URL for 'foo' locally.
<Noldorin> hm
<Noldorin> lifeless: fair enough. no big deal, ceratinly for now :)
<Noldorin> night
<lifeless> night
<mgz> morning!
<abentley> jelmer: In your MP comment, are you saying that foreign branches should only implement public methods, not private ones?
<jelmer> abentley: that's how it is at the moment
<abentley> jelmer: Well, I can turn those into public methods, but I wouldn't want normal API users calling them.
<abentley> jelmer: them= _get_uncommitted, _put_uncommitted
<jelmer> abentley: why not?
<abentley> jelmer: Because those methods accept raw files, but only shelves should be stored there.
<abentley> jelmer: GitBranch implements _get_checkout_format, _get_nick, _basic_push, so ForeignBranches do seem to implement private methods from Branch.
<jelmer> abentley: _basic_push  and _get_nick are just private methods, helpers for push() and nick (the property) respectively
<jelmer> not sure about _get_checkout_format
<abentley> jelmer: Right, just as _put_uncommitted is a helper for store_uncommitted, and _get_uncommitted is a helper for get_unshelver
<mgz> I'm torn on the proposal as well
<jelmer> abentley: except _put_committed and _get_uncommitted are on the base Branch object, not on BzrBranch or anything like that
<mgz> on the one hand, it'd be useful to have shelves on the actual branches they relate to rather than on my lightweight checkout
<jelmer> abentley: _basic_push and _get_nick are called by the bzr-git branch implementation itself
<mgz> but I do hack-on-branch, then remember to switch -b later quite a lot
<abentley> jelmer: The implementation on the base Branch object raises NotImplementedError.
<abentley> jelmer: The functional implementations *are* on BzrBranch.
<jelmer> abentley: so if the thing that the interface requires is really the presence of store_uncommitted, has_stored_uncommitted and get_uncommitted
<jelmer> can't we just have that in the Branch, and the bzr-specific implementation (which uses _get_uncommitted and _store_uncommitted) in BzrBranch ?
<abentley> jelmer: I think you mean "get_unshelver", not "get_uncommitted"?
<jelmer> abentley: euhm, yes
<abentley> jelmer: You mean, provide implementations of store_uncommitted, has_stored_uncommitted and get_unshelver on Branch that raise NotImplementedError?
<abentley> jelmer: And then provide the real implementation on BzrBranch?
<jelmer> abentley: yeah
<abentley> jelmer: Forcing you to rewrite (complicated) get_unshelver instead of (simple) _get_uncommitted?
<abentley> jelmer: And meaning we need to move tests of get_unshelver/store_uncommitted/has_stored_uncommitted to the per-branch tests?
<jelmer> abentley: it doesn't make sense to store a (bzr-specific) serialization of a tree transform in a foreign branch
<jelmer> abentley: I think those tests need to be in per_branch anyway, as they can be overridden by the implementation
<jelmer> abentley: the other thing is that it simply won't be possible to support this for most of the foreign formats - svn nor git support per-branch metadata like this
<abentley> jelmer: That's a good point.  I was trying to avoid burdening you.
<abentley> jelmer: Okay, I'll do that.
<jelmer> abentley: Perhaps it would be possible to allow implementations to raise something if they don't support storing uncommitted changes?
<abentley> jelmer: Yes, that makes sense.
<abentley> jelmer: So rick_h told me that when you try to switch with uncommitted changes in git, you get "error: You have local changes to "X"; cannot switch branches.".  Is that right?
<jelmer> abentley: no, it works fine here
<jelmer> abentley: perhaps he has extra options for that enabled in his config?
<abentley> jelmer: Odd.  This StackOverflow article also says that's the behaviour: http://stackoverflow.com/questions/1304626/git-switch-branch-and-ignore-any-changes-without-committing
<jelmer> abentley: maybe that behaviour changed at some point? I don't have anything in my gitconfig as far as I can tell
<abentley> jelmer: It seems the behaviour I described is from /git checkout/, not /git switch/.
<abentley> jelmer: Or maybe the behaviour I described only happens when the changes would conflict?
<jelmer> abentley: the behaviour I described is from 'git checkout', I'm not sure about 'git switch' (didn't even realize that existed)
<jelmer> abentley: Yes, I could imagine changes conflicting being cause for an error
<abentley> jelmer: That seems to be it.  So the difference between bzr and git would be in the handling of conflicts.
<abentley> jelmer: So RemoteBranch isn't a descendant of BzrBranch, which means it won't automatically get get_unshelver/store_uncommitted/has_stored_uncommitted.  I could write a mixin, but it feels... dirty.  Thoughts?
<jelmer> abentley: I see two options: 1) provide smart verbs for fetching/storing uncommitted changes 2) add three stubs that call out to self._real_branch
<abentley> jelmer: I had actually started on 3) extract get_unshelver/store_uncommitted/has_stored_uncommitted to a component, i.e. UncommittedManager.  Maybe I'll go for 2.  Smart verbs don't seem worth it yet, since it's just 1 or 2 vfs operations.
<mgz> this isn't normal is it:
<mgz> $ bzr merge --preview -r15645..15644 .
<mgz> === modified file 'database/schema/security.cfg'
<mgz> things the file needs changing, no content changes, no x bit changes...
<mgz> *thinks
<abentley> mgz: No, but TransformPreviews don't necessarily detect when a file-level merge produces no change.  What does an actual merge do?
<mgz> nothing.
<mgz> `bzr st` returns blank
<abentley> mgz: And presumably "bzr st -r15645..15644" lists security.cfg?
<mgz> and a whole bunch of other stuff, as r-1 is the revert of that
<mgz> but for some reason that file doesn't think the revert was complete
<jelmer> abentley: I'd rather leave the RemoteBranch ignorant of the actual underlying logic, which is already present in the actual branch
<maxb> mgz: Thanks for forwarding that email from Thorsten. It only went to admins of ~bzr, not members, it seems. (jelmer: <- fyi)
<maxb> I guess I should send a reply
<mgz> he's replied to your post on the list now
<mgz> so would make sense to respond there I think
<mgz> still don't really understand why using a newer LTS isn't an option :)
<jelmer> maxb: ah, urgh
<jelmer> maxb: the web page says it would go to all *members*
<abentley> jelmer: for me, it says "Contact this team's admins".  Or am I looking in the wrong place?
<jelmer> abentley: https://launchpad.net/~bzr says "None, members emailed directly" near the email field
<jelmer> the link in the right hand side column indeed does say "Contact this team's admins"
<abentley> jelmer: This spamming of team admins seems to be a new phenomenon.  I don't think it had ever happened to me two months ago.
<maxb> jelmer: You *are* an admin, so for you it contacts the members
<jelmer> maxb: I have no idea how it would actually contact the members though
<jelmer> maxb: I don't have a link for that..
<maxb> ?
<jelmer> maxb: It doesn't provide me with a way to actually contact all members as far as I can see
<maxb> If I look at a team page for a team of which I am admin, the right hand portlet says "Contact this team's members". For a team I'm not admin, it says "Contact this team's admins"
<jelmer> maxb: ah, you'r eright
<jelmer> also, I can't spell
<Noldorin> hi jelmer
<Noldorin> jelmer: you around bychance?
<thomi> In Quantal, it seems bzr bisect doesn't work due to "AttributeError: 'CHKInventoryRepository' object has no attribute 'iter_reverse_revision_history'" - does anyone know if this is a simple patch, or a more involved fix?
<thomi> submitted as https://bugs.launchpad.net/bzr-bisect/+bug/1026827
<ubot5> Ubuntu bug 1026827 in Bazaar Bisect Plugin "bisect broken in quantal" [Undecided,New]
<thomi> I have a branch that seems to fix the issue for me: https://code.launchpad.net/~thomir/bzr-bisect/fix-for-quantal/+merge/115847
<jelmer> Noldorin: hi
<Noldorin> jelmer: was just trying out bzr-git again (on my mac)
<Noldorin> noticed a new error
<Noldorin> well, it may not be new
<Noldorin> bzr: ERROR: The file id "None" is not present in the tree <bzrlib.inventory.CHKInventory object at 0x105dc4950>.
<Noldorin> jelmer: other hting wasâ¦ does bzr-git support rmbranch?
#bzr 2012-07-20
<Noldorin> no one :(
<lifeless> Noldorin: its 1am or something for Jelmer
<lifeless> Noldorin: and you were addressing your discussion to him, so its not surprising :)
<Noldorin> lifeless: 1am is the middle of the day for me :)
<fullermd> Best time to lay out and work on your startan.
<Noldorin> startan?
<fullermd> Well, with my skin, it's more of a starburn, but...
<Noldorin> oh
<Noldorin> heh
<Noldorin> fullermd: what's the 'index' in bzr btw?
<mgz> morning
<abentley> mgz: jelmer wondered if maybe you'd take a look at this MP: https://code.launchpad.net/~abentley/bzr/branch-store/+merge/115618
<mgz> will have a look.
<mgz> (relook)
<abentley> mgz: ty.
<pfsmorigo> hi, I want to understand the "branches" command. I just created a branch using "bzr branch repo1 repo2". If I execute "bzr branches", on both, will show the following message "* (default)". What this means?
<jelmer> pfsmorigo: each of those directories has only one branch in it, the default branch
<pfsmorigo> jelmer: so, how do I create another branchs in it?
<jelmer> pfsmorigo: if you have a shared repository with multiple branches in it, they should show up in 'bzr branches'
<jelmer> or you can create new colocated branches (in newer versions of bzr), by running "bzr branch . co:newbranch" or "bzr switch -b newbranch" (which will switch to the new branch too)
<pfsmorigo> jelmer: the "co:" command doesnt worked by the second worked (at least the branch now have a new name)
<pfsmorigo> jelmer: so, I have two options. create a directory copy using "bzr branch oldcopy newcopy" or this colocated option. I'm right?
<pfsmorigo> jelmer: two directories for each branch or one for both, right?
<jelmer> pfsmorigo: yes, and the one-directory-per-branch approach is used most commonly
<pfsmorigo> jelmer: I was reading bzr use guide and there is just the "two directories" approach... http://doc.bazaar.canonical.com/latest/en/user-guide/organizing_branches.html
<jelmer> pfsmorigo: colocated branches (multiple branches in a single directory) is still experimental, and therefore not yet documented or recommended
<pfsmorigo> jelmer: hmm... now the parent branch is "."
<jelmer> pfsmorigo: if you use the shared repository approach (which should be documented), "bzr branches" will report sibling branches
<pfsmorigo> jelmer: how can I keep the default branch with the original parent branch?
<jelmer> pfsmorigo: how do you mean?
<jelmer> pfsmorigo: the parent branch is the branch that a particular branch was based off
<pfsmorigo> jelmer: https://gist.github.com/753752177417d6c5b03c
<pfsmorigo> jelmer: there isn't a default branch anymore...
<jelmer> pfsmorigo: the defualt branch is like HEAD in git
<jelmer> pfsmorigo: it's only shown if it isn't referring to one of the named colocated branches
<pfsmorigo> jelmer: ok. I will read a bit more the help and test some commands. tks for the support!
<leo2007> hello
<mgrandi> hello
<leo2007> what is the best way to move a commit (someone else's) from one branch to another?
<leo2007> I need to backport a commit from emacs-trunk to emacs-24.
<mgrandi> merging?
<mgrandi> make another branch of the branch from emacs-trunk at the commit you want to move, then merge it into emacs24?
<leo2007> sounds a bit too heavy for just one commit.
<jelmer> leo2007: it sounds like you want to cherrypick a single commit ?
<leo2007> jelmer: yes
<leo2007> how to do that?
<jelmer> leo2007: bzr merge -c REV-TO-CHERRYPICK BRANCH-TO-CHERRYPICK-FROM
<jelmer> leo2007: bzr commit -m "Cherrypick REV-TO-CHERRYPICK"
<mgrandi> so that just takes the diff/changes of that revision and merges that, rather then trying to merge the entire tree at that revision?
<jelmer> mgrandi: yes
<leo2007> jelmer: that seems to work but it didn't keep the authorship
<jelmer> leo2007: right, it doesn't - you can use the --author argument to respecify the author
<leo2007> a lot of hassle.
<jelmer> leo2007: there is the 'bzr replay' command that's part of bzr-rewrite too, but it doesn't deal with conflict
<luke-jr> Possible to get bzr to use diff3 for merge conflicts?
<maxb> jelmer: Do you have an unpushed revision for lp:~jelmer/ubuntu/precise/bzr/2.5.1-sru for the -0ubuntu2 upload?
<jelmer> luke-jr: bzr merge --diff3 ?
<mgrandi>     --diff3             Merge using external diff3.
<luke-jr> jelmer: I tried that, it doesn't seem to work
<luke-jr> I still get non-diff3 conflicts
<mgrandi> do you have diff3 installed?
<luke-jr> yes
<mgrandi> slash can it find it? (look in .bzr.log to see if it reported anything)
<jelmer> luke-jr: ah, you mean diff3 as a command line utility?>
<luke-jr> the log doesn't suggest it tried
<jelmer> luke-jr: bzr merge --using=diff3 perhaps?
<luke-jr> jelmer: I mean showing me TREE, common ancestor, and merging branch
<jelmer> luke-jr: ah, --show-base will do that
<luke-jr> aha
<jelmer> maxb: lp:~jelmer/ubuntu/precise/bzr/2.5.1-sru was just for the -0ubuntu1
<jelmer> I don't think I used UDD for the -0ubuntu2 upload
<maxb> fair enough
<maxb> just assessing how best to represent things in the ppa-oneiric branch
<Noldorin> ooh, busy tonight :)
<jelmer> hey Noldorin
<Noldorin> heya
<Noldorin> jelmer: was takign a look at some bzr-git stuff yesterday after you were gone
<Noldorin> jelmer: i'm tempted to say the way forward is using bzr-fastimport actually
<Noldorin> in combination with git import
<Noldorin> and whatnot
<Noldorin> it's quite versatile in fact
<Noldorin> can be extended to hg and other VCSs too in fact
<Noldorin> there are some derivative projects that do cool things actually
<jelmer> Noldorin: bzr-fastimport is not bzr-git :)
<Noldorin> jelmer: no but they can accomplish many of the same things ;)
<Noldorin> this is my point
<Noldorin> and bzr-fastimport has versatility on my side
<Noldorin> just found out about it
<Noldorin> but it seems like an interesting way to do various vcs-interop tasks.
<jelmer> Noldorin: bzr-fastimport is mostly interesting if you're using git and want to interoperate with bzr
<Noldorin> jelmer: it can be used to mirror branches both ways
<Noldorin> it's bidirectional ability is very good actually
<Noldorin> just saying :)
<jelmer> Noldorin: git->bzr only works if you're importing into the same bzr branch you originally exported from
<jelmer> Noldorin: so it's mostly useful if you're the only one using bzr, or if you're the only one merging from git
<Noldorin> jelmer: it's good enough in the vast majority of cases
<jelmer> Noldorin: depends on your use case
<Noldorin> only for intricate cross bzr-git workflows do you need more
<Noldorin> jelmer: well i've not seen one person lamenting the lack of features so far :)
<Noldorin> more than enough for me
<Noldorin> in fact
<Noldorin> it's really nice
<Noldorin> heh
<jelmer> Noldorin: for e.g. contributing a simple fix for an existing git project, bzr-fastimport is suboptimal
<Noldorin> you just use git for that :P
<Noldorin> ha
<Noldorin> no point using anything else
<jelmer> you first have to clone the git repository, then git fast-export it, then bzr-fastimport it, then make your change, then bzr-fast-export your change and git-fast-import it
<jelmer> Noldorin: That's the use case dpush was designed for
<Noldorin> yeah but dpush is horribly broken as we know :)
<Noldorin> https://github.com/alexreg/git-bzr-ng
<Noldorin> really nice ^
<Noldorin> simplifies import/export tasks
<jelmer> Noldorin: dpush doesn't handle a few corner cases well
<jelmer> Noldorin: but the same is true for bzr-fast-import
<Noldorin> mate, stop calling them corner cases
<Noldorin> w
<Noldorin> e
<Noldorin> we know that's not true
<Noldorin> bzr-git fails on the bzr branch itself, and two of my branches
<Noldorin> git-bzr-ng and fastimport works on all of them :)
<Noldorin> it has to be said
<jelmer> Noldorin: if you're just pushing one or two changes (and don't care about renames, since you're contributing to a git repo anyway) that's unlikely to matter
<Noldorin> yeah but git-bzr-ng is just as easy
<Noldorin> to be fair
<jelmer> Noldorin: isn't git-bzr-ng a git plugin?
<Noldorin> yep
<Noldorin> so?
<jelmer> Noldorin: if you're happy using the git executable and are storing your main code in git, what are you using bzr for?
<Noldorin> haha
<Noldorin> jelmer: no-one said anything about storing main code in git
<jelmer> Noldorin: that doesn't make much sense to me, but okay
<Noldorin> explain then
<Noldorin> if you're confused
<jelmer> Noldorin: that's okay, that bit doesn't really interest me; it's more the different approaches for exporting to git
<Noldorin> jelmer: this *is* an approach for exporting to git :P
<jelmer> Noldorin: it's the different approaches for exporting to git I'm interested in, not really on why your main branch is in the 2a format rather than in the git format
<Noldorin> this is a different approach
<Noldorin> so i don't get you
<jelmer> Noldorin: anyway, I seem to be the de-facto maintainer for both bzr-fastimport and bzr-git; I just think bzr-git is the cleaner approach
<Noldorin> yeah i saw that ;)
<Noldorin> so it's not like i'm slagging off one over the other
<Noldorin> fastimport just seems rather more reliable at htem oment
<Noldorin> at the moment*
<Noldorin> and indeed versatile
<maxb> There are some rather perplexing test failures for bzr-builddeb in oneiric and natty :-/
<jelmer> maxb: can you give an example?
<maxb> IOError: [Errno 21] Is a directory: u'/tmp/testbzr-LexZzZ.tmp/bzrlib.plugins.builddeb.tests.test_util.TreeContainsUpstreamSourceTests.test_empty/work/.bzr/checkout/dirstate'
<maxb> !
<maxb> and some sort of treetransform fallout in natty:
<maxb> OSError: [Errno 20] Not a directory: '/tmp/testbzr-kPYNe4.tmp/bzrlib.plugins.builddeb.tests.test_revspec.TestRevisionSpec_package.test_from_string_package/work/tree2/.bzr/checkout/limbo/new-1'
<jelmer> that second one looks vaguely familiar
<jelmer> maxb: I mean, the "Not a directory" bit looks vaguely familiar
<jelmer> I'm afraid I don't remember specifics though :-/.
 * maxb reviews some previous versions
<maxb> The same test failed in a different way in the previous bzr-builddeb release on natty
<maxb> and before that, a string of failures for other reasons
<jelmer> I think it had something to do with tarballs or zip files
<maxb> From the oneiric failure:
<maxb> 101.551  trying to create missing lock '/tmp/testbzr-LexZzZ.tmp/bzrlib.plugins.builddeb.tests.test_util.TreeContainsUpstreamSourceTests.test_empty/work/.bzr/checkout/dirstate'
<maxb> err... what? Something's amusingly confused there !
<jelmer> urgh, yep :)
<maxb> Hm, looks like the dulwich testsuite has hung on maverick & lucid too
<maxb> There was I thinking this series of PPA updates was going OK
<jelmer> maxb: that's probably one of the compat tests
<jelmer> maxb: you might need a minimal version of git-core in order to be able to run it
<Noldorin> jelmer: hmm is colocated stuff still in a separate plugin?
<Noldorin> on the latest version i have on mac, i don't see it there
<maxb> The bzr-builddeb failures are feeling like tests that don't properly support concurrency
<maxb> Also these builds would be a lot faster if they didn't run the tests 4 times
<Noldorin> lifeless: hye
<Noldorin> lifeless: just saw http://doc.bazaar.canonical.com/developers/colocated-branches.htmlâ¦
<Noldorin> lifeless: you may want to update that re: the branch separatorâ¦ even though i prefer the simple ',' ;)
<jelmer> Noldorin: it's in core, but only 2.6
<Noldorin> ah right
<Noldorin> jelmer: was just curious why it wasn't included as a default plugin in 2.5...
<jelmer> Noldorin: bzr-colo is very different from the colocated branch support in the core
<Noldorin> oh i see
<Noldorin> how so, briefly?
<jelmer> Noldorin: bzr-colo was designed to not depend on any changes to the core
<jelmer> but it's a bit of a hack, it adds an entire new set of commands to deal with colocated branches and has more overhead than the native colocated branches
<Noldorin> right
<Noldorin> jelmer: not to worry. i presume colo branches will be adequately documented when 2.6 comes out :)
<jelmer> Noldorin: note that the ocument you just linked to is the spec for colocated branches, not the user documentation
<Noldorin> indeed
<Noldorin> i knew that was just a whitepaper heh
<Noldorin> jelmer: only thing i'm curious aboutâ¦ did you decide on the "," seperator (as in the spec) or ",branch=" as before?
<jelmer> Noldorin: at the moment it's ",branch=foo"
<Noldorin> oh
<Noldorin> okay
<jelmer> Noldorin: we decided to use that as it's the safer option
<Noldorin> that's unfortunateâ¦ i'm sure you have a reason though
<jelmer> it's always possible to add support for ",foo" in addition to ",branch=foo" later
<Noldorin> indeed
<Noldorin> that's true
<jelmer> Noldorin: there are other situations in which you might want to use ,
<jelmer> Noldorin: e.g. "file:///tmp/bzr,revision=43
<jelmer> Noldorin: e.g. "file:///tmp/bzr,revision=43"
<Noldorin> hmm, yeah
<Noldorin> does that already work?
<Noldorin> i would suggest file:///temp/bzr?r=43 is better
<Noldorin> but fair enough
<jelmer> Noldorin: what happens when things are nested?
<Noldorin> like?
<jelmer> Noldorin: if you hasve a bzr tree inside another bzr tree
<Noldorin> ha
<jelmer> you might want to specify the revision of the inner tree
<Noldorin> then you've fucked up? ;)
<jelmer> this is the reason we picked , - that's what's specified by std66 for per-path-element parameters
<jelmer> Noldorin: also, ? is interpreted by shells and often can't be used without quoting i
<Noldorin> fair enough
<Noldorin> jelmer: so maybe simply ,b= and ,r= would be better
<Noldorin> at least
<Noldorin> a
<Noldorin> s
<Noldorin>  as aliases*
<jelmer> Noldorin: those aliases can always be added later
<Noldorin> yes that's what i just said
<jelmer> Noldorin: also, that's a fair bit less readable
<Noldorin> :P
<Noldorin> jelmer: ah, but is readability the key here? to me, definitely not
<Noldorin> succinctness is preferable
<jelmer> Noldorin: to occasional bzr users coming across these for the first time
<jelmer> Noldorin: another issue is whether "r" is going to be short for revno or for revid
<Noldorin> yes but weigh it up against the verboity
<Noldorin> verbosity
<Noldorin> definitely worth considering
<Noldorin> it shouldn't be dismissed quickly!
<jelmer> Noldorin: let's worry about that when it actually becomes an issue - colocated branch support has to be finished first
<Noldorin> i'm not worried
<Noldorin> i'm just throwing ideas at you!
<Noldorin> thought you might be grateful
<Noldorin> *shrug*
<jelmer> I'm not working on this stuff :)
<Noldorin> jelmer: you replied to me :P
<Noldorin> was initially at lifeless
<Noldorin> but yeah
<jelmer> Noldorin: you asked about my design considerations for colocated branches
<Noldorin> either way is cool
<jelmer> anyway, time for some sleep!
<jelmer> g'night
<Noldorin> yes, after lifeless was away
<Noldorin> jelmer: you reply, you involve yourself! ;)
<Noldorin> just try and be more receptive
<Noldorin> bureaucracy is the downfall of all entreprises
<Noldorin> after all
<jelmer> Noldorin: what's bureucratic here?
<Noldorin> i'll let you figure that out for yourself mate
 * jelmer sighs
<Noldorin> hah, go sleep on it or something
<Noldorin> don't sigh
<Noldorin> *think*
<Noldorin> it's good.
<jelmer> I don't care :)
<jelmer> /me sleeps
<Noldorin> good
<Noldorin> then don't ask
<Noldorin> else you'll give people conflicting views
<Noldorin> *laughs*
 * maxb looks at distro-info for the first time
 * maxb boggles that anyone ever thought writing it in Haskell was a good idea
<Noldorin> maxb: writing anything practical in haskell is probably a bad idea
<stumbles> Hi, I'd like to copy a configuration file from a template whenever I make a new branch of a repository. Ideally the behaviour would be embedded in the repository itself, rather than my user configuration. Is this something I can do with a plugin?
#bzr 2012-07-21
<glyph> I just got a notification about this bug: https://bugs.launchpad.net/bzr/+bug/806348
<ubot5> Ubuntu 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]
<glyph> What do all those status changes mean?
#bzr 2013-07-15
<ewong> hi, I'm trying to download bzr to my Slackware system.  I go to http://wiki.bazaar.canonical.com/Download, click Slackware, and it tells me to download the last version in http://bazaar-vcs.org/Download,  but that goes back to http://wiki.bazaar.canonical.com/Download
<ewong> is there a slackware package?
<jam> jelmer: ping about bzr and udd in particular. We're having a bug right now and I'm trying to remember how everything is set up. poke for vila if he shows up as well.
<jam> mgz: ^^
<jelmer> hi jam
<jam> jelmer: wasn't sure if you'd be on IRC around this time. :)
<jam> apparently someone rejected the package importers write access, so a bunch of packages were failing. They fixed that so I requeued the packages.
<jelmer> jam: I'm not too familiar with udd, mostly just with the bzr-builddeb side of things
<jam> Now they seem to be failing with: http://package-import.ubuntu.com/status/xserver-xorg-video-intel.html#2013-07-15%2009:34:58.867732
<jam> and I'm trying to remember where stuff like the shared repo is to go clean it up
<jelmer> jam: I'm not sure about that
<jam> jelmer:  no problem, I think Vila is the best person to ask, but he's not on IRC right now.
<jelmer> mgz might be another good candidate?
<mgz> yeah, I saw the mail but have no good ideas
<jelmer> maybe james_w ?
<jam> mgz: well I requeued the original bits, this is a new failure after the requeue
<jelmer> mgz: also, hi :-)
<mgz> jam: by cleanup, what do you mean? requeue? remove partial imports?
<jam> I have the feeling something managed to commit/pull garbage data that needs to be removed.
<jelmer> remove the shared repo and rerun the import I think? IIRC that was the main way to work around these
<jam> mgz: it is failing to commit because of "missing chk nodes" ,which makes me think something already put data in there with missing nodes and we are just detecting now on every commit.
<jam> but I don't know where that repo is
<jam> jelmer: right, but where is it? :)
<mgz> okay, so the repos are all somewhere obvious enough, don't have the path memorised but it's under /srv/package-import somewhere
<jam> mgz: well I know where the 'new' directory is, but I don't know where the actual content is stored. And searching is a bit slow because of the dirs with 1000s of subdirs in them.
<aviiiii> hi
<aviiiii> hi all
<aviiiii> looking for some help in bazaar
<jelmer> hi aviiiii
<aviiiii> hi jelmer
<aviiiii> looking for some help mate. I have a bazaar repo, lets call it 'foo'. Under foo repo I have a directory, lets call it projects.  so, I want to create a separate bazaar repo with only porjects directory & I want to retain the log too. I mean to say, everything that is related to project folder present in log file, should be available with this new repo.  Hope I am clear. Thank you in advance :)
<james_w> jam: the local repo is created afresh for each import attempt
<james_w> jam: so any bad data should probably be coming from the LP repo
<jam> james_w: would there be a cache that might get left behind?
<james_w> jam: I don't think so
<jam> It is certainly possible, but surprising to see >10 repos fail for the same reos.n
<jam> reason
<james_w> yeah
#bzr 2013-07-16
<STremblay> Hello everybody
<jelmer> hi STremblay
<STremblay> I am having somewhat of an issue with my Bazaar Client on Windows 7. With the GUI toolks almost every single operation I try to do gives me the same error.
<STremblay> bzr: ERROR: Could not acquire lock "(local)": file:///C:/Users/XXXX/AppData/Roaming/bazaar/2.0/lock
<STremblay> I did not install the Tortoise client and  the Automatically refresh status report option is checked off
<STremblay> The application will freeze when I click ok or cancel or even the close window button and after about 20 seconds or so, the erorr will pop up with the buttons Ignore error or close application. Ignore brings me back to the window that generated the error, closse the app closes it.
<STremblay> If I ignore errors, the changes made in the dialog are often not saved.
<STremblay> I've been searching for a solution for days and I can't figure it out. I've been using the Cygwin client instead, but I would really like access to the GUI tools to visualize things.
<STremblay> We use this a my job and if I can't get it to work properly, this is a big problem.
<STremblay> If anyone has any idea what could cause this or how to fix it, I would really appreciate it
<STremblay> I found this is also a problem using the commandline tools
<mgz> STremblay: you probably don't want your bzr stuff under Roaming, is that a network filesystem?
<STremblay> no, that's a local directory
<mgz> the windows nfs stuff is not very good at keeping operations ordered, so the dir renaming lock stuff bzr does can get tripped up
<STremblay> you mean ntfs?
<mgz> nopenope, and actually that symptom is slightly different
<mgz> can you pastebin the whole traceback please?
<STremblay> brb. I have to reboot.
<STremblay> I'm back
<STremblay> Ok, so I uninstalled everything and deleted the folder under AppData/Roaming. I'm going to retry installing the thing from scratch
<mgz> thanks.
<mgz> what version, by the way?
<STremblay> 2.5.1
<STremblay> using the bundled python 2.6.6
<STremblay> Hello.
<STremblay> Has anyone here ever had problems using bzr under Windows 7 x64?
<STremblay> I'm having issues where bazaar can't acquire locks
<STremblay> for example, I do a simple bzr checkout bzr+ssh://server/repo/branch and I get the message bzr: ERROR: Could not acquire lock "(local)": file:///C:/Workspace/projet/branch
<STremblay> this happens every time
<STremblay> I haven't been able to find any help online regarding this.
<STremblay> Otherwise, is there any possibility to use qbzr and bzrexplorer with the bazaar in cygwin?
<STremblay> I've been trying to resolve this all day and I need this to work. We're using bzr at the office and for some reason it just won't work on my machine. I'm using Win 7 x64
<STremblay> I'm back. I had to reboot again.
<STremblay> I anybody here at all?
#bzr 2013-07-17
<mlischke> Hi, I have a bzr repository on a server without working tree and when I run "bzr status" (or "bzr merge.." what is my original intent) I get the error "bzr: ERROR: No WorkingTree exists for..".
<mlischke> Shouldn't that work also for tree-less branches?
<lifeless> no
<lifeless> status reports on the tree status
<lifeless> it has no meaning for tree-less branches
<lifeless> bzr info will work
<mlischke> hmm, forget bzr status then, it was just a test, actually I want to merge another branch into this one
<mlischke> (bzr info works as expected)
<lifeless> well you'll need a tree :)
<mlischke> sounds a bit â¦ weird, I can create a branch without working tree, shoudn't I be able to merge from the parent tree to the copy also without a tree?
<lifeless> no, because merge's job is to prepare an updated tree.
<lifeless> when you commit the merge you can push the commit to a treeless branch
<mlischke> Ok, so what can I do to to make the copy take all changes from another branch? Create a tree in the copy, merge, remove tree?
<lifeless> mlischke: either do the merge elsewhere and push the result of the merge to the branch, or checkout the branch and do the merge in the checkout.
<mlischke> hmm, actually, this was my first approach, I have a checkout of both branches, but that gives me a criss-cross
<lifeless> mlischke: for instance; if you want to do this directly on the server; bzr checkout --lightweight $(branchpath) /tmp/foo; cd /tmp/foo; bzr merge $(otherbranch); bzr commit -m "Merged otherbranch";cd ..; rm -rf foo.
<mlischke> ok, let me try this on the server...
<mlischke> Previously I only tried locally
<lifeless> mlischke: criss-cross merges are a result of having an ambiguous history, not of the trees
<lifeless> you'll get that everywhere until it's resolved.
<mlischke> hmm, so it wouldn't help to merge on the server?
<mlischke> I always have to resolve criss-cross issues?
<mlischke> My hope was it would be simpler to solve when doing it on the server, but if that wouldn't help I can as well go through the hassle and clean it up locally
<mlischke> lifeless: thanks, I see the same criss-cross merge problem on the server...
<lifeless> mlischke: http://doc.bazaar.canonical.com/bzr.dev/en/user-reference/criss-cross-help.html
<mlischke> yes, thanks, have read this already
<mlischke> and use weave, but got +50 conflicts, so I was looking for an easier approach
<lifeless> so yes, you will see it everywhere until its been resolved (by merging into one or the other side)
<mlischke> seems I have to bite the bullet
<lifeless> sorry yeah
<lifeless> this tends to happen if you merge branch A to branch B and B to A without picking up the prior merge of A to B
<mlischke> It was a chain like this: A -> B, A -> C, now C -> B (as preparation for a later merge back to C)
<lifeless> that can do it
<lifeless> one way you might be able to fix it
<mlischke> C -> B is rather C merge to B, not a branch
<lifeless> merge C->B with -r - and choose the revision of C right before the merge of A->C
<lifeless> commit that
<lifeless> then merge C->B without -r
<mlischke> thanks, will try that
<icebrain> Hi! I'm thinking of setting up a readonly bzr server. Is it safe to give access using bzr_ssh_path_limiter?
<icebrain> safe enough to, say, publish the access information publicly?
<mgz> should be, you can just expose over http, which is reasonable performance for smaller repos
<wedgwood> anyone know of good examples of how to do the bzrlib equivalents of status (minimally checking for changes), revert, and clean-tree?
<beuno> wedgwood, I can help after lunch
<wedgwood> beuno: much appreciated
<wedgwood> I was just about to grab the bazaar source, but I'm nearly certain there's a more concise way
<beuno> wedgwood, have you seen this?  http://wiki.bazaar.canonical.com/Integrating_with_Bazaar
<beuno> it won't have exactly what you're looking for, but it may tp you in the right direction
<beuno> IIRC, what you want to operate on is the working tree
<wedgwood> no, I hadn't seen that. It does cover the status/diff bits. I'll see if I can find the rest.
 * beuno goes eat
<wedgwood> I see WorkingTree.revert (undocumented). Looks promising.
<wedgwood> beuno: I found everything I need. thanks for the pointer
<beuno> wedgwood, w00t, np
#bzr 2013-07-18
<cgrier> hi BRZ folks. I need help configuring BZRTOOLS under OpenSuse. I can get as far as ./setup.py install   but the builds always fail.
<spiv> cgrier: what error do you get (perhaps pastebin them if it's more than 2 lines long)
<spiv> cgrier: a common issue is that you'll need some 'devel' packages installed (maybe called 'python-devel' on suse?)
<cgrier> Thanks I'll check for the the python devel stuff.
<cgrier> didn't think that would be needed.
<cgrier> I can do the test "bzr zap -h" and it works correctly, but my build always fails with BZR: unknown command "patch"
<lifeless> cgrier: the patch command is in bzrtools
<lifeless> cgrier: you need to install that addon
<cgrier> lifeless: I did unzip all the bzrtools and followed the documentation on installing, but it didn't always recognize the extra stuff during when doing a make
<cgrier> I did the ./setup.py install
<cgrier> when that didn't work I tried the "mv" to the .bazaar folder
<cgrier> but  I didn't really understand the "mv" approach, since it said to not copy the contents.
<lifeless> is bzrtools listed in 'bzr plugins' ?
<cgrier> I'll check. how do I do that?
<cgrier> I tried bzr-explorer from the command line, but it isn't a good command (I know the package is installed)
<cgrier> OK, duh
<cgrier> I tried bzr plugins
<cgrier> and bzrtools is listed
<cgrier> if I try "test.py" it gives this response: ImportError: cannot import name bzrtools
<lifeless> cgrier: you need to call bzrlib.plugin.load_plugins()
<lifeless> or something like that
<lifeless> before you can import plugins, I think.
<lifeless> sorry, I'm out of date here.
<cgrier> OK, I'll try that. need to hang up now thanks for the assist
<hachre> how worried should I be that there has been no development for a year?
#bzr 2013-07-19
<LeoNerd> I haven't found a bug or a missing feature in the last year
<LeoNerd> For me bzr JustWorks
<hachre> well, I guess it just looks bad
<lifeless> hachre: there has been some dev - bug fixes mainly
<hachre> https://launchpad.net/bzr
<hachre> the last release I see here is a beta from one year ago
<hachre> that's what I'm referring to
<hachre> and before then there was a release every month
<hachre> what happened?
<maxb> hachre: If I understand correctly, the amount of employee time that Canonical devotes to Bazaar decreased sharply. Unfortunately that seems to have revealed that no-one else is doing significant Bazaar core dev.
<maxb> I still like and use Bazaar, but I have to admit I wonder what its long-term future is going to be, given Git and Mercurial seem to be winning the popularity battle.
<hachre> yea, I'm wondering the same
<hachre> and I think it's detrimental by now for launchpad to be only supporting bazaar...
<ScottK> It's OK, ~no one is working on developing that either, so they are even.
<hachre> yea
<hachre> lol
<hachre> I noticed that too
<mlischke> hi, I have moved a number of files in my branch (manually) and now want bzr to update its internal references. So I tried bzr mv âauto, but that does not have any effect.
<mlischke> Does this only work for single file changes?
<LarstiQ_> mlischke: that should work for multiple files
<mlischke> I tried with âverbose but get no output at all, it just returns without effect.
<LarstiQ_> mlischke: are you sure you're in the right branch?
<mlischke> I have now prepared a text file with all the mv commands and am running that.
<LarstiQ_> mlischke: what does `bzr status` say?
<mlischke> I am, yes
<LarstiQ_> mlischke: you want --after for that probably
<mlischke> tried that too
<LarstiQ_> I mean for the text file you mentioned
<mlischke> That file is only for easy search and replace etc. so I don't need to type all the commands.
<mlischke> (doing it file by file)
<icebrain> hi! Is there any way to branch a branch (ha) from Launchpad using HTTPS? It seems bzr is trying to use bzr+ssh, and my proxy doesn't like that
<mgz> no, but you can use http
<icebrain> mgz: sorry for the delay, I missed your reply. How can I set it to use HTTP?
<LarstiQ_> icebrain: if you're not using bzr+ssh, you can comment out launchpad_username in bazaar.conf
<LarstiQ_> icebrain: which then will have lp: resolve to http
<icebrain> LarstiQ_: it doesn't seem to work. I get the message "You have not informed bzr of your Launchpad ID", but still "ERROR: Invalid url supplied to transport: "bzr+ssh://bazaar.launchpadd..."
<LarstiQ_> icebrain: that soudns like you already branched something?
<icebrain> LarstiQ_: well, not successfully, no ;)
<icebrain> I've been trying to, though
<LarstiQ_> icebrain: can you paste the relevant bit from .bzr.log?
<icebrain> sure
<mgz> icebrain: there's a trick to just getting the http url as well, if a branch is the main one for a project
<mgz> for example, use `bzr info http://launchpad.net/bzr` and take the branch url that give
<mgz> then you don't need to fiddle with launchpad login
<icebrain> mgz: thanks, I'll try that.
<icebrain> LarstiQ_: http://pastebin.com/raw.php?i=diGYYR7Y
<icebrain> mgz: that worked, thanks!
<icebrain> LarstiQ_: thanks for your help as well
<LarstiQ_> icebrain: I'm a bit confused about that error. You don't have launchpad username set, you apparently do not have support for bzr+ssh (nothing to do with your proxy), yet it tries to use it?
<LarstiQ_> ho hum
<LarstiQ_> same happens here
<LarstiQ_> but it does work for lp:bzr
<mathrick_> hiya, I'm seeing TREE_ROOT rear its ugly head again, and I can't see why
<mathrick_> namely, I tried joining a git-derived tree into a development-colo branch of mine, and it complained about same root
<mathrick_> turns out both are TREE_ROOT, which baffles me
<mathrick_> moreover, if I attempt to restart the branch by fast-export, fast-import, it turns into TREE_ROOT as well, even though a freshly init'd branch has a proper randomly generated root name
<mathrick_> it's really throwing a spanner in the works for me
#bzr 2013-07-20
<Munchor> Hi is there a bzr command that prints out every revision number and its commit message on the terminal?
<Munchor> oh found it, 'bzr log', thank you
<mathrick_> jelmer: so it seems that git dpush retroactively erases file-ids somehow, and makes the tree root be TREE_ROOT. How's that possible at all (I thought file ids were a part of the commit, and thus immutable)?
<maxb> Normally yes, but the d in dpush is 'destructive'
<mathrick_> maxb: hmm, so it basically replaces the true history with one rebased onto the remote?
<jelmer> mathrick_: yes, that's why it's a separate command
<jelmer> mathrick_: you can prevent that behaviour with --no-rebase
<mathrick_> jelmer: any way to have a tree I push to git and be able to join it with another git-backed tree?
<jelmer> mathrick_: I don
<jelmer> 't think that works at the moment
<mathrick_> damn
<jelmer> not without "proper" push support, which I never finished for bzr-git
<mathrick_> and "at the moment" seems to be here to stay :\
<mathrick_> I really don't want to use git to interact with git trees
<jelmer> mathrick_: it'd be great if somebody could take over bzr-git maintenance
<mathrick_> jelmer: I don't think I could do it without understanding git really well, which kinda defeats the purpose of using bzr-git to avoid touching git
<mathrick_> lemme tell you, the result of DVCS wars don't make me happy a single bit
<mathrick_> *results
<mathrick_> jelmer: what's lacking in "proper" git push support?
<jelmer> support for lots of corner cases
<mathrick_> sounds like understanding git very well is mandatory for those
<mathrick_> jelmer: another thing, which is very hard to glean, is there anyone doing anything at all with bzr still? I know that the canonical team has been effectively disbanded, but do you have any idea if anyone remains working on it in spare time, or if anyone from the outside came?
<mathrick_> to be honest, it's not even possible to guess, without some very extensive googling, that the project is effectively dormant
<jelmer> mathrick_: yes, hacking on bzr-git requires knowledge of both bzr and git internals
<jelmer> mathrick_: there isn't really a way around that :-)
<jelmer> I think the commit logs, the bug tracker and the mailing list archives show a correct picture
<jelmer> bzr isn't dead - there are still things happening - but at a rate that's much lower than before
<SamB> wow, there seem to have been several commits to lp:bzr in may
<Jayden> Hi all.  I just started using bzr ... to checkout the src to a project I'm interested in (fwiw, MariaDB).  I'm having a heck of a time checking-out the entire repo; keep getting "Connection Timeout: disconnecting client after 300.0 secondse 1178175/1178175" at various points/times.
<Jayden> Is there a 'resume' command in bzr? Starting over each time is getting me nowhere fast.
<SamB> -r might help?
<SamB> like, start with -r 100 and then pull with gradually increasing numbers
<Jayden> SamB: Hi.  How would pulling a specific revision help?
<Jayden> ah, missed your comment.  I suppose that could work; worth a try.
<Jayden> SamB_: Looks like a working, if clunky, solution.  Thanks!
#bzr 2013-07-21
<mathrick_> jelmer: do you have any tracker bug or TODO of what remains to be sorted out for git push?
<jelmer> mathrick_: yes, http://pad.lv/544776
<ubot5> Launchpad bug 544776 in Bazaar Git Plugin "no roundtripping support" [Wishlist,Triaged]
<jelmer> it doesn't have a summary of what's left though
<jelmer> you can run the full bzr testsuite with bzr installed to get some idea of what's missing
<jelmer> (you'll get ~1000 broken tests)
<mathrick_> I see
<mathrick_> I assume it's not only bzr-git that fails in those 1000?
<jelmer> it is just bzr-git
<jelmer> I'm sure you can get more errors if you install more plugins :)
<mathrick_> heh
#bzr 2014-07-18
<cmn> hi, what would be the best tool for moving a bunch of commits to a branch in a different repository? would that still be replay from bzr-rewrite?
<jelmer> cmn: pull/push?
<cmn> jelmer: that would work even for disconnected branches?
<cmn> presumably through -r?
<jelmer> cmn: no, it wouldn't work for disconnected branches
<jelmer> replay wouldn't work either ,though
<cmn> there's a thing in the bug tracker that at least makes it look like it does
<cmn> though I haven't checked too deeply
<jelmer> cmn: it works based on fileids, and the file ids will be different if you have two disconnected branches
<jelmer> cmn: (replay also has other issues)
<cmn> jelmer: yeah, it turns out it ends up removing a ton of stuff
<jelmer> cmn: I think fastexport/fastimport is probably the best thing available at this point
<cmn> yes, that's what it looks like
<cmn> though the docs say it wants to create the branch itself
<cmn> I'll have to dig deeper
<jelmer> cmn: it supports applying changes to an existing branches
<jelmer> s/branches/branch/
<cmn> excellent
#bzr 2015-07-16
<thomi> Does anyonw know what this error means while trying to run 'bzr revno'?
<thomi> bzr: ERROR: Could not determine revno for {thomi.richards@canonical.com-20150716223714-538h7jeoeo5fzb62} because its ancestry shows a ghost at {thomi.richards@canonical.com-20150716223714-538h7jeoeo5fzb62}
#bzr 2015-07-17
<spiv> thomi: is it a stacked branch where the stacked-on branch has moved, or something?  It's basically saying part of the history isn't there anymore, which shouldn't happen in a self-contained repo.
<spiv> But perhaps could happen if it depends on other repo for some of the history (i.e. is stacked).
<spiv> Perhaps see if you can find a likely repo with that revision in it.
<thomi> hmmmm..
<fullermd> That sounds like it's the _current_ rev that's a ghost, which is Really Marfed Up.
<thomi> the repo isn't anything special, I don't think.
 * bambams began reading bzrinit.com after the author's blog post enraged him.
<bambams> And now I just don't know what to think.
<wgrant> thomi: If it's a package branch, that's probably https://bugs.launchpad.net/bzr/+bug/888615
<ubot5> Ubuntu bug 888615 in Bazaar "UDD branch freshness checker breaks on incomplete history" [High,Confirmed]
<thomi> wgrant: it's a charm branch. Same problem I guess?
<wgrant> thomi: Likely.
<thomi> *sigh*
<wgrant> thomi: There's a workaround in the bug.
<wgrant> Comment #3
<thomi> it's not a huge deal, just yet another papercut in my day :D
#bzr 2015-07-18
<bambams> As an experienced Git and Mercurial user I have completed the bzrinit.com tutorial.
<bambams> Is this still in active development? It seems rather obsolete. I mean, it's good for GNU to have its own software to maintain, but I think it would be a better use of the project's time to contribute to Git until the license become non-free and fork.
<hinst> git shit
#bzr 2016-07-19
<memguy> I am wondering now that i got the general process of most of the different version controls down , and terminology /structure of the repo's....I have a question related to project hosting websites and web based revision control software
<memguy> The question is 1) is behind the scenes when one signs up with things like savannah , sourceforge , launchpad , codeplex, cloudforge , bitbucket , gitorious ,...etc are they all storing the projects in a revision control software behind the scenes like cvs,svn,git.hg, bazzar,..etc
<memguy> 2) I just recently realized that web based version controls work much in the same way as  command line cvs ,svn,..etc. So i am kind of wondering when i reach a website repo how to relate it back to the command line . i.e say i go to cvs web viewer site  can i just uses the url i am at as the repo   and do a command line cvs -qd whatshouldbehere get -P src
<memguy> I guess i am trying to just by going to a web repo site finding out right from that how to get it by command line
<memguy> If i can completely relate the web repo gui buttons in the website itself to  cvs command line that would be so awesome but the thing stopping me is figuring out the repo location from the website... without googling my butt off for an alternative repo that i can get from command line
<vila> memguy: web sites can do whatever they please, they are no rules. Most of the time, some hint about the repo/branch is described on the page, but again, no hard rule there either.
<vila> s/they are/there are/
<memguy> I see github does a good job of providing the git repo like over http or https or just download the folder as a normal file download
<Demosthenex> i'm using bzr 2.5.1 on an old ubuntu, i have a simple repo in a dir with a bunch of org-mode (text) files. cron job commits hourly if there's any changes. had a computer crash during a commit, had to break a bzr lock. working dir says run update, update says a revision is not found and fails. where to go from here?
<mgrandi> can you see if the revision its trying to get is actually a commit?
<mgrandi> as in @Demosthenex is it a recent commit?
<mgrandi> (brb software upgrade)
<Demosthenex> i see the long revision string lists a date AFTER the latest commit in the log
<Demosthenex> or rather what it says is missing
<Demosthenex> but if i try uncommit, it wants to rollback a commit made yesterday
<mgrandi> can you checkout just the latest commit
<mgrandi> that you know you made?
<Demosthenex> i'll give that a shot when i'm at the machine next
<memguy> one last thing with revision control current does anybody know what most project managers and code developers like to uses for the repo ? Me personally i imagine 99% of things now adays are either git , cvs ,svn , and maybe hg  at least for the opensource / free software community
<memguy> For the closed source windows, mac, ...etc os they uses there on proprietary  RCS some times like TFS ...etc
<memguy> IBM uses clearcase , cpvc ,...etc
<mgrandi> perforce, bitkeeper, plastic
<memguy> Would i be missing any major players in the repo software category
<mgrandi> fossil (open source)
<memguy> way but those don't seem used all that much
<memguy> i am talking about the 99%
<mgrandi> i guess
<mgrandi> plastic i know is sorta big
<mgrandi> and bitkeeper used to host hte linux kernel at one point =P
<memguy> ya but bitkeeper broke into git and hg
<mgrandi> it still exists as a product though
<memguy> ya but i am talking about most of the projects
<mgrandi> and now apparentloy open source =P https://www.bitkeeper.org/
<memguy> repo
<Demosthenex> memguy: bzr check! =]
<Demosthenex> and bzr check bugged out.
<Demosthenex> branch clone, thats ok, replaced original.
<mgrandi> good to hear =)
#bzr 2016-07-20
<memguy> well ya i knew about that but doesn't seem alot of mainstream projects are using it most sticks with git,cvs,svn
#bzr 2016-07-21
<memguy> I have a repo question i am wondering about this link  http://www.openbsd.org/plus27.html its a web based changelog for version changes. Curious is the changelog part of the Reversion control software. Because i am confused between how these are built from the commit logs ... commit logs being to big to be useful for most people
#bzr 2016-07-24
<jimt> I would like to migrate a bzr branch to git. The internet suggests I use bzr fast-export --plain to do that, but when I try using Bazaar 2.7.0 on Ubuntu 16.04 it complains that fast-export is an unknown command. Is there a plugin I need to install?
<Peng> jimt: apt-get install bzr-fastimport
<Peng> I can't say if it's particular the best tool for this job, but that is the package.
<Peng> particularly*
<jimt> Peng: Thanks.  I had tried installing bzr-fastimport, but Ubuntu warned me that it had been replaced by python-fastimport. And I have the latest version of that installed, but no fast-export command.
<Peng> Oh. D:
<jimt> And unfortunately there doesn't seem to be a python-fastexport (or anything obvious with export in its name).
<Peng> I almost wonder if Ubuntu made a mistake... They added the package back in Yakkety.
<Peng> The bzr-fastimport package, i mean.
<fullermd> 'm pretty sure they're not the same thing...
<Peng> The python-fastimport package appears not to contain bzr-fastimport.
<fullermd> I use git-bzr-ng to maintain a git mirror of some bzr branches.  You might look at that.
<Peng> http://packages.ubuntu.com/yakkety/all/python-fastimport/filelist vs. http://packages.ubuntu.com/yakkety/all/bzr-fastimport/filelist
<Peng> Super weird. bzr-fastimport exists in 14.04 and 16.10 but not 16.04. ???
<Peng> There are ways to install things that aren't Ubuntu packages, of course. But i don't get this.
<jimt> Hmm... Since I only need to do this once, I'll just log in to a 14.04 machine. I should have tried that.
<jimt> Thanks peng and fullermd for the help/suggestions.
<jimt> Yes, it did indeed work on 14.04... so I've got the git repo I was after. I filed a bug on Launchpad about the missing package. Thanks again for the pointers.
#bzr 2017-07-20
<LeoNerd> Where did 'bzr rebase' go?
<LeoNerd> I thought it was part of bzr-rewrite but my debian no longer knows of such
 * LeoNerd peers at  https://people.samba.org/bzr/jelmer/bzr-rewrite/trunk/
<LeoNerd> Well, that works :)
#bzr 2017-07-21
<Walex2> LeoNerd: interesting
#bzr 2018-07-16
<mgz> jelmer: reviewed
<jelmer> mgz: gracias
