#bzr 2007-09-24
<lapthrick> hrmpf
<lapthrick> it seems that a push didn't, in fact, include the nested tree :(
<lifeless> had you committed?
<lapthrick> yes
<lifeless> does 'bzr branch mytree mynewtree' include the upstream subtree ?
<lifeless> and did you use bzr push, or bzr svn-push?
<lapthrick> lifeless: when I do svn log on that branch, there's a missing revno corresponding to when I merged
<lapthrick> lifeless: svn-push
<lapthrick> actually, it might be due to another thing
<lifeless> jelmer_: good timing
<lifeless> assuming you are here :)
<lapthrick> that SVN repo uses a two-level branch structure
<lapthrick> so branches/owner/branchname
<jelmer> hey lifeless
<lifeless> 08:04 < lapthrick> hrmpf
<lifeless> 08:04 < lapthrick> it seems that a push didn't, in fact, include the nested tree :(
<lifeless> 08:05 < lifeless> had you committed?
<lifeless> 08:05 < lapthrick> yes
<lifeless> 08:05 < lifeless> does 'bzr branch mytree mynewtree' include the upstream subtree ?
<jelmer> it's actually evening here (-:
<lifeless> 08:05 < lifeless> and did you use bzr push, or bzr svn-push?
<lifeless> 08:05 < lapthrick> lifeless: when I do svn log on that branch, there's a missing revno corresponding to when I merged
<lifeless> 08:06 -!- jelmer [n=jelmer@157pc196.sshunet.nl]  has quit [Remote closed the connection] 
<lifeless> 08:06 < lapthrick> lifeless: svn-push
<lapthrick> and it did bail out with "not a valid SVN branch" during that push
<lapthrick> so I assume it was trying to push that sub-tree after pushing the parent tree and then it died
<lapthrick> jelmer: so, I need support for two-level branch scheme for the repo I'm using
<lapthrick> though it's actually optional, some branches we have are directly unders branches/, some live in branches/owner/
<jelmer> lifeless: Thanks
<lapthrick> jelmer: I also submitted a bug report and have a scenario where merge-into manages to kill bzr-svn for you :)
<jelmer> lapthrick: 'bzr svn-branching-scheme' should be able to tell you what branching scheme is being used for a repository atm
<lapthrick> bzr pokerolymp:2090/> svn-branching-scheme svn+https://beta.aimido.de/svn/src2/
<lapthrick> trunk
<lapthrick> branches/*
<lapthrick> tags/*
<jelmer> you'd probably want to add 'branches/*/*' there as well
<lapthrick> jelmer: how can I do that?
<jelmer> bzr.dev svn-branching-scheme --set
<lapthrick> jelmer: so just svn-branching-scheme --set branches/*/* ?
<jelmer> lapthrick: just bzr svn-branching-scheme --set <url>
<jelmer> that should put you into an editor allowing you to edit that list
<lapthrick> ahh
<jelmer> the branches/*/* should probably be the first line
<lapthrick> bzr pokerolymp:2090/> svn-push svn+https://beta.aimido.de/svn/src2/branches/mathrick/pokersource/
<lapthrick> Unhandled error:
<lapthrick> hmm
<lapthrick> I suspect that branch might be broken by the previous botched push
<lapthrick> no, actually it happens for every branch I try to push to
<lapthrick> jelmer: any idea where I should poke it?
<jelmer> lapthrick: what unhandled error exactly?
<lapthrick> jelmer: that's exactly what it says. Unhandled error and then nothing
<jelmer> can you try running with BZR_PDB=1 set and seeing what line it bails out on?
<lapthrick> jelmer: http://pastebin.com/m68ba42d8
<lifeless> igc: I have all tests passing in packs
<jelmer> ah, looks like ListBranchingScheme still needs a is_parent_branch() implementation
<igc> that's great lifeless
<lifeless> igc: about to send a patch that cleans up weave stuff - and makes the tests pass ;)
<igc> ok - I'll have a look
<lapthrick> jelmer: is there an easy fix for that?
<jelmer> lapthrick: looking at it atm
<jelmer> lapthrick: btw, I don't think I've seen any bugreport on the merge-into/bzr-svn problem
<lifeless> igc: mail sent
<igc> cool
<igc> btw, up early because it's school holidays here now - best to get as much done as early as possible :-)
<lifeless> heh
<lifeless> I got 7 hours solid sleep.... and then woke up at 0430
<lapthrick> jelmer: no, I didn't submit a bugreport, as it wasn't entirely clear what's happening
<jelmer> lapthrick: If you can still reproduce it, a bug report would be very useful. merge-into and bzr-svn should be able to work ok together
<lapthrick> jelmer: sure
<lapthrick> jelmer: actually it seems I'm able to trigger two separate errors
<lapthrick> mathrick@hatsumi:/tmp/merge$ bzr merge-into file://$PWD/../test/trunk test
<lapthrick> bzr: ERROR: Repository KnitRepository('file:///tmp/merge/.bzr/') is not compatible with repository SvnRepository('file:///tmp/merge/../test')
<lapthrick> jelmer: that's on a local test repo
<lapthrick> jelmer: http://pastebin.com/m63022805
<lapthrick> this one is on the actual repos I wanted to merge-into
<jelmer> lapthrick: that first error should be fixable by upgrading the bzr repository
<jelmer> lapthrick: see the FAQ in bzr-svn's 0.4 branch
<jelmer> lapthrick: I'll fix the other one
<lapthrick> jelmer: great, thanks
<lifeless> igc: repository branch that passes all tests pushed
<igc> cool. Did you want me to run any tests here?
<lifeless> not as such
<lifeless> just letting you know
<igc> sure - thanks
<Peng> Pulling from the repository branch: bzr: ERROR: Revision {robertc@robertcollins.net-20070923224332-qy28l0g345rcyein} not present in "rev_storage.py-20051111201905-119e9401e46257e3".
<Peng> Is it in the middle of a push or something?
<lifeless> no
<lifeless> revert back a couple of revisions
<lifeless> then pull again
<lifeless> termporary bokrage
<Peng> What, uncommit back a few revisions?
<lifeless> yes
<lifeless> bbiab
<lifeless> before the 'fix test X' one, that broke it
<lifeless> uncommit + revert
<lifeless> ok, ciao, -> poolies
<Peng> Oh, revert too.
<Peng> Yeah, that worked.
<Peng> Thanks.
<abentley> lifeless: The branch: and ancestor: revision specs do a fetch.
<poolie> hi
<poolie> abentley, i think lifeless is on a train
<abentley> poolie: Okay.  No big rush.
<poolie> (rebooting)
<lifeless> Peng: cool
<Peng> So what was wrong with it?
<lifeless> I broke it
<lifeless> then I unbroke it
<lifeless> you had the broken copy
* igc food
<Peng> Okay.
<lifeless> Peng: the details are pretty boring really; there was a failing test that was more important than I realised; and two variables being tested for equality that were of different types
<lifeless> Peng: but all tests pass now; so should all be good
* fullermd blinks.
<fullermd> Underrating the importance of a failing test??  Who are you, and what have you done with lifeless?
<lifeless> its an experimental branch
<lifeless> I don't have a zero-tests failing policy for things that I'm doing open heart surgery on; I try for zero but its not always feasible.
<fullermd> Hrmph.  Excuses, excuses.  Getting soft in your old age...
<Peng> lifeless: Oh, okay.
<lifeless> igc: ping
<igc> hi lifeless
<lifeless> want a quick call ?
<igc> sure
<igc> you at poolies?
<lifeless> up
<igc> or you can call me
<lifeless> yup
<lifeless> nah, call poolies
<igc> np
<igc> 2 minutes
<ubotu> New bug: #144352 in bzr "tag should refuse to tag null:" [Undecided,New]  https://launchpad.net/bugs/144352
<jelmer> lapthrick: ok, the bug you posted to pastebin should be fixed now
* Starting logfile irclogs/bzr.log
<poolie> jelmer: hi?
<jelmer> poolie, hi
<lapthrick> jelmer: the one with merge-into svn://, or the one with push svn:// ?
<jelmer> lapthrick: merge-into
<jelmer> poolie: ping?
<lapthrick> okay, lemme try
<jelmer> btw, I've only fixed the issue you reported, not actually tested merge-into with bzr-svn..
<lapthrick> jelmer: it seems to work fine
<jelmer> cool, great :-)
<lapthrick> jelmer: do you have that push bug recorded somewhere, or should I put it in launchpad?
<jelmer> lapthrick: I just filed a bug report on launchpad, with you subscribed
<lapthrick> good, thanks
<fullermd> poolie: Hi dere.
<fullermd> poolie: Is 0.91 blocked on something?
* jelmer gets some sleep
<poolie> fullermd: no, just other work keeps getting ahead of it
<poolie> liw, hi
<liw> poolie, greetingses
<fullermd> Coolies.  Just making sure I didn't miss something on the list   :)
<lapthrick> I have a branch in which I removed some files present in upstream, now it turns out I need them. What's the best way to restore them?
<GaryvdM> lapthrick: revert
<GaryvdM> I think
<AfC> lapthrick: revert is correct if it's simply current uncommitted work.
<AfC> lapthrick: if numerous revisions have gone by since then, you'll have to do something more elaborate
<lapthrick> the latter
<liw> would a reverse merge work? "bzr merge -r 42..41"
<lapthrick> it suggests merge -r foo
<AfC> ... a kludgy way to do it would be to just copy the files [back]  in, and `bzr add` them [again]  [potentially using  --file-ids or whatever to make sure it knows what you're up to] 
<AfC> liw: [that would assume the file removal was the only thing in that revision, although you could do that and then revert the parts you didn't want to, er, revert :)] 
<lapthrick> it seems that revert takes revision argument, but it also seems that I didn't, in fact , remove the dir I needed, I was just looking in the wrong place :)
<lapthrick> aye, revert -r foo bar restores bar just fine
<lifeless> ciao for now, be back in a bit
<lapthrick> AfC: we need to beat some sense into desrt
<lapthrick> what with his silly delusions about git
<lifeless> lapthrick: are you a gnomer ?
<lapthrick> lifeless: indeed
<lifeless> cool
<lapthrick> indeed :)
<lifeless> AfC: btw, did I mention I have local initial commit faster than hg now ?
<lifeless> AfC: (not that hg are *my* benchmark, but they seem to be some folks' benchmark)
<lifeless> heading home, be back in a bit
<lapthrick> see ya
<vila> hi all
<lapthrick> hi vila
<lapthrick> vila: looked into that curl bug perhaps?
<vila> lapthrick: 1) not yet, 2) I thought you found it was more on the bzr-svn front ?
<lapthrick> vila: no, quite the opposite, I found it's a general libcurl-gnutls compat issue
<vila> lapthrick: more precisely ? Is that a problem in curl or a problem in the way we interact with it ?
<vila> lifeless: regarding my corrupted repo, I found that gutsy have changed the way nfs interacts with OSX
<lapthrick> vila: I dunno, but last time you said it looked like an API compat bug and you need to look into it, since there was no error 77 as far as you knew
<vila> lapthrick: That point I didn't have time to check yet
<lapthrick> ok
<lapthrick> I'm not in a big hurry, I can use https+urllib for now, that repo isn't very likely to haxx me for not checking the cert properly
<vila> lapthrick: ok
<vila> lifeless: as I update gutsy as soon as the update-manager warn me, I can't know exactly if/what/when something went wrong, *but* this morning, the nfs mount from OSX failed at boot (but worked from command line...) until I add proto=tcp in /etc/fstab (using mount-v revealed that the mount succeeded with proto=udp)
<vila> as I can't reproduce the corruption by committing in the same conditions (to the best of my knowledge), I will consider that NFS was the cause (I don't really like leaving a possible corruption bug lying around, but I really can't see what to do to get a better diagnosis)
<vila> lifeless: I am currently reorganizing around a new repo and will keep the corrupted one for some weeks anyway as it looks as a perfect candidate to better understand many details (why 'bzr send -o -' needs to refer to a revision outside of the branches it should care of, for one :)
<lifeless> vila: ok
<lifeless> oh, and I'm back :)
<vila> lifeless: :) I still feel bad about that corruption though... What is *your* feeling ?
<lifeless> vila: One of the lp developers has had similar corruption twice now; they use nfs.
<vila> lifeless: haaaa, what a relief, same symptoms ? zeroed revision ?
<lifeless> dunno exactly
<vila> lifeless: ok, will keep an open eye then (but I rarely commit from OSX these days anyway)
<vila> lifeless: is there same way to check against this corruption from another data path or do we rely on the gzip crc ?
<lifeless> file sha will find it
<vila> ok, I'll try to look into that (if only to understand if bzr may have been tricked by nfs telling him, yes, the content have been written to disk, when in fact it has not)
<vila> that's one of the reason I didn't want to touch that repo if I was able to rebuild everything (which I'm close to have achieved)
<vila> lifeless: errr, scratch that, the commit was from the NFS server
* igc food
<ubotu> New bug: #144388 in bzr "Cannot do svn checkouts in a repository" [Undecided,New]  https://launchpad.net/bugs/144388
<ubotu> New bug: #144394 in bzr "stderr from a bzr+ssh smart server process should not be sent to the client" [Undecided,New]  https://launchpad.net/bugs/144394
<ubotu> New bug: #144421 in bzr "Using branch: revspec in stat blows up" [Undecided,New]  https://launchpad.net/bugs/144421
<abadger1999> Does launchpad support the smart server?
<Peng> Yes.
<Peng> It's even recommended now1
<Peng> !
<Peng> Not sure about bzr+http.
<abadger1999> Cool.
<abadger1999> Oh.
<abadger1999> Does that mean I would need an account of some sort to have ssh?
<Peng> Yes.
<fullermd> I didn't think it did, only the +ssh variant.
* abadger1999 is not an ubuntu dev
<Peng> I tried to set up a bzr+http server once. It didn't work. Someone else had the same experience too.
* Peng wanders off.
<abadger1999> I'm making some speed tests for a blog post and wanted to include smart server times to lp.
<abadger1999> Guess I'll just include times to a server I have ssh on and note any discrepancy between doing a plain branch operation and smart server branch operation compared to lp.
<fullermd> I don't think bzr+http is in general significantly faster than http.  It'll gain a little, and the special case of initial mirror may be a good bit faster from the tarball sending thing, but that's pretty fringe...
<abadger1999> Good to know.  Is http in general faster than bzr+ssh?
<abadger1999> err.. as fast as.
<fullermd> Well, theoretically (mod protocol setup overhead), bzr+ssh should be the same speed as bzr+http
<fullermd> Somewhat axiomatically, http should be slower than bzr+http by some non-zero factor; I think that factor is pretty small outside of very specific cases, though.
<abadger1999> Okay.  Sometime when I'm less busy I'll have to run some more in-depth tests.
<fullermd> Now, bzr+ssh is noticeably faster than sftp.  But that's mostly on writes (and the specific limitations of sftp in that realm), not reads, so that doesn't translate over to http.
<abadger1999> Okay.  And the initial checkout? (because of the tarball sending)
<fullermd> Too, there are the currently in-progress (and vaguely hoped for in 0.92) smart server improvements that should make a drastic improvement there, by making the smart server actually smart.  It's pretty dumb overall...
<fullermd> Well, when it kicks in, that should make the transfer bandwidth limited at the size of the repository.
<abadger1999> heh, my quick blog post is just to address someone who claimed that bzr branch awn (a project on lp) took 10 minutes.  So the smart server will definitely add another interesting number to the mix.
* Lo-lan-do gently pokes jelmer 
<abadger1999> Does anyone know what the scope of this warning in http_smart_server.txt is?
<abadger1999> **This feature is EXPERIMENTAL and is NOT SECURE.  It will allow access to
<abadger1999> arbitrary files on your server.**
<abadger1999> Does it refer to the particular configuration in the file or to limitations of running bzr+http at all?
<Peng> abadger1999: It's out-of-date.
<abadger1999> Even better :-)
<Peng> abadger1999: Personally, I'd like to know one of the developers went through the bzr+http code, but I'd be willing to use it.
<Peng> abadger1999: Tell me if you get it to work!
<abadger1999> Peng: Cool.  I'll be sure to mention it if I get it running!
<sabdfl> fullermd, abadger1999: there's also the history-horizon stuff, which should make "bzr branch" take about the same time as a tarball download of source snapshot without history
<sabdfl> i think that's post-1.0, though, so December+
<abadger1999> Nifty.  I didn't realize history horizon would improve performance.
<abadger1999> Does that mean that it doesn't download history unless it's necessary?
<fullermd> Well, in the degenerate case, it drops you to a equivalent 'checkout --lightweight' time.  Which doesn't really crank up spiffiness until the smart server gets rather smart.
<sabdfl> abadger1999: the idea is to make it do "asm much as it can" with the history it has availble
<sabdfl> so, bzr log would show the revisions it has
<sabdfl> you could fetch more revisions to do more
<sabdfl> merge would bring in just the revisions needed to do the merge
<abadger1999> Thanks for the explanation.
<schierbeck> phanatic: hi
<phanatic> hey schierbeck
<phanatic> i've just rolled out 0.91.0
<schierbeck> cool
<schierbeck> have you taken a look at the remove-date-column branch?
<dato> phanatic: cool, thanks
<phanatic> schierbeck: yep, but i think we should go with what GaryvdM suggested (allowing the user the select which columns s/he wants to see)
<phanatic> dato: yw :)
<schierbeck> phanatic: okay, is someone working on that atm?
<phanatic> i don't know if GaryvdM does, i hope he can answer that when he returns
<schierbeck> okay, i was just hoping we could've merged my branch first, and then worked on a more advanced solution later on
<jelmer> phanatic, congrats on your first release (-:
<schierbeck> phanatic: should i create a separate branch for the removal of the email part of the committer column?
<phanatic> jelmer: thanks :) i hope i haven't f'd up anything...
* Lo-lan-do spots jelmer 
<Lo-lan-do> Aha!
<phanatic> schierbeck: it's up to you
<jelmer> hey Lo-lan-do
<Lo-lan-do> jelmer: I'm sorry I was not online during the weekend, hope you weren't waiting for me
<schierbeck> phanatic: okay, i'll do that -- you'll merge it to trunk?
<jelmer> hey Lo-lan-do
<phanatic> schierbeck: sure, just send a mail about that to the list, so we can track them. and don't forget the NEWS entry. i had to hunt down at least 5 missing items before the release :)
<jelmer> bad timing for a client crash :-)
<Lo-lan-do> As I was saying: <Lo-lan-do> jelmer: I'm sorry I was not online during the weekend, hope you weren't waiting for me
<Lo-lan-do> (Hope you're not fleeing away from me :-)
<ubotu> New bug: #144522 in bzr "test suite fails" [Undecided,Fix committed]  https://launchpad.net/bugs/144522
<jelmer> Nah, was travelling
<Lo-lan-do> 'kay.  Did you have time to have a look at my pushing problem?
<schierbeck> phanatic: btw, do you want me to sign the commits?
<jelmer> Lo-lan-do: working on it atm
<Lo-lan-do> That's great!
<phanatic> schierbeck: it's not neccessary
<schierbeck> phanatic: screw it, i already did it
<schierbeck> :)
<phanatic> hehe :)
<phanatic> no problem
<phanatic> i hope it won't break anything
<phanatic> jelmer: could you update gnomefiles and freshmeat? i don't have access to those bzr-gtk pages
<schierbeck> phanatic: i'm thinking of adding some ui for displaying whether a commit has been signed, so i'm planting some data
<jelmer> phanatic, I'll add you to the list of maintainers of both
<phanatic> jelmer: thanks!
<phanatic> schierbeck: sounds cool :)
<schierbeck> okay, i've got to get something to eat now, see you guys later
<abadger1999> abentley: When you're around I have some trac-bzr patches.
<GaryvdM> phanatic, schierbeck: Hi
<GaryvdM> I'm not working on the columns selector currently.
<phanatic> GaryvdM: hey, thanks for the update
<jelmer> phanatic: I've added you on freshmeat
<GaryvdM> How is the release going?
<jelmer> phanatic, and you're now owner of bzr-gtk on gnomefiles.org
<phanatic> GaryvdM: 0.91.0 is out :)
<phanatic> jelmer: thank, updating those sites now...
<phanatic> thanks
<GaryvdM> Cool!
<phanatic> jelmer: freshmeat and gnomefiles updated
<lapthrick> oooh, jelmer, my favourite bzr-svn maintainer
<phanatic> schierbeck: subscribe to the list :P
<jelmer> hey lapthrick
<jelmer> phanatic, thanks!
<lapthrick> jelmer: did you have the time for bugfixing love perhaps?
<jelmer> lapthrick, I'm working on bzr-svn atm though on a different bug..
<lapthrick> I see
<jelmer> Lo-lan-do: can you try the pushing again
<jelmer> ?
<Lo-lan-do> Sure
<Lo-lan-do> http://paste.debian.net/37896
<lifeless> abadger1999: the warning is out of date, I believe it is less scary in bzr.dev
<abadger1999> lifeless: Great.
<corporate_cookie> dose anyone have a bzr RPM for RHEL4 ?
<lifeless> corporate_cookie: I'm not sure, however its really easy to run from source - just unpack it somewhere and add the dir to your path
<lifeless> corporate_cookie: as long as you have pythn2.4 or newer, the very core will simply work
<corporate_cookie> lifeless: I need an entry in my RPM database for some dependancy checking
<corporate_cookie> I've tried to roll my own ..but i'm getting some fun errors ...and I have no clue what they mean
<lifeless> corporate_cookie: oh
<abadger1999> corporate_cookie: Which python version is in RHEL4?
<lifeless> corporate_cookie: what sort of errors, ones from rpm ?
<abadger1999> corporate_cookie: python -c 'import sys; print sys.version'
<abadger1999> I was pretty sure it was 2.3 :-(
<jelmer> Lo-lan-do: thanks
<corporate_cookie> abadger1999: its 2.3
<corporate_cookie> however ..i have a parallel install of 2.4
<abadger1999> corporate_cookie: Ah.  Then I might be able to help (I build the Fedora and EPEL-5 bzr rpms)
<abadger1999> corporate_cookie: if you pastebin your errors and spec file I can take a look.
<schierbeck> phanatic: i thought i already was :) i've done it now
<phanatic> schierbeck: thanks. your previous mail will appear on the list as soon as we get moderation fixed :)
<schierbeck> phanatic: cool
<corporate_cookie> abadger1999: (managers always pick the best times to stop by and check in; pardon my slow responce)
<corporate_cookie> abadger1999:  im generating the spec ..and rpm with python2.4 setup.py bdist_rpm
<abadger1999> corporate_cookie: k.
<corporate_cookie> im pasting the full output
<corporate_cookie> http://pastebin.com/d37383707
<abadger1999> Hmm... it's unable to find generate_docs.py even though it's in the toplevel directory.
<corporate_cookie> abadger1999: is this a problem with the python install ?
<abadger1999> corporate_cookie: I don't think so.  I'm able to replicate it here with the vendor py2.5 install.
* Lo-lan-do starts hacking his DSL gateway
<Lo-lan-do> I'll probably blink for a while, but I'll definitely be back :-)
<abadger1999> corporate_cookie: Looks like it's a problem with distutils.
<lifeless> Lo-lan-do: good luck :)
<abadger1999> corporate_cookie: Let me see if I can get an old enough version of the bzr spec from Fedora that might work for you.
<corporate_cookie> thanks : )
<ubotu> New bug: #144300 in bzr "bzr log dies on more fancy revisionspecs with bzr-svn branches" [Medium,Triaged]  https://launchpad.net/bugs/144300
<Lo-lan-do> Back (yay for TCP timeouts being longer than the reboot time of a Soekris box)
<abadger1999> corporate_cookie: http://toshio.fedorapeople.org/bzr.spec
<corporate_cookie> woo hoo
<corporate_cookie> thanks abadger1999
<lifeless> bubg 144300
<abadger1999> corporate_cookie: Have you built an rpm from scratch before?
<lifeless> bug 144300
<ubotu> Launchpad bug 144300 in bzr-svn "bzr log dies on more fancy revisionspecs with bzr-svn branches" [Medium,Triaged]  https://launchpad.net/bugs/144300
<jelmer> looks like the ancestor: one is a bzr-svn related bug
<corporate_cookie> abadger1999:  I have ...but i must admit i've only done it aa few times
<jelmer> lifeless: but the branch: one is valid for bzr itself too
<lifeless> yah noticing that
<abadger1999> corporate_cookie: Okay.  If you have troubles using rpmbuild with that spec let me know and I'll try to work out what's going wrong.
<abadger1999> corporate_cookie: I don't have a rhel 4 box with python2.4 so I can't test it easily :-(
<fullermd> That kinda ties in with but 144421 I filed earlier.
<jelmer> lifeless: There's no "split" option for bugs in lp yet, right? I'll make a copy
<lifeless> bug 144300
<ubotu> Launchpad bug 144300 in bzr "bzr log -r branch|ancestor attempt to fetch data in a read only transaction" [High,Triaged]  https://launchpad.net/bugs/144300
<fullermd> Note that my testing was on stat, which fails with branch:.  Using 'diff' instead works, though.
<lifeless> another patch up :)
<lifeless> so jelmer, I'm curious why the new list
<AnMaster> http://pastebin.ca/709607
<AnMaster> shouldn't both report no such command?
<AnMaster> bzr should handle utf8 everywhere IMO
<jelmer> lifeless: doesn't require contributors to be on the high-volume bzr list, makes it easier to set up separate bundlebuggy, doesn't clutter the main list with bzr-gtk merge requests
<fullermd> AnMaster: Are you using a UTF-8 locale?
<AnMaster> fullermd, I am
<lifeless> jelmer: OTOH if most of our users use bzr-gtk as well, then until they get used to the other list your contributors won't see their questions
<AnMaster> sv_SE.UTF8
<lifeless> also slack folk like me with $ too many lists, will be lazy about joining the new list
<AnMaster> sv_SE.UTF-8 even
<fullermd> AnMaster: It DTRT's for me.  en_US.UTF-8.
<AnMaster> bzr 0.90
<jelmer> lifeless: There'll still be bzr-gtk folks like Szilveszter and me around to help with the occasional question on the main bzr list
<fullermd> bzr.dev and 0.91rc2.  I don't have 0.90 handy at the mom...  wait, maybe I do.
<fullermd> Yeah, works on 0.90 too.
<AnMaster> fullermd, system is freebsd
<fullermd> So're all mine.  I've got taste, after all   ;>
<AnMaster> it also fails on gentoo
<AnMaster> hm
<AnMaster> it fails on my 64-bit gentoo but not my 32-bit gentoo
<AnMaster> as for freebsd, it is 32-bit
<AnMaster> weird
<fullermd> Are you setting LANG, or some of the LC_*'s individually?
<AnMaster> fullermd, I'm setting LC_ALL
<AnMaster> LANG is set to C
<AnMaster> but, it is same on each
<AnMaster> fullermd, actually no it isn't
<jelmer> lifeless: also, two bundlebuggy's on one list doesn't work - at least not with the standard bundlebuggy and standard 'bzr send'
<AnMaster> fullermd, but well both gentoo got LC_COLLATE set to C as well
<AnMaster> and one of those worked
<AnMaster> so makes no sense
<fullermd> I've never tried mixing and matching.  I just have LANG=en_US.UTF-8 on my systems, LC_ALL stays blank, and the other LC_*'s follow it.
<fullermd> I get a headache every time I try to figure out more intricate setups and precedence   :|
<AnMaster> fullermd heh
<fullermd> But that's where I'd guess the problem is; it ends up seeing a 7-b ASCII encoding rather than a UTF-8 because of whatever vagary of interpretation of the mixing, on those systems.
<AnMaster> btw who should I complain to about trac-bzr?
<AnMaster> the trac ppl or you here?
<fullermd> Probably someone here.  Not sure who, though...   I think abentley did some work on it, but I don't know if he's currently looking at it.
<AnMaster> http://kuonet.org/~anmaster/envbot/trac/timeline <-- see two weird changesets at top
<lifeless> jelmer: re BB thats really just a bug :)
<AnMaster> also I get messages like:
<AnMaster> /usr/local/lib/python2.5/site-packages/TracBzr-0.2-py2.5.egg/tracbzr/backend.py:674: DeprecationWarning: bzrlib.revisiontree.RevisionTree.get_weave was deprecated in version 0.90.
<AnMaster>   weave = self.tree.get_weave(self.entry.file_id)
<lifeless> I don't like the idea that folk have to have a list to use BB properly.
<AnMaster> :/
<AnMaster> fullermd, ^
<AnMaster> bzr is 0.90
<AnMaster> trac and trac-bzr are last from ports on freebsd
<fullermd> Yeah, that would be a 'bzr API moving ahead, trac not keeping up' thing.
<AnMaster> fullermd, same for the broken changesets ?
<fullermd> Oh, I don't know trac or trac-bzr well enough to say, but it could be a suspicious coincidence.
<AnMaster> fullermd, also did bzr do a version jump, it seemd to be around 0.15 just some months ago then I turned my back for a few months and it is suddenly at 0.90
<AnMaster> ?
<lifeless> jelmer: for instance, one could give BB a submission address, rather than the list. Then BB mails the list as things come into it
<jelmer> lifeless: Yup, I agree. I don't think it's likely that support for determining whether a revision is relevant for a particular project is going to be added soon though and working with a separate list is much easier than adding such support.
<fullermd> bzr port is up to date.  trac-bzr is from March, though, so I dunno.  I don't have any involvement with the trac side...
<fullermd> AnMaster: Yes, it jumped from 0.18 to 0.90.
<AnMaster> fullermd, reason?
<lifeless> jelmer: This would be trivial, all you need is BB to forward the message rather than just linking to it.
<lifeless> much simpler than what you're talking about
<fullermd> AnMaster: Well, _I_ stick by the belief that it's a bit error in memory somewhere...     :p
<jelmer> lifeless: so you have to send merge requests to both the list /and/ bundlebuggy?
<lifeless> jelmer: no
<AnMaster> fullermd, and the official reason?
<jelmer> lifeless, that sounds more complicated than joining an additional mailing list
<fullermd> AnMaster: The theory behind it was to express some sense of progress toward 1.0.
<AnMaster> fullermd, anyway, I need to know who to complain to really about trac-bzr
<lifeless> jelmer: rather than --mail-to bazaar-at-blah, its --mail-to bundle-buggy
<jelmer> lifeless: that means the development process for bazaar would have to change as well
<jelmer> lifeless: otherwise bzr's bundlebuggy would pick up the bzr-gtk merge requests
<lifeless> jelmer: its a trivial change
<lifeless> and its not like we're static, we change what, monthly?
<fullermd> AnMaster: Well, you may have to bug Radim about it.  I'm not sure there are any 'official' releases; it looks like a snapshot that he rolled and hosts himself for the port.
<jelmer> lifeless, it requires all contributers to change how they work, docs on submitting merge requests to change, etc
<AnMaster> fullermd, who? *confused, just a user*
<fullermd> AnMaster: I'm not sure where the 'official' upstream is, to check if there are catchup changes.
<fullermd> AnMaster: The port maintainer.
<AnMaster> ah
<lifeless> jelmer: yes, I understand that.
<lifeless> AnMaster: we jumped to 0.90 because some people judge 'progress' by 'how close to MAJOR.0'
<AnMaster> fullermd, /usr/ports/www/trac-bzr/pkg-descr says http://bazaar-vcs.org/TracBzr
<lifeless> AnMaster: and while we were happy moving point release by point release, it wasn't clear to folk casually perusing, how mature a project this is.
<AnMaster> lifeless, ah
<lifeless> AnMaster: (we think its pretty mature)
<AnMaster> I always find a project that jumps versions like this suspect
<jelmer> lifeless: I think getting that changed would take a lot more time than setting up an additional list
<jelmer> lifeless: if you really feel having an additional list is a problem, please bring it up on the bazaar list
<lifeless> jelmer: I wasn't claiming it was a problem, I was asking why.
<fullermd> AnMaster: Well, there aren't any fixed for that sort of problem on Aaron's branch; there's hardly anything recently.  I'm not sure if someone else's is the "main" branch now.  You could try asking on the list.
<lifeless> it surprised me is all, and it makes more work for me
<fullermd> (fixes)
<AnMaster> fullermd, what list? not mailing list I hope, I hate mailing lists
<lifeless> jelmer: so enough said, nothing to see here, moving right along
<fullermd> AnMaster: Oh.  Well, forget I said anything, and poke Radim them   :] 
<AnMaster> fullermd, and where do I get hold of him?
<fullermd> cd /usr/ports/www/trac-bzr/ && make -V MAINTAINER
<AnMaster> ah
<lifeless> phanatic: good to see you around again ;)
<abadger1999> AnMaster: I have patches to make those changesets slightly less wierd.
<AnMaster> abadger1999, oh?
<abadger1999> AnMaster: Let me dig up the launchpad bug
<AnMaster> :)
<fullermd> Oh good!
<abadger1999> AnMaster: https://bugs.launchpad.net/trac-bzr/+bug/116659
<ubotu> Launchpad bug 116659 in trac-bzr "Phantom changesets in timeline" [Undecided,Confirmed] 
* fullermd pawns off the trac issues on abadger1999 and runs away while he can.
<abadger1999> I've been working on the assumption that abentley's branch is canonical.
<AnMaster> abadger1999, hm
<phanatic> lifeless: thanks, but actually reviewing patches and managing a release takes more time than just hacking :)
<AnMaster> I think I will mail ports maintainer either way
<AnMaster> so everyone can make use of it
<abadger1999> yeah.  It would be good.
<fullermd> Hm.
<fullermd> hsn_: Around?
<lifeless> phanatic: indeed it does
<hsn_> fullermd: yes
<fullermd> hsn_: Oh good.  See above discussion about trac-bzr port compatibility with current bzr.
<fullermd> Quicker than email   :] 
<jelmer> lifeless: Sorry, you said it takes more time for you, that's why I figured you considered it a problem. Anyhow, I'll let it rest.
<AnMaster> abadger1999, sent mail to trac-bzr maintainer
<abadger1999> AnMaster: Cool -- I think hsn_ is that maintainer :-)
<AnMaster> abadger1999, sent it to output of that command fullermd gave me
<AnMaster> but yes hsn was in the mail
<hsn_> abadger1999: you think right
<AnMaster> hsn_, got my mail right?
<lifeless> jelmer: it does, but I patch bzr-gtk what, once a month? If that? So I'll ignore it until my next patch, if its more convenient for the folk doing the coding that is the important thing.
<AnMaster> yet*
<AnMaster> btw, does source forge support bzr? I don't really like launchpad, it is slower than sourceforge even (and that is pretty slow) and it looks ubuntu-ish, and is confusing
<fullermd> In theory, you could just host the bzr files in project webspace.  I suspect it's probably at least moderately frowned on, though.
<dato> AnMaster: bzr can be served over a normal http server, so there you go
<abadger1999> hsn_: Cool. I'm packaging trac-bzr for fedora so if we need to work on standardizing on someone's branch as canonical or cooperating on getting bugs fixed feel free to ping me.
<AnMaster> dato, hm true
<AnMaster> dato, but does pycurl fail at bzr branch http://kuonet.org/~anmaster/bzr/envbot for anyone but me
<AnMaster> some users reported problems
<AnMaster> lighttpd on freebsd
<fullermd> SF is probably better connected (depending on where you are).  A lot of the slowness may be just bzr, though...
<AnMaster> it works with urllib
<AnMaster> fullermd, yes pushing almost half a minute to my current web server
<jelmer> lifeless: But why is it more work? subscribing takes less than a minute
<AnMaster> but anyway, why is pycurl broken for that site
<lifeless> jelmer: subscribing, managing the mail to a new folder, remembering to check that folder, remembering to send to a different list, moving discussion cross-list as needed
<fullermd> AnMaster: Hard to say, probably.  pycurl will probably have somewhat different characteristics (request rate and accel, number pipelined, number keepalive'd, blah blah) than urllib.  What about it is significant, though..
<AnMaster> fullermd, a user who did some debugging said it somehow borked with certain range requests
<lifeless> hmm
<lifeless> perhaps we should make disabling pycurl easy without uninstalling it
<lifeless> vila: ^ ?
<fullermd> I thought we had a discussion just last month-ish about turning off default-enable-if-found on it, and just saving it for explicit http+pycurl
<lifeless> AnMaster: we've had a bunch of issues with lighthttpd IIRC
<lifeless> fullermd: sounds vaguely familiar
<lifeless> AnMaster: or some http server, sending bad range responses
<lifeless> failing to serve our requests ok
<lifeless> and this forces us to fallback to slower means
<lifeless> or error
<lifeless> bbiab
* fullermd also passes the buck to vila.
<AnMaster> lifeless, ah
<AnMaster> lifeless, for now I tell my users to use http+urllib://...
<fullermd> I think in the current state, urllib is generally preferable anyway, so you don't lose much that way.
<AnMaster> hsn_, so, how long can it take to get a fixed version into ports? :)
<hsn_> AnMaster: if you submit patch, it can be quite fast
<AnMaster> hsn_, I sent a link to the patch yes in my mail to the maintainer
<AnMaster> :)
<AnMaster> and that was you
<hsn_> did you tested patch?
<AnMaster> hsn_, not yet I sent a link to the bug report to be exact
<AnMaster> but I will test in a bit
<AnMaster> once I find out how to patch this in the correct way to test it
<hsn_> ok. test it and report it back to me
<AnMaster> I don't know, should I edit the port?
<hsn_> yes, edit port
<AnMaster> hsn_, or how to do it without making package manager loose track?
<AnMaster> hsn_, um, and what with portsnap do then?
<hsn_> put patch in files/ directory
<fullermd> AnMaster: Copy the port dir somewhere else (in /tmp, say) and work on it there.  It doesn't have to be under /usr/ports to work.
<hsn_> recompile port, test, install porttools and do port submit
<AnMaster> fullermd, oh? cool
<fullermd> Then you can diff against the 'main' one to gen the patch.
<AnMaster> hsn_, hm
<fullermd> 's how I do it (actually, I cvs co from my local CVS mirror in /tmp, but 6 of one, half a dozen of the other...  either way)
<AnMaster> hsn_, um, I got to sleep now, it is late here
<AnMaster> I will do it tomorrow
<mgedmin> I can't use bzr diff to look at my changes while I'm editing the commit message for bzr ci?
<jelmer> phanastic: ok, pqm is up at http://145.97.196.157:8089/
<james_w> mgedmin: no you can't I'm afraid. With 0.91 you can use bzr ci --show-diff to get the diff in the message editor.
* mgedmin weeps
#bzr 2007-09-25
<poolie> hello
<igc> morning
<mgedmin> when I bzr push a branch to my webserver with bzr+ssh://, how can I tell it to create an up-to-date working tree as well?
<poolie> mgedmin, hi,
<poolie> i'm not 100% sure this will work, but have you tried running 'bzr checkout' on that location?
* mgedmin finds a description in 'bzr help working-trees'
<mgedmin> yes, bzr checkout . works, but bzr's help tells me I will have to manually ssh into the server and run bzr update in that directory after every push
<mgedmin> (or look for some plugins to automate that)
<igc> bbiab
<lifeless> mgedmin: there is a plugin that will invoke update for you on the remote server
<poolie> spiv, do you see the new bug about ^c in the smartserver?
* spiv looks
<igc> lifeless: Assuming packs contain plain knits, how often are we expecting to be joining a plain knit source to an annotated knit target?
<lifeless> igc: when we export a pack branch for a knit user
<lifeless> igc: its ok for it to be slow if thats your concern
<igc> yes it was
<igc> so command wise, we're talking pull or branch right?
<lifeless> push
<lifeless> and pull
<lifeless> and in rare cases upgrade
<igc> thanks
<lifeless> its not ideal for it to be slow, but its tolerable
<ubotu> New bug: #144627 in bzr "TooManyConcurrentRequests raised when bzr+ssh push is interrupted" [Undecided,New]  https://launchpad.net/bugs/144627
<lifeless> do you see why your logic was flawed ?
<igc> yes
<lifeless> cool
<lifeless> jelmer: oh btw, did you want to use the bzr pqm? pqm is totally happy to have multiple projects...
<lifeless> poolie: the index change in your branch - shoot that to bzr.dev directly please
<poolie> lifeless,  the docstrings? i thought i did
<lifeless> the __repr__
<lifeless> I'm just checking for performance regressions in your patch [unlikely but needs to be done] 
<ubotu> New bug: #144633 in bzr "KeyError for BzrCheckError.message" [Medium,In progress]  https://launchpad.net/bugs/144633
<poolie> lifeless, cherrypicking addition of a repr is not going to be very high on my list
<poolie> unless you particularly want it in main
<lifeless> I'll do it then
<lifeless> I want nothing in my branch
<lifeless> thats where I'm heading, and thats clearly 'done' as a piece of code, so no reason not to get it into bzr.dev
<lifeless> ok its on its way
<lifeless> poolie: your patch is about 1/2 second slower consistently
<lifeless> poolie: I haven't tracked it down yet
<poolie> which one?
<lifeless> I just merged from pack-repository
<poolie> i'm glad you checked then
* poolie reads bialix's second win32 patch
<lifeless> poolie: did you find all tests passing ?
<lifeless> poolie: one thing I'm having some trouble telling with your patch is if it causes more index instances to be created
<lifeless> I think it doesn't
<poolie> will just finish this review then look
<poolie> spiv, rise and shine :)
<spiv> poolie: I'm here :P
<poolie> :)
<Verterok> moin
<poolie> Verterok, hi
<poolie> lifeless, so do you know if there's a problem with that patch, or do you want me to look at it?
<lifeless> poolie: I've merged it
<poolie> there's no performance problem?
<lifeless> its within the noise factor
<lifeless> it looked 1/2 sec higher, but its possibly just noise
<lifeless> there *may* be an issue with new indices being made when we should use existing ones, but its not showing up on incremental commit, and I alread knew of latent issues there
<abentley> I hate the way everyone just assumes everything's on Launchpad.
<abentley> Today I found out that people have been filing bugs on my branch of trac+bzr for months now.
<abentley> With no one bothering to tell me about it.
<lifeless> igc: ping
<igc> hi lifeless
<lifeless> abentley: there is a flag to tell lp if it should consider itself to be the bug tracker
<lifeless> abentley: or not. Is that set for bzr-trac ?
<abentley> How was I supposed to know trac+bzr was even in Launchpad?
<lifeless> igc: I replied to your review of moving weave code out; did you re-reply ?
<lifeless> abentley: oh hmm, thats a tougher one to answer :)
<poolie> abentley, that is a good question
* igc checks 
<poolie> however, it's supposed to  make it hard for people to file bugs if it's not approved by the owner
<poolie> if someone else claimed to be the owner though...
<lifeless> igc: cause I'd like to merge it :)
<igc> I'm yet to reply ...
<igc> we can cover it now if you like (i.e. here)
<lifeless> please
<igc> assume the first issue isn't ...
<igc> i.e. the duplication is ok
<abentley> Looks like Yann Houdique registered it way back when.
<igc> I'd like the get_revision_graph API back there with just a docstring ...
<igc> relying just on interface tests feels ...
<igc> a bit of a stretch :-)
* igc looks ar 2nd issue again
<igc> lifeless: I'm ok with the 2nd explanations as well, altohugh it might to good to put a comment in to that effect in the ...
<igc> _get_revisions() method for weaves say.
<igc> that's it ...
<lifeless> igc: there is a comment there.
<lifeless> igc: that was my point on the second one :)
<igc> do you want an email summarising that?
<lifeless> igc: AIUI its 'put a stub NotImplemented get_revision_graph method on the base class'
<igc> yep
<lifeless> igc: I think I can get by without a mail :)
<igc> lifeless: that comment I was asking for ...
<igc> looking again, putting it in _get_revisions in repository.py would be good because ...
<igc> right now, the docstring says "without sanity checks" and ...
<igc> you then proceed to do some I think?
<lifeless> igc: mmm
<lifeless> its checked for being a revision id or not
<lifeless> but the results are not checked for sanity
<poolie> abentley, i suggest what you do now, if you haven't already, is claim the project and then tell it bugs are not tracked in lp
<poolie> unless in fact you do want to track them there
<abentley> Yeah, I might track it there.
<abentley> But in fact, I wasn't aware that anyone even cared about trac+bzr
<lifeless> abentley: its one of the first questions people at conferences put to me
<lifeless> 'its written in python, cool. Does it integrate with trac?'
<abentley> Well, my answer would be "Kinda.  For it to integrate properly, either Trac or Bazaar would have to change architectures"
<lifeless> thats true
<lifeless> I usually just say 'there is a plugin for trac, but I don't have personal experience with it'
<poolie> i'm going to take a lunch break
<poolie> biab
<lifeless> good idea
<cory> I installed trac+bzr at one point out of curiosity.  What sort of differences are you saying are really irreconcilable?
<abentley> They want to know what was the last-modifying revision of a directory, even for directories that aren't even branches.
<abentley> That's the sort of thing.
<abadger1999> Oh cool.  It's an abentley and he's talking trac+bzr stuff ;-)
<cory> Yeah, that sort of thing doesn't really bother me, either because I expect it could be reasonably easily made optional in trac or omitted/lied about by trac+bzr when it's difficult/impossible to get.
<abentley> Yeah, but people bitch about the lie.
<cory> :)
<jelmer> lifeless: Yes, it would be very nice if we could use the bzr pqm.
<abentley> Seriously.  Look in Launchpad, and you'll see people filing bugs about the null: and current: revisions, even though they're documented in the README.
<lifeless> jelmer: Cool. Can you mail me a list of initial committers, and the build rule you want executed, plus where the writable location for the main trunk is (we could put that on bazaar-vcs.org if you like, I don't think poolie would object)
<abadger1999> heh, abentley I commented on that bug and added a patch to make them slightly better.
<abentley> abadger1999: if you look at the scrollback, you'll see that I was not aware that any launchpad activity was taking place.
<abadger1999> Yep.  I saw that.
<poolie> lifeless, np here
<abadger1999> I was looking for you earlier to ping you about it.
* igc food
<abentley> abadger1999: Sorry, I've been busy.
<jelmer> lifeless: ok
<abadger1999> No problems, I fugred you were.
<abentley> So what did you want me to look at?
<abadger1999> with the current: and null: changesets, I had two issues.
<abadger1999> the important one is that they're messing up the trac timeline RSS feed.
<abadger1999> Since it uses time.time() as its timestamp, everytime an RSS reader looks at it, it thinks there's a new entry when it's just current: re-occurring.
<abadger1999> I added a patch to the lp bug to have it use the same timestamp as the last revision.
<abentley> That's bogus.  This is why Atom has unique identifiers for postings.
<abentley> Why not go the whole way and use the last revision instead of current:?  And how much performance degradation did you see?
<abadger1999> I'm subscrbing to the feed via mugshot.
<abadger1999> So all the fedora developers were getting popups saying that there was new activity every time mugshot polled the RSS feed for the timeline.
<abentley> Well, if RSS has unique IDS, that's bogus.  If it doesn't, you should be using Atom.  But my main concern about getting rid of current is the performance cost of determining the last-modified revision.
<lifeless> we could build a cache
<abadger1999> Looking at the RSS feed, I don't see any ID :-(
<lifeless> annotate each dir by whether paths under it changed
<abadger1999> Do you know how to get trac to serve atom?  ?format=atom doesn't do it.
<lifeless> build a dict {revid:{dirid:changed_revision}}
<abentley> Sure, but then you've got to do invalidation and stuff.
<abentley> Which seems just as espensive as not having a cache.
<lifeless> abentley: no invalidation really, its static for a given revision
<lifeless> abentley: I was not proposing this for bzr itself btw
<cory> Hmm?  I see a guid, but it looks like it has a timestamp on the end...
<abentley> I'm talking about running trac against a repository with hundreds of branches.
<lifeless> abentley: long term we should make answering the question cheaper; this is a proposal for the trac plugin to work with
<abentley> I'm not talking about the issue of last-modified-revision for versioned directories.
<lifeless> oh, perhaps I am confused
<abentley> I'm talking about last-modified-revision for unversioned directories.
<abadger1999> cory: Right
<lifeless> abentley: *blink*, is there such a thing?
<abentley> For Trac's benefit, we pretend there is.
<lifeless> so any dir whether it exists or not ?
<abentley> Not "whether it exists or not"-- whether it exists as part of a versioned tree, or is used for layout in the repository.
<lifeless> ah I get you
<lifeless> so reporoot
<lifeless> reporoot/project
<lifeless> reporoot/project/branch1
<lifeless> noth reporoot and reporoot/project are given a 'last modified'
<lifeless> s/noth/both/
<abentley> Given the path a/b/c, 'a' may be a plain directory.  Its last-revision is 'current:'  'b' is a branch directory.  Its last revision can be the branch last revision.  'c' is a versioned directory, and is not physically present in the repo, just referred to by 'b'
<abentley> lifeless: Right.
<lifeless> so the 'corect' last modification needs to move forward when any branch under an unversioned dir has its tip change
<abentley> Yes, you could do it that way in theory.
<lifeless> fraught with holes doing it on push etc
<lifeless> just trying to understand the 'definition'
<lifeless> I see what you mean about the model mismatch
<abentley> Yeah.
<abentley> So now we have to define 'latest'.
<abentley> We can't use the ancestry, because the branches may be unrelated.  Do we use the revision timestamp?  The time the tip was modified?
<lifeless> what about stat of the dir ?
<cory> This is vaguely relevant: http://trac.edgewall.org/wiki/VcRefactoring#SupportforMultipleRepositories
<cory> At least just as confirmation that they might work on refactoring things for things structured like bzr.
<abentley> lifeless: I don't think that helps.
<abentley> Because if we're trying to find the latest revision, we must examine branches, not the directories containing them.
<lifeless> if we accept that there is no well defined value
<lifeless> then we can just show a fake commit, no message other than 'last modified on xxx' etc
<abadger1999> Right.  I don't mind the lie, I just want the lie to remain the same between real commits.
<abentley> Because trac does recursive comparisons, I don't know if that would work.
<lifeless> using the dir stat would mean that adding a new branch or removing one would change the date
<abentley> It could make the directory look like its contained directories weren't changing.
<abentley> (except when branches were added or deleted)
<lifeless> a commit id of date:secondssinceepoch
<lifeless> might be a half-decent way to represent this
<abentley> abadger1999: I think it could be harmful if the lie *didn't* change when commits happened.  Which is I believe what lifeless is proposing.
<abadger1999> That would be more confusing than now, true.
<abadger1999> abentley: Is the current ancestry of current: to be trusted?  ie: bzr_repo.previous_rev('current:')
<abentley> I believe so.
<abentley> Been months since I looked at the code though.
<igc> lifeless: a question about converting deltas between annotated and plain knits ...
<lifeless> sure
<abadger1999> abentley: k.  My patch takes the timestamp of that rev and applies it to current:
<igc> parse_linedelta returns something different to what ...
<igc> lower_line_delta accepts ...
<igc> it's works within ann-to-ann or plain-to-plain but ...
<igc> not across the two
<lifeless> ah yes
<lifeless> thats my fault, I specialised it somewhat
<igc> I'm concerned about ...
<igc> changing that because it will impact ...
<igc> perforamnce undoubtedly
<igc> should I change it?
<lifeless> so don't change it
<abentley> abadger1999: So that means you potentially have multiple timestamps for current
<lifeless> write a converter
<abentley> Actually, no, I guess not.
<igc> sure
<abentley> You just don't have per-directory accuracy on that timestamp.
<abadger1999> Yeah. It's definitely a lie.
<lifeless> bbiab
<lifeless> igc: ring me if you need more info/discussion - going for lunch
<igc> ok
<abentley> abadger1999: So the problem is that bzr_repo.previous_rev('current:') can be quite expensive.
<abentley> Theoretically less so for branch format 6.
<abentley> (aka dirstate-tags)
<abadger1999> abentley: hmmm.... is bzr_repo.previous_rev() expensive in general or only when finding for 'current:'?
<abentley> It's certainly more expensive for current:.  It might not be cheap normally, either.
<abentley> For current, it means scanning every branch in the repository.
<abentley> I'm off to bed.
<abadger1999> 'night.
<abadger1999> Interesting.  I think previous_rev() loads the history for the entire repo whenever it's called (unless history has previously been cached)
<lifeless> abadger1999: knits have no partial index facility
<lifeless> abadger1999: so accessing one revision loads the index of all revisions
<abadger1999> Ah.
<lifeless> igc: I've reinstated the stat cache on packs
<lifeless> igc: 4 second hit on initial commit (for now), but 10 second win on incremental commit
<igc> awesome!
<igc> I'll take the 10 sec win on incremental :-)
<lifeless> pfft
<lifeless> I figure that we don't need the stat cache when the fileid is new
<lifeless> so I'm going to add a special case for no_parents, passed into path_content_summary
<igc> sounds good
<lifeless> should take it back to 1m20
<lifeless> and keep the 10 second win
<lifeless> so I now have 5 patches send in today
<lifeless> *sent*
<lifeless> (and not reviewed)
<igc> I'm getting there - just sending mine to the ML now
<igc> sent
<vila> I intent to review the transport put related one
<igc> I'll swap you - one review for >1 reviews :-)
<vila> and hi all
<igc> hi vila
<vila> igc: np, if you take in your swap the project delivery I must do today ;P
<lifeless> igc: 1:M
<vila> about pycurl/urllib, what about making urllib the default for http and pycurl the default for https ?
<vila> I'm a bit hesitant about it for coherence reasons, but on the other hand, we had many reports recently where pycurl failed were urllib worked...
<vila> and I don't like dropping cretificate verification for https
<lifeless> cretans eh?
<vila> lol
<vila> yeah, better than greeks :)
<igc> lifeless: I'll do the path_content_summary review now unless you want a different one done 1st
<lifeless> any order is fine
<lifeless> igc: reviewed
<igc> thanks
<lifeless> igc: basically good; but you missed a large body of duplicate code in the tests
<igc> ok
<lifeless> if you move the assertions into your helper and rename it, you'll be good to go
<igc> np
<lifeless> igc: I've mailed you my current uncommitted-cause-its-experimental changes
<lifeless> if you want to see how it performs on real hardware
<igc> got those
<lifeless> bbiab
<poolie> thanks for the review
<lifeless> me?
<vila> lifeless, poolie: looks like I'm 7 hours late to review the transport.put_file patch :-)
<lifeless> vila: is it ok?
<poolie> is there a problem with it?
<lifeless> vila: or would you like it changed?
<poolie> lifeless, yes, you
<vila> lifeless: no, at first read it's ok, it will break webdav again, but it's mentionned in NEWS (for other transport implementors) and land sufficiently early to be taken into account
<Stevage> hello
<Stevage> can anyone help me get TortoiseBZR to work?
<Stevage> It compiles, but it doesn't seem to create any icons
<Stevage> it does create shell extensions though - but they don't do much, and the 'diff' command seems broken
<matkor> Stevage: pls fill bug report
<matkor> but I have not seen much work recently in that area ...
<Stevage> hmm
<Stevage> pity
<Stevage> I'd love to have tortoisebzr going
<matkor> so fill bugreport and keep presure on developers ;)
<poolie> Stevage, alexander haro is the developer
<igc> lifeless: ping
<Stevage> yeah just reading the README
<Stevage> I don't see that I installed it wrong, so I don't get it
<poolie> suggest you cc him on your mail to get his attention
<Stevage> also I think most of the shell extensions didn't appear
<Stevage> what's his email?
<poolie> amduser29 at gmail
<Stevage> ta
<Stevage> hmm
<Stevage> it seems to be trying to find some method called CommitCommand
<Stevage> which doesn't exist in bzr.dev/bzrlib
<Stevage> has bzr been radically reorganised recently?
<igc> no
<igc> perhaps that's a method in a plugin?
<Stevage> oh no, maybe I'm just confused
<Stevage> yeah it is
<Stevage> there's a CommitCommand.py
<Stevage> I don't know why it can't find it
<igc> :-)
<Stevage> (I don't really speak python)
<Stevage>         command_mod = __import__('commands', globals(), locals(), [command_filename] )
<Stevage>         command_mod = getattr(command_mod, command_filename)
<Stevage>         command_class = getattr(command_mod, command_filename)
<Stevage> one of those is failing
<Stevage> command_filename is "CommitCommand"
<poolie> that seems a bit strange...
<poolie> can you put the traceback in a  pastebin?
<Stevage> ok it's the first line
<Stevage> there's no traceback
<Stevage> it's just an exception
<Stevage> um
<Stevage> maybe that's nonsensical
<lifeless> igc: yo
<Stevage> I don't know how to get debugging output from it
<igc> in the tests, where does the size "22" come from?
<Stevage> those three lines of code above look pretty weird to me though
<Stevage> especially #2 and #3
<lifeless> igc: which test
<igc> test_file_content_summary_executable
<lifeless> oh, thats the number of bytes in the file
<lifeless> the content is generated by build tree - 'contents of path\n' IIRC
<igc> ok - thanks
<igc> not that easy to follow that in the code
<igc> got it now
<ubotu> New bug: #144693 in bzr "remove {Branch,Tree}.print_file" [Low,Confirmed]  https://launchpad.net/bugs/144693
<Lo-lan-do> Hmpf.
* Lo-lan-do gets bitten again
<Lo-lan-do> Is there a way of having "bzr status" display paths relative to the current directory?
<matkor> What is network usage in bzr over sftp comparing to rsync over ssh ? More or less ?
<Lo-lan-do> It currently shows, f'rinstance, "foo/bar.txt" even when I'm in foo/
<matkor> I mean doing rsync local remote vs  bzr commit local, bzr push remote ?
<Lo-lan-do> So "bzr add foo/bar.txt" (cut and paste) fails
<igc> lifeless: that review sent to the list now fyi
<igc> that knit join patch merged to bzr.dev now too
<matkor> I have org-branch and branched from it modified-branch... now I want cherrypick some changes from modified-branch (I know which revisions) back to org-branch, what is easies way to do it ?
<pbor> hi
<pbor> not sure if it is on topic here, but if I branch from a launchpad import, will I be able to then push to the upstream svn repo with bzr-svn?
* pbor tried to to a local branch directly from the svn repo but it totally killed my machine... it required 1,5 gigs of mem
* igc food
<pbor> mmm... I now realize that launchpad import is totatlly stale anyway, so nothing useful :/
<lifeless> igc: thanks
<mwh> pbor: no, launchpad imports are different from bzr-svn imports
<mwh> pbor: which import is it?  i can try to find out why it's stale
<pbor> mwh: gedit
<mwh> oh oops, that's still importing from anoncvs.gnome.org
<pbor> mwh: just out of curiosity, how do launchpad imports and bzr-svn imports differ?
<mwh> well, the glib answer is that they are created by different pieces of software :)
<mwh> (launchpad imports are done by cscvs)
<mwh> more technically, launchpad imports have random revids and bzr-svn imports have deterministic ones
<pbor> okay
<mwh> so if you run a cscvs import twice you'll get (as far as bazaar can tell) different histories
<mwh> there are different trade offs
<mwh> (roughtly speaking what bzr-svn does is harder and much more of a commitment in some ways)
<pbor> mwh: btw, looks like this is my problem with yesterday's import https://bugs.launchpad.net/bzr-svn/+bug/54253
<ubotu> Launchpad bug 54253 in bzr-svn "Excessive memory usage in bzr-svn" [Undecided,Confirmed] 
<mwh> you can often get away with killing the process and having it resume from some point
<mwh> current thinking on that bug is that it's a problem in the python-svn bindings i think
<pbor> mwh: how do I resume?
<mwh> what stage had it got to when you killed it?
<pbor> no idea, I had to hard reboot :/
<mwh> ugh
<lifeless> pbor: rather than doing bzr branch, do 'bzr init --dirstate-with-subtree', then do 'bzr pull svn://'...
<pbor> lifeless: what does that give me?
<lifeless> if you hit ctrl-c
<lifeless> just do 'bzr pull svn://' again
<lifeless> and it will resume
<pbor> ah
<lifeless> mwh: you might like to start dogfooding packs for codeview; we're closing in on a first release of it in the next week or two
<lifeless> mwh: if it sucks for you, *now* is the time to hear.
<jrydberg_> lifeless: what's the status of packs?
<lifeless> mwh: there's two known issues may affect you; annotations will be no longer cheap in the first release (plain-knits always, and no cache implemented yet). Secondly partial index reading has not landed yet.
<lifeless> jrydberg_: good.
<lifeless> jrydberg_: initial commit is nice and fast :)
<jrydberg_> lifeless: what about push and pull?
<lifeless> initial push runs about 20% slower than rsync
<lifeless> ditto pull
<lifeless> needless to say this is hugely faster than knits.
<jrydberg_> how about incrimental updates?
<lifeless> they are ok, but not great because the text indices are read entirely still, and they are much larger than the individual indices that knit repos have
<lifeless> so we're reading more index data
<lifeless> though there is plenty of room to optimise that even before partial index reads come in
<lifeless> we don't do ghost filling automatically in packs
<lifeless> so we can examine just incremental data, and thats in the most recent (and smallest) packs, so checking them first for content will usually be a win
<mwh> lifeless: makes sense
<jrydberg_> lifeless: i see
<mwh> lifeless: can i get a bzr.dev
<mwh> lifeless: can i get bzr.dev in packs somewhere?
<lifeless> fwiw, by nice and fast on initial commit, its 1m30 wall clock for me in my latest not-quite-committed stuff; thats the same as hg on this machine (well actually a little faster)
<lifeless> mwh: yes; see my dogfooding emails to the list
<mwh> lifeless: subject?
<jrydberg_> lifeless: why do we have so large indexes then?  can't we have a pack-index, and then have per-pack indeces (either as a separate file, or in the pack header) ?
<lifeless> jrydberg_: thats what we have
<lifeless> jrydberg_: its just that rather than N knit indices
<lifeless> where N is the number of file ids
<jrydberg_> lifeless: well, the pack index doens't have to be that big, does it?
<jrydberg_> pack: <contained revisions>
<lifeless> we have one text index per pack, which has the data for all N fileids-versions in that pack
<lifeless> jrydberg_: we limit the number of packs to prevent latency explosion due to one pack per commit, which would be going back to the arch days
<jrydberg_> so you're doing auto repacking, is what you're saying?
<lifeless> yes
<lifeless> so the text index size is not excessive, its smaller than the combined .kndx files
<lifeless> its just that we're reading more than we need to
<jrydberg_> when i was experimenting with a blob-like format, i did the repacking on incrimental updates (push or pull)
<lifeless> how far did you get; what conclusions did you draw?
<jrydberg_> the only conclusion i came to was that it was often smarter to fetch a bit more data, if the data is grouped in a fetch-frendly way, than to do all kind of smart stuff on the client side to minimize the amout of data to fetch
<jrydberg_> but that isn't really rocket science
<lifeless> yeah
<lifeless> latency hurts
<lifeless> small reads often increase latency
<jrydberg_> i also experimented with using already defined container formats
<jrydberg_> such as each blob being a .zip
<jrydberg_> but the zip-format is kinda borked
<lifeless> jrydberg_: 7z might have been reasonable
<lifeless> jrydberg_: but being able to controll index locality of reference seemed quite important to me
<lifeless> to make client reads more effective without insanely complex logic on the read size
<jrydberg_> mmm
<lifeless> jrydberg_: the current index doesn't do this, but the one in development by keir does
<lifeless> it groups nodes by the graph, giving graph walking with less roundtrips (and roundtrips are our biggest problem)
<lifeless> jrydberg_: packs are still knit delta based
<lifeless> jrydberg_: please, dogfood :)
<jrydberg_> hehe
<jrydberg_> how many files are fetched before the actual pack-data is started to be brought in?
<lifeless> jrydberg_: well, theres .bzr/format, .bzr/repository/format
<lifeless> jrydberg_: then .bzr/repository/pack-names (the index of packs)
<lifeless> jrydberg_: I'm out for the night I think
<jrydberg_> you need to figure out the head of the branch too?
<lifeless> jrydberg_: well depends on the operation you're doing; if you need a branch info its .bzr/branch/format and .bzr/branch/somethingorother
<lifeless> ciao
<mwh> hm
<mwh> ../bzr/pack-repository.knits/bzr get http://people.ubuntu.com/~robertc/baz2.0/repository
<mwh> seems to be doing an awful lot of nothing
<lifeless> mwh: I've just updated the pack-repository.knits branch FWIW
<lifeless> mwh: there is no progress bar at the moment
<mwh> lifeless: oh
<mwh> that was probably it then
<lifeless> ciao, for real
<mwh> does keir irc?
<sabdfl> hey revisionistas
<Peng> Good morning!
* Peng goes to bed.
<sabdfl> night pe
<sabdfl> ng
<Peng> :D
<ignas> hi
<ignas> is there a way to make bzr display relative paths for bzr st?
<dato> not at the moment
<matkor> How bzr handles soft links ? /branch-root/link-to-dir-out-of-branch ?  Will link-to-dir-out-of-branch be threated as subdir and versioned ?
<mwh> the symlink will be versioned
<matkor> mwh: No way to force bzr to version contents of symlink not symlink itself ?
<mwh> not that i know of
<mwh> AfC: hi, are you involved in the gnome-java bindings?
<lifeless> matkor: we do version the contents - the thing pointed at
<lifeless> matkor: I think you'd need to give us some use cases, help us design what you'r interested in bzr doing, for us to help you get bzr to do it
<lifeless> mwh: ping
<mwh> lifeless: hi there
<lifeless> did you get a pack error ?
<mwh> lifeless: yes i dud
<mwh> did
<lifeless> with the latest branch ?
<mwh> yes
<lifeless> ok
<lifeless> try this
<lifeless> bzr init --experimental
<lifeless> bzr pull /path/to/your/knit/based/bzr.dev
<lifeless> bzr push ../newpath
<lifeless> (this should make a fresh packs repo locally and clone it to a second fresh packs repo
<mwh> 'bzr' here being my pack-repository.knits tip ?
<lifeless> yes
<mwh> ok
<lifeless> revno 2783
<mwh> that's what i have
<lifeless> yay
<mwh> ok, it's running
<lifeless> igc's patch has landed, time for the next pack format change tomorrow
<lifeless> if this works I probably have something weird in my repo
<lifeless> would not surprise me :)
<lifeless> how did it go ?
<abentley> Hey, when the going gets weird, the weird turn pro.
<lifeless> abentley: :)
<lifeless> abentley: Are you comfortable with packs being cached-annotation-less in their first iteration ?
<lifeless> I am, though more from necessity than desire.
<mwh> lifeless: first pull completed
<lifeless> mwh: ok, you now should have a .bzr/packs/*
<lifeless> mwh: with one pack in it
<mwh> (i'm on my powerbook this week, slooooow)
<mwh> lifeless: .bzr/repository/packs ?
<lifeless> yes
<mwh> ok, then yes
<lifeless> I am asleep
<lifeless> this is a ghost typing
<mwh> noted
<lifeless> mwh: so, try a push
<mwh> trying
<lifeless> it should be a) successful, and b) pleasantly faster
<abentley> lifeless: As something we release?  Seems like they couldn't be default if they had a performance regression like that.  But an optional format for those who understood the tradeoffs would be okay.
<lifeless> abentley: I am comfortable with that.
<lifeless> abentley: I think it gives us something to talk to the mozillas of the world with
<abentley> Sure.
<lifeless> abentley: btw, I have incremental commits in the moz tree down to 24 seconds
<lifeless> and a fairly good idea of where I'm going to drop the next 10 seconds off
<lifeless> abentley: which *should* drop off on initial commit too
<lifeless> mwh: has it finished?
<mwh> lifeless: no
<lifeless> mwh: is it showing  aprogress bar ?
<mwh> no
<lifeless> is your cpu locked at max?
<mwh> yes, pretty much
<lifeless> if your disk is ticking over, not idle but not busy, you are cpu bottlenecked
<mwh> certainly seems that way
<lifeless> you can see how much data has been copied by looking in .bzr/repository/uploads
<mwh> seems like it's about 1/3 done
<mwh> lifeless: the push failed in the same way
<lifeless> so, you are probably locked in gunzipping the knit segments.
<mwh>     next = self.get_parents(cursor)[0] 
<mwh> IndexError: tuple index out of range
<lifeless> mwh: ah, its the old issue I mentioned in my how to dogfood notes.
<lifeless> bzr has an unreferenced text
<lifeless> look in .bzr/repository/packs
<lifeless> in the new repo, is it empty?
<mwh> no, it has a 54 meg file
<lifeless> good
<lifeless> I know what the problem is; its bad data in bzr.dev that knit based repos tolerate
<mwh> ok
<lifeless> (bad data == an index that is not quite right)
<lifeless> your bzr.dev in pack format will work fine
<lifeless> it just can't be cloned by bzr because bzr will not copy quite enough data
<mwh> ok, i'll play with pointing loggerhead at that in a bit
<lifeless> there is a patch to run on the knit format repo to fix this; its been written by Aaron, and tweaked by spiv
<mwh> ok, i saw those mails go by
<lifeless> not *quite* up for using it yet, when we do what I asked you to do will work
<lifeless> right, please let me know how loggerhead plays with packs.
<mwh> first: lunch
<mwh> :)
<lifeless> night
<lifeless> *yawn*
<lapthrick> mwh: loggerhead's loggerhead seems very much dead
<lapthrick> at http://www.lag.net/branches/loggerhead/loggerhead_dev/
<AfC> mwh: pong, yes
<mwh> AfC: and you use bzr already for all the java-gnome development?
<AfC> "already"?
<mwh> ehm ;)
<AfC> We've been using Bazaar since ...
* AfC does bzr log -r 0..1
<mwh> lapthrick: that's nothing to do with launchpad
<mwh> lapthrick: launchpad's is at urls like http://codebrowse.launchpad.net/~mwhudson/loggerhead/production/changes
<lapthrick> mwh: I never said it had anything to do with launchpad, I was just pointing out in the hope you'd be more able to fix it
<mwh> lapthrick: oh, sorry, misread
<AfC> mwh: well, since the beginning. First commits (which imported a huge whack of stuff) were Oct '06
<mwh> lapthrick: not my site
<mwh> AfC: cool
<AfC> 829 revisions, 14 committers. I suppose that's starting to edge out of small
<lapthrick> AfC: I still don't understand how you can put up with that ugly lump of a language :)
<AfC> Python? That's why we ditched it :)
<pbor> lifeless: I am now trying your suggestion of using bzr init --dirstate-with-subtree', then do 'bzr pull svn://', but it doesn't seem to help much:
<pbor> lifeless: resume works but ends up using the same amount of memory
<pbor> (incidentally, resume is really slow, unless it's the progress indicator that it is not clear)
<corporate_cookie> abadger1999: I'm having a bit o' trouble building a rpm for bzr-0.17; could you perhaps lend a bit of a hand ?
<jelmer> pbor: how much revisions are you trying to pull?
<pbor> jelmer: 5923
<pbor> jelmer: I am not interested in the whole history... can I tell it to start from a revision? (I recall git-svn doing something similar, but I am not sure if it makes sense for bzr)
<jelmer> pbor: no, that's not possible in bzr yet (requires a feature called historyhorizon)
<jelmer> pbor, you can fetch sets of 500 revisions for example, by running 'bzr pull -r500', 'bzr pull -r1000', etc
<pbor> jelmer: will that help keeping the memory usage under control?
<jelmer> pbor: yes, it will free the memory after each set of revisions
<pbor> jelmer: ok, thanks for the suggestion.. /me tries
<pbor> jelmer: any chance to implement the same workaround of hg? Or will the python-svn bug be resolved soon?
<jelmer> pbor:it's not just the memory usage of svn.ra.get_log() that's a problem
<jelmer> pbor: subversion seems to've fixed a bunch of memory problems in 1.5
<pbor> jelmer: ok... though if that workaround at least makes hg usable I hoped the same could work for bzr
<pbor> jelmer: btw, it seems the -r trick is working very well
<pbor> jelmer: I am already up to -r 3000
<pbor> jelmer: maybe for now the conversion could be batched in blocks of 1000 revisions
<pbor> or something like that
<Lo-lan-do> I think I saw something ot that effect in a NEWS file recently :-)
<jelmer> pbor: that's a very large amount of work I'm afraid
<Lo-lan-do> Isn't that what revno. 711 was about?
<pbor> jelmer: okay, so maybe this trick should be at least documented... one could whip up a quick shell script to parse svn info and then run bzr pull -r$i+500 until it recahes head :)
<abadger1999> corporate_cookie: What's the error?
<corporate_cookie> abadger1999:  i've got it : )
<corporate_cookie> but thanks for the responce
<abadger1999> Cool :-)
<corporate_cookie> im still a little green ...but i'm figuring stuff out
<pbor> jelmer: I let the pull from svn run with a script that pulled 100 revisions at a time but now it errors out in a somewhat surprising way:
<pbor> bzr: ERROR: Requested revision: u'4900' does not exist in branch: SvnBranch('svn+ssh://pborelli@svn.gnome.org/svn/gedit/trunk')
<pbor> but...
<jelmer> pbor: bzr revno's are per-branch
<pbor> URL: svn+ssh://pborelli@svn.gnome.org/svn/gedit/trunk
<pbor> Repository Root: svn+ssh://pborelli@svn.gnome.org/svn/gedit
<pbor> Repository UUID: 553ab114-d825-0410-8aca-8eebfce848a2
<pbor> Revision: 5923
<jelmer> the svn revno is per-repository
<pbor> jelmer: mmm, so is it normal?
<pbor> ah, so it discarded all revisions that didn't affect trunk?
<jelmer> well, didn't fetch them at all
<pbor> neat!
<pbor> so one more pull and I am done!
<pbor> :)
<jelmer> this sort of stuff (memory issue as well) is documented in bzr-svn trunk, and will be in 0.4.4
<pbor> jelmer: great, thanks a lot for your help (and for bzr-svn!)
<pbor> now I just need to figure out a patch to test my new toy
<pbor> but first of all I'll push the import to a remote ssh, so that if I screw up I can just branch that
<pbor> if I do bzr log |  less and then ctrl+C before it's finished bzr gives a traceback...
<pbor> which is a bit annoying since it triggers ubuntu bug reporting tool
<radix> yeah, that seems to be new behavior
<radix> or reintroduced behavior
<radix> ('q' instead of ctrl+C reproduces it just as well)
<james_w> I think reintroduced as well.
<james_w> is it a pipe error? (I can't remember the name)
<pbor> yep, IOError: [Errno 32]  Broken pipe
<fkumro> I'm just reading through the docs but I cannot find out what the command would be to revert a file to before a commit
<GaryvdM> bzr revert
<fkumro> heh I feel foolish
<GaryvdM> :-)
<fkumro> how would I use it ? Specify the file and revno ? bzr revert file?
<radix> fkumro: bzr revert -r revno file
<fkumro> thanks again
<radix> fkumro: if you don't pass "-r", it just reverts to the latest version (i.e. throwing out all changes only made in the working tree)
<ipkiss> see bzr revert -h for more details
<fkumro> good to know that about the -r flag
<joseo> hi
<joseo> anybody knows if its possible to rename .bzr to something else like _bzr
<joseo> I'm having problems with ftp uploaded and I think are related to this
<joseo> so quiet here :)
<GaryvdM> Hi - sorry - don't know
<fkumro> I would help but I just started using bzr for my projects today heh
<GaryvdM> What are your problems?
<GaryvdM> Steps to reproduce?
<james_w> joseo: no way apart from patching the source.
<joseo> Me too I'm starting today
<joseo> or trying
<joseo> :)
<joseo> james_w:okay, I see
<joseo> It's a pitty
<GaryvdM> joseo: What problems are you having?
<joseo> GaryvdM: this -> bzr: ERROR: Generic path error: '/.bzr': error w/ stat: 550 CWD command failed. "/.bzr": Permission denied.)
<joseo> 
<GaryvdM> What did you do to get there?
<GaryvdM> e.g. what command?
<joseo> bzr push ftp://user:pwdf@ftp.drivehq.com --use-existing-dir
<james_w> joseo: that will push to the root of the server, you probably want to push to a subdir.
<joseo> I know
<james_w> bzr push ftp://user:pwd@ftp.../home/user/bzr/ or similar
<joseo> but no difference
<lapthrick> jelmer: hoho, you have fixed that push bug I see?
<joseo> bzr push ftp://joorce:gandalf@ftp.drivehq.com/PublicFolder/CocoaNotepad --use-existing-dir
<joseo> this the desired command but no way
<GaryvdM> joseo: have you tried using another ftp client to see if you have permission to write there with another file?
<lapthrick> is there something like bzr missing, but for checkouts?
<lapthrick> as in, I want to know how out-of-date my checkout is
<Lo-lan-do> I was wondering about that, and didn't find anything.
<lapthrick> Lo-lan-do: bueh :\
<lapthrick> it'd be a good tool for those of us who only follow someone else's branches
<Lo-lan-do> Yeah.  I turned my checkout into a branch for precisely that reason.
<joseo> GaryvdM: Have to go, thanks for the help
<james_w> can you bzr missing <master> ?
<GaryvdM> ok - np
<lapthrick> james_w: are you asking me?
* Lo-lan-do tries
<lapthrick> mathrick@hatsumi:~/.bazaar/plugins/svn$ bzr missing http://people.samba.org/bzr/jelmer/bzr-svn/0.4/
<lapthrick> Branches are up to date.
<lapthrick> I guess not
<james_w> ah, no it will compare the branch to itself I guess.
<lapthrick> Lo-lan-do: but branches are a huge waste of space if you don't intend to hack the code, just follow it
<james_w> what would be cleanest, a flag to checkout, a flag to update, or a new command?
<Lo-lan-do> lapthrick: I know, I know, but in the case of bzr-svn, it's not much space anyway, I guess.
<Lo-lan-do> 5 MB instead of 800 KB  I can afford that.
<lapthrick> yeah, I guess
<lapthrick> but there were biggest checkouts I did
<lapthrick> james_w: how about bzr status?
<lapthrick> I think it'd make sense to have it there
<james_w> status could be good too.
<lapthrick> james_w: are you gonna hack it in? :)
<lapthrick> (go james_w!)
* pbor still has problems with bzr-svn... I am not able to push to the svn repo
<Lo-lan-do> Then make it "status -u", please, in order not to *require* net connection
<Lo-lan-do> pbor: You're not alone :-)
<pbor> paolo@murdock:~/bzr/gedit-dev$ bzr merge svn+ssh://pborelli@svn.gnome.org/svn/gedit/trunk
<pbor> Nothing to do.
<pbor> paolo@murdock:~/bzr/gedit-dev$ bzr push svn+ssh://pborelli@svn.gnome.org/svn/gedit/trunk
<pbor> bzr: ERROR: These branches have diverged.  Try using "merge" and then "push".
<pbor> it refuses to commit because there is stuff  to merge but it refuses to merge because there is nothing to merge
<lapthrick> Lo-lan-do: -u?
<Lo-lan-do> lapthrick: Like in svn
<lapthrick> Lo-lan-do: also, I'd make -u *not* check that, and do otherwise
<Lo-lan-do> Or --somethingelse, I don't care
<lapthrick> so -u would be "unconnected"
<Lo-lan-do> "svn status -u" means check for remote changes too, so I don't think it would be a good idea to reuse the same option with an opposite meaning
<lapthrick> Lo-lan-do: then --offline
<lapthrick> I personally think it's a good default to do it
<Lo-lan-do> Hm.  The default for status in branches is to work offline, so I'd rather have the same behaviour in checkouts.
<lapthrick> does status in branches ever result in network connections?
<fkumro> after i create a personal branch (bzr branch), edit a file, commit it, do I need to use bzr merge to get the file to the server or push?
<Lo-lan-do> lapthrick: No
<lapthrick> fkumro: push
<fkumro> thanks
<lapthrick> fkumro: though a merge could be also needed before you can push, if the upstream has done something you didn't merge yet
<lapthrick> Lo-lan-do: but then, checkouts pretty much by definition are networked whilst branches aren't
<fkumro> very true, I'll have to remember to do that so I dont run into issues.
<lapthrick> I think it makes perfect sense to include that for checkouts
<lapthrick> fkumro: it will tell you when you do :)
<asabil> pbor: try to pull ?
<fkumro> lapthrick: when I try to push and it needs to merge it will tell me that? Seems too easy :-P
<lapthrick> asabil: but it's still very odd that bzr merge won't do anything
<Lo-lan-do> bzr status doesn't check for missing changes.  bzr missing does.  Please don't change the behaviour of bzr status.
<lapthrick> fkumro: yeah, it won't let you push to a diverged branch
<lapthrick> Lo-lan-do: but bzr missing ./mycheckout will check missing for the branch it's a checkout for, not for checkout itself, so you can't overload it to check for checkout's status too
<lapthrick> Lo-lan-do: I really don't see anything bad about defaulting to networked ops for checkouts, they do that already anyway
<pbor> asabil: do you mean pull from the svn repo? shouldn't merge imply that? (trying anyway in the mean time)
<fkumro> one more question for everyone. I'm only playing around with simple directory layouts but I have my levels of directories on my projects at home. If I go into the root and execute "bzr init ." then "bzr add" and then commit will bzr recursively add all the directories below root?
<asabil> pbor: pull and merge are slightly different, but still your case seems really weird
<pbor> asabil: didn't help...
<pbor> :(
<lapthrick> fkumro: yes
<asabil> pbor: which version of bzr ?
<pbor> asabil: I just pulled from svn, made a change, committed it and now I want to push it... it's not like I was doing some crazy stuff
<lapthrick> fkumro: if you want to keep different things in separate branches, you might consider making it a repository (though it mostly makes sense when there are branches that would be able to share stuff, as repos make them able to reuse identical data)
<pbor> asabil: 0.90.0
<asabil> hmm, really weird
<fkumro> lapthrick: That's something I have to read into more tonight before moving my code over. I will probably be back here asking more questions about that exact topic.
<pbor> asabil: do you successfully use bzr with a gnome svn module?
<asabil> pbor: https://lists.ubuntu.com/archives/bazaar/2007q2/026497.html
<asabil> pbor: I don't have a gnome svn account, so I cannoy push
<asabil> I pulled already without any problem
<pbor> asabil: yeah, that message looks like the same issue
<pbor> pulling works
<asabil> looks like a bug to me
<pbor> yeah... /me digs in launchpad
<lifeless> moin
<GaryvdM> Hello lifeless
<vila> hi lifeless
<asabil> pbor: can you try the latest bzr and bzr-svn ?
<pbor> asabil: well, I hoped that gutsy had stuff recent enough :)
<pbor> asabil: but ok, I'll try latest and greatest
<GaryvdM> lifeless: Do you know a easy way to run a lsprof on olive-gtk?
<asabil> 0.91 is not in gutsy I guess
<Lo-lan-do> 0.91 is out?
<james_w> asabil: bzr-svn 0.4.2 is a more significant change than bzr 0.91.
<asabil> candidate
<james_w> Lo-lan-do: not as yet I believe.
<Lo-lan-do> Oh.  Right.
<asabil> james_w: bzr-svn 0.4.2 works with 0.90 ?
<asabil> pbor: try to update only bzr-svn then
<lifeless> GaryvdM: hmm
<lifeless> GaryvdM: if the --lsprof command doesn't work well
<lifeless> GaryvdM: then I'd use the bzrlib.lsprof module directly around the function to profile
<pbor> asabil: mmm... how do I install bzr-svn without changing bzr?
<asabil> system wide ? or for the user only ?
<GaryvdM> lifeless: I was thinking, maybe I could make olive-gtk a plugin command....
<pbor> asabil: well, if possible I'd like to test it locally
<GaryvdM> Would that work>
<GaryvdM> s/>/?
<lifeless> GaryvdM: I'd guess so; bzr viz already is
<GaryvdM> Cool
<lifeless> GaryvdM: so you could try 'bzr --lsprof viz' and see how well it works
<GaryvdM> I've been useing that lots...
<asabil> pbor: then download the latest release from http://samba.org/~jelmer/bzr/bzr-svn-0.4.3.tar.gz and untar it to ~/.bazaar/plugins
<GaryvdM> I've managed to get bzr viz bzr.dev from 30 sec to 2.5 sec
<GaryvdM> Lots and lots of profiling
<lifeless> cool
<GaryvdM> Now I want to look at Bug 70463
<ubotu> Launchpad bug 70463 in bzr-gtk "olive slow when used in bound branch" [Medium,Confirmed]  https://launchpad.net/bugs/70463
<asabil> pbor: after untarring it, you would probably want to rename the folder to svn (so that it is a valid python package)
<asabil> also don't forget to uninstall the installed system wide bzr-svn just in case
<lifeless> mwh: so how did it look ?
<asabil> pbor: how did it go ?
<pbor> asabil: trying... the push seems to be going through, albeit slowly
<asabil> yeah, bzr-svn is quite slow unfortunately :/
<pbor> UGH
<pbor> http://svn.gnome.org/viewcvs/gedit/trunk/
<pbor> it touched *every* file
<asabil> :/
<Lo-lan-do> Probably only the properties
<asabil> 5900 revisions ... did you manage to check it out without eating 4 Gb of memory ?
<pbor> Lo-lan-do: does that mean that it may have screwed up all svn properties?
<mwh> lifeless: not great :/
<Lo-lan-do> I don't think so, it probably just added bzr:* revisions
<Lo-lan-do> Er, properties
<pbor> asabil: heh... that was a pain, thanks to jelmer suggestions we figured it out:
<pbor> r=$1
<pbor> while [ $r -ne $2 ] ; do
<pbor>         bzr pull -r$r svn+ssh://pborelli@svn.gnome.org/svn/gedit/trunk
<pbor>         r=$(( $r + 100 ))
<pbor> done
<mwh> lifeless: most of the "getting data out of bzrlib" steps took 1.5-2x as long on the packs repo
<mwh> so not hideous, but not very good either
<pbor> asabil: and yes, it took a looooong time :)
* mwh --> pub
<asabil> pbor: it's a memory leak in python-svn :/ not really bzr's fault
<pbor> asabil: yeah, I know
<pbor> asabil: that's why I had to do it 100 revisions at a time
<asabil> that's a smart trick :)
<pbor> asabil: however it's not the only thing that is slow...
<asabil> yep, bzr-svn needs some profiling I guess
<pbor> asabil: I am trying to push a copy of the repo to my gnome.org ~ dir and it is taking forever
<Lo-lan-do> I can branch ~4800 revisions from the Gforge svn without such a trick, but it does take some time.
<pbor> Lo-lan-do: how many gigs of memory do you have :)
<Lo-lan-do> 1
<Lo-lan-do> But I expect gforge may be smaller than gedit
<pbor> asabil: the push I am tryng to do is with sftp...
<Lo-lan-do> 44 MB
<pbor> Lo-lan-do: 5900 revisions here
<Lo-lan-do> Ah, no, not even that, 37 MB
<pbor> 126M    gedit-dev/
<Lo-lan-do> I think that's where you beat me :-)
<pbor> mmm... wait that is with built stuff
<pbor> clean 87M
<pbor> is there a way to compress all local commits in a single revision for svn?
<pbor> e.g: I hack on feature X do 10 small commits and fixups in my branch
<pbor> but then I just want to push it as a single patch for the 'upstream' repo
<Lo-lan-do> Maybe doing it in another branch, then merging to your gateway branch, then pushing that gw branch to svn
<Lo-lan-do> (Not tried myself, since bzr-svn still doesn't want to let me push to svn)
<pbor> Lo-lan-do: did you update to the latest bzr-svn? that did the trick for me
<Lo-lan-do> I run on the latest, but I have another bug.
<GaryvdM> pbor: You can uncommit x n and then commit
<GaryvdM> Ah - uncommit has -r so you can uncommit -r (starting revision) and then commit
<pbor> GaryvdM: ugh, sounds ugly :)
<asabil> pbor: why collapse the commits ?
<GaryvdM> Please do it in a branch....
<asabil> you lose the ability to make quite orthogonal commits
<lapthrick> argh
<lapthrick> now that jelmer fixed that push but, I'm running into branches diverged thing myself
<lapthrick> *bug
<asabil> pbor: can I get you to give bzr record a try ?
<lapthrick> pbor: you say bzr pull fixed it for you?
<lifeless> mwh: ok, can you give me some timings and operations you were testing with
<lapthrick> mine says no revisions to pull
<pbor> asabil: because with a local repo I commit very often but that makes the history hard to follow... if I hack, commit, fix a typo that prevents compilation fix it, commit, there is no use for that to go in the public history
<lapthrick> lifeless: is there some way I can make bzr bail out on errors?
<pbor> lapthrick: using the latest bzr-svn fixed it
<lapthrick> pbor: I thought I was using the latest :(
<asabil> pbor: then you can think about writing a bzr plugin ?
<pbor> asabil: what is bzr record?
<lapthrick> mathrick@hatsumi:~/.bazaar/plugins/svn$ bzr update
<lapthrick> Tree is up to date at revision 718.
<lapthrick> pbor: what branch do you pull from, 0.4 or trunk?
<asabil> pbor: a plugin I wrote to create orthogonal patches from a bzr tree :D
<pbor> lapthrick: I used the last released tarball 0.4.3
<pbor> asabil: sounds nice!
<asabil> pbor: you can grab it from the bzr plugins page
<pbor> ok
<lapthrick> pbor: bummer, that I can't use because I rely on fixes from r716
<lapthrick> asabil: ooh, sounds nice
<pbor> lapthrick: yay, for bleeding edge software :P
<lapthrick> that's really useful for pushing upstream
<lifeless> lapthrick: we do bail on errors
<lapthrick> lifeless: err, yes, bad phrasing, I'd like it to bail when it says branches have diverged
<asabil> lapthrick: it is still very sketchy, I wrote it because we use bzr at work and we need to submit patches upstream
<lifeless> lapthrick: what do you mean precisely; do you mean a different return value to the shell ?
<pbor> asabil: add a --bugzilla option that attaches the patches in bugzilla and I am sold :)
<lifeless> lapthrick: and from what command
<asabil> pbor: that would be easy to do, but what I want is a --interactive to the commit commands
<asabil> so that you can select exactly which hunks to commit
<asabil> (yes I used darcs before ...)
<lapthrick> lifeless: I would like something I can break on in PDB or similar
<lapthrick> bzr bzr-pokersource:2902/> push svn+https://beta.aimido.de/svn/src2/branches/mathrick/pokersource
<lapthrick> These branches have diverged.  Try using "merge" and then "push".
<lapthrick> lifeless: I mean I'd like to catch the moment when it decides they have diverged
* pbor wonders if bzr squash to merge commits in just one commit would doable as a plugin
<lifeless> lapthrick: oh hmm, edit bzrlib/builtins.py  perhaps ?
<lifeless> lapthrick: or have you not tried 'BZR_PDB=1 bzr push'
<lapthrick> nope
<lapthrick> hmm, that doesn't really tell me which part of bzr-svn decides they have diverged
* pbor keeps on asking since it worked out well so far...
<pbor> can I make bzr-svn do not commit .bzrignore files in svn?
<GaryvdM> add .bzrignore to .bzrignore and remove from tree
<pbor> GaryvdM: but if I remove it from the tree, then when branching with bzr it will not be pulled right?
<GaryvdM> Yhea
<pbor> I wonder if bzr-svn could special case that
<lifeless> lapthrick: ah, so now we get closer:)
<lifeless> lapthrick: bzr-svn exposes the regular bzr api
<lapthrick> lifeless: yeah, I even for it to stop in branch.py
<lifeless> lapthrick: which pull can use
<lapthrick> s/for/got/
<lifeless> are you using svn-push? I think you are meant to
<lapthrick> lifeless: no, svn-push is only meant to be used if you need to create a new branch on the svn side
<lifeless> oh
<GaryvdM> It would be cool if bzr-svn could translate betweem bzr ignore and svn ignore...
<lifeless> are you sure ? :)
<lapthrick> lifeless: that's what all the docs say, so pretty sure, yes
<lifeless> ok
<lifeless> so anyhow, the decision about variance is quite simple
<lifeless> given a graph for the left branch and for the right branch
<lifeless> either the tip of the left branch is in the right branch's graph, or its not
<lifeless> if it is, the right branch can be pushed onto the left branch
<lifeless> if it is not, it errors
<lifeless> so in bzrlib api terms
<lapthrick> yeah, I can see the line where it raises DivergedBranches
<lapthrick> I just need to understand what exactly it checks
<lifeless> bzrlib.branch.Branch.open('svn://...').last_revision() in bzrlib.branch.Branch.open('.').repository.get_ancestry([bzrlib.branch.Branch.open('.').last_revision()] )
<lifeless> IIRC
<lifeless> possibly get_ancestry takes a revid not a list of revids
<lapthrick>         if not other.repository.get_graph().is_ancestor(self.last_revision(),
<lapthrick>                                                         stop_revision):
<lapthrick>             if self.repository.get_graph().is_ancestor(stop_revision,
<lapthrick>                                                        self.last_revision()):
<lapthrick>                 return
<lapthrick>             raise DivergedBranches(self, other)
<lapthrick> bah
<lapthrick> not pretty
<lifeless> so the inner if there checks for 'this branch has already been pushed here'
<lifeless> the outer checks for 'someone else has pushed here before you and you should merge from them before pushing'
<lapthrick> http://codebrowse.launchpad.net/~jelmer/bzr-svn/0.4/annotate/jelmer%40samba.org-20070925134348-1bsc948sqqmevhvh?file_id=svnbranch.py-20051017135706-11c749eb0dab04a7#L343
<lapthrick> here it is a bit nicer
<lapthrick> lifeless: I see
<lapthrick> lifeless: so foo.is_ancestor(bar) checks if bar is ancestor of of foo?
<lapthrick> or the other way around?
<lifeless> graph.is_ancestor(foo, bar) is True if bar is reachable from foo in graph
<lifeless> that is, if foo is an ancestor of bar
#bzr 2007-09-26
<lifeless> poolie_: ping
<offray_> Hi all
<offray_> I'm trying to use svn2bzr to convert a svn project to bazaar but I get two errors related with bzrlib: "ImportError: No module named bzrlib.branch" or "ImportError: No module named clone". I don't know how to deal with it. May be my version of bzrlib is not syncronized with svn2bzr, but I don't know which version is supposed to be. Any pointer to a solution?
<AfC> offray_: I believe that the plugin called 'bzr-svn' is the solution recommended by the Bazaar hackers; you might try that
<cory> Is there any variant on commit that doesn't actually touch the working tree?
<cory> Er, revert.
<poolie_> lifeless, hi
<Odd_Bloke> cory: Look at 'uncommit'.
<offray_> AfC: Thanks. I will try, but it says that you can put bzr code in svn, but not convert from svn to bazaar. I will read mode
<cory> Odd_Bloke: I spoke poorly.  For instance, the working tree might know that I have moved a => b.  I want it to forget that so that I can, say, add b and remove a instead.
<cory> add b and remove a, that would be.  Maybe I should stop talking. :P
<cory> I don't want to do anything with already committed revisions, like uncommit does.
<Odd_Bloke> cory: Why doesn't revert do what you want?
<offray_> umm... there is a svn-import wich seems to make the same that svn2bzr
<cory> Because revert will move the file back.
<cory> I happen to need it to not do that.
<poolie_> cory, do you mean revert --keep?
<poolie_> i mean, remove --keep
<cory> I think revert --keep is what I want. ;)
<poolie_> cory, you could file a bug asking for that
* cory nods.  Just wanted to make sure there wasn't something obvious I was missing.
<fullermd> Wouldn't rm/add do that?
<cory> Or even unexposed api that I could use.
<cory> Only if there's a bzr add --even-if-it-doesn't-exist
<fullermd> Huh?
<fullermd> Why would you want to add a file that didn't exist (and what would that even mean?)?
<cory> I want it to forget that I told it to move it, not to add it!
<cory> This is me fighting with perforce, really.
<poolie_> cory, so in this particular case
<poolie_> why not just do a reverse mv
<fullermd> OK, you're losing me...  I thought you had the case "moved a to b", and wanted to change that to the case "rm'd a and added b".
<lifeless> poolie_: what time should I pop over ?
<poolie_> any time
<lifeless> ok
<poolie_> are you trying to call?
<lifeless> I'll head over shortly
<poolie_> i can't hear anything when i pick up
<poolie_> do you want to meet spivvo on the way?
<lifeless> I did try
<lifeless> it went to your voice mail both times
<lifeless> try ringing yourself perhaps. Is the spivster up ?
<lifeless> cory: there is a bzrlib api to add a file regardless of physical presence
<lifeless> cory: tree.add([paths] , [ids] , [kinds] )
<lifeless> spiv: I'll be on the 10:30 from hornsby again
<cory> Oh, I have another issue...the smart server seems to like leaving locks around. :/
<igc> morning all
<poolie_> cory, if you abort the operation, or even when it succeeds?
<poolie_> igc, hi
<igc> hi poolie_
<cory> poolie_: From aborted operations, yes.  I expected the server instance would clean up after itself after it loses its connection.
<cory> Running it through inetd...maybe it's terminated before it gets the chance.
<lifeless> bbiab
<AfC> cory: any reason you chose not to run it as a daemon full time?
<cory> AfC: No special reason.
<AfC> cory: (but I note that bzr+ssh := run a `bzr --serve` for one time use and seems to manage to last long enough to clean up after itself)
<cory> Doh, I'm getting sigpiped.
<fullermd> Mmm.  Could be a diff.  bzr+ssh probably gets sighup.
<poolie_> cory, there's a recent bug discussing how to do that better
<ubotu> New bug: #145027 in bzr "bad assertions in WorkingTree4._add" [Medium,Confirmed]  https://launchpad.net/bugs/145027
<AfC> As at which version did --trees become the default implied behaviour in `bzr init-repo` (ie, can I remove --trees from my instructions now?)
<fullermd> 0.15, I think
<fullermd> Anybody keeping up should be long past that, but there're probably still a notable percentage of people below it.
<AfC> fullermd: oh, that's ok
<AfC> fullermd: I actively encourage my users to be >= 0.90
<AfC> fullermd: I was just worried it was 0.18 or something, in which case I would have left the documentation alone
<AfC> fullermd: thanks
<fullermd> I think I actually have a server with 0.14...
<fullermd> But that's 'cuz everything on it is outdated, and I'm just waiting to do it all in one swell foop, so not bothering to piecemeal.
<AfC> What about --dirstate-tags ? Is it default as of 0.90?
<fullermd> 0.91, I think.
<AfC> fullermd: shit
<AfC> ok
<Peng> How does one switch a repo between --trees and --no-trees?
* Peng wanders off.
<fullermd> rm or touch still, I think.
<fullermd> .bzr/repository/no-working-trees
<cory> Or checkout / remove-tree?
<cory> repo / branch...never mind.
<ubotu> New bug: #145033 in bzr "need a command to switch a repository between trees and no-trees" [Medium,Triaged]  https://launchpad.net/bugs/145033
<lifeless> fullermd: a patch to reconfigure to do it would be good
<fullermd> Would be the reasonable place for it.
<poolie> or maybe we should have gdb-like set/show commands
<fullermd> Wow, we're over half a million bugs in launchpad?  ;)
<cory> 564043 isn't found...
<lifeless> fullermd: no, 145K
<lifeless> or perhaps I'm on crack
<igc> today's plan: review things (particularly from lifeless and poolie), then start on OSDC tutorial
<igc> knit repo formats tidyups will be first
<fullermd> lifeless: I'm aware.  Hence the ;) for poolie's x-ref.
<lifeless> igc: thanks
<igc> np
<lifeless> igc: I'm working on applying inventory deltas to the parent tree of a working tree
* lifeless waits for jelmer________________________________________
* jelmer__ blames AT&T
<jelmer__> sucky airport wireless
<schierbeck> jelmer_: is there some historical reason why the viz window is titled "bzrk"?
<jelmer_> schierbeck: yup, it used to be a standalone plugin called 'bzrk'
<jelmer_> or 'bezerk' (if I got hte spelling right)
<schierbeck> jelmer_: do you think it should be changed to something more descriptive?
<schierbeck> like "branch history"
<AfC> Agreed
<jelmer_> schierbeck: yeah, that's probably a good idea
<schierbeck> jelmer_: i'll make a branch for it
<jelmer_> cool, thanks (-:
<schierbeck> "branch history" is fine, right?
<lifeless> sounds good
<lifeless> or graphical log of URL
<lifeless> sorry, "Log of <URL>"
<lifeless> (because viz is a graphical log)
<schierbeck> lifeless: i'm not really fond of "log"
<schierbeck> it struck me when i saw it in olive
<schierbeck> "history" much better captures the purpose
<schierbeck> perhaps it's just me
<schierbeck> it usually is
<abentley> I always find "unprintable" exceptions amusing, because "unprintable" was used in place of swear words in the Foundation series.
<poolie> :)
* igc food
<lifeless> schierbeck: on the other hand, 'bzr log' is the text command to get the same data
<lifeless> schierbeck: I don't have a strong opinion though; mainly showing the url would be nice.
<schierbeck> lifeless: why not show the branch nick? isn't that more descriptive?
<fullermd> Why not just "bzr viz: $URL"
<schierbeck> fullermd: i'd like it to be more human-readable
<schierbeck> remember, it could be launched from nautilus
<schierbeck> the user may not even know of the "viz" shorthand
<abentley> schierbeck: The historical reason was that it was based on "gitk".
<schierbeck> abentley: ok
<schierbeck> but the users won't really care about that
<schierbeck> i'm trying to find ways to streamline the viz, to make it less confusing to newcomers
<abentley> lol, looks like the git crew stole bzrk back, and made gitview.
<igc> now reviewing poolie's patch re safe_revision_id, etc.
<spiv> abentley: did you see my post about reconcile where a file parent is a ghost?
<abentley> Yeah.
<Odd_Bloke> I've created a separate branch for a particular release of my project.  However, I now have a bug-fix branch which I need to apply to both branches without its application to the release branch also merging the features that have been added since the release branch was branched from trunk.  What's the best way to go about doing this?
<abentley> I guess I have a preference for sticking to the known facts.
<abentley> The ancestry data in your knits should be derivable from the texts of the revisions and the texts of the inventories.
<spiv> So I guess one issue is if we remove the parent the ghost is later filled in and it turns out that the data wasn't wrong after all, then reconcile will be introducing problems rather than fixing them.
<abentley> But really, I'd rather sleep on it.
<spiv> s/the ghost/and the ghost/
<spiv> Fair enough.
<abentley> What problems?
<spiv> That's why I wanted to check you'd seen then mail, so you had plenty of time to think about it :)
<spiv> Well, just that the data is now "wrong", whereas if we'd never run reconcile in that case it wouldn't be.
<fullermd> Odd_Bloke: DAGgy it back to the branch point.
<Odd_Bloke> fullermd: DAGgy?
<fullermd> That's the term the mtn guys use for it.  Catchy.
<fullermd> The theory in extremis is that you make the bug fix revision a child of the revision that introduced the bug; that way any branch that has that bug, can directly merge the bug fix.
<fullermd> In less extreme cases like this, just making it a child of some rev both branches have in common (the branch point being the obvious choice).
<Odd_Bloke> fullermd: OK, thanks. :)
<fullermd> Odd_Bloke: http://www.venge.net/mtn-wiki/DaggyFixes
<abentley> spiv: My point is having knit data with too few ancestors doesn't produce many harmful results, while having knit data with too many ancestors does.
* ..[topic/#bzr:poolie] : The Bazaar Version Control System | http://bazaar-vcs.org/ | Bazaar 0.91 is out - http://bazaar-vcs.org/Download | Please complete the Bazaar User Survey - http://www.surveymonkey.com/s.aspx?sm=L94RvLswhKdktrxiHWiX3g_3d_3d
<fullermd> Ooh.  Purdy.
<lifeless> abentley: possibly gitview went via hg ?
<igc> yah for the 0.91 release!
<lifeless> abentley: it does produce harmful results - bzr log FILENAME dpeends on the index
<lifeless> AIUI
<lifeless> abentley: the harm in having ancestors that aren't validated, at the border to a ghost, is two fold- index, and text construction.  Making a fulltext there addresses the text construction hole
<abentley> The gitk man page says that gitview is derived from bzrk.  Of course, it could be wrong.
<lifeless> oh cool
<lifeless> what version of gitk do you have ?
<abentley> I was just looking at this page: http://www.kernel.org/pub/software/scm/git/docs/gitk.html
<lifeless> ah
<lifeless> Ubuntu would appear to be out of date, and networkmanager blows again
<Peng> Oh, 0.91 is out!
<Peng> Cool.
* Peng wanders off.
<lifeless> bbiab
* AfC seems to remember showing lifeless the gitview sources in a deli in Railway Square one morning and you saying "ah ha", "they copied that from us", and "yes we have that its called bzr viz"
<fullermd> Y'know, there are some people who don't pass around source code in delis   :p
<fullermd> (granted, they're people who live sad, colorless, wasted little lives.  But still.)
<lifeless> AfC: sounds familiar
<AfC> (sounds to me like the perfect opportunity for some propaganda on the bzr-gtk page)
<AfC> Am I correct in believing that `bzr serve` doesn't background itself?
<fullermd> I think you are...   though I've not tried, so for what that's worth...
<Odd_Bloke> AfC: Just running it here doesn't background it...
<AfC> [I mean, you run it on the command line and it sits there in foreground, implying I need to use the otherwise frowned upon --background option to start-stop-daemon (which, itself, I frown on, but I was being a good sys admin and being lazy)
<AfC> Odd_Bloke: yeah
<AfC> Well then. `bzr branch http://...` takes 20m36s minutes, bzr branch bzr://...` takes 1m46s. Guess I'll run the server daemon full time now
* AfC never did figure out how to get the transparent http redirect to bzr server working
<AfC> Canonical staff: someone should put an expires header on http://bazaar-vcs.org/LogoOptions?action=AttachFile&do=get&target=Bazaar+Logo+2006-07-27.png ... its a bit ridiculous that you download it every page load
<AfC> (of course, that's a stupid way to serve static files, but anyway)
<mwh> AfC: yay moin
<AfC> (If there _is_ a static file I can point at, I would be happy to)
* AfC is really enjoying watching the Bazaar logo load again and again and again!
<mwh> lifeless: wow, 'diff' seems slow with packs
<mwh> http://rafb.net/p/EVQLD158.html
<lapthrick> jelmer: there doesn't seem to be any bugreport of that push -> diverged branches bug, and it's hitting me atm
<lapthrick> jelmer: are you aware of / working on it?
<poolie_> AfC: what's happening?
<AfC> poolie_ do a
<AfC> wget -S 'http://bazaar-vcs.org/LogoOptions?action=AttachFile&do=get&target=Bazaar+Logo+2006-07-27.png'
<AfC> and note the lack of expires headers
<AfC> (compare
<AfC>  wget -S 'http://www.operationaldynamics.com/images/logo/logo-130x167.jpg'
<AfC> )
<AfC> poolie_: result is that each time I reload my blog as I'm authoring I wait a few seconds for the Bazaar logo image I've used to load.
<AfC> ... that has knock on effect when aggregated on places like planet.*
* Lo-lan-do suggests using HEAD rather than wget -S
<AfC> (knock on load for you guys, that is)
<AfC> Lo-lan-do: --spider would have worked too
<AfC> Lo-lan-do: but HEAD is lwp and it does funny things sometimes
<AfC> Whatever. The point is to see the headers
<AfC> poolie_ a .htaccess would probably kludge-fix it if you don't have easy access to the virtual host config
<AfC> poolie_ I can whip up the directives if they're not coming to mind easily
<Gacha> hi
<Gacha> can somebody explain me the difference of --trees and --no-trees
<Gacha> I'm reading the docs, but I dont get it :)
<AfC> A branch doesn't have to have its files (a "checkout", if you will) present
<AfC> Gacha: For instance,
<Gacha> in whitch case?
<AfC> Gacha: http://research.operationaldynamics.com/bzr/java-gnome/mainline/ is a branch called 'mainline' in a repository in directory /bzr/java-gnome on that server, whereas
<AfC> which has --trees
<AfC> ... in other words, files are there
<lapthrick> Gacha: in a case you never need those file because you're only serving a branch, like launchpad does
<AfC> whereas
<lapthrick> s/a/the/
<AfC> Gacha: http://research.operationaldynamics.com/bzr/java-gnome/hackers/andrew/treeview/ is quite "emtpy" [*]  but contains a branch
<AfC> * we actually want to change things so that a "THERE IS A BRANCH HERE" message appears
<AfC> Gacha: /bzr/java-gnome/hackers is a different repository, and was created with --no-trees
<AfC> Gacha: when you're working locally, you almost always want files present, so --trees
<AfC> (which is the default now, according to conversation earlier today)
<poolie_> acf, we should probably just put the image on a static host somewhere and point to that
<Gacha> so with --no-trees files are keept in the main repo but not in the branch
<lapthrick> is anyone aware of a branch of ezbzr still around? Nathaniel apparently removed everything from his site, and bzr release didn't make its way into mainline bzr
<AfC> Gacha: the _revisions_ are kept in the repository (Which may be in .bzr, it may be in ../.bzr, whatever)
<AfC> Gacha: whether there is a checkout of the files in that branch is what --trees influences
<AfC> Gacha: like I said, you generally want files, and its default, so don't worry about it :)
<Gacha> ok, thanks
<poolie_> igc, are you still around?
<igc> yep
<poolie_> igc, i just commented on https://bugs.edge.launchpad.net/bzr/+bug/137449/comments/8
<ubotu> Launchpad bug 137449 in bzr "status performance regression compared to 0.17" [Critical,Triaged] 
<poolie_> i think that's why status looks so slow
<poolie_> so, do you think this is the likely cause,
<poolie_> and if it is, do you think it'll be hard for me to change the order in which the test components are run?
<igc> I agree with your assessment ...
<igc> and have been meaning to make that change
<Slant_Laptop> How can I have a directory inside my repo that is a branch from another repo, and will updates will pull from it?
<igc> it's not a large change but it's not a 10 minute one
<poolie_> Slant_Laptop: just branch it, and then pull changes in
<poolie_> it should work in the obvious way
<poolie_> however, at the moment you can't branch a subdirectory of a branch, if that's what you're talking about
<igc> poolie_: a sad workaround right now is, when running by hand at least, to run usertest on one tool ...
<igc> then run it again on another
<igc> you don't get the nice cross comparison of course
<poolie_> right, i was going to at least try that and see what happens
<igc> poolie_: I'm happy to make the change later this week if you don't get time ...
<igc> right now, I need to get my osdc tutorial together as the submission date is Sep 30
<Slant_Laptop_> Grr, that was annoying.
<Slant_Laptop_> poolie_: So, if I already have a directory, "a/" that I did a bzr init in.
<Slant_Laptop_> poolie_: Inside it, do a bzr branch http://blah
<Slant_Laptop_> poolie_: If I cd into "a/blah" from then on and do a bzr update, it will merge in the upstream updates?
<Slant_Laptop_> And if I do a bzr push from "a/" it'll push everything under a/ including a/blah?
<poolie_> Slant_Laptop_: no, it will only push a, you need to push a/blah separately
<poolie_> but i think there is a plugin (multipush?, maybe in bzrtools?) that will automate it
<poolie_> if you can't find it, please just ask the list
<igc> multi-pull is part of bzrtools
<igc> not sure about multi-push though
<Slant_Laptop_> There is a multi-pull, but I don't see a multi-push.
* igc food
<Slant_Laptop_> So, no real solution to the problem? Grr, I don't want to do this in SVN. :-\
<lapthrick> Slant_Laptop_: there's experimental (yet) nested tree support being worked on, 0.92 I believe is the target. For now, you can use merge-into plugin
<lapthrick> (I'm using it myself)
<lapthrick> Slant_Laptop_: it will let you embed a branch inside another
<Slant_Laptop_> lapthrick: It doesn't seem to be in my 0.90 copy. Do you have a link?
<lapthrick> Slant_Laptop_: also, I'm working with SVN myself (which is why I know it), and there are bugs right now that prevent it from actually working
<lapthrick> Slant_Laptop_: bzr plugins page links to it
<lapthrick> Slant_Laptop_: you will need extra-recent bzr-svn (r716 or newer from http://people.samba.org/bzr/jelmer/bzr-svn/0.4/), but that has a problem of not being able to push into SVN (because there's some breakage which makes it think the branches have diverged)
<lapthrick> Slant_Laptop_: you will also need https://bugs.launchpad.net/bzr-merge-into/+bug/144108 for merge-into to work
* Slant_Laptop_ nods.
<ubotu> Launchpad bug 144108 in bzr-merge-into "Doesn't work with 0.90 --  no attribute 'base_is_other_ancestor'" [Undecided,New] 
<lapthrick> Slant_Laptop_: I hope jelmer will fix the push thing soonish, so that it'll work finally
<lapthrick> Slant_Laptop_: other than that, it works very well, with the caveat that merging upstream changes that move files around (as opposed to just changing their contents) will trigger spurious conflicts, that's probably unfixable before the nested trees support lands in, rendering merge-into obsolete
<Slant_Laptop_> Hmm, gotcha.
<poolie_> igc, yes, that seems to be the problem with status
<poolie_> so that's kind of nice
<Peng> Oh, I forgot. 0.91 adds -c. Yay!
<Lo-lan-do> What -c?
<Peng> bzr diff and other commands.
<Lo-lan-do> Oh, cool.
<Lo-lan-do> Although I prefer diff -u myself :-)
<Peng> -c revision means changes introduced by that revision.
<Peng> Oh, not *that* -c.
<Lo-lan-do> Ah.
<lapthrick> Peng: h? How is that different from what diff normally does?
* lapthrick checks to see if gutsy has 0.91 yet
<Peng> lapthrick: Instead of having to do 'bzr diff -r 99..100', you can do 'bzr diff -c 100'.
<lapthrick> ah
<lapthrick> handy
<Peng> Also useful when dealing with a huge revno from a bunch of merges.
<lapthrick> I was annoyed by the -r99..100 thing
<poolie_> night all
<gabe> hi all
<matkor> Hi ! One can safely edit .bzrignore files ? I would like to remove some bad patterns from it ? TIA
<Peng> matkor: Yes.
<matkor> Thank you Peng !
<Peng> :D
<lapthrick> jelmer: you have a new bug report awaiting
<lapthrick> jelmer: I actually discovered that while trying to reproduce another bug I ran into in my test repo, where bzr missing shows extra local revisions, yet bzr push says nothing to push
<lapthrick> jelmer: there's definitely something wrong going on with diverged branches logic, first is that "can't push, can't merge" bug, then is that "nothing to push" (which I ran into trying to create a minimal testcase for the push bug)
<matkor> Hmmm From where I can download bzr-gtk 0.91.0 ?
<lapthrick> matkor: I don't think there is bzr-gtk 0.91
<lapthrick> matkor: anyway, just grab it from the plugins page
<lapthrick> oh wait, it is synced
<lapthrick> matkor: https://launchpad.net/bzr-gtk/0.91/0.91.0/+download/bzr-gtk-0.91.0.tar.gz
<matkor> lapthrick: Thanks !
<pbor> lapthrick: do you have a ~ on gnome.org ?
<lapthrick> pbor: unsure, I know I have an SVN account
<pbor> no, that's unrelated
<pbor> lapthrick: pushing there with bzr push sftp takes forever (I mean it's been running for three hours and it is not even 50% of 1/4)
<pbor> I was wondering if it is normal or related to gnome.org
<lapthrick> no idea
<lapthrick> pbor: how big is the push?
<lapthrick> if it's pushing afresh, then you want to use rspush instead
<pbor> pushing with sftp to localhost took some minutes
<pbor> lapthrick: the gedit repo, so pretty big
* pbor tries rspush
<pbor> does that accept --create-prefix ?
<pbor> it is not mentioned in the help...
<lapthrick> dunno
<lapthrick> pbor: but it's a shitload faster, since it uses rsync
<pbor> lapthrick: execept that I get a traceback :/
<pbor> bzr: ERROR: bzrlib.errors.ObjectNotLocked: <WorkingTree4 of /home/paolo/bzr/gedit> is not locked
<lapthrick> ugh?
<lapthrick> pbor: no idea what it means, I never got it
<pbor> bzr doesn't like me apparently
<lapthrick> jelmer: I was able to pull command log out of .bash_history, it's now reported as https://bugs.launchpad.net/bzr-svn/+bug/145165
<ubotu> Launchpad bug 145165 in bzr-svn "bzr missing reports extra revs, yet push says nothing to do" [Undecided,New] 
<lapthrick> pbor: well, look at it another way: we whack the bugs now so it's awesome later :)
<lapthrick> pbor: also, I'd definitely report that one
<pbor> lapthrick: yeah, I started reporting the bugs I am running into
<pbor> speaking of which, before I report a bogus bug, is this request reasonable:
<lapthrick> pbor: btw, you can just rsync the branch over, it will work just as well
<pbor> pull, hack, [someone commits an unrelated change to svn] , merge, commit, push
<pbor> now two revisions are pushed to svn
<pbor> my hack
<pbor> and the merge
<pbor> could bzr be smart enough to avoid the 'merge' revision?
<mwh> pbor: presumably your 'hack' included committing?
<pbor> it's already in svn, that's where I pulled it from
<pbor> mwh: sure
<pbor> (sorry for omitting that)
<mwh> i think the same would happen with pushing to a bzr repo then
<pbor> yes, I do not think it is specific to svn
<pbor> but it (IMHO) sucks a bit
<mwh> i think a common pattern is "only merge to mainline"
<pbor> it means that for instance I'll have all the commts to po files by translators twice in the history
<mwh> eh, that probably doesn't make sense
<pbor> well, if I do not merge into my tree it doesn't let me commit
<mwh> but anyway, you seem to be asking for a situation where you have a revision in your branch
<mwh> then after a push, that revision is _not_ in the target branch
<mwh> that seems to violate a pretty important invariant...
<pbor> mwh: I know, in fact I would be happy to avoid the merge if I could
<pbor> mwh: what I am saying is that that revision is already in the 'upstream' branch
<pbor> that's where I get it from
<pbor> (because I am forced to)
<mwh> but the result of the merge is a separate revision (what if there were conflicts?)
* mwh wishes for a blackboard
<lapthrick> heh
<pbor> ok, but there weren't... I am asking if there is a workflow to avoid that: in fact (but I still have to try) I think I can do this:
<pbor> keep two branches: one mirrors upstream
<jelmer_> 'morning
<lapthrick> pbor: besides, the merge results are only shown in the history of the branch that did the merge in the first place. When you commit, the upstream history will only have a revision that says "pbor: merged from upstream"
<pbor> every time I want to commit I sync the mirror and then merge my hacking branch and then push
<lapthrick> jelmer_: hiya, can you read jelmer's backlog?
<mwh> pbor: right, i was going to suggest a different approach here...
<lapthrick> jelmer_: I reported a couple of bugs
<pbor> mwh: that should work but it's a bit of a PITA :-)
<lapthrick> jelmer_: and I still have that diverged branches bug, except that I can't even do a merge to fix it
<lapthrick> pbor says it doesn't happen for him in 0.4.3 tarball, I'm running r719 tho
<mwh> pbor: well, in True Distributed Style (tm) you only should only merge to mainline and push when your branch is done (bug fixed, new feature working, etc)
<lapthrick> pbor: actually, could you try if you get that bug with the latest rev of http://people.samba.org/bzr/jelmer/bzr-svn/0.4/ ?
<mwh> if, in effect, you're using subversion to share your changes then yeah, it's a bit of a pain
<pbor> lapthrick: which bug?
<pbor> oh, got it
<lapthrick> pbor: bzr push reporting that branches have diverged
<pbor> lapthrick: mmm... I'll try it later, right now I have no pending changes to commit and I'd prefer to avoid bogus test changed in the upstream gedit svn repo
<pbor> lapthrick: I am already waiting to flamed since my commit touched all the files :)
<lapthrick> pbor: okay, as long as you remember to do it :)
<lapthrick> pbor: hehe, because of bzr-svn?
<pbor> yeah
<lapthrick> how so?
<pbor> no idea... probably the properties
<jelmer_> pbor: it's only viewcvs that reports all files as changed
<jelmer_> pbor: if you use 'svn log', you'll see there are only a few files changed by that commit
<pbor> jelmer_: yeah, but I don't think viewcvs is psychic so something must have happened in the repo
<pbor> :)
<jelmer_> pbor: Replying to your bugreport atm
<pbor> jelmer_: thanks!
<lapthrick> jelmer_: I don't see the DivergedBranches bug reported anywhere (not in 0.4 anyway). should I go and create it?
<jelmer_> lapthrick, which bug do you mean exactly?
<jelmer_> ok, I'm off again - will reply to the bugs later today
* pbor goes to lunch too
<lapthrick> jelmer_: uh-oh, yet more bugs
<ubotu> New bug: #145170 in bzr "traceback doing rspush (bzrlib.errors.ObjectNotLocked)" [Undecided,New]  https://launchpad.net/bugs/145170
<lapthrick> so do people actually practice DAGgy bugfixes? Does it work well?
<lapthrick> ( http://www.venge.net/mtn-wiki/DaggyFixes )
<mwh> lapthrick: i think, in practice, "no"
<mwh> people don't do that
<lapthrick> because it's a bother, or because it doesn't work?
<mwh> because it's a bother
<mwh> just my impression of course, both the bzr using projects i follow closely (bazaar and launchpad) have a pretty centralized model in some ways
<mwh> (i.e. a mainline that contains or will contain almost everything interesting)
<mwh> the kernel folks may have a different view
<nocturn> Hi all
<nocturn> What is the difference between bzr merge and bzr merge --pull?  In what circumstances do you use --pull?
<AfC> nocturn: if the thing you're merging actually supersedes the current branch (ie has only got things that you don't have) then you can pull them in on top instead of the revision graph doing a zig-zag
<lapthrick> nocturn: it's a shortcut
<lapthrick> nocturn: equivalent to bzr merge && bzr commit && bzr pull
<AfC> nocturn: frankly I don't bother anymore, in no small part because our 'mainline' has almost always moved on since the contribution
<AfC> lapthrick: It often seemed to me that `bzr pull` should just do that automatically if it isn't a "needs [manual]  merge"
<AfC> seems a bit silly to have the question arise
<lapthrick> AfC: somewhat, yeah
<ike> Hello. I have a problem and i'm kinda confused now. Maybe i'm missing something or so. I cannot push my repository to remote server.
<ike> This is what bzr says:
<ike> LPA:~/Projects/Repositories/bzr/bffrg ike$ bzr push  bzr+ssh://ike@lu/repository
<ike> bzr: ERROR: Generic bzr smart protocol error: Permission denied: u'//repository': [Errno 13]  Permission denied: '//repository'
<AfC> lu is a server name that resolves, with /repository in its root directory?
<ike> And now - i can log into server 'lu' user 'ike' using my keys so.
<ike> Yes. Lu resolves.
<ike> But /repository doesn't exist.
<ike> Hm.
<ike> I get it. Thanks.
<ike> :-)
<ike> Sorry for trouble.
<AfC> It's a bit ugly, actually:
<AfC> we have things set up so that
<AfC> http://research.operationaldynamics.com/bzr/java-gnome/mainline is equal to
<AfC> bzr://research.operationaldynamics.com/bzr/java-gnome/mainline , but for writing (push) it is
<AfC> bzr+ssh://centauri.lhr.operationaldynamics.com/export/web/com/operationaldynamics/research/bzr/java-gnome/hackers/andrew/treeview/
<AfC> which is unfortunate
<ike> Kinda.
<AfC> the only workaround would be a symlink called bzr in /. Somehow that doesn't seem quite right.
<ike> No. That's too ugly. ike@lu/home/users/ike/repository is fine.
<ike> Hm. I still have an error. bzr: ERROR: exceptions.AssertionError: end of file reading from server.
<ike> Whole traceback : http://paste.debian.net/38066
<ike> I'll try to figure this out, but if you guys have any suggestions - don't hesitate to tell.
<ike> :-)
<nocturn> Thanks lapthrick and AfC
<AfC> ike: you could upgrade to 0.91 seeing as how you're running your own code anyway
<AfC> That'd be the usual start
<sabdfl> was 0.91 released today?
<AnMaster> what do I do to update the repo location in a --lightweight checkout
<AnMaster> the repo moved
<AnMaster> but I got uncommited changes so doing a new --lightweight checkout wouldn't be an optimal solution
<Odd_Bloke> AnMaster: 'bzr bind <new location>' is probably what you want.
<AnMaster> bzr: ERROR: Not a branch: http://url.here/
<AnMaster> and that url is the old location of the repo
<AnMaster> Odd_Bloke, so it tries to bind the repo of the old checkout
<AnMaster> this is a --lightweight checkout, not a full one
<Odd_Bloke> AnMaster: OK, try 'bzr unbind' followed by that command...
<AnMaster> $ bzr unbind
<AnMaster> bzr: ERROR: Not a branch: http://url.here/
<AnMaster> :/
<AnMaster> Odd_Bloke, any idea?
<Odd_Bloke> AnMaster: Hmm, those're all the suggestions I had.  I don't really use lightweight checkouts in anger. :/
<lapthrick> AnMaster: try bzr shelve, then do a new lightweight checkout
<AnMaster> lapthrick, that shelve also returns bzr: ERROR: Not a branch: http://url.here/
<AnMaster> I guess new checkout and then copy files over is the only way
<AnMaster> lapthrick, there should be a way to repoint where the repo is if the repo has moved
<AnMaster> lapthrick, like svn switch --relocate
<lapthrick> AnMaster: there should be
<lapthrick> oh right
<lapthrick> AnMaster: there's bzr switch
<lapthrick> which does that
<AnMaster> Purpose: Set the branch of a lightweight checkout and update.
<AnMaster> ah!
<AnMaster> this may work
<AfC> `bzr pull --overwrite` is a core command that will switch branches quite emphatically.
<AnMaster> lapthrick, good but if the repo already moved it still tries to access the old repo first and fails
<AnMaster> like happened now
<mwh> there's a bug about that somewhere
<mwh> vim .bzr/branch/<something> might work...
<AnMaster> nano but hm
<AnMaster> or emacs
<mwh> this is not the important detail :)
<mwh> (though, nano?? ew)
<AnMaster> mwh, nano or emacs, but better just say $EDITOR
<AnMaster> :)
<Odd_Bloke> Ew, emacs.  Stick with nano. ;)
<lapthrick> eww nano and vi
<bwinton> Stick with Notepad!
<lapthrick> (though I actually use nano for my commit messages, too lazy to set up $EDITOR)
* Odd_Bloke doesn't have $EDITOR set but bzr still uses vim for my commit messages.
* AnMaster mostly uses -m 'Message here'
<AnMaster> though:
<AnMaster> $ echo $EDITOR
<AnMaster> /usr/bin/emacs
<AnMaster> :)
<AfC> A bit hard to do good quality multi line messages with -m
<AnMaster> AfC, that is true
<AnMaster> but well, it depends on how big changes you do
<Lo-lan-do> I have started using -mm for really minor commits
<Lo-lan-do> Typos and the like.
<AnMaster> interesting in a repo (as in init-repo)
<AnMaster>  $ bzr st
<AnMaster> bzr: ERROR: [Errno 2]  No such file or directory
<AnMaster> it should say like when it is not a branch or repo:
<AnMaster> $ bzr st
<AnMaster> bzr: ERROR: Not a branch: /some/dir
<AnMaster> or maybe "not a branch, this is a repo)
<AnMaster> or something like that
<AnMaster> but the "no such file or directory" seems bad
<lapthrick> Lo-lan-do: what's -mm?
<Lo-lan-do> Use "m" as a commit message?
<AnMaster> that isn't very informative
<Lo-lan-do> As in "minor fix"
<AnMaster> bzr ci -m 'Fixed typo'
<AnMaster> or something like that is what I do
<AnMaster> or even
<AnMaster> bzr ci -m 'Fixed typo in log message in src/foo.c'
<Lo-lan-do> Well, I don't really need much information in commits on my blog entries.
<AnMaster> blog? what do you mean?
<AnMaster> what has blog got to do with bzr?
<Lo-lan-do> And I like important commits to stand out and not be drowned under big but useless messages.
<Lo-lan-do> I use ikiwiki for my blog.  I edit articles on a local copy (it's an SVN checkout, but whatever), and the HTML gets generated and pushed online with a commit hook.
<AnMaster> hm
<AnMaster> interesting
<Enquest> I don't understand the how to publish my webproject
<Enquest> I try to use the push command but it only creates a .bzr file in the destination dir
<Odd_Bloke> Enquest: You'll need to also checkout a working directory there.
<schierbeck> p
<Enquest> What is the difrence then?
<Enquest> why use push then?
<Odd_Bloke> Enquest: At the moment, you have pushed the branch and repository, which is enough for a branch which is just being served.  If you also want the contents reconstituted there, you need to create a checkout (look at the push-and-update plugin at https://launchpad.net/bzr-push-and-update/).
<Enquest> is the bazaar server down... No response of the website?
<mwh> the canonical data centre is having a bad day, it seems
<Odd_Bloke> :(
<gabe> it seems the ubuntu forums are shot away, at least for me
<gabe> :(
<Enquest> how do I deploy my website in best. Know that some info changes... like some PATH info and mysql settings ?
<Enquest> What is the best way to avoid every update to my website changing those paths
<gabe> use relative paths where possible?
<sabdfl> mwh: it's upstream ISP, not the data centre itself, afaik
<mwh> sabdfl: ah right
<Mez> is ther eanywhere that I can show someone an example of bzr#'s "much better branching and merging" to try and convionce the people ar work regarding it?
<radix> argh, "bzr log |head" in gutsy causes a crash report dialog to pop up :\
<fullermd> lapthrick, mwh: I daggy sometimes, when I think there's a good chance it'll be useful.  Not as a reflex, though.
<AnMaster> radix, shouldn't it simply dump core?
<AnMaster> <-- not ubuntu user
<AnMaster> but "crash report dialog" sounds too much like windows for me
<radix> AnMaster: well, the issue is that "bzr log |head" raises an exception in bzr now
<radix> it's an old bug that was fixed and seems to have regressed back
<AnMaster> radix, that sucks, but what I wondered about was why it simply doesn't dump core / traceback, why a *dialog* poping up for it
<AnMaster> that would only work inside X
<AnMaster> breaks horribly if you aren't running X atm
<radix> AnMaster: forget the dialog :)
<radix> AnMaster: it's not related to bzr
<AnMaster> radix, I use freebsd mainly, a dialog poping up sounds way too much like windows
<radix> AnMaster: I'm sorry you feel that way
<AnMaster> radix, thanks for the warning though, I will avoid ubuntu now, I prefer to work from command line
<AnMaster> :)
<AnMaster> (but indeed this isn't a flamewar channel)
<radix> fwiw, nothing bad happens if you're not in X
<AnMaster> that is at least a good thing, but even in X I prefer getting a core dump / python traceback
<radix> you still get those.
<AnMaster> I will stay with FreeBSD, slackware and gentoo :)
<dato> radix: hm, I don't get an exception with bzr.dev
<dato> ah
<dato> but gutsy is closed
<radix> maybe it was refixed
<radix> 0.90.0 seems to be raising the exception
<dato> right, here too
<dato> but 0.91 not
<radix> cool
<AnMaster> radix, um on gentoo with 0.90.0 bzr log | head does NOT cause any traceback
<AnMaster> and there is almost 500 revs in this project
<AnMaster> $ bzr --version
<AnMaster> Bazaar (bzr) 0.90.0
<pbor> jelmer: "if you would like to avoid this, use the 'rebase' command, which makes sure history stays linear"... I can't see any rebase command, can you give me a link?
<Lo-lan-do> pbor: It's an external plugin
* pbor looks
<pbor> thanks Lo-lan-do
<pbor> whooo... that looks *really* interesting
<pbor> I guess that it would allow me to adapt my workflow with svn
<pbor> I just need to rebase before pushing
<pbor> so that I do not need to merge the translator chnages
<pbor> jelmer: so if I understand correctly, the fact that all the files where "touched" is due to the fact that there was a commit to svn between the time I pulled and the time I pushed? So if did rebase before pushing I would have avoided the problem with viewcvs?
<jelmer> pbor: The rebase plugin is listed on the plugin page
<jelmer> pbor: the fact that you merged upstream at some point causes the problem
<pbor> jelmer: so if I rebase instead of merging I avoid the issue
<jelmer> yep
<pbor> neat
<Lo-lan-do> Hmm.  Would that apply to me too?
<jelmer> I'd recommend using the 0.1 version of rebase though, current trunk is a bit unstable
<pbor> jelmer: will rebase in the future also allow to "squash" changeset together?
<jelmer> pbor: not really... why would you want to do that?
<james_w> pbor: you will be able to do that with pure bzr soon.
<pbor> jelmer: suppose on the branch I have two changesets: "Implement feature X" and "ops fix compilation", now when I want to rebase it against the main repo I want also to just have one changeset and "delete" the typo from the history
<pbor> james_w: awesome
<GaryvdM> Hi phanatic
<phanatic> hey Gacha
<phanatic> heh
<phanatic> sorry
<phanatic> GaryvdM :)
<GaryvdM> I can't decide what I want to work on next
<GaryvdM> Either
<GaryvdM> https://blueprints.launchpad.net/bzr-gtk/+spec/gannotate-viz-integration
<GaryvdM> https://blueprints.launchpad.net/bzr-gtk/+spec/viz-pending-merges
<GaryvdM> or
<GaryvdM> https://bugs.launchpad.net/bzr-gtk/+bug/127734
<ubotu> Launchpad bug 127734 in bzr-gtk "Progress bars as widgets" [Medium,Triaged] 
<phanatic> GaryvdM: fixing the progress bars would be really awesome
<GaryvdM> Right thats what I'll do, but I need some clarification on what we want :-)
<GaryvdM> I thnk I'm going to flesh out a blueprint before I start coding...
<pbor> you guys work on the gtk ui?
<GaryvdM> Yhea
* pbor noticed some buglets
<phanatic> pbor: yep, feel free to report them, we're actively squashing bugs ;)
<pbor> well, not bugs but things that could be better wrt to gtk
<phanatic> GaryvdM: cool. the basic idea is to fix the progress bars. now they are 1) ugly 2) don't close automatically
<phanatic> pbor: please share your thoughts with us
<GaryvdM> And it would be nice if they we intragrated in to the existing ui?
<pbor> like the gstatus missing the proper shadow type in the scrolled window and having a horizontal separator that should not be there
<pbor> or why visualise doesn't use a toolbar dor the back/forward buttons at the top
<phanatic> GaryvdM: exactly, now they are separated a bit
<GaryvdM> Cool
<pbor> gmissing is particularly ugly with those frames
<phanatic> pbor: these are still bugs in my opinion :/
<pbor> I guess my eye is too used to the HIG-police :)
<phanatic> yeh, i'm pretty sure that there are quite a few HIG-unaware stuff unfortunately
* GaryvdM starts reading HIG section on progress windows and bars
<pbor> for prgress bars the easiest thing is probably put it in a statusbar
<pbor> unless you want to do something fancy as gedit message area
<pbor> but you'd need to redo that widget from scratch in python
<GaryvdM> Sorry -  I have now idea what the gedit message area looks like
<GaryvdM> I work mostly on windows...
<pbor> GaryvdM: open a file long a few pages in gedit and do print preview
<pbor> ah ok
<pbor> GaryvdM: something like http://www.gnome.org/~paolo/screenshots/new_mdi/open-progress.png
<pbor> (that screenie is a bit old)
<GaryvdM> Thats cool.
<GaryvdM> That would better for something like gcommit where we need to cater for both olive and gcommit.
<phanatic> yep
<pbor> btw, the olive toolbar doesn't respect my toolbar settings
<GaryvdM> And I think some operations might meret a Checklist Window.
* pbor vanishes... later guys
<phanatic> pbor: thanks for you valuable comments
<Peng> "``Transport.should_cache`` has been removed." is listed twice in NEWS for 0.91rc1 or whatever, undder both "API breaks" and "Testing".
<bialix> hi people
<dato> jelmer, siretart: I uploaded bzr 0.91 and bzr-gtk
<dato> james_w: I'll do bzr-builddeb tomorrow
<james_w> dato: thanks.
<james_w> phanatic: in notify.py it should be  self.zeroconfserver.run() rather than .start()
<phanatic> james_w: thanks, but i don't really know that part of the code, since it's pretty new, and i still couldn't catch up with that part (i was away on a soc duty with gnome)
<james_w> I've tested the fix, it was just late, and seemed a little trivial for bug report/patch. Are you ok to just make the fix?
<phanatic> sure, thanks again!
<james_w> no problem.
<siretart> dato: thanks!
<lifeless> jelmer: 06:01 < jdub> lifeless: that whole svn-upgrade problem still exists -- no bzr-rebase in the repos, so can't do anything with bzr-svn atm
<lifeless> james_w: are you aware of pull --merge ?
<bratsche> Hi guys, I might have a small but annoying bug here.. or maybe I'm doing something wrong.
<bratsche> I do: bzr diff -r ancestor:url-to-my-ancestor-branch
<bratsche> It works fine if that url starts with sftp:// but it fails and crashes bzr if that url starts with bzr+ssh://
<dato> lifeless: do you mean `merge --pull`?
<bratsche> Is there something obvious I'm doing wrong, or is this a bzr bug?
<lifeless> dato: something like that; james wrote a bzr-for-git page, and it says that we always do a commit to merge branches where git does, but this is bogus. Git simply chooses not to do a merge some of the time.
<lifeless> and we have that as an option - merge --pull
<lifeless> s/does/does not/
<lifeless> bratsche: I think its a bzr bug
<bratsche> lifeless: Seems like maybe the + is confusing the commandline arg parser, but I'm not sure.
<lifeless> 0
<lifeless> bratsche: could be
<lifeless> bratsche: file a bug ?
<bratsche> Okay, sure.
<bratsche> Where is bzr's bug tracker?
<james_w> lifeless: yess, why?
<lifeless> https://launchpad.net/bzr/
<bratsche> Thanks
<james_w> lifeless: ah, I see now. I'll update the page.
<lifeless> james_w: you say that 'merges in bzr require a commit regardless of conflicts'. Its not clear to me whether you are talking about git fast-forward, or if git automatically does a commit for you ?
<lifeless> if you are talking about fast-forward, thats actually a case of skipping a merge, rather than not requiring a commit
<james_w> yeah, it also automatically commits when there are no conflicts, so both need to be highlighted.
<lifeless> if you are talking about git doing a commit for you, thats dangerous (because  textual conflicts are not a good indicator of semantic conflicts), and its worth noting why we don't autocommit there
<lifeless> (there was a thread on the hg list about exactly the same behaviour just this week)
<james_w> yeah, I was trying to avoid editorialising, I got a bit close with the left hand parent discussion, but it's obviously an evolution, so we can decide whether to include that there, or have another section for some 'why we think bzr is better' comments.
<lifeless> ok, so concretely then ...
<lifeless> we can fast forward
<lifeless> so how it feels different can say 'bzr will fast-forward merges if you supply --pull'
<lifeless> (rather than by default)
<lifeless> but when it cannot fast forward it requires a commit be done
<lifeless> or someting like that
<lifeless> we don't want a page that a git user that things git is just perfect can point at and say 'look at all the differences, thats why I don't use bzr'
<lifeless> mmm, I think I'm saying 'vive la difference'
<lifeless> excuse the mangled french :)
<lifeless> bbiab
<james_w> yeah, I'll clean that page up.
<ubotu> New bug: #145383 in bzr "bzr fails with diff -r ancestor:bzr+ssh://branchname" [Undecided,New]  https://launchpad.net/bugs/145383
<lapthrick> does ubotu announce bzr-svn bugs too?
<jelmer> lifeless: sorry about that, it's still on my todo list
<jelmer> lapthrick, no[e
<jelmer> s/[/p/
#bzr 2007-09-27
<lapthrick> jelmer: it seems that that svn branch of mine got completely botched
<lapthrick> bzr missing svn://parent reports entire history to be missing on both sides
<lapthrick> that's rather unfortunate, as I will have to re-do the changes I already committed in it
<lapthrick> does shelf provide any way to export shelved patches?
<LeoNerd> They're just plain .diff files
<LeoNerd> Go take a look at e.g.  .shelf/shelves/default/00
<lapthrick> LeoNerd: I guess, but I dunno where they live :)
<LeoNerd> (I specifically know they're plain patches because they blow up if you rename a file while it wasn't looking)
<LeoNerd> (whereas tla/baz "undo" facility works fine)
<abentley> lapthrick: but also, depending on why you want that, you may find merge --uncommitted useful.
<lapthrick> I want that because an svn branch of mine broke :\
<lapthrick> and I'm carrying over the changes to a fresh one
<abentley> so if you unshelve and run diff, does it show all your changes?
<lapthrick> actually it seems I have no changes shelved in that branch, I got confused
<bicchi> Would anyone know if version 0.91 will make it into gutsy?
<lapthrick> bah
<lapthrick> another error
<lapthrick> :(
<Peng> Does anyone in the world have bzr+http working?
<LeoNerd> I presume for that to work, some sort of (Fast)CGI app is needed
<Peng> Yes.
<Peng> It's very simple.
<Peng> And it doesn't work.
<Peng> I want to know if anyone has it working so I can see what I'm doing wrong.
<lifeless> Peng: when you say it doesn't work, what happens
<Peng> Hold on.
<Peng> http://privatepaste.com/44AFaH6wN7
<Peng> Eh, oops.
<Peng> Anyway
<Peng> I meant to obfuscate my email address in that.
<lifeless> oh hmm, no browser here at the moment
<lifeless> is it long?
<lifeless> could you /msg it to me ?
<Peng> Eh. Not that long.
<Peng> hold on.
<Peng> '$ echo hello | POST http://bzr.mattnordhoff.com/bzr/.test/.bzr/smart' returns ok2
<Peng> '$ time bzr log bzr+http://bzr.mattnordhoff.com/bzr/.test$ time bzr log bzr+http://bzr.mattnordhoff.com/bzr/.test' says 'bzr: ERROR: Not a branch: "bzr+http://bzr.mattnordhoff.com/bzr/".'
<Peng> But with regular http, it works.
<Peng> Oops. How did I paste that twice?
<Peng> I blame my keyboard!
<poolie__> hello
<lifeless> Peng: what version of the smart server?
<lifeless> Peng: I bet that you are being bitten by the bug where the relpath must match inside and outside apache
<lifeless> I don't know if that is fixed or not
<Peng> lifeless: 0.91. And that could be it. My homedir is a symlink.
<Peng> What, what's the bug, exactly? And what's the workaround?
<lifeless> Peng: hi
<lifeless> the problemi s that bzr sends in its protocol a path like
<lifeless> /foo/bar
<lifeless> to a url like
<lifeless> http://host/bzr/foo/bar/.bzr/smart
<lifeless> and on the server process that is mapped
<lifeless> so /bzr/foo/bar might be /home/bzr/~public_html/foo/bar
<lifeless> and finally chrooted
<lifeless> so '' inside bzr means /home/bzr/~public_html/foo/bar
<lifeless> but we sent '/foo/bar'
<lifeless> so you actually end up accessing /home/bzr/~public_html/foo/bar/foo/bar
<lifeless> which of course, does not exist
<igc> morning
<lifeless> and we don't know on the client where the chroot point is, s o we cannot do path calculations to send less, sanely.
<lifeless> hi igcv
<Peng> lifeless: Well, I'm not chrooted.
<lifeless> Peng: its a bzr software chroot
<Peng> Oh.
<lifeless> so that people cannot ask for /etc/passwd
<Peng> Yeah.
<Peng> Well, what's the workaround?
<lifeless> one is to make the duplicated path segments exist
<lifeless> in your case, I'm guessing, movig bzr/.test on bzr/.test/bzr/.test
<lifeless> just on the server
<lifeless> may well work
<lifeless> or
<lifeless> possibly symlink bzr/.test/bzr/.test to ../..
<Peng> Err.
<lifeless> how often are workarounds pretty ?
<Peng> :(
<Peng> So until then, what, bzr+http is completely nonfunctional?
<lifeless> it works if your paths line up
<lifeless> there is a high severity bug on this
<Peng> Oh.
<Peng> Does anybody have their paths lined up?
<lifeless> yeah, we did when we tested it lol
<lifeless> abentley: ping; is there a method to get an inventory delta from two trees/two inventories ?
<Peng> Well, I guess the bug 107161 guy got bzr+http to run. So it's not impossible.
<ubotu> Launchpad bug 107161 in bzr "http smart server performance is far worse than http alone" [Medium,Incomplete]  https://launchpad.net/bugs/107161
<AfC> Actually I never got it to work. Debugging it was too hard.
<Peng> Okay, https://bugs.launchpad.net/bzr/+bug/119330/comments/8 has a good explanation of the path issues.
<ubotu> Launchpad bug 119330 in bzr "bzr+http mod_python wsgi issues" [Undecided,New] 
<Peng> Hey, awesome!
<Peng> In /bzr, I added a symlink to . so /bzr/bzr/bzr/bzr ... works.
<Peng> Now I get a different error! :)
<Peng> AttributeError: 'DisabledTags' object has no attribute 'get_reverse_tag_dict'
<lifeless> ok, I think that is fixed in bzr.dev
<Peng> Newer than 0.91?
<lifeless> yes
<Peng> Hey, cool.
<Peng> Oh, yes, 2867.
<Peng> It sucks that hg can only use a smart server, but at least its smart server works!
<abadger1999> hg can use plain http as well... just not very well.
<Peng> That's true.
<Peng> So, then, I could say in #mercurial, "It sucks that bzr can't use a smart server, but at least its dumb server works!".
<abadger1999> heh.  As long as you have your asbestos suit +2 equiped :-)
<Peng> Haha.
<jelmer> Peng: the smart server is also available over plain tcp/ip or ssh
<jelmer> the latter two are better supported than http
* jelmer wasn't even aware it wokred over http :-)
<Peng> jelmer: I know that. In fact, I use bzr+ssh. I just thought "can't" sounded better. :)
<AfC> bzr 0.91 is in Gentoo now, btw
<Peng> Hey, no version of bzr is marked as stable. :(
<poolie> in where?
<Peng> Gentoo.
<lifeless> Peng: seems appropriate, it is Gentoo
<lifeless> AfC: thanks!
<lifeless> igc: hi
<lifeless> igc: I think you did two reviews, one I've submitted the other replied to; any chance of some more today ?
<igc> Probably ...
<igc> I'm flat out putting together a 3 hr tutorial for ODSC today ...
<igc> but I'm keen to keep you moving :-) :-)
<lifeless> igc: rotfl, sorry, but I've had to just mini rant at you; I couldn't contain myself.
<igc> lifeless: hasn't arrived yet. Looking forward to it :-)
<lifeless> should be there now ;)
<igc> yep :-)
<lifeless> igc: :)
* igc food
<abentley> lifeless: I don't think there is a method for that.
<lifeless> abentley: I've whipped up a test helper
<Gacha> I'm trying to ignore a single file, but it doesnt work - bzr ignore ./top/settings.py
<Gacha> when I run bzr ignored the wile isn't there
<Gacha> not wile but file
<Peng> Gacha: Well, that should work, as long as 'top' is in the root directory of the branch.
<Gacha> I know, but it doesn't
<Peng> Heh.
<Peng> Yeah, "it's supposed to work!" isn't a very useful answer, is it?
<lifeless> Gacha: can you cat .bzrignore please
<lifeless> I don't have a browser right now; so either paste it here or /msg it to me
<Gacha> ./top/settings.py
<lifeless> ok
<lifeless> next thing is that adds overwrite ignores
<lifeless> so try bzr rm --keep top/settings.py
<Gacha> but if I want that the settings.py is a part of the project after doing checkout
<Gacha> but when doing changes it should ignore them
<lifeless> oh
<lifeless> this is not what ignores do :)
<Gacha> because settings.py can be different
<lifeless> ignores are for files you don't want to be part of the project.
<lifeless> I can offer a work around; we are discussing on the list at the moment a 'readonly' flag that would probably do what you want; you might want to peek at that discussion thread
<lifeless> the workaround is -
<lifeless> have a file, 'settings.py.default' or something like that
<Gacha> nice idea
<lifeless> have your build process - setup.py, or Makefile, can copy that to settings.py IFF settings.py does not exist
<Gacha> ok, I will try
<lifeless> anyhow, I realise this is not as ideal as having the VCS manage this for you
<Gacha> when the readonly feature will be?
<lifeless> but, we may be able to manage it directly in the future
<lifeless> well, its early days of discussion now
<Gacha> ok
<lifeless> if you would use this, I encourage you to get involved in the discussion
<lifeless> simply because that will give the folk considering how to implement it more input on how you, the user, expect it to work
<Gacha> in launchpad?
<lifeless> the bazaar mailing list
<Gacha> ok
<lifeless> there is a link to that from http://bazaar-vcs.org/
<poolie> lifeless, still around?
<lifeless> yeth
<poolie> can i call?
<lifeless> bit later would be better
<lifeless> say 5 sharp ?
<lifeless> sorry, phone is in other room
<poolie> np, call whenever you're ready
<poolie> lifeless, on phone atm
<lifeless> lol
<lifeless> well ring me back
<siretart> dato: yay. it seems neuro has fixed ball's (the mips buildd) chroot! :)
<lifeless> lol, neuro has fixed balls. Quote of the day.
<AfC> I was just thinking that that was one of the less comprehensible sentences I had ever seen.
<lifeless> poolie: will you be long?
<siretart> lifeless: LOL
<siretart> I didn't write that! :)
<siretart> dato: but this time the sparc buildlog looks fishy :/
<lifeless> siretart: you building 0.91 binaries?
<siretart> lifeless: http://buildd.debian.org/pkg.cgi?pkg=bzr
<lifeless> browser is awol
<lifeless> so is that a 'yes' ?
<siretart> lifeless: dato has uploaded 0.91-1 to debian yesterday
<siretart> so, 'no, not be, but the debian buildd network yes'
<siretart> not me, even
<lifeless> cool
<lifeless> cause I need to do the official builds
<lifeless> so his packaging is helpful
<lifeless> :)
<siretart> lifeless: but the alternative build depends is causing lots of trouble
<siretart> After installing, the following source dependencies are still unsatisfied:
<siretart> python-celementtree(missing)|python(inst 2.4.4-6 ! >> wanted 2.5)
<siretart> Source-dependencies not satisfied; skipping bzr
<siretart> that's because some chroots already have the package 'python' installed, which is at version 2.4.4-6 in debian
<siretart> so sbuild fails the build here
<lifeless> thats an sbuild bug right ?
<siretart> in some ways, yes
<siretart> but fixing bugs in the official buildds seems nearly impossible, since neuro is unreachable
<siretart> at least for me
<siretart> well, actually it is a pure sbuild bug. I've mailed neuro and CC'ed our mailing list with an detailed analysis of the problem
<siretart> atm, I think the easiest would be to have more strict build dependencies on debian, and carry a small patch for ubuntu's bzr
<lifeless> so theres a couple of issues here hmm
<lifeless> we should probably build extension modules for multiple pythons
<siretart> 'extension modules'?
<lifeless> we have C extension modules
<siretart> yes
<lifeless> they are specific to the python version
<lifeless> if you use bzrlib via python2.4, you need a 2.4 version of the module
<lifeless> ditto 2.5, 2.6, 3.0
<siretart> and what does this mean wrt packaging
<lifeless> multiple binary packages, one per python version, I presume, or whatever python-magic we have today
<lifeless> but I would expect that to change the source dependencies
<james_w> if you use pycentral and have correct build rule then you get one per python available.
<james_w> build: $(PYVERS:%=build-python%)
<james_w> build-python%:
<james_w>         python$* setup.py build
<lifeless> so how does tis reconcile with sbuild borking on this dep ?
<james_w> then build depend on python-all-dev
<lifeless> surely it's going to be pulling in all the different pythond *anywy*
<james_w> that's due to cleverness trying to avoid trying to pull in celementree which doesn't exist in Ubuntu, but is required on Debian.
<james_w> the method chosen fails if python is already installed as sbuild wont try and remove/upgrade packages to satisfy it.
<indraveni> hi all
<indraveni> I use subversion, and I am working for a linux distibution
<indraveni> and we invite community to work with us on the source,
<indraveni> thus we need to maintain the source in a good version control system.
<indraveni> and I thought of using subversion
<indraveni> BUT
<indraveni> I have seen ubuntu is using Bazaar , and our distro is something like ubuntu distro
<indraveni> so i want to know what are the advantages of Bazaar
<indraveni> and why I should go for Bazaar for maintinaning source for a linus distribution project, which is a huge project
<matkor> indraveni: Check if developement model fits bzr style
<indraveni> what is bzr style ?
<indraveni> matkor, what is bzr style ?
<matkor> multibranch, commits for whole tree
<matkor> subversion IIRC it is server client (checkout) style
<matkor> also check if performance of bzr is enough ...
<indraveni> matkor, bzr also, can act as server / client right ?
<matkor> indraveni: yes
<indraveni> matkor, wnat about security aspects?
<indraveni> matkor, how can I authorize some people to rw, and some to onlt read
<indraveni> in svn, we can control this though apache athz module
<matkor> indraveni: I think it depends on transport used to access remote repository
<matkor> I basically use sftp / local (file) transports so I set proper file ACLs
<matkor> and use ssh key-based auth
<Gacha> how can I export the code from a bazaar banch? When I use export os push command it doesn't copy the full tree
<Gacha> I want to export my code to a production enviroment
<Gacha> without the .zr specific folders and files
<Gacha> I mean, without .bzr files
<matkor> Gacha: export code ? What would be wrong with bzr checkout <repo> ?
<matkor> Gacha: bzr export    also exists but I never used it
<indraveni> matkor, so it cannot be remotely accessed through http protocol ?
<Gacha> bzr checkout I can do on the other enviroment, but not from my current
<Gacha> to do checkout I need to ssh to the production enviroment and then execute the command
<Gacha> but I want to export the data from my local machine to another
<spiv> Gacha: "bzr export" can export the current version of the tree to a directory or a zip file.
<Gacha> but the dir is empty
<Gacha> I found there only .bzr
<vila> indraveni: bzr branches can be accessed via http
<spiv> Gacha: what command did you run?
<spiv> Oh, I misread.
<spiv> Gacha: Most people I think just use rsync for that.
<spiv> Gacha: you can easily tell rsync to exclude the .bzr directory.
<Gacha> I know, but I was thinking maybe there are some special feature for bazaar
<Gacha> ok, I will use rsync
<spiv> You could use "bzr export" to e.g. a zip file, copy that, and then unzip on the remote machine instead, but I don't think that's any easier.
<indraveni> vila, what is the server that it uses ?
<Gacha> thats hard
<Gacha> I want to execute one command then type password and  done
<vila> for read access any http server, for write access you will need a webdav enabled server and the bzr-webdav plugin
<Gacha> spiv: thanks for helping
<vila> but don't expect good performances with webdav
<indraveni> where can i get good document to configure all these ?
<indraveni> i am findnig only 10 pages quick tutorial in bzr website
<vila> if  you control the server you'd better use bzr serve directly
<vila> to publish your branches via http, you just need to have them accessible with whatever access you configure in your web server
<vila> for 'bzr serve' more precise answers I think spiv is the right guy :)
<indraveni> vila, which web server, can i use for http access ?
<vila> indraveni: any http server
<indraveni> vila, i need a document for confugirig all these . please suggest a good one
<spiv> indraveni: any http server that can serve plain files from the filesystem.
<indraveni> spiv, apache is it ok?
<spiv> Yep.
<indraveni> spiv, , i need a document for confugirig all these . please suggest a good one
<spiv> indraveni: a document for configuring apache to serve bzr branches?
<indraveni> spiv, yes
<spiv> indraveni: there isn't much to configure.  You just use the usual <Directory> or whatever sections; it's just the same as serving static HTML as far as apache is concerned.
<indraveni> spiv, if it is html , we place them in /var/www
<indraveni> spiv, for bzr where does we place , the repo could be anywhere
<spiv> indraveni: right, so say you want to publish at http://host/code/, you could simply place the bzr branches in /var/www/code on the filesystem.
<indraveni> spiv, and specicy DocumentRoot /var/www/code ?
<indraveni> will this work out ?
<spiv> Or if you want to keep the branches elsewhere on the filesystem, you could use symlinks or Alias directives or whatever instead.
<indraveni> ok
<spiv> I'm not very familiar with apache directives, but there's nothing bzr specific to doing this.
<indraveni> spiv, and specicy DocumentRoot /var/www/code ?will work ?
<indraveni> ok i will check and let you know
<spiv> Probably.  (Like I say, I'm not very good with apache)
<indraveni> but i think there should something else, s
<spiv> How do you mean?
<indraveni> spiv, i willl check and let you know
<indraveni> implementation gives more ideas
<indraveni> and solutions
<spiv> Ok.
<lifeless> spiv: you know of jam's 'trigger update' plugin?
<poolie> spiv, hi?
<spiv> lifeless: the push-and-update one?  yeah.  It doesn't seem like it would help the "I don't want the .bzr directory" case.
<spiv> poolie: hello
* spiv -> dinner
<lifeless> spiv: oh right; but it does help the 'I want the other files' case :)
<mrevell> igc: ping
<igc> hi mrevell
<mrevell> hi igc, could we organise a time for a quick chat some time?
<igc> mrevell: sure - how does around 24 hours from now sound?
<igc> I'm pretty tired tonight :-(
<mrevell> igc: Yeah, no problem. Either that or when you start your Friday?
<igc> ok - that's usually around 9am my time
<igc> how about I see in you're around ...
<igc> and ping you then?
<igc> s/see in/see if/
<mrevell> igc: Which city are you in? (Just trying to work out what time that'll be for me)
<igc> Brisbane GMT+10
<poolie> i'm going to call it a night
<igc> night poolie
<poolie> igc, if you're tired maybe you should go home too
<poolie> mentally i mean
<mrevell> igc: Oh right, yeah, silly me - that's midnight for me. Okay, could we say 18.00 your time Friday?
<igc> dinner is real soon now
<igc> mrevell: yes, that's no problem
<mrevell> igc: Thanks, I look forward to it :)
<igc> cool
<lifeless> night poolie
<ubotu> New bug: #145511 in bzr "compiled dirstate extension breaks hashcache" [High,In progress]  https://launchpad.net/bugs/145511
* igc food - night all
<lifeless> night all
<dato> siretart: cool (re ball's chroot)
<dato> siretart: but now we have the same story with sparc
<siretart> dato: right
<siretart> dato: lifeless was thinking about introducing extension module packages to work around that
<dato> a package doing what exactly? and how would it help?
<dato> the real question would be if the ubuntu autobuilders can cope with 'B-D: python-celementtree | python (>> 2.5)'. I can't remember if we got that answered or not.
<lifeless> build arch-any for the non-C code
<lifeless> sorry
<lifeless> bleh, I forget which is -all and which -any
<lifeless> but we only need to build the extensions per arch
<lifeless> and building the extensions does not need celementree etc etc
<lifeless> *also*, we don't need celementree for the package build, FWIW
<dato> ah, that last statement is way more interesting
<dato> it was in build-depends when I first touched the package, so I never questioned whether it was
<lifeless> celementree is purely performance optimisation
<siretart> that would make things lots easier here...
<dato> oh yes.
<siretart> lifeless: is python-paramiko necessary at build-time?
<fullermd> No.
<fullermd> I don't think _anything_ is needed at build time, except python (and cc if you're building the C .so's).
<lifeless> pyrex to do .pyx -> .c
<lifeless> (if building from bazaar, rather than tarball)
<lifeless> if you run the test suite
<lifeless> then paramiko, medusa, python-crypto (for old pythons only) are needed
<vila> lifeless: they should not even be required, better to test with them though, but I think the patch handling their availability have been merge (or is it in 0.92 ?)
<vila> nope, bug #59150 not merged for 0.91, so paramiko is required to run the test suite
<ubotu> Launchpad bug 59150 in bzr "bzr selftest fails on a machine without paramiko" [Low,Fix released]  https://launchpad.net/bugs/59150
<lapthrick> bzr treats branch as equal when their history's the same and doesn't have a concept of any unique "branch ID", right?
<lapthrick> *branches
<matkor> lapthrick: to my tiny knowledge - right
<matkor> I think about branches as sequences of unique revisions
<lifeless> vila: well, not required, but strongly preferred
<lifeless> lapthrick: URL is branch id
<vila> lifeless: agreed
<siretart> oh, since we don't run the testsuite on the buildds, I'll remove paramiko for now
<lapthrick> lifeless: well, yeah, but it's not encoded anywhere inside the branch itself, no?
<lapthrick> so if I switched the parent branch of anything to an equivalent branch under another URL, it wouldn't change anything, right?
<pbor> bzr: ERROR: Repository KnitRepository('file:///home/paolo/dev/gedit/.bzr/') is not compatible with repository KnitRepository3('file:///home/paolo/bzr/gedit/.bzr/')
<pbor> what should I do?
<lapthrick> pbor: bzr upgrade --something
<pbor> (I did bzr init-repo in dev/gedit because I want to create a repo with multiple branches under it and then I tried to branch from bzr/gedit which is the branch I created with bzr-svn...)
<lapthrick> for appropriate value of something :)
<pbor> lapthrick: in the newly created repo or in the bzr-svn one?
<lapthrick> pbor: I think the newly created, as KnitRepository is the default (still) and older format unless you override it
<pbor> mmm the bzr-svn one is "dirstate-with-subtree" while the newly created is "dirstate or dirstate-tags or knit"
<lapthrick> pbor: you need dirstate-with-subtree for svn interop
<pbor> bzr  help formats doesnt mention dirstate-with-subtree
<lapthrick> it's in the FAQ now
<pbor> okay
<lapthrick> though usually it complains about not being able to interop with SvnRepository, not KnitRepository3
<pbor> work now, thanks lapthrick
<matkor> Hi ! I have problems:
<matkor> >>> import bzrlib.plugins
<matkor> >>> bzrlib.plugins.__file__        -> '/usr/lib/python2.4/site-packages/bzrlib/plugins/__init__.pyc'
<matkor> >>> import bzrlib.plugins.gtk       -> ImportError: No module named gtk
<Odd_Bloke> matkor: That presumably means that you don't have the bzr-gtk plugin installed.
<matkor> Odd_Bloke: I have but in /usr/share:
<matkor> [matkor@laptop-hp /usr/share/python2.4/site-packages/bzrlib/plugins] $ python
<matkor> >>> import gtk       ->  No handlers could be found for logger "bzr"
<matkor> but it imports
<Odd_Bloke> In that case I don't know.  Sorry. :(
<matkor> >>> "/usr/share/python2.4/site-packages" in sys.path         -> True
<dato> matkor: the gtk plugin *has* to be under the plugins path
<dato> so either /usr/lib/python2.4/site-packages/bzrlib/plugins/gtk or ~/.bazaar/plugins/gtk
<dato> (or other location if you play with BZR_PLUGIN_PATH)
<matkor> dato: But I have /usr/share/python2.4/site-packages in sys.path
<dato> yes, but plugins can't be there directly
<matkor> dato: so "plugins path" is sth different than sys.path ?
<dato> if I'm not mistaken, yes
<matkor> can I add another plugins path during configure install ?
<dato> I don't think so, but there is the runtime BZR_PLUGIN_PATH (or a similar name)
<matkor> dato: I am preparing bzr bzr-gtk bzrtools for distro release and we use both "/usr/lib/python2.4" and "/usr/share/python2.4" (FHS) so it would be much much better to do it during install
<dato> if it's for distro release, why dont you put them under /usr/lib/python2.4/site-packages/bzrlib/plugins/gtk ?
<dato> *or*
<dato> make /usr/lib/python2.4/site-packages/bzrlib/plugins/gtk a symlink to /usr/share/python2.4/...
<dato> *but*
<dato> I think it's a very very very bad idea to put the gtk plugin *directly* in /usr/share/python2.4/site-packages/gtk
<matkor> dato: Why is that ?
<matkor> dato default bzr-gtk install (setup.py install) puts plugins under /usr/share/ ...
<dato> because 'import gtk' should import the pygtk bindings, not the bzr plugin
<matkor> dato: That's true. But I understood that bzr plugin path contains only /usr/lib/python2.4/site-packages/bzrlib/plugins/gtk and ~/.bazaar/plugins/gtk so putting them under  /usr/lib/python2.4/site-packages will not help with import bzrlib.plugins.gtk
<dato> I said put them under /usr/lib/python2.4/site-packages/bzrlib/plugins/gtk, not /usr/lib/python2.4/site-packages/gtk
<matkor> Sensible fix would be to add new default /usr/share/python2.4/site-packages/bzrlib/plugins/ ...
<dato> that won't work
<dato> because when bzr imports plugins, it's not looking at sys.path
<dato> directly
<dato> but under `dirname bzrlib.__file__`/plugins
<matkor> Ah ... so symlinks are only way ...
<dato> mostly, if you insist on not shipping the plugin under /usr/lib
<matkor> but you said that it is not only looking in  `dirname bzrlib.__file__`/plugins but also in ~/.bazaar/plugins/gtk , correct ?
<dato> yes
<matkor> dato: You think that wishlist to add /usr/share... to bzr plugin paths during setup.py has a chance to be included in next bzr releases ? That would be step towards FHS ...
<dato> matkor: I personally don't know, because I'm not a bzr developer, but if it depended on me, I would not.
<matkor> dato: I will try anyway ...  , but what is yours rationale against ?
<lifeless> matkor: why do you want usr/share/something in the bzrlib plugins path?
<lifeless> matkor: (also, you can just set an environment variable to control that)
<matkor> lifeless: default setup puts plugins there (and it is correct according to FHS)
<lifeless> matkor: the default is in the plugins path
<matkor> lifeless: I would like to have install time and system-wide way of adding that path
<matkor> lifeless:  python  setup.py install --optimize=2 --root=$RPM_BUILD_ROOT  puts them uder /usr/share
<lifeless> matkor: our default path is [dirname(bzrlib.plugins.__file__), '~/.bazaar/plugins'] 
<lifeless> matkor: where under /usr/share ?
<matkor> lifeless: /usr/share/python2.4/site-packages/bzrlib/plugins
<matkor> default for pure-python packages
<lifeless> what does 'python -c import bzrlib.plugins; print bzrlib.plugins.__file__' report ?
<matkor> lifeless: /usr/lib/python2.4/site-packages/bzrlib/plugins/__init__.pyc
<lifeless> ok, there is the problem
<matkor> which also correct (but for binary modules)
<lifeless> what is
<lifeless> what does 'python -c import bzrlib.plugins; print bzrlib.plugins.__path__' report ?
<ubotu> New bug: #145612 in bzr "Unable to use pure-python plugins from /usr/share/ ... (FHS) location" [Undecided,New]  https://launchpad.net/bugs/145612
<matkor> lifeless: ['/home/users/matkor/.bazaar/plugins', '/usr/lib/python2.4/site-packages/bzrlib/plugins'] 
<lifeless> matkor: this is a bug in your python environment, not bzr
<schierbeck> jelmer: ping
<lifeless> matkor: I am pretty sure
<lifeless> $ python -c 'import bzrlib; print bzrlib.__path__'
<lifeless> ['/usr/lib/python2.5/site-packages/bzrlib'] 
<lifeless> if I put any additional package FOO in /usr/share/python2.5/site-packages/bzrlib/FOO
<lifeless> then it will not load into python
<matkor> lifeless: I think it should in default python setup
<lifeless> matkor: try it
<matkor> I mean package foo should be looked both in /usr/bin/.. and  /usr/share
<lifeless> matkor: importing bzrlib does not alter the module __path__
<lifeless> matkor: but they are not; its not how python works
<lifeless> it can be made to work that way, but its a problem in your environment not bzrlib, as long as bzrlib handles the __path__ that you assign to the bzrlib.plugins module correctly (and there looks to be a small bug there today, which I'll fix tomorrow)
<matkor> lifeless: I think import foo/bar should check module in both /usr/share and /usr/bin in FHS installed python
<lifeless> (we look at __file__, rather than __path__ to grab the default place to load plugins from)
<lifeless> matkor: I'm not arguing that you are wrong, I'm arguing that you should file a bug on python in redhat, because it *doesn't*, not for non-root modules.
<lifeless> and bzr inherits this behaviour
<lifeless> what you want is: $ python -c 'import bzrlib; print bzrlib.__path__'
<lifeless> to print out
<lifeless> ['/usr/lib/python2.5/site-packages/bzrlib', '/usr/share/python2.5/site-packages/bzrlib'] 
<lifeless> (for bzrlib, or any other module)
<lifeless> I don't know enough about the design implications of the module system in python to comment on whether this is a good idea or not.
<lifeless> I do know enough to say that bzrlib should not prevent that, and should, if that is being done, honour it for plugins.
<lifeless> I'm reasonably sure that doing it manually is a potentially bad idea
<lifeless> well, I hope this has helped clarify things; and I'll look at the bug, and also fix the bug I spotted during the discussion, tomorrow.
<lifeless> gnight
<matkor> gnight :)
<siretart> lifeless: dato: bzr_0.91-2 uploaded, without paramiko and celementree in build-depends
<siretart> hopefully it builds this time on all archs
<dato> siretart: I saw, thanks
<karmazilla> was there a way to use bzr for diffing two files without adding them or using some repo/branch ?
<karmazilla> patiencediff.py, it seems
<schierbeck> any bzr-gtk hackers here?
<matkor> schierbeck: one tiny ;) why ;) ?
<matkor> and olive-gtk only
<schierbeck> i've cleaned up the viz code quite a bit, removing some redundancy
<schierbeck> could i get you to check it out a bit?
<schierbeck> it's not really advanced at all, i just want to be sure you can run it
<matkor> schierbeck: I think you should talk with jelmer
<matkor> schierbeck: Have you published branch with those changes somwhere ?
<schierbeck> yup, at http://bazaar.launchpad.net/~dasch/bzr-gtk/viz-cleanup
<schierbeck> i don't think jelmer's online
<matkor> send him or Szilwester e-mail and be patient - I worked little bit only with olive-gtk
<schierbeck> ok
<Lllama> Afternoon all. Anyone using bzr-svn under Windows?
<Lllama> I'm having trouble pushing up to Google Code
<zyga> is there any description of API changes from around 0.16 to 0.91?
<zyga> I'm trying to use latest tailor to convert something but 0.91 has different API
<steko> hi
<steko> what is the current status of the webdav plugin ?
<mgedmin> to whoever implemented 'bzr ignore': thank you thank you thank you!
<LarstiQ> mgedmin: multiple people, what makes it so joyful for you? :)
<mgedmin> it's what I always wanted
<disorder> hi, can I use username containing @ somehow with bzr over FTP? Hosting uses user@domain.tld usernames
<disorder> tried to google something and set username inf config but no luck yet
<dato> disorder: try `bzr push ftp://user%40domain.tld@server.com`
<mwh> url-encode the @?
<disorder> thaks dato and mwh. haven't thought of it
<jelmer> re
<jelmer> hey schierbeck, matkor
<vila> steko: webadv plugin status is: requires bzr-0.92.0 (i.e. bzr.dev), pass the bzr test suite, awaiting testers :)
<jelmer> looks like Samba will end up using git :-(
<steko> vila: thanks. then I'll wait for 0.92 to enter lenny
<vila> steko: what is your use case ?
<steko> vila: I think nothing very interesting, I have a web space with webdav access and I'd like to keep also there some of the code I write. But I just write very small Python programs for myself
<vila> steko: there is no such thing as not interesting user needs :) I'd lie the webdav plugin to work on as many setups as possible, so feel free to ping me here when you're ready
<vila> s/lie/like/
<steko> vila: thanks. The server is running Apache 2.0 so there should be no problem
<schierbeck> jelmer: hi
<dato> jelmer: aw
<vila> steko: ok. That's my testing env so yes, that should work ok, do you administer the server yourself ?
<steko> vila: no, I don't. otherwise I would have used something like SFTP.. ;-)
<vila> :)
<schierbeck> jelmer: have you seen my merge request on the bzr-gtk list? i'm not sure it's getting through...
<pbor> jelmer: do you have a link on samba discussion/decision?
<zerok> hi :)
<schierbeck> zerok: hi!
<zerok> if you use a centralized approach with checkout and also have some local commits, can you somehow push them to the central branch without creating another changeset? (or is this done with push?)
<dato> zerok: yes, with push
<zerok> dato, thanks :) i was just not sure because the default push path wasn't automatically set when creating that branch :)
<jelmer> pbor: all happening in person
<fullermd> Heck, that should make it easy to sway toward bzr.  In person, it's SO much easier to apply blunt instruments...
<jelmer> schierbeck, will check in a moment
<jelmer> fullermd, :-)
<TeTeT> is there currently a problem with registering new branches on LP?
<TeTeT> e.g. failed to create path prefix?
<mwh> not that i know of
<schierbeck> jelmer: thanks
<LarstiQ> TeTeT: what are you trying to do? bzr push? Tried --create-prefix?
<schierbeck> phanatic: hi
<phanatic> hey schierbeck
<schierbeck> phanatic: i've tried posting a merge request to the list, but it doesn't seem to have gotten through
<TeTeT> LarstiQ: yes, found the prob: when not using a projects name as directory path, it won't work
<TeTeT> bzr+ssh does not tell you, but sftp does
<LarstiQ> TeTeT: oh?
<mwh> uh
<mwh> TeTeT: what does bzr+ssh say?
<phanatic> schierbeck: i didn't get any mails about moderation either (theoretically all the mails which don't make it to the list, should be in the moderation queue, and we should get notified about that)
<schierbeck> i'll try to re-send
<phanatic> okay
<dato> LarstiQ, mwt, TeTeT: there's a thread in the list by jam precisely on that.
<LarstiQ> dato: thanks
<schierbeck> phanatic: i've cleaned up the viz code a bit, removing some redundancy -- wanna have a peek?
<phanatic> schierbeck: first i'd say you should have a look at Gary's brokenlines branch, because that pretty much refactors some bits of viz, and probably we'll merge it into trunk (at least i'd like to)
<schierbeck> phanatic: okay, i'll have a look
<schierbeck> phanatic: it seems there's room for both
<schierbeck> should i try to merge it into trunk or brokenlines?
<phanatic> schierbeck: good question :) first i'd like someone with the sufficient knowledge to review the brokenlines branch (tbh, i don't know that part of the code well, since it was written way before olive existed), after that we can talk about any changes to viz. that's my opinion, but feel free to convince me :)
<schierbeck> sounds reasonable -- this was just a maintenance cleanup, removing code duplication and simplifying the construction of the widget
<TeTeT> mwh:failed to create path prefix
<schierbeck> but the brokenlines branch seems to be pretty sophisticated, i'm not sure it's that easy to review...
<mwh> sounds like a bug
<phanatic> schierbeck: sure, don't forget about it please :)
<phanatic> schierbeck: yeah, maybe i'll just go on and merge it, so we can find possible bugs
<schierbeck> sounds like a good idea
<schierbeck> i'd also like to see a major cleanup of some parts, including moving the scrollwin outside of brancwin.py
<phanatic> what's scrollwin?
<schierbeck> the part of the viz with the treeview and stuff
<schierbeck> i think it would be cool if we offered it as a widget of itself
<Peng> How does bzr do binary diffing and whatnot?
<Peng> Bah, I dunno what that question is supposed to mean.
<phanatic> schierbeck: yep, maybe you're right. logview was also moved to a separate module/widget by jelmer
<Peng> pmezard: You ask. I don't know what to ask. :P
* Peng goes to eat.
<schierbeck> phanatic: perhaps it could be generalized, and included in anjuta or something :)
<phanatic> probably other applications could make a use of it as well, that's true
<schierbeck> hmm, my mail still hasn't come true (that is, if it is resent to the author)
<schierbeck> *through
<phanatic> schierbeck: are you sending it from your gmail account?
<schierbeck> yup
<schierbeck> phanatic: is that causing problems?
<phanatic> no idea
<Peng> Um, is 'bzr commit' supposed to say 'Committing revision N to "<PATH>"'?
<jelmer> peng: yup
<Peng> Why?
<Peng> Is that new with 0.91?
<TeTeT> which bazaar GUI would you recommend for technical writers? I'm looking for something that provides ease of use for simple things, rather than completeness
<Odd_Bloke> Peng: Yeah, assuming '<PATH>' is replaced with an actual URL/path. :p
<Odd_Bloke> (Yeah to both questions)
<Peng> Odd_Bloke: Right.
<mw> when i do "bzr add *" in a large directory (a svn checkout of evolution-data-server, fwiw) it says "ignored 583 file(s)."  how can i see what those files are?
<mw> nothing about those files goes to stdout or stderr
<fullermd> 'bzr ignored'
<mw> aha, those were just object files anyway
<mw> --verbose lists them too.  duh.
<mw> passing --verbose to add, that is
<Peng> Really? I didn't know that. Cool.
<TeTeT> does bzr init-repo also work for already existing branches in a directory?
<TeTeT> or is it recommend to make a new directory, bzr init-repo there, and then bzr move the branches to the repo directory?
<Odd_Bloke> TeTeT: You would want to 'bzr branch' them to the repo directory.
<TeTeT> Odd_Bloke: thx
<lifeless> moin
<lifeless> abentley: morning; you identified a merge base problem a few weeks back; are you working on correcting that?
<jelmer> hey lifeless
<lifeless> hey jelmer
<lifeless> pqm will happen soonm I have your mail
<jelmer> lifeless: cool, thanks
<lifeless> jelmer: how long till you have rebase fixed do you think?
<lifeless> jelmer: is it worth shipping a bzrlib.plugins.svn.rebase in the interim ?
<ubotu> New bug: #145812 in bzr "Upgrade can leave a broken repository (with backup)" [Undecided,New]  https://launchpad.net/bugs/145812
<ubotu> New bug: #145813 in bzr "Can't upgrade RepositoryFormatKnit1 and no clue given as to what to do about it." [Undecided,New]  https://launchpad.net/bugs/145813
<jelmer> lifeless: Yeah, that may be a good idea. I'll do that if it's still broken when I do the next rleease
<lazy1> Can someone explain why even though I have '.subversion/auth/*' in my .bzrignore I still get .subversion/auth/svn.simple/0e79c1d269bc64edc62fd3ca3683a2cc as unknown?
<lifeless> jelmer: I'm seeing lots of people be unable to upgrade, its breaking users; so if your next release is more than a few days away; I'd encourage you to do this now :)
<lifeless> lazy1: if svn.simple was added, then that will override the ignore.
<lifeless> lazy1: for a full path match, use ./.subversion/auth/*
<lazy1> lifeless: Just .subversion as a whole
<ubotu> New bug: #145814 in bzr "Please provide a way to do 'missing' between a bound branch and it's master." [Wishlist,New]  https://launchpad.net/bugs/145814
<lazy1> lifeless: ./.subversion/auth/* does not work as well
<lifeless> lazy1: so is .subversion versioned ?
<lazy1> lifeless: yes
<lifeless> is auth ?
<lazy1> (as most of my home directory)
<lazy1> auth as well
<lifeless> oh, hmm
<lifeless> perhaps you need /**/*
<lazy1> ?
<lifeless> ./.subversion/auth/**/*
<lazy1> excellent, that works. Thanks!
<lifeless> bzr help ignore has the language
<lazy1> missed that, sorry
<lifeless> hey no problem
<lazy1> thougth it's just shell regexp
<mgedmin> well, in shell patterns * doesn't match subdirs
<mgedmin> so I'd expect .subversion/auth/*/* to work, but not .subversion/auth/*
<lazy1> you are right
<lazy1> however Python glob does show subdirectories with *
<lifeless> yes
<lifeless> glob is broken
<lifeless> it doesn't match shell
<lazy1> for f in `/bin/ls .subversion/*`; do echo $f; done shows subdirectories as well
<lazy1> (bash)
<mgedmin> that's ls
<lifeless> that shows the dir, not the contents
<lazy1> yup
<mgedmin> try echo rather than ls
<lifeless> 'ls dir' shows whats in dir
<lazy1> for f in .subversion/*; do echo $f; done shows sub directories as well
<lifeless> not for me
<lifeless> ~$ for f in .subversion/*; do echo $f; done
<lifeless> .subversion/auth
<lifeless> .subversion/config
<lifeless> .subversion/README.txt
<lifeless> .subversion/servers
<lazy1> But you see "auth" which is a directory
<lifeless> its not a sub directory of the point the * is at
<lazy1> ?
<mgedmin> when I said "in shell patterns * doesn't match subdirs" I meant that it doesn't match the / character
<lazy1> oh, now I get it
<mgedmin> not that it checks the types of the filenames
<lifeless> james_w: hi
<lifeless> james_w: there is another bug, about format ui - your bug is really a dup of that, because you need 'dirstate-with-subtree-tags'
<fullermd> Ooooh, do I get to renew my crusade against rollup format names?   ;>
<lifeless> fullermd: only if you write the patch for that bug :)
#bzr 2007-09-28
<james_w> lifeless: thanks.
<poolie> hello
<poolie> i love when people ping me on irc at 3am :)
<fullermd> Heck, I see you pinging on irc at 3am all the time   ;p
<poolie> at least they're not phoning i guess...
<poolie> spiv, ping?
<igc> morning
<poolie> hi igc
<lifeless> poolie: well, we can fix that
* igc food
<igc> I'll review the patch from lifeless after that
<bignose> "bzr: ERROR: No WorkingTree exists for file:///foo/bar/.bzr/checkout/."
<bignose> This branch was created by a remote 'bzr push --create'.
<bignose> How do I change it so it has a working tree?
<bignose> I see the 'bzr remove-tree' command; I awant the opposite, 'add-tree'.
<bignose> poolie__: I have a question you may have missed in this channel, may I ask it again?
<poolfool> Could someone please give tell me how to join (merge?) two different bzr repositories? I have one repo (~/public_html) and a second (~/development) that I would like to join (merge?) (~/repo)?
<poolie_> bignose: sure
<bignose> poolfool: what do you want the end result to be?
<bignose> poolie_: here it comes
<bignose> "bzr: ERROR: No WorkingTree exists for file:///foo/bar/.bzr/checkout/."
<bignose> This branch was created by a remote 'bzr push --create'.
<bignose> How do I change it so it has a working tree?
<bignose> I see the 'bzr remove-tree' command; I awant the opposite, 'add-tree'.
<poolfool> bignose: End result? I would like to merge both repositories (including history) into a single repo ... similar to 'svn-style' where I have 'repo/<project[a...b] /'. I really don't want to loose the history.
<bignose> Bazaar (bzr) 0.18.0
<bignose> poolfool: so, the two branches have similar files and similar structure; you want one of them to become "the" branch. yes?
<poolfool> bignose: No, the two repositories do /not/ have similar files ... I did find someone in the mailling list trying to do that.
<poolfool> bignose: No, I want to merge two different repo's that have individual projects into a single repo.
<bignose> poolfool: (note that "repo" is a different thing to "branch" in Bazaar.)
<bignose> poolfool: can you describe what the end result would be? what would happen to either or both of "~/public_html/" and "~/development/"?
<poolfool> bignose: Got that. Maybe some background, I wanted to try out bazaar so I choose to use 'public_html' #bzr init ... <do some revision and updates>
<poolfool> bignose: Bazaar is pretty good ...  I choose to put some small project in 'development' under revision control # cd ~/development; bzr init <do some revision and update>
<poolfool> bignose: Oops ... now I have .bzr <repo> in two different places (~/public_html and ~/development) each with working copies checked out too.
<bignose> poolfool: ah, there's the disconnect. the '~/public_html/.bzr/' directory is *not* a repo, it's a branch.
<bignose> or rather, it's not a "shared repository", which is what is often lazily called a "repo".
<poolfool> bignose: I guess I am trying to now move to a more CVS repo like I am used to.
<bignose> poolfool: you can set up a shared repository with 'bzr init-repository ~/Projects/'
<bignose> poolfool: and then 'bzr branch ~/public_html/ ~/Projects/public_html/'
<bignose> poolfool: you'll then have the shared repository '~/Projects/', and within it a branch '~/public_html/'
<bignose> poolfool: but remember that the shared repository is only useful once you start branching *within* that repository, e.g. 'bzr branch ~/Projects/public_html/ ~/Projects/public_html.coolnewfeature/'
<bignose> poolfool: i.e. shared repositories are only useful because they share revision data; identical revisions (i.e. ones common to two or more branches with common ancestry)
<poolfool> bignose: Ok, I am still digesting and reading more documentation at bazaar-vcs.org?
<bignose> poolfool: you can then 'bzr branch ~/development/ ~/Projects/development/', but of course that branch will have no common revisions with any of the 'public_html' branches that exist in the '~/Projects/' repository
<poolfool> bignose: So 1) Everything, including '#bzr init' are branches, 2) a repo is a shared /branch/, and 3) shared branches only include 'common ancestry'?
<bignose> poolfool: not quite. all branches have repositories; but 'bzr init-repository' sets up a *shared* repository that allows branches inside that directory to share revision data.
<poolfool> bignose: One more time for the cheap seats, '~/Projects/dev...' and '~/Projects/public...' will have no common revisions between them? Great ... just what I wanted.
<bignose> poolfool: your existing '~/development/' branch has a repository, that lives inside that branch alone and isn't shared, even if you branch from it
<bignose> poolfool: the only reason to set up a repository is to make it even cheaper and faster to branch, because the common revision data will stay in one place.
<bignose> (well, that's the only reason I use it. there may be others.)
<bignose> poolfool: any time you 'bzr branch' from a branch *inside* the shared repository to one *outside*, all the necessary revision history will be carried along. it's only branches within the shared repo that share their revision data.
<bignose> poolfool: so, the space and speed advantages of a centralised repository containing many possibly-unrelated branches; with all the benefits of being able to branch those elsewhere at will.
<poolie_> bignose: in older versions, use 'bzr checkout .' in that tree; in newer ones 'bzr reconfigure --tree'
<poolie_> hth
<poolfool> poolie_: 'reconfigure --tree' can you use that command to convert a dirstate tree to dirstate-tags tree?
<poolfool> bignose: Ok ... thank you I think I get it. I just started to try out Bazaar and well I am used to my CVS frame of mind where all projects are in the same repo. Not several different 'branches' left around the file system.
<bignose> poolfool: yes, you definitely want a shared repository.
<poolie> poolfool: no, that's 'upgrade'
<poolie> reconfigure switches between different kinds of bzrdir in the same format
<bignose> poolfool: you also want to read about the 'bzr checkout' command; it lets you treat a branch elsewhere as "the central branch", and commit changes simultaneously to both the central and local working tree.
<poolie> i guess maybe upgrade should be considered a subset of reconfigure
<poolie> but it is not at present
<poolfool> bignose: The only thing I do not get is, if I setup a 'shared repo' as you explained ... will I keep the existing history of the branch (public_html) when I branch to the 'shared repo'?
<bignose> poolfool: 'bzr branch foo/ bzr/' always preserves the complete history of the branch.
<bignose> erm, that should be 'bzr branch foo bzr/' for clarity :-)
<bignose> argh
<bignose> erm, that should be 'bzr branch foo bar/' for clarity :-)
<poolfool> bignose: no problem. Thanks again for the help.
<poolfool> bignose: are you a bazaar developer?
<bignose> poolfool: no, just a fan :-)
<bignose> I've been using Bazaar since it was the throwaway prototype for the new version of GNU Arch
<bignose> then it because the not-to-be-thrown-away much improved system that gets rid of all Arch's cruft :-)
<poolfool> bignose: well I am sold ... no more monster patch to and from work on thumb drives to commit after hours of work at home.
<bignose> s/because/became/
<poolfool> bignose: I could never wrap my head around the funny file names of Arch ... but I have thought the idea of distributed (cheap branch) rcs was a good idea.
<bignose> yep. GNU Arch paved the way for all this good stuff, and Tom Lord deserves more money than he ever got from it.
<poolfool> bignose: Name me two good people who ever get the money they deserve?
<bignose> well, if you insist on the "good" qualifier, I can't :-)
<poolfool> Next stupid question, I original ran '#bzr init' and now have a 'dirstate(?)' branch; can I convert(?) to 'dirstate-tags'? Or can you tag 'dirstate'?
<bignose> poolie: yes, 'bzr checkout .', while completely unintuitive, does seem to have done the trick.
<bignose> poolie: I'm glad it has become 'reconfigure --tree'.
<bignose> poolfool: one tip with 'bzr checkout'; get accustomed to doing 'bzr info' in a cranch to determine whether it's a checkout (bound to a remote branch) or not.
<bignose> s/cranch/branch/
<bignose> man, my typing is lousy today.
<poolfool> wow ... now I am scared because I read that right before the correction.
<poolie> lifeless: just a ping about debs
* #bzr  [freenode-info]  if you need to send private messages, please register: http://freenode.net/faq.shtml#privmsg
* spiv -> slug
<mrevell> igc: Hi
<igc> hi mrevell
<mrevell> hey igc - would now be a good time to have a quick chat?
<igc> yes
<igc> mrevell: how about I call you?
<igc> night all - have a good weekend
<steko> hi, I'm trying to convert a little darcs repo to bzr using tailor, but I have problems http://pastebin.com/m1ff6d86b
<steko> is there another way to to darcs > bzr ?
<fullermd> I don't know of one.
<fullermd> That actually looks like a problem on the darcs side of tailor.
<fullermd> I'm given to understand there are some current bumps on the bzr side of it too   :|
<steko> fullermd: I know. but it's not good to ask on ##darcs how to stop using darcs itself! :-)
<oly_mk2> hi could do with some help with bzr please,
<oly_mk2> i am trying to update a local branch but it wants me to first commit my changes is there anyway i can cancel my changes
<oly_mk2> and just do a merge ?
<GaryvdM> Are you sure that your changes are not important
<oly_mk2> yes they where changes to try and fix a problem as a test,
<GaryvdM> Check what has been changed with a bzr status and/or bzr diff
<oly_mk2> basically i am developing on one machine commiting then pulling on other machine
<GaryvdM> If you don't want the changes any more you can bzr revert
<oly_mk2> i think i am using bzr wrong on my test machine to be honest
<oly_mk2> i use bzr branch and bzr merge to update
<oly_mk2> on the test machine but i never want changes to go back from test machine
<oly_mk2> thanks bzr revert does exactly what i need
<GaryvdM> You should probaly use bzr pull on your test machine
<GaryvdM> insted of merge
<oly_mk2> okay, thxs i did get confused between checkout pull and branch at one point
<oly_mk2> i started of with pull i think, and changed
<oly_mk2> i will give that a try
<oly_mk2> thxs for the help though appreciated,
<GaryvdM> It's a pleasure
<spiv> lifeless: turns out stacking test adapters isn't *too* difficult.
<spiv> abentley: my reconcile work has been mailed to the list
<spiv> abentley: it turned out to be much bigger than I anticipated, but if you can forgive that I'd love to get your feedback on it.
* spiv -> bed
<adedov> hello
<adedov> It seems, I still cannot get principles of DRCS... Am I right that if I have, say, two branches than they will always have different revision history even being synchronized each to another?
<fullermd> Yes and No and Maybe and It Depends.
<radix> given he said "always", I would say the answer is "no" :)
<mw> Ask not fullermd for council, for he will say Yes and No and Maybe and It Depends.
<radix> heh
<adedov> :)
<fullermd> Well, it _can_ be always, if you work it that way.  And it can be never, if you work it that way, and anywhere in between.
<radix> adedov: no, two branches can have the same revision history. "bzr branch foo bar" makes a branch "bar" which has the same history as "foo".
<adedov> I have already told my history today on this chat. However... I have three branches: at launchpad, at home, and at office. And each time I commit to a local branch (either at home or at office) I push changes on launchpad. After that I need merge another one and commit merge results locally. And finally I must push commit results back to launchpad. It appears that launchpad's branch will be always contain merge results of it-self...
<radix> adedov: sure, and that's fine.
<radix> adedov: actually....
<radix> adedov: you don't need to merge if the two branches haven't diverged
<luks> adedov, if you are the only developer, you probably want pull instead of merge
<radix> adedov: you could just be pulling from launchpad instead of merging
<adedov> radix: right, but once they diverged, I merge, commit and push... and launchpad constantly hides its previous history with merged results.
<radix> adedov: "hides"?
<adedov> hmm... I look into branch log and I see records rearanged.
<adedov> please tell me common practice of commiting merge results? is it ok commit as 'Merge with xxx branch' or it is better to name all the changes in merge?
<radix> adedov: the former
<radix> adedov: all the changes in the merge are still there, so there's no need to name all of them in the merge commit message
<Solarion> http://ooextras.sourceforge.net/http://ooextras.sourceforge.net/aaaaaa
<Solarion> sorry, terminal seems to have gone haywire
<adedov> radix: in this case, after pushing merged revision to launchpad, the branch log on launchpad lists records like 'Merge with main' (which actually the launchpad's branch name)
<adedov> readability suffers
<radix> adedov: what's the problem?
<radix> maybe the problem is that launchpad doesn't make it easy to see the merged revisions?
<radix> (although maybe it does, I don't know)
<radix> but like I said, if you're not diverging the branches, you have no need to merge, and instead you can just pull.
<poolfool> adedov: Are you trying to use launchpad as a common central repo for your work at home and office?
<adedov> radix: OK. I think my head needs time to get it all :)
<adedov> poolfool: yes
<poolfool> adedov: Ok, then it makes a little more sense to me ... that and what bignose said last night. What is your past RCS?
<adedov> poolfool: CVS
<adedov> poolfool: I know it is awful :)
<poolfool> adedov: Me too .... totally different train of thought, but you can use bazaar kind of like CVS with a central (blessed) repo (launchpad).
<adedov> poolfool: I know that, but I also like to have an ability making local commits before getting new feature mature enough.
<adedov> poolfool: or I need have a branch per feature in this case?
<poolfool> adedov: Exactly, you are on the right track ... now come the details.
<poolfool> adedov: I work alone (or with few other people) in CVS and try to branch often ... bad idea I know. But bazaar works better that way. I branch for each new feature (within reason).
<poolfool> adedov: Ok, here is my conversation last night with bignose (nice guy) who helped to clear up some things. I am still learning ... but it sounds like you are trying to do what I want to do; remote distributed development checked into a common central repo.
<poolfool> adedov: http://pastebin.com/m32b3d220
<adedov> poolfool: aha. thank you!
<poolfool> adedov: Have you read the workflow section at bazaar? http://bazaar-vcs.org/Workflows
<adedov> poolfool: long time ago. before I started use bzr. I will re-read :)
<TeTeT> can some bzr expert take  a look at https://wiki.ubuntu.com/Training/KnowledgeBase please and see if I made any glaring errors on how to use bazaar for the desktop course?
<schierbeck> phanatic: hi
<phanatic> hey schierbeck
<mrevell> hey phanatic
<schierbeck> phanatic: have you decided on what to do with brokenlines?
<phanatic> hey mrevell :)
<phanatic> schierbeck: i was about to send a mail to the list
<schierbeck> phanatic: ooooh :D
<phanatic> mail sent :)
<phanatic> schierbeck: i got your test mail :P
<schierbeck> great!
<schierbeck> what about the merge requests?
<phanatic> these mails have made it to the list: https://lists.canonical.com/archives/bzr-gtk/2007-September/thread.html
<schierbeck> wow, they did come through
<schierbeck> it's weird -- it seems like they were responses to other messages...
<phanatic> yes
<schierbeck> doesn't show up that way in evolution, though...
<schierbeck> phanatic: have you had a look at the viz-change-title branch?
<schierbeck> *viz-window-title
<phanatic> not yet, but i'll do have a look at all merge requests during the weekend
<schierbeck> cool
<schierbeck> btw, it was a sound decision to merge brokenlines
<schierbeck> waiting longer would've put off other changes to the viz
<schierbeck> well, i'm gonna go make some dinner, see you later
<ubotu> New bug: #146379 in bzr "Wrong format suggested when subtrees are required." [Undecided,New]  https://launchpad.net/bugs/146379
<mtaylor> if I get this when trying to do a push:
<mtaylor> bzr: ERROR: Can't rename /srv/sm-ng/push-branches/00/00/0e/49/.bzr/repository/lock/5jz7rhqnlo.tmp to /srv/sm-ng/push-branches/00/00/0e/49/.bzr/repository/lock/held: /srv/sm-ng/push-branches/00/00/0e/49/.bzr/repository/lock/held already exist
<mtaylor> is that a lock held on the server repos?
<mtaylor> if so, how can I clear it?
<fullermd> I thought it gave you a 'lock already held' error when it noticed something.  Maybe that particular error means you lost a locking race?
<rele> Is there someone responsible for the Bazaar website?
<rele> The Windows downloads at http://bazaar-vcs.org/Download are still the old 0.90 versions, despite the link text mentions 0.91. (Last-Modified: Sun, 02 Sep 2007 14:31:44 GMT)
<rele> Still 0.90:
<rele> http://bazaar-vcs.org/releases/win32/bzr-setup-latest.exe
<rele> http://bazaar-vcs.org/releases/win32/bzr-latest.win32-py2.5.exe
<rele> http://bazaar-vcs.org/releases/win32/bzr-latest.win32-py2.4.exe
<fullermd> That's know.  Something on the list about it.  0.91 is there, the -latest links just don't point to it.
<rele> @fullermd: thx!
<TeTeT> is the channel logged somewhere?
<TeTeT> !ubuntulog log
<ubotu> Sorry, I don't know anything about ubuntulog log - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<james_w> TeTeT: yes. I just can't remember where.
<james_w> http://people.ubuntu.com/~fabbione/irclogs/ has some
#bzr 2007-09-29
<Rotund> Isn't the topic out of date?  Isn't 0.91 out now?
<Rotund> wait.  my Xchat was screwy
<Rotund> My real question is "is there a reason the apt repositories don't have 0.91 yet?"
<james_w> the bazaar-vcs.org repos?
<Rotund> yup
<james_w> lifeless hasn't got to it yes.
<james_w> yet
<Rotund> they are still 0.90.  I'm just wondering if there was a known problem or something
<james_w> Debian has 0.91.
<Rotund> Kinda funny that Ubuntu doesn't
<james_w> they are busy with Gutsy.
<Rotund> =)
<james_w> Rotund: if you are desperate you can run from source easily.
<Rotund> yeah.  mostly lazy =)
<james_w> ah, me too.
<Rotund> I don't think 0.91 will be THAT much better that I can't wait
<GaryvdM> Where can one view the log for the channel?
<phanatic> GaryvdM: http://people.ubuntu.com/~fabbione/irclogs/
<GaryvdM> Thanks
<ubotu> New bug: #146705 in bzr "wishlist: Add Generated-By header to bzr diff " [Undecided,New]  https://launchpad.net/bugs/146705
<ubotu> New bug: #146715 in bzr "bzr+ssh broken for non standard ports." [Undecided,New]  https://launchpad.net/bugs/146715
<ubotu> New bug: #146780 in bzr "unix tar install should go to /usr/local/" [Undecided,New]  https://launchpad.net/bugs/146780
<elijah> Is it possible to get bzr-svn working with svn-1.4, or do I have to install an unstable development version of svn?
<elijah> The README file seems to suggest the latter, but I'm not willing to go that route...
<jelmer> elijah: Either patch svn-1.4 or install a development version of svn
<elijah> Where's the patch for svn-1.4?
* elijah must have missed it
<jelmer> it's linked from the wiki page
<jelmer> Ubuntu and Debian's packages contain it by default
<jelmer> http://samba.org/~metze/subversion-1.4.0-metze-python-bindings.patch
<elijah> ah, I see it now
<elijah> I must be blind
<elijah> Thanks, jelmer
<schierbeck> hello y'all
<jelmer> hey schierbeck
<luisbg> what's the command to know what revision is my local repo of a bzr branch?
<james_w> luisbg: is 'bzr revno' what you are looking for?
<james_w> or bzr revision-info
<luisbg> james_w, revno did the trick ;)
<mtaylor> when I use bzr+ssh to push to a launchpad repos, I get this:
<mtaylor> No handlers could be found for logger "bzr"
<mtaylor> that, and any idea when 0.91 is going to hit the deb http://bazaar-vcs.org/releases/debs/gutsy ?
<mtaylor> and...
<mtaylor> bzr: ERROR: Can't rename /srv/sm-ng/push-branches/00/00/0e/49/.bzr/repository/lock/vq3i0r99qa.tmp to /srv/sm-ng/push-branches/00/00/0e/49/.bzr/repository/lock/held: /srv/sm-ng/push-branches/00/00/0e/49/.bzr/repository/lock/held already exists
<james_w> mtaylor: first one is a launchpad configuration problem I believe.
<james_w> the second I can't say for sure, probably next week sometime
<mtaylor> james_w: oh good. that's always nice. :)
<james_w> and the third has a bug report in launchpad if you want to look.
<mtaylor> james_w: I'd love to. you don't know the number, do you (I can look if you don't)
<james_w> I don't I'm afraid, a search for "can't rename already exists" in the bzr bugs should get you it.
<mtaylor> james_w: thanks!
<james_w> not the most helpful bug log to read, but at least it is reported.
<mtaylor> james_w: indeed. at least I'm not the only one with it. :)
<james_w> do you see it when pushing to launchpad?
<james_w> do you see it every time?
<james_w> and is there a chance that someone else is pushing at the same time?
<james_w> ah, mtaylor did you look at Bug #137668?
<ubotu> Launchpad bug 137668 in bzr "bzr doesn't understand new 'directory already exists' message from codehosting sftp server" [High,Triaged]  https://launchpad.net/bugs/137668
<mtaylor> james_w: yup. that's the one I looked at
<mtaylor> james_w: it happens every time. I aborted a push a day or two ago
<james_w> ah, I was thinking of another, that one is better.
<mtaylor> james_w: and since then, I can't push to that branch anymore
<james_w> I'll find the other and merge as appropriate.
<james_w> mtaylor: ok, you could try break-lock.
<james_w> and I don't know if delete by hand somehow.
<james_w> otherwise request that the launchpad admins fix it up for you.
<mtaylor> james_w:  just tried break-lock - didn't work.
<mtaylor> james_w: is there a better way to request than just bug someone on #launchpad?
<james_w> I don't know if filing a support request in lp is preferred. Ask in #launchpad and they will tell you.
<mtaylor> thanks for the help1
<james_w> no problem.
<james_w> I found the other bug, it has nothing to do with this at all :)
<Odd_Bloke> mtaylor: Try break-locking using sftp rather than bzr+ssh (if you haven't already).
<mtaylor> Odd_Bloke: I did. I stopped using bzr+ssh when I got that logging error
<james_w> good job there was another filed, otherwise you could have been looking for a while.
<mtaylor> Odd_Bloke: well I'll be - I tried break lock with bzr+ssh instead of sftp and it worked
<Odd_Bloke> mtaylor: Heh.
<Odd_Bloke> There are some oddities with LP's bzr+ssh stuff, I find switch protocols seems to fix it.
<mtaylor> Odd_Bloke: that makes me all warm and fuzzy
#bzr 2007-09-30
<schierbeck> GaryvdM: hi
<GaryvdM> hello
<schierbeck> i just wanted to ask; do you accept somewhat unrelated patches to brokenlines?
<schierbeck> it seems that it'll be merged soon, so i might as well place them there, to avoid any conflicts later on
<schierbeck> (given that phanatic is in on it, of course)
<GaryvdM> Yhea - I think you can make patches against vizchanges, and then send them to the list
<GaryvdM> With a note that it is of vizchanges.
<schierbeck> ok
<GaryvdM> I think that is the best way to go.
<GaryvdM> If you send them to the mailing list - I'll test them.
<schierbeck> ok, thanks
<schierbeck> GaryvdM: have i asked you about the title of the viz window?
<GaryvdM> Like https://code.launchpad.net/~dasch/bzr-gtk/viz-cleanup ?
<schierbeck> i'd like to rename it "Revision history"
<GaryvdM> No
<GaryvdM> Am\
<GaryvdM> I agree that it needs to be changed
<schierbeck> yup
<schierbeck> okay, i'll make a quick patch and send it to the list
<phanatic> if noone raises any objections on the list until tomorrow, i'll merge vizchanges/brokenlines
<schierbeck> sweet
<GaryvdM> Cool!
<GaryvdM> I do like Revision History because it is consistent with previous vcs I have used.
<GaryvdM> But in bzr it is Log
<schierbeck> i know, but i just think that's unintuitive
<GaryvdM> And I feel we should use that to be consistent.
<schierbeck> hmm
<schierbeck> i agree that it would be best
<schierbeck> and using 'revision history' consistently would mean convincing the bzr guys it's for the better...
<schierbeck> screw it, i'll use 'log'
<GaryvdM> Else try get log changed to history in bzr ;-)
<schierbeck> exactly :(
<schierbeck> i don't know why they picked 'log' -- it really makes no sense
<schierbeck> well, some
<GaryvdM> And I think we need to add glog as a alias for viz
<Odd_Bloke> Historical reasons and it is a log of revisions.
<Odd_Bloke> Adding history as an alias for log would work...
<schierbeck> Odd_Bloke: but you're not really reading a log, which in my mind is a secondary piece of information about events
<schierbeck> you're seeing the *history*, the main purpose of the rcs
<schierbeck> okay, i'm going with "revision log"
<Odd_Bloke> schierbeck: Sure, I was just filling in the 'well, some'. :p
<schierbeck> :)
<schierbeck> sorry, i easily get very involved in silly matters
<GaryvdM> schierbeck: are these the changes that you wanted to make against vizchanges: https://code.launchpad.net/~dasch/bzr-gtk/viz-cleanup
<GaryvdM> ?
<Odd_Bloke> I suppose 'log' is also a more obvious/convenient shorthand than 'his' or 'hist'...
<schierbeck> GaryvdM: that's another branch
<schierbeck> i was working on a general cleanup of viz, but then i heard of your branch
<schierbeck> that made some of my changes redundant
<phanatic> that's the reason why we set up that mailing list: to avoid redundancy :)
<schierbeck> i really feel there's a lot of code duplication in there; i'd like to have a reference to the currently selected revision stored in the tree model
<schierbeck> phanatic: yeah, but i've been having some trouble with it; didn't receive your mail, either :(
<schierbeck> the branch's pushed to http://bazaar.launchpad.net/~dasch/bzr-gtk/viz-change-window-title
<phanatic> schierbeck: that sucks :(
<schierbeck> i of course made a typo in the commit msg
<schierbeck> i'll try to send a mail to the list
<phanatic> schierbeck: not even in your spam folder?
<schierbeck> nope
<schierbeck> it freaks me out
<phanatic> weird
<schierbeck> wow, that's like the third "change title" mail i've sent to the list
<schierbeck> first two were dupes
<schierbeck> okay, it's off
<schierbeck> i hate the list archive
<schierbeck> it displays my message as a reply to another mail
<GaryvdM> phanatic: Do you have access to modify this page: https://launchpad.net/bzr-gtk/ ?
<GaryvdM> If you do, may I suggest adding a link to the mailing list.
<GaryvdM> Hmm - never mind -  it seems I have access :-)
<GaryvdM> schierbeck: I received you list mail.
<schierbeck> great :)
<schierbeck> please do tell here if you reply; i'm not sure i'll receive it
<phanatic> GaryvdM: thanks for updating the page (i've been away from my computer for a bit)
<GaryvdM> NP
<schierbeck> i've played around with vizchanges -- isn't the window getting *very* wide?
<schierbeck> it's caused primarily by the new "Children" label
<Vantage13> Does bazaar have a way of pulling multiple patches or merging multiple branches at once?
<GaryvdM> Vantage13 - Yes - you can merge multiple branches/patches in one commit
<Vantage13> for example, if I have multiple features for one release.  I'd like to just pull a release rather than have to pull each feature in individually
<Vantage13> GaryvdM: how would you go about doing that?
<GaryvdM> bzr merge branch1
<GaryvdM> bzr merge branch2
<GaryvdM> bzr merge patch
<GaryvdM> bzr commit
<schierbeck> GaryvdM: i'm not sure you can merge if you have uncommitted changes...
<Vantage13> GaryvdM: is patch a command or just the name of the combination of the two?
<schierbeck> test> bzr merge ../viz-status-message/
<schierbeck> bzr: ERROR: Working tree "/home/daniel/Projects/bzr-gtk/test/" has uncommitted changes
<GaryvdM> No - you can specify a patch to the merge command
<luks> --force
<schierbeck> luks: does --force have any destructive side effects?
<luks> in case of conflicts, you will probably end up in a confusing situation
<luks> but otherwise no, as far as I know
<egx0r> Having trouble with the initial orginazation. If I have 5 sub-projects working seperately but under one major project, should I then make 1 project and 5 branches or 5 seperate projects, any hints?
<james_w> egx0r: I would personally go for 5 separate projects.
<james_w> (a branch and a project would be the same thing here I think).
<james_w> unless you always need all of the sub-projects, and it is inconceivable that anyone would ever work on just one.
<egx0r> james_w: Good point. You can see my sub-projects as tasks in a project. Every task should work independently of each other, but they should all be under the same project. I hope this makes sense..
<schierbeck> phanatic: do you have any remarks on the viz-change-title patch?
<GaryvdM> schierbeck: are you sure that children are making the viz window wider?
<GaryvdM> It seems like it's the tree to me
<schierbeck> GaryvdM: it's both, i guess
<phanatic> schierbeck: i like history better i think
<schierbeck> phanatic: me too :D
<schierbeck> GaryvdM: i'd like some of the columns to disappear, too
<schierbeck> like the revno -- it should be in the logview
<phanatic> schierbeck, GaryvdM: as we've discussed before, i'd prefer to allow the user to set which columns s/he wants to see
<GaryvdM> logview?
<phanatic> logview is the bottom part, the details :)
<schierbeck> phanatic: but that'll take some time to implement -- i'd really like to keep the viz simple until we can offer such an option to the user
<schierbeck> GaryvdM: oh, yeah, the bottom :)
<schierbeck> GaryvdM: also, we really should simplify the date format
<schierbeck> displaying both weekday and timezone seems to be overkill...
<GaryvdM> Weekday - Yes, Timezone - maybe
<schierbeck> GaryvdM: if we can, why not convert to local time format?
<GaryvdM> Yhea
<schierbeck> i think i better file a bug report, otherwise i'll just forget all this...
<GaryvdM> I think stuff that is in the tree must be helpfull to locate a revision.
<schierbeck> exactly
<schierbeck> there should be nothing more
<GaryvdM> Yhea - Timezone does not help
<GaryvdM> Revision number would be usefull
<GaryvdM> I remember revision numbers
<schierbeck> GaryvdM: i'd rather have a search box, then
<schierbeck> type the revno, and be taken to the right revision immediately
<GaryvdM> That is all ready the case :-)
<GaryvdM> Click on the tree and type a number.
<schierbeck> GaryvdM: cool! but not very intuitive for a new user...
<schierbeck> i'd rather hide the column and have a search box instead
<GaryvdM> Cool
<GaryvdM> There must allready be some gtk applications that have a column selector.
<GaryvdM> There is on built into the mozilla xul tree.
<GaryvdM> But there does not seem to be one for gtk.
<schierbeck> hmm
<schierbeck> i'm not sure how to do it
<luks> GaryvdM, evolution, but it uses an ugly custom widget
<schierbeck> GaryvdM: i've fixed the time stamp format: http://bazaar.launchpad.net/~dasch/bzr-gtk/viz-date-format
<GaryvdM> schierbeck: cool
<Verterok> moin
<schierbeck> phanatic: merge material?
<phanatic> schierbeck: looks okay
<GaryvdM> schierbeck>
<schierbeck> i left the format as it was in the bottom; should i change it there, too?
<GaryvdM> schierbeck: that code is now in a different file in vizchanges (treemodel.py)
<schierbeck> hmm
<schierbeck> should i make a patch for vizchanges?
<schierbeck> GaryvdM: i'll mail you the patch
<GaryvdM> cool
<GaryvdM> Thanks
<schierbeck> sent :)
<phanatic> it's a bit late over here, so good night guys :)
<GaryvdM> The formated date will allways be 16 chars - so we can set the width-chars to 16
<GaryvdM> Night phanatic
<GaryvdM> Night
<elijah> Is there a howto on bzr-svn anywhere?  The website seems to list features, downloads, caveats, etc., but no instructions on use.
* elijah tries a bunch of 'bzr svn <some> <random> <stuff>' commands, without much luck
<radix> elijah: The idea is that you use bzr normally but with svn URLs instead of bzr URLs
<elijah> oh
<radix> elijah: so e.g. "bzr branch svn://..." should work
<radix> For http you might have to prefix with "svn+http://", but that may not be necessary any more, I don't remember.
<elijah> ah, and the works-in-an-svn checkout means I just do 'bzr status' and it'll work the same as 'svn status'...yes?
<radix> well, no :)
* elijah tries
<radix> it'll be a bzr status
<elijah> well, yes
<elijah> but very similar commands with similar status
<elijah> yeah, only slightly different output
<sm> good evening all
<harrisony> afternoon
<sm> could someone straighten me out on the current naming of bazaar|bzr[-ng]  ? I am dreadfully confused
<sm> are there still two projects ?
<sm> next question: I just committed and see my email address in the log in bad.. can I uncommit and do it again ?
<sm> and how do I influence the email address bazaar picks ?
<sm> fourthly, if we get that far, how would I typically push what I've committed to the upstream developer ?
<sm> (or have I done that already ? not sure)
<sm> I see the answer to configuring email address, in the (excellent) man page
<sm> excellent.. uncommit, just like darcs unrecord
<Peng> sm: The old, abandoned project (baz) is just called "baz" now. The new project is called Bazaar (bzr).
<Peng> sm: The old project used to be called "Bazaar" and the new project used to be called "Bazaar-NG".
<Peng> Hmm, "baz" is easier to type than "bzr".
<Peng> Of course, "hg" beats them both at that. :P
* fullermd makes a note to name his VCS 'asdf'.
<Peng> What about Dvorak?
<fullermd> Their problem, not mine   :p
<Peng> aoeu, I guess.
<sm> thanks
<Peng> You could make a symlink.
<james_w> sm: yes you can uncommit
<fullermd> Except that if you're thinking darcs-ish, uncommitting something other than the latest rev is probably not going to do what you expect.
<james_w> sm: you can either push if you have write access to their public branch.
<james_w> otherwise use 'bzr send --mail-to their@address'
<james_w> (assuming you have a fairly recent bzr'
<sm> excellent.. I'll try
<sm> not new enough I think.. bzr 0.15 in ubuntu feisty
<fullermd> Well, that should have the old 'bundle' at least.  You can attach that to an email manually (me, I do it manual all around anyway)
<sm> fullermd: thanks, that worked
<sm> changes made, committed and sent.. mission accomplished
<fullermd> Now, on to world domination.
<sm> muhahaHAHA
<sm> the world should switch to darcs/bazaar/mercurial methinks
<fullermd> Well, when I'm elected Emperor...
<schierbeck> hi y'all
<pbor> does bzr have an online interface?
<Peng> pbor: A web interface? There's Loggerhead (which is pretty heavy-weight, based on TurboGears) and there's also bzr-webserve (dunno how maintained it is).
<Peng> pbor: Loggerhead powers http://codebrowse.launchpad.net/~bzr/bzr/trunk/files .
<ubotu> New bug: #147266 in bzr "Crash when getting log of remote branch using bzr+ssh" [Undecided,New]  https://launchpad.net/bugs/147266
<schierbeck> hi guys
<matkor> hi !
<thumper> morning
<schierbeck> phanatic: ping
<phanatic> schierbeck: pong
<schierbeck> :)
<schierbeck> phanatic: any updates on the state of vizchanges?
<phanatic> schierbeck: i'll merge it tonight into trunk, so it gives green light to further changes :)
<schierbeck> great!
<schierbeck> it'll be much easier to make changes once it's merged
<phanatic> yep, i hope so :)
#bzr 2008-09-22
<poolie> good morning
<pygi> poolie, hey :)
<pygi> poolie, right, morning at 1:25AM :)
<poolie> hello pygi
<pygi> poolie, any idea when we'll have the next sprint? :)
<poolie> pygi, are you keen?
<pygi> poolie, yesh, I wanna work on this cheezburger stuff
<poolie> we'd talked about doing something again in early 2009, roughly a year from the last one
<pygi> a lot of people poked me about it ...
<pygi> poolie, as long as it's not during exams/papers season, I'm good =)
<jml> bzr just gave me a MemoryError: https://pastebin.canonical.com/9365/
<poolie> pygi: cheezburger?
<pygi> poolie, bzr repositories hosting thingy
<Peng_> Oooh?
<pygi> roughly, bzr equivalent to gitorious
<mwhudson> jml: public channel private pastebin?
<mwhudson> jml: but that looks like that "occasionally the sftp server sends random junk" message
<mwhudson> bug
<poolie> pygi, i've not heard of this before but it sounds cool
<poolie> pygi, maybe you should come to UDS?
<jml> mwhudson: ungh
<pygi> poolie, I'm trying, I applied for sponsorship ...
<pygi> poolie, you think me will get accepted?
<lifeless> jml: unless its actually confidential, a public pastebin works better for this channel
<pygi> (I didn't really mention cheezburger cause it's Bzr related, and not ubuntu, but I did mention I mentored for bzr two years ago)
<lifeless> anyhow, return os.read(self.proc.stdout.fileno(), count)
<lifeless> thats a strange line to memory error on
<lifeless> I wonder what count is
<lifeless> jml: is it repeatable?
 * jml tries
<mwhudson> jml: https://bugs.edge.launchpad.net/bzr/+bug/255292
<mwhudson> hmm
<jml> lifeless: yes it is. would you like to know the value of count?
 * mwhudson things he would like to use bzrlib.graph._BreadthFirstSearcher
<pygi> poolie, lets hope we do meet there
<lifeless> jml: not particularly, but I should I guess
<poolie> pygi, i hadn't decided to go but i'm thinking about it
<poolie> lifeless and abentley will
<poolie> be there
<pygi> poolie, decide then :)
<pygi> so we can talk and then later on hack!
<jml> last two numbers are 1714499681
<jml> 1714466917
<jml> large numbers the twain of them.
<pygi> poolie, I really hope I get sponsored :)
<pygi> I did two years ago, same location, but had to decline it :-/
<mwhudson> jml: quite close large numbers
<mwhudson> (they only differ in three bits)
<lifeless> jml: a 1.7GB index would be quite a sight
<jml> lifeless: indeed.
 * jml updates the bug report
<lifeless> jml: do you have a 1.7GB index?
<jml> lifeless: no.
<jml> lifeless: unless bazaar multiplies the size when you push the branch up
<mwhudson> lifeless: does branch.repository.get_parent_map take stacking into account?
<jml> lifeless: locally the repo is ~600mb and the branch is ~2mb.
<mwhudson> (as in, will it return the same thing when branch is stacked on some other branch as when branch is not stacked?)
<lifeless> mwhudson: yes
<mwhudson> cool
<lifeless> mwhudson: all public apis take stacking into account, or are buggy
<mwhudson> lifeless: good to hear :)
<mwhudson> oh hm, i was misreading things
<poolie> hee hee
<mwhudson> (good)
<lifeless> mwhudson: also any chain of public attributes/methods will be safe, except the obvious ones where you folllow a stacked relationship or some such
<BasicOSX> I'm working on bzr repo B, a larger bzr repo (called it A) wants to absorb my bzr repo B, how do I get my files into repo A and maintain the history/changelogs?
<mwhudson> lifeless: i think i was scared unnecessarily by the way repository.get_graph mentions "stackedparentsprovider"
<mwhudson> (although i think stackedparentsprovider is mostly something else?)
<lifeless> BasicOSX: bzr join
<BasicOSX> oh, ty, let me research it
<pygi> poolie, correction: cheezburger is roughly bzr's equivalent to gitosis, not gitorious (just noticed the "bug")
<poolie> hm, what's the difference?
<pygi> gitorious is with web UI and all that, something like Launchpad for git
<pygi> gitosis is server-side stuff for creating/managing repos and access to them, and can manage things like gitweb to show repositories on web
<abentley> mwhudson: StackedParentsProvider predates branch stacking.  Not really related.
<mwhudson> abentley: right
<poolie> lifeless: daniel has heaps of patches up for review for pqm
<poolie> http://blog.daniel-watkins.co.uk/updated_state_of_pqm.html
<poolie> can we get them unblocked somehow?
<abentley> It's stacking on a much more temporary basis, so that you can find the LCA when neither repository has all the relevant revisions.
<abentley> spiv: ping
<poolie> hello abentley
<spiv> abentley: pong
<abentley> poolie: hi.
<abentley> spiv: How do I use RemoteRepository.leave_lock
<abentley> _in_place?
<spiv> The same way as for other repos, hopefully :)
<abentley> spiv: I am doing a branch_implementations test, and it fails with RemoteRepository only, because RemoteRepository raises NotImplemented.
<spiv> Oh, hmm.
<spiv> I bet it's because it's because remote pack repos don't return lock tokens.
<abentley> spiv: The lock token is '', and this evaluates to boolean false.
<spiv> Right.
<spiv> The test there probably should be for "if self._lock_token is not None"
<spiv> Hmm.
<spiv> Or you could just notice that repo.lock_write() doesn't return a token; and thus indicates that the repo doesn't support this interface.
<abentley> support which interface?
<spiv> lock_write(lock_token=foo) / leave_lock_in_place / dont_leave_lock_in_place
<abentley> Or maybe I should ask, are we saying the RemoteRepository doesn't support the interface, or that the actual repository doesn't?
<spiv> The latter.
<spiv> (RemoteRepository is the only repository class that varies this by instance, unsurprisingly)
<abentley> Pack repositories don't raise NotImplementedError for this, AFAIK.
<spiv> Yeah, there does seem to be an unfortunate behaviour difference there, but IIRC they are both providing reasonable behaviours.
<spiv> There's a lot of per_branch/test_locking.py tests that already inspect the return value of branch.lock_write().
<abentley> I tell a lie.  It does raise.
<spiv> Ah, even better :)
<nandersson> I'm about to file a job description for BzrEclipse regarding "bzr tag support". Where do you guys think would be the best place to put it? Together with "commit" or as a separate option under "project -> team -> Tag"?
<spiv> FWIW, the docstring for leave_lock_in_place says "If lock_write doesn't return a token, then this method is not supported
<spiv> "
<abentley> spiv: I'm trying to fix a test that breaks a lock.
<nandersson> Together with commit would make more sense I think
<abentley> That test does not release the original lock.
<abentley> I want to use leave_lock_in_place, then release the lock.
<abentley> So should I actually be saying the test is NotApplicable for repos whose write_lock returns None?
<spiv> Which test?
<abentley> branch_implementations.TestBreakLock.test_unlocked_repo_locked
<spiv> If the test needs to use leave_lock_in_place to create a lock that needs breaking, then it definitely should skip with something like NotApplicable if lock_write returns None.
<abentley> spiv: Great, thanks.
<spiv> (or find another way to make a broken lock)
<abentley> spiv: But the *reason* is that the repository cannot create physical locks, right?
<abentley> And therefore, there's nothing to leave behind or break.
<lifeless> poolie: the next major one was merge-directives, which I reviewed but hasn't been updated AFAIK
<spiv> abentley: I think so, yes.
<abentley> Although, that's not entirely true for packs.  There is that names list lock.
<spiv> abentley: the shame here is that RemoteRepository does support this interface, it's just that the pack repo behind it doesn't.
<abentley> I see.  I just found it very confusing trying to understand why it was doing what it was doing.
<spiv> So ideally we'd run this test against with a slightly different RemoteBranch scenario: RemoteBranch + dirstate-tags format, say.  I'm not sure it's worth the effort to arrange that.
<abentley> spiv: I hear you.
<lifeless> abentley: the names list lock is rather more transparently managed though, because there is atomic-insert of a bunch of data, though you probably know this :)
<abentley> lifeless: Don't bet on it :-)
<spiv> Also, hmm...
<spiv> I would have expected that a RemoteBranch would still return a lock token, even if the RemoteRepo' underlying repo doesn't.
<lifeless> spiv: the branch should yes
<spiv> Oh, but this test is doing branch.repository.lock_write() etc, not branch.lock_write().
<spiv> So that makes sense.
<BasicOSX> Tried to bzr join, error about KnitPackRepository, so I  ' bzr upgrade --rich-root-pack' then tried to join, 'bzr: ERROR: Cannot join debian/.  Trees have the same root'
<abentley> BasicOSX: There's a reason join is a hidden command.
<BasicOSX> understood, I'll research more, sorry to bother
<abentley> BasicOSX: Also, you should understand that --rich-root-pack is a one-way conversion.
<abentley> For your needs, the merge-into plugin sounds more appropriate.
<BasicOSX> researching that ... ty
<BasicOSX> thank you abentley  that did exactly what I wanted
<abentley> BasicOSX: great
<poolie> abentley: hi
<poolie> i'd like to get the lca shape merge thing unblocked
<poolie> this seems like a case where our reviews are kind of slowing us down
<poolie> i do really appreciate you reading it, in your own time i know
<fullermd> Wow, PQM scares me even more now...
<abentley> poolie: jam said he'd call me about that.
<toytoy> hi guys, after I issued 'bzr update', I encountered this bug -> http://pastebin.ca/1207947
<toytoy> any idea, what causes and why does that error resumes?
<abentley> poolie: my problem with the patch is that I feel it degrades design design clarity by changing the model without changing the class to match.
<poolie> toytoy: so it's running out of memory trying to update the dirstate
<poolie> toytoy, i'd start by trying to upgrade to 1.6.1 or 1.7rc2
<poolie> abentley: so i can see how it would be cleaner with those changes
<poolie> i'm just wondering if it would be better to merge it as is first basically
<toytoy> poolie: you mean the memory is full or sorry I am not sure why would my memory would be full
<poolie> toytoy: is it a very large tree, or something with a large file in it?
<lifeless> the C extensions sometimes raise MemoryError on corrupt dirstate
<toytoy> poolie: oh i see, yeah i think so, so what is your best advise? lessen the files inside the trees?
<poolie> toytoy: yeah it's too large?
<AfC> toytoy: you are running a very old version of Bazaar. Really, you should upgrade to the current release and try again.
<toytoy> poolie: btw, what do you mean by too large? i mean how many size do you expect a 'too large' to you?
<lifeless> 500000 paths would be pushing it
<abentley> poolie: I'm ambivalent.  On the one hand, we can always fix it later.  On the other, we could have fixed it by now.
<poolie> abentley: i think what may be happening here is that we feel like if we don't catch things in review we won't fix them
<poolie> however,
<toytoy> lifeless: that's really too big, but mine is not so. let me check the trunk
<toytoy> trunk's size
<poolie> it's making the cycle time for reviews longer, and i think it can be discouraging for the submitter (and might be in this case)
<toytoy> it's just 163MB so that might not too big right?
<abentley> I think you're right about what's happening here.
<toytoy> but yeah, my bazaar version at server is 1.3.1
<poolie> it may also make things linger in the queue because they don't get a crisp decision
<poolie> i think, all other things being equal, if it takes X additional work to clean it up
<poolie> it would be preferable to land the patch and then do X,
<abentley> The attempt to review thoroughly is part of them problem?
<poolie> than otherwise
<poolie> i'm assuming these are cleanups not outright bugs
<poolie> hm
<poolie> do you think so?
<poolie> i wouldn't say so
<abentley> Well, it does make the cycle time for reviews longer.  What did you mean, then?
<poolie> ah, what i meant by "it" is asking for things to be resubmitted to be cleaner or tested in a different way
<abentley> Ah, increasing the number of cycles, then.
<abentley> poolie: If we change this from requiring resubmissions to asking for followup patches, should we try to ensure that the followups happen?
<abentley> And if we did, how?
<poolie> (back, with coffee)
<poolie> yes, this would be trying to have more but smaller cycles
<poolie> so one proposed idea is to get people to file bugs for the followon work
<poolie> if people want to do it good luck to them but i don't think it's a very good general solution because
<poolie> i think they're often too fuzzy to be good bugs - they are not falsifiable
<poolie> and, also, just filing a bug doesn't give much assurance that it will actually get done
<poolie> it would be weird to mark them as 'critical' and objectively they're not
<poolie> but that seems to be the priority we're giving them by blocking out a high-priority fix until they're done
<poolie> i think the core of it is just that people need to have time to make those cleanups
<poolie> remembering what they have to do is not hard if they get to do them soon (within a few days)
<poolie> and if they don't have time to do them soon, no record keeping system will help
<abentley> Similarly, we could mark them in Bundle Buggy.
<abentley> They would show up in peoples' 'todo' tab, even after they were merged.
<poolie> mm
<poolie> or we could make some more formal use of todo comments in the code
<poolie> but - i hadn't realized it til talking to you - the record keeping is not the main issue, i think
<abentley> Well, one issue is that in the short term, the follow-ups appear to have much lower priority than the original patch.
<poolie> btw i can call if you'd rather talk on the phone
<abentley> Sure, maybe that would work better.
<poolie> skype or pots?
<abentley> Skype's good.
<Spaz> lol skype
<thumper> hi people
<thumper> if I have rev_id x in branch 1, how do I find the mainline rev_no on branch 2 where rev_id x was introduced?
<lifeless> poolie: btw, I'm reasonably strongly negative on trading 'correct before landing' for 'please follow up' :- we already have 'please follow up' merges permitted; the process allows that and people use it
<fullermd> thumper: The simplest way is just to branch at that rev, and see what revno you get.
<lifeless> poolie: when reviewers ask for 'correct before landing' I believe thats because they assess that as the best route forward
<poolie> lifeless, do you want to join us?
<lifeless> poolie: If you are talking about the weighting different reviewers have, then sure
<lifeless> poolie: no, I am just doing lunch, then back to getting status purged
<lifeless> please do consider though that the current process seems to me to allow what you are talking about.
<thumper> fullermd: that's not going to tell me the right revno
<thumper> fullermd: and also I'm really wanting to do this through bzrlib
<poolie> lifeless: this is a bit of a case of "what you're asking for is either wrong or is trivial"?
<lifeless> poolie: ugh. review process is hard and complex; I'm just giving my input into your analysis. Once status is done I'd be delighted to discuss more.
<fullermd> thumper: Sure it will.  If that revision is the head, the revno will always be the same.
<fullermd> thumper: I dunno bzrlib near well enough to say in there.  I presume you could tell the revno-building function to pretend that rev was the head and just get the number directly.
<mwhudson> fullermd: uh?
<mwhudson> you have revid A
<lifeless> fullermd: I think you misunderstood the question
<mwhudson> in a branch, you add 17 revisions on top of A
<thumper> fullermd: b1 was branched from b2 at revno 3, b1 has 4 commits and has revno 7 as head.  b2 has x commits one of which introduces b1
<mwhudson> in trunk, you merge these 17 revisions and commit
<mwhudson> you want the answer to be A + 1
<fullermd> Oh.
<LaserJock> I'm reading on jelmer's bzr-svn FAQ page that one can use stacked branches for large SVN repos
<LaserJock> I'm not exactly sure what a stacked branch would do
<LaserJock> are you "stacking" on the svn repo?
<lifeless> poolie: what would have let me express my opinion without it being 'either wrong or trivial' ? I didn't say or suggest it was easy, and I was clear that it was my opinion
<mwhudson> LaserJock: yes
<lifeless> mwhudson: there is a method on branch I think
<lifeless> thumper: ^
<LaserJock> hmm, this is still gonna take forever, KDE's svn is *huge*
<beuno> lifeless, would that be _gen_revno_map ?
<beuno> I mean, get_revision_id_to_revno_map
<lifeless> ok, full test running and then submit time
<poolie> lifeless: so, basically i'm suggesting that we should look harder at cases where patches are being asked to resubmit when they are not actually wrong
<vila> hi aal
<vila> :-/ all
<beuno> hi vila
<poolie> hello vila
<jonnydee> Does anyone know if there is a similar functionality like the q*-commands of mercurial? (They allow to manage and version-control patches on a patch-stack)
<poolie> jonnydee: yes, see bzr-loom
<jonnydee> oh, that was a pretty fast answer :) thanks for your help :)
<poolie> let us know how you go
<jonnydee> ok, I'll let you know
<a_c_m> hey all :)
<ngnp> How do I move my .bzr dir out of my project. "bzr init project" create project/.bzr and I don't want it there but in ~/backup/bazaars/ for backup reasons
<Peng_> ngnp: Err.. I don't you can. You could try to move it and symlink it, but bzr would probably freak out.
<Peng_> ngnp: You could move it to ~/backups/bazaar and then make "project" a lightweight checkout of that.
<bob2> a simpler solution is to make project/ a lightweight checkout of a branch in ~/backup/bazaars
<ngnp> At Froscon some guy claimed i could be done
<Peng_> ngnp: Then ask him. :P
<spiv> Depending on how your backup system works, maybe you could just put a symlink to the .bzr dir in ~/backup/foo ?
<ngnp> Peng_: bob2: can i do a lightweight checkout with the file:// protocol?
<bob2> ngnp: yup
<spiv> But my guess is the Froscon guy was thinking of lightweight checkouts.
<Peng_> Or he was weird. :D
<ngnp> thanks guy ... i'll check it out ... dunno how to do a lightway one
<spiv> http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#using-checkouts
<ngnp> no he was not weird .... worked for sun afaik ... they are not weird guys
<ngnp> spiv: :-)
<spiv> ngnp: if you get stuck, feel free to ask for help in here.
<ngnp> thanks
<spiv> lifeless: The last two bzr.dev commits announced on bazaar-commits@ don't seem to be published yet.  Can you check if there's something awry at PQM's end?
<a_c_m> i'm not sure on the terminology, but here is the situation. I have a few generic programs (web sites) which i want to then take copies of to make clients sites, but i want an easy way, for me to say fix a bug or add some new function to the generic version, and then be able to pull that change down into the specialized ones. What is the correct terminology for this (is it upsteam?) and can anyone point me at some workflows / descriptions on 
<spiv> a_c_m: your text got cut off at "workflows / descriptions on".
<a_c_m> ï»¿ / descriptions on how to do this?
<a_c_m> :)
<spiv> a_c_m: But it sounds like you could make the "generic" version a branch called "trunk", and have the specialised versions be branches off the trunk.  You'd then merge the trunk into the branches when appropriate.
<spiv> (You don't have to call it "trunk", but it's a convention that seems to fit your situation ok)
<a_c_m> spiv: right, except ideally the projects would be self contained, with only some dev's having commit access to some projects etc... is this still possible with branches ?
<fullermd> Well, it's not possible any other way but with branches   ;)
<spiv> a_c_m: in bzr, you can't version anything without using branches :)
<spiv> So your question is effectively "is this still possible with bzr?" :)
<ngnp> spiv: I still don't get it ... I'm new to bzr, lost a day work by 'eclipse/cvs replace with head' ... I understand the 'normal' commands but setting things up is brand new :-( ... haven't created a branch yet.
<a_c_m> spiv: humm ok, but in that case, can branches have different read-write rights?
<spiv> Commit access is generally managed with regular filesystem permissions.
<a_c_m> spiv: ahh ok, that might work
 * a_c_m is also going to be trying to play with commit hooks ! 
<spiv> ngnp: so, the key thing with lightweight checkouts is that you can make a "branch" in one location, and make a "checkout" of that branch somewhere else.
<ngnp> spiv: I misread some part of the url ... i now have a working checkout ... let me test some more
<ngnp> thanks btw
<spiv> ngnp: a branch in bzr is the thing that tracks the history; i.e. "the current version is revision ABC".
<spiv> ngnp: so for instance if you are starting a new project, you could do "bzr init mybranch; bzr checkout --lightweight mybranch mycheckout".  Then all the commits etc you do in "mycheckout" will be recorded in the branch at mybranch.
<spiv> ngnp: ah cool.
<ngnp> I still have to get used with this D in drcs :p
<ngnp> spiv: thanks ...  I think I get to an understanding with bzr ... he now listens somewhat to my commands :p
 * ngnp missed some documentation about a workflow that is working in conjunction with another vcs like cvs or subversion. That is making sure the .bzr is not committed into cvs/subversion and not overwritten by a 'cvs replace from head'
<spiv> ngnp: Off the top of my head, it'd probably be enough to make bzr ignore 'CVS', and make cvs ignore '.bzr'?
<ngnp> a_c_m: can we upgrade these pages http://drupal.org/node/45368 together?
<a_c_m> hey ngnp
<a_c_m> i will help where i can for sure
<ngnp> spiv: me stupid ... you are so right :-)
<ngnp> .cvsignore
<ngnp> hmm ... but that does not prevent a 'replace from head' if i'm not in control of the cvs ... which is the case ... I do some patches for drupal as an anonymous cvs user ...
<a_c_m> i'm trying to build an "uber" system, PQM to check against coding standards (and perhaps even coder) before commiting
<ngnp> a_c_m: after I have this cvs/bzr workflow a little in place i'll update those pages
<ngnp> a_c_m: auto coder ... is that possible? (sorry for the drupal talk)
<a_c_m> ngnp: http://www.trellon.com/blog/daily-quality-control-checks-coder
<ngnp> a_c_m: thanks ... have you tried drush_mm too?
<a_c_m> not yet
<stewart> lifeless: ping, aronud again? came back at about 4:50am (in europe atm), and went to bed instead of responding :)
<LeoNerd> Hrm...
<LeoNerd> bzr baz-import => This command is disabled.  Please install PyBaz.
<LeoNerd> apt-get install pybaz => E: Package pybaz has no installation candidate
<Stavros> hello
<Stavros> is there in bzr something equivalent to git rebase?
<james_w> Stavros: there's a bzr-rebase plugin
<Stavros> james_w: ah, thanks
<Stavros> actually i want to branch some official code and make some changes to it, keeping up with the official version. what's the best way to do that?
<james_w> get a branch of the code and work on it, and occaisionally "bzr merge" the official version
<Stavros> ah, i don't need rebase then?
<james_w> you could use rebase, but they will both do what you want
<Stavros> great, thanks
<james_w> they will just do it in slightly different ways
<Stavros> hmm yes
<Stavros> i'm looking to keep my drupal installation up to date, so i figured i can pull from their repo, but i have some local changes
<james_w> siretart: hi, would you be available for sponsoring an upload today?
<siretart> james_w: sure
<james_w> siretart: great, thanks. Do you have time now, or would you prefer to wait until after work?
<siretart> james_w: perhaps you can sign and upload to alioth, and I'll rebuild and upload it to debian?
<james_w> siretart: that works for me.
<james_w> siretart: they're in /srv/alioth.debian.org/chroot/home/groups/pkg-bazaar/htdocs/2.0.1
<james_w> siretart: targeted at experimental
<james_w> siretart: I would like this version in Intrepid, is a sync request going to be processed in a timely manner do you think? Or should a fakesync be done?
<siretart> it depends on how hard you hit the archive admins ;)
<LeoNerd> Does bzr have the equivalent of tla/baz's "sync-tree".. Ie. pretend I have a commit when really I don't...?
<LeoNerd> I have two longlived branches that I crossmerge a lot; it would be nice to be able to ignore all the merges in one side on the other
<LeoNerd> .oO( Mm.. I suppose merge + revert might do it... )
<siretart> james_w: is the Vcs-Bzr location in debian/control up to date? it seems the last commit there was in march
<james_w> siretart: no, you are correct
<Kinnison> LeoNerd: I tend to pull when I can, so if I know I've merged on my laptop, and haven't committed recently on the desktop, I pull from the laptop.
<Kinnison> LeoNerd: that kind of thing
<LeoNerd> Kinnison: Ya.. this is for two branches of some code that's quite diverged between them, for the last.. er.. 4 years
<james_w> siretart: fixed packages uploaded
<Kinnison> LeoNerd: aah, :)
<james_w> siretart: thanks a lot.
<siretart> you're welcome!
<Stavros> hello
<Stavros> will bzrtools ever be included in the repo so there aren't broken dependencies?
<jelmer> james_w:ping
<james_w> hey jelmer
<jelmer> james_w, hi!
<jelmer> james_w, I noticed the function that exports tarballs is a bit simpler now in bzr
<jelmer> james_w, I was wondering whether bzr-builddeb could perhaps just call that directly and override the last modification time?
<james_w> jelmer: perhaps, I haven't looked at the changes
<jelmer> james_w, you have no objections to calling the tarball creating function directly and bypassing the export infrastructure though?
<james_w> jelmer: ah, I think I get it now. I'd have to see the patch really, but I have no objection on principle.
<james_w> jelmer: the only think would be that it ignores .bzr* as the export code does
<jelmer> james_w, It's still exercising that code
<jelmer> http://samba.org/~jelmer/bzr-builddeb-tar-exporter.diff
<james_w> jelmer: I see "def tar_exporter(tree, dest, root, subdir, compression=None):"
<jelmer> I've got a patch for bzr.dev as well that allows overriding "now"
<james_w> ah
<james_w> once that patch is in bzr.dev I don't really care how the builddeb bit is done, so your patch would be fine
<jelmer> cool, thanks
<james_w> jelmer: does the bzr.dev patch also use the time from the tree if it is not overridden?
<jelmer> it uses the time.time() as was done previously
<james_w> ok
<james_w> it could use tree.get_file_mtime() instead
<jelmer> Hmm, I wasn't aware of that function
<jelmer> When using that, bzr-builddeb wouldn't need patching anyway
<james_w> for revision trees I think it just backs on to the timestamp of the revision
<jelmer> ah, but that is too slow for real use..
<jelmer> hmm
 * jelmer gives up
<Leonidas> what do I need to do to move the TREE_ROOT?
<Leonidas> I tried setting set_root_id and deleting the former root folder, but that throws exceptions.
<pysquared> Hi all, I have been evaluating Bazaar, and want to get away from CVS.
<pysquared> One nice thing about CVS was that I understood how it represented files and revisions and subdirectories etc. and therefore what it might be able to do for me.
<pysquared> Does anyone know where I could find similar info about Bazaar without attempting to grok the source?
<jelmer> pysquared, you may want to look in doc/developer/
<jelmer> *-format.txt in particular
<pysquared> jelmer, thanks, will do
<Leonidas> abentley: In the commit that I saw, there was a new file called '' with the fileid TREE_ROOT created and the old '', with tree_root-* deleted. But when I try changing the root_id and deleting '', it throws an exception
<strk> guys, I manually installed bzr latest (1.6) on a Debian stable.
<strk> then I 'bzr branch sftp://strk@......'
<strk> modified, commit
<strk> and (wow: commit was incredibly fast)
<strk> well, now I pull from other machines and my changes are not there
<strk> no wonder commit was fast :)
<strk> so, hints on how to find out what happened ? bzr status shows no changes.
<strk> on push: bzr: ERROR: These branches have diverged.  Try using "merge" and then "push".
<strk> so, does it mean my commits were "offline" ?
<Leonidas> strk: your commits are always offline, that's the nature of DVCS
<Leonidas> strk: I'd try a pull (to get the newest changes), merge and then a push.
<james_w> strk: if you "bzr branch" instead of "bzr commit" then all commits are offline, "bzr bind" will bind your branch to the master branch so that they are no longer offline by default
<strk> bzr: ERROR: Operation denied because it would change the main history, which is not permitted by the append_revisions_only setting on branch "sftp://strk@bzr.savannah.gnu.org/srv/bzr/gnash/trunk/".
<james_w> strk: that was for the bind?
<ngnp> This Quick Start Card is not a quick start http://doc.bazaar-vcs.org/bzr.dev/en/quick-reference/quick-start-summary.svg as I do not understand ie bzr branch mp myproject ... how to make this better? File a bug?
<Leonidas> ngnp: file a patch would be more effective :)
<ngnp> how? I'm a newbie to bzr
<Leonidas> ngnp: bzr branch np mayproject branches the repo in the mp directory to the myproject directory.
<strk> james_w: nope, that was for push. Trying bind now.
<Leonidas> ngnp: basically, this is a quick reference, not a quick start tutorial. It's just useful then you know how things work, but forgot the commands.
<ngnp> Leonidas: I know after testing ... but it should be more like "bzr branck myproject newproject"
<strk> still, the bind gave me no automatic commit of the pending changes
<Leonidas> ngnp: download the file, edit it, run diff and create a bug with a patch added to it.
<strk> and push still gives me "Operation denied"
<ngnp> Leonidas: that's part of that patch :-) ... how to patch is now the question ;-(
<strk> now how do I get out of this ?
<ngnp> Leonidas: ok
<Leonidas> strk: if you want to have SVN-like workflow one normally uses bzr checkout.
<james_w> strk: does "bzr update" bring in the remote changes now?
<james_w> strk: it will leave pending merges of the things you committed "offline"
<strk> Your local commits will now show as pending merges with 'bzr status', and can be committed with 'bzr commit'.
<strk> ah, great :)
<strk> update seemed to help
<strk> now I commit ? (I'm bound now)
<james_w> strk: yeah, if you commit now then it will happen "online", and so the master branch will receive your offline commits
<strk> and they'll look like a merge
<james_w> strk: exactly
<strk> now, how do I go to make each of my offline commits appear as online ones ? is that possible at all ?
<strk> the use for it would be for gnulog to produce nicer ChangeLog entries basically
<james_w> ngnp: a bug explaining clearly the problem and how you think it could be improved would be ok
<james_w> strk: ok, that's possible, it will take me a minute to find the best way to do it.
<ngnp> james_w: I'm inkscaping atm :-)
<james_w> strk: you will need to do a rebase if you want this, do you have bzr-rebase installed?
<james_w> strk: ok I believe "bzr rebase --pending-merges" will do what you want
<Leonidas> how can I change the directory that is used as root directory?
<ngnp> james_w: what project the bug is for?
<james_w> ngnp: bzr please
<plexq> how can I diff two branches?
<james_w> plexq: there are a couple of ways
<james_w> plexq: "bzr diff --old ../other-branch" from one of them is one way
<james_w> "bzr diff -rbranch:../other-branch " would be a second
<Leonidas> what do I need to change the root directory in a repository?
<ngnp> james_w: see https://bugs.launchpad.net/bzr/+bug/273160
<ubottu> Ubuntu bug 273160 in bzr "The quick start card is actually a quick reference card" [Undecided,New]
<james_w> thanks ngnp
<ngnp> james_w: thank you!
<ngnp> hmmm ... that patch is not in order .... bzr branch myproject newproject .... as ... bzr branch --help ... suggests FROM_TARGET TO_TARGET ... any suggestion with this?
<rkerr> problem...
<rkerr> "If you're sure that it's not being modified, use bzr break-lock lp-140342092://..."
<rkerr> bzr: ERROR: Unsupported protocol for url "lp-140342092://..."
<ngnp> so I had to type  bzr branch ./myproject ./newproject :-( including the path
<nandersson> Verterok, Hi, I'm about to file a bug in bzr-eclipse regarding "bzr tag" support, but I'm not sure how it would best be implemented
<nandersson> To me it makes sense to place it together with "commit"
<Verterok> nandersson: hi!
<nandersson> In order not to clog down the right click menu
<nandersson> Because I think that "bzr tag" is a thing you don't do that often - not as often as a commit
<nandersson> and my guess is that you first commit, then tag, when you're "tagging" a source tree
<Verterok> nandersson: so, adding a "commit & tag" feature in the commit dialog? (like the optional fixes or adding untracked in commit)
<nandersson> i.e you don't want to tag a tree that isn't first commited
<nandersson> Verterok, yes, thats how I see it - I don't know if others agree
<james_w> ngnp: that should be no different to "bzr branch myproject newproject"
<nandersson> But to me it makes sense
<nandersson> I can't see where you would like to tag a branch that isn't commited.
<Verterok> nandersson: I think both approaches could coexist, i.e: having a tag dialog, and the optional "tag after commit" in the commit dialog
<nandersson> In that case - it makes sense to put it in the "commit" dialog
<nandersson> Verterok, yes, of course - and if you tag a tree that is modified I think you should raise a warning
<Verterok> nandersson: ok, file the bug with your requirement, and this comment about raising a warning (I like it :))
<nandersson> Verterok, I'll do that. I think that's how it should be implemented
<nandersson> Verterok, BzrEclipse works as a charm - very nice job indeed
<Verterok> nandersson: if someone want to have it outside the commit dialog, I can easily add a standalone tag dialog (once it's implemented for the commit) ;)
<Verterok> nandersson: thanks, I really appreciate this kind of feedback :-D
<nandersson> Verterok, yes, I guess there could be scenarios when you realize that the existing tree should be "tagged" Good to have it as an option
<nandersson> Verterok, I'm glad I can help out :)
<Verterok> nandersson: by the way, I'll be rolling out a new build at the end of the day, (minor bug fix, related to xmlrpc service, and possibly a new option to limit the log fetching)
<nandersson> Verterok, cool :) I update then
<Verterok> nandersson: if you are interested in peeking what I've playing with, I have a screensshot (it's just a prototype) of future launchpad integration (via launchpadlib) :) http://verterok.com.ar/images/BranchList_prototype.png
<Verterok> nandersson: my idea is to allow branching directly from that list, I'm sure there are other possible use cases
<Verterok> nandersson: but it's just a prototype, it need a lot more work to make it "usable"
<nandersson> Verterok, That looks cool. Perhaps something that could be used together with the "New -> Other -> Bazaar"-Wizard?
<nandersson> Verterok, i.e to have the possibility there to browse your launchpad code repository?
<Verterok> nandersson: ideed, and with all dialogs that asks for a branch location :)
<nandersson> Verterok, or projects that have your name on it - if that is possible
<Verterok> nandersson: launchadlib, it's still in early stages, so I depend on what features it provides. ATM, it only allows to get the branches of a project
<Verterok> nandersson: but I'm sure that's going to change soon :)
<nandersson> Verterok, cool, I think that would be an effort then that depends on what Launchpad provides. a "Navigate Launchpad"-feature would be cool.
<nandersson> Verterok, but I guess it is also dependent on the amount of data that flows between LP and Eclipse
<nandersson> Verterok, what you said about Mylyn seems interesting - and to connect Eclipse with the bugtracker and TODO-lists
<Verterok> nandersson: sure, quering LP is in the roadmap of launchpadlib, so it 'll land sooner than later. that 'ld allow me to add the "Navigate" option
<nandersson> Verterok, I filed the bug by the way with some useful links
<Verterok> nandersson: Mylyn integration is also on it way ;)
<Verterok> nandersson: great!, thanks.
<Verterok> nandersson: I just need a bit more of time to put on this, too many things to do :p
<nandersson> Verterok, hehe, I can imagine :-)
<nandersson> Verterok, Now I'm very pleased with the workflow. The rest is pure features
<Verterok> nandersson: great to know.
<pagenoare> Hello
<Verterok> pagenoare: Hi
<frikazoyd> So when using bzr, is there a way to release locks automatically once you push?
<frikazoyd> Or an option for push that releases locks?  I didn't see one immediately
 * LarstiQ blinks
<LarstiQ> frikazoyd: I'm not sure what you mean?
<frikazoyd> Okay
<frikazoyd> So we just started using bzr for a project
<frikazoyd> Now I committed some files, and that went fine.  Everything seems to work so far.
<frikazoyd> But then someone else wanted to edit that file, and couldn't commit his changes.  Said I had a lock on it
<frikazoyd> but I was done with it.  And I didn't request a lock on it in the first place.
<frikazoyd> so he broke my lock
<frikazoyd> now, I couldn't pull after that.  Had to do a merge, and now I can't commit without breaking his locks and further causing problems down this vein
<LarstiQ> that's rather weird
<LarstiQ> frikazoyd: in normal operation, locks don't get left around
<frikazoyd> Hm
<frikazoyd> so something may be borked
<LarstiQ> frikazoyd: a lock either means: someone is actively doing something with it, or, a client got interrupted (^C) and didn't get the chance to clean up
<frikazoyd> Hm
<LarstiQ> frikazoyd: if you're getting locks strewn all over in regular operation, something is wrong.
<frikazoyd> I know neither is the case at the moment
<ngnp> james_w: i do not copy :p ... is bzr branch myproject newproject should work?
<ngnp> ok ... i tested it without ./ and it worked ... aargh
 * ngnp go to sleep
<aa_> hi, anyone got any experience (nice way) to do a bzr mirror of an hg repo?
<mwhudson> aa_: there's bzr-hg, don't know how well that works currently
<aa_> mwhudson: just trying it, it kind of hates me :)
<mwhudson> aa_: and a fast-import based stuffs
<aa_> hmm, is there a way I can get an actual traceback with the "send this traceback to bug tracker"
<aa_> I just get some output about version and thing, but no traceback
<rsc-> hey guys.
<rsc-> so lets say I made a local branch out of a remote branch (bzr branch lp:xxxxx). if I made 10 new revisions on my local branch, how can I update the remote branch with just one consolidated revision?
<beuno> rsc-, branch the remote branch again
<romaia> Hello there. Does someone have a quick reference for a server-side post push hook that updates the tree after the push?
<beuno> rsc-, and, locally, go to that branch, bzr merge ../otherbranch
<rsc-> okay
<beuno> commit n' push
<beuno> you can also just do a checkout
<beuno> and just commit
<rsc-> what do you mean?
<beuno> isntead of a branch again, do: bzr co lp:xxx
<beuno> so, when you commit, it will send the changes
<beuno> so you don't need to push
<rsc-> oh, right
<beuno> checkouts are bound to it's parents
<rsc-> it sort of automatically pushes it
<rsc-> because it's the "same" branch, just stored in 2 different locations, right?
<beuno> yeap
<rsc-> are there locks?
<rsc-> like in svn?
<beuno> yes, it takes out some write locks in certain cases
<rsc-> okay
<rsc-> when i do a "bzr merge", can I use meld?
<rsc-> to preview the changes to be done?
<rsc-> and perhaps to decide on how to merge certain conflicting files
<beuno> yeap, you can
<rsc-> how do i do that?
<beuno> with bzr-extmerge plugin
<rsc-> sounds good.
<rsc-> not sure if its in the ubuntu repositories though
<beuno> it isn't
<beuno> mkdir ~/.bazaar/plugins
<rsc-> but im sure it's easy to install. ill check it out :)
<beuno> bzr co lp:bzr-extmerge ~/.bazaar/plugins/extmerge
<beuno> and you're set
<rsc-> so do i just do "bzr extmerge" in place of "bzr merge" ?
<beuno> well, you can do bzr help after you install the plugin  :)
<beuno> I don't really remember
<Verterok> rsc-: you should do something like: bzr extmerge <file_with_conflicts>
<Verterok> hey beuno
<rsc-> okay
<beuno> hey Verterok
<Verterok> rsc-: after you executed a 'bzr merge'
 * Verterok brb
<rsc-> oh there we go
<rsc-> hmm, extmerge does a 3 way diff. shouldn't it be 2 way? (my changes vs. remote changes)
<mwhudson> i usually just run 'meld .' after a merge
<mwhudson> oh, he left
<poolie> good morning
<Verterok> hi poolie
<lifeless> abentley: your preview intertree diff seems to include lots of stuff in NEWS that isn't part of your branch; I haven't read further yet because I presume you had an our of date bzr.dev mirror or some such
<abentley> lifeless: Yes, that's why I sent in a corrected one.
<lifeless> abentley: cool, I haven't seen that yet
<abentley> lifeless: Subject was [MERGE] Intertree testing for PreviewTree
<lifeless> great, thanks
<lifeless> jam: when do you finish?
#bzr 2008-09-23
<MapMan> hello! Im seeking help!
<MapMan> frikazoyd: oh hai
<frikazoyd> beat you to it
<frikazoyd> :P
<Verterok> MapMan: just ask
<MapMan> Verterok: my mate frikazoyd already asked
<Verterok> ok, then
<MapMan> maybe you can help us though
<MapMan> we have a problem with bzr
<MapMan> every commit > push causes a lock
<MapMan> and everytime someone wants to push, he needs to break lock
<lifeless> well, I know where my disk space has gone
<lifeless> evo -> 6.4g used
<lifeless> !!!
<lifeless> frikazoyd: the branch you are pushing to; is it on nfs/ftp/sftp/bzr+ssh ?
<lifeless> frikazoyd: and are the permissions set to allow both of you to create and delete common files?
<MapMan> its ftp mate
<MapMan> i dunno about the permissions, i havnt seen the cfg
<lifeless> check in ~/.bzr.log for errors related to deleting
<lifeless> (unless break-lock does work, in which case you clearly can delete)
<lifeless> might be a ftp server bug that you can't delete a file you created in the same session or something weird
<lifeless> anyhow, its not usual, we do work on ftp; please file a bug and the devs can ask for details there to figure out whats wrong (if you can't figure out a config issue shortly)
<aa_> hi everyone
<aa_> I get this error trying to push: http://paste.pocoo.org/show/86007/
<aa_> now I try what it suggested but unknown protocol
<aa_> is it a launhcpad thing or a bzr thing?
<spiv> aa_: it's a bit of both
<spiv> aa_: use bzr break-lock with your usual URL.
<spiv> aa_: e.g. bzr break-lock lp:~name/proj/foo
<frikazoyd> Lifeless:  The problem isn't that we can't delete, the problem is that a lock is automatically created if someone pushes
<frikazoyd> and it doesn't release
<frikazoyd> so if I commit a file in a local branch and then push, it puts a lock on the central repo I'm pushing to
<frikazoyd> so nobody else can push that file either (even if it is up to date before editing) unless they break my lock
<frikazoyd> We don't want to have to break locks to commit and merge every time someone changes an existing file
<lifeless> frikazoyd: I'm talking about the technical details required to manage the transient locks bzr uses to ensure data consistency as it pushes
<lifeless> frikazoyd: please assume I understand exactly what you want and how it works and am trying to help you get it to work as it *should* for you.
<frikazoyd> Oh
<frikazoyd> the .bzr.log file doesn't exist
<frikazoyd> also breaking works fine
<lifeless> bzr --version
<lifeless> will have a line like
<lifeless>   Bazaar log file: /home/robertc/.bzr.log
<lifeless> with the full path to the local log file
<MapMan> we use windows binaries
<frikazoyd> Okay
<frikazoyd> Map:  You can do it from command line :P
<MapMan> its in default user folder in windows
<MapMan> I hate that, it should be placed in apps folder
<aa_> spiv: I did that and it returns without error, but it doesn't break the lock
<aa_> spiv: doesn't break the lock == still has the cannot get lock error
<spiv> aa_: its https://bugs.edge.launchpad.net/bzr/+bug/255062, btw
<ubottu> Ubuntu bug 255062 in bzr "bzr: ERROR: Invalid url supplied to transport: "Host empty in" [High,Confirmed]
<spiv> aa_: That should break the lock.  You could try "bzr break-lock sftp://aafshar@bazaar.launchpad.net/~glashammer-devs/glashammer/glashammer-main" instead, but that shouldn't be any different.
<spiv> aa_: Hmm, by "returns without error", you mean it doesn't output anything, not even a prompt?
<aa_> spiv: no just returns
<aa_> I get the shell prompt afterwards
<aa_> and return code is 0
<spiv> Ok, then there is no lock to break.
<aa_> "locked 24 minutes, 59 seconds ago"
<spiv> What's cannot get lock error look like?
<aa_> spiv: that thing I apsted
<spiv> (and on what operation?)
<aa_> on bzr push
<aa_> its exactly the thing I pasted here http://paste.pocoo.org/show/86007/ except the time is creeping up
<spiv> Is your launchpad user a member of glashammer-devs?
<aa_> yes
<spiv> Hmm, it appears it is.
<spiv> What URL exactly is your local branch pushing to?
<aa_> spiv: if I forget about it for a while is it likely to go away, or will it stay forever?
<spiv> It isn't going to go away by itself unless the connection that created it is still connected.
<aa_> bzr push bzr+ssh://aafshar@bazaar.launchpad.net/%7Eglashammer-devs/glashammer/glashammer-main/
<aa_> locked 30 minutes, 44 seconds ago? [y/n]:
<aa_> that's new
<aa_> yay
<aa_> spiv: guess I was running break-lock on the wrong url
<aa_> spiv: sorry for the bother
<spiv> That's ok.
<spiv> Glad to hear that you're sorted.
<Odd_Bloke> poolie: Did you get my email with bank details?  I never got an ACK.
<poolie> Odd_Bloke: hi, yes, i passed it on to our finance guy
<Odd_Bloke> poolie: Cool, thanks. :)
<poolie> i wonder if gpg defeated him because i didn't hear anything myself :)
<Odd_Bloke> Heh.
<poolie> but i did send an extra comment explaining it
<igc> morning all
<poolie> hello igc, how are you going?
<igc> hi poolie - ok today
<Odd_Bloke> igc: Hey, long time no see.
<igc> hi Odd_Bloke!
<poolie> jam, the description of the change to log seems to make sense to me too
<poolie> if you want me to look at it harder, just say so
<poolie> i'm trying to work out what's up with the oldest queued patch, "setlocale (bug 128496)"
<ubottu> Launchpad bug 128496 in bzr-svn "Unable to open native working tree with non-ascii filenames" [Medium,Fix released] https://launchpad.net/bugs/128496
<lifeless> is it correct that opening a RemoteBranch always opens the underlying disk branch ?
<poolie> yes
<lifeless> k, I'll do an isinstance in my branch hook open tests
<poolie> hrm, ok
<poolie> lifeless: it's a bit hard to avoid it given the repository stacking must be configured when the branch is opened
<lifeless> poolie: yeah
<lifeless> poolie: its just to make the interface tests that say what the hook should do, pass
<poolie> obviously you could just make a promise to do it later, but iirc people have argued errors with the repo must be detected then
<lifeless> If spiv knows that opening a remote branch generates remote + normal object
<spiv> I'm aware that the stacking stuff has caused that, yeah :(
<lifeless> elf.assertEqual([b], self.hook_calls)
<lifeless> AssertionError: not equal:
<lifeless> a = [RemoteBranch(bzr://127.0.0.1:49396/extra/)]
<lifeless> b = [RemoteBranch(bzr://127.0.0.1:49396/extra/),
<lifeless>  BzrBranch6('chroot-46912499497232:///')]self.assertEqual([b], self.hook_calls)
<lifeless> AssertionError: not equal:
<lifeless> a = [RemoteBranch(bzr://127.0.0.1:49396/extra/)]
<lifeless> b = [RemoteBranch(bzr://127.0.0.1:49396/extra/),
<lifeless>  BzrBranch6('chroot-46912499497232:///')]
<lifeless>  BzrBranch6('chroot-46912499497232:///')]self.assertEqual([b], self.hook_calls)
<lifeless> AssertionError: not equal:
<lifeless> a = [RemoteBranch(bzr://127.0.0.1:49396/extra/)]
<lifeless> b = [RemoteBranch(bzr://127.0.0.1:49396/extra/),
<lifeless>  BzrBranch6('chroot-46912499497232:///')]
<lifeless>  BzrBranch6('chroot-46912499497232:///')]self.assertEqual([b], self.hook_calls)
<lifeless> AssertionError: not equal:
<lifeless> a = [RemoteBranch(bzr://127.0.0.1:49396/extra/)]
<lifeless> b = [RemoteBranch(bzr://127.0.0.1:49396/extra/),
<lifeless>  BzrBranch6('chroot-46912499497232:///')]
<lifeless>  BzrBranch6('chroot-46912499497232:///')]self.assertEqual([b], self.hook_calls)
<lifeless> AssertionError: not equal:
<lifeless> a = [RemoteBranch(bzr://127.0.0.1:49396/extra/)]
<lifeless> b = [RemoteBranch(bzr://127.0.0.1:49396/extra/),
<lifeless>  BzrBranch6('chroot-46912499497232:///')]
<lifeless>  BzrBranch6('chroot-46912499497232:///')]self.assertEqual([b], self.hook_calls)
<lifeless> AssertionError: not equal:
<lifeless> a = [RemoteBranch(bzr://127.0.0.1:49396/extra/)]
<lifeless> b = [RemoteBranch(bzr://127.0.0.1:49396/extra/),
<lifeless>  BzrBranch6('chroot-46912499497232:///')]
<lifeless>  BzrBranch6('chroot-46912499497232:///')]self.assertEqual([b], self.hook_calls)
<lifeless> AssertionError: not equal:
<lifeless> a = [RemoteBranch(bzr://127.0.0.1:49396/extra/)]
<lifeless> b = [RemoteBranch(bzr://127.0.0.1:49396/extra/),
<lifeless>  BzrBranch6('chroot-46912499497232:///')]
<lifeless>  BzrBranch6('chroot-46912499497232:///')]self.assertEqual([b], self.hook_calls)
<mwhudson> lifeless: oops
<lifeless> AssertionError: not equal:
<lifeless> a = [RemoteBranch(bzr://127.0.0.1:49396/extra/)]
<lifeless> b = [RemoteBranch(bzr://127.0.0.1:49396/extra/),
<lifeless>  BzrBranch6('chroot-46912499497232:///')]
<lifeless>  BzrBranch6('chroot-46912499497232:///')]self.assertEqual([b], self.hook_calls)
<lifeless> AssertionError: not equal:
<lifeless> a = [RemoteBranch(bzr://127.0.0.1:49396/extra/)]
<lifeless> b = [RemoteBranch(bzr://127.0.0.1:49396/extra/),
<lifeless> oooooh
<lifeless> sorry
<lifeless> no idea what caused that; wifi glitch I guess
<lifeless> (it wasn't pasting, so I tried again..)
<spiv> lifeless: stop playing hopscotch on your middle mouse button ;)
<lifeless> spiv: anyhow
<lifeless> self.assertEqual([b], self.hook_calls)
<lifeless> AssertionError: not equal:
<lifeless> a = [RemoteBranch(bzr://127.0.0.1:49396/extra/)]
<lifeless> b = [RemoteBranch(bzr://127.0.0.1:49396/extra/),
<lifeless>  BzrBranch6('chroot-46912499497232:///')]
<lifeless> thats the clear unmixed up assertion
<lifeless> so I propose to isinstance it and changed the expect value appropriately.
<lifeless> that sound ok?
<spiv> (sorry, lag on my end isn't helping)
<spiv> adjusting the test for the RemoteBranch scenario to assert that the hook observes the same remote branch get opened, plus a non-RemoteBranch, sounds good to me.
<spiv> Given that's what (currently) happens.
<lifeless> well specifically, I'll use the real branch from the opened branch
<spiv> Ah, ok.
<lifeless> we know what it is after all, no need for a hand-wave
<spiv> Yeah, that makes sense. "if isinstance(b, RemoteBranch): expected.append(b._real_branch)", basically?
<lifeless> yes
<spiv> Sounds reasonable.
<lifeless> is that bb:approve to this change ?
<spiv> Sure.
<lifeless> thanks
<lifeless> oh, I see, it is a remote VFS call already
<lifeless> tweaking more
<lifeless> can I ask though, why the current find_branch wasn't just extended to return the stacking url as well, to avoid additional round trips ?
<lifeless> spiv: here?
<spiv> lifeless: intermittently, it seems.
<spiv> "Lag: 51 (??)"
 * spiv restarts irssi
<spiv> Well, the "good" news is that restarting irssi didn't magically make IRC stop lagging.
<Spaz> does it still lag with other clients?
 * igc lunch
<nealmcb> I just did a "bzr add" of some files I didn't really want to add.   I've been stung in the past because iirc immediately doing "bzr remove" actually removed the file.  how do I un-do the "add".  I haven't committed yet
<AfC> nealmcb: use Bazaar's remove command, but add the --keep option
<AfC> $ bzr rm --keep path/to/file/I/added/by/mistake.txt
<nealmcb> AfC: thanks.  Last time I think I decided that --new  would do that (Remove newly-added files) but --keep looks much better  :)
<AfC> Although as I read the help for remove in 1.7rc1 I see it say "--safe       Only delete files if they can be safely recovered (default)."
<Peng_> What about "bzr revert"ing them? Would that work?
<AfC> which would make me think that you would have been ok after all.
<AfC> Peng_: I imagine Bazaar would respond by complaining that the paths aren't versioned. (ie, "How can I revert a file to a state that I don't know about?"). But it might have special case logic. One way t find out.
<Peng_> Yeah, "revert" works
<Peng_> If "rm" deleted an unversioned file, that would be a bug.
<AfC> Nice
<lifeless> also, I think bzr rm <added-file> should act like revert, IMO. I don't know if it *does*, but it seems like a sensible default to me.
<Peng_> "bzr rm added-file" errors out with "bzr: ERROR: Can't safely remove modified or unknown files".
<Peng_> "bzr rm --keep added-file" works fine, just like revert.
<Peng_> Hmm, I should test "--new".
<lifeless> poolie: don't-sha-added-files is passing micro-tests, full run underway
<lifeless> -> lunch
<poolie> lifeless, nice
 * fullermd ponders.
<fullermd> 1.7 isn't yet, right?
<fullermd> Hm.  Webiste doesn't like rc2 either.  Wacky.
<lifeless> all tests pass. wahoo
<poolie> lifeless, i was thinking of changing the test runner so that if a test fails it shows the stacktrace rightaway
<poolie> rather than waiting til the suite has finished
<lifeless> poolie: as an option ?
<poolie> if necessary
<poolie> i find i'd often like to start looking at the first failure while it's running....
<lifeless> I'm pretty sure I had a project once that output nothing at all, except error traces, and those as they happened
<lifeless> weirded people out
<lifeless> uhm
<lifeless> I'm personally pretty happy with the current behaviour, but then if I'm running either to get all the errors to filter, or with -1, as a general pattern
<poolie> i can't parse that "either"
<vila> hi all !
<spiv> vila: good afternoon
<lifeless> I tend to run bzr selftest in one of a few modes
<lifeless> with -1, to find and debug a failure
<lifeless> without -1 to find all the failures (and I want a compact manner of inspecting them
<lifeless> without -1 on a small set of tests (found by the previous run)
<lifeless> I've mentioned before wanting to do a machine parsable output to file to automate this more
<poolie> ok, same
<vila> I do the same. And when I get a small enough set of failing tests, I start putting some pdb.set_trace()
<lifeless> I don't know if this is optimal, or an accomodation of sorts
<poolie> the main thing i want is to not have to wait until all of them run to find the rest
<lifeless> other data point is I run from within vim
<lifeless> so I'm always going to be waiting
<poolie> possibly it would be better to write them either to a separate file (maybe in a subdirectory)
<poolie> or to use tribunal or something
<vila> But sometimes, I wish I had the traceback for one of them. In that case I C-c and re-run only that tests with --starting-with
<poolie> oh btw i have a vim tip
<poolie> for when switching to another branch
<poolie> do :1,9999bdel to remove everything already in memory
<poolie> and avoid accidentally editing files from your old directory
<lifeless> poolie: heh, I don't need that
<lifeless> I suspect I use vim rather...differently to you
<Odd_Bloke> vila: I used --starting-with when writing the `branch --standalone` stuff, and it's much faster.  Good job on that. :)
<vila> Odd_Bloke: you're welcome :)
<poolie> probably
<poolie> to start with i use gvim
<Odd_Bloke> Heresy!
<poolie> quitting and restarting is adequate but it's nice to know an alternative
<lifeless> poolie: yahh, I use text vim, and many concurrent sessions
<jml> spiv: ping
<spiv> jml: pong
<a_c_m> anyone know any good (semi idiot) tutorials on setting up bzr with pqm (ie automated gatekeeper workflow)
<dereine> hi
<dereine> how can i get all changed files since the init
<dereine> or all changed files between two revisions
<james_w> a_c_m: I don't know of one, sorry
<a_c_m> james_w: yeah thats a shame... i'm googling for one now
<james_w> dereine: "bzr status -r" may be what you want
<james_w> e.g. bzr status -r2..3
<dereine> thx
<dereine> how do i get the latest revision?
<james_w> what do you mean?
<lifeless> the pqm docs include setup info; file bugs please if its not enough
<lifeless> dereine: '-1' refers to the tip revision
<siretart> lifeless: maybe I didn't get what you mean with 'part of the target that pqm runs to run tests could update NEWS'
<lifeless> siretart: there is a Makefile
<lifeless> siretart: it has targets; one of those targets is dedicated to PQM, its the 'run this when doing a merge' target
<lifeless> siretart: I'm suggesting it can be extended to also update the NEWS file from the merge source (because its run in a tree with a pending merge, it can do $something to do this)
<siretart> lifeless: okay. does this $something include the results of the testsuite?
<lifeless> siretart: no
<lifeless> siretart: I'm talking about the NEWS file
<lifeless> siretart: which is a problem for merges
<siretart> okay. then I misunderstood you completely. ignore me then
<lifeless> siretart: I don't understand why you are talking about test suite output - its always all-pass because thats the policy for PQM
<lifeless> siretart: if it fails, we don't commit it
<lifeless> siretart: If Debian is packaging bzr with test failures, thats bad, and it should definitely stop doing that :P
<siretart> last upload contained some known pycurl failures that I was told were harmless
<lifeless> they happen consistently on recent pycurls, I'm not convinced they are harmless
<lifeless> visik7: ^
<lifeless> erm
<lifeless> vila: ^
<lifeless> sorry visik7
<lifeless> siretart: I am curious why you thought a thread about NEWS was related to Debian packaging ?
<lifeless> oops, community council meeting time, back later
<siretart> lifeless: I was under the impression you wanted to include results of the testsuite to NEWS
<lifeless> wow
<lifeless> I guess its context
<lifeless> you may not but NEWS is a continual merge headache
<lifeless> because entries may merge ok but be in the wrong release etc
<vila> siretart: I'd be *very* interested about those pycurl failures, do you have some selftest output ?
<siretart> not anymore, I removed the output some days after my upload
<siretart> lifeless: see, it might make sense to install the selftest output in the package after all ;)
<lifeless> siretart: sure, I wasn't saying it was a bad idea, just totally confusing for me in that tread
<siretart> yes, I was confused as well. sorry
<lifeless> siretart: it was a non sequiter :)
<vila> siretart: mail me the next time you run the test suite then :)
<lifeless> vila: there is a bug
<vila> lifeless: only one ? Gosh, we're close :)
<vila> lifeless: yes ? What bug ?
<lifeless> vila: on the pycurl failures
<vila> You can reproduce it ?
<lifeless> spiv can
<spiv> I can't anymore; it got fixed AFAICT.
<vila> the poll/select one ?
<spiv> Yep, that's the one I used to see.
<vila> a nightmare :)
<lifeless> siretart: how long ago was the upload?
<vila> Once I upgraded to hardy it popped up everywhere :)
<siretart> lifeless: that was the last upload to debian experimental
<lifeless> siretart: not what, when
<siretart> sep 5, 2008
<vila> siretart: does it looks like bug #225020 ?
<ubottu> Launchpad bug 225020 in bzr "pycurl reports "select/poll returned error"" [High,Fix released] https://launchpad.net/bugs/225020
<siretart> I'm running the testsuite right now on my intrepid laptop
<vila> great
<siretart> vila: yes, I think I've seen "select/poll returned error" back then
<vila> siretart: the bug is fixed in 1.7 but not in 1.6.1. I think intrepid uses the later
<vila> lifeless: by the way, did pycurl get re-installed on pqm (you said you asked for it to be removed in the bug comments) >
<vila> s/>/?/
<lifeless> vila: arh, don't think so.
<vila> lifeless: no urgency,  that should be done carefully...
<siretart> vila: what is your email adress?
<vila> v.ladeuil+lp at free.fr
<lifeless> vila: is the bug fixed?
<vila> lifeless: yes, it didn't dare reproduce anywhere AFAIK
<vila> lifeless: but note that it's fixed in 1.7 and pqm uses 1.6.1 if I'm correct
<lifeless> vila: errr
<lifeless> vila: it was removed from the pqm chroot, not from the bzr pqm uses
<lifeless> vila: two totally separate thing
<vila> I understand that
<vila> My point was that running the tests should not fail anymore, but merging before running the tests may
<lifeless> vila: my point is that the bzr doing the merging *still has pycurl* AFAIK
<lifeless> vila: and never had trouble merging
<vila> lifeless: then all is fine and I will cure my paranoia happily :)
 * vila will try to better understand what run under the chroot and what doesn't another day :)
<lifeless> vila: 'make check' runs in teh chroot. Nothing else does
<vila> clear and simple, thanks
<lllama> Hello all. Anyone got a good method for running the smart server as a service on a central ubuntu box?
<pysquared> Does anyone know how to do garbage collection in a shared repository after deleting unwanted branches?
<lifeless> pysquared: currently there isn't a simple answer; unless your branches are large I would say don't worry
<pysquared> This post https://lists.ubuntu.com/archives/bazaar/2007q3/031099.html mentions a "garbage collection" plugin, but provides no link, and I cannot find one.
<lifeless> pysquared: I don't think there is
<pysquared> I thought it would be nice to have a bzr2xyz (and back again) in a similar vein to http://msi2xml.sourceforge.net, to allow open-heart-surgery on a repo - anyone else thought this?
<lifeless> pysquared: thats roughly what fast-import|fast-export is, though note that *any* modification makes your content appear like new branches to others (its a distributed DB)
<lifeless> pysquared: rebase and similar tools are much more user friendly ways to make it hard for people to merge :P
<pysquared> For a technically minded newbie to bzr, I would also appreciate a program which would give me a nice view of a shared repo, all branches using it, orphaned heads etc., and it could be extended to show possible actions like commit, branch etc.
<pysquared> lifeless: thanks. checking out fast-[import|export]
<a_c_m> branches rock !
<lifeless> pysquared: qbzr|bzr-gtk|tbzr(windows)
<pysquared> I'm on Ubuntu 8.04, so tbzr (TortoiseBZR?) is out.  Just tried qbzr, feels a bit clunky though, you have to wrestle with it to get information out.
<pysquared> I have been using bzr-gtk (olive-gtk yes?) for a while, and it's better than qbzr IMVHO so far.
<pysquared> Thanks for the fast-import link, looks like a useful example of using bzrlib to disect a repo.
<lifeless> generally speaking, I just use bzrlib to work with repo's :)
<lamont> can I safely remove things in .bzr/repository/obsolete_packs (as the name would tend to imply)??
<james_w> lamont: removing the directory is not a good idea, but the contents of the directory will be safe to delete if your system didn't die before things were synced to disk
<vila> siretart: got your mail, I can confirm that bug #225020 is *not* fixed in bzr-1.6 nor bzr-1.6.1 :-/
<ubottu> Launchpad bug 225020 in bzr "pycurl reports "select/poll returned error"" [High,Fix released] https://launchpad.net/bugs/225020
<vila> jam: when you'll come online, are you aware of bug #269770 ? 1.7 may still find its way into intrepid... (me? trying to push a time-based release trough a Freeze exception ? me ?)
<ubottu> Launchpad bug 269770 in bzr "bzr - New upstream versions released" [Undecided,In progress] https://launchpad.net/bugs/269770
<lamont> james_w: thansk
<pysquared> Would a good method of cleaning out orphan revisions, i.e. garbage collecting (after deleting branch directories) be this: create a new shared repo, and branch every branch from old to new?
<james_w> pysquared: yeah, that works
<james_w> pysquared: it's obviously just a bit of a pain to do manually
<Tak> vila meant: lifeless: by the way, did pycurl get re-installed on pqm (you said you asked for it to be removed in the bug comments) ?
<vila> Tak:  ?
<Tak> hell, sorry
<vila> :)
<Tak> script + scrollback = eek!
<jam> vila: I'll be packaging 1.7 "now-ish" I don't know whether that means it will get merged or not. Certainly I would hope they do 1.6.1
<vila> They mentioned 1.7, that's why I mentioned it to you, no pressure, at all, I swear :)
<james_w> https://bugs.edge.launchpad.net/ubuntu/+source/bzr/+bug/269770
<ubottu> Ubuntu bug 269770 in bzr "bzr - New upstream versions released" [Undecided,In progress]
<Leonidas> why do I need to --force for a multi-branch merge? is it considered a bad idea?
<james_w> Leonidas: well, the first merge will mean that there are files modified in the working tree, and merging in that state can be a headache, I don't know if there is more to it than that
<Leonidas> james_w: ok, so it is just a human issue, not some technical problem. Thanks.
<fdv> huh
<fdv> bzr-svn seems to have replaced an svn revision
<fdv> is this normal?
<fdv> never done it before, but I haven't done this with the latest and greatest bzr-svn before
<jelmer> fdv, see the FAQ
<fdv> oh
<fdv> that was.. unexpected
<fdv> jelmer: I had a bound branch, and the operation was a commit
<fdv> unsure how to interpret the faq on that point
<jelmer> fdv, This happened after "bzr up" created pending merges I suspect?
<fdv> jelmer: indeed'
<jam> guilhembi: ping, I'd like to chat with you sometime about the 'bzr log file' changes
<jam> just to get a feel of someone outside the bzr project itself
<guilhembi> jam: hi! good idea. We can IRC now.
<jam> Is this channel fairly quiet?
<jam> I haven't been watching
<guilhembi> it is
<jam> guilhembi: so here is my standard example for the 'bzr log file' situation: http://paste.ubuntu.com/49712/
<jam> You have 3 branches, the one on the left (ABEG) is the mainline
<jam> guilhembi: do you understand the graph, in general?
<Verterok|out> ~/away
<Verterok|out> sorry :p
<guilhembi> reading
<guilhembi> jam: yes; to be sure: the only changed of 'foo' is C, right?
<guilhembi> s/changed/changer
<jam> guilhembi: right, that is the only *direct* change to the file.
<guilhembi> ok
<jam> well, and "A" for introducing it
<jam> however, if you were to do "bzr diff" or E, or F, you would also see it "changing" C
<jam> because of the merge
<guilhembi> jam: right, makes sense; E changed 'foo' compared to ancestor B.
<guilhembi> due to merge.
<jam> and same for F
<jam> so, there are 3 possible results from "bzr log foo"
<jam> A C
<jam> A C E F
<jam> A C E
<jam> My 'file-log' plugin does the first
<jam> only reporting *direct* changes to the file
<guilhembi> jam: this is fine. But,
<jam> sorry, I'm having side conversations so this is taking a while.
<guilhembi> what if when the merge was done in E (pulling C into B), a conflict happened in 'foo',
<guilhembi> then I'd like "bzr log" to how A C E.
<jam> guilhembi: if a conflict happens then there is a new node
<jam> because B had to change the file
<jam> And E is then resolving the changes between B and C
<guilhembi> jam: so would I see A B C E?
<jam> *in fact*
<jam> If there are *no conflicts* you'll still see "ABCE" because E is merging the texts together to create a new text that has not been seen before.
<guilhembi> jam: this is fine too
<jam> guilhembi: the existing "bzr log file" code shows "ACEF"
<jam> my change would start to show "ACE"
<jam> (though I have a change which solves the bulk of the problem, and still gives ACEF)
<jam> So back to the original example...
<jam> the reason to show "E" is because it is nice to know when that change was "landed"
<jam> rather than just when it was created.
<jam> do you agree?
<guilhembi> yes and no
<guilhembi> it's nice, but it multiplies the output, creating some sort of noise;
<guilhembi> in MySQL, we merge all the time, so we'd rather see what revision introduced a change for the first time,
<guilhembi> and not the multiple merge revisions which propagated it all around,
<jam> guilhembi: so, the idea with the *new* code, is to only see the changes as it propagates to *your branch mainline*
<jam> so the changes as it propagates to *this* branch, rather than showing "F" which is propagating to some other branch.
<guilhembi> from MySQL 5.0-team to 5.0-main to 5.1-team to 5.1-main to 6.0-team to 6.0-main, that's a lot of noise merge revisions; I call them noise only if there were no conflicts.
<jam> guilhembi: knowing those branches, I have some guesses that you might see it anyway because of non-conflict resolutions...
<jam> guilhembi: sorry, network hiccup, did you respond to "knowing those branches ..." ?
<guilhembi> not yet
<guilhembi> jam: what is a "non-conflict resolution" ?
<jam> guilhembi: B & C both modified 'foo', just in a way that doesn't conflict
<jam> (B changes the first line, C changes the last)
<guilhembi> jam: ah, then it's fine to see B and C and E.
<guilhembi> jam: let's put it this way:
<guilhembi> I believe we should see all revisions which introduced a change in the first place,
<guilhembi> plus, if you wish, merges where the two ancestors changed 'foo'.
<guilhembi> It's "if you wish", because I don't see a need to see such merges if there were no conflicts.
<guilhembi> as then I consider they didn't really change something.
<jam> well, they did get a new text. Also, I don't think there is a way to figure out whether it was a conflicting or non-conflicting without explicitly recording that at commit time.
<jam> As it can even depend on the merge algorithm used
<jam> (as you've seen for bzr merge --weave/lca/merge3)
<jam> so, in the short-short term, I'll point you towards my "bzr file-log" plugin, which gives you the minimal revisions you requested, and I'll probably land the change to "bzr log file" which is a step along the way.
<guilhembi> jam: mmmmmm
<guilhembi> I'd rather not tell people to switch to your plugin, it is a bit hell to make 100+ devs use a plugin,
<jam> With newest code in both, "bzr file-log sql/..yacc.yy" was 4-5s, and "bzr log file" was about 10s
<guilhembi> then abandon it when the changes are in bzr.dev
<guilhembi> how about "land the change to "bzr log file" which is a step along the way"
<guilhembi> - which is easier to sell to my colleagues -
<guilhembi> do you see a problem with getting your change into bzr.dev?
<jam> just waiting on final approval, things seem positive
<guilhembi> jam: I believe that the person who reported that problem can accept waiting for a couple of weeks (but not a couple of months) and then just upgrade its bzr.
<guilhembi> jam: while I have you here, when finally will your lca_merge_multi reach bzr.dev ?
<jam> I don't know what is happening here....
<jam> bad network
<jam> 10:58:02) guilhembi: jam: while I have you here, when finally will your lca_merge_multi reach bzr.dev ?
<jam> (10:59:05) jam: a bit unclear
<jam> (10:59:10) jam: it took a month to get anyone to review it
<jam> (10:59:18) jam: and then they asked for some large changes
<guilhembi> jam: :((
<jam> so I need to find some time to both discuss with him what has to happen
<jam> and have time to make the changes.
<jam> (we're also in the process of discussing our review process, as it seems to not be functioning as smoothly as it should)
<guilhembi> jam: then that patch needs higher prio, "angry customer" thing.
<guilhembi> poolie: hello! please see above.
<jam> guilhembi: well, poolie is in deep-sleep right now, but he'll wake up in about 6 hours
<jam> anyway, I'm off to reboot and release 1.7 final, I'll be back in a second.
<Leonidas> what is the dirrefence between lock_read and lock_write?
<Leonidas> *difference
<jam> Leonidas: "lock_read" indicates that you are going to not be modifying the object you are locking, "lock_write" says the opposite
<Leonidas> jam: so other processes could access a lock_read locked tree also via lock_read, but that wouldn't be possible with a lock_write?
<jam> Leonidas: ATM, I'm pretty sure you just can't take two lock_write at the same time. lock_write doesn't block a lock_read
<jam> as our data model stays consistent for old data when adding new data.
<fdv> jelmer: I now tried setting append-revisions-only on the repository I bind to an svn repo (where I update from and commit to), but this doesn't seem to make any difference
<fdv> jelmer: is that expected?
<jelmer> fdv, append-revisions-only has to be set on the master branch (the svn repository), e.g. in ~/.bazaar/subversion.conf
<fdv> ah
<Leonidas> jam: ok. I'm asking because I need read access to a repo and locking&unlocking on every operation is quite slow
<fdv> jelmer: is it possible to set it in svn itself?
<fdv> so that no "clients" can do this
<jelmer> fdv, not atm, no
<fdv> we just had a very hectic couple of hours here, it'd be nice to be able to aviod that :p
<Leonidas> jam: anyway, this is cool; thanks.
<fdv> ok
<jelmer> fdv: feel free to file a wishlist item about it
<fdv> is this new behaviour or has it been like this for some time?
<jelmer> fdv, it's always done this
<fdv> ok, guess I've just been lucky in the past
<fdv> jelmer: will add it to the wishlist. thanks for your help
<Leonidas> jam: but, uhm, of what use is the lock_read?
<fdv> jelmer: btw, you said 'e.g. ~/.bazaar/subversion.conf', does this mean that there are other options? Can I set it 'globally' for a user (across repos), for instance?
<jelmer> fdv, the setting is append_revisions_only btw, not append-revisions-only - I'll update the FAQ
<fdv> jelmer: I tested and found out :)
<jelmer> fdv, I think you should be able to set it in ~/.bazaar/bazaar.conf
<fdv> ok, thanks, I'll test
<fdv> jelmer: you don't think this could be considered a bug? I mean, in centralised thinking I think it's a bit counter-intuitive that the checkout should act as "master"..
<jelmer> fdv: What should be considered a bug exactly?
<fdv> jelmer: that append-revisions-only isn't default (against svn)
<jelmer> the fact that the mainline can be altered rather than only be appended to ?
<fdv> yes
<jelmer> fdv: In that case, it would have to be the default against bzr itself too (for consistency)
<fdv> well, maybe
<Pieter> 2
<fdv> on the other hand, when you're working against svn you might be in a slightly different mindset
<fdv> jelmer: not least that this sort of "breaks" svn
<fdv> you get an inadvertent copy, which might very well not be what you want
<fdv> (or replace, that is)
<jelmer> fdv: true, but you may not want a changing mainline for native bzr master branches either
<fdv> quite possibly, I'm not sure how bazaar handles this
<jelmer> fdv: I'm not opposed to making append_revisions_only the default, but only across bzr, not just for a particular master branch format.
<fdv> I see, I don't think I'm sufficiently proficient to be strongly opinionated on the matter
<jelmer> fdv: I could add a info message that points at the FAQ, would that help?
<fdv> jelmer: in my case, indeed, but I can only speak for myself
<fdv> maybe bzr could implement a prompt in these cases, unless specifically turned off
<fdv> jelmer: fyi, bazaar.conf seemed to work as well
<jelmer> fdv, ah, cool
<Kinnison> jelmer: Are you responsible for ctrlproxy?
<jelmer> Kinnison, yes
<Kinnison> jelmer: why is 3.0.x such a regression? is it still WiP ?
 * Kinnison accidentally upgraded, spent an hour trying to make it work, gave up and force downgraded again
<jelmer> Kinnison, it works fine here - what do you consider a regression exactly?
<Kinnison> jelmer: I couldn't get it to start an SSL listener which would actually transact any data
<Kinnison> jelmer: Also, startlistener and then saveconfig => no listeners saved
<Kinnison> at that point, I gave up trying to make it work
<jelmer> the second one is a known issue
<Kinnison> jelmer: it's also a showstopper with no config documentation :-)
<jelmer> the first one I'm not sure - what version exactly?
<Kinnison> whatever is in hardy
<Kinnison> I think
<jelmer> ah, ok - that's a known issue as well then but that's resolved now
<Kinnison> mmm 3.0.5-1
<jelmer> I do plan to fix the documentation for the next release
<Kinnison> there was nothing in the NEWS which hinted at SSl fixing for incoming connections
<jelmer> I'll give you a ping when that's out.
<Kinnison> so I didn't try trunk
 * Kinnison shrugs, I've downgraded the package and put it on hold
<Kinnison> also, it asks you to run a script which doesn't exist
<Kinnison> ctrlproxy-upgrade
<Kinnison> (although that might be the packager's fault)
<jelmer> yeah, that's a package bug
<Verterok> hi
<Verterok> would make sense to implement __str__ in bzrlib.inventory.Inventory?, mainly to avoid this http://rafb.net/p/yY76bI24.html
<bpierre> hi
<LeoNerd> Guys.. I have an idea...
<LeoNerd> I would loveyoulongtime if you provided me a way to hook into bzr's local file reading, and mangle a string that contains a file's content before bzr looked at it
<LeoNerd> I'd then use it to squash  $cvs: .*$  into   $cvs$   meaning that bzr ignores changes to CVS's keyword expansions
<LeoNerd> Currently, I have a dual CVS/bzr working directory (don't ask :P) and every single time I "cvs ci" I have to "bzr ci" as well because CVS has rewritten them
<LeoNerd> I know it'd slow things down a bit, but hey.. bzr is about 5 times quicker on my workdir than CVS ever is anyway, so it has plenty of leeway ;)
<jam> Leonidas: sorry, lunch came inbetween
<jam> anyway, 1 caveat, "WT.lock_read()" does take out an OS shared lock on a file
<jam> and *will* block a lock_write on a working tree
<jam> (we are considering ways to avoid this)
<jam> and 2
<jam> it gives a lifetime for cache objects
<LeoNerd> How confusing... someone else with the same initial 4 letters as me :P
<jam> LeoNerd: there *is* a pre-commit hook
<jam> but that would require modifying the file-on-disk
<LeoNerd> Yah...
<jam> you could also monkey patch WT.get_file*
<LeoNerd> What I want is a filter between the filesystem read() calls, and what bzr internally uses
<jam> LeoNerd: well, igc was working on just that sort of thing recently
<jam> it got a little side tracked when he got sick
<jam> LeoNerd: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C4880CF60.2080805%40canonical.com%3E
<jam> Is part of his work on that
<jam> along with a plugin on his end
<jam> Leonidas: back to the "cache lifetime". The idea is that we'll have a snapshot of how a branch/repository looks and cache certain things in memory. By using lock_read()/unlock() we define the boundary of when that cache is valid.
<jam> Leonidas: so that if you have a long running process, it doesn't think a branch is always at the same point, nor does it have to re-query all information repeatedly.
<jam> for bzr, the cache lifetime is generally just the process lifetime
<a_c_m> is anyone actually using PQM ?
<a_c_m> finding it really hard to find any useful doc's or tutorials on how to set it up
<abentley> jam: You wanted to talk with me about LCA merge stuffs.  Do you still want to do that?
<a_c_m> Patch Queue Manager? is it abandoned?
<a_c_m> no activity in the last month
<a_c_m> no download (that i could see)
<james_w> a_c_m: bzr itself uses it
<james_w> and there is work being done on it
<seb_kuzminsky> halp!  i'm using bzr to work with an svn repo, and it's backtracing on me
<seb_kuzminsky> i'm on intrepid, fully apt-get updated, with bzr-svn from the 0.4 branch, also recently updated
<jelmer> seb_kuzminsky, please pastebin the traceback somewhere
<seb_kuzminsky> here's the backtrace: http://pastebin.ca/1209653
<seb_kuzminsky> ;-)
<jelmer> seb_kuzminsky, please file a bug
<seb_kuzminsky> will do
<a_c_m> james_w: right... but i would love to see if i can set it up for my purposes, seems like a really cool plugin/addon/thing even for trival stuff like checking committed code matches our coding standards... or would there be a better way to do that? perhaps with pre-commit hooks?
<james_w> a_c_m: either would work I think, it's about where you want to check it really.
<a_c_m> james_w: as i cant find any released code for the PQM, i guess pre-commit hooks is where its at ;)
<seb_kuzminsky> jelmer: thanks: https://bugs.launchpad.net/bzr-svn/+bug/273716
<ubottu> Ubuntu bug 273716 in bzr-svn "backtrace in a bzr branch of an svn repo" [Undecided,New]
<james_w> a_c_m: you can grab it from bzr
<jelmer> seb_kuzminsky, thanks
<seb_kuzminsky> any suggestions on how i can work around this for now?  i'd really like to keep working with that sandbox!
<seb_kuzminsky> jelmer: hm i think that bug is probably my fault
<strk> how do I drop a working tree from a branch once I forgot the --no-tree ?
<LarstiQ> strk: `bzr remove-tree`
<strk> thx
<seb_kuzminsky> jelmer: it's my fault, sorry for wasting your time
<jelmer> seb_kuzminsky, what's the problem exactly?
<seb_kuzminsky> i'd been playing with a newer version of bzr (from lp:bzr)
<seb_kuzminsky> i made a shared repo of format RepositoryFormatKnitPack5RichRoot (bzr 1.6.1)
<seb_kuzminsky> but intrepid only has 1.6, i think that's what made it confused
<seb_kuzminsky> i upgraded to lp:bzr-1.6 and now it's working
<seb_kuzminsky> sry!
<a_c_m> james_w: do you know of any good tutorials for doing hook based things?
<beuno> statik, hi. Are you around?
<beuno> a few of us have been using the bzr nightly PPA
<beuno> and have a very very very very special request  :)
<beuno> (add bzrtools to it as well)
<BasicOSX> how do I remove just the file ID? I have a fileName and filename and on osx native fs those are the same file
<james_w> a_c_m: the documentation is a start, I don't know of any tutorials
<lifeless> a_c_m: looking at an existing plugin - e.g. email - that uses hooks is a good way to see what they do
<lifeless> BasicOSX: uhm
<BasicOSX> I've had this "problem" before on osx, bzr remove "File" worksi
<lifeless> BasicOSX: python -c "import bzrlib.workingtree; t = bzrlib.workingtree.WorkingTree.open('path'); t.remove('exact_relpath')"
* jam changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | bzr-1.7 now available! |  http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
#bzr 2008-09-24
<poolie> hello
<lifeless> poolie: I need more details on vila's stuff to find it
<poolie> "how various commands display revisions"
<poolie> and there's one about python2.6, which does have a patch that i'm about to read
<poolie> you don't need to spend a lot of time on it, i think he'd just like to know people read them
<lifeless> I read the former
<lifeless> I'll pass on the latter for now
<lifeless> spiv: btw aren't context manages 2.5?
<spiv> lifeless: yeah, they are.
<spiv> lifeless: but we're still supporting 2.4, so that doesn't help us much.
<lifeless> spiv: yah, not to mention, like I said, I don't think they help anyhow
<lifeless> spiv: because, aren't they effectively just syntactic sugar for try:finally:except:?
<spiv> Roughly, yes.
<beuno> mwhudson, do you have a bit of time today to review Verterok's branch for traceback logging?
<lifeless> so the squashing will still happen
<spiv> But that is helpful, in this case.
<lifeless> spiv: how so?
<spiv> Because unlike try/except/finally, I'm fairly sure you can put the logic to preserve the original exception (if any) inside the context manager.
<mwhudson> Verterok: yeah, should think so
<spiv> So the obvious spelling of "with write_locked(foo): ..." can then DTRT, where "foo.lock(); try: ... finally: foo.unlock()" doesn't.
<lifeless> __exit__(  	exc_type, exc_val, exc_tb)
<lifeless> is the key spelling
<lifeless> spiv: but you can spell write_locked as try:finally:except e:try:self.unlock() except:pass; raise e
<spiv> It is possible to preserve the original exception (and traceback) with try/except; our needs_write_lock decorator does that now.
<beuno> mwhudson, thanks. It's a big patch, and mostly touches code you've worked on
<spiv> But it's awkward to reuse that in a typical try/finally, which means that it's going to be easy to miss places that don't do it properly.
<lifeless> apply_locked ?
<lifeless> erm
<lifeless> apply_write_locked, suggesting a name
<spiv> Yeah.  I was also thinking that *maybe* it would be possible to re-write just the finally block as "preserve_original_exception(foo.unlock)"
<spiv> (not a great name, obviously)
<lifeless> the sys.tb* are not threadsafe though
<spiv> sys.exc_info() is.
<lifeless> oh cool
<spiv> The tricky bit is that I need to look up if there can be times where sys.exc_info() can be set when there isn't an active exception (and I suspect there are).
<spiv> Possibly those are just corner cases about invoking things from except: blocks.  But I'd prefer a solution that obviously correct :)
<lifeless> abentley: ping
<abentley> lifeless: pong
<lifeless> abentley: the intertree previewtree test, I'm not quite sure what its testing
<lifeless> abentley: I just had a conflict on that change, so I thought I'd expand on the comment.
<lifeless> abentley: is there a different InterTree that it tests? Or are you just adding-some-coverage-to-PreviewTree ?
<abentley> I'm just adding-some-coverage-to-PreviewTree
<lifeless> ok.
<lifeless>     # PreviewTree doesn't get the stock interface tests for working tree,
<lifeless>     # having it exercised by the standard intertree tests provides useful test
<lifeless>     # coverage.
<lifeless> thats my expanded comment, seem ok ?
<Verterok> beuno, mwhudson: thanks!
<lifeless> [I've also made it clear that the InterTree tests are running with PreviewTree, so failures are clearer
<lifeless> ]
<beuno> Verterok thanks for working on it  :)
<abentley> lifeless: I don't understand why you're referring to working tree.
<lifeless> s/working tree/trees/
<abentley> lifeless: Okay, so now I don't understand the comment, because PreviewTree is exercised by the tree_implementation tests
<lifeless> abentley: I'm trying to write down _why_ we get more coverage by having PreviewTree present in the InterTree tests.
<lifeless> obviously we *do*, and thats fine.
<abentley> I would say "PreviewTree does get the stock interface tests for tree..."
<lifeless> but the System-Under-Test is the InterTree class and its subclasses, not any specific tree implementation; its very weird from that perspective to have PreviewTree here
<abentley> So the point is that PreviewTree doesn't have an InterTree, perhaps?
<lifeless>     # The stock interface tests for 'tree' are insufficient to thoroughly cover
<lifeless>     # PreviewTree. Exercising it by the InterTree tests provides useful
<lifeless>     # additional coverage.
<lifeless> abentley: from a theory perspective, any failures you uncovered are failures in the tree interface tests
<lifeless> [in that they fail to cover something that anything claiming to be a Tree should provide]
<lifeless> poolie: you sunk my battleship
<abentley> lifeless: So do you think that iter_changes et al should be tested in tree_implementations?
<lifeless> poolie: (conflict in NEWS after the lock patch landed)
<lifeless> abentley: uhm, that question suggests I need to read a little deeper. Tree.iter_changes is meant to be just a thunk down to InterTree; if its not its going to be asymmetric across types.
<lifeless> abentley: I'll be a minute, just fixing this conflict for pqm
<abentley> lifeless: For PreviewTree, it's not, but that's not relevant.
<poolie> lifeless: someone should write a script to avoid NEWS conflicts :-P
<abentley> I need to make sure that PreviewTree.iter_changes works.  How should we be testing that?
<lifeless> abentley: ok, now I see whats going on
<lifeless> abentley: InterTree is the right place to test iter_changes; I think PreviewTree should not have an iter_changes method though
<lifeless> abentley: because wt.iter_changes(preview_tree) should be the reverse of preview_tree.iter_changes(wt)
<lifeless> anyhow, the comment I propose now is:
<lifeless>     # PreviewTree does not have an InterTree optimiser class.
<abentley> lifeless: In these tests, it's using InterTree.iter_changes.
<abentley> It still needs to be tested.
<abentley> If we just use the existing tests, it won't be.
<lifeless> I'm getting more confused by the minute
<abentley> There needs to be a scenario for every tree type.
<lifeless> InterTree does not have a scenario for every tree type and shouldn't have one
<abentley> Correct.
<lifeless> it should have a scenario for every code path from InterTree
<abentley> But we do need to test every tree type in "tree_implementations".
<poolie> lifeless: +1 to taking files from a special directory and merging them into NEWS
<abentley> Sorry
<abentley> in "intertree_implementations".
<poolie> i don't see why special handling would be needed for deletions
<mwhudson> how do i make a repository a no-trees repository again?
<lifeless> poolie: in a single-file approach
<lifeless> mwhudson: touch no-working-trees in .bzr/repository
<mwhudson> lifeless: thanks
<poolie> lifeless: i mean if someone changes the news entry after it's merged into NEWS
<poolie> that is a real conflict
<poolie> we'd want them to instead update the bit merged in to NEWS
<abentley> Otherwise, we don't know that those operations work.
<lifeless> abentley: the point of interfaces is to avoid polynomial growth; test that object A implements interface I correctly, then test that object B uses interface I correctly
<lifeless> abentley: InterTree tests are tests of object B on the interface 'Tree'
<lifeless> abentley: any failure on an arbitrary (Tree,Tree) pair passed into InterTree.get(Tree, Tree).iter_changes() is either a failure in the Tree interface tests (if the object doesn't support something), or a failure in the InterTree tests (if the code path in InterTree is faulty)
<abentley> lifeless:  I think that isn't true when optimizers are invoked.  I suspect that the InterTree optimizer for WorkingTree4 has requirements that Tree doesn't meet.
<lifeless> abentley: the optimiser for WT4 only kicks in (and this is tested) when the other tree is a DirStateRevisionTree
<abentley> lifeless: So it is not a test on the interface 'Tree'.
<lifeless> abentley: what 'it' there?
<abentley> A test of iter_changes involving a wt4 and a DirstateRevisionTree.
<lifeless> right, its a test of InterTree (specifically InterDirstateTree)
<abentley> But you said "InterTree tests are tests of object B on the interface 'Tree'"
<lifeless> object B is is the SUT, which is InterDirstateTree
<lifeless> the interface 'Tree' is a layer the test depends on
<abentley> lifeless: expand SUT please?
<lifeless> system under test
<lifeless> the code being tested
<lifeless> as opposed to things the test needs but assumes are in good working order
<abentley> lifeless: So you are saying that InterTree and not InterDirstateTree tests are tests on the interface "Tree"?
<lifeless> I'm saying they are both tests that build on the interface "Tree" but *do not test the interace "Tree"*
<lifeless> they make no assertions about the behaviour of e.g. get_file_sha1
<lifeless> abentley: we almost certainly have missing test coverage of the Tree interface
<abentley> lifeless: Well, less since I merged my previous two patches.
<lifeless> abentley: so doing what you've done is a good thing, I'm just trying to make sure its commented correctly; and ideally get some bugs filed about the things you found out so that we can fix the other faulty/missing tessts
<lifeless> abentley: skipping the theory, here is the pragmatic thing I'm trying to get at: a broken method on PreviewTree found by running InterTree tests implies a missing/faulty test in tree_implementations/*.py
<abentley> lifeless: Since PreviewTree's iter_changes was broken, this suggests that iter_changes should be tested in tree_implementations.
<lifeless> abentley: the transform.iter_changes was broken, or InterTree.iter_changes broke on PreviewTrees?
<abentley> InterTree.iter_changes broke on PreviewTrees
<lifeless> abentley: that says that tree_implementations is missing tests, but not of iter_changes
<lifeless> abentley: rather of the parts of the Tree interface that are not fully tested.
<abentley> I don't think there's anything that mandates that iter_changes be implemented in terms of InterTree.  I think it's an implementation detail.
<lifeless> abentley: you found get_file_sha1 was missing, IIRC?
<abentley> lifeless: Yes, and _comparison_data, _file_size.
<lifeless> abentley: to me that says there are missing tests for get_file_sha1, _comparison_data, _file_size on Tree
<abentley> lifeless: We don't disagree about that.
<lifeless> ok
<lifeless> phew, I thought we were stuck.
<abentley> But I also think that iter_trees should be tested on every class that claims to provide it.
<abentley> Because testing that PreviewTree provides X and InterTree works with X doesn't work if iter_changes doesn't use InterTree.
<lifeless> abentley: I don't think anyone should override iter_changes, and so we shouldn't need to test it on each tree.
<lifeless> iter_changes needs two trees to test; doing interface tests for that needs two degrees of parameterisation; its tricky at best.
<lifeless> I think what you've done is ok, though I'm struggling to reconstruct the change you made vis-a-vis _test_mutable_trees_to_test_trees
<abentley> I wasn't suggesting it we needed to do n^2 complexity.
<lifeless> (its broken by iter_changes branch)
<lifeless> s/by/my/
<abentley> But to not test at all seems questionable.
<lifeless> abentley: I'm not suggesting that we don't test!
<abentley> lifeless: You are essentially saying we should test InterTree.iter_changes, not Tree.iter_changes.
<lifeless> abentley: I'm saying that there should be only one implementation of Tree.iter_changes - its meant to be just syntactic sugar
<lifeless> abentley: because the multimethod support InterObject gives us lets us test it effectively; it certainly looks like you found it easy enough to slot it in.
<abentley> lifeless: So yeah, that's what we disagree on.  Mandating that Tree.iter_changes be implemented via InterTree and therefore not testing Tree.iter_changes.
<lifeless> I guess so
<abentley> lifeless: Anyhow, I just changed _test_mutable_trees_to_test_trees to take TestCase as a parameter.
<abentley> That allows me to call addCleanup to clean up the PreviewTree's TreeTransform.
<lifeless> yup, thanks
<lifeless> I had a change there to add C and python versions of the dirstate iter_changes code
<abentley> lifeless: So one of the breakages was that PreviewTree doesn't provide .inventory, and iter_changes attempted to use it.
<lifeless> now I need to figure out why readdir acceleration fails on PQM
<poolie> jam, still around/
<Verterok> Hi, any thoughts about implementing __str__ in bzrlib.inventory.Inventory?...to avoid this http://rafb.net/p/yY76bI24.html
<lifeless> Verterok: well thats for debugging really :P
<Verterok> hehe
<jam> spiv: there was a specific discussion in the Pyrex mailing list, about Pyrex leaving something in sys.exc_info() when there wasn't an active exception.
<Verterok> lifeless: it's using __repr__
<jam> poolie: I'm aronud a bit, but I'll probably be in and out
<lifeless> Verterok: I'd definitely want that output given that error to analyse things; user input shouldn't be able to trigger any normal exception like that
<lifeless> jam: can you put that python 2.4 IFDEF in the pyrex bug I opened ?
<lifeless> jam: PQM itself needs that
<poolie> jam, so, for the lca shape merge, i'd like to merge it as-is to 1.7 in preparation for a 1.7.1
<poolie> what say you?
<lifeless> poolie: is it really worth a 1.7.1 for it ? It doesn't seem to meet our general policy there [its not a regression]
<jam> lifeless: well, we don't have a real policy for "large project publicly using bzr having problems doing common operations needs an officially released update to function properly"
<jam> not sure if that makes a 1.7.1 valid or not
<jam> just saying that it is outside of general policy we have crafted so far
<lifeless> mmm
<jam> for *their* trees, 'bzr merge' likes to leave broken paths around, because they have lots of things that get merged into multiple "release" branches, and then the release branches get merged (causes criss-cross)
<lifeless> 1.7.1 will affect everyone by causing a new upgrade, more QA for distro folk etc
<jam> poolie: My concern is that 1.7.1 will come out with it, and then 1.8 won't have it, which will be weird.
<jam> lifeless: I'm not particularly concerned with the code causing regressions. I've done a lot of testing, including setting it as the default algorithm and running the full test suite.
<jam> ATM the issues are "clarity of design" etc
<jam> which is more a "can we maintain this?" rather than "is it broken?"
<Verterok> lifeless: what's your recommendation? I made trivial fix, added __str__ to Inventory, and now only shows: http://paste.ubuntu.com/49910/
<jam> lifeless: I don't see a "pyrex bug that you just opened" can you link it for me?
<poolie> jam, so i do see the "clarity of design" thing as a case of the general thing about the way we do reviews
<lifeless> Verterok: I think the bug is that it's showing the inventory and not a tree objct
<lifeless> Verterok: totally unrelated to __str__ or __repr__
<poolie> if we merge it to bzr.1.7 we should immediately merge that back to trunk
<Verterok> lifeless: ok, thanks for the tip :) I'll back after digging a bit more
<lifeless> jam: https://bugs.edge.launchpad.net/bzr/+bug/271939/comments/2
<ubottu> Ubuntu bug 271939 in bzr "extensions fail to build on python 2.4" [Medium,Triaged]
<jam> lifeless: of course, lp has a bug that linking to a comment on a bug doesn't have an obvious link back to the bug itself ... :)
<lifeless> hey, I just work here
<lifeless> jam: re using 'pathjoin' rather than 'osutils.pathjoin'
<jam> lifeless: what about: https://bugs.edge.launchpad.net/bzr/+bug/271939/comments/3
<ubottu> Ubuntu bug 271939 in bzr "extensions fail to build on python 2.4" [Medium,Triaged]
<lifeless> jam: you can't use default values in cdef functions
<lifeless> jam: thanks
<jam> so you can't do "cdef myfunction(foo, bar=XXX)" ?
<lifeless> right
<lifeless> so I can cache it in some of the places its used, and I've just done that
<lifeless> but I really don't want a double-lookup in _update_entry
<poolie> jam, lifeless, any other concerns about doing this?
<lifeless> poolie: I think it doesn't match our stated motivations for point releases. So we shouldn't do it, or we should rewrite those motivations.
<jam> lifeless: I don't have a problem with it being at module scope, I just find "from bzrlib import osutils\nfrom bzrlib.osutils import X, Y" to be a bit odd.
<lifeless> jam: we do it a lot; doing an import and assignment would be more weird IMNSHO, but I can do that if you want
<fullermd> Whoah.  Did I miss the announcement of meta week on the list?
<poolie> lifeless: ok, we'll add "or as needed"  :-)  specifically, this is a serious bug for numerous users
<lifeless> poolie: its not a regression
<lifeless> poolie: thats the real thing that annoys me about it
<jam> lifeless: strictly speaking neither was 1.6.1
<jam> branch --stacked wasn't *in* 1.5
<lifeless> jam: 1.6 was a brown paper bag
<jam> so we couldn't regress anything
<lifeless> jam: it had a format that could create data loss; that is a regression
<poolie> is this defined in hacking or is it just general principle?
<lifeless> poolie: memory from our interminable discussions years ago
<poolie> i don't remember us saying it was only regressions and not bugs
<lifeless> poolie: dunno if its enshrined or not
<jam> lifeless: i don't actually know any way that data loss could have actually happened in it. but if you say so
<poolie> _anyhow_, they want it sooner than 1.8 and i want to help them
<poolie> i think this is a reasonable use of a point release
<jam> poolie: we could always make it "1.7-mysql" :)
<poolie> jam, 1.7-we-love-you-and-brought-you-flowers
<lifeless> I can't wait for 2.5.34, when we have more large users
<poolie> me either, that will be great
<poolie> well
<poolie> to be a bit more serious, we have some other options
<poolie> 1- just wait for 1.8
<poolie> 2- start releasing 1.8 now, from trunk
<poolie> 3- do a 1.7-mysql that's not a regular release
<poolie> 2s/$/, with this merged in first/
<poolie> let's decide what's right in this case and we can use that to tune the documented policy if necessary
<lifeless> My understanding, from the original agreement with them was that we would do (1)
<lifeless> we'd get them a fix, and then work to get it into the normal release
<poolie> the original plan was it would be in _1.7_ since the patch was ready before then
<poolie> after it looked likely it would slip i told them we would do a 1.7.1
<poolie> or at least that it would be soon after 1.7
<poolie> not a month later
<poolie> so, 1 would both be disappointing for them and breaking our commitment
<lifeless> I don't think its breaking our commitment if it took more than one release to polish the workaround to inclusion
<lifeless> I can understand the disappointment
<poolie> are there any issues other than the policy one?
<lifeless> releases have a cost; I don't see why paying that cost is better than spending the same effort on getting the thing merged to trunk
<poolie> it's a good poitn
<poolie> but for them it won't really be done until it's in a release
<poolie> as they can't ask everyone to run from trunk
<lifeless> so if you want to talk about getting it done, why didn't we just do what Aaron requested during the 1.7 cycle, then it could be landed already?
<lifeless> jam: re putting the python stuff in _dirstate_helpers_py.py, I'm a bit ambivalent; I guess feeling lazy more than anything
<jam> lifeless: well, if we are getting to that point, why didn't we review it a month earlier when it was posted ?
<jam> there are a lot of "woulda-coulda-shoulda"s we can get to
<jam> but how do we get where we want to be now?
<jam> lifeless: I think it is a bit easier to find the comparison code if it follows the same layout
<jam> is it more than a cut & paste for you to do so?
<lifeless> jam: adjust imports, possibly circular ones
<lifeless> other than that, no, just c&Pp
<jam> lifeless: ATM, I can respect your feeling, I think it is cleaner to put it in _py.py, but it doesn't change the correctness of your patch :)
<lifeless> jam: moving it over
<lifeless> I ended up with it in dirstate.py because _update_entry started there.
 * spiv -> lunch
<lifeless> jam: circular imports up the wazoow
<Verterok> lifeless: when you have a few minutes to spare in the inventory.__repr__ bug, I have a question (or two)
<lifeless> Verterok: sure
<lifeless> Verterok: I think its a annotate bug :P
<Verterok> lifeless: indeed :)
<Verterok> lifeless: acctually Inventory contributes a bit
<Verterok> lifeless: Inventory.__getitem__ raises errors.NoSuchId, with the inventory instance instead of a tree
<Verterok> maybe annotate could catch that and raise the right error?
<Verterok> or there is an API to access the inventory that annotate isn't using?
 * Verterok hides
<lifeless> Verterok: I need food rather badly; could you pastebin the backtrace perhaps? or file a bug about the bad UI result?
<lifeless> I'll look whwen I get back
<Verterok> lifeless: np, I'll keep playing a bit, and file a bug about it
<lifeless> Verterok: ah caffeine and food
<Verterok> lifeless: what we would do without them!
<fullermd> Starve in our sleep.
<Verterok> jaja
<lifeless> ITYM java :P
<Verterok> :p
<Verterok> lifeless: done, filed Bug #273835
<ubottu> Launchpad bug 273835 in bzr "annotate of a not present file_id give a huge error message" [Undecided,New] https://launchpad.net/bugs/273835
<lifeless> Verterok: thanks
<Verterok> ups...I think it's a duplicate :p (Bug #246573)
<ubottu> Launchpad bug 246573 in bzr "'bzr annotate file.OTHER' during contents conflict gives traceback" [Medium,Confirmed] https://launchpad.net/bugs/246573
 * AfC wonders if the Bazaar hackers have landed the compression work they've been talking about over the last few months.
<beuno> AfC, I think the b-tree stuff is in 1.7 as experimental
<lifeless> beuno: groupcompress is what afc means
<lifeless> AfC: no, its not landed yet
<beuno> lifeless, oh, I thought that was part of the btree?
<lifeless> beuno: no
<beuno> lifeless, so that would be another format?
<lifeless> groupcompress is a replacement for the 'knit' stuff
<lifeless> btree isn't in a format in bzr.dev yet
<beuno> but both of them will trigger a format change, right?
<lifeless> either of
<lifeless> (yes, you need a new format to use either set of code)
<vila> hi all, yeah for 1.7 !
<lifeless> vila: I'm still not sure what stuff you wanted in my inventory docs
<lifeless> vila: AFAICT I wrote some prose; you were confused by it; I rephrased the exact same text and it made you happy.
<vila> lifeless: your answers made me happy, I'm not sure they found their way in the text, but I think I BB:approved anyway
<lifeless> vila: it was approved with the edit, but I'm feeling lost as to how to do the edit without repeating myself lots
<vila> I can review it again if you want but I'm not sure about where to find the latests version
<vila> s/ts/t/
<vila> I needed to read it again anyway
<poolie> hi vila!
<vila> hey poolie :)
<lifeless> vila: on-list/bb
<vila> lifeless: ok, I've got it back (I've lost all my read/unread markers last week and had to triage ~10.000 mails again :-/)
<fullermd> Gyuh.
<fullermd> What a horrible thought.
<vila> Just thinking about it is far less painful though :D
<poolie> vila: um
<poolie> anyhow, i'm reading your 2.6 patch
<fullermd> Y'know, that sorta thing wouldn't happen if you used vi...
 * fullermd hides.
<vila> fullermd: I'm not sure there is mail agent suiting my needs for vi, but anyway, storing ~25.000 files in a single directory is more likely the root cause, especially when mounted over NFS
<vila> sometimes you just have to pay for your sins :D
<lifeless> vila: "NotFileSystem"
<vila> lifeless: until it's broken, don't fix it :D It's likely a combination NFS/shutting down a virtual machine including a running mail client inside an editor, something I don't even want to start debugging, not even starting to think about it :)
<lifeless> spiv: let me know if you want to chat re Inter*Remote*
<lifeless> vila: how do you feel about me just landing the current prose?
<vila> lifeless: just give me a few more minutes and I send you a patch where I inserted in your document the relevant comments
<lifeless> vila: oh thanks
<spiv> lifeless: If there's no InterOtherToRemote/InterRemoteToOther, which InterRepo would you want used?  Whichever of InterSameData/InterModel1and2/InterDifferingSerializer fits best?
<lifeless> spiv: 'yes'
<lifeless> spiv: as in, the RemoteRepo already exposes the needed data to choose one of those and use it
 * spiv nods
<lifeless> spiv: my reasoning in a nutshell is - the generic API should be fine for performance
<spiv> At the moment, the generic InterRepo's would force an _ensure_real just by the is_compatible checks.
<vila> lifeless: sent
<lifeless> spiv: if its not then many other things like 'annotate', 'cat', 'fast-export' that operate directly on RemoteRepo etc will be slow too
<igc> lifeless: wrt the inventory prose patch, please check 'make docs' works before submitting it
<lifeless> spiv: realy? those attributes are statically allocated by find_repositoryV2 I thought
<igc> it didn't for me
<spiv> They check repository._serializer
<spiv> Which is a property that does _ensure_real atm :(
<vila> igc, lifeless: I didn't check and my patch may contain even more errors :-/
<lifeless> spiv: oh, thats reasonable. Its needed to ensure the inventory and revision style is understood
<lifeless> spiv: so fix that :P
<spiv> That's something to fix in a find_repositoryV3...
<lifeless> spiv: yah, I'm not trying to add work you understand, rather reduce overall work
<spiv> I do understand that :)
<igc> hi vila!
<vila> hi Ian !
<lifeless> vila: so there is duplication straight up
<vila> lifeless: ? my patch try to add things you already added ?
<vila> if that's the case, I may have started with the wrong base, if you think what my patch try to add is already there, forget it and merge your version
<lifeless> vila: btw its easier to merge patches if they are attachments
<vila> lifeless: I was about to ask that precise question :)
 * vila solves that kind of problem by having a mail agent integrated into an editor :D
 * vila should nevertheless think more about vi's users :)
<lifeless> vila: well, everything you quoted was already duplication
<igc> vila: I'll take a look at 'how various cmds display revisions' tonight fwiw
<lifeless> vila: I don't have any specific ideas on how to parameterise log_adapters; if I did I would have written them down.
<vila> igc: thanks
<lifeless> vila: I just think it needs doing; look at bzr-search if you want an example of a plugin patching into the log adapter stack
<vila> lifeless: ok
<vila> lifeless: ha, excellent
<igc> spiv, poolie: well done on http://bazaar-vcs.org/SmartPushAnalysis1.8 - will be nice as we nail each of the issues found!
<poolie> hm
<poolie> it still needs more structure as a document but thanks
<vila> I started with revno: 3641
<vila> revision-id: robertc@robertcollins.net-20080827004239-7d2b1m4bsd2u8ufm
<vila> but anyway, BB:approve, land, land ! :)
<lifeless> vila: This is the patch I have uncommitted. ...
<lifeless> http://paste.ubuntu.com/49971/
<lifeless> 10 past 5 makes an unhappy boy
<lifeless> vila: (bzr log -m "\bVincent\b") will use a bzr search index, if you have one
<lifeless> igc: looks like a rest bug to me :(
<lifeless> igc: its valid reset list AFAICT, but it fails-to-format
<a_c_m> with bzr using file permissions can you restrict commit access to a folder in a branch e.g. only about the dba to commit to /sql ? would that work?
<bob2> no
<a_c_m> is there a way to achieve that?
<bob2> you could use a commit hook, I think
<a_c_m> why would the file permissions thing not work?
<lifeless> a_c_m: because bzr does not version anything other than the 'x' bit
<lifeless> a_c_m:  you could use a seperate baranch for /sql
<bob2> a_c_m: all the data in the branch is stored in .bzr in the root of the branch
<lifeless> a_c_m: or you could just enforce policy on merge; bzr is aimed at distributed setups
<a_c_m> lifeless: humm ok, the commit hooks method is interesting, but i'm no python programer
<lifeless> a_c_m: so, you could get someone to write it for you, its no harder than shell (actually easier than shell :P)
<lifeless> a_c_m: because we support many databases, polcy can't be enforced by normal access control
<lifeless> a_c_m: instead you have to do it 'when the content arrives'
<a_c_m> lifeless: makes sense really :)
<vigneswari> hello all
<vigneswari> plz help in resolving my problem reg.bzr-trac
<vigneswari> if i create any brach or repo using bzr init or init-repo..i couldnt view in trac browser
<vigneswari> am i asking in correct channel?
<vigneswari> plz help in resolving my problem reg.bzr-trac
<vigneswari> if i create any brach or repo using bzr init or init-repo..i couldnt view in trac browser
<vigneswari> should i provide some more details?
<bob2> maybe try the list
<frk2> hi guys!
<frk2> have successfully switched my project over to bzr from svn but have some issues with versioning while merging
<jakobb> vigneswari: I just checked the website of trac: it says: 'it provides an interface to subversion' Are you even sure it should work with bzr?
<jakobb> aah got it.... there is a plugin
<frk2> my problem is, mostly, that after merging and pushing - version numbers on the target repository get overwritten
<bob2> yes
<frk2> is that intentional?
<frk2> is thats how bzr is supposed to work? or am i doing something wrong
<bob2> you can set the append_mumble option
<frk2> bob2, append_mumble?
<bob2> append_revisions_only
<frk2> in bazaar.conf?
<bob2> in the branch.conf for the trunk
<lifeless> frk2: merge + commit doesn't reset revisions
<lifeless> frk2: 'pull' can and so can 'push'
<frk2> right
<frk2> thats whats happening
<frk2> we have a central trunk
<frk2> where multiple developers PULL from, and then PUSH
<lifeless> frk2: this is covered in the users guide I believe
<frk2> if the branches diverge, one of us has to MERGE and PUSH, upsetting revision numbers
<lifeless> frk2: recommended way to manage your trunk is to use checkouts for the trunk itself
<lifeless> frk2: then you don't push into it, you commit your merge
<lifeless> revision numbers won't change if you do this
<frk2> hmm
<frk2> I understand... but the whole point of me using bzr was that we have developers who have no write access to trunk
<frk2> so, we merge their changes and then push to trunk
<lifeless> frk2: so those developers can't push anyhow
<lifeless> frk2: exactly
<frk2> ah okay
<frk2> i see :)
<jakobb> vigneswari: I guess you should try to get one of the developers of the bzr-plugin for trac to answer your question; I don't think the 'general' audience here has much experience with it
<vigneswari> jakobb, any separate channel for plugins
<jakobb> not that I'm aware of
<jakobb> I do see that jelmer is among the developers... he's in here as well
<vigneswari> jelmer, do u have any idea abt my issue?
<vigneswari> in bzr-trac integration
<jelmer> vigneswari, you mean trac-bzr ?
<jelmer> (there are two different projects these days)
<vigneswari> jelmer, yes
<vigneswari> jelmer, am not able to see the content of branch as well repo
<vigneswari> jelmer, anything created using bzr init command
<jelmer> vigneswari: Did you edit the trac configuration file to include bzr?
<vigneswari> tracbzr.* = enabled jelmer
<vigneswari> jelmer, this line i ve added in trac.ini file
<vigneswari> nothing else :)
<jelmer> nothing about trac not being able to find the plugin, etc, in the logs?
<vigneswari> jelmer, http://pastebin.com/m14c672cb
<vigneswari> jelmer, i cant locate the logs
<jelmer> vigneswari, please file a bug
<vigneswari> jelmer, where?
<jelmer> launchpad.net/trac-bzr
<vigneswari> jelmer, ok
<vigneswari> thnks
<xtrqt> I have branch without main repo ~/a, and in it I have ~/a/b which is standalone branch of project-part, I want to have only ~/a branch and not to lose revs in b.
<xtrqt> how could I import b as subdirectory of a, without deleting /a/b/.bzr
<luks> you can try https://launchpad.net/bzr-merge-into
<xtrqt> thanks
<Stev> Hi
<Stev> I'm pushing my revisions to a ftp server (from a free hosting service), is there some web interface to browse through the sources/revisions? The ones i've found are not suitable for me as I cannot run anything execpt cgi/php/perl scripts on the host.
<Kinnison> Register it on launchpad and use that to view the source?
<Kinnison> E.g. http://bazaar.launchpad.net/~dsilvers/flail/devel/files
<Stev> Uhm nice :)
<Stev> OK, another question then... is there a way to push more to than one locations at once?
<luks> I dont think so
<Stev> I mean.. "bzr push" and it pushes "ftp://server1.foo.com" and "sftp://aaa@bbb.com"
<Stev> ok, thanks, i think i'll just create a small script/alias to avoid typing the 2nd whole url :) Thanks guys
<luks> well, you can use bzr-bookmarks to not having to type the whole url
<Stev> Had a look at bzr-bookmarks, thanks
<nevans> hmm... bzr-bookmarks... that looks useful.
<rocky> jelmer: which version (if any) of bzr-svn should we use with bzr-1.7 ?
<jelmer> rocky, the 0.4 branch at the moment
<rocky> kk
<Tak> jelmer: I think I'm supposed to ping you about monodevelop-bzr?
<jelmer> Tak, Hi
<jelmer> Tak, What about specifically?
<Tak> hi - I've been working on it in a branch
<Tak> speaking with palango, he said I should request to be added to the monodevelop-bzr team
<Tak> (which I have, on launchpad)
<jelmer> ah, ok
<jelmer> one sec, let me check if I've received any email yet
<strk> bzr: ERROR: no such option: --no-tree
<strk> bzr branch --no-tree <src> <tgt>
<LarstiQ> strk: supplied to what command?
<strk> Bazaar (bzr) 1.6.1
<jelmer> Tak, I've approved you
<Tak> cool
<LarstiQ> strk: branch doesn't take a --no-tree argument
<LarstiQ> strk: did you mean init-repo --no-trees?
<strk> I never know what I'm doing when it comes to bzr really
<LarstiQ> strk: hmm :)
<LarstiQ> strk: what are you trying to do in this specific case?
<strk> setup my working envorinment :)
<strk> so far I've been using two branches
<strk> one bound to the main shared one online
<strk> and one unbound
<strk> both with no trees
<strk> then a separate tree-only dir, from which i used to 'bzr switch'
<strk> between the bound and unbound ones
<strk> this was as for lifeless suggestion
<strk> not sure it's a good setup though
<strk> it surely isn't straightforward
<strk> so may change habits and only branch when really needed
<strk> as long as I can still do offline setups w/out big hassle
<Odd_Bloke> strk: Please file a bug about the lack of a --no-tree option to branch.
<strk> Odd_Bloke: url ?
<Odd_Bloke> strk: launchpad.net/bzr "Report A Bug", I think.
<LarstiQ> strk: I guess that is how I would work if I wanted to use switch.
<LarstiQ> strk: although I'd a shared repository inited with --no-trees
 * LarstiQ fails in English
<LarstiQ> use
<Tak> branch pushed
<Odd_Bloke> strk: Give me a link to the bug report and I'll claim it. :)
<strk> LarstiQ: there should be a 'drop-tree' or similar to use after the fact IIRC
<LarstiQ> strk: `bzr remove-tree`
<strk> Odd_Bloke: https://bugs.launchpad.net/bzr/+bug/273993
<ubottu> Ubuntu bug 273993 in bzr "bzr 1.6.1 lacks --no-tree option for 'branch'" [Undecided,New]
<Odd_Bloke> strk: Thanks. :)
<strk> LarstiQ: so, now I created the two branches, and dropped tree
<strk> but I forgot how I was supposed to crete the actual working tree for use with switch
<strk> checkou --lightweight ?
<Odd_Bloke> strk: Yup.
<strk> good. all setup now :)
<enobrev> anybody ever see a "Unrecognised container format" error after trying to "update" a recently pushed set of changes?
<enobrev> actual error message is bzr: ERROR: Unrecognised container format: 'B419'
<LarstiQ> enobrev: I haven't, can you pastebin the entirety?
<enobrev> that's it... that's the whole error... what would you like me to pastebin?
<enobrev> LarstiQ, or at least, that's all I get from bzr when i try to bzr update
<james_w> enobrev: please run again with -Derror as an option
<LarstiQ> enobrev: the command you tried plus it's output. If there is no traceback, supply -Derror as well.
<enobrev> cool... thanks... one mo.
<enobrev> LarstiQ, james_w: hey, that's fancy, here it is: http://pastebin.com/d5f6b5372
<james_w> wow
<enobrev> that sounds ominous
<james_w> it seems to be trying to read the pack header and getting something totally unexpected back
<enobrev> hmm... well, is there a way to revert a push?
<james_w> it should say "Bazaar pack format 1 (introduced in 0.18)" and it says "B419" apparently
<enobrev> any way i can help debug?
<james_w> I'm just looking at where we should look
<enobrev> i'm completely blank on this one... as for getting my job done, i just need to know how to revert the push - but if this is a bug i can help find / report, i'll be glad to help dig if you point me in the right direction
<LarstiQ> what's it bound to?
<enobrev> not sure what you mean
<LarstiQ> enobrev: what does `bzr info` say?
<enobrev> LarstiQ: ah, thx: "Standalone tree (format: pack-0.92) Location: branch root: ."
<james_w> enobrev: do you have .bzr/repository/packs/ ?
<enobrev> james_w: yep
<enobrev> 7 .pack files within
<james_w> enobrev: can you run "head -n 2 .bzr/repository/packs/*.pack ?
<LarstiQ> enobrev: where did you push from, and whereto?
<enobrev> another dev pushed from bzr 1.6.1 on a mac
<LarstiQ> update isn't in your typical workflow on a standalone branhc
<enobrev> onto this 1.5 repo on my server
<LarstiQ> enobrev: to what, this branch?
<enobrev> yes
<LarstiQ> ok
<enobrev> james_w, head doesn't seem to like the wildcard
<james_w> enobrev: it works here, may be a new feature or extension
<james_w> for i in .bzr/repository/packs/*.pack; do echo $i; head -n 2 $i; done
<james_w> that should do it
<enobrev> oh man.. silly mistake.. sorry - i was in .bzr
<enobrev> I got it one sec...
<enobrev> one of the packs came back as B419.  did you wan the full output?
<james_w> that's the badger then
<james_w> I wonder why it's got the first line missing
<james_w> you can fix it by adding "Bazaar pack format 1 (introduced in 0.18)" as the first line to that file
<enobrev> oh i see, so the first line is supposed to be "Bazaar pack format..."
<enobrev> oddly enough there's another pack file that's missing it as well
<enobrev> should i just open it up in vim and add it to the top?
<enobrev> here's the output, btw http://pastebin.com/d155efcd1
<james_w> yeah, you'll need to fix them both
<enobrev> i see... ok, i'll give it a shot, thanks guys.. back in a couple min.
<LarstiQ> well
<enobrev> LarstiQ: ?
<LarstiQ> if that is missing, the question arises as to what more could be wrong
<enobrev> any suggestions?
<LarstiQ> enobrev: make a backup before you do anything else
<LarstiQ> enobrev: cp -a repo backup
<enobrev> already done.
<LarstiQ> should be enough
<LarstiQ> enobrev: cool :)
<LarstiQ> enobrev: well then, go ahead and try it
<LarstiQ> enobrev: might want a `bzr check` later as well
<enobrev> ah.. ok
<enobrev> bzr check gave the same error
<enobrev> wow, talk about files that look like you don't want to edit them manually.  trying another bzr check...
<enobrev> It's GOOD!!!
<enobrev> thank you gentlemen.
<enobrev> bzr update worked just fine after fixing the headers on the pack files.  going to have to tell the other dev what happened to see if he can figure out anything from his end... appreciate the help.
<quicksilver> any news on the bzr web integration thingy?
<quicksilver> was it called loggerhead?
 * quicksilver googles
<jelmer> quicksilver, yup
<jelmer> lp/loggerhead
<jelmer> it's awesome
<quicksilver> that's interesting, because an awesome thing was just the kind of thing I wanted
<quicksilver> where's it's home page these days?
<quicksilver> google for 'loggerhead bzr' doesn't appear to work.
<jelmer> :-) I think the launchpad page is the main page for it these days
<quicksilver> did it become launchpad, then, basically?
<jelmer> quicksilver, it's homepage is on launchpad I think, or are you searching for an example instance to see how it looks like?
<jelmer> for the latter, see e.g. http://bzr-playground.gnome.org/
<abeaumont> hi, how can a svn repo be updated from a bzr repo created with svn-import?
<jelmer> hi abeaumont
<quicksilver> jelmer: I'm looking to download it to install locaally
<quicksilver> ah
<quicksilver> https://launchpad.net/loggerhead
<jelmer> abeaumont, pushing back into svn you mean?
<jelmer> abeaumont: bzr push <svn-url>/branch-path
<abeaumont> jelmer: yes, that's what i mean
<jelmer> abeaumont, you can only push one branch at a time though
<abeaumont> jelmer: hmmm, so, there's no need for svn specific command needed, as with svn-import?
<jelmer> abeaumont: You don't need a svn-specific command to import from svn per se, you can use "bzr branch" as well
<jelmer> abeaumont, there are no bzr commands for copying all of the branches underneath a repository
<jelmer> abeaumont, that's why svn-import exists
<abeaumont> jelmer: ahhh, ok, i didn't understand svn-import purpose then
<abeaumont> jelmer: ok, thanks!
<rockstar> How do I set my smtp server port in bazaar.conf ?
<rockstar> abentley, ^^  Maybe you know?  I don't see any docs about it.
<fdv> bzr: ERROR: Operation denied because it would change the main history, which is not permitted by the append_revisions_only setting on branch
<fdv> can anybody tell me why that is necessary?
<jelmer> fdv, why the change of main history is needed?
<fdv> I mean, as long as I get an error when trying to commit when there's a mid-air-collision, how will the two branches diverge?
<fdv> a little more context, perhaps. I do a bzr bind, then an update
<fdv> that's when I get this error
<fdv> oh, maybe it's because I have set the setting globally
 * fdv tests
<fdv> that's better, yes
<fdv> sorry about the fuss
<abeaumont> jelmer: it worked like a charm, many thanks!
<eyepulp_> yo ho ho
<eyepulp_> tryng to get 1.7 setup properly on osx without having to run the setup.py install.  is this doable?
<LarstiQ> eyepulp_: I myself run from the source tree without installing
<eyepulp_> hrm - from the python command line I can do "from bzrlib import workingtree"  but  when running under textmate and trying to commit it says it can't find the module bzrlib
<eyepulp_> the add and init work fine
<eyepulp_> looking at the textmate commit code now
<LarstiQ> eyepulp_: bzrlib users need to be able to find it. One option is to install it so it gets into python<version>/site-packages/
<LarstiQ> eyepulp_: another is to broaden the python path, for instance, export PYTHONPATH=~/src/bzr/bzr.dev/
<eyepulp_> yeah, I have a .pth file that points to the dir above bzrlib
<LarstiQ> ok
<LarstiQ> eyepulp_: but textmate isn't looking at it?
<eyepulp_> as mentioned, I can drop into the py interpreter and import bzrlib
<eyepulp_> but yeah, TM can't find it.
<strk> I'm trying to install the bzr-gtk plugin, but isn't working
<eyepulp_> I've restarted TM on the odd chance it cached the .pth settings
<jam> beuno: ping
<strk> I got bzr-1.6.1 release
<strk> and fetched bzr-gtk from repository
<strk> do I need a bzr-gtk *release* instead ?
<strk> bzr: ERROR: exceptions.AttributeError: 'module' object has no attribute 'link_button_set_uri_hook'
<jam> siretart: ping
<strk> ^^ this is the error with that setup
<jelmer> strk, afaik that's caused by a too old version of pygtk
<strk> uhm
<jam> hmm... perhaps I can ask Jelmer... do you know the process for packaging bzrtools?
<jam> siretart and beuno have done the last few, so I'm not explicitly set up for it
<jam> but I'd like to, and I'd like to get 1.7 into the ppa
<jelmer> jam: Same story as everything else :-)
<strk> I'm on debian... could add ppa with instructions
<jelmer> strk: On debian, you should be able to just install the debian package
<strk> ii python-gtk2   2.8.6-8
<jam> jelmer: well, not the same as bzr-svn or bzr, since I packaged both of those :)
<jelmer> jam: ah, it's probably not based on the Debian package then
<jam> there seems to be a lp:~jelmer/bzrtools/experimental
<strk> Need to get 213MB of archives.
<strk> :!
<strk> 156 upgraded, 102 newly installed, 30 to remove and 541 not upgraded.
<jam> Is it just grab that, put in a new dch entry
<jam> and package it up?
<strk> not now plz :)
<jelmer> jam, Yeah, I think so
<jam> Ah, now I see the other packaging branches, thanks for bearing with me
<abentley> rockstar: You put a colon after the server name, followed by the port number.
<rockstar> abentley, that wasn't working.  I ended up just setting up a local postfix instance to relay mail.
<abentley> rockstar: Works for me.  What config line did you have.
<rockstar> smtp_server = <mail_host>:587
<abentley> rockstar: That looks right.  Where did you put it?
<rockstar> Tried two different servers.
<rockstar> abentley, bazaar.conf [DEFAULT]
<abentley> I mean, did you put it in bazaar.conf, locations.conf or branch.conf?
<abentley> Okay, perhaps it was being overridden by a setting in locations.conf.
<rockstar> Yea, wasn't defined anywhere else.
<abentley> rockstar: Was any additional configuration needed, e.g. username or password?
<rockstar> No, but the relay server I set up in postfix requires it.
<eyepulp_> LarstiQ: it looks like textmate is using a different install of python than I am.  irksome
<abentley> What operation were you doing?
<eyepulp_> me?
<eyepulp_> not me - sorry
<abentley> eyepulp_: no, I meant rockstar.
<LarstiQ> eyepulp_: if you try setting PYTHONPATH in the shell instead of using a .pth, it should pick up on that though?
<rockstar> abentley, trying to submit to PQM.  Comcast decided to start blacking port 25 today.
<rockstar> I also can't seem to type blocking today...
<abentley> rockstar: Maybe you can and your computer's just trying to make you crazy...
<rockstar> abentley, if you had been working on cscvs as long as I have, you would start hallucinating too... :)
<jam> jelmer: so which is more correct to use... ~debian-bazaar/bzrtools/debian, or ~jelmer/bzrtools/experimental, or is it something over in the bzr.debian.org domain?
<jelmer> jam: http://bzr.debian.org/pkg-bazaar/bzrtools/experimental is the most correct at this point
<jam> jelmer: of course, "experimental" is rich-root while "unstable" is still knit format...
<jelmer> jam: I've recently merged the debian/ directory and the upstream branch
<jam> sure, I noticed
<jelmer> jam, since that involved using join, I had to upgrade
<jam> well, you didn't *have* to. I've done it about 4 times in the bzr code base
<jam> with various plugisn
<jam> but probably the simple "bzr join" command wouldn't work without it
<jam> bzr merge-into would, though
<LarstiQ> are you sure?
<jam> LarstiQ: asking me? I just did it (as well as updating bzr-merge-into to work again :)
<LarstiQ> hmm, maybe I did explicitly ask for --development-subtree
<LarstiQ> jam: sort of, I was pondering if join didn't work by default
<LarstiQ> jam: maybe I've been living too close to nested-trees lately
<jam> ugh, we've got 3 different ways that bzrtools is being packaged... :(
<jam> with different branch ancestries
<jam> jelmer: I'm not positive, but I think your 1.7 package for bzrtools is incorrect.
<jam> Is see:
<jam> http://edge.launchpad.net/bzrtools/stable/1.6.0/+download/bzrtools-1.6.0.tar.gz
<jam> sorry
<jam> Depends: ${python:Depends}, bzr (>= 1.6~), bzr (<< 1.7~), patch
<jam> which means the bzrtools 1.7 package is depending on bzr 1.6 rather than bzr 1.7
<jelmer> jam, Sorry, I had that fixed, just not pushed yet
<jelmer> jam: Should be pushed now
<jam> any particular reason you don't use a checkout? You seem to often forget to push
<siretart> jam: pong?
<jelmer> I sometimes do but always unbind when I work offline
<jelmer> (I hate bzr up's behaviour turning local commits into pending merges)
<jam> siretart: jelmer answered my question, thanks for getting back to me
<siretart> k
<jam> jelmer: do I need to do a new bzr-svn package for bzr 1.7? Or is it still compatible with the 0.4.12 release?
<jelmer> jam, You need a new one - I silently released 0.4.13 today
<jam> again with "experimental" ?
<jam> and you did upload it, right?
<jelmer> yep
<jam> jelmer: so do I need to be releasing them as 0.4.13-2~bazaar1, or 0.4.13-1~bazaar1 ?
<jam> since you had to do a -2
<jelmer> the first
<jelmer> so people who are using ubuntu will get your package rather than the broken 0.4.13-1
<jelmer> (just theory, in practice this can't really happen because the time window between -1 and -2 is so short)
<jam> I suppose, though your -2 branch supersedes the -2~bazaar1 one anyway
<jam> s/branch/package/
<nDuff> Does bzr-rebase contain functionality equivalent to "git rebase -i"?
<jam> jelmer: you may have uploaded, but I don't have a bzr-svn-0.4.13 tag
<Odd_Bloke> nDuff: Describe what the git command does. :)
<jam> Odd_Bloke: it doesn't have --interactive, I believe
<jam> Robert has talked about it, as have others
<nDuff> Odd_Bloke, provides a text file describing the order in which the given revisions are applied, and allows that file to be edited to reorder or coalesce revisions.
<jam> or maybe you do and I just forgot --export-upstream
<jam> let me check
<Odd_Bloke> nDuff: Then, no, I don't think so.
<jam> last I recall, lifeless thought it would be about 1 day worth of work to implement it
<jam> jelmer: what about bzr-gtk? Since that is in the same repo
<jelmer> jam, try "debian-0.4.13-2"
<jelmer> jam, I've started using "bzr mark-uploaded" (from bzr builddeb)
<jam> jelmer: I just needed to use --export-upstream=.
<jelmer> yeah, by default the location is set to launchpad
<Odd_Bloke> jam: Is that 1 lifeless day or 1 normal-person day? :p
<jam> Odd_Bloke: well, parsing a text file isn't particularly difficult
<jam> it is more the what do you do when you conflict, and how do you resume
<Odd_Bloke> So one normal-person day?
<jam> anyway, mostly afk because the sick baby just woke up
<Crusher4> I'm having problems with Mac OS X 10.5.5 + bzr 1.5 and/or 1.6.1 + sftp repository
<Crusher4> it says 'garbage packet recieved'
<Crusher4> but i can ssh to it just fine
<Crusher4> just tried it with 1.7, same problem
<rockstar> jelmer, around?
<jelmer> rockstar, sortof
<rockstar> jelmer, what does "sort of" mean?
<rockstar> Could you help me with a libsvn issue?
<jelmer> rockstar, sure
<rockstar> I'm stuck, and I'm searching for help...
<rockstar> jelmer, https://code.edge.launchpad.net/~rockstar/launchpad-cscvs/remove-pysvn
<rockstar> I'm trying to check out from libsvn using the SWIG python bindings.
<rockstar> However, I think I have the params right, but it fires off the exception SubversionException: (None, 195002) which appears to be a revision error.
<jelmer> yeah, that's SVN_ERR_CLIENT_BAD_REVISION
<rockstar> jelmer, do you have that memorized?!
<jelmer> well, there's a couple of these that you hit very often
<jelmer> rockstar, what are the exact arguments you are passing in?
<rockstar> client.svn_client_checkout(svn_url, path, core.svn_opt_revision_t(), True, client.svn_client_ctx_t(), self._pool)
<rockstar> jelmer, ^^
<jelmer> rockstar, you have to initialize core.svn_opt_revision_t
<rockstar> jelmer, yea, so the actual call is client.svn_client_checkout(svn_url, path, revision, True, ctx, self._pool)
<rockstar> I just wanted demonstrate the types.
<jelmer> (pool is optional, you shouldn't use it for new code)
<rockstar> jelmer, I thought that was correct.  IT should be managing its pools on its own, right?
<jelmer> yeah
<rockstar> But if I remove it, I still get the error.  :(
<jelmer> how do you initialize opt_revision_t ?
<rockstar> revision = core.svn_opt_revision_t()
<jelmer> you don't initialize any of the members of svn_opt_revision_t ?
<rockstar> jelmer, I found no docs that said I needed to.  :(
<jelmer> You found docs !? (-:
<rockstar> Yea, it's called reading other people's code...  :)
<jelmer> I always initialize the "kind" member
<jelmer> not sure if that's really necessary
<rockstar> jelmer, I don't think I'm familiar with that.
<jelmer> revision.kind = svn_opt_revision_head
<rockstar> jelmer, holy crap, I think that got it!
<rockstar> jelmer, still around?
<jelmer> rockstar, yeah
<rockstar> So if I set revision.kind to svn_opt_revision_number, how do I set the actual number?
<jelmer> rev.value.number IIRC
<rockstar> Ah, great, thanks.
<jml> lifeless: hello
<igc> morning
<poolie> hello igc, jml
#bzr 2008-09-25
<lifeless> jml: hi
 * jml waves hello
<jml> lifeless: are you waiting on anything from me for the testresources merge?
<lifeless> no
<lifeless> just time
<jml> ok.
<lifeless> jam: ping
<poolie> re.search(r'^(?!Bazaar)', 'Bazaar')
<lifeless> poolie: ?
<poolie> is for jam. not for you.
<poolie> In [11]: re.search(r'^(?!.*\[merge\])', 'Subject: [merge]taheout')
<poolie> In [12]: re.search(r'^(?!.*\[merge\])', 'Subject: [mer]taheout')
<poolie> Out[12]: <_sre.SRE_Match object at 0x8a2dfa8>
<jam> lifeless: hi
<jam> I should be heading out soon
<lifeless> oh, on the call? didn't see a invite..
<lifeless> jam: I want to talk per file log
<jam> we can chat briefly
<poolie> In [14]: re.search(r'^Subject: (?!.*\[merge\])', 'Subject: re: re: [merge]taheout')
<lifeless> irc or voice? either is fine for me
<jam> ATM, I'm thinking we could add a flag to switch between "only the things in the per-file graph" and "also include merges"
<lifeless> so
<lifeless> IIUC what we have at the moment is roughly 'when log -v would mention the file' union (per-file graph nodes) with containing commits listed to give an organisation sense
<jam> lifeless: I'm not sure how you are defining "containing commits", as I'm pretty sure it is just when "bzr log -v" would mention the file
<jam> (is what we have now)
<lifeless> say we have a triangle
<lifeless> A
<lifeless>  B
<lifeless> C
<lifeless> A<->C doesn't alter FOO
<lifeless> B<->C does
<lifeless> and A<->B does
<jam> lifeless: so you modify B and then revert it to C
<lifeless> (e.g. b makes a change, but its rejected when merged to A
<jam> ?
<lifeless> yrd
<lifeless> yes
<lifeless> meh, not complex enough to show
<lifeless> anyhow
<jam> right, we'll show C
<jam> I think, because it is different from a merge parent, but I'm not 100% sure
<jam> however, that should also show up in the per-file log
<jam> sorry, per-file graph
<lifeless> thats what I mean by not complex enough to show the point
<jam> I should really get going. Perhaps we can phone-chat later?
<lifeless> so one benefit of showing the file where log -v would show it, is that its unsurprising to users
<lifeless> please, ping me
<lifeless> poolie: have you done the daily chat?
<poolie> yes
<poolie> i pinged you on irc just beforehand
<poolie> if we call from inside the call everyone has to talk over the ring tone
<lifeless> poolie: yes, I saw, but didn't see a skype prompt pop up
<lifeless> poolie: I'm not stressed, was just confirming
<lifeless> chore to run, brb
<abentley> poolie: Do you want to talk about reivews now?
<jam> lifeless: ping for great justice
<poolie> abentley, sure, if you want to
<abentley> poolie: I think this is the day we planned to.  So let's.
<lifeless> jam: I've replied in mail
<jam> lifeless: yeah. It sure looks like you wanted to vote in there :)
<jam> lifeless: I replied to you. And basically I think we are in agreement.
<lifeless> jam: ok, cool then
<lifeless> I'd approved previously, consider it reinstated
<lifeless> igc: you should upgrade http://bazaar.launchpad.net/%7Eian-clatworthy/bzr-usertest/trunk/.
<lifeless> abentley: around ? I'd like to run an idea past you
<abentley> lifeless: okay
<lifeless> this is about rich roots.
<lifeless> I'm thinking to remove the watershed event by writing a rich-root->non-rich-root-with-root-in-rev-property->rich-root-by-reading-rev-property set of code
<lifeless> abentley: What I want to ask you is two-fold; do you think this is a reasonable thing to do, and do you think I can avoid a new rich-root-format to enable this (I don't think I can)
<lifeless> abentley: uhm, various little details that might matter are - I'm not suggesting to add rich-root capabilities to non-rich-root formats, just allow pulling from rich to non-rich
<abentley> lifeless: So, roundtripping?
<lifeless> abentley: yes
<lifeless> abentley: I think its 1-2 days work tops, and if it gets rid of the watershed it may allow more motion on this
<abentley> lifeless: The lack of round-tripping is not the biggest issue for me.  The biggest issue for me is the whole "let's add a new serializer as a condom" thing.
<lifeless> abentley: uhm, wasn't that your idea though?
<abentley> kinda originally.  But then when I realized that we had to mutate the sha1s for existing rich-root formats, I didn't see much point in it.
<abentley> But then you wanted it as a "condom" to ensure that sha1s were correct.
<lifeless> abentley: I think we must have talked past each other then; I want the sha1 chain to be intact regardless of repo format and serializer.
<lifeless> abentley: thats my primary issue, so that 'check' can actually do its job
<abentley> So would you have any hesitation about making 1.6-rich-root our next default format?
<lifeless> abentley: my set of concerns is ([has-the-sha1-thing-been-fixed, how-will-users-find-the-change])
<lifeless> abentley: I admit to some trepidation that the one-way nature of the change will burn some users that want to interoperate, as 'init' 'init-repo' etc will all suddenly make them unable to interoperate with bzr's more than 2 months old
<lifeless> abentley: the sha1 is a MUST for me; I'll happily follow consensus on the other
<abentley> So has the sha1 thing been fixed?
<lifeless> abentley: there is an outstanding patch of yours; I'll poke around at the sha1 code in the near future and see
<abentley> Right, so I believe that's the last piece.
<abentley> And the problem with that patch is that it's overbroad.
<abentley> I think the interoperability situation is quite good.  bzr 1.0 supported "rich-root", so anything in 1.6-rich-root can be converted into a 1.0 compatible format.
<lifeless> abentley: oh true
<lifeless> a possibly useful test would be a script to mass-convert everything on lp to rich root, to see if it all works
<lifeless> (s/convert/branch and do a convert locally|branch-into-a-rich-root-branch/)
<abentley> lifeless: Why do you think it would be useful for mthaddon to kill me? :-)
<lifeless> tom would love it
<lifeless> we have that shiny new machien
<abentley> So possibly a torture-test would be useful.  Bazaar itself was pretty tortuous.
<abentley> My patch handles weaves repos and their predecessor format.  You said you thought it should only cover knits and packs, IIRC.
<abentley> We land that, and reconcile will fix sha1s.
<abentley> This doesn't prevent revisions with bad sha1s from being fetched, of course.
<abentley> Does that remove your concerns about correctness?
<abentley> lifeless: ^^^
<lifeless> abentley: I thought it should only cover the cases where we know that fetch creates broken sha1s
<lifeless> abentley: not-fetching-bad-sha1s will come in after this because I can actually land my patch to do that without breaking every rich root user :)
<abentley> lifeless: I think that TreeTransform should be able to set the SHA1 of a file.  Do you agree?
<lifeless> abentley: with a caveat - the stat cache cutoff time
<lifeless> abentley: which basically means that any file we write we usually can't put in the stat cache
<abentley> lifeless: do renames update the stat values used?
<abentley> Actually, even if they did, only a few files are actually renamed.
<lifeless> abentley: I don't know for windows; for unix no - the directories inode changes, not the files
<lifeless> IIRC doing a hard link invalidates the stat cache
<abentley> lifeless: Pity that.
<abentley> But I think many tree constructions would take long enough that we could use the stat values.
<abentley> So for those files, at least, we'd be able to avoid the initial SHA.
<lifeless> abentley: we can use the stat value if we write the dirstate outside the cutoff time AND noone-else could have touched the file inside that period either
<abentley> lifeless: So if the file is inside .bzr/workingtree/limbo, is that safe enough?
<lifeless> abentley: so pragmatically, I think that if the cutoff time is passed while its in limbo, then its safe
<lifeless> abentley: yes, if someone fucks with limbo they can keep both pieces
<abentley> So for TT to update this data, should we update apply_inventory_delta, or introduce a new function?
<lifeless> abentley: I have a branch up for review that adds a function to tree- _observed_sha1
<abentley> lifeless: Yeah, I saw it.
<lifeless> abentley: its the commit-updates-sha patch; is that function suitable for you ?
<abentley> lifeless: I thought it might be better to do the operation on a list.  But I could also use _observed_sha1.
<lifeless> abentley: I think a new function, that takes a list form of the parameters for _observed_sha1 would be fine
<lifeless> abentley: possibly just make _observed_sha1 take a list of tuples
<ReachingFarr> I'm new to Bazaar so please bear with me.  I have started a project on my local machine and now I want to move it to a centralized location (hopefully with full history).  Am I correct in thinking that `put` is the command I'm looking for?
<fullermd> ReachingFarr: push.
<fullermd> I don't think 'put' _is_ a command...
<ReachingFarr> Hehe ya, sorry.  Push.
<Peng_> ReachingFarr: That's exactly what the "push" command is for.
<Peng_> ReachingFarr: Have you been reading a tutorial?
<ReachingFarr> OK, second problem then is why does my Bazaar install not deal with authentication over http.  From what I have seen while Googleing it is supported but when I try pushing it just errors out on 401.
<fullermd> At one time, it would only even try auth if you put the username in the URL.  Not sure when/if that changed.
<ReachingFarr> Peng_: I did a while ago then started using Bazaar locally.  I thought `push` was the correct command and have been trying to use it as such.  But the authentication issue is why I'm really here and thought I would make sure I was using the correct command first.
<ReachingFarr> Part of the problem here is that Fedora only has 1.5 in the repo.  I guess I better update to something recent before I start asking for help.
<fullermd> 1.5 isn't that old.  I'm not sure much has changed in auth since then.
<fullermd> (updating is a good idea in general, of course.  But I don't think it'll fix this)
<Peng_> ReachingFarr: Do you have FTP or SFTP access to your server? That might be easier to use than HTTP auth.
<ReachingFarr> Peng_: I don't think so.  We are using my friends Dreamhost account and I'm not entirely sure how things are set up on it.
<fullermd> Dreamhost?  You can set up the smart server on Dreamhost?
<Peng_> fullermd: I wouldn't recommend it due to procwatch.
<Peng_> ReachingFarr: Well, DH offers SFTP access, but your user may not be configured to allow it. Try it, or ask your friend.
<fullermd> Well, that was somewhat my point...
<ReachingFarr> Whenever I put the username in the address (http://user@example.org) bzr crashes on me.  And this is after I installed 1.7.
<fullermd> Crash how?  Pastebin it.
<seb_kuzminsky> i have to work with an svn repo...  I'd like to use bzr & loom to do it.  Am I crazy?
<seb_kuzminsky> what i mean is, is it possible?
<Peng_> seb_kuzminsky: Check out the bzr-svn plugin. But yes, you're probably crazy. :P
<seb_kuzminsky> i got that installed, (0.4.11, from intrepid), and i branched my svn repo to a local shared repo, that was slow but it worked :-)
<Peng_> Sounds about right.
<seb_kuzminsky> i branched locally, checked out, and loomified and we'll see what happens next ...
<ReachingFarr> fullermd: http://pastebin.com/d5317e471
<fullermd> Well, that's pretty wacky.
<fullermd> vila: ^^^
<fullermd> vila's the http guy; he'll know better what to look at.
<fullermd> You have the fgci/mod_python smart server all setup and working on it?
<fullermd> Er, fcgi that is.
<seb_kuzminsky> what does 'bzr record' do?  i dont understand the --help message
<seb_kuzminsky> a thread has a "tip", but what does that mean?
<lifeless> seb_kuzminsky: the tip of a thread is just like the tip of a branch; its a pointer into the revision graph
<seb_kuzminsky> that makes sense...
<seb_kuzminsky> if i 'bzr push' from a thread, will it also push all the threads below it?
<lifeless> two cases; pushing from a loom to an existing normal branch; this pushes the current thread into that branch
<lifeless> the threads below it are included if you have merged them into that thread (which is what happens when you 'up-thread')
<lifeless> second case; pushing from a loom to a new branch (or to an existing loom)
<lifeless> this will push the last recorded loom (much like 'push' from a normal branch pushes the last commit from that branch)
<seb_kuzminsky> lifeless: thanks!
<seb_kuzminsky> is there something like 'bzr log' for 'record'?
<seb_kuzminsky> or is that the wrong way of thinking of it?
<lifeless> seb_kuzminsky: there should be; I haven't written it yet :(
<seb_kuzminsky> wow, you wrote loom?!  I love it!  (though i'm having a bit of a hard time learning to use it)
<seb_kuzminsky> thanks for some sweet software :-)
<lifeless> thanks, I'm glad you like it
<seb_kuzminsky> hm, i think it just ate my changes (or i'm misunderstanding how to use it)
<lifeless> it shouldn't have any bugs of that nature; what were the last few things you did?
<Peng_> How do you think I should set up logging for the HTTP smart server?
<Peng_> Just a couple lines with the logging module? Something in bzrlib?
<lifeless> spiv: ^ your public awaits
 * Peng_ reads trace.py
<lifeless> Peng_: it probably already logs to ~/.bzr.log
<seb_kuzminsky> lifeless: i just tried it again and it did the same thing
<seb_kuzminsky> bzr loomify; bzr create-thread test
<seb_kuzminsky> # hack, hack
<seb_kuzminsky> bzr commit
<seb_kuzminsky> bzr combine-thread
<lifeless> ah, yes, you misunderstand :P
<seb_kuzminsky> now my loom has just the original thread, and it doesnt have the change from the test thread
<seb_kuzminsky> oh good :-)
<lifeless> combine-thread is used to remove a thread from the list :P
<seb_kuzminsky> ah
<lifeless>   Use combine-thread to remove a thread which has been merged into upstream.
<seb_kuzminsky> hm, just like the --help says...
<seb_kuzminsky> right
<lifeless> (the help describes exactly what it does)
<seb_kuzminsky> so i should bzr push before i combine-thread?
<seb_kuzminsky> then up in the bottom thread?
<Peng_> lifeless: Why do you think it would use ~/.bzr.log? I mean, it isn't normally used when you "import bzrlib", is it?
<lifeless> seb_kuzminsky: so, the general use case would be
<lifeless> Peng_: oh, hmm, gues snot
<seb_kuzminsky> (my branch is bound to an svn repo)
<lifeless> seb_kuzminsky: a trunk, at URL $TRUNK (your svn repo in this case)
<seb_kuzminsky> sorry, unbound but parent is an svn repo
<lifeless> seb_kuzminsky: a developer with a loom, containing a bottom thread 'trunk' (or similar)
<lifeless> seb_kuzminsky: then you create threads and hack. when a particular thread is accepted by upstream, doing a pull in the 'trunk' thread will bring in changes you already have higher up in your stack.
<lifeless> seb_kuzminsky: when you (up-thread & commit) those changes, the difference the thread contains will go away, and you would then combine thread
<Peng_> Hmm, I could change the location by setting os.environ['BZR_LOG'[, right?
<Peng_> Err, minus the syntax error. :P
<seb_kuzminsky> lifeless: i see
<lifeless> seb_kuzminsky: so yes, you should push the thread you've finished into svn before removing it :P
<seb_kuzminsky> heh, that might help :-)
<lifeless> seb_kuzminsky: or have the person that will accept and commit the patch do so,a nd then you get it back via your trunk thread
<seb_kuzminsky> i think the "combine" in combine-thread threw me off
<seb_kuzminsky> if i'd read your docs i would have understood
<seb_kuzminsky> thanks for teaching me :-)
<lifeless> seb_kuzminsky: theres been some talk of renaming it
<lifeless> this is evidence towards doing that
<seb_kuzminsky> drop-thread or delete-thread maybe?
<lifeless> yah
<seb_kuzminsky> or evidence i should read tfm
<lifeless> :P
<fullermd> drop-thread is a fast version of down-thread   :p
<lifeless> knowing the tool is good; reducing the learning curve is also good
<Peng_> If I do "from bzrlib import trace; trace.push_log_file(...)", will anything have been logged yet?
<seb_kuzminsky> lifeless: when should i record?
<spiv> Peng_: there was a patch about this to the list recently
<spiv> Peng_: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C418c22640809141502o187ee0det95166e025836aba%40mail.gmail.com%3E
<lifeless> seb_kuzminsky: whenever you like; the main reason for record is to allow collaboration on a loom-scale between loom-users
<spiv> (Which oddly was approved by John, but not merged...)
<lifeless> seb_kuzminsky: if you're just managing your own patches via loom, and are not publishing your loom anywhere, you don't need to push at all.
<seb_kuzminsky> dont need to record at all?
<lifeless> seb_kuzminsky: otherwise, if you are sharing them, or are publishing your loom, record before you push
<lifeless> seb_kuzminsky: yes, I made a typo :)
<seb_kuzminsky> ok i get it :-)
<seb_kuzminsky> i got a backtrace just now
<seb_kuzminsky> i'll pastebin it
<lifeless> seb_kuzminsky: (before you push the /loom/ as opposed to pushing a thread into svn or something similar)
<lifeless> seb_kuzminsky: thanks
<seb_kuzminsky> http://pastebin.ca/1210326
<spiv> Peng_: I suspect that patch probably isn't as flexible enough yet; I'm guessing you'd like to be able do something like "make_app(..., logfile='/foo/bar')" ?
<seb_kuzminsky> i tried to change the nick of a loomified branch
<seb_kuzminsky> afterwards (now), show-loom shows no active thread, and it keeps leaving the lock around
<markh> does bzr attempt to perform 'globbing' on its cmdline args on windows?  I'm surprised to find 'bzr revert foo*.py' not work...
<lifeless> seb_kuzminsky: oh, put the nick back to the name of the thread you were on
<spiv> Peng_: if you do get logging set up to your satisfaction, please mail the list with details of how you did it :)
<lifeless> seb_kuzminsky: the nickname is managed by loom automatically when you switch threads (bzr up-thread, bzr down-thread, bzr switch)
<lifeless> markh: yes, see cmd_add for example, for instance
<seb_kuzminsky> indeed!  thanks!
<igc> lifeless: usertest is upgraded now as requested
<lifeless> igc: thanks :P
<seb_kuzminsky> i'm gettin me all kinds of learning tonight :-)
<seb_kuzminsky> thanks lifeless, see you later
<markh> lifeless: revert, status and diff seem not to - is that a bug?
 * beuno stabs beuno_ 
<markh> dir
<markh> heh
<lifeless> markh: I'd say its a bug, yes
<Peng_> spiv: I've got it set up, but not to my satisfaction. I just used bzrlib.trace.push_log_file(), so it doesn't show the date, time, PID or any sort of contextual information. (At least for the messages I've been able to get it to generate so far: warnings about a knit repo.)
<spiv> Peng_: ah, crummy.
<Peng_> Hmm. Using enable_default_logging would make it output that information, but it would also set up a stderr logger, which I don't want.
<spiv> Yeah, the stderr handler doesn't sound like a good idea :)
<markh> so, there is an existing bug that 'commit' doesn't glob on windows.  Should I just 'adopt' that bug and broaden it for all commands known to need that support added?
<Peng_> I might just copy parts of enable_default_logging().
<lifeless> markh: I don't like broadening bugs
<markh> so add 4 new bugs all identical except for the specific command?
<lifeless> markh: because it marks it harder to ever actually close it; unless you think there is a simple fix-for-all-commands
<markh> well yeah, the same fix would be used for all, but possibly need to be applied for each commaand
<spiv> markh: it's easier to combine separate bugs (by marking as dupes) than it is to separate an existing bug into multiple bugs.
<lifeless> markh: what would be ideal is a simple way to test globbing-on-windows-on-commands, so we can tell if things regress etc
<spiv> markh: so when in doubt it's probably best to default to filing multiple bugs.
<markh> even easier to avoid it if possible, hence my question ;)
<spiv> Well, true :)
<spiv> Unless you count asking questions as hard work ;)
<lifeless> markh: put it this way, if you're writing code to fix it for all commands you know of, why bother touching the bug :P
<markh> :) less work than re-touching 4 bugs that are effectively dupes if that isn't what was wanted.  But as it is, I'll do it.
<lifeless> markh: just wrte the code, tell the bug you have a branch, and bingo its done :)
<markh> I'm not proposing to fix it ;)
<markh> heh
<markh> then we spend 5 weeks debating the style, remember ;)
<lifeless> mmmm, I don't think we do. But YMMV
<markh> the bug actually notes a fix was previously submitted but resubmission was requested multiple times, according to the bug anyway
<Peng_> No, someone sends one "bb:tweak" suggesting the style be changed, and then everybody forgets about the branch for a few months until someone reminds them to check the BB queue.
 * Peng_ ducks
<markh> ditto for my "update -r" bug I must get back to
<Peng_> markh: I think someone sent a patch for that. Was it you?
<markh> "update -r" - yeah
<markh> I picked up old work that I thought was quite close, so I merged it and updated it for 2 years worth of changes, but it turns out a number of other things still need doing, and I really can't justify spending any more personal time on it :(  I asked for help landing it in the bug...
<vila> hi all !
<vila> fullermd, ReachingFarr (actually he seems to be gone :-/): on that particular one (65 data rewind), I think spiv knows more than me
<vila> I've never reproduced it so I don't know where to lookt at
<Peng_> spiv: OK, I've got it set up to my satisfcation (as far as I can tell)
<pysquared> Hi all.  Does anyone know if possible to do a partial checkout?  I have a big tree of related sub-projects, and usually only want to work on one or two, and do not want a complete working tree.
<beuno> pysquared, you can't currently, no
<pysquared> Shame
<pysquared> Any plugins to do this that you know of?
<pysquared> Is there a feature request for this (that I have not found yet), or shall I add one?
<beuno> no, I don't think you can do that currently
<beuno> feel free to add it
<Peng_> I'm thinking about making a certain branch public, so I was just reading through the log to see if it's appropriate. One message includes a declaration of love for one of bzr's developers. Whoops.
<beuno> that's very appropriate
<pysquared> Ah, just found a note about it on jam's blog - http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html
<pysquared> Should I file a feature request anyway?
<beuno> pysquared, yeap, go for it
<LarstiQ> if there isn't already one
<pysquared> Ahah, I spent ages searching for something before.  Found this: http://bazaar-vcs.org/FilteredViews
<pysquared> It was linked from http://www.infoq.com/articles/dvcs-guide
<lifeless> night all
<beuno> g'night lifeless
<beuno> AFAIK filtered views still bring in the full repo
<beuno> I may be wrong
<beuno> igc is working on it
<lifeless> they always will in the current designs
<lifeless> anyhow, /gone
<tvainika> jelmer: did you notice that debian experimental now has bzr-svn 0.4.13 which depends on bzr (<< 1.7~) so it cannot be installed with bzr 1.7 from debian experimental after your yesterday uploads?
<beuno> mwhudson, I'm cleaning up bugs in LH: https://bugs.edge.launchpad.net/loggerhead/+bugs?search=Search&field.status=New&field.status=Incomplete&field.status=Confirmed&field.status=Triaged&field.status=In+Progress&field.status=Fix+Committed
<beuno> the last two NEW have your name on it  :)
<Peng_> spiv: There's a typo in your -Eallow_debug patch. It should be "sanitisation", not "santisation".
<fullermd> That hardly sounds sanitized   :p
<Peng_> Oh, my email client unfroze now.
<spiv> Peng_: d'oh, thanks.
<Peng_> :)
<spiv> vila: how's your patch to remove SmartClientMedium from RemoteTransport's set of base classes doing?
<vila> waiting review :)
<spiv> vila: My -Dhpss patch on the list reminded me just how many SmartClientMedium instances we're currently creating, and it's a bit nuts...
<spiv> Hmm, I don't see it in my bundle buggy queue.
<vila> my fault wrong subject it appears
<vila> it's part of the python-2.6 compatibility RFC
<vila> the patch includes caching the medium created so that should address your concern
<vila> The controversial bit is that I use weakref to avoid a circular dependency
<spiv> Huh, interesting.
<spiv> What's wrong with a circular reference?
<spiv> Because the medium has a __del__ it causes uncollectable cycles?
<vila> no more gc ?
<vila> __del__ will never be called if the ref never reach zero, the medium references the transport
<vila> and is an attribute of the transport
<vila> so I made the transport attribute a weak ref in the medium
<vila> all of the above applies to SmartClientHTTPMedium only of course
<spiv> I suspect it's possible to find a more elegant solution.
<spiv> But I don't think it's worth wasting the effort to find it :)
<spiv> Thanks for the update.
 * spiv goes swimming
<spiv> (idea: maybe the HTTP transport and HTTP medium could share a reference to an HTTP channel, rather than to each other?)
<vila> spiv: the root problem is that both the transport and the medium have a 'base' attribute with isn't related to the http channel
<vila> so while the http 'channel' can be shared between transport/medium pairs, the base must be shared by each pair
<vila> and this sounds is a bit complicated for what we want to achieve
<vila> I don't have problems with weakref per se but I'm not sure this is view shared by everyone
<vila> spib: Anyway, I'd like to rework my python-2.6 branch into a loom so I can more easily extract that smart medium part if you think it's worth merging sooner
<vila> spiv (grr): Anyway, I'd like to rework my python-2.6 branch into a loom so I can more easily extract that smart medium part if you think it's worth merging sooner
<poolie> vila, hi
<poolie> how are you going?
<strk> so, I have these two branches on two machines being both parented to the online one
<strk> how can I avoid a double network activity to bring them both in sync with the online one ?
<strk> ie: can I have hostA pull from hostB on a case-by-case basis ?
<strk> case-by-case means: sometime I want hostB to pull from hostA
<Peng_> strk: I guess you could keep a copy of the parent on one of the machines, then have the other pull from it.
<jonnydee> hi, i need help: "bzr revert" returns 'bzr: ERROR: Could not acquire lock "D:/duscher/docs/ProjektM/dev/.bzr/checkout/dirstate"'
<jonnydee> I am using bzr.dev on windows
<jonnydee> break-lock does not help
<jonnydee> re-checkingout the branch produces the same error in the new branch
<jonnydee> does anyone have a clue how to recover from this state? I have a presentation in 2 hours and I would like to be able to revert...
<Peng_> jonnydee: Sorry, but I don't know. My only two ideas are 1.) Are you using the most recent version of bzr?, and 2.) did something get marked read-only?
<poolie> night all
<poolie> jonnydee: probably there is still a bzr process running somewhere
<poolie> kill it off and you should be ok
<poolie> if all else fails :-( reboot
<poolie> hth
<pysquare1> Hello.  Is there a way to reconfigure a shared repository to have the --no-trees option?
<spiv> pysquare1: touch .bzr/repository/no-working-trees
<spiv> I don't think there's a nice way to do it with the 'bzr' command line, although there ought to be.
<pysquare1> Thanks spiv, I just did; bzr init-repo t1; bzr init-repo --no-trees t2; diff -r t1 t2; and got "Only in t2/.bzr/repository: no-working-trees" -- cool.
<_dereine> hi, are there any private bazaar hosting services?
<LeoNerd> Anything with a webserver I should think
<LeoNerd> You don't need a special server.. anything you can (s)ftp to and http from is sufficient
<Lo-lan-do> Hi all
<Lo-lan-do> I apologise in advance for being rude, but is there work done on performance these days?
<Lo-lan-do> Specifically, start-up time?
<james_w> hey Lo-lan-do
<james_w> there was a discussion on the list just recently about that very topic, discussing where and how to reduce start-up time
<Lo-lan-do> Goody :-)
<Lo-lan-do> Has it been suggested that maybe not all of bzr needs to be loaded and initialized for each invocation?
<Lo-lan-do> I understand lots of code has to be loaded for complex operations, but maybe "bzr info" could do without it (and come below 2 seconds)...
<Lo-lan-do> I have a large root+lots of feature branches+integration branch setup, with a script to merge all feature branches back into the integration branch, and it seems like a shame to spend so much time waiting for bzr nick to answer.
<siretart> Lo-lan-do: if that script is in python, you could use bzrlib directly
<Lo-lan-do> It's shell so far.
<Lo-lan-do> Maybe "bzr shell" could help?
<siretart> maybe, but I'm not familiar with 'bzr shell'
<siretart> I meant when your script needs to iterate over a lot of branches, it might make sense to do that in python with bzrlib directly to avoid loading bzrlib for every branch but just once at startup of that script
<Lo-lan-do> Yes, and I think bzr shell does approximately that.
<Lo-lan-do> Except it behaves as a shell, with extra (or overridden) commands such as status, merge, cat, info, nick and so on.
<siretart> is your script for package maintenance?
<Lo-lan-do> More or less.  I use it to prepare packages of patched apps for clients.
<siretart> hm. in that case, you could perhaps add some more magic into the bzr-builddeb plugin
<Lo-lan-do> I'd rather keep it generic.
<Lo-lan-do> I mean, the patches I do are not Debian-related, they just happen to be on source trees that will eventually be turned into debs.
<thrope> is there any documentation for bzr-svn? I have having trouble finding anything except the faw
<thrope> also is there any way to get a graphical log like hg glog? (I am just trying out dvcs and found that quite helpful)
<Lo-lan-do> Besides, I would honestly prefer keeping my shell script and have it run faster :-)
<Lo-lan-do> thrope: bzr viz, in the gtk plugin
<Lo-lan-do> As for bzr-svn, it's supposed to be "transparent"
<thrope> Lo-lan-do: ah - how to i 'activate' the plugin (I installed it but get error with bzr viz)
<thrope> Lo-lan-do: for bzr-svn it is owkring ok but I expect bzr push to update the svn repository but it said no location known
<bob2> bzr push svn//url
<thrope> oh - it won't store it anywhere?
<bob2> push doesn't default the url the branch was branched from
<bob2> it will once you specify it once
<thrope> oh
<thrope> right
<bob2> (this is a debated feature)
<Lo-lan-do> I use a checkout (bound branch) for that.
<Lo-lan-do> But that's nothing to do with svn :-)
<thrope> any idea what this means? http://pastebin.com/m646013ae
<thrope> and how can I activate bzr viz?
<bob2> you don't activate plugins
<bob2> just install them
<bob2> (ie put or symlink the dir into ~/.bazaar/plugins)
<thrope> ah - i thought it was in bzrtools package but its in bzr-gtk... I'm on a mac so it's kind of a pain to install all of gtk - is there no console tool?
<thrope> re: the error - when I try and rebase it says "no revisions to rebase"
<bob2> did you find the bz-svn page on the wiki?
<thrope> bob2: yes but it doesn't have much info - just about installation
<awilkins> bzr-curses might be welcomed by some, I suppose
<awilkins> How about qbzr, thrope?
<awilkins> Is Qt4 hard to get on Mac?
<awilkins> qlog is arguably much nicer than viz
<thrope> its easy enough to get stuff through macports - it just takes ages to compile
<Verterok> heya
<awilkins> Isn't there a mpkg for qt though ?
 * awilkins has no mac
<Verterok> thrope: there is no need to compile Qt4
<thrope> anyway it doesn't really matter if I can't use it with svn - I'm just playing to try it out but can't seem to commit anyc hanges made in bazaar to a svn repo
<thrope> no one has any idea what that error means?
<awilkins> jelmer is the expert
<thrope> i just made a toy repo for testing - checked out in bazaar, made some changes, meanwhile made some changes in svn and commited - and now I'm stuck
<awilkins> I think it's probably the "toy" nature of the repo - is all the content in the root?
<awilkins> I think it works best with a project/trunk;tags;branches layout
<thrope> yeah
<thrope> all content in root
<Verterok> thrope: did you tried with dpush?
<thrope> no - what is dpush
<thrope> rats i just deleted the dir to try with trunk/tags/branch etc
 * Verterok is not an bzr-svn expert :)
<Verterok> thrope: a command provided by vzr-svn
<Verterok> bzr-svn
<quicksilver> Would be nice if you could re-merge into an uncommited merge
<quicksilver> (to merge another revision)
<thrope> seemed to work now - don't know what went wrong the first time
<thrope> maybe it was being the root of the repo
<seb_kuzminsky> what did i just do to my svn repo...
<seb_kuzminsky> i'm using bzr, bzr-svn, and loom, all on intrepid
<seb_kuzminsky> i've branched a big svn repo into a local bzr repo
<seb_kuzminsky> i loomified my local branch and hacked for a while
<seb_kuzminsky> meanwhile others were committing to the svn repo
<seb_kuzminsky> finally i went down to my bottom thread and ran bzr pull to get their commits
<seb_kuzminsky> then i went up on thread, and it showed all their commits as M - modified files (ie, it looks like a merge, not a pull)
<seb_kuzminsky> i committed in the next-to-bottom thread and pushed....
<rockstar> seb_kuzminsky, yea, so you'll have to merge those into your thread.
<seb_kuzminsky> now when i look at the svn repo (with the svn program, not bzr), it looks like all the other peoples' commits are gone, and instead is the merge i did in my thread...
<seb_kuzminsky> all their commits replaced by one commit of mine, with the log message "merge"...
<seb_kuzminsky> svn thinks /trunk got replaced (svn log shows "R /trunk") at the place where my first thread-commit went in
<seb_kuzminsky> guess i'll open a bug report
<bpierre> hi
<lifeless> jelmer: there is a thread on list you should read :P - 'lost commits in our repo' (its bzr-svn w/ bzr-loom)
<seb_kuzminsky> i'm the OP on that thread, i'm here and i can answer questions about the problem for the next few minutes before i have to leave
<seb_kuzminsky> lifeless: you didnt think you were rid of me did you :-P
<lifeless> seb_kuzminsky: I hoped not :>
<lifeless> jam: btw the pyrex iter_changes merge blocks the other too
<lifeless> s/too/two/
<lifeless> jam: do you want to review the __next__, or would you rather I nag someone to review that part?
<jam> lifeless: yeah, I know that. I just got to the easy ones. My son has an ear infection so I got little sleep and I'm maybe 50% time working today
<jam> depends when he sleeps
<jam> I do have it on my TODO
<lifeless> jam: thanks; I'm not meaning to pressure, just didn't want to be nagged about the approved ones either :P
<jam> spiv: if you are interested, my personal vote on "thing to do next" is "bzr up" over bzr+ssh. Even when it is a no-op it takes like 10s here to Launchpad.
<jam> which is a bit of a pain for the packaging. It could just be LP handshaking being slow
<jam> uh-oh.... something we did recently broke "bzr revert" on win32
<jam> I now *always* get "Could not acquire lock"
<jam> And I can't reallly revert to find out when that happened :)
<AfC> jam: not to worry. There's always reformatting the drive... :)
<jam> AfC: I have about 10 copies of bzr on this machine, I can just switch :)
<jam> not to mention "bzr branch" still works
<jam> just odd
<jam> ok, weird. Doing plain "bzr revert" fails, but "bzr revert -r -1" works, at least that gives me somewhere to point to
<lifeless> jam: bet you its taking out a lock earlier
<jam> luks: It seems to be your fault :)
<jam> lifeless: yeah, rev 3733: fix bzr st -rbranch:path-to-branch (Lukas Lalinsky)
<spm> is there a way to do a 'bzr cp'? Like 'bzr mv', but end up with two files that at some point in history were one?
<lifeless> spm: 'bzr branch'
<jam> lifeless: the problem is that "bzr revert" no args, is not using "tree.basis_tree()" and probably that is a DirStateRevisionTree, which is then getting ".lock_read()"
<lifeless> spm: (no, its a desired feature, see under TIME)
<jam> before the actual working tree is getting .lock_write()
<spm> lifeless: ta (again :-) ). isn't a major issue, but would have been a nice touch of sugar.
<AfC> spm: I ran into wanting that not too long ago myself.
<jam> lifeless: best help ever: http://docs.python.org/dist/module-distutils.extension.html
<jam> So much information there, I don't know what to do :)
<lifeless> jam: :>
<lifeless> jam: what are you working on?
<abadger1999> jam: If you're not being sarcastic, that would make that the only distutils page that's helpful :-)
 * abadger1999 is migrating all his code to paver
<jam> abadger1999: considering it is a single line of documentation, I'm probably being sarcastic :)
<jam> lifeless: I'm trying to review your patch, and I figured getting it *compiling* on win32 might be a good first step
<AfC> Compile-driven development. It's the latest vogue in testing.
<abadger1999> heh.  That figures
<lifeless> jam: sweet
<jam> AfC: there are some that feel if your code is statically typed enough, compiling *is* correctness :)
<lifeless> they are wrong :P
<jam> typedef one int; typedef two int; ...
<jam> :)
<poolie> hello all
<jam> Isn't  Verterok == Guillermo Gonzales?
<jam> I'm trying to answer https://answers.edge.launchpad.net/bzr/+question/46326
<lifeless> jam: yes
<jam> And ISTR that it was supposed to be fixed in xmloutput
<jam> poolie: morning
#bzr 2008-09-26
<lifeless> jam: also new patch; btree refactoring that was needed in pack repo
<lifeless> poolie: slugging?
<abadger1999> When branching from launchpad, does one have to have a launchpad account?
<mwhudson> nope
<mwhudson> the branches are accessible over plain old http
<abadger1999> I keep getting a permission denied error.
<abadger1999> Ah.
<abadger1999> Okay, how do I translate the lp:BRANCH URL to an http URL?
<lifeless> abadger1999: private branches require a lp login
<lifeless> abadger1999: because access control
<abadger1999> lifeless: How do I tell if they're private?
<mwhudson> abadger1999: what are you actually doing?
<abadger1999> https://code.launchpad.net/trac-bzr
<abadger1999> I'm updating the Fedora package.
<mwhudson> abadger1999: as in, pastebin
<abadger1999> And I'm writing instructions for other people to retrieve the branch in case they need to verify that what I packaged is what's upstream.
<abadger1999> So I just need to figure out how to tell them to retrieve: "bzr branch lp:trac-bzr"
<mwhudson> that should work for you
<abadger1999> mwhudson:  ahh.... Thanks!  I see my error now.
<abadger1999> I do have a launchpad account registered in bazaar.conf
<abadger1999> But I've changed my ssh key since it was registered.
<abadger1999> So I was assuming lp: was erroring because I was anonymous but it was really because my ssh key didn't match.
<mwhudson> ah
<lifeless> spiv: sorry for death-by-a-thousand-replies
<lifeless> spiv: also I think you might benefit if you think about hooks a little differently;
<markh> jelmer: ?
<lifeless> spiv: because they are intended to allow plugins to add actions, they -by definition- cannot operate on a per-hooked-thing basis
<lifeless> spiv: rather they look like C-object-style with object as the first parameter;
<lifeless> spiv: as such, its _never_ right to add a hook function just-for-one-instance; instead its always add-hook-thunk, which acts-when-appropriate
<spiv> lifeless: yeah.  That's why I had the alternative implementation that did just that.  But it seemed more complicated in this instance.
<spiv> Hmm.
<lifeless> spiv: WeakKeyDictionary FTW ?
<lifeless> spiv: surely thats all you need
<spiv> The problem is that WeakKeyDictionary just silently drops the entry when the ref goes away.
<spiv> I just had an idea.
<spiv> I *might* be able to get away with using a WKD + my own weakref, so that the callback on my weakref can retrieve the value out of the WKD before it goes away.
<lifeless> subclass ReferenceType
<spiv> (Weakref callbacks are guaranteed to be called in reverse order of weakref creation)
<spiv> Right, I can do that too.  But again that's significantly more complicated.
<lifeless> k
<spiv> I'm willing to add the complexity if people think its worth it, but I thought that it would be best to try the simplest approach first.
<lifeless> I think fitting the pattern hooks are designed around is simpler
<spiv> It is frustrating that WKD is so close to what I need, but not quite there.
<lifeless> the thing that is unique in this case is wanting a 'done with' event
<lifeless> and I think it would be easier for you if you had a 'done with medium' hook :P
<spiv> Heh.
<spiv> It would be.  Any suggestions on how to implement that easily? :)
<lifeless> add a __del__ to Medium
<spiv> It already has one.
<lifeless> add a hook that triggers during del
<lifeless> with a signature of (weakref(hook))
<spiv> I'm not sure why I haven't tried using that __del__, actually.
<lifeless> (so that we aren't adding refs to the hook accidentally)
<lifeless> spiv: this is I think why I mentioned /thinking/ about hooks differently
<spiv> Well, I already did try thinking that way.
<spiv> As I hope the alternative patch in my original mail shows :)
<lifeless> spiv: sure, I think I'm expressing myself badly
<lifeless> I just mean that it seemeed simpler to you to try and work against the current
<lifeless> which suggests you haven't quite internalised the reasons behind the stream
<lifeless> [to me]
<lifeless> aaaanyhow, I'll stop blathering and let you get on with it;
<spiv> Well, I don't think so.  I just failed to see a nice way for a single hook function to find the right medium to associate with when using weakrefs.  That didn't mean there wasn't, just that I didn't find one yesterday afternoon.
<lifeless> spiv: isn't the hook called  with the medium ?
<spiv> I definitely appreciate that it's not so nice to have lots of hook function registrations.
<spiv> It is, but I was keeping weakrefs in the counter object to keep the impact as obviously minimal as possible.
<spiv> And WKD is unfortunately nearly but not quite what I needed...
<lifeless> a hook even on del would do it, and will trigger when the WKD will too
<spiv> Yeah, seeing as there's already a __del__ I think I may as well use that.
<spiv> If there wasn't already a __del__, I think weakrefs would be the way to go.
<markh> jam:?
<jam> markh: yes?
<markh> I notice the 1.7 branch is labeled as 1.7.1rc1 - should I just skip a 1.7final?
<markh> or jump back a rev or 2
<markh> (maybe I should be using a tag on that branch?  I haven't looked I admit...)
<jam> markh: We need to do a 1.7-final
<jam> you can either use the tarball
<jam> or use rev 3705
<markh> ok, will do.  When do you expect 1.7.1 final?
<markh> heh - so, how do I force a branch *back* a revision?  Using -rfoo when the current rev is greater than foo doesn't seem to do anything?
<fullermd> What -rfoo?  pull works...
<lifeless> markh: uncommit
<lifeless> markh: or pull -rfoo --overwrite
<markh> lifeless: I just thought of override as you said it - sorry for the noise!
<markh> overwrite too :)
<lifeless> wow
<lifeless> bzr heads -> 1.6GB used
<fullermd> 1.6 billion heads are better than one.
<lifeless> eeepic fail
<lifeless> I think its the svn-branch-open-leak-fail
<lifeless> jelmer: is that fixed?
<jam> lifeless: so generally, I think there is a lot of cleanup we *could* do, and some discussion to be had. But we can do that after it lands.
<lifeless> jam: 'it' ?
<jam> lifeless: iter_changes in pyrex
<lifeless> ah yes
<lifeless> I want to make it much smaller and more many-function clean
<spiv> Oh right, the __del__ isn't on SmartClientMedium, just one of its subclasses.  I'll see if I can workaround WKD's deficiency...
<lifeless> super(self, Class).__del__()
<lifeless> ?
<jam> markh: well for making a release, you are probably fine to do "bzr revert -r -2" make foo; bzr revert ; make foo
<jam> and build both the 1.7-final and 1.7.1rc1
<jam> lifeless: I'm pretty sure it is super(Class, self).__del__() :)
<spiv> lifeless: I really don't want to add __del__ to objects that don't already have them
<lifeless> jam: MEH, DETAILS
<lifeless> sorry for shoutig
<spiv> lifeless: that would mean the debug option would be penalising things even when not used.
<markh> jam: ah, thanks.  As it turns out I've built 1.7.1rc1 first, but that should be fine as it stands.  I've build 1.7 and will testing that now...
<jam> spiv:  so as always, can we push the __del__ into an attribute other than self, to avoid circlese
<lifeless> spiv: sometimes its the right thing to do though
<spiv> jam: or, just use weakrefs :)
<jam> I wasn't following closely, just poking at __del__
<lifeless> jam: oh bugger
<lifeless> jam: guess what I just did
<jam> ?
<jam> found a problem, or submitted your version?
<lifeless> submitted la version robert
<lifeless> and then took a shower, so its well and truely in progress
<jam> np, we can always submit another one :)
<lifeless> do you want to queue yours up now ?
<jam> sure
<jam> you didn't do any other changes?
<lifeless> nup
<lifeless> spiv: is there a way to tell RemoteRepositoryFormat to create a specific backend format ?
<spiv> lifeless: I think if you pass something other than a RemoteBzrDir to RemoteRepositoryFormat.initialize it might work.
<lifeless> I'm trying to test RemoteRepository with a chk_bytes supporting backend
<spiv> I don't think we have many tests of RemoteRepo on top of specific backends.  The ones we do have probably all do it by making the backend repo directly, then re-opening that via a SmartTCPServer_for_testing.
<lifeless> +class TestCaseWithRepositoryCHK(TestCaseWithRepository):
<lifeless> +
<lifeless> +    def make_repository(self, path):
<lifeless> +        TestCaseWithRepository.make_repository(self, path)
<lifeless> +        return repository.Repository.open(self.get_transport(path).base)
<lifeless> that works, ilttle fuglay
<lifeless> http://spooky-possum.org/cgi-bin/pyblosxom.cgi/harmless.html
<markh> hrm - 'bzr selftest' has 41 threads running for me!
<markh> make that 72 :)
<markh> eek - and counting - just crashed through 300!
<markh> 500!  How much can vista on a vm handle!
<mwhudson> 'running' in a very loose sense i think
<markh> yeah
<markh> 1/2GB ram, 6000 handles open...
<lifeless> markh: well it is *testing* :P
<lifeless> jam: this is wrong/missing:
<lifeless> # source_branch: http://bzr.arbash-meinel.com/branches/bzr/1.8-\
<lifeless> #   dev/trivial_python_compat
<lifeless> anyone around for a quick irc teddy bear session
 * beuno tries to resist asking what that would be
<AfC> I just used Google's image search on "IRC teddy bear" and got http://images.villagevoice.com/issues/0521/expo-011s.jpg Something is clearly wrong with the world.
<mwhudson> AfC: i need a drink now
<fullermd> And a cigarette.
<mwhudson> (possibly i needed a drink already, before clicking that link, mind)
<fullermd> Possibly you had a drink already, if you're clicking links AfC pastes with disturbing prose around them   :p
<kgoetz> i'm thinking this image may not be good to clik at work
<AfC> I figured I had done my part to make it clear that the aforementioned link was for mature audiences only. That said, the real question is what Robert is doing looking for an IRC teddy bear. Fascinating, really.
<beuno> and why he would need someone else...
<fullermd> I was going to say I myself could use an IRC piggy bank, but I figured I should google it first, just to be safe.
<fullermd> And somehow I end up with http://gadgets.boingboing.net/2008/06/19/bandai-ikemenbank-pi.html
 * fullermd boggles.
 * beuno wonders if google substitute "IRC" for something kinky internally
<fullermd> Well, I still sometimes end up with 'International Reply Coupon' on my first acronym-fault...
<lifeless> AfC: when designing things its often easier to discuss it with someone
<lifeless> AfC: they are a teddy bear, if they are not needed for content so much as for the fact-of-discussion
<lifeless> AfC: and being on IRC was well, being on IRC :P
<fullermd> Well, way to make it boring in comparison   :p
<fullermd> Here we were, picturing stuffed animals engaging in all sorts of bazaar acts...
<jml> lifeless: it's also called "rubber ducking" sometimes.
<lifeless> jml: thats so much more open to misinterpretation
<lifeless> jml: it has rubber, and water sports, and its fowl
<jml> quick! get me my pun glasses!
<lifeless> fingers crossed, all my status work will have landed in 30 minutes or so
<vila> hi all !
<lifeless> yay, status stuf landed
<lifeless> have a good weekend all
<fullermd> Weekend indeed...  it's only an hour into Friday   :p
<beuno> you too lifeless
 * beuno is happy to be on the other side for once
<poolie> hi
<poolie> night lifeless
<poolie> abentley: bb is down :-/
<abentley> poolie: restarted
<vila> abentley: which one ? :D
<vila> abentley: joke aside, I playfully thought about multiple BB instances... interesting problem (not worth the trouble though)
<poolie> oh, thanks!
<poolie> hi vila, abentley
<poolie> vila, that was a 'tweak' overall for the 2.6 stuff
<vila> ha, ok, hmm, I'm checking a bit more but I see your points and will merge most of it (at least)
<vila> I've checked that Exception.message has indeed be deprecated, that leave only the unicode stuff
<tvainika> what means format: unnamed in bzr info? e.g. I create bzr init-repo --1.6.1-rich-root and then branch or checkout under it, then shared repo shows format: 1.6.1-rich-root, but branch under it format: unnamed.
<spiv> tvainika: it means bzr doesn't have a short label for the combination of branch format & repo format you have.  "bzr info -v" will tell you more.
<spiv> tvainika: "unnamed" isn't very helpful.  There's a bug filed about that: https://bugs.launchpad.net/bzr/+bug/202083
<ubottu> Launchpad bug 202083 in bzr "need better short names for format combinations" [Undecided,New]
<jonnydee> bzr revert returns with      bzr: ERROR: Could not acquire lock "D:/duscher/docs/ProjektM/dev/.bzr/checkout/dirstate"
<jonnydee>  i am using bzr.dev newest version and I rebooted my computer to make sure there is no system lock....
<awilkins> jonnydee: I think that's either been fixed or I saw a patch in the pipe that fixes it
 * awilkins wonders if anyone else but him uses msvc 7.1 to build the extensions
<jonnydee1> awilkins: ok, so until now the fix seems not to be in bzr.dev because I did an update of my bazaar installation right before I tried to revert... So I hope the patch comes soon, thanx :)
<awilkins> jonnydee1: I think it's http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C48DC0B60.4010201%40arbash-meinel.com%3E
<awilkins> So if you do a bzr merge http://bundlebuggy.aaronbentley.com/download_patch/%3C48DC0B60.4010201@arbash-meinel.com%3E  to your bzr.dev, maybe it will fix it :-)
<asabil> is there a way to cherry-pick commits between branches ?
<james_w> asabil: bzr merge -rx..y ../other-branch
<asabil> well, real cherry picking with merge tracking
<asabil> and commit message preservation
<luks> bzr replay -rx..y ../other-branch for the second point
<abadger1999> I'm looking at a bug in the trac-bzr plugin and have a question.
<abadger1999> bzr's  NEWS file says that _get_weave() was deprecated in favour of RevisionTree.plan_merge().
<abadger1999> But there is no plan_merge() in Tree.
<abadger1999> Does the document mean: One of these: 'plan_file_lca_merge', 'plan_file_merge' ?
<abadger1999> Or does it mean VersionedFile.plan_merge() ?
<abadger1999> Looks like I'm working on https://bugs.launchpad.net/trac-bzr/+bug/263300
<ubottu> Launchpad bug 263300 in trac-bzr "Does not work with bzr 1.6" [Undecided,New]
<Okkin> hi
<Okkin> how can I generate a patch (like the send command) unsing directly bzrlib ?
<Odd_Bloke> Okkin: Do you want a patch or a bundle?
<Odd_Bloke> jelmer: How do you keep track of what API breaks are going on in bzrlib that might affect you?
<Odd_Bloke> Okkin: i.e., are you looking to generate a patch, or do you want to be able to merge from the produced output?
<Okkin> Odd_Bloke: a blundle
<Okkin> sorry
<Okkin> i want to merge the result in a remote branch that is only accessible by email
<Odd_Bloke> Okkin: Then I'd suggest looking at the code for the send command. :)
<Okkin> that want i was doing in fact :)
<Okkin> but I'm lazzy on friday
<Odd_Bloke> Okkin: Well, that's what most of us would have to do to help you, and it's Friday for us as well. ;)
<Okkin> Odd_Bloke :)
<Okkin> I understand so well the friday laziness
<Odd_Bloke> sabdfl had a sudden posting spree to the bzr list about 16 hours ago.
<LarstiQ> Odd_Bloke: read NEWS?
<Odd_Bloke> LarstiQ: Sure, but at what point?
<Odd_Bloke> Because presumably he's going to want to have made the changes before the release containing said NEWS.
<LarstiQ> Odd_Bloke: right
<LarstiQ> Odd_Bloke: pull bzr.dev from point to point and read NEWS? :)
 * LarstiQ heads off
<Odd_Bloke> LarstiQ: Yeah, I'm wondering how that could be improved.
<Odd_Bloke> Or, rather, if it needs to be.
<resolve> hi folks. i've been using mercurial for the last year, and i was using bzr and arch before that
<resolve> since a year has passed i've decided to survey the field again
<Odd_Bloke> resolve: Hi. :)
<resolve> i've been very happy with mercurial - generally it did what i wanted without trouble
<resolve> but bzr seems to have made decent progress recently, and the ability to use launchpad does seem nice
<resolve> any of you here switched to/from bzr from mercurial?
<resolve> has 1.7 made any changes related to the repo blowout on http://vcscompare.blogspot.com/2008/06/git-mercurial-bazaar-repository-size.html ?
<Odd_Bloke> resolve: I'm not sure about 1.7, but there are some improvements of that ilk in the pipeline.
<Odd_Bloke> In the development{1,2} formats.
<Odd_Bloke> 1.7 may have included development1, I'm not sure...
<vila> la la la, pqm blocked
<vila> :-/
<vila> any LOSA around ?
<vila> jam: pqm is blocked on a successful merge, once again :-/ I hate leaving for week-end like that, could find a LOSA and kill the offending (ssh ?) process (worked well the las timeS it occured)
<vila> s/could/could you/
<vila> pqm has been updated to bzr-1.6.1 (AFAIK) in the hope it will fix the problem. It doesn't apparently
<jam> vila: what I want to know, is why does it always happen with *your* branches? :)
<vila> Shooting in the dark again but: it looks like I'm the only one triggering this
<vila> My only guess is that it happens with branches "freshly" pushed on lp
<jam> maybe because you are using 'lp:' ? just a guess
<jam> I always use my own
<jam> still, it doesn't make a lot of sense
<vila> that too but that a bit short as a diagnosis :-/
<jam> since it isn't failing to *merge* it is failing to commit
<vila> yeah
<vila> not even failing
<vila> the commit succeeds even when the process is killed, something else should block...
<ignas> what do I do with "bzr: ERROR: [Errno 17] File exists" ?
<james_w> if you use lp: and PQM has a launchpad login then it will use ssh, presumably everyone else will submit with http?
<james_w> ignas: during what operation?
<ignas> james_w: bzr ci
<james_w> ignas: running again with -Derror will give some clue as to what is going on
<ignas> james_w: where do you want your traceback?
<james_w> ignas: my guess is https://bugs.launchpad.net/bzr/+bug/242510
<ubottu> Launchpad bug 242510 in bzr "Pack already exists when pushing/autopacking" [High,Fix committed]
<james_w> ah, no, wrong message I guess
<james_w> ignas: paste.ubuntu.com or anywhere similar is fine
<james_w> not pastebin.ca
<ignas> james_w: http://paste.ubuntu.com/50932/
<james_w> wow, that's an odd one
<james_w> I guess you're not running bzr.dev?
<ignas> nope
<ignas> Bazaar (bzr) 1.7.1rc1
<ignas> james_w: i have a dev version
<ignas> i can try using it
<ignas> when i'll bzr pull it
<james_w> it seems like one of opendir, readdir or closedir are returning "File exists"
<james_w> The man pages don't say that that will happen though
<james_w> I'm stumped
<james_w> ignas: please file a bg
<ignas> https://bugs.launchpad.net/bzr/+bug/274875
<ubottu> Launchpad bug 274875 in bzr "Unexpected File exists error when trying to commit" [Undecided,New]
<ignas> ouch
<ignas> branched the branch locally
<ignas> and tried committing the same changes
<ignas> it failed with the same error
<abadger1999> Anyone here use bzr commit --fixes ?
<ignas> yep, i can't commit into any of the branches in that shared repository
<ignas> and I really do not like it...
<ignas> frankly - it is preventing me from working :/
<abadger1999> I'm wondering what the syntax is for marking a bug fixed in launchpad... --fixes 1234 OR --fixes lp:1234 OR ....
<ignas> ok, i can't do any bzr commits on my machine...
<ignas> ok, I can with bzr.dev
<ignas> hmm, i will recompile bzr.dev and see then
<ignas> yep, still works
<james_w> abadger1999: the latter
<abadger1999> james_w: Excellent.  Thanks
<ignas> so bzr.dev works, bzr 1.7.1rc1 packages from PPA - don't
<Peng_> Augh, what big new thing landed in bzr.dev that's making pulling it so slow? :(
<barry> hi folks, bzrtools is driving me crazy
<barry> i have this in my sources.list: http://ppa.launchpad.net/bzr-beta-ppa/ubuntu hardy main
<barry> but bzrtools is always getting out of sync.  either it's too old, or if i branch lp:bzrtools, it's too new
<abadger1999> barry: Switch to Fedora :-)
<barry> how am i supposed to keep these in sync?!
<barry> abadger1999: yeah, not actually an option :)
<abadger1999> barry: There was just a discussion about this on the bazaar mailing list.
 * abadger1999 looks for URL
<Peng_> barry: My solution is to run from source. :|
<barry> Peng_: i might have to do that :/
<abadger1999> The devs uploading the ppas came up with a plan to "do better" about keeping them in sync.
<barry> abadger1999: cool.  at least they're aware of the problem.  i need to figure out something to get my bzr shelve back now, but i'll install from src if i have to for the short term
<abadger1999> barry: Here's where the thread starts: https://lists.ubuntu.com/archives/bazaar/2008q3/047810.html
<barry> abadger1999: thanks
<abadger1999> barry: No problem.  I think bzr should change it's release practices to make this better for everyone but... I'm only a distro packager and occassional bug fixer so I don't have much clout.
<barry> abadger1999: i see that shelve is a candidate for pulling into the core.  that's the one that always kills me, so that would benice
<abadger1999> <nod>
<abadger1999> barry: My problem as a packager is that we get into situations where one set of plugins only works with an older version of bzr.
<abadger1999> Meanwhile other users want to have the newer bzr because someone they work with has upgraded their repository to an incompatible version.
<barry> abadger1999: i don't envy packagers jobs at all! y'all do a great job with a tough problem
<abadger1999> heh.
<abadger1999> barry: Were you at PyCon and attended the BoF on packaging?
<barry> i was!
<barry> abadger1999: you too?  /me looks at abadger1999's info
<abadger1999> barry: Yep. I'm toshio, the skinny Fedora guy :-)
<barry> :)
<barry> nice to see you here
<abadger1999> likewise :-)
<barry> abadger1999: i see a lot of traffic on the distutils-sig.  i have no time to keep up with it, but how do you think it's going w.r.t. distro needs?
<abadger1999> barry: I'm sad to say I haven't been able to keep up with it either.
<abadger1999> barry: when I take a look at the code, it doesn't look like there's much going on.
 * barry perfects his clonebot
<abadger1999> But there might be discussion that just hasn't been implemented yet.
<barry> abadger1999: lots of grand ideas
<abadger1999> Right.
<barry> at least they're getting phillip involved.  sometimes guilt is the best motivating factor in floss (it's worked on me *many* times :)
<abadger1999> Yeah.  That is good.
<abadger1999> I've been migrating some build scripts over to paver recently.  That seems to fit the distro packagers needs a lot better than vanilla setuptools
<barry> i'm not familiar with paver
<abadger1999> http://www.blueskyonmars.com/projects/paver/
<abadger1999> It's something like a make/setuptools cross.
<barry> neat: kevin dangoor
<abadger1999> It imports distutils (and setuptools if available) so you can have those commands if you want them.
 * barry bookmarks
<abadger1999> But it allows you to define custom tasks easily.
<barry> sort of like a cleaner scons?
<abadger1999> And add more declarative information.
<abadger1999> I haven't actually used scons.
<barry> i built a huge system with scons in my previous job.  nicely modular, but the hard things were *really* hard
<jam> barry: I just synced bzrtools into bzr-ppa
<jam> Mak esure you have both
<jam> I'm going to try and keep them in sync more
<barry> jam: cool, thanks! i think the thing was i was using bzr-beta-ppa
<jam> barry: it doesn't usually have "beta" releases, and it always wants tobe in lock-step...
<barry> which didn't have bzrtools
<jam> you can probably use both
<abadger1999> hmm... Yeah.  paver aims to make things always easy.
<NfNitLoop> so Ubuntu is trying to upgrade bzr and bzr-svn, but is complaining that they can't be authenticated?   Anyone know what might be up w/ that?
<barry> jam: awesome, thanks
<barry> abadger1999: i'm really looking for something better for mm3 development, than just setup.py develop
<NfNitLoop> it also looks like the "upgrade" verison is the same as the one that's installed, but I'll ask about that in #ubuntu. :p
<barry> abadger1999: but virtualenv just doesn't DTRT for me
<barry> abadger1999: thanks for the paver link
<abadger1999> barry: Cool.  Keep in touch because I'm very interested in this too.
<barry> abadger1999: definitely!
<barry> gotta run.  thanks everyone!
<vila> jam: No LOSA around ? :-/
<jam> nobody has responded
<vila> jam: thks
<jam> it is friday night after all
 * vila remembers his first *day* as intern: 'del library member', damn that's long, hey tutor, why so long ? EEEEEEEEERK Of course you have backup tutor ? And why the 'del' command doesn't check its arguments before running ?
<herb> .win 11
<vila> pfff, dos was just a child in those days :) No the system name was Pick or something and the script language 'English', it was supposed to be natural (like real people the script was ignoring what it didn't understand :-D )
<vila> Well, I did my best to summon fullermd, but that should really be friday night :)
<bpierre> hi
<jam> vila: well, mthaddon was nice enough to restart it
<vila> yeah for mthaddon !
<vila> yeah for jam !
<vila> :)
<jam> vila: you may need to resubmit your patch
<jam> or *not* for now :)
<vila> hehe, yeah, I'll left pqm alone for the week-end ;-)
<guilhembi> jam: hi! please, what's the status of "put merge_lca_multi into bzr.dev" ?
<jam> guilhembi: 1.7.1rc1 is out and in ~bzr-beta-ppa
<jam> I need to merge it back, though the pqm was wedged for a bit
<guilhembi> jam: uh, merge it back... to where?
<jam> guilhembi: it is in the 1.7 branch, I need to merge that into bzr.dev
<guilhembi> jam: 1.7.1rc1 is out? where (bazaar-vcs.org only mentions 1.7) ?
<jam> it is available at https://launchpad.net/bzr/1.7/1.7.1rc1 I just need to update the other pages
* jam changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | bzr-1.7 now available! please test bzr-1.7.1rc1 |  http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
<abadger1999> Any people here who use looms?
<abadger1999> I'm wondering if they solve my problem or not.
<abadger1999> I have a sequence of patches. and I want to be able to get them in two forms:
<abadger1999> 1) Independent patches against the base revision.  These would be suitable for sending to upstream if I have no idea of the order that upstream is going to take the patches in.
<abadger1999> 2) A sequence of patches against revision.  These patches would be suitable for applying when creating a distribution package.
<abadger1999> I know how to do #2 using separate branches.
<abadger1999> I'm not sure how to do either one using looms.
<james_w> abadger1999: looms naturally satisfies number 2
<abadger1999> james_w: Excellent.  How do I convert the threads into the patches I need?
<abadger1999> Is it a semi-manual process?
<james_w> abadger1999: export-loom I think is the command
<abadger1999> james_w: hmm... Okay. That gets me from loom to branches.
<james_w> maybe the command you want doesn't exist yet then
<james_w> I would like the same command as you, so I'll write it one day :-)
<abadger1999> :-)
<abadger1999> Ah.  Okay for #2 this will work:
<abadger1999> bzr diff -r thread:lp:trac-bzr..thread:no-repo
<abadger1999> bzr diff -r thread:no-repo..thread:get-ancestry
<abadger1999> Generates two patches with the changes stacked on top of each other.
<abadger1999> I foresee #1 being harder to achieve.
<james_w> is there another revisionspec provided?
<abadger1999> Yeah.
<james_w> below: or something
<james_w> -r below:thread:no-repo..thread:no-repo or something
<abadger1999> Hmm... It's not in the documentation
<james_w> easier to code
<james_w> ah, maybe it's just one of those imagined features
<abadger1999> Yep.  Looks like a not yet implemented
<abadger1999> Ah.. thread:
<abadger1999> nothing after thread: selects the thread below the current one.
<james_w> hmm, doesn't help getting the thread below the one below easily though
<abadger1999> heh... down-thread functions as a 'set-thread' command if a thread name is given
<abadger1999> but up-thread does not.
<abadger1999> So.. alternate commands would be bzr down-thread lp:trac-bzr ; bzr up-thread ; bzr diff -r thread: ; bzr up-thread ; bzr diff -r thread:
<Odd_Bloke> Any thoughts on what might be causing http://rafb.net/p/AhoLJv69.html?
<Odd_Bloke> Hmm, http://mail.python.org/pipermail/distutils-sig/2007-May/007600.html may contain the answer.
<abadger1999> Hmmm... anyone tried running loggerhead via mod_wsgi?
<MapMan> hey guys, you know what's causing the RMB menu to disappear for no reason? Im talking about win32 bzr
<Odd_Bloke> MapMan: Do you mean TortoiseBZR?
<MapMan> yeah
<Odd_Bloke> MapMan: markh is your guy for that.
<Odd_Bloke> He's probably not around, as it's the weekend.
<Odd_Bloke> I'm afraid I have no idea how to diagnose a TBZR problem. :(
<MapMan> too bad
<MapMan> it happens from time to time to me and friends
<MapMan> and adding files manually takes more time... Especially explaining friends on how to do that.
<MapMan> manually = from command line
<markh> MapMan: please check .bzr.log - you might find a traceback there.  It might say something about "would recurse to death" which is a problem I'm aware of but can't repro
<MapMan> you're right markh, I got that in my log
<markh> cool - at least we don't have a *new* problem ;)
<MapMan> and it happens pretty often
<MapMan> maybe I need new py win32?
<MapMan> or smt
<markh> no - its a bug in tbzr
<markh> its something to do with the order things are requested.  I've seen it myself, but can't for the life of me make the test suite hit it
<markh> its frustrating, and its a priority now 1.7 is (almost) out
<MapMan> yeah, I realize it might be frustrating
<MapMan> good luck on fixing it man
<MapMan> doing good job on tbzr
<markh> thanks!
#bzr 2008-09-27
<rama> hi from Argentina, does anybody know how to make this post_commit hook for trac work? : https://trac.m0n5t3r.info/oss/wiki/BzrTracHook
 * awilkins needs sleep
<jam> markh: ping
<markh> jam: hi.  Let me guess - asking about binaries? :)  Launchpad is giving me grief :(
<jam> just curious
<jam> you mentioned you built them yesterday
<markh> "Sorry, there was a problem connecting to the Launchpad server. " - about 7 times now :(
<jam> ouch
<markh> last time I asked on #launchpad, the advice was basically "keep trying"!
<markh> this is *after* it spends 30 minutes doing the upload :(
<markh> MapMan: I meant to say: from the cmdline, consider doing 'bzr qadd' - that way you get the same GUI as TBZR, but can avoid that bug :)
<MapMan> thanks man
<jam> markh: is there somewhere else you could upload them?
<markh> yeah - lemme do that.
<jam> I don't know what resources you have available, but I would be happy to try to upload them if I could get to them.
<MapMan> markh: that helps a lot
<markh> This is only the second time I've struck this launchpad problem
<markh> MapMan: cool - many commands have a 'q' implementation - that is what tbzr uses under the covers.
<markh> bzr help will list them
<markh> err - bzr help commands
<MapMan> k
<MapMan> i figured that on my own
<jam> markh: I wonder if it happens because you are in AU, and something times out while uploading
<MapMan> qcommit etc.
<jam> You're uploading larger files than the rest of us, too
<MapMan> markh: ima make some bath files for my friends so they can access verything easily and quickly
<markh> jam: likely - maybe my isp struggling.  Everything else seems fine.  Last I asked on #launchpad though, others were having identical problems at the same time.  Who knows... :)
<markh> of course, now I have the l/p upload and the other upload competing the the bandwidth that does exist!  I'll wait though, as if I cancel the l/p upload, that then obviously would have turned out the be the one that worked :)
<poolie> hello
<poolie> hi markh, jam
<jam> morning poolie
<markh> hi poolie
<poolie> jam, should i merge bzr.1.7 back to trunk?
<poolie> guilhemb was just wonering why lca-shape-merge was not there yet
<jam> poolie: if you want, I'm planning on getting to it, but had about 4 other approved things that didn't get in yet
<jam> poolie: actually, I'm set up here, give me 2 secs and I'll submit it
<poolie> because of pqm delay?
<poolie> oh, ok, thanks,
<poolie> i'll reply to tell him so
<jam> I mentioned it to him on IRC. When do you want to release 1.7.1 final? Mon or Wed?
<poolie> somewhere in that range :)
<rama> hi people, i need help with post_push / post_commit hooks, anyone experienced could help? thx in advance
<rama> i'm trying this one: https://trac.m0n5t3r.info/oss/wiki/BzrTracHook but does not get run after i commit local and push to a remote ssh+bzr repo using versions 1.6 ... any clues?
<markh> jam: http://starship.python.net/crew/mhammond/bzr-setup-1.7-1.exe and ...asc - I'll do 1.7.1rc1 now
<poolie> rama sorry i need to got in a sec, can you post to the list or a question on launchpad.net/bzr
<poolie> markh, thanks!
<poolie> rama, are you sure the hook is configured to run for that push location?
<rama> i did setting it on ~/.bazaar/location.conf
<markh> (jam - obviously that means the launchpad upload failed yet again!  Not even bothering to try with 1.7.1)
<rama> poolie, i have this on my locations.conf: [/usr/local/bzr/vodo-net]
<rama> post_push = bzrlib.plugins.trac_hook.post_push_hook
<rama> post_commit = bzrlib.plugins.trac_hook.post_push_hook
<rama> where bzr is setup as a repo and vodo-net a branch
<poolie> markh, what happened with the launchpad upload?
<markh> last few days been getting an error from l/p after the upload saying there was trouble connecting.
<markh> happened once before and I asked in #launchpad, and they basically said "keep trying"
<poolie> :-/
<markh> so I did :)  last time it eventually worked after about 6 goes.
<poolie> that sucks, did you get an oops or something?
<poolie> or is there a bug?
<poolie> rama, i get an error loading that trac page atm
<jam> markh: uploading now
<markh> no oops - just a plain html message asking me to try again, or if it keep happening to ask on #launchpad
<markh> I even checked the html source for clues :)
<markh> (I've closed that tab now - jml helped me out on #launchpad last time)
<markh> s/few days/24 hours/ :)
<markh> and no other indications of network problems
<rama> poolie, strange, it opens here.. anyway, i've been fiddling with its code and found in fact it was done for bzr 0.15 and reading the doc on the site found how to adapt it
<rama> but it does get "registered" into bzr, despite not printing any sign of being run
<rama> i'm doing this:         install_named_hook('post_push', post_push_hook, 'trac_hook')
<rama> and post_post hook is the function to be called upon a post push on the remote bzr repo pushing from my box.. if i get it right
<markh> jam: bzr-setup-1.7.1rc1-1.exe and bzr-setup-1.7.1rc1-1.exe.asc there too.  Let me know when I can remove them
<alperkanat> hey there... i want to use bzr for my project but i already have 61 revisions in svn.... most of the migrators on bzr's site are for using svn through bzr... i just care about the history.. is there a doc for this ?
<james_w> alperkanat: you can just do a "bzr branch" from svn and throw the svn away, or you could use something like bzr-fastimport to do a conversion
<james_w> they're pretty much equivalent
<alperkanat> james_w: but i have http authentication at the svn side...?
<jml> markh: did we end up filing a bug about that?
<james_w> alperkanat: hmm, I think that may work with bzr-svn, but I can't be sure, sorry.
<markh> jml: no - we just agreed it was transient - someone else was having the same problem at the same time too - then it worked for both of us, so we all forgot it :)
<jml> markh: :)
<jml> markh: for things like this, it's good to ask a question at https://answers.launchpad.net/launchpad/ -- it's easy enough to turn into a bug and means that people who *really* know what they're doing can answer it.
<jml> of course, asking on IRC is also wonderful
<jml> I speak mostly to remind myself :)
<markh> the error page specifically directs you to #launchpad :)  the error message is a very generic "sorry, something went wrong" page.
 * jml finds the page in the source code.
<jml> markh: actually, I'll have to follow this up later.
<markh> jml: no probs - its only the 2nd times it happend and jam is doing the upload for me - thanks tho!
<jml> np
<alperkanat> anyone here used svn2bzr before ?
<fullermd> I was under the impression that it was pretty much superceded by bzr-svn.
<alperkanat> pff i just don't want to lose the history of the svn repository.... and the documentation of all plugins are bad..
<alperkanat> :S
<james_w> alperkanat: bzr-svn won't lose any history
<alperkanat> james_w: i can't even make bzr-svn work
<alperkanat> james_w: make complains about compilation errors at the end.. and bzr co http://repo doesn't do anything :S
<james_w> probably because it didn't compile
<alperkanat> james_w: Make sure the directory name is 'svn'. => which directory does it mean for instance ?
<alperkanat> james_w: the directory i copy into the plugins or..?
<james_w> you want the bzr-svn plugin directory to be called "svn"
<james_w> e.g. ~/.bazaar/plugins/svn
<james_w> sorry I can't help you further, I must go to sleep now.
<alperkanat> ok thanks anyway
<alperkanat> any ideas for this error ? => bzr: ERROR: Invalid http response for http://svn.raptiye.org/raptiye/trunk/.bzr/branch-format: Unable to handle http code 500: Internal Server Error
<alperkanat> someone please ?
<Verterok> alperkanat: it seems that the server is using mod_svn or mod_dav, and can't serve the url (possibly it not exists)
<alperkanat> but there's no .bzr directory inside the repository ?
<Verterok> if it's a svn repository no
<alperkanat> Verterok: then how am i supposed the import the svn project into a bzr project ?
<alperkanat> s/the/to
<Verterok> alperkanat:  I assume you want to use bzr-svn to do that
<alperkanat> Verterok: yes
<alperkanat> Verterok: i just care about the history..
<Verterok> alperkanat: if you have bzr-svn installed, juts: bzr branch  http://svn.raptiye.org/raptiye/trunk
<Verterok> alperkanat:  to check if bzr-svn is installed, execute: bzr plugins -v
<alperkanat> Verterok: http://screencast.com/t/0xsL59q8a
<alperkanat> i didn't think it'd be this much painfull :(
<Verterok> alperkanat: it shouldn't
<Verterok> alperkanat: please try with: 'bzr -Derror branch' and pastebin the output
<Verterok> alperkanat: do you want to keep you bzr branch in sync with the svn one?
<alperkanat> no
<alperkanat> i'll delete the svn one
<alperkanat> i don't want any .svn or any other related thing in the project and want to use bzr as vcs
<alperkanat> Verterok: http://dpaste.com/80835/
<Verterok> alperkanat: you could try using svn-import (I'm not an bzr-svn expert, but it sounds reasonable)
<alperkanat> i'd just wipe out the svn repo and start over but i don't want to lose the history
<Verterok> sure, makes sense
<alperkanat> Verterok: svn-import ?
<alperkanat> there's no such command
<Verterok> alperkanat: it seems that bzr-svn is doing absolutely nothing :(, so it's bazaar trying to find a branch
<Verterok> it's a bzr-svn command
<Verterok> alperkanat: try running the bzr-svn tests with: bzr selftest svn
<alperkanat> ok
<alperkanat> Verterok: this will take up long... i'm going to sleep now.. thanks any way.. i'll try my chance tomorrow..
<Verterok> np
<ausimage> How can show a file splitting into several pieces? I wrote a module that I now want in 3 - 4 parts. I did not want the module to be just removed without expressing this change.
<rama> ausimage, about plugins i can't setup the post_push hook to get run when pushed via ssh.. any clue?
<ausimage> not sure about that one :/
 * ausimage is only a user, and a recent one at that...
 * ausimage wanders off, but hopes someone could give him insight into how keep history when splitting files up. PM him with answers ;)
<GaryvdM> Hi - I'm getting the following error in one of my repositories:
<GaryvdM> bzrlib.errors.BadIndexFormatSignature: 8b44a161cf3c0ccead798d1f111c8379.rix is not an index of type <class 'bzrlib.index.GraphIndex'>.
<GaryvdM> How do I fix this?
<GaryvdM> I have no idea how it happened :-(
<GaryvdM> I think this might have happened because this repo was on a flash drive, which I removed with out doing the safe remove thing.
<GaryvdM> I've recreated the repo form other sources.
<Spaz> hmm
<Spaz> say i have a bzr repo on a remote host
<Spaz> the directories/files must always have the same owner
<Spaz> is there any method i can use to ensure the files are always owned by the same owner:group?
<Spaz> assuming i'm using bzr+ssh://
<doomster> hi!
<Spaz> hello
<doomster> I'm just running "bzr branches http://code.python.org/python" and it's been hanging for two minutes or so, is that normal?
<fullermd> I wouldn't expect branches to be able to work over http...
<doomster> I'm rather new to Bazaar, can you tell me why?
<doomster> and, is there a different way to see what branches are present at that location?
<fullermd> Well, it has to be able to list directories to search for branches.  You can't do that over http.
<fullermd> Maybe it has enough smarts to process some of the forms of dir listings web servers send out, but I'd be a little surprised.
<fullermd> You can just pull the URL up in a browser and look; at least some presumed branches are visible there.
<doomster> ah, I see.
<doomster> I'm trying to wrap my brain around the bzr workflow and need some help. When I 'bzr branch' something, does it also create a repository?
<doomster> I'm also not sure I understand the difference between a branch and a repository...
<Pieter> there is no difference
<LarstiQ> there is a huge difference
<doomster> :|
<LarstiQ> doomster: branches are the entities you work with most, repositories are just a storage area for revisions
<doomster> hmmm...
<LarstiQ> doomster: wether branch makes a repository or not depends on if you are branching into a shared repository, if not, you're making a standalone branch and it will store it's own revisions in a private repository for that branch
<LarstiQ> doomster: but in your workflow, you usually don't care about repositories
<LarstiQ> doomster: branches are where the action is
<LarstiQ> doomster: this is in bzr terminology, in other systems branch and repository can mean slightly different things
<doomster> yes, I guess my SVN background is giving me troubles understanding this....
<LarstiQ> right, svn doesn't really have a branch concept, it's just convention by the users
<LarstiQ> doomster: is there a specific piece of workflow you're confused about?
<doomster> I just did "bzr init-repository test" and then "bzr log test", but that complained that it is not a branch. Doesn't a repository contain changes?
<doomster> LarstiQ: no, I guess I'm just confused by terminology.
<LarstiQ> doomster: not as such
<LarstiQ> doomster: when you make branches under 'test', those branches will use 'test' as the place to store their revisions
<LarstiQ> doomster: that is also true for unrelated branches, so the set of revisions in the repository can form multiple disjunt revision DAGs
<LarstiQ> doomster: there isn't a sense of a 'line of development' for a repository, it's just a big bucket of revisions
<LarstiQ> doomster: whereas a line of development is exactly what a branch is
<doomster> okay, so when I'm working on some project, I have two options. One is to just "bzr branch $URL", then I get a branch with an integrated repository where I can make changes.
<doomster> The other option is to first create a separate repository and then create branches within.
<LarstiQ> doomster: you can always decide to switch from the one to the other later
<LarstiQ> doomster: what a shared repository gives you is storage advantages and faster branching within (since it doesn't need to copy revisions it already stores)
<fullermd> The idea is that you always "bzr branch $URL".  If you happen to be putting it inside a shared repository, it will use that.  Otherwise it'll create an internal repository.
<LarstiQ> doomster: functionally, there is no difference
<LarstiQ> doomster: what fullermd said
<doomster> okay...
<fullermd> You don't [superficially speaking] really care either way, because everything will act the same.
<doomster> Okay, let's get to a real-world example...
<fullermd> (and it's easy to switch things from being shared to being standalone if you come to care in the future)
<fullermd> This is very different from SVN, where the boundaries of the repository determine what you can do between branches.
<doomster> I'm trying to port Python to MS Windows CE. On the way, there is quite some cleanup to do with the 'normal' win32 port.
<doomster> So, I guess I will have a handful of separate branches, each for one small step. It would be useful to create a shared repository for those, right?
<LarstiQ> doomster: correct.
<fullermd> It will save you space and time, yes.
<doomster> okay.
<doomster> I think I'm getting it now. ;)
<fullermd> LarstiQ: Hi, BTW.  Good to see you alive   :)
<LarstiQ> doomster: and if compiling your project takes a long time/has a big working tree, you might consider using lightweight checkouts and `bzr switch`
<LarstiQ> fullermd: thanks, you too :)
<fullermd> qi
 * fullermd slaps his mouse.
<LarstiQ> doomster: this will decrease the cost of the working tree, which when significant is, well, significant ;)
<fullermd> And it should be a reasonably familiar workflow if you're used to svn.
<fullermd> It is, however, a somewhat less common workflow with bzr, so you're more likely to snag some rough edges in the implementation.  It may be better to skip that part until you get comfortable with bzr.
<fullermd> (said with no real authority other than my offhand opinion)
 * LarstiQ nods
<doomster> when ~/repo is my repository, I will typically have ~/repo/branch-x and ~/repo/branch-y. Can I also create branches somewhere else and connect them to that repository?
<fullermd> No, they have to be inside it.
<fullermd> Now, you can (as in the just-described workflow) have the branches there, but have the working tree elsewhere.
<fullermd> Branches don't "point to" their repository, it's searched for.  When you need the repository (to find a revision, or save one, or something), bzr will look for it right with the branch, then in $BRANCH/.., then $BRANCH/../.., and so on.
<LarstiQ> doomster: branches have to be within the directory hierarchy, but deeper levels are fine (repo/trunk, repo/win32/cleanup, repo/win32/CE, etc)
<fullermd> It'll use the first repo it finds along that walk.
<doomster> the repository is just the .bzr directory?
<fullermd> Technically, the repository is the .bzr/repository/ directory.
<fullermd> The .bzr/ is...   I dunno what you'd call it.  'bzrdir' probably.
<LarstiQ> yup
<fullermd> It contains the internal files for the repository, and/or the branch, and/or the checkout, depending on which is at that location.
<LarstiQ> so with branches in a repository, there will be repo/.bzr/repository, and repo/branch-X/.bzr/branch/
<fullermd> It's sorta a combination in SVN terms of the repository and the .svn/ dirs scattered through the tree.
<doomster> okay, so both the repository and each branch have a .bzr dir
<LarstiQ> doomster: yes, and each working tree
<fullermd> Right.  It basically means "there's something bzr here, and I've got all the control files"
<doomster> btw: can I move a repository around using the shell or do I have to notify bzr about it?
<fullermd> It depends on whether you have something external referencing it (like a checkout somewhere outside it, or other people trying to look at it)
<fullermd> If not, you can move it around or tar it up or whatever.
<doomster> good.
<fullermd> Similarly, you can move branches around inside it, as long as they stay in it.
<fullermd> (or if they're standalone branches, you can move them around anywhere)
<LarstiQ> doomster: if you move a branch outside of it's repository, it will do the walk upwards again to find it's repository. If it doesn't find one, it's unhappy, but if it finds one that doesn't contain it's revisions, it's not so happy either.
<LarstiQ> doomster: move it back and it's fine again.
<doomster> poor unhappy branch!!1! O_O
<LarstiQ> (or provide a repository that has the same set of revisions)
<LarstiQ> :)
<doomster> comparing to SVN, doing a lightweight checkout from a branch is similar to SVN's working copies, right?
<LarstiQ> doomster: yes
<LarstiQ> doomster: a lightweight checkout will have to contact the branch it is bound to for all operations concerning history (diff, commit, log, etc)
<LarstiQ> doomster: but if the branch lives on the same harddisk (~/repo/branch and ~/project/checkout for example), that's ok. Whereas doing that over a 300ms latency link to the other side of the word is less snappy.
<fullermd> In contrast, a heavy [default] checkout will only have to contact the branch for a few operations (commit, update, etc).  The better choice if it's across a network somewhere.
<fullermd> (You'll find discussions in the docs of more details regarding the low-level implementation of heavy checkouts.  Join with me in narrowing your eyes in mild displeasure, and ignoring them   :p)
<doomster> well, sometimes understanding the internal motivations helps a lot using the tool
<fullermd> It doesn't in this case.
<doomster> bzr is now working more than five minutes on a normal checkout from a local branch...
<fullermd> How big is it (both checkout and history size)?
<doomster> 275MiB for the branch itself
<doomster> 40k revisions
<fullermd> A normal [heavy] checkout makes a full copy of the history.  So if it's big, that can take a while.
<LarstiQ> beuno: there has been quite some api changes on Tree I notice.
<mnemo> what package do I have to install to be able to use the "bzr vis" command?
<fullermd> bzr-gtk
<beuno> LarstiQ, hi
<beuno> changes since when?
<chandlerc[g]> is it a known issue that the password prompting for bzr-svn doesn't inject the password into subversion's cache?
<chandlerc[g]> as a side note, the password prompting did work (awesome!!) as did a branch, edit, commit, push cycle, depsite using weird and broken code.google.com svn!! rock!!
<abadger1999> Any loggerhead devs around by chance?
<beuno> abadger1999, sure, what's up?
<abadger1999> I almost have loggerhead working under mod_wsgi .
<abadger1999> I'm having one issue with the redirect from /project/ =? /project/changes
<abadger1999> In the code that's
<abadger1999> raise httpexceptions.HTTPMovedPermanently(
<abadger1999>                 self._url_base + '/changes')
<abadger1999> Instead of redirecting it's giving me this exception:
<abadger1999> [Sat Sep 27 11:04:03 2008] [error] [client 127.0.0.1] TypeError: expected string object for header value
<beuno> abadger1999, no tracebacks?
<abadger1999> For some reason, mod_wsgi doesn't give me a traceback there.
<abadger1999> beuno: I found the place in the code by inserting debug statements.
<abadger1999> It's in app/branch.py
<beuno> so, _url_base isn't a string?
<beuno> can you check to see what it's getting
<beuno> ?
<abadger1999> Let me print
<abadger1999> ugh. firefox is being a dog
<beuno> it's barking and licking your face?
<abadger1999> chewing on my swap and growling faintly.
<abadger1999> beuno: url_base:/bzr//packagedb/0.3.x:
<abadger1999> bzr is my webpath
<abadger1999> packagedb is the project
<abadger1999> 0.3.x is the branch
<abadger1999> URL I'm hitting is http://localhost/bzr/packagedb/0.3.x
<abadger1999> Oh... type is unicode.
<beuno> ah
<beuno> odd
<abadger1999> Not sure if that would make a difference
<beuno> try and convert it
<abadger1999> Yep, that's it.
<beuno> so, any ideas how we ended up with unicode?
<abadger1999> I wonder if this is something that needs fixing in paste's httpexceptions....
<abadger1999> Nope.  There's no unicode in the URL.
<abadger1999> Let me look at the wsgi env
<abadger1999> 'SCRIPT_NAME': u'/bzr//packagedb/fchiulli'
<abadger1999> (different branch)
 * beuno pokes mwhudson_ ^
<beuno> it's 8am-ish for him, but he'll read the scrollback  :)
<abadger1999> So mod_wsgi is adding that as a unicode object instead of a byte string.
<abadger1999> Cool.
<beuno> we should probably add a check
<beuno> could you file a bug for it?
<abadger1999> Ah ha.
<abadger1999> http://pythonpaste.org/news.html#id2
<abadger1999> Exceptions with unicode messages donât cause the collector to fail.
<abadger1999> That was added in paste 1.7 and I'm using paste 1.6 ATM
<abadger1999> beuno: k.  I'll file a bug.
<beuno> abadger1999, interesting
<beuno> hardy has 1.6
<abadger1999> beuno: Are you guys interested in my script to start loggerhead using mod_wsgi?
<beuno> abadger1999, thanks for debugging it!
<beuno> abadger1999, yes we are!
<abadger1999> It's mostly removing things from the start-loggerhead script.
<abadger1999> Cool :-)
<beuno> upload the branch, file a merge request
<beuno> make sure it doesn't break any tests
<abadger1999> Okay.
<abadger1999> How do I run the tests?
<abadger1999> Ah nose
<abadger1999> beuno: Thanks!  I'll get the bug and the branch up today.
<beuno> abadger1999, fantastic, thank you  :)
 * beuno is off to catch another plane
<astrobunny|afk> hello
#bzr 2008-09-28
<alperkanat> hey there.. i want to migrate to bazaar from svn... but i can't import the code to a new bzr repository.. can someone please help me ?
<alperkanat> any help for bzr-svn ?
<alperkanat> it always keep looking for .bzr directory inside the subversion repository
<cody-somerville> You can easily import from svn into bzr using launchpad
<Pieter> .. is there a performance regression in 'bzr blame' from 1.5 to 1.7?
<Pieter> anyway, http://pastie.org/280554
<lifeless> Pieter: there could be; 1.6 made some significant refactoring of deepguts
<Pieter> pretty serious difference, 8x slowdown
<lifeless> Pieter: tried to keep everything balanced; may not have completely succeeded
<lifeless> Pieter: oh, no, thats less likely
<lifeless> Pieter: big project, deep history ?
<Pieter> yes, samba
<lifeless> wheee that sucks
<lifeless> if you could file a bug, that would be great; I'm in the middle  of some social stuff atm
<Pieter> let me try
<Pieter> i'm not too fond of bug trackers :)
<lifeless> you might like to try the btree based repo format (--development2) just landing in bzr.dev right now
<Pieter> (bug 275303)
<ubottu> Launchpad bug 275303 in bzr "Performance regression on blame" [Undecided,New] https://launchpad.net/bugs/275303
<lifeless> Pieter: thank you
<lifeless> Pieter: so the index that the current pack-* formats use is bisection-searched
<lifeless> Pieter: and this due to a number of things isn't very good, even though its better than the pre-pack formats
<lifeless> Pieter: the --development2 format, replaces the index layer with a B+Tree; and that is quite possibly going to be the thing that suddenly chews up huge amounts of time
<lifeless> erm, fix the thing that chews up time
<lifeless> (because, during 1.6/1.7 some heuristics were added that can cause a full index read (think table scan) unnecessarily, because its faster in some cases
<Pieter> hmm, ok
<Pieter> I'm not going to run a -dev version though ;) I'll wait a bit
<lifeless> its landed I think, just checking the merge result
<lifeless> sure; not expecting you to run one, just noting that you could give it a spin and see :P
<lifeless> yes, its landed
<bb-bzr> does anyone have a minute to answer some nubi questions with using bzr?
<lifeless> sorry, just popping away
<lifeless> ciao guys
<bb-bzr> I had a question about branches in general... if I have a mirror branch that has recently pulled in changes from some feature branch foo; at which point foo will no longer be used, is there a reason that I shouldn't just remove the whole foo branch from the disk?
<alecwh> ï»¿Hello, I downloaded the package "bzr-gtk", and I don't see anything changed in the Nautilus File Browser. What am I supposed to see? I'm on Ubuntu Hardy.
<spiv> bb-bzr: usually no important reason
<bb-bzr> so there won't be any orphaned data in a repository if i nix a branch?
<spiv> bb-bzr: as you can see with e.g. "bzr viz" all the revision data from foo is present in the mirror branch.
<bb-bzr> yah I see that using qlog
<bb-bzr> or viz
<bb-bzr> so i guess if there is some case where a diverging set of branches would resolve down to a feature branch would be the only case where it would become an issue and in that case I could just figure something else out?
<spiv> bb-bzr: so usually the only reason to keep the foo branch around on disk is if you want a convenient way to refer to those revisions later
<bb-bzr> ahh
<bb-bzr> i usually work on a defect or feature on its own branch, so have lots of branches that have short lifetimes
<bb-bzr> I am used to just killing them once merged, but wanted to make sure this wouldn't be an issue in bazaar
<spiv> Yeah, just remove them in that case.  That's what I do.
<spiv> alecwh: I don't think the nautilus extension is enabled by default
<alecwh> what would I see then? I don't notice any differences
<bb-bzr> spriv: thanks much man, busy setting up bazaar for my company and writing a developers guide and wanted to make sure I was not recommending something goofy
<spiv> alecwh: also, /usr/share/doc/bzr-gtk/README.Debian for the hardy version of bzr-gtk says that it isn't even packaged in that version.
<spiv> alecwh: IIRC it adds emblems to versioned files & directories.
<spiv> alecwh: http://bazaar-vcs.org/bzr-gtk links to some screenshots
<alecwh> that's... it? and can I easily add support?
<spiv> alecwh: the README that comes with bzr-gtk explains how you can enable the nautilus integration (although obviously not with the hardy packaging of it)
<spiv> alecwh: in addition to emblems, I believe it adds options to the right-click context menus, e.g. "View Changes..."
<spiv> alecwh: note that a lot of what bzr-gtk provides is accessible without nautilus, type "bzr help gtk"
<alecwh> spiv: thanks a lot!
<Odd_Bloke> http://amix.dk/blog/viewEntry/19350 looks interesting.
<Odd_Bloke> Unfortunately, I'm using a LiveCD ATM, so can't really play with a bzr convertor.
<chandlerc> jelmer: i have an odd crash report
<chandlerc> but i can't really file a bug, because it fixed itself
<chandlerc> and i am happilly using bzr-svn better now than ever before
<AfC> "Self healing systems"
<chandlerc> but in case someone else runs into it, I was using neon compiled against OpenSSL, and getting segfaults (with no python backtrace or anything) while pushing to a repository
<chandlerc> another machine wasn't despite the same bzr, bzr-svn, and repository
<chandlerc> the other machine was using gnutls, so i recompiled neon against it here, and everything works
<_J_m_D_> any insights on bzr vs svn?
<_doomster_> _J_m_D_: in what context?
<_J_m_D_> looking for a general versioning system - not only for code but for all kinds of files. Will be used for online colaboration
<_J_m_D_> many heavy files (3D-graphics) will be used
<_doomster_> how about the intended users? BZR makes it easier to do detached development of private branches, with SVN you can also create and maintain branches, but you need to maintain them in the same repository, i.e. give everyone access.
<_J_m_D_> I like the concept of bzr in that respect. Seems like each team member can do his own "local development" and synchronize to the central repository only "when needed". Is that correct?
<_doomster_> right.
<_J_m_D_> (I am a version vontrol noob)
<_J_m_D_> at the moment IDE integration is not a big issue. But file browser integration (shell integration) for windows would be nice - like tortoise for svn.
<_doomster_> tsvn is damn sweet, true.
<_J_m_D_> anlything similar available for bzr?
<_J_m_D_> anything*
<_doomster_> not that I was aware of, but I'm a bzr noob myself. I'm an svn veteran though.
<luks> http://bazaar-vcs.org/TortoiseBzr
<luks> but obviously not as mature as tortoisesvn
<_doomster_> :)
<_J_m_D_> mmm, seems very nice
<_J_m_D_> doomster - so what is your impression so far with bzr compaired to svn?
<doomster> I'd rather not make a statement, because I really haven't used it enough.
<_J_m_D_> is anyone aware of some issue that makes bzr inferior to svn?
<doomster> As far as SVN is concerned, it is a very simple too without too many bells and wistles, but it is solid and does its job. I'm looking for the possibility to efficiently maintain detached branches, and BZR offers that. Further, there are many users to BZR, so it's rather well supported.
<doomster> *tool
<luks> partial checkouts are a reason why you might like svn more, but it depends on the project
<_J_m_D_> from what IÂ´ve learned bzr is more flexible as to the choice of available workflows compaired to svn, where as svn is more widespread and thus has more 3rd party tools. But I guess bzr is catching up, right?
<doomster> actually there is one thing that might bite you with large binary files. When you prepare a directory for local work, you retrieve the current state via SVN but you retrieve the whole history via BZR, which takes significant amounts of time. I think (someone here will probably help out) that you can ignore parts of the history though, in order to preserve bandwidth.
<_J_m_D_> regarding binary files - how are revisions made (whether svn or bzr)? Is the whole file saved again and again, or is some binary change-tracking-magic going on only storing incremental changes even to binary files?
<Peng_> _J_m_D_: Most VCSes (including bzr and svn) use delta compression, but they also store full copies occasionally to improve performance.
<Peng_> Bazaar's delta algorithm is line-based, isn't it?
<luks> _J_m_D_: it uses text-based (splits the text to blocks on lines) delta compression
<_J_m_D_> delta compression would then be like "store only the changed bytes of the file" or something similar?
<luks> SVN uses a specialized binary delta compression for binary files
<Peng_> _J_m_D_: Right.
<luks> yes
<_J_m_D_> oki - thnx
<krokosjablik> Hello, question to bzr 1.3 (in hardy): the parent of my branch has been changed, how can I adjust my brunch? Or merge with the changed parent and just push?
<doomster> brunch - mjam-mjam... ;)
<krokosjablik> ï»¿doomster: ï»¿have I to look in man pages for the mjam-mjam option ;)
<krokosjablik> ok, my solution was just to adjust the property "push_location"  in "<myBrunch>/.bzr/branch/branch.conf
<awilkins> jelmer: ?
<bob2> krokosjablik: 'bzr push --remember someurl' will work, too
<krokosjablik> ï»¿bob2: Many thanks!
<jelmer> awilkins: hi
<jelmer> chandlerc: please file a bug
<jelmer> chandlerc: sorry, hadn't read the rest of your lines yet
<LarstiQ> beuno: since the last merge of bzr.dev into nested-trees :)
<LarstiQ> beuno: tree._iter_changes -> tree.iter_changes was easy enough to spot
<LarstiQ> beuno: but tree.case_sensitive looks a bit harder, it only seems to be defined on working trees (which makes sense), I hope not to get into working vs revision problems there, will have to try.
<LarstiQ> jfroy: I see some of your changes made it the bzr-svn 0.4 branch, how far away are you from having Keychain working?
<jfroy> LarstiQ: it's working perfectly fine in bzr-svn
<jfroy> The work is complete.
<LarstiQ> cool
<jfroy> It requires no modifications to svn either
<jfroy> (and works fine with the version bundled with 10.5)
<jfroy> I'm currently working on Keychain integration in bzr itself (lp:~jeanfrancois.roy/bzr/keychain-auth-rdonly)
<jfroy> still at the experimental stage
<LarstiQ> ooh, I should round up some of my mac users and point them to your work :)
<jfroy> The branch works, but it's a huge ugly hack :p
<jfroy> the work in bzr-svn was released with 0.4.12 (I think)
<jfroy> .13 maybe
<jelmer> 0.4.13
<jfroy> thanks you :p
<jfroy> *thank
<jelmer> and thanks again for that work, btw ! :-)
<jelmer> nabend LarstiQ
<LarstiQ> navond jelmer :)
<chandlerc> jelmer, was you're comment saying to not file the bug?
<jelmer> chandlerc, yep
<chandlerc> is this a known deficiency in the OpenSSL neon lib?
<jelmer> chandlerc, filing a bug against neon may be a good idea though
<chandlerc> fun times
<jelmer> (not against bzr-svn though, which was what I was first thinking about)
<chandlerc> ahh, yea, clearly not there
<chandlerc> jsyk, the only remaining issue i have with actively using bzr-svn and googlecode is the 401 error not flipping from https to svn+https
<chandlerc> i think i already filed a bug for that a while back
<jelmer> chandlerc, yeah, that's been reassigned to bzr
<jfroy> jelmer: oh, I noticed something odd while working on the keychain stuff in bzr. I did a merge or pull command from one bzr branch to another locally (2 local branches in a shared repo), and a file:/// svn RA connection was opened (or was tried), according to .bzr.log :p
<chandlerc> but by specifying the svn+ i'm pulling and pushing and even merging conflicts across multiple machines now w/o issue! =]
<jelmer> jfroy, it probably tried to open a file:// using svn
<chandlerc> very happy about that
<jelmer> chandlerc, cool
<jelmer> jfroy, That's fine though - svn repositories can exist locally
<jfroy> jelmer: yeah, not a big deal
<jfroy> indeed
<Kosjer> hi got a short question about the update from bzr 1.5 to bzr 1.7 on osx 10.5 . the installer is sayin the following warning note:  If you have installed a previous version of this bundle, please remove /usr/bin/bzr manually (the executable is located in /usr/local/bin/ since 1.4). so is it enough to manually delete in /usr/local/bin/  the bzr file? is that all? and then the updater could be run?
<Kosjer> or have other files to be be removed too?
<LarstiQ> Kosjer: I'm not certain, but I think that notice is to ensure there isn't an old leftover /usr/bin/bzr that comes earlier in the path than /usr/local/bin/bzr
<LarstiQ> Kosjer: in which case, yes, that would be enough
<Kosjer> larstiq ahhh true. i was unsure about the note. but i remember vaguely that on the switch to i guess 1.5 there was already the removal. tried it right now without any removal and it worked. updated nicely. all fine now :) thanks!
<LarstiQ> Kosjer: good to hear
<Kosjer> thanks and good night
<alperkanat> is there authentication for bzr ? i want to setup a centralized server available over http using nginx..
<alperkanat> so i guess i shall provide http authentication ?
<jakobb> alperkanat: I know from experience at least that http authentication works
<jakobb> you can even set a user/password in your personal rc files, such that you don't have to type them over and over again
<alperkanat> is there some other choices like path authentication ? i may want to make some repos available to the public.. or read access is available to the public and write needs auth.. etc ?
<alperkanat> jakobb: what rc files ?
<jakobb> as long as you don't need redirection to get to the url, things should work fine
<jakobb> alperkanat: the authentication.conf file in the .bazaar/ dir
<alperkanat> hmm i haven't seen it in the docs
<jakobb> it is definitely there, but I remember that you have to look hard for it
<jakobb> It don't remember all the details, because I use hg nowadays mostly :P
<jakobb> alperkanat: http://tinyurl.com/4zl6ae
<alperkanat> jakobb: thanks
<lifeless> moin
<funkyHat> Where is the upload location for upload stored?
<funkyHat> It keeps trying to upload to the old location although I've manually told it to upload to a new location
<james_w> funkyHat: did you use --remember?
<funkyHat> ah, I feel silly now :)
<funkyHat> thanks
#bzr 2009-09-21
<lifeless> igc: whats the testing guide and why isn't it part of the dev guide?
<lifeless> sorry if that came across picky, I'm just a little surprised / concerned about fragmentation
<igc> lifeless: someone moved it out (vila maybe)
<igc> lifeless: http://doc.bazaar-vcs.org/developers/
<lifeless> oh
<lifeless> so this is a terminology thing
<lifeless> thats all dev guide to me
<lifeless> and I suspect to poolie as well
<lifeless> just chapters in the dev documentation
<Peng_> Is http://bazaar-vcs.org/bzr/.bzr/repository/packs/ really badly compressed, or did I accidentally misplace most of my repo while upgrading to 2a?
<Peng_> Oooh. Never mind. That is a 1.9-format repo. Hm.
<Peng_> Ohh! http://bazaar-vcs.org/bzr/bzr.dev/ is a branch reference now. Clever!
<Peng_> Confusing, too.
<Peng_> So lp:bzr is now the official location for bzr.dev?
<lifeless> yup
<Peng_> What should I set bzr to use as the public/submit branch?
<lifeless> check the docs ;)
<Peng_> :<
<Peng_> .....Which docs? :D (kidding)
<lifeless> [I've paged it out]
<Peng_> The doc directory in the source tree doesn't help.
<Peng_> I'll keep the public and submit branches set to bazaar-vcs.org for now, then.
<lifeless> Peng_: HACKING.txt
<lifeless> look for locations.conf
<Peng_> Ah, thanks. That didn't help very much, though. I'm not a PQM user.
<Peng_> And LP is open source now. I have missed a lot!
<lifeless> Peng_: well, lp:bzr then ;)
<Peng_> Literally "lp:bzr", or the http or bzr+ssh location that points to?
<lifeless> literally
<lifeless> if you just want 'bzr send' to work
<Peng_> OK.
<poolie> hi all
<poolie> welcome back igc
<igc> thanks poolie
<spiv> Good morning.
<Peng_> Good morning. Or whatever. :)
<igc> hi spiv
<Peng_> Is it morning?
<igc> hi Peng_
<igc> Peng_: it is here :-)
<thumper> hi ho
<thumper> what is the simplest way to allow people to push to a machine with bzr+ssh but not to have shell access?
<Peng_> There's a script, contrib/bzr_access or somesuch.
<lifeless> authorized_keys policy
<Peng_> Yeah.
<lifeless> and or that script
<thumper> oh kay...
<thumper> which is easier / more configurable?
<lifeless> launchpad :P
<Peng_> Heh.
<thumper> lifeless: haha
<Peng_> He's right...
<thumper> where does the package install the contrib dir?
<lifeless> I don't think it does
<thumper> Peng_: it is for some friends polytech work
<thumper> no project
<thumper> and they don't want it public
<thumper> and I don't want them poking around my machine
<Peng_> Umm. Install Launchpad on your machine? :D
<thumper> heh
<thumper> no
<Peng_> You could just give them SFTP access.
<SamB_XP_> Peng_: that isn't great
<thumper> this should be an easy thing to set up for bzr
<thumper> I've been frustrated that it wasn't easier
<thumper> like sticky group bits
<SamB_XP_> Peng_: you'd want to give 'em smart server access too ...
<thumper> and umasks
<thumper> et al
<thumper> I think we should be able to set something in the locations.conf (or something)
<thumper> and have the smart server set the right groups
<thumper> IMHO
<Peng_> SamB_XP_: I know
<poolie> spiv, hello
<spiv> poolie: hi
<spiv> poolie: I've done a couple of rounds of "do something to a bug" "gar, file a bug on launchpad" this morning.
<spiv> poolie: I have a fix for the 2 hpss vfs calls on incremental push; I've played a bit with trying to anticipate future requirements with the new verb I'm adding, but decided against it so I'll just submit the simple fix.
<poolie> igc, to answer the only other question on our agenda
<poolie> see my mail to emma on friday, i'm aiming to get the site up this week
<poolie> from a shared branch deployed to escudero
<poolie> spiv, cool
<igc> poolie: thanks
<poolie> or you can if you get to it first
<poolie> spiv, we still seem to get a lot of 'medium(?) in use' errors
<poolie> maybe this should be handled under -Dcleanup but perhaps there's something else we should do that would avoid them obscuring the real error?
<spiv> poolie: hmm
<poolie> my thoughts exactly :)
<spiv> :)
<poolie> maybe we'll try -Dcleanup first and then see what happens
<poolie> or more importantly, putting a choke point for all cleanups
<lifeless> spiv: whats trigering vfs on incremental push ?
<spiv> lifeless: "cannot update remote workingtree" warning
<lifeless> meep yes I saw that
<lifeless> what was it?
<spiv> push explicitly checks for a working tree so that it can issue that warning, and we have no HPSS way to find a working tree.
<spiv> It doesn't actually care what format or anything it is, just whether or not there is one.
<spiv> So I've made a new BzrDir.open verb that returns a yes/no for the presence of a workingtree in this bzrdir.
<lifeless> +1
<lifeless> have you seen spurious outputs of that warning btw?
<spiv> I could have made a has_workingtree verb, but may as well cut out the roundtrip and take the opportunity to slightly decruft the BzrDir.open verb :)
<spiv> No, I don't think so.
<lifeless> so, I think has_workingtree would be more precise
<lifeless> but as we don't support working with them remotely anyway
<lifeless> doing what you've done is fine
<spiv> Right.
<lifeless> what cruft are you deing?
<lifeless> [if its the declarative capabilities, I'm not sure we want to remove them]
<spiv> The current BzrDir.open verb squashes some error conditions into just 'yes'/'no', for backwards-compat reasons.
<lifeless> I see, cool.
<igc> poolie: one thing I forgot to discuss on the phone: elmo's email re the karmic chroot
<igc> poolie: one of us should reply
<zsquareplusc> hmm, why does multi-pull try to pull data from a file URL when i want to fetch from a bzr+ssh URL? even worse, it sees the path the branch was on the other machine from which i first pushed it up
<spiv> zsquareplusc: it uses the remembered pull locations, IIRC.  You can use "bzr pull --remember NEW_URL" in those branches to change that.
<zsquareplusc> hm, doesn't this make the multi-pull more or less useless? it apparently manages to find these branches on the remote URL but then it turns to a completely different location to download?!?
<spiv> zsquareplusc: no, it just does the same as "bzr pull" with no arguments would do in each of the individual branches.
<spiv> Which is often the right thing, and if it's not it's usually easy to use either --remember or edit your locations.conf to make it do the right thing.
<spiv> It would be nice to have a "pull all of these from *over there* just this once" feature too, though.
<zsquareplusc> well the branches were created on one machine, converted from CVS. i pushed them to a repo on sf.net. so i have to manually touch each of these again, re-push etc :(
<zsquareplusc> spiv: i disagree that it is doing the right thing in this case. i have no local copy yet, just and empty shared repo. i'd certainly expect that multi-pull downloads from the URL i'm giving it not from anywhere else.
<zsquareplusc> how do i see the saved push location? bzr info?
<zsquareplusc> because i don't see it there on the branch i pulled (one of those were multi-pull failed)
<spiv> zsquareplusc: if you don't have a branch yet, then pull (and multi-pull) aren't the commands you need.
<zsquareplusc> i don't see a multi-branch :/
<spiv> Yeah :(
<spiv> I agree there are things we could support better, I'm just explaining that multi-pull is doing what it was designed to do.  It would be nice to have multi-branch or similar.
<spiv> We're actually planning to rethink how we deal with groups of branches for 3.0, because we know we're a bit lacking.
<zsquareplusc> well if it would just fail, OK. what's irritating me is that it somehow remembers a local path on my other machine
<zsquareplusc> i ran a bzr info on the branch i originally pushed, it has that file URL there listed as parent
<spiv> zsquareplusc: that does sound weird.  multi-pull walks all the subdirectories of the directory you run it in looking for branches to pull, perhaps one of those has a branch with that info?
<spiv> Whatever multi-pull does with an individual branch you ought to be able to reproduce with plain "bzr pull" on that branch.
<zsquareplusc> i gave it the URL of the remote repo, so it apparently walks trough those :/
<spiv> Oh!
<spiv> That does sound likely to confuse, yes.
<spiv> I guess that's like doing "bzr pull -d REMOTE_URL"...
<zsquareplusc> that the branches remember that file:// parent does not hurt? at least the fresh branch i made from the remote repo (using bzr branch) does not list it anymore, it has the remote repo URL as parent, which makes more sense
<zsquareplusc> and is there a special reason that when i bzr branch, that same URL is not right away saved as push, pull and merge location? at least the way i was using it, that would have been helpful
<SamB_XP_> spiv: yeah, it does seem a bit silly for it to be attempting to pull *into* an HTTP url ;P
<spiv> SamB_XP_: there might be a smart server there :P
<zsquareplusc> it was a bzr+ssh URL
<SamB_XP_> oh, that's a bit less dumb then
<lifeless> I thought that the bug with bzrlib/bzrlib/*.so was fixed?
<zsquareplusc> hmm. getting access denied on  c:\...\temp\xxx.pag
<zsquareplusc> i made a bash script that does several bzr branch(es) now when i run it under cygwins bash it prints that its connected using ssh and then the error about access denied on the temp file :(
<zsquareplusc> when i run the command manually it fails the same way - when run in a bash shell. it works in a cmd.exe :/
<zsquareplusc> it seems to be paramiko/win_pageant.pyo:121 that causes the error (official bzr 1.15 windows distribution)
 * igc lunch
<poolie> spiv btw bug 432993 is the kind of thing i was referring to earlier
<ubottu> Launchpad bug 432993 in bzr "TooManyConcurrentRequests when failing to connect over ssh" [High,Confirmed] https://launchpad.net/bugs/432993
 * igc medical appointment - bbl
<thumper> i can haz hard linkz agan plz?
<lifeless> poolie: you're working on a bug script?
<lifeless> thumper: what do you want them for?
<poolie> i am
<thumper> lifeless: hardlinking working copy files is not currently supported in <WorkingTree6 of /home/tim/src/lp/bmp-notification-recipients>
<thumper> lifeless: just how I work
<lifeless> thumper: tell me more
<thumper> lifeless: I have light weight checkouts of devel
<lifeless> many?
<thumper> lifeless: and I build new branches using 'cbranch --lightweight --hardlink'
<thumper> lifeless: now about 20
<lifeless> have you considered using switch ?
<thumper> yes
<thumper> I use pipelines
<lifeless> What doesn't it do/does wrong for you?
<thumper> but I like to keep my work in meaningful directories
<thumper> it adds context for me
<lifeless> sure
<thumper> I started with switch originally
<lifeless> so I use meaningful directories
<thumper> but I found I had too many copies on the go
<lifeless> and switch
<lifeless> do you mean 'you forgot where you were'
<lifeless> or 'you actually needed multiple work areas at once due to $thing'
<thumper> lifeless: it had to do with work that was in various states of review
<thumper> lifeless: I often have tests running in one branch
<thumper> while hacking in another
<poolie>    888 Confirmed
<poolie>    353 Triaged
<poolie>    265 New
<poolie>    147 Incomplete
<poolie>     47 In Progress
<poolie>     17 Fix Committed
<thumper> or even running LP locally in another
<lifeless> poolie: welcome to API's
<poolie> mm, i have poked at them before
<thumper> lifeless: I also found that using TAGS, with multiple directories, I need different emacs buffers
<poolie> the vodka is strong but the meat is no good
<thumper> lifeless: or I can get jumped around into the wrong directory
<lifeless> thumper: would it be a good idea for 'bzr switch' should incremental-update TAGS?
<lifeless> thumper: here's where I'm coming from: we're doing UI overhaul around groups of branches.
<thumper> I don't pretend to understand TAGS
<thumper> I know
<lifeless> thumper: I suspect many folk have 'lightweight + switch' as key building blocks in how they want to tackle that.
<thumper> I guess I use my checkouts as a kinda "work in progress" list
<lifeless> thumper: so I want to understand the friction you felt more
<thumper> I delete them when they are merged
<thumper> I use multiple checkouts for various reasons
<thumper> I like to be able to run against trunk without switching my current work
<poolie> thumper: so just click affectsmetoo on the bug and then... oh :)
<thumper> to perhaps test stuff
<poolie> more seriously, we could look at in content filtering
<thumper> and sometimes running long tests locally while wanting to hack other stuff
<thumper> so I need more than one concurrent checkout
<thumper> one I had more than one
<thumper> I found that I wanted meaningful directory names
<thumper> the easiest way I found was to have lightweight checkouts for my work
<thumper> and moved to cbranch
<thumper> from there to hardlink
<thumper> perhaps having a way to tag branches in a local repo as in various states would help me
<thumper> so I could easily see which branches I have locally that aren't merged
<thumper> without having them all in their own checkouts
<mwhudson> fwiw, i work almost exactly like thumper
<thumper> as long as I could list them easily
<lifeless> thumper: I use directories to tag branches
<thumper> lifeless: inside the repo?
<lifeless> thumper: mkdir pending; mkdir review; mkdir experimental
<abentley> fwiw, thumper works almost exactly like me :-)
<lifeless> yup
<mwhudson> i don't actually have any real problems with bzr here, as 'make build' takes far longer than tree building :(
<thumper> I don't have trees in my repo
<thumper> it seems ick to me
<thumper> mwhudson: true
<lifeless> thumper: thats not anything to do with trees :)
<lifeless> thumper: I put branches under there
<thumper> lifeless: but if you have a lightweight checkout, and you move the branch
<thumper> lifeless: how do you reconcile that?
<lifeless> bzr switch --force
<lifeless> but it happens rarely
<lifeless> as I have only a few checkouts
<lifeless> and usually state changes are also when I need to stop editing (or conversely start editing) branches
<thumper> lifeless: I got my workflow from jamesh
<thumper> lifeless: when I first started using bzr
<lifeless> thumper: I'm not criticising it!
<thumper> lifeless: I'm not saying you are
<thumper> lifeless: I'm trying to give context
<lifeless> thanks ;)
<thumper> lifeless: part of it is "this is how I was taught"
<lifeless> righto
<thumper> lifeless: I have thick skin, you have to be a hell of a lot more direct for me to think you are criticising :)
<lifeless> All the rugby
<thumper> lifeless: I didn't start rugby until I worked in the UK
<thumper> lifeless: never played in NZ before that
<thumper> :)
<RenatoSilva> what's the recommended workflow when working on a feature branch while trunk keeps actively updated?
<lifeless> hack;hack; commit; merge trunk; check for regressions; commit; hack; hack; loop
<RenatoSilva> I'm using launchpad, I have one branch in rev 18, and other in rev 21 which is the trunk. I'm afraid that when I merge the former (likely to keep at rev 18) with the latter, that could be at rev 25 for example, well I'm afraid I have problems...
<RenatoSilva> what are regressions?
<lifeless> when things stop working
<RenatoSilva> and so I need to keep in sync with the target branch?
<lifeless> up to you
<lifeless> you asked for recommended ;)
<RenatoSilva> hum so it is recommended to avoid regression?
<RenatoSilva> the more diffs between branches, the more likely the merge will break code?
 * RenatoSilva how merges are get done is still an enigma for him
<bob2> RenatoSilva: avoiding regressions is a fancy way of saying 'don't introduce bugs' :)
<bob2> RenatoSilva: I dunno if falling behind and having to do larger merges is more likely to introduce bugs (probably), but it's also harder and more likely to conflict
<lifeless> and bugs can happen when you merge.
<spiv> RenatoSilva: basically, bzr compares the history of all the changes in the two branches, and applies the changes that are present in the merge source but not yet present in the target.
<RenatoSilva> bob2: yeah, I don't know about bugs either (generated by the merge itself?)
<spiv> RenatoSilva: but bzr is just software; the way it understands changes is by seeing which lines of text have changed, rather than understanding that e.g. "function X was renamed to Y", so it's possible that the result bzr merge will produce something other than what a human would have done if they were applying those changes manually.
<bob2> RenatoSilva: by combining your code with the trunk - e.g. if you modified some function to introduce a bug
<mwhudson> RenatoSilva: the classic thing is stuff like adding a required argument to a function in one branch while adding a call to that function in another
<mwhudson> RenatoSilva: both branches are correct, but the combination is not, and you'd need to be waaay cleverer than any vcs tool is today to figure that out automatically
<RenatoSilva> spiv: that's what I imagined, for example if I merge branch X in rev 19 with trunk rev 21, where they have diverged at rev 17, so bzr will take revs 18 and 19 and try to apply the diffs to rev 21 on the trunk, right?
<spiv> RenatoSilva: and sometimes changes in the two branches are simply incompatible as-is, e.g. one branch may add a new argument to a function, and the other may add a different new argument instead.  (or mwhudson's example, which is similar)
<lifeless> RenatoSilva: the mechanics of the merge - bzr will merge unmerged work.
<lifeless> RenatoSilva: you should just try; nothing like experimentation to help you see
<spiv> RenatoSilva: if you merge X into trunk, then yes.
<spiv> RenatoSilva: (although not via diffs, precisely; diffs don't handle renames and bzr does, for instance)
<spiv> Hmm, well, I guess diffs can do renames.
<spiv> diffs aren't so good for changes to symlinks or binary files, though :)
<Peng_> Well, merging isn't so good for symlinks or binary files.....
<RenatoSilva> spiv: ok I don't mean `diff`s are generated, I just think it's sort of magic :)
<spiv> Peng_: yeah, but at least it DTRT when only one side has changed them.
<Peng_> spiv: Oh, cool.
<RenatoSilva> Peng_: for bin files you have to choose between one and another versions right? there's no merge for them ...
<Peng_> RenatoSilva: Well it's totally theoretically possible to develop merge tools for binary files.
<Peng_> RenatoSilva: Merging really isn't scary, and it's a major part of using a DVCS.
<Peng_> RenatoSilva: Even if things go horribly wrong, you can just "bzr revert".
<RenatoSilva> lifeless: well I have merged a few times, I just see it as magic :) (just curious about how it works -- because of the initial issue)
<RenatoSilva> spiv: well I think something similar to a merge-directive is used
<spiv> RenatoSilva: well, if a file originally had a series of lines ABCD, and one branch changed it to ABC, and the other changed it to AECD, then merge would result in AEC.
<RenatoSilva> spiv: except that the commits are "packaged" under another one
<RenatoSilva> spiv: AEC? weird, so bzr tries to do same-line merges? o.O
<spiv> RenatoSilva: no, by "ABCD" I mean four lines
<spiv> RenatoSilva: just using a very compact notation because IRC isn't really designed for multi-line examples :)
<RenatoSilva> ok :)
<RenatoSilva> so it is recommended that as I update trunk, I do a bzr pull in the other branch?
<lifeless> no, you can't
<spiv> (In principle a merge algorithm can work with sequences of bytes rather than sequences of lines, but for various reasons lines tend to be a good tradeoff for performance and human-intelligible results for source code)
<lifeless> because the other branch has different changes
<igc> back
<RenatoSilva> lifeless: hum you can't pull from a diverged branch, right
<RenatoSilva> so what should I do?
<RenatoSilva> merge trunk into the other?
<lifeless> yes; as I said waaaay above :)
<RenatoSilva> let's use an example
<RenatoSilva> branch X rev 19, diverged from trunk at rev 17, and trunk is at rev 21
<RenatoSilva> so I merge trunk into X, and X get a new rev 20 { trunk 18-21  } ?
<lifeless> RenatoSilva: yes
<lifeless> cd X; bzr merge trunk; <check for regressions>; bzr commit -m 'merge trunk'
<RenatoSilva> and when I'm done I merge X into trunk, that gets a rev 22 { X 18, 19, 20 { trunk 18-21 }  } ?
<RenatoSilva> * trunk, which gets
<spiv> Not sure exactly what you mean by that notation.
<RenatoSilva> spiv: that's the only way I can see it :(
<spiv> It's tip revision, rev 22, would have two parents, trunk's 21 and X's 20.
<RenatoSilva> spiv: rev 22 of trunk will contain 3 revs from X: 18, 19 and 20, where 20 is a merge with trunk
<spiv> RenatoSilva: "contain" isn't really the right relation.
<spiv> RenatoSilva: "has parent" is the relation.
<RenatoSilva> what's a tip revision?
<spiv> RenatoSilva: the most recent revision in that branch.  The "tip" of the branch :)
<lifeless> the most recent commit on a branch
<spiv> Also known as "head"
<spiv> RenatoSilva: have you seen the output of "bzr viz" (if you have the bzr-gtk plugin) or "bzr qlog" (if you have qbzr)?
<RenatoSilva> spiv: I think if you explain me using my notation I could easily understand :)
 * RenatoSilva trying to understand "It's tip revision, rev 22, would have two parents, trunk's 21 and X's 20."
<spiv> RenatoSilva: I can't, because I think the way you read your notation presumes a view of the system that isn't accurate
<lifeless> poolie: so whats your bug thing?
<davidstrauss> spiv: I'm pretty sure that notation means rev 22, which contains X's 18, 19, 20. X's 20 contains trunk's 18-21.
<lifeless> davidstrauss: contains is the problem though :)
<lifeless> davidstrauss: as revisions are not containers for revisions
<davidstrauss> lifeless: what does it mean when they're nested in the log output, then?
<spiv> davidstrauss: a) what lifeless said, b) that reading would confirm my suspicion that it's an inaccurate model for bzr
<lifeless> davidstrauss: non-left hand parent
<lifeless> davidstrauss: e.g. a merge occured, and the revision that is indented was not present in the left hand ancestor of the above revision
<RenatoSilva> lifeless: last time I saw a merge commit the revisions merged were showing "inside" the merge revision
<spiv> RenatoSilva: so, a commit has links its parent(s), and they are links rather than copies.
<spiv> RenatoSilva: and those parents in turn have links to *their* parent(s), and so on.
<RenatoSilva> lifeless: I have never seen one for the scenario I mentioned though
<lifeless> RenatoSilva: yes, they will show like that; this indicates 'merged by' not 'contained within'
<poolie> lifeless: i'd like to make the state of the queues more visible
<poolie> maybe with a graph of open bugs etc
<poolie> and to have a list of tags perhaps
<spiv> RenatoSilva: so you can draw a diagram of the revision ancestry back to the start (a revision with no parents) by repeatedly following those links.
<poolie> and just generally get a better feel for how much things can be extended using apis
<lifeless> poolie: what I'd love: a google appengine web page; showing the bzr project [perhaps project-group even] bugs in my preferred sort order
<davidstrauss> spiv: so replace "contains" with "has children linking to it, which are:"
<davidstrauss> spiv: is that accurate?
<spiv> davidstrauss: if so, that notation is inaccurate, and should be trunk 22 { X 20, trunk 21 }
<poolie> lifeless: yeah me too but small steps
<vila> hi all
<poolie> i'd like to prototype some kind of dashboard
<davidstrauss> spiv: why would a single revision have children from two different branches?
<spiv> davidstrauss: and expanded out one more level would be trunk 22 { trunk 21 { trunk 20 }, X 20 { X 19, trunk 21 } }
<davidstrauss> spiv: I mean, direct childred
<davidstrauss> children*
<spiv> davidstrauss: that's what a merge is
<davidstrauss> spiv: A merge pulls in revisions from one other branch
<spiv> davidstrauss: also, "parent", not "children", unless you're asking a different question to what I think you are?
<davidstrauss> spiv: which may have children from other branches still
<poolie> lifeless: i guess overall the thing is that all the data is there, but the tools for querying it are not so great
<poolie> for something as simple as 'how many bugs are open in bzr' you need to iterate them
<poolie> which is the opposite of what you want
<davidstrauss> spiv: but if i merge from another branch and commit as rev 22, revision 22 should only have direct child revisions from one other branch
<lifeless> poolie: meep, theres no __len__ on search results?
<spiv> davidstrauss: it will have two parents
<spiv> davidstrauss: and no children (yet)
<davidstrauss> spiv: so, the indented revisions below a merge revision in log are *parents*?
<lifeless> poolie: the API folk have expressed a strong desire to be told about issues
<spiv> davidstrauss: those parents will be the previous tip of the branch you just committed in, plus the revision you merged in from the other branch.
<spiv> davidstrauss: have you seen "bzr viz" or "bzr qlog"?
<RenatoSilva>  trunk 22 { X 20, trunk 21 }?
<davidstrauss> spiv: haven't used any gui tools
<spiv> davidstrauss: the history is a DAG, and those tools do a good job of visualising it
<spiv> davidstrauss: "bzr log" makes an attempt to represent some the structure of that DAG in plain ascii, which is inevitably a bit hard in complex cases :)
<RenatoSilva> spiv: I'll jsut keep X updated by merging trunk into it regularly, then when I'm done I'll merge X into trunk, and then see what happens in log/qlog :)
<spiv> davidstrauss: if you pass --show-ids to log it will explicitly give the "parent:" links for each revision.
<spiv> RenatoSilva: good idea :)
<davidstrauss> spiv: ok, so let me rephrase my previous statement. "rev 22, which has parents {X's 18, 19, 20}. Also, X's 20 has parents {trunk's 18-21}.
<Peng_> A revision only has 1-2 parents. But its parents have their parents, and on up the chain.
<davidstrauss> spiv: I still don't see how a revision could have parent revisions other than (1) in the same branch and (2) in one other branch
<spiv> davidstrauss: "rev 22, which has parents {trunk 21, X 20}."
<lifeless> Peng_: N parents
<Peng_> (Not that it has to be restricted to a simple chain.)
<lifeless> Peng_: hg has the 2 thing
<davidstrauss> spiv: Is rev 22 in X?
<Peng_> lifeless: Oh, I thought bzr did too.
<spiv> davidstrauss: "and consequently some of its ancestors are X 19, X 18, etc."
<Peng_> Bazaar supports octopus merges?
<spiv> Peng_: yes
<lifeless> Peng_: nope, 0 through to 'overflow a 4K b+Tree zlib page'
<lifeless> Peng_: which is 'many'
<RenatoSilva> davidstrauss: this stuff is really ahrd to understand :)
<RenatoSilva> hard
<davidstrauss> RenatoSilva: Is rev 22 on branch X?
<Peng_> lifeless: I hope that doesn't mean there will be some obscure index exception instead of a simple WhatTheHellAreYouDoingError.
<Peng_> "bzr merge" will let you do it?
<lifeless> Peng_: it will except on commit; and yes bzr  merge will let you do it - --force
<RenatoSilva> davidstrauss: I mean the whole subject
<davidstrauss> Given that rev 22 has parents X:22 and trunk:21 (according to spiv), it should follow that rev 22 is either on branch X or trunk, correct?
<RenatoSilva> davidstrauss: I can't see it as anything different from the weird rev 22 { X 18, 19, 20 { trunk 18-21 }  }
<davidstrauss> I meant "Given that rev 22 has parents X:20 and trunk:21 (according to spiv), it should follow that rev 22 is either on branch X or trunk, correct?"
<RenatoSilva> davidstrauss: I'll just try to do it in pratice and see what happens
<Peng_> lifeless: Cool. I always figured --force would lose the other revision information or something, like with a cherrypick.
<spiv> davidstrauss: yes, I'm talking about the example where X is merged into trunk
<spiv> davidstrauss: e.g. "cd trunk; bzr merge path/to/X; bzr ci"
<davidstrauss> spiv: OK, this suddenly makes a bunch more sense.
<davidstrauss> spiv: I was assuming rev 22 was on yet another branch
<spiv> Which AIUI was the example under discussion
<spiv> But I might be wrong :)
<spiv> davidstrauss: phew :)
<davidstrauss> spiv: and that's why i couldn't understand how it could have parents on two other branches
<lifeless> spiv: it was trunk to X
<spiv> lifeless: hmm, skimming scrollback, I see both
<spiv> lifeless: the most proximate to where I started clarifying notation was X to trunk, though :P
<lifeless> spiv: no its not :)
<davidstrauss> It seems more likely that it's X->trunk, given that one of the parents is rev 21 on trunk.
<lifeless> spiv: :08 RenatoSilva asked, 5 lines later or so you said you didn't get the notation :)
<davidstrauss> (And knowing that the new revision is 22)
<poolie> lifeless: https://edge.launchpad.net/hydrazine
<poolie> barely anything there
<lifeless> a foaming agent huh?
<davidstrauss> If it were trunk->X, the new revision (22) would have to have rev 21 on X as a parent
<lifeless> by definition, yes.
<lifeless> branch contents are recursively defined
<lifeless> rev 21 is the first parent of rev 22
<RenatoSilva> so it really is trunk's 22 { X's 18, 19 and 20 { trunk's 18, 19 } }  ?
<poolie> lifeless: 'dangerously unstable'... 'used in various rocket fuels'
<poolie> '  These reactions are extremely exothermic (the catalyst chamber can reach 800 Â°C in a matter of milliseconds,[22]) and they produce large volumes of hot gas from a small volume of liquid hydrazine,[23] making it a fairly efficient thruster propellant '
<lifeless> :)
<poolie> i aspire to making a fairly efficient propellant
<poolie> we shall see
<davidstrauss> When is the current "edge" version of LP going stable?
<poolie> 3.0 is targeted for the end of this week
<davidstrauss> nice
<poolie> and it'll run bzr 2.0.0 to
<poolie> too*
<spiv> lifeless: yes, I see :08, but :11 is more proximate to me :P
<davidstrauss> poolie: Is there a comprehensive listing of changes?
<poolie> in lp? or in bzr?
<davidstrauss> poolie: in lp
<poolie> i don't know, sorry
<davidstrauss> poolie: bzr 2.0 is pretty obvious with the changelogs
<poolie> well, the branch is public
<RenatoSilva> what's the recommended comment when commiting a merge with a lp branch? "merge with lp:project" ?
<poolie> https://code.edge.launchpad.net/~launchpad-pqm/launchpad/devel
<poolie> RenatoSilva: i guess that's fine, but maybe say why
<davidstrauss> RenatoSilva: Given that the merge will always be directly on "lp:project," it would mean every merge commit would be identically explained.
<davidstrauss> RenatoSilva: It's best to list any bug or question that's related.
<RenatoSilva> always be directly on "lproject," ?
<spiv> RenatoSilva: that's fine, or even "merge from trunk", although as poolie says you're probably doing the merge for a reason, so stating that reason in the commit message is a good idea.
<davidstrauss> RenatoSilva: "Merge changes from branch lp:~davidstrauss/pressflow/blah to fix LP #23424"
<ubottu> Launchpad bug 23424 in pango1.0 "Opentype Latin fonts poorly handled" [Medium,Fix released] https://launchpad.net/bugs/23424
<spiv> RenatoSilva: e.g. "Merge from blah to get bugfix for 1234"
<RenatoSilva> davidstrauss: the reason for merging is always the same: to keep up-to-date with trunk
<davidstrauss> RenatoSilva: Oh, you mean a merge from trunk into your feature branch
<davidstrauss> RenatoSilva: I was assuming this would be into trunk from a feature branch
<spiv> But personally I've often done just "Merge from trunk", and left the rationale implicit (keeping up to date to minimise integration headaches)
<davidstrauss> Yeah, it's not important to be too detailed when merging from trunk to keep a feature branch updated.
<davidstrauss> The opposite direction is where the commit messages matter more than anywhere
<spiv> If I'm merging from an unusual source or for an unusual reason I would say why, though.
<RenatoSilva> davidstrauss: yes, X into trunk would be "merge with lp:~user/project/subject", and I think bug numbers and explanations they're all in the branch, the problem is if it is deleted after merging
<RenatoSilva> doesn't source branch go automatically into commit metadata?
<davidstrauss> RenatoSilva: Merged revisions retain all data post-merge
<RenatoSilva> davidstrauss: Merged revisions retain all data post-merge?
<RenatoSilva> Aren't I repeating info when typing branch name in commit?
<spiv> RenatoSilva: merge copies all the revisions that are referenced (and not already present)
<Peng_> I prefer commit messages like "AutoWidget 3.0 support (Some User, #12345)".
<Peng_> I guess it would make sense to include the branch URL too, though.
<RenatoSilva> Peng_: doesn't it go into commit metadata?
<davidstrauss> RenatoSilva: The branch URL isn't the same as the branch short name
<RenatoSilva> ok url is better
<spiv> RenatoSilva: (and recursively, so parents of parents of parents, etc, will be copied.  So if you merge a branch to trunk it is possible to later rebranch that old branch from trunk)
<RenatoSilva> if url is stored, then no need of even the word merge
<RenatoSilva> you just say "fix for problem x" or "new feature y", it doesn't matter whether it is a merge or regular revision
<spiv> RenatoSilva: basically, whatever works well for you :)
<RenatoSilva> I just think it's a bit weird having to put any message for just keeping up-to-date with trunk
<RenatoSilva> spiv: but I want to know if urls are stored or not :)
<spiv> RenatoSilva: No
<spiv> Not in the history.
<davidstrauss> RenatoSilva: you might prefer rebase
<RenatoSilva> spiv: so it says it is a merge, but don't say a merge with what?
<davidstrauss> RenatoSilva: I personally hate rebase
<RenatoSilva> what's rebase?
<davidstrauss> RenatoSilva: Please use google
<spiv> RenatoSilva: the history has a full copy of all the revisions from the source branch that you merged from.
<spiv> davidstrauss: hmm, I don't see how rebase would help here
<RenatoSilva> spiv: i know
<RenatoSilva> spiv: but you don't know from where they came from if you don't have urls
<davidstrauss> spiv: It would eliminate RenatoSilva having to write commit messages for merging from trunk
<spiv> True, but why do you need where they came from if you have the commits themselves already?
<davidstrauss> RenatoSilva: It's literally impossible for bzr to guess the canonical URL for a branch at merge time
<spiv> I.e. what information does "where they came from" tell you that can't already get from the commit messages, authors, etc in the actual commits?
<spiv> davidstrauss: oh, I see.  I think that would be the tail wagging the dog, personally.
<davidstrauss> spiv: Indeed.
<RenatoSilva> I'm thinking of a workaround: merge X into trunk locally, delete lp's X, push local trunk as X. How about it :)
<davidstrauss> So, if Launchpad is launching with bzr 2.0 this week, does that mean bzr 2.0 is going stable, too?
<davidstrauss> RenatoSilva: How does that change anything?
<RenatoSilva> davidstrauss: humm, true :(
<lifeless> 2.0 is already stable
<RenatoSilva> I just think up-to-date merging is not natural
<davidstrauss> RenatoSilva: Rather, it would just create a very confusing history.
<davidstrauss> RenatoSilva: What do you consider a natural alternative?
<lifeless> RenatoSilva: you don't need to delete lp's x; just push over it
<lifeless> RenatoSilva: I think you could do your workaround; it will look very similar, but you won't be able to as easily tell where you merged trunk, which means you won't know why a bug was introduced.
<RenatoSilva> davidstrauss: well s/merge X into trunk/bzr send X > trunk, how about it
<RenatoSilva> a natural way is one just like I'm cerating X NOW
<davidstrauss> lifeless: I disagree. There's a big problem with the proposed workaround: every time he updates from trunk, the commit history for his feature branch gets buried in the parents of a merge revision.
<RenatoSilva> and applying the changes, that before were revs 18, 19 and now would be palin revs 22, 23
<davidstrauss> lifeless: It creates a history with a depth at least as many parents deep as the number of merges with trunk
<RenatoSilva> Imagine I can get X and extract the changes on raw diffs
<RenatoSilva> then I bzr branch trunk and manually apply the diffs
<RenatoSilva> and commit
<RenatoSilva> just like I'm cerating X today
<davidstrauss> RenatoSilva: "bzr send" is just a tool for packaging merge data
<RenatoSilva> davidstrauss: well it would not work as the branches have diverged
<davidstrauss> RenatoSilva: What does "send" have to do with the branches diverging?
<RenatoSilva> davidstrauss: I'd pry to bzr pull md.diff
<RenatoSilva> try
<davidstrauss> RenatoSilva: I think you should look at http://bazaar-vcs.org/Rebase before trying such an ill-advised workflow
<davidstrauss> RenatoSilva: Taking a fresh branch, applying the old diff, and committing is just a bad approximation of rebase
<RenatoSilva> ok thanks
<RenatoSilva> as I have a commit prompt in my front, I'll just type merge with trunk by now :)
<davidstrauss> RenatoSilva: Rebase treats updating a feature branch from trunk as fundamentally different from merging
<davidstrauss> RenatoSilva: I advise against using the language "with" for bzr merges
<RenatoSilva> merge from trunk?
<davidstrauss> RenatoSilva: In Bazaar, merges are directional. Branch A can be merged into B, or B into A, but there is no single operation that does both
<davidstrauss> RenatoSilva: Either "merge from trunk" or "merge trunk into _____"
<RenatoSilva> merge trunk into here
<davidstrauss> RenatoSilva: "From" is generally best because the "to" is obvious
<davidstrauss> RenatoSilva: "To" is always the current branch
<RenatoSilva> with is obvious too
<RenatoSilva> merge with trunk cannot mean merge this into trunk
<davidstrauss> RenatoSilva: Not really. Once your revisions get merged back into trunk, the "merge with trunk" commit messages may be a bit ambiguous
<RenatoSilva> because the comment would be in trunk, not in this branch :)
<RenatoSilva> ok ok, not that bad to be clearer anyway
<davidstrauss> RenatoSilva: Remember that every commit you create on the feature branch will be browsable on the trunk after the feature branch is merged back into trunk.
<RenatoSilva> ok
<RenatoSilva> "Merging trunk changes"
<RenatoSilva> how about it
<RenatoSilva> or "Trunk changes merge"
<davidstrauss> RenatoSilva: "Merge from trunk" is my usual one
<RenatoSilva> Maybe rebase or something similar could be in bzr as default
<davidstrauss> RenatoSilva: "changes" is redundant. All revisions and merges are of "changes"
<davidstrauss> RenatoSilva: rebase is distributed with most bzr installs
<RenatoSilva> I don't like 'from'
<davidstrauss> RenatoSilva: Is there a reason why?
<RenatoSilva> why don't you like rebase?
<davidstrauss> RenatoSilva: http://fourkitchens.com/blog/2009/04/20/alternatives-rebasing-bazaar
<RenatoSilva> Merging trunk --> trunk changes into here or here's changes into trunk??? Merging trunk changes ----> oh, trunk changes were merged (obviously, into here)
<RenatoSilva> bookmarked your link, thanks
 * vila . o 0 (God bless people that fix loom test failures :-)
<davidstrauss> vila: Is Looms being actively developed?
<vila> davidstrauss: supported rather than developed, but it's here to stay under one form or another if that's what you care about
<davidstrauss> vila: What's the preferred option, that other one that works among multiple branches?
<vila> davidstrauss: I use loom or regular branches myself, but some people seem more at ease with bzr-pipeline (if that's what you're referring to :)
<vila> davidstrauss: I don't have an opinion on their respective merits since I use only loom but I heard that pipeline were fitting its users needs
<vila> davidstrauss: both are work in progress AIUI
<davidstrauss> Pipeline looks like a crappy copy of the git branching interface
<davidstrauss> :-(
<RenatoSilva> http://img24.imageshack.us/img24/1857/imagemxv.png ---> WEIRD !
<davidstrauss> RenatoSilva: Looks normal to me
<RenatoSilva> davidstrauss: hard to understand, I mean
<davidstrauss> RenatoSilva: Granted, I've never used this application before, but this is what I see:
<RenatoSilva> absolutely crazzy actually
<davidstrauss> (1) upserprefs is branched from trunk
<davidstrauss> at 17
<davidstrauss> (2a) Revs 18-21 get made on trunk
<davidstrauss> (2b) The theme prefs work gets committed to userprefs.
<davidstrauss> (3) Merge from trunk -> userprefs
<davidstrauss> (4) Merge from userprefs -> trunk
<davidstrauss> RenatoSilva: right?
<spiv> davidstrauss: right :)
<RenatoSilva> davidstrauss: humm :)
<RenatoSilva> how about the numbers 17.1.1 and 17.1.2
<davidstrauss> It's unclear (and irrelevant) whether 2a or 2b happened before one another
<davidstrauss> RenatoSilva: The first number means you merged from a branch that was originally branched at revision 17.
<spiv> RenatoSilva: those are just the revision number's bzr assigns those revisions; http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#understanding-revision-numbers
<RenatoSilva> ok I just mean weird numbers
<davidstrauss> RenatoSilva: the revision numbers are unique for all numbers on the trunk
<davidstrauss> RenatoSilva: unique and stable
<RenatoSilva> I'd use 22.1 and 22.2 instead of 17.1.1 and 17.1.2
<RenatoSilva> what does the red lines and circles mean?
<davidstrauss> RenatoSilva: The red line is the merge into trunk from the feature branch
<davidstrauss> RenatoSilva: The red circles are unique revisions on the feature branch
<spiv> RenatoSilva: I think the colours are just to help you associate revisions from the same branch
<RenatoSilva> ok
<spiv> RenatoSilva: so qlog has arbitrarily chosen grey/black for trunk and red for userprefs, I think.
<RenatoSilva> maybe I get those numbers better later
<spiv> RenatoSilva: you can ignore the numbers if you like, you probably don't need to use them.
<davidstrauss> RenatoSilva: If we numbered like 22.1 and 22.2, the numbering wouldn't actually provide any useful data about the source of the revisions
<davidstrauss> RenatoSilva: spiv is right; you can just treat the numbers as opaque strings
<spiv> davidstrauss: (actually, I usually am more interested in when revisions got merged than when they were branched, but that's another discussion...)
<RenatoSilva> ok guys
<davidstrauss> spiv: But it's obvious where revisions got merged in the bzr log --include-merges
<spiv> (and either way, a graphical tool like qlog is probably a nicer solution than interpreting dotted revnos)
<spiv> davidstrauss: ah, but that presumes I know when the revision was merged ;)
<spiv> davidstrauss: or requires me to log all of history
<davidstrauss> spiv: You mean by time?
<davidstrauss> spiv: Are you trying to answer, "Given revision ID X (and no other data), I want to know where it was merged into my current branch."
<spiv> davidstrauss: yes
<davidstrauss> spiv: There's no way to look that up with the log tool?
<spiv> davidstrauss: qlog or similiar does a good job of it (I haven't looked recently, so pardon my lack of precision), but not in core "bzr log", no :(
<spiv> Actually, qannotate is probably what I'm thinking of.
<RenatoSilva> what about bzr log --include-merges ?
<spiv> The use case is usually "look at annotations, see a line of interest, and wonder a) what the original commit that introduced that line was, and b) when it landed in this branch"
<spiv> And qannotate handles that very very nicely, IIRC.
<spiv> RenatoSilva: that will show all revisions, including merges, but I'd rather not have to grep all of history if I can help it :)
<davidstrauss> spiv: Actually, you can. It's just two steps.
<davidstrauss> spiv: bzr log -rX --show-ids
<davidstrauss> spiv: bzr log -rrevid:[parent-from-last-command-results]
<davidstrauss> wait
<davidstrauss> spiv: sorry
<davidstrauss> spiv: that's just the source
<spiv> davidstrauss: right :)
<spiv> davidstrauss: given that qannotate exists and works so well I'm probably not going to scratch this itch any time soon, but it probably wouldn't be so hard to extend log somehow to handle this.
<spiv> Possibly with mainline:REV revisionspec or something.
<davidstrauss> spiv: Looking into the bzr architecture, it appears that there's no way to directly determine the children of a revision.
<spiv> Right.
<davidstrauss> spiv: It has to be constructed by iterating through the mainline
<spiv> Yes, graph-walking is required.  But that's how bzr determines the x.y.z revno anyway.
<davidstrauss> spiv: How does the second number of a merged revision get set if I branch from A->B, then B->C, and then merge C->A?
<vila> lifeless: bug #433843 and associated fix in lp:~vila/qbzr/433843-fix-isolation-breaks
<ubottu> Launchpad bug 433843 in qbzr "test failures trying to escape isolation" [Undecided,Fix committed] https://launchpad.net/bugs/433843
<lifeless> vila: is there a merge proposal?
<davidstrauss> spiv: s/second number of a merged revision/second number of the merged revisions/
<vila> lifeless: permit_dir('/') sounds like the easiest way to fix it and not being that heretic
<lifeless> vila: I'll need to look
<vila> lifeless: it's in qbzr just as sec
<davidstrauss> spiv: Oh, bzr must just assign that number at merge time
<spiv> davidstrauss: So multiple levels of merge between mainline and that rev, you mean?
<davidstrauss> spiv: nevermind
<spiv> ok :)
<vila> lifeless: https://code.edge.launchpad.net/~vila/qbzr/433843-fix-isolation-breaks/+merge/12148
<davidstrauss> spiv: I was trying to figure out how the second number (which is the ordinal of branches off the revision in the first number) was assigned when branching is read-only and transitive
<davidstrauss> spiv: But it's clear there's no way that could happen until merge-time
<spiv> davidstrauss: right
<ngnp> I want to merge 2 websites codebase. Yesterday I upgraded 1 website. Added a 'before upgrade'. Now I want to start working on site 2 with that tag.
<ngnp> Can I continue working in the same directory? I still not understand bzr branching :(
<ngnp> s/Added a/Added a tag/
<RenatoSilva> thanks everybody
<davidstrauss> ngnp: Don't your sites have different directories?
<ngnp> davidstrauss: partly ... but the main code is the same
<davidstrauss> ngnp: you can branch from the tag
<ngnp> in the same working dir?
<davidstrauss> ngnp: i would use a different dir
<ngnp> otherwise I have to reconfigure apache :(
<ngnp> davidstrauss: I guessed I had to. I hoped for a 'switch to' tag
<davidstrauss> ngnp: you can revert to a tag
<ngnp> and then merge later with current .bzr or through a push
<davidstrauss> ngnp: I'm still not clear on your workflow
<ngnp> davidstrauss: me neither ... with eclipse/svn i'm used to 'switch to' and then continue working on that older/newer version. Code stays in same dir. But that is with central repo. Now I have a local. So I guess I need more experience with bzr ...
<ngnp> Tnx for your time :)
<davidstrauss> ngnp: you can't switch to tags in bzr
<davidstrauss> ngnp: tags are merely aliases for revision numbers
<ngnp> ic ... so I have to "bzr pull -r 7" then upgrade site 2, then merge with site 1?
<davidstrauss> ngnp: I still don't understand your upgrade workflow, but I have to head off.
<davidstrauss> ngnp: Sorry :-/
<ngnp> np .. cy
<bialix> heya
<trondn> why do bzr status show unknown filenames from the root (if my cwd isn't root of the repository), and if I try to add them it only tries to do so relative from my cwd???
<bialix> trondn: this is old bug
<trondn> bialix: ah.. ok.. just got bitten by it...
<bialix> heh
 * igc dinner
<igc> bialix: 429911 has some further info now -bbl
<bialix> igc: hi
<bialix> ubottu, say me please URL for bug 429911
<ubottu> Launchpad bug 429911 in bzr-explorer "BZR > Explorer > UnicodeDecodeError" [High,New] https://launchpad.net/bugs/429911
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<lifeless> trondn: its a mismatch
<bialix> good ubottu, take a cookie
<lifeless> trondn: there is a desire to have commands report paths from the root; but its [fairly clear to me] that this doesn't work well with paths users type in from their shell
<lifeless> trondn: and commands like add work from that basis
<bialix> igc: re that bug, we seems to get mbcs encoding path to wordpad.exe. we need to cast it to unicode.
<trondn> lifeless: I would expect that I could use the output from one command as the input to the next one without having to change directory.. That said, its not that big of a problem :)
<lifeless> trondn: me too!
<lifeless> vila: sorry, was on a call
<vila> lifeless: no worries
<lifeless> vila: MemoryTransport
<lifeless> vila: someone may have a branch at /
<bialix> vila: check isolation is bad idea
<lifeless> bialix: its a very good idea; its telling you about latent bugs in your test suite
<vila> lifeless: in theory yes, that's why I restricted the permit_dir('/') to very very narrow tests
<lifeless> vila: they look like they should cope with MemoryTransport, no ?
<vila> they all want to check a '/not/existant/branch'
<bialix> aaron insists that MemoryTransport is not very well
<vila> bialix: MemoryTransport is not *yet* very well, it doesn't mean we can't take it there
<bialix> vila: does your patch compatible with bzr 2.0?
<lifeless> bialix: he's asserted that MemoryTree is a problem; its not very complete which I agree with, but PreviewTree writes to disk so is slow.
<bialix> vila: or more precisely: with 1.17 API?
<lifeless> MemoryTransport is fully compatible with Transport, I'm not aware of any issues with it.
<vila> bialix: does your test suite pass ?
<bialix> vila: I'm using 1.18.1
<lifeless> bialix: that patch won't be comaptible with < 2.1
<bialix> vila: test suite pass for me
<bialix> vila: w/o your patch
<vila> bialix: feel free to delay landing that patch, I'm not going to play tricks to guarantee API backward compatibility for potentially borken tests...
<bialix> you can make self.permit_dir optional
<NET||abuse> hey folks,, looking for an article on using bzr in deployment of web site code.
<NET||abuse> i saw an article before where you setup a bare repository on your webserver, then you setup some kind of hook which exports the code straight to the site working directories on pushing up from your local branch.
<NET||abuse> does anyone know of this technique or know where the article might live.. google isn't getting me there today.
<Kinnison> Personally I use a cron job
<Kinnison> because my site needs an amount of 'building' before it can go live.
<Kinnison> My cronjob pulls, if any updates happened, it runs 'make check' and then rsyncs the content
<NET||abuse> the site i'm working on doesn't need any building like that, just need to export 2 tree paths to locations in the website accounts directories.
<NET||abuse> just looking for a way to push it up to the webserver
<vila> bialix: I'm not part of qbzr-devs 8-) I can't supersede my own submission :D
<vila> lifeless: nice suggestion, works like a charm
<vila> lifeless: (MemoryServer is needed instead of MemoryTransport of course, but that was semi-obvious ;-)
<vila> bialix: bah forget my last remark, the UI has changed again and I thought I couldn't resubmit where in fact hte button has just been moved
<fullermd> Oh good.  I was just thinking, "Gee, bzr _seems_ like a decent project, but where are the long license discussions?"
<bialix> vila: so what should I do?
<vila> fullermd: bzr is a GNU project :-D
<rusty> Hi all...  Can I just double-check: .bzrignore files must be in top level of project, right? And there's no comment syntax?
<Peng_> rusty: 1.) Right. 2.) Comments start with #
<rusty> Peng_: ah, thanks... I couldn't find any documentation on that point.
<vila> bialix: well, I applied to join the team, feel free to approve me :-D As for the patch, I think I addressed all concerns raised by lifeless and you, so again, feel free to approve and merge :-P
<rusty> Peng_: does \ escape # then?
<Peng_> rusty: Noo idea.
<spiv> fullermd: haha
<Peng_> rusty: Try it and see! :D
<bialix> vila: so I should feel free as twice as usual?
<lifeless> rusty: hi
<fullermd> Now all it needs to do is read email, and it'll be a Real Opensource Project.
<spiv> rusty: I suppose [#] would work too...
<lifeless> rusty: you pung me about subunit; did you get my replies ?
<rusty> lifeless: hi!  Just back on the .vcignore tradmill...
<vila> bialix: yeah, welcome to free software world :D
<bialix> triple free
<bialix> ta-da
<rusty> lifeless: yep!  But then I went away for 3 weeks, and the draft sitting there when I got back today seemed stale :)_
<lifeless> rusty: I'm doing a subunit talk @ LCA
<lifeless> rusty: so the more adoption between now and then the better :)
<bialix> we decided to make part of our new project free (LGPL)
<rusty> lifeless: I've pretty much decided to go with libtap for the moment, but the API could be easily changed to output subunit directly (rather than via tap2subunit)
<spiv> rusty: in fact, I see that the default ~/.bazaar/ignore uses [#] to escape a rule :)
<lifeless> rusty: whats the usecase/situation?
<bialix> vila: if you join qbzr-dev you'll get all bugmails
<rusty> spiv, bialix: \# works too.
<rusty> Oops, I mean Peng_
<vila> bialix: ha, right :-/
<Peng_> rusty: Cool. (You mean it does what you want, right?)
<rusty> Peng_: I'm compiling a table of the different VC systems ignore semantics, that's all!
<vila> bialix: there should an option somewhere that allow me to unsubscribe to these mails, otherwise, I'll filter them, anyway, I think I better join anyway
<lifeless> rusty: so, tell me more about where you're choosing between tap/subunit
<lifeless> rusty: or I'll have to supply you with beer and ask you @ LCA
<bialix> vila: ok, be good boy and don't commit wild code then.
<bialix> vila: approved, welcome to the club
<vila> bialix: :-D
<rusty> lifeless: because I maintain libtap? :)
<lifeless> rusty: :P
<lifeless> rusty: then I should talk to you about how subunit is an improvement over tap :)
<lifeless> rusty: however, you said something about samba?
<rusty> lifeless: naah, line-at-a-time rules :)
<SamB_XP> and here I thought tap was to do with ethernet ...
<lifeless> rusty: shame that it can't detect unfimished
<rusty> lifeless: well, it can if you have a plan...
<SamB_XP> rusty: you mean, like a plan to cook and eat you ?
<lifeless> rusty: I know :> [tap2subunit handles that]
<rusty> lifeless: yes, I want to put some unit test infrastructure into the samba tree.  They already use subunit, so makes sense to aim for that.
<lifeless> rusty: they have a thing called libtortue
<lifeless> sorry
<lifeless> libtorture
<lifeless> have you found that?
<rusty> lifeless: yeah, but it confuses torture testing and performance testing with correctness and unit testing.
<lifeless> ah
<lifeless> jelmer: ^
<rusty> lifeless: I really want just unit tests, ie. "hey, I really screwed this up" :)
<lifeless> rusty: so I think a good reason to use libsubunit for stuff in the samba tree is because it's easier ;)
<lifeless> rusty: tap2subunit isn't ugly, but its not brilliant either. Much better to start with the same protocol, unless you have some external code you're just exposing.
<rusty> lifeless: my tdb and talloc tests are already using libtap tho :)
<rusty> (CCAN went for libtap)
<lifeless> are you at all interested in being able to drop maintenance of libtap ?
<rusty> lifeless: TBH I think subunit is a YA project.  Tap is nice and browsable, and simple.
<lifeless> SamB_XP: http://en.wikipedia.org/wiki/Test_Anything_Protocol
<SamB_XP> rusty: young adult ?
<lifeless> SamB_XP: yet another
<SamB_XP> ah
<NET||abuse> yarg,, keyserver down?
<lifeless> SamB_XP: pejorative sometimes, sometimes adopted such as 'yaml' - yet another meta language
<SamB_XP> yeah, I've seen many programs whose names start with "ya" for that reason
<rusty> lifeless: my main issue with TAP is lack of nesting, which is finally being fixed...
<lifeless> rusty: I disagree rather strongly there; taps simpleness pushes burdens onto the programmer/editor; I can go into some detail of the things it inhibits another time
<rusty> lifeless: In my limited experience it has been sufficient.  I don't like complex tests :)
<lifeless> rusty: this isn't about the test though - its about what you do with them
<SamB_XP> rusty: it's not so much complex tests as nested test suites, I think
<lifeless> rusty: taps not introspectable; you can't run - or even sensibly approach the problem - of running just a single thing from tap in an edit-test cycle, as a for-instance.
<rusty> SamB_XP: yes, I agree.  Which is why I'm happy about the nested TAP implementation.  I have exactly this issue with ccanlint, in fact.
<lifeless> rusty: anyhow, you're happy with tap - great. Let me know of any bugs or glitches you have with tap2subunit and I'll fix em.
<rusty> lifeless: unit tests should be so fast you don't need to :)
<SamB_XP> rusty: yeah right!
<lifeless> rusty: ack; see my blog recently ;)
<SamB_XP> some of us use finite-clocked computers
<lifeless> rusty: but, you shouldn't have to change test _protocol_ to work with integration tests, acceptance tests, and so forth.
<SamB_XP> have to admit bzr does a pretty good job of using the same framework for acceptance-type tests as for plain-old unit tests ;-)
<lifeless> when you change protocols you change toolchains; unless one toolchain is a strict superset and can read the other protocol
<rusty> lifeless: it's not clear why that universal protocol shouldn't be TAP tho!
<SamB_XP> rusty: well, not having enough features might do it ;-)
<SamB_XP> lifeless: maybe you should write a blog entry about it ;-)
<lifeless> SamB_XP: I have a 'real testing needs XXX' list to finish; my most recent post to the TIP list was one of the items on that list.
<SamB_XP> tip list?
<lifeless> SamB_XP: when I get those items checked off, I'll feel confident going 20 rounds vs TAP anyday :)
<lifeless> SamB_XP: testing-in-python@lists.idyll.org
<SamB_XP> ah
<jelmer> rusty: I think you mean smbtorture
<lifeless> rusty: there are a bunch of reasons that make it clear to me ;). it can't tell the different between streaming & trailing plans - unless its told at the front :P. fixtures aren't addressable; the model it encodes isn't comaptible with xUnit(arguably _way_ more successful than TAP), it can't attach [for transport] test artifacts (neither can subunit, in progress), it can't provide progress [unless it has an up front plan]
<jelmer> rusty: libtorture is just a unittest framework
<lifeless> hmm, did that cut off ?
<jelmer> hi, btw :-)
<lifeless> hi jelmer :)
<lifeless> jelmer: where did that run-on paragraph end for you jelmer ?
<jelmer> "front plan]
<lifeless> oh cool
<rusty> jelmer: hi :)  Yes, smbtorture conflates a lot of different tests.  I'm mainly concerned about the lib/ dir; it'd be nice to have good unit tests for stuff in there.
<lifeless> rusty: jelmer wrote a *separate* think 'libtorture' - its not smbtorture
<lifeless> s/think/thing/
<jelmer> lifeless: some things in smbtorture use libtorture though
<lifeless> sure, but rusty is seeking pure unittesting, which is what I thought, and you're confirming, libtorture is
<jelmer> lifeless: initially we just had very big functions that would return 0 or 1 depending on whether all of the hundreds of subtests they ran succeeded
<jelmer> lifeless: right
<jelmer> rusty: there are some things that do have tests
<jelmer> rusty: in particular for some of the functions in lib/util/ we have basic unit tests
<jelmer> rusty: see lib/util/tests
<lifeless> rusty: there's more, but its not really a 'quick over IRC' discussion, so I'm inclined to shelve it until either I get time to write a serious blog post on it (and endure any flames :P) or we're face to face and I can show you stuff
<lifeless> rusty: you might like to watch the SLUG talk I did a couple of months back; it was a 'oh we need a speaker urgently' deal, but not bad all the same
<rusty> lifeless: sure... I've been happy with tap.  But I *always* use a plan.  The arbitrary numbering of tests, rather than being explicitly labelled: well, you should see what libtorture does :)
<lifeless> rusty: I'm happy for users to make their life as hard as they want :)
<rusty> lifeless: ccan uses a simple system where independent test cases go in separate source files.  So ideally only dependent tests are in a single file.  It works quite well for isolating tests (though a gdb helper to stop on the first fail would be a win).
<rusty> lifeless: for CCAN, I want any idiot to be able to write tests.  libtap has the benefit of simplicity.  libtorture starts to push the curve, *and* you don't get "addressable fixtures" (if that means what I think it means?)
<jelmer> rusty: libtorture does give you all that's required for addressable fixtures (if I am guessing right what they are)
<jelmer> rusty: addressable fixtures just aren't implemented yet
<lifeless> an addressable fixture is just naming a single test
<lifeless> rusty: I'm not sure I want idiots writing C code :) but I agree with the desire for simplicity
<rusty> lifeless: right,that's what I figured.  tap uses numbers, which is a movable feast unless you have the source in front of you.
<rusty> lifeless: (and even then, figuring out the 113th test can be nontrivial)
<lifeless> precisely
<rusty> lifeless: but in libtap the test name (if using "ok1" which is the simplest) is the code, which is the same as libtorture's torture_assert().
<lifeless> rusty: interesting
<lifeless> rusty: have you seen check ?
<lifeless> rusty: you'll probably hate it, because it needs some boilerplate to insert it into a project, but I'm curious :)
<rusty> lifeless: no?
<lifeless> https://sourceforge.net/projects/check/
<lifeless> (or apt-get install check)
<lifeless> its an xUnitish C unittesting library
<lifeless> forks() before fixtures
<lifeless> supports some half decent higher order assertions - not brilliant though
<rusty> lifeless: this is *not* helping me get through my email backlog!!
<lifeless> rusty: phfhtaw
<Alcmene_> Eer... Hello? :)
<Alcmene_> Is there anyone here available to give a little bit of help for a problem with bzr on OS X, whose cause is an upgrade from 1.13 to 1.17?
<Peng> I probably can't help, but I'm curious what your problem is.
<Alcmene_> well, mostly the fact that I get the following notice every time I use bazaar :
<Alcmene_> "Key 'foreign-mapping-upgrade' already registered"
<Alcmene_> Unable to load plugin 'rebase' from '/Library/Python/2.5/site-packages/bzrlib/plugins'
<Alcmene_> fact is, the rebase plugin exists in the given directory
<jelmer> Alcmene_: you have incompatible versions of svn and rebase
<Alcmene_> so, the problem is with svn and not bzr ?
<Alcmene_> anyway, I've been living with this notice for two weeks, so it's not the main problem
<Alcmene_> the big one happened when I tried to use the "push" command
<Alcmene_> bzr: ERROR: The API for "<module 'bzrlib' from '/Library/Python/2.5/site-packages/bzrlib/__init__.pyc'>" is not compatible with "(1, 13, 0)". It supports versions "(1, 17, 0)" to "(1, 17, 0)".
<jelmer> Alcmene_: with bzr-svn
<Alcmene_> I therefore assume that the upgrade from 1.13 to 1.17 didn't go totally well, which I already suspected before
<Alcmene_> unfortunately, I haven't found any way to uninstall bazaar completely
<Alcmene_> since I haven't found a full list of all installed data
<Alcmene_> jelmer: isn't the bzr-svn plugin packaged with the bzr isntaller itself? I don't understand why I should upgrade it on its own :s
<Peng_> 'bzr plugins -v' shows their paths.
<Peng> So will the traceback in .bzr.log (use 'bzr version' to see where that's located).
<jelmer> Alcmene_: I'm not saying you should upgrade bzr-svn necessarily, just that the versions of bzr-svn and bzr-rebase you have installed are incompatible with each other
 * Alcmene_ is checking the log
<Alcmene_> jelmer: are you sure about that? Cause the log says "Plugin name svn already loaded", which is quite the same as "Key 'foreign-mapping-upgrade' already registered": makes me think that I have a plugin duplicate, one from 1.13, and one from 1.17. How does this sound to you?
<Alcmene_> Furthermore, the "IncompatibleAPI" message I gave earlier says that (unless I misunderstand something) my bzrlib module expects bzr to be 1.17 and not 1.13... While my bzr _is_ 1.17!
<fullermd> No, that's just unclarity of the message.  It means SOMETHING expects bzrlib 1.13 and got 1.17.
<Alcmene_> fullermd: mmh, that's interesting. Thanks!
<Alcmene_> Examinating the log, it seems that bzr-svn is called when trying to use "push"
<Alcmene_> so I think we have spotted our guilty module
<Alcmene_> however, if someone could tell me why the hell bazaar calls bzr-svn when pushing a bzr branch to an ftp server... :s
<jelmer> Alcmene_: it's not called, but loaded nonetheless
<jelmer> (all plugins are loaded when bzr is started)
<Alcmene_> I agree, it's always loaded (that's the cause of the notice I get every time), but it is actually used when using push
<Alcmene_> because it's only when using this command that svn-bzr outputs to the log
<Alcmene_> ...and only with it that I get an error and not just a warning
<jelmer> Alcmene_: it might be trying to see if the remote location happens to contain a svn repo
<Alcmene_> might be, yeah
<Alcmene_> anyway, I have the trace now, so perhaps I'll take a look at it
<Alcmene_> this IRC is logged and archives are publicly available, isn't it?
<Lo-lan-do> Hi all
<Lo-lan-do> Is there a way to do a bzr push without remembering the address of the pushed-to branch?
<Alcmene_> Hi Lo-lan-do
<bob2> Lo-lan-do: when you first push, bzr remembers that url and should use it in future if you just run 'bzr push'
<Lo-lan-do> bob2: Yes, and I'd like to avoid that in some circumstances :-)
<Alcmene_> bob2: he asks for the opposite ;)
<bob2> Lo-lan-do: sorry, totally missed the '-out'
<Alcmene_> Lo-lan-do: do you want to sometimes push to another server and have bzr remember the previous one instead?
<Alcmene_> Or do you want it to not remember at all?
<Lo-lan-do> Alcmene_: I want it to not remember at all.
<Lo-lan-do> The context is that I want to mirror a local repo into a remote one with pushes.
<Alcmene_> and don't want bzr to push every time you commit ?
<Lo-lan-do> Some of my local branches have push addresses memorised, which is fine.
<Lo-lan-do> Others don't, and then my mirror script will remember unwanted addresses.
<Lo-lan-do> Alcmene_: No, this is a maintenance script I intend to run from time to time only.
<Lo-lan-do> (I know about bound branchesÂ :-)
<Alcmene_> Lo-lan-do: (couldn't know, had to try ;) )
<Alcmene_> well, have you tried --no-remember?
<Alcmene_> cause the help tells you about --strict and --remember
<Alcmene_> but the --no-strict option exists, even though it is not listed
<Lo-lan-do> Ho-hum.
<Lo-lan-do> Good to know, let me try that.
<Alcmene_> perhaps have they implemented it too?
<Lo-lan-do> push --no-remember doesn't give an error message, but it still remembers the URL :-/
<Alcmene_> :/
<Alcmene_> from the doc:
<Alcmene_> If there is no default push location set, the first push will set it. After that, you can omit the location to use the default. To change the default, use --remember. The value will only be saved if the remote location can be accessed.
<Alcmene_> doesn't seem like they've thought that someone would _not_ want it to be remembered
<Lo-lan-do> I'll just have to patch it :-)
<Lo-lan-do> (someday)
<Lo-lan-do> In the meantime, I'll sed on the branch.conf
<Alcmene_> (omission that I totally understand, BTW  ;) )
<Alcmene_> Ok, so, just in case all of this is logged and someone happens to have the same problem as I had: the problem was an obsolete bzr-svn version
<Alcmene_> I know, sounds obvious :(
<Lo-lan-do> diff size stuff?
<fullermd> Lo-lan-do: You can set the push loc in the branch.conf to an empty string, and then it won't be touched (except by --remember)...
<Lo-lan-do> fullermd: But then IÂ lose the automatic remembering next time IÂ do a manual push.
<Lo-lan-do> But thanks for the idea :-)
<Alcmene_> well, you could add the --remember option to the default ones in the conf
<Alcmene_> or you could also, with your script, save the previous location, do the push, and re-write the previous location back
<jelmer> hi Lo-lan-do
<Lo-lan-do> Hi jelmer
<Lo-lan-do> Alcmene_: I think it might be simpler to just implement a working --no-remember option :-)
<Tak> hello jelmer
<Alcmene_> Lo-lan-do: might be, yeah ;)
<jelmer> hi Tak
<jelmer> Tak: Feel free to merge your branch into lp:monodevelop-bzr - I've approved it
<Tak> oh, ok
<Tak> I'm not overly familiar with how that works on launchpad :-)
<Tak> do you have any thoughts on how "Review Changes" should act when there are pending merges?
<jelmer> Tak: it should probably list the pending merges somewhere
<Tak> hmm...I don't have a ton of control over how that works without completely overriding/rewriting the UI for that panel
<Tak> I suppose I could try creating a dummy diffset with the merges grouped together
<Lo-lan-do> Can bzr reconcile fix "inconsistent parents" errors?
<fullermd> Yes.
<Lo-lan-do> Thanks, I'll try that.
<Lo-lan-do> I'm getting a KnitCorrupt error when pushing to a branch that has them.  Hopefully a reconcile will allow me to push again.
<fullermd> Lo-lan-do: I doubt the two are related.
<Lo-lan-do> fullermd: Indeed, the push failed.  I'm trying to start afresh.
<Tak> so how do I do a merge on launchpad? normal branch,merge,commit,push?
<beuno> Tak, yes
<Peng> beuno: So what did become of the t-shirt?
<beuno> Peng, I can't ship to the US, so I'm trying to score one in the London office, and send to you via snail mail
<Peng> beuno: Ah. That sounds complicated..
<beuno> Peng, it is, but I will eventually win
<Peng> How do t-shirts normally make it to the U.S.?
<Tak> so how does that interact with the merge proposal stuff? or are merge proposals just formalities?
<Peng> Tak: Merge proposals are an administrative thing, so people can work together to get a branch ready to merge.
<Tak> ok, so it's technically unrelated to the actual merging
<Peng> Tak: They're of great value, but they're completely disconnected from runn -- yeah.
 * Tak nod
<Peng> That could be changed in the future, of course.
<Tak> I was wondering if I was missing the big green MERGE! button
<Peng> There already is...something to help automatically merge things, but I don't remember the name.
<fullermd> Oh, there's your problem.  It's chartreuse.
<Peng> What's chartreuse?
<Lo-lan-do> Chartreuse is a problem?
<Lo-lan-do> Try GÃ©nÃ©pi instead.  It even tastes better.
<fullermd> The big MERGE! button.
<Peng> Oh!
 * Peng looks up chartreuse on Wikipedia.
<Peng> Yellow-green? I did not know that.
<fullermd> Think of how much happier you were 3 minutes ago   :p
<Peng> Now that LP is open-source, I can go download it and change it to chartreuse and set up my own instance, right?
<fullermd> Only if you GFDL it.
 * SamB_irssi wonders why bzr-search creates so many files in /tmp in the process of indexing a branch...
<Peng> It does?
<SamB_irssi> Peng: it sure seems to!
<SamB_irssi> try it with a branch of lp:coq
<SamB_irssi> it keeps waffling between files like "/tmp/bzr-index-B4Xk5c" and files like "/tmp/tmpoubU4Q"
<jam> SamB_irssi: I believe when we create a btree index, we build the content in tmp
<jam> and then copy the bytes to the final location
<jam> That way we don't hold the whole content in memory
<jam> and we can be sure that we can 'seek', etc.
<Tak> that explains why I didn't see it - my font color is already set to chartreuse
<SamB_irssi> jam: makes sense ... but you repeatedly open new BTree files in /tmp ... like, way faster than I can run ls
<SamB_irssi> that part, not so much
<jam> SamB_irssi: this is while building the index, right?
<jam> I believe bzr-search creates 1 index per prefix, or something like that
<jam> I don't know the specific storage mechanism
<jam> but it creates a *lot* of little indexes
<SamB_irssi> jam: a buttload, yeah
<jam> and puts them all together and then indexes that, I believe
<SamB_irssi> why does it put them each in a file before indexing it ?
<jam> the file you see *is* the index
<jam> we just write it to a temp file
<jam> and then move it across
<jam> i think
<jam> I haven't researched the bzr-search code much
<jam> I also believe it builds the index 2k revs at a time
<Peng> That's right.
<jam> search seems to generate... 4 different indexes
<jam> revisions, terms, documents, terms2
<jam> and that may just be the top level view and those themselves have sub indexes
<Peng> Indexilicious. Or something.
<jam> well, it has the low level data, then indexes those, shoves all of that data into a '.pack' file as a series of indexes, then creates a 'names' file which is yet another index...
<jam> interesting poking at the code a bit
<jam> it uses 'make_mpdiffs()' to be able to figure out what actual content was introduced in a revision
<jam> walking the diff hunks
<jam> also interesting is that it doesn't seem to index non-ascii data
<jam>         _tokeniser_re = re.compile("[^A-Za-z0-9_]")
<Peng> That would be a good place for one of bzr's lazy regexes, no?
<jam> Peng: it probably would, but it is done inside an "_ensure_regexes()" so it is already lazy
<Peng> "_ensure_regexes()" seems more error-prone than a lazy regex to me.
<Peng> Anyway, not the point.
<jam> Peng: Sure, probably mostly because of timing
<jam> lazy may not have been available
<Peng> True.
<jam> also, bzr the command line replaces the regex compiler so that *all* re.compile() statements are lazy
<jam> more interesting is that bzr-search does a lot of work to make its content compact
<jam> using offsets to produce simple integers to do lookups between the different indices
<jam> I wonder if that is obsolete with btree indices but was never updated to follow suite
<Lo-lan-do> Any idea why loggerhead would be generating links like <a href="http://zforge.org, zforge.org/scm/loggerhead/testbzr/download/..."?
<Lo-lan-do> (Note duplication of host)
<Lo-lan-do> It seems to do it when proxied through Apache but not when IÂ hit it directly.
<Lo-lan-do> Nevermind, it seems the Apache config does Funny Stuff.
<Lo-lan-do> Seems maybe I shouldn't try and cascade two levels of proxyingâ¦
<Peng> Two levels of proxying does...that?
<Peng> I guess it gives the hostname at each level of proxying, in case they're different?
<Lo-lan-do> Loggerhead receives only one Host: header, but "X-Forwarded-Host: zforge.org, zforge.org" (and same for X-Forwarded-Server)
<Peng> Ah.
<Lo-lan-do> I'll debug that after food.
<Peng_> Prob'ly a Paste thing.
<servilio> hi! I have a lot of changes in a project that I'd like to partition across a series of commits, is there a tool that helps on this?
<Tak> shelve/unshelve?
<phinze> servilio: yup, shelve/unshelve works or if you prefer there's an interactive commit plugin that's pretty nice
<phinze> http://bazaar.launchpad.net/~asabil/bzr-interactive/trunk
<servilio> phinze: thanks!
<LeoNerd> I quite like shelve/unshelve, although annoyingly shelve(2) doesn't do partial interactive unshelve, as unshelve1 had
 * servilio goes to look at bzr-interactive
<LeoNerd> So you either have to shelve up in reverse order, each set of changes, or.. shelve the lot, commit, unshelve, then reshelve again
<Lo-lan-do> Peng_: Prob'ly, yes.  Any idea how to be sure?
<SamB_irssi> jam: I'm talking a bajillion different files created in /tmp -- not just a few hundred
<jam> SamB_irssi: are they being deleted?
<SamB_irssi> jam: of course, yes
<SamB_irssi> there only ever seems to be one at a time ...
<jam> SamB_irssi: then i'm not very surprised
<jam> bzr-search generates a lot of tiny indices
<jam> when it is done, you could try doing
<Peng_> Lo-lan-do: Sorry, I don't, except for lots of digging around in the code.
<jam> grep 'Graph Index' .bzr/bzr-search/indices/*.pack
<jam> and you'll see how many it created
<jam> also note that it has some logic for combining indices
<jam> I don't know the frequency, etc
<jam> but there is a possibility of having significantly more created than the final number
<jam> SamB_irssi: On my simple index of bzr-search itself (which is a rather tiny project), I have 2928 indices
<SamB_irssi> % grep 'Graph Index' .bzr/bzr-search/indices/*.pack -c
<SamB_irssi> .bzr/bzr-search/indices/1aa4b32392ac306a517bbde1541c6156.pack:69833
<SamB_irssi> .bzr/bzr-search/indices/1cc10f06974551571a251c2b615a7ecd.pack:42632
<SamB_irssi> .bzr/bzr-search/indices/3428b8cb5c8ca0c0ce6fbd3e77440b24.pack:45649
<SamB_irssi> .bzr/bzr-search/indices/50ad99ed8415ebe08ff77c5ba0ff2efd.pack:33426
<SamB_irssi> .bzr/bzr-search/indices/9b494322bed23caf692fbfb91adea948.pack:47050
<SamB_irssi> .bzr/bzr-search/indices/cc5a9bde095ed3939a49a73f1fabb749.pack:42741
<bialix> igc: hi
<jam> SamB_irssi: that isn't a bajillion, that is only about 200k
<jam> well off of a bajillion
<bialix> hello all
<jam> but yes, all 200k of those will have created a temp file
<SamB_irssi> that's still a heck of a lot of temp files!
<Peng> 200k temp files? That's healthy...
<bialix> 200k -- what the hell?
<jam> bialix: 'bzr-search' while generating the search index creates a *lot* of temp files
<bialix> oh no
<jam> only 1 at a time
<jam> but a lot in a row
<bialix> this will be major overkill on windows
<jam> SamB_irssi: actually, looking at the code, we may be creating 2 temp files per index
<jam> hence why you saw the bzr-index and the plain tmp-
<jam> we create a temp per row, and then one temp for the root
<jam> well, temp per row, and then a temp for the final output
<Peng_> That's, um, a lot of writing.
<jam> SamB_irssi: out of curiosity, what is the total size of your .pack files?
<jam> I'm just curious what the average index size is
<SamB_irssi> jam: the index ones ?
<jam> SamB_irssi: yeah
<jam> du .bzr/bzr-search/indices
<alf> Hello all, is there a way to tell bzr-svn to have dpush-like behaviour in checkouts (not use bzr metadata)?
<SamB_irssi> jam: 55 megs, apparently, or 56028 for the command you gave
<jam> hmm... 288 bytes each
<jam> lots of small ones :0
<SamB_irssi> alf: that would be excessively evil
<alf> SamB_irssi: why is that?
<servilio> SamB_irssi: why would that be? for me it would make sense if you are trying to commit to a repo you don't own and don't want to create noise
<SamB_irssi> I personally think binding to a remote branch is evil period ...
<Tak> hmm, how much does the post-dpush rebase load the server?
<SamB_irssi> no, I mean I think you should look at your commit and make sure you did it right before pushing to the remote ;-)
<Lo-lan-do> Peng_: Too lazy to debug myself, but I found a workaround by deleting the header in the Apache configuration.
<jam> SamB_irssi: You may be interested in: lp:///~jameinel/bzr/2.1.0b1-small_btree_no_disk
<jam> That uses an in-memory object until the btree > 1 page (4k bytes)
<jam> the time for 'bzr index bzr-search' drops from 4s => 1.0s for me
<Lo-lan-do> http://zforge.org/scm/browser.php?group_id=9 now works :-)
<ereslibre> ideas on this guys ? http://pastebin.com/m37a7deec
<jam> ereslibre: upgrade your bzr-gtk
<jam> ereslibre: the ProgressBarStack was deprecated for a long time before bzr-gtk was updated
<jam> (which didn't happen until we finally removed it :)
<bialix> jam: senior Fuente insists on newer subvertpy in windows installer. can you update it and provide new installer?
<ereslibre> jam: thx :)
<jam> SamB_irssi: on my Windows laptop, that change makes a world of difference in the OS
<jam> without it, the System overhead goes through the roof, and my machine is a bit unresponsive
<jam> with the change, the cpu load goes up, but without a corresponding IO overhead
<jam> bialix: I'm happy to change it, but what am I changing it to?
<NET||abuse> hey guys.... trying to update from my laptop to my windows desktop,,, c:\devel\myproject>bzr update     "bzr: ERROR: [Error 123] The filename, directory name, or volume label syntax is incorrect"
<NET||abuse> htis is when it gets down to a file that is in a tmp directory which should be ignored.
<jam> SamB_irssi: by comparison, I can index all of bzr.dev in 5m2s, with temp files I was at only 22MB/65MB after 4min
<Peng_> I'm glad I usually have /tmp as a tmpfs.
<alf> I was just trying to commit to a checkout of a simple SVN repo and got "bzr: ERROR: exceptions.TypeError: unsupported type None" (along with the traceback).
<alf> I am using 1.17 (debian). Is this something known/fixed or should I file a bug?
<davidstrauss> alf: Always upgrade before asking/filing a bug
<bialix> jam: buildout.cfg: subvertpy-release = 0.6.9
<jam> alf: I'm pretty sure that is a known and fixed issue
<jam> bzr-svn was trying to set a revision property to None
<jam> rather than an empty string, etc.
<jam> bialix: what about the version of bzr-svn itself?
<bialix> jam: I dunno
<bialix> jam: jelmer is not very specific
<bialix> jam: http://bazaar-vcs.org/BzrForeignBranches/Subversion?action=recall&rev=234 lists bzr-svn 0.6.5 as latest
<jam> I think we want to release the 1.0 series with 2.0 if possible
<jam> but I don't know where jelmer is in finishing 1.0
<jam> k, I believe Naoki also wanted us to try out tbzr 0.3
<jam> rc2-5 ... coming up
<bialix> thx jam
<alf> davidstrauss: using bzr 2.0rc2 and latest bzr-svn I am still getting a crash, although I am not sure if it is a bug in bzr or bzr-svn...
<davidstrauss> alf: Why are you asking me, in particular?
<alf> davidstrauss: only because you were the first to answer me before, sorry
<davidstrauss> alf: Sorry, but I don't know anything about bzr-svn :-/
<alf> davidstrauss: no problem
<denys> hmm... just checking: there is no way I can migrate history to a SVN server to which I only have HTTPS access, right?
<Lo-lan-do> denys: If your history is linear, yes you can.
<Lo-lan-do> If you have write access.
<denys> Lo-lan-do: what's the trick?
<Lo-lan-do> And if you have a non-linear history, then you can only move one part of it.
<Lo-lan-do> You can push to svn repositories.
<denys> Lo-lan-do: you mean: I replay the history?
<denys> Lo-lan-do: bzr-svn + push (I am sorry if this is a stupid question, but I have never done that)
<denys> Lo-lan-do: I have to migrate a CVS module to a SVN server, and I only have HTTPS access to the SVN server
<zsquareplusc> really? can't you ask the admin to import a dump of a svn repository? there are cvs2svn tools that work well, you do not need to do the extra conversion through bzr.
<denys> zsquareplusc: no, unfortunately, there is NO WAY they will allow anything to execute locally on the server.
<zsquareplusc> denys: svn can dump a repository to a xml file and svnadmin can mport those again. of course the admins would need to run that, not you. i would hope they already to use that to backup their servers..
<denys> zsquareplusc: I know this would be possible, but the admins are extremely paranoid and not exactly willing to go out of their way to help. so, that option is unfortunately out. hence my enquiry :-(
<zsquareplusc> sounds like an IT department of a larger company ;-)
<Lo-lan-do> Maybe tailor is able to push to a remote SVN repository?
<denys> just an IT at a modest university
<zsquareplusc> denys: do you really need to use their svn server? use bzr right away ;-)
<denys> Lo-lan-do: things is, I could not see how it could be done using svn functionality - I just wanted to check with others
<denys> zsquareplusc: it has been a 3 years battle just to get svn with external access.  I would love to get bzr, but that is still "FUTURE WORK"
<Lo-lan-do> Ideally, you'd pull from CVS into a bzr branch that's bound to an SVN branch with bzr-svn.
<Lo-lan-do> But that sounds like a lot of complication.
<denys> Lo-lan-do: the problem is just preserving history with a reasonably accurate timeline (timestamp-wise)
<zsquareplusc> denys: well with a distributed system like bzr you don't have to integrate that tightly with system administration. having a smart server may be nice, but bzr also works if you just have webspace where you can push to using sftp :-)
<denys> zsquareplusc: yes, but the issue is that research oriented projects should be hosted at the university (this is an essential part of the valorization of the work beeing done here).  hosting elsewhere is possible (I have done it) but that's not desirable.  furthermore, sftp cannot work for external collaborations, because there is no way that the university will grant ssh access (even restricted, even when run in VMs as we do) to non-local
<denys> personel.
<zsquareplusc> the external participants would need to host their branches elsewhere ("outside") so that you can merge them in that case. so the "trunk" could be at your place
<zsquareplusc> denys: hey you came to bzr so we at least have to try to sell it ;-) you can of course also try to import your code into the SVN repo. bzr-svn may work and there may also be other tools that can accomplish this.
<denys> they would still need to authenticate to get locally hosted branches - and that is a problem
<zsquareplusc> http+password is possible
<denys> only if you are in control of the server, which we are not
<denys> I have NO access to the server but HTTPS
<zsquareplusc> its the same setup as you would do for https for svn, only that its not the svn backend but a simple forder you have write access to
<denys> but I have NO access. not to a folder. not to anything. its HTTPS or nothing.
<zsquareplusc> so you do not even have a web page for your project where you can upload files?
<denys> no, uploading is also extremely difficult.  you need to setup a tunnel through 2 specific gateways.  _I_ can do that, but none of my colleagues could. and the pain, the pain...
<RenatoSilva> I want to have software version in each text file of my application automatically. Is it possible? Just like those $xxx$ comments in CVS
<fullermd> "Keyword expansion" is the ...  well, keyword, you're looking for.
<fullermd> There's a plugin for it, but it's not practically usable.  Needs various bugfixes.
<RenatoSilva> so bzr doesn't have it in core?
<fullermd> No.
<Lo-lan-do> It causes large amounts of headaches in CVS.  Would it be better in Bazaar?
<fullermd> Everything's better in bzr.
<fullermd> Ponies get distorted by RCS files, y'know.
<Lo-lan-do> Don't belittle RCS files.  RCS files are going to make me rich.
<Lo-lan-do> Well, they'll make me money, at least.
<RenatoSilva> how to know what rev a file belongs to? I mean, the rev that was the latest to change that file?
<Lo-lan-do> (Large migration from CVS to Bazaar planned at a client.)
<fullermd> "I am Sub Version, the widow of the late Premier of CVS.  On his death, he left TEN MILLION DOLLARS in his RCS files.  I require your help to move this out of the country..."
<Lo-lan-do> RenatoSilva: bzr log $file
<Lo-lan-do> fullermd: :-)
<zsquareplusc> fullermd: you get too much spam ;-)
<fullermd> Well...   I have an email address.  It's tautological.
<alf> Hello, I am trying to understand why bzr dpush needs a rebase afterwards. Can someone point me to an explanation (preferably containing a simple example)?
<fullermd> alf: AIUI, because what dpush does IS actually a sort of rebased push.  I don't know any details beyond that vague sense though.
<zsquareplusc> after the dpush it has to make your local revisions carry the ID of the remote branch again, as otherwise they would not look at being the same? the changesets get a new ID when they are integrated in the other VCS. (maybe this, i don't really know)
<zsquareplusc> so it integrates all your changes in the other repository and the rebase makes your local branch look as it were checked out from the new head of the remote repo. (?)
<alf> zsquareplusc: the devil is in the details :)
<RenatoSilva> Lo-lan-do: thanks
<alf> Let's say that the svn repo contains revision A-B and you dpush additional revisions C-D.
<alf> Then the local branch will contain A-B-C-D and the remote A-B-C'-D' (?)
<alf> How then is the rebasing performed? I must be missing something.
<zsquareplusc> after rebasing, your local repository will also contain A-B-C'-D'  - same contents so they are "in sync"
<alf> Can rebasing delete revisions (eg C-D)?
<dsuch> hmm is anyone working on a bzr book?
<fullermd> Depends on your opinion on the Great Detroying History question.
<fullermd> It doesn't delete them from the repository, no.  But they're no longer in your ancestry.
<RenatoSilva> not following rebase discussion but I have a question about the one from a time ago
<RenatoSilva> merge from trunk for just updating versus rebase (which I have not used yet)
<RenatoSilva> isn't the former a mess with your history?
<zsquareplusc> when you work with bzr on both ends you usually don't need rebase i guess
<RenatoSilva> because in pratice if you're working on a feature branch, you just want to keep it up-to-date with trunk
<RenatoSilva> I'm just worried about the mess in mistory
<RenatoSilva> we'll have seevral artificial commits  "merge with trunk"
<zsquareplusc> why artificial? it was a change in the history of your branch
<RenatoSilva> is keeping the exact history of what happened, even if it includes those artifical merges (for update purpose), the only reason for preferring the former not the latter?
<RenatoSilva> zsquareplusc: artificial in the sense that you'd get the same result if you instead of merging from trunk, remove changes, pull from trunk, then apply changes (I think this is rebase)
<RenatoSilva> zsquareplusc: the question is: is it just about keeping a history???
<zsquareplusc> rebase rewrites your branches history. so you may get different revision numbers. with merge you do not have this problem. you just get an increment when you commit the merge
<RenatoSilva> so you may get different revision numbers? for example?
<zsquareplusc> in a rebase that can happen. as you can make it base on a different history
 * RenatoSilva is back (conn problems)
<NET||abuse> when you checkout code from a remote system, do you have to specify an absolute path?   eg,,, bzr init; bzr pull bzr+ssh://me@ipaddr/home/me/code/project1   or can you just specifiy a location relative to your home on the remote system after the host address?
<fullermd> Full path, until the server's running 2.1.
<zsquareplusc> 1) i'd just cd to to local directory with your projects and use bzr branch
<fullermd> (or you're using sftp)
<RenatoSilva> fullermd: so rebase...
<RenatoSilva> fullermd: I was disconnected
<RenatoSilva> fullermd: what's the problem of rebase
<fullermd> Oh, no.  I'm not getting drawn into THAT discussion again.
<NET||abuse> fullermd, ahh,, ok i'm only running 1.18
<RenatoSilva> fullermd: our conversation was interrupted
<fullermd> I wasn't in that conversation.
<RenatoSilva> fullermd: my point is that rebasing (if I understand it correctly) makes the history more natural, even if not that precise
<RenatoSilva> fullermd: sorry if you wasn't, I thought it was you who wss talking to me
<fullermd> No, you were talking with zsquareplusc.  After the 15th or 20th time I watched that discussion unfold, I decided it was an utter waste of time.
<fullermd> If you already agree with $ME (for any value of), there's nothing to discuss, and if you don't, nobody is going to change their mind.
<fullermd> It's more productive to debate whether god exists, and if so, whether he supports $POLITICAL_PARTY.
<RenatoSilva> I think you're confusing me to someone wanting a flame war, REALLY
<RenatoSilva> fullermd: if you were here yesterday or so you'd know why I was asking
<fullermd> Yeah, that's what everybody says when they open up topics like that  :p
<RenatoSilva> fullermd: I don't even know how to use rebase or what it is exactly, I just think the idea is good
<RenatoSilva> fullermd: ok forget the word rebase, I'll explain the problem more strictly
<RenatoSilva> fullermd: ok forget the word rebase, I'll explain the problem more strictly (ignore if you wish)
<NET||abuse> hmm, i have .bzrignore in the root directory of my WT, is that that right location for my ignore list?
<NET||abuse> i'm finding that some files matching my pattern aren't being ignored.
<fullermd> It is.
<fullermd> What suggests they aren't being ignored?
<NET||abuse> they're appearing in unknown
<fullermd> Oh.  That's a good indication   8-}
<NET||abuse> ahhh wait, they're in another tmp dir near the other tmp dir.... ;P
<NET||abuse> there's tmp for uploads, and a tmp for captcha's,, i forgot to ignore jpg's in the captcha tmp.... oops
<RenatoSilva> 1) I have feature branch fb cerated from trunk rev 10 2) I submit a few revisions to trunk, which is now at rev 15 3) at the same time I commit to fb, which is now in rev 12 and done 4) I merge fb into trunk and the result is...
<NET||abuse> bzr: ERROR: [Errno 2] No such file or directory: u'C:/Users/Me/Documents/devel/project.com/.bzr/checkout/limbo/new-2/web/public/shared/js/jquery.form.js?2.31"
<NET||abuse> what's this about???
<NET||abuse> trying to pull down from repo on my linux box.
<NET||abuse> windows version i'm getting this error on is 1.18.1   and linux version is 1.18
<fullermd> Got me.  There've been occasional weird issues with files being/not being in limbo where they shouldn't/should, but they were mostly older versions.
<fullermd> Is it happening consistently?
<NET||abuse> yeh, i completely deleted the copy on the windows machine, then re-init'd an empty branch, and tried to pull into that branch again.
<NET||abuse> is it something to do with the ? in the file name perhaps?
<fullermd> Possible, I guess, if that's illegal on Windows.  But I thought all those cases were handled.
<fullermd> Any particular reason you're init/pull'ing instead of branch'ing?
<NET||abuse> oh, tried just branching also and it broke.
<NET||abuse> was first try to just branch.
<NET||abuse> just as alternate method tried init/pull
<NET||abuse> didn't try a shared repo yet,,, but i feel this is something to do with the file or that character, rather than antyhing like branch locaiton.
<jam> morning lifeless
<fullermd> No, shared repo wouldn't much matter.  That's all happening in limbo (building the working tree)
<fullermd> Can you make filenames with question marks in them?
<fullermd> jam may be more helpful than I...
<NET||abuse> i'm actually just deleting the file from the branch on linux machine, and trying now, it was just a copy of the downloaded jquery.form 's plugin.
<jam> fullermd: ? is illegale
<jam> \ / * : ? | " < > are all illegal
<poolie> hello
<poolie> hi jam
<jam> hey poolie
<fullermd> Well, that would 'splain it then.
<fullermd> Though I thought we had traps to give more pointed errors in cases like that.
<jam> NET||abuse: I would agree with fullermd that I thought we would at least give a nice error for this case. But we can't create them so you need to delete them on another machine (for now)
<NET||abuse> eh, yeh,,, problem solved... hmmmm so no ? marks in windows version.
<NET||abuse> guess it could be an ntfs problem.
<NET||abuse> restricted characters
<jam> poolie: let me know when/if you want to call
<poolie> jam, hi, i do want to call
<poolie> i'm just finishing something up here and i'll call in a few minutes
<poolie> skype/home/mobile?
<jam> home is probably easiest, but skype is fine too
<lifeless> hi jam
<lifeless> so the cStringIO thing; my original thought was 'probably won't hit disk', I think.
<lifeless> jam: but I'm glad to have it be nicer for windows ;)
<jam> lifeless: well, it has to allocate an inode, etc
<jam> I'll try checking it on a linux box
<lifeless> allocating the inode doesn't have to hit disk, until fsync on the containing dir
<lifeless> anyhow, I've +1'd
<jam> yeah, I sawthat
<poolie> jam, calling
<NET||abuse> huh.. when i have parent branch: bzr+ssh://me@ipaddr/path/to/repo    but then bzr push says no push location
<NET||abuse> sorry for the basicness of this, it's just a bit of a confusion
<fullermd> push doesn't use the parent location by default.
<fullermd> It has its own.
<NET||abuse> ohhh,, how do i set that then?
<fullermd> You can use the saved loc shortcut to set it quick (`bzr push :parent`)
<NET||abuse> ahhh, ok
<NET||abuse> bit confusing though isn't it?
<fullermd> The operative theory is that push'ing to somewhere other than you branch'd from is a very common case.
<fullermd> (e.g., you might often branch from a location you can't write to)
<NET||abuse> ahah,, that's true.
<NET||abuse> i guess.. it's just more a ,, where do i look for those instructions?
<NET||abuse> they're not very obvious, even after reading the workflows documentation.
<fullermd> Contrast with merge, which also has its own stored location, but will use the pull loc if that's not set.
<zsquareplusc> hm. when that :parent shortcut works in such cases, it would be worth mentioning that in the error message of push when it has not yet a saved location
<fullermd> First, merge'ing from your original base is more common, and second, if it's NOT what you want, accidentally doing so isn't near as harmful.
<fullermd> (if you accidentally push somewhere you didn't intend, it can be much harder to undo)
<fullermd> Not sure what instructions you mean.  If you mean having to supply a location when none is saved, that's common to pretty much any command (including pull).
<fullermd> If you mean the shortcut names, last I heard they weren't documented.
<fullermd> Their existence is mentioned buried in NEWS, but last time I wanted to know what the choices were I had to dig into the code.
<fullermd> That was a while ago, though.  Maybe they're in the manual.
<zsquareplusc> well i did not know about it, i always had to specify the same URL 3 times.. branch then pull/merge and push :/
<jam> lifeless: so on an old linux box, indexing 'bzr-search' itself: 4.894s => 2.426s
<lifeless> cool
<fullermd> (I haven't followed the progression of the documentation as closely as I should  :| )
<fullermd> zsquareplusc: You certainly shouldn't have to specify it on pull after branch.  branch sets the parent loc.
<zsquareplusc> fullermd: with instructions i mean instead of just "bzr: ERROR: No push location known or specified." it could additionally mention what's possible
<fullermd> Well, what's possible is specifying it.  Trying to describe all the possible forms that can take is *way* out of scope for an error message.
<fullermd> It _should_ (in the sense of 'out to', not 'I think is') be in the docs.
<fullermd> Holy crow.  "ought to".  My fingers are not my friends today.
<zsquareplusc> i'd not mind short usage tips when i'm doing something wrong. better than nothing and "good look to find it in the manual"
<fullermd> Giving useful tips in a situation like that is bzr-dwim territory  ;)
<alf> I am experimenting with bzr-svn and have created a branch of an svn repo. I have commited something on local branch and something in the svn repo so they have diverged.
<zsquareplusc> well an an option is when the help is built in to give at least a hint on how to get that help, e.g. if there were a "bzr help location" it could direct the user to read that.
<alf> I am trying to push to the svn and of course I cannot due to the branches having diverged. So I merge from svn to the local branch.
<alf> Now when I try to push to the svn it says that Operation denied because it would change the mainline history...
<alf> I am wondering in what way my push  will change the history on the svn.
<fullermd> svn can't represent the history bzr has, and the standard projection into lower dimensions (as it were) differs from the existing history.
<zsquareplusc> so is this one of the use cases for rebase?
<alf> so if svn and its bzr branch have diverged, is there a way to perform the merge from the branch->svn without changing the mainline?
<alf> (I mean the mainline history)
<fullermd> Generally, by doing the merge the other way around, so the svn history and bzr mainline coincide.
<alf> I don't think I got that. If my branch and svn have diverge what steps do I have to take to get my branches changes to svn (without history changing)?
<fullermd> Merge the bzr changes into the svn changes, rather than the other way around.
<fullermd> e.g., have a checkout (not a branch) of the svn branch, and a bzr branch in which you do the work.  To land it, merge it into the checkout and commit it.
<alf> ahh, ok
<fullermd> (you could use a branch instead of a checkout of course, but a checkout can be conceptually more accurate)
<fullermd> Basically, you want to end up with "merge my-changes ; push" rather than "merge upstream-changes ; push"
<alf> if I use a branch isn't the situation the same as the one we have been talking about?
<fullermd> No, it's not really branch vs checkout, it's a question of which side of the merge you're on.
<fullermd> Checkout just conceptually fits what you're doing (merging stuff into the svn 'branch') and suits staying in lockstep.
<RenatoSilva> I'd appreciate very much if you could read this http://pastie.org/625271 :)
<RenatoSilva> http://pastie.org/625271 - update-merges vs. rebase
<RenatoSilva> that's an example where I put how would it be in both cases
<alf> fullermd: thanks for the explanation, I think after some processing on my part things will become clear
<zsquareplusc> RenatoSilva: i don't think that this will work in all cases. you known that with rebase, you can run into conflicts while rewriting the history?
<RenatoSilva> zsquareplusc: see I'm not agueeing, I'm learning. No I don't know
<RenatoSilva> zsquareplusc: what proplems in that example could get wrong?
<RenatoSilva> * argueeing
<RenatoSilva> * arguing
<RenatoSilva> zsquareplusc: in that example specifically, no history is really rewritten, it's just like starting the work again after each update in trunk
<RenatoSilva> zsquareplusc: e.g. you could replace steps  3.[2,3].2 with "forget it all, do the same code changes again manually"
#bzr 2009-09-22
<spiv> poolie: ping
<poolie> hullo spiv
<poolie> i have a call with francis soon
<poolie> how are you today?
<spiv> Pretty good, despite a test failure.  It's fairly shallow, I think...
<spiv> So I'll have this patch up shortly (to cut out two vfs calls on incremental push).
<spiv> I haven't decided what to tackle next...
<igc> morning
<spiv> igc: good morning.
<igc> hi spiv, poolie
<poolie> spiv, yay
<poolie> how about looking at the systematic cleanup patch?
<poolie> i haven't written any code
<poolie> or review the critical queue
<poolie> also, thanks for the update
<fullermd> That bug with mv screwing up the WT state could stand tackling...
<spiv> Yeah, looking at cleanup does sound good.
<spiv> fullermd: be my guest ;)
<fullermd> Yeah, that would be the opposite of happening...
<spiv> fullermd: I very much agree, but I'm hoping someone with at least a tiny amount of familiarity with that code looks at that before I have to :)
<RenatoSilva> I want to put a tag value (containing current version) for each single text file in my app. Is it bad pratice? It's similar to those $xxx$ tags in cvs
<zsquareplusc> is locations.conf only respected when there is also a bzr branch? when i run bzr whoami i see the default, event if i'm below the location specified in locations.conf but not yet in the branch
<fullermd> bug 276201
<ubottu> Launchpad bug 276201 in bzr "locations.conf is only consulted when there's a branch" [Low,Triaged] https://launchpad.net/bugs/276201
<zsquareplusc> changed to "This bug affects me too" :-)
<zsquareplusc> while it's probably not a real problem it gives the *impression* of not being reliable :/
<fullermd> It could be a problem in some cases.
<zsquareplusc> and there seems to be an issue when setting the name through whoami it writes to bazzar.conf, but then when displaying it read form locations.conf again
<fullermd> That's by design.
<pmatulis> i have some bzr repos on a feisty server.  i now want to migrate that stuff over to a jaunty server.  how do i transfer this without losing history/logs?
<lifeless> pmatulis: rsync ?
<pmatulis> lifeless: k, so no compatibility issues?
<lifeless> jaunty
<lifeless> jaunty's bzr can read back to the dawn of time
<lifeless> you might want to upgrade to a newer repository format to improve performance, but thats orthogonal
<lifeless> and best done separately IMO
<pmatulis> so if my directory structure is /home/bzr/{project1,project2} i just rsync/scp over /home/bzr?
<pmatulis> lifeless: ^
<lifeless> yup
<pmatulis> how do i change format afterwards?
<lifeless> bzr upgrade
<lifeless> there are docs about this for 2.0
<lifeless> jaunty is kindof old - you might like to install 2.0rc2 from the beta ppa :)
<pmatulis> heh, latest crack
<lifeless> no, thats in the nightlies ppa :)
<SamB_XP> lifeless: why are they called nightlies, anyway?
<lifeless> because they happen every night
<SamB_XP> they don't seem to have nearly the regularity that the term suggests ...
<lifeless> no?
<zsquareplusc> since i have +archive/ppa in apt's sources it says it will remove bzr-svn when i upgrade from bzr 1.17 -> 1.18 :(
<SamB_XP> well, I've noticed times when the same one was up for periods that were probably more than two days ...
<SamB_XP> entire weekends, possibly!
<lifeless> they are generated nightly, and only when trunk has changed
<SamB_XP> possibly more than that
<fullermd> Maybe it's a statement of tolerance rather than periodicity.  They wilt and sublimate when exposed to sunlight.
<SamB_XP> but maybe that's just when nobody manages to land anything for a bit ...
<pmatulis> how do i define the default host & path for a repository again?
<SamB_XP> lifeless: oh, and re in-branch-p thing, I never said I thought it was easy
<SamB_XP> I just figured it would be nice to have an easy-to-find bug ...
<lifeless> SamB_XP: sure ;)
<lifeless> pmatulis: what do you mean?
<pmatulis> lifeless: enter /home/bzr/project and then do 'bzr push' without specifying a remote host & path
<mwhudson> pmatulis: bzr push --remember <location>
<pmatulis> ah yeah, that's it
<pmatulis> can never... remember
<SamB_XP> pmatulis: lol
 * SamB_XP is a bit tired
<Kilroo> Doggone it, I keep forgetting to try to figure out how to get bzr-svn to work with svn 1.6 when I have time for it...
 * spiv -> lunch
<poolie> thumper: hiya
<thumper> hi
 * igc lunch
<poolie> spiv, is there a bug for the desire to translate urls back into ones that make sense to the user on the way back out?
<poolie> like we talked about the other day
<poolie> thumper: ^^
<lifeless> jelmer: ping
<spiv> poolie: not an overall one AFAIK
<spiv> poolie: there's at least one for specific symptoms, like the message that suggests break-lock FOO.
<poolie> maybe we should have one?
<spiv> Yeah, seems like a reasonable bug to have.
<spiv> Well, reasonable bug *report* to have ;)
<lifeless> :)
<lifeless> poolie: I need to pop out for a bit; if you need me please SMS ?
<vila> hi all
<poolie> hi vila
<poolie> vila, i'm writing a little script to test if the ppa is selfconsistent
<poolie> i hope that doesn't overlap with your stuff at all?
<vila> hmm, I can't see any stuff I'm working on that can overlap that...
<vila> poolie: what was you thinking about ?
<vila> err were
<poolie> i want to see if the packages in the ppa simultaneously install into a clean environment, and pass their selftests
<vila> ha, ok, mmm
<vila> and you do that how ? With a chroot ? oooh, that could be done on a slave is what you mean !
<igc> hi vila
<igc> jelmer around?
<vila> hmm, a dedicated one since that requires system-wide install...
<vila> poolie: if you keep that in mind, your script may be *used* in a slave but, no, I didn't think about that kind of setup
<poolie> vila, so, i'll continue with this script and then maybe later we can run it in babune
<vila> poolie: so how do you plan to do that ?
<vila> poolie: sounds good
<RenatoSilva> I'd like to have the version (tag?) on each file of the branch. Is it a good idea? What's the best way of doing it?
<RenatoSilva> So that end-users can identify sofware version in each file
<poolie> it's in pursuit of bug 434412 etc
<ubottu> Launchpad bug 434412 in bzr-svn "no bzr-svn release compatible with bzr 2.0.0" [Undecided,New] https://launchpad.net/bugs/434412
<poolie> vila, https://edge.launchpad.net/ppa-smoketest
<poolie> igc, so bzr-svn is in fact ok in the windows installers?
<poolie> did jam just ship a snapshot?
<igc> poolie: he updated subverty to 0.6.9 which I understand fixed some issues
<vila> poolie: may be you can mention that in a reply to my babune metronome mail, just to keep track...
<igc> poolie: it looks like Jelmer tagged bzr-svn 1.0.0rc1 19 hours ago
<poolie> vila, good idea
<igc> poolie: I think we're down to the wire wrt karmic: https://wiki.ubuntu.com/KarmicReleaseSchedule
<poolie> https://wiki.ubuntu.com/BetaFreeze
<poolie> it's definitely good to get it in now though
<igc> poolie: so I'd be keen to see 2.0.0 core announced "internally" so we can begin the final round of packaging testing
<poolie> let's do it
<poolie> vila, why did you send the babune mail only internally? i think it can be public?
<poolie> also, um
<poolie> this mail is at risk of being ignored because
<poolie> it's regular, and it doesn't make clear up front what you want people to do if anything...
<poolie> like if you want to call for builds, do it separately
<vila> poolie: you're right
<poolie> ok, pushed and (pre)announcement sent
<davidstrauss> Wait, this sounds like 2.0 going gold.
 * davidstrauss cheers
<poolie> hold on a sec
<poolie> i meant the test scripts
<poolie> but i am going to push the button on 2.0.0 now
<davidstrauss> :-D
 * tonyyarusso waits for a link to release notes to check out new features
<RenatoSilva> thanks everybody!
<poolie> all the features are in rc2
<poolie> it's just a version bump
<poolie> but rc2 has great features :)
<tonyyarusso> poolie: Yeah, but that doesn't mean there was a concise listing of them all pretty on the web page.
<poolie> http://doc.bazaar-vcs.org/test/en/release-notes/bzr-2.0rc2.html
<poolie> igc is it just me or are the fonts weird on that page?
<tonyyarusso> ah, cool
<igc> poolie: so the plan is for a fixed length of time between gold and final announcement, yes?
<poolie> i think so
<igc> poolie: if so, best to make that clear in your email
<poolie> i think it will be gated by getting the website adequately deployed
<poolie> however, it can start going into karmic today
<poolie> if they have a version of bzr-svn they can build
<igc> right
<igc> poolie: fonts are ok for me on that page
<poolie> can you find out which version the windows installers shipped and comment on that bug?
<igc> poolie: the window installer with include 1.0.0rc1 now that it's out
<igc> poolie: I need to check with jelmer re the dependencies once he's around
<vila> poolie, igc: the previous/next buttons are reversed on the release notes pages IMHO
<igc> vila: nice catch. I wonder whether it's wonder putting the last release last to fix that?
<igc> s/wonder/worth/
<vila> igc: No, I think getting to the last first is right (so to speak :), but from there, when I click previous, I want the previous version...
<igc> vila: those links are provided by sphinx fwiw
* poolie changed the topic of #bzr to: Bazaar version control system | 2.0.0 code frozen! <https://aunchpad.net/bzr/2.0/2.0.0> |  try https://answers.launchpad.net/bzr for more help | http://bazaar-vcs.org | http://irclogs.ubuntu.com/
<poolie> friday should be enough time, but we could even have less perhaps...
<poolie> i guess friday will allow for some testing
<poolie> spiv, how about lunch tomorrow?
<spiv> poolie: sounds good; north or south?
<igc> poolie: the 2.0.0 branch is?
<igc> bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/2.0.0/?
* vila changed the topic of #bzr to: Bazaar version control system | 2.0.0 code frozen! <https://launchpad.net/~bzr-pqm/bzr/2.0.0> |  try https://answers.launchpad.net/bzr for more help | http://bazaar-vcs.org | http://irclogs.ubuntu.com/
<Toksyuryel> "The Bazaar team decided that 2.0 will be a long-term supported release,
<Toksyuryel> with bugfix-only 2.0.x releases based on it, continuing for at least six
<Toksyuryel> months or until the following stable release."
<Toksyuryel> six months is not "long-term"
<Toksyuryel> long-term implies a few years at least
<AfC> Toksyuryel: it's long term for a crew that used to do releases monthly
 * igc dinner
<Toksyuryel> AfC: I am aware of this, but people who haven't been following the project for this long aren't likely to understand that. Just sayin' there's an issue with the phrasing.
<poolie> spiv, north, my bolt saga continues :)
<poolie> Toksyuryel: good point
<poolie> maybe we should just say a supported stable release?
<AfC> poolie: (as it happens, I agree with Toksyuryel)
<poolie> alternative phrasing welcome
<AfC> poolie: (but the bigger question is going to be how much backporting bzr hackers learn to do)
<poolie> i know people would like "supported for the next five years" and i'd like to give it to them, but that would be a big first step
<AfC> poolie: (as many have observed, that'll be a new idea for [us, /me waving the moral support banner, er] you)
<poolie> we could probabyl commit to a year
<AfC> poolie: we're not there yet
<AfC> 6 mo on this is good
<AfC> the real point is having your stable (and backported to) release synced with a certain prominent distro
<spiv> poolie: ok, see you tomorrow then :)
<poolie> and others hopefully
<AfC> :)
<poolie> maybe we could get bzr-stable etc into gentoo?
<poolie> or bzr=2.0?
<poolie> i forget the syntax
 * beuno waves at poolie 
<poolie> or rather, the conventions
<poolie> hello
<AfC> well, a) I'm not using Gentoo at the moment,
<AfC> and b) 2.0rc1 was in, but it got rehidden. Once you guys actually do 2.0 for real I'm sure it'll be there pretty fast. Someone seems to be packaging it rather quickly.
<poolie> they can do it now
 * AfC has taken a deep breath and is trying Ubuntu again. #2. The experience has not been overwhelming. I really hope that's just because I'm using Karmic [big mistake, apparently], but I would have hoped this close to release it wouldn't have been so unstable :(
<poolie> the only remaining bit is shouting
<AfC> poolie: you've cut a 2.0.0 tarball?
<poolie> (i have to go soon)
<AfC> [they need that]
<AfC> (me too)
 * poolie waves towards the top of the window
<poolie> and to https://edge.launchpad.net/bzr/2.0/2.0.0
<AfC> terminology "code frozen" != "released"
<AfC> IMHO
<poolie> released == code frozen && announced
<poolie> we're trying to separate them
<AfC> =yeah
<poolie> it seems worthwhile but is confusing
<AfC> not sure I think it's going to pay
<AfC> much as the theory seems good
<poolie> mm
<AfC> it's more a "what's in my PPA" & "what's in my distro" thing
<poolie> we'll try it a bit more then decide
<AfC> it wouldn't have been an issue if we weren't releasing so often, I think
<poolie> the question is can we get people to package it within a short bounded period of time
<AfC> yeah
<AfC> I followed the argument.
<AfC> worth a try
<AfC> s/argument/cogent debate/
<AfC> Reading bzr email is what I do instead of a paying job
<AfC> ahem
<bialix> good day bzr
<poolie> hello bialix
<poolie> ramen's calling
<poolie> good night...
<bialix> hi poolie, congrat to 2.0 gold
<poolie> thanks
<poolie> i hope you find the installers good
<AfC> poolie: parting thought "release" and then later "available"==tell people
<AfC> {shrug}
<bialix> poolie: no way for me
<AfC> == "bzr 2.0 now available in Ubuntu" & "bzr 2.0 now available in Gentoo" etc
<bialix> igc: hello, me a bit busy today, will build installers either tonight or tomorrow
<vila> AfC, poolie : That may be an interesting alternative: send announce when source tarball is cut, then followup with shorter announce for each platform availability...
<AfC> Well, Network Manager isn't working for 3G cards in Karmic right now, so as I will be mobile I won't have internet access for the rest of the night. So see you all tomorrow sometime.
<AfC> vila: {shrug} I realize it's all bikeshedding at this point, but "upstream released" and "available in..." seem to be more understandable in a distro driven world
<vila> AfC: ouch, I hope you have an alternate network access
<AfC> vila
<AfC> nope.
<vila> AfC: yeah, always apply your regular filters when it comes to correct wording from *me* :-D
<AfC> vila: which is why I'm so incredibly excited to have just switched to Ubuntu. The crashing on logout is a nice touch, too
 * AfC bears with it :)
<AfC> see you tomorrow
* vila changed the topic of #bzr to: Bazaar version control system | 2.0.0 code frozen! <https://launchpad.net/bzr/2.0/2.0.0> |  try https://answers.launchpad.net/bzr for more help | http://bazaar-vcs.org | http://irclogs.ubuntu.com/
<igc> bialix: ok - thanks for letting me know
<bialix> igc: got your mail about development.html, the same delay applied here as well. sorry
<bialix> dear core devs, can you look at https://bugs.launchpad.net/qbzr/+bug/434034/comments/14
<ubottu> Launchpad bug 434034 in qbzr ""'dict' object has no attribute 'encode'" error on commit" [High,Confirmed]
<bialix> does it ring the bells?
<bialix> it seems like critical bug in 2.0rc2 for me
<bialix> poolie? vila? lifeless?
<DaffyDuck_> I noticed something funny with bazaar. I had a file in a repository, which I deleted (unix rm) and then, in its place, I put a new revision of the file. Upon running "bzr status", it claimed that the file had been deleted. Does bzr store the inode of files in the repository?
<igc> DaffyDuck_: no it doesn't store inodes
<DaffyDuck_> Hmm.. Any idea how it knew the file was "deleted"?
<bialix> do you see new file in unknown?
<bialix> do you commit after delete?
<igc> DaffyDuck_: bzr will detect missing files and assume they're been deleted
<vila> DaffyDuck_: most probably you didn't create the new file in the same place or you changed its name (case sensitive issue ?)
<vila> bialix: was is critical there ? The reconfigure bug ?
<DaffyDuck_> Hmm.. It was a while back, but I'm going to try it again and see if I remember correctly.
<igc> DaffyDuck_: so a commit before putting a new version there will end the lifetime of that file
<bialix> vila: reconfigure
<vila> bialix: is it a regression ?
<igc> DaffyDuck_: as bialix suggests, maybe the file wasn't put back with exactly the same case or something like that?
<bialix> vila: I can test with 1.18.1
<igc> poolie: what branch should I be building the 2.0.0 docs from? lp:~mbp/bzr/prepare-2.0.0 isn't overly official. :-)
<bialix> vila: 1.18 produce the same error
<vila> so it's not a regression
<DaffyDuck_> Yeah, you guys are right -- I must have made some mistake. I'm glad, because I was mighty confused by the behavior.
<bialix> it's not regression from 1.18 then? it's old bug? nice
<bialix> how wonderful
<bialix> workaround for bug 434034 require reconfigure from light to heavy checkout, but this is impossible because of reconfigure bug
<ubottu> Launchpad bug 434034 in qbzr ""'dict' object has no attribute 'encode'" error on commit" [High,Confirmed] https://launchpad.net/bugs/434034
<vila> bialix: that's often the case with workarounds...
<bialix> vila: they discover new bugs?
<bialix> like a domino effect?
<vila> yes
<bialix> (no smile there)
 * bialix bbl
<vila> more precisely, when *searching* a workaround, you often encounter either related or unknown bugs
<vila> bialix: and doing that search remotely is even worse of course...
<vila> s/worse/harder, more prone to encounter unexpected bugs, etc/
<jelmer> lifeless: pong
<jelmer> igc: pong
<lifeless> hi
<lifeless> jelmer: you have mail :)
<SamB_XP> lifeless: how do you know it wasn't eated?
<fullermd> Oooh, my shiny little 2.0.0.tar.gz...   my own...    my...   preciousssss....
<Lo-lan-do> Will you share?
<bialix> 2.0 going gold
<fullermd> Thief!  Lo-lan-do!  Curse them; we HATES them!
<Lo-lan-do> Okay, okay.  See if I care, I'm on my way to fecth my new motorbike anyway, you can keep your poxy 2.0.
<igc> hi jelmer
<igc> jelmer: I wanted your advice on what things to package in the window installer
<jelmer> igc: Hi
<jelmer> igc: For 2.x, the latest versions of bzr-svn (1.0.0rc1) and subvertpy (0.6.9)
<igc> jelmer: thanks
<igc> jelmer: fyi, if you visit http://bazaar.launchpad.net/~bzr/bzr-windows-installers/trunk/files/head%3A/tools/win32/
<igc> the buildout.cfg file in there is the magic one for configuring the windows installer
<igc> jelmer: I'll make the change now for bzr-svn 1.0.0rc1
<jelmer> igc: thanks
<jelmer> igc: can I just commit updates to the version there or is there a review process required for that?
<Lo-lan-do> jelmer: Any thoughts on my latest merge request (for loggerhead)?
<igc> jelmer: you can commit directly there
<igc> jelmer: *and* it would be great if you may the change
<jelmer> igc: ok
<lifeless> bah
 * lifeless regenerates loom 2.0 tarball
<igc> jelmer: as well as bzr-svn, getting the right branches & tags for bzr-rewrite and subvertpy is clearly importantly too
 * jelmer nods
<lifeless> igc: https://edge.launchpad.net/bzr-loom/2.0/2.0
<lifeless> too, btw
<igc> lifeless: do you think loom ought to be included in the windows installer?
<lifeless> igc: up to you; AFAIK there aren't any issues with it, and folk may want to use it.
<lifeless> by issues I mean 'things that affect non users'
<igc> lifeless: we've been pretty conservative wrt putting plugins in so far
<igc> lifeless: I'd like to bundle a heap more but ...
<lifeless> I got 'bzr selftest loom Loom' passing and did some user testing beyon
<igc> I wonder whether we need a simple way of disabling/enabling installed ones first
<lifeless> d
<lifeless> its up to you
<igc> lifeless: my current feeling is we ought to keep the status quo for 2.0.0 and add more (loom, fastimport, etc.) in 2.0.1
<jelmer> Lo-lan-do: +1 on your patch
<jelmer> Lo-lan-do: should I push it or will you?
<ngnp> How do I get ie http://bazaar.launchpad.net/%7Evcs-imports/drupal/main/ into my bzr-project/www directory ???
<NET||abuse> hmm, i accidently set my push location in a WT to be another directory under the same directory call "parent" instead of pushing to :parent,, how do you override the default push location?
<jelmer> NET||abuse: push with --remember or edit .bzr/branch/branch.conf
<NET||abuse> jelmer, ahh, thanks.
<ngnp> I'm reading http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#setting-up-a-central-repository but I want to pull in an external resource into a subdir :(
<fullermd> sta
<fullermd> w
<fullermd> qr
 * fullermd boggles.
<fullermd> Stupid mouse.
 * fullermd wanders off to beat it.
<ngnp> Is my question stupid?
<bialix> jelmer: why you removed Subversion page from wiki?
<jelmer> bialix: ?
<bialix> ngnp: pull in external resource? you want svn:externals?
<bialix> jelmer: http://bazaar-vcs.org/BzrForeignBranches/Subversion
<bialix> there no more this page exists
<jelmer> bialix: I haven't removed anything
<bialix> of course, maybe b-v.o moin moin don;t like me
<bialix> does this URL works for you?
<ngnp> bialix: no ... I have brz-project/www ... I need to pull ie http://bazaar.launchpad.net/%7Evcs-imports/drupal/main/ into my bzr-project/www directory
<bialix> ngnp: you can't pull, but you can merge
<ngnp> bialix: that is a bzr repo to?
<ngnp> into a subdir?
<lifeless> bialix: it shows empty for me; I think its a moin cache bug
<lifeless> because the page history is there
<lifeless> and its not emptied
<lifeless> hmm, hit ctrl-shift-f5, now its gone :P
<bialix> jelmer, lifeless: waut a sec, I'll show you screenshot
<jelmer> bialix: it's gone here as well
<jelmer> bialix: but I havne't removed anything
<lifeless> moin failure
<lifeless> I'm made a trivial whitespace change and saved it
<lifeless> and its back
<bialix> that's better
<bialix> ngnp: I don't understand your question and your intent
<ngnp> bialix: I want to have my whole project (www-dir, sql-dir) under version control. But part of it (www-dir) comes from that launchpad repo. How to get that into my project tree? (Is that better :)
<bialix> what is project tree? shared repository? branch?
<bialix> do you want to have entire project as one branch?
<bialix> or do you plan to use something like config-manager or scmproj?
<bialix> ngnp: ^
<ngnp> bialix: I want to have control over my shared repository and update now and then this durpal/main
<ngnp> It's like a svn:external
<bialix> bzr has no support for svn:external
<bialix> you have 3 choices: 1) put everything into one big branch
<bialix> 2) use manual deploy or automatize it with make, rake, ant, zc.buildout, etc.
<bialix> 3) use tools like config-manager or scmproj plugin to specify config for your components
<bialix> ngnp: shared repository is just place where your branches lives
<bialix> it's not interesting per se
<bialix> bzr working with branches as first-class citizens
<ngnp> hmmm ... I'm disappointed about that. I'll check config-manager scmproj :)
<bialix> ngnp: what is your intent re drupal sources?
<bialix> ngnp: in simpliest case you can just branching drupal branch into your project, and use pull later to update it
<bialix> ngnp: maybe this is what you asking initially?
<ngnp> It means all web project users like me who need a proj/www and proj/sql directory under version control cannot use bzr :(
<fullermd> bialix: Oh, I'd never heard of rake.  Inneresting.
<bialix> fullermd: IIRC, this is ruby make
<ngnp> bialix: I know how to branch from that drupal ... but it should reside in a _subdir_ ....darn
<bialix> ngnp: so branch it into subdir
<bialix> what's the problem?
<fullermd> Yah.  At a glance, it looks similar to a project of mine, except for the ruby bit.  I'll have to dig into it sometime in search of interesting ideas to stea.... er, borrow.
<ngnp> bialix: how? That's my question after all :p
<bialix> bgnp: if you need to recreate branches structure on another nachine you need config-manager or scmproj
<bialix> ngnp: ^
<ngnp> i'm reading ..
<bialix> ngnp: how? cd subdir; bzr branch lp:drupal
 * ngnp tried his hell out yesterday ... retrying
<bialix> what it means "hell out"?
<bialix> oh, ignore me
<bialix> fullermd: me personally prefer scons
<ngnp> bialix: no no ... thanks for helping ... I tried this all day yesterday
<bialix> ngnp: ignore me related to my dumb question about english phrases
<ngnp> bialix: my english is neither native :p
<bialix> oh, ok
 * bialix hopes ngnp found lp pages for both projects
<ngnp> bialix: I give up :( ... thanks for your time :)
<bialix> you give up?
<bialix> so fast?
<bialix> ngnp: write a mail to bzr mailing list and ask for help. provide more details about what you want to achieve. you'll get more detailed suggestions
<ngnp> bialix: not fast .. trying for days ... and have to do some productive things :( ... maybe I try the mailing list ... still don't understand there is no svn:externals equiv ... I do understand your 'first class citizens' :)
<ngnp> tnx again
<bialix> ngnp: feature similar to svn:externals is still under development, right now it's stalled
<ngnp> ic
<bialix> scmproj is my plugin which tried to poorly emulate this feature
<ngnp> Just reading http://bialix.com/scmproj/docs/howto.html ;)
<bialix> ngnp: it's a bit outdated
<bialix> ngnp: write a mail and I'll show you more realistic examples
<bialix> ngnp: you are not first drupaler who struggles with such problem
<ngnp> bialix: I will after I've written my drupal article about it ... thanks
<bialix> about it -- about what?
<bialix> ngnp: what is "it"?
<ngnp> It is about how to get three dirs under version control "www, sql, meta" ;)
<ngnp> It's working for svn thanks to svn:externals but as I learned not for bzr :(
<bialix> ok :-)
<VSpike> Just to check, I started some changes in trunk that I now want to relegate to a WIP branch and come back to later, and go back to the last commit in trunk...
<VSpike> can I just do cd proj; cp -r main shelved; cd main; bzr revert --no-backup
<james_w> that would work
<james_w> (I would advice cp -a)
<james_w> advise
<VSpike> Ah yeah, good point
<VSpike> I guess I could also mv main shelved && bzr branch -r last:1 shelved main
<james_w> that would work
<james_w> though it would leave the branch parents a little weird
<james_w> "bzr pull" in main would pull from shelved
<Spritz> Hi everyone
<Spritz> I'm trying to evaluate bzr migrating from svn. But I'm constantly hitting an issue when importing a branch or whatever from the main svn server - i.e. SubversionException: ("REPORT of '/!svn/bc/43573': 200 OK (*URL*)", 175002)
<Spritz> I've tried on any system I have access to. Even 2.0 on Windows... same problem :(
<Spritz> I've googled a bit but can't really understand how to possibly fix
<jelmer> Spritz: that looks like a known bug in libsvn
<Spritz> jelmer: yep, that's what I gathered. No solution until know, or I couldn't find one
<Spritz> jelmer: that's pretty unfortunate and looks like git might be my only option even though I was very keen to try bzr out
<jelmer> Spritz: git would have the same problem getting that information out I imagine
<Spritz> jelmer: looks like it works fine...
<jelmer> Spritz: did you import the same URL?
<Spritz> yes
<Lo-lan-do> jelmer: Sorry, was away fighting motorcycle vendors.
<Lo-lan-do> About the patch: please push it, I probably don't have appropriate permissions.
<Lo-lan-do> (I could grant them to myself on alioth, but that wouldn't be fair-play, and I can't to that upstream anyway)
<Spritz> jelmer: the only difference being that git doesn't seem to fetch the whole history as far as I can tell
<jelmer> Spritz: that would indeed explain it
<jelmer> Lo-lan-do: I'm happy to add you to the pkg-bazaar-maint team fwiw
<Spritz> jelmer: I've also tried a bzr lightweight checkout with no difference though. Same error just comes faster
<Lo-lan-do> jelmer: Then why not.  I might end up uploading loggerhead though, beware :-)
<jelmer> Lo-lan-do: :-)
<Lo-lan-do> And other stuff I (or my clients) need.
<jelmer> Lo-lan-do: welcome aboard (-:
 * Lo-lan-do subscribes to the list
<OllieR> Is bzr really badly suited to deploying media files (e.g. video)? I am not actually going to be comparing versions of these .mov files (well it wouldn't work) but thought it would be convenient to track when files were added/removed and use it to deploy to another server...
<jelmer> OllieR: when it's working it keeps multiple copies of files in memory
<jelmer> OllieR: (at the moment, at least - this will likely be improved in the future)
<Lo-lan-do> jelmer: Every file?
<jelmer> Lo-lan-do: not at the same time, but if you change a 2Gb file and commit it that might require quite some memory at the moment..
<jelmer> OllieR: so if your files are significantly large, it would be a bad idea
<OllieR> in which case I should probably leave video files out side of my main website tree then
<Lo-lan-do> jelmer: 'kay, thanks.
<fullermd> VSpike: You could also use merge --uncommitted to copy over the changes from trunk and then revert them there...
<Lo-lan-do> jelmer: Shall I create a branch for my patch, or should I push to unstable directly?
<jelmer> Lo-lan-do: feel free to push directly
<Lo-lan-do> jelmer: Done :-)
<jelmer> cool ;-)
<jelmer> s/;-)/:-)
<Lo-lan-do> Any way to get log entries between two dates in the general case?  -r date:foo only works if there's at least one revision after foo
<jnz_> Hi, I have installed the subversion branch support for bazaar, but when I type bzr branch <url> to get the branch it tells me that "bzr: ERROR: Not a branch:"
<Lo-lan-do> What's <url>?
<jnz_> http://dev.hinezumi.org/svnroot/netsukuku/branches/bzr-updates/
<Lo-lan-do> I can get a listing of that with bzr ls
<Lo-lan-do> But try with the svn+http:// protocol
<Lo-lan-do> (Just add svn+ in front of your URL)
<jnz_> bzr: ERROR: Unsupported protocol for url "svn+http://dev.hinezumi.org/svnroot/netsukuku/branches/bzr-updates"
<jnz_> there's something missing?
<Lo-lan-do> Sounds like it.  How did you install bzr-svn?
<jnz_> by package, just downloaded it and installed
<Lo-lan-do> Does "bzr plugins" list it?
<jnz_> it doesn't :\\\\
<Lo-lan-do> What OS, what versions of stuff?
<Lo-lan-do> Also, you're not getting error messages such as incompatible versions?
<jnz_> Lo-lan-do, well now I have installed it correctly (subverty is still missing)... thanks however, it was a wrong install, I think I can manage with it :)
<Lo-lan-do> :-)
 * Lo-lan-do â food
<jnz_> wow there's also a plug-in for eclipse :)
<Stavros> hello
<Stavros> i have been using bzr for a while and tried bzr-git because i really want to use github. unfortunately, it has a bug that makes it not work in windows, and hg-bzr is no better. why doesn't bzr try to fix git support under windows and get *everyone* who wants to use git in windows to switch to bzr?
<Lo-lan-do> Stavros: I'm only an occasional contributor to bzr-git, but as far as I'm concerned there's a very good reason: I don't have a Windows box.
<Stavros> Lo-lan-do: hmm
<Stavros> that is a very good reason
<Stavros> i'd like to work on bzr-git, but i can't pull from its repo!
<Stavros> oh it's in launchpad
<Stavros> yay
<Stavros> my point is that more of the development effort should focus there, though
<Lo-lan-do> Feel free to focus your efforts there, I'm sure it'll be appreciated :-)
<Stavros> yeah yeah, the classic OSS argument, "you do it" :P
<Lo-lan-do> Keep in mind I'm just a bystander myself.  Not trying to be demeaning or anything.
<Stavros> i know, i wasn't offended or anything
<Stavros> i'm just saying that it could be a good thing for bzr if git support was working on windows
<Stavros> as it would be the only scm to do that
<SmileyChris> in using git for a recent project, I have become quite enamoured with the "Your branch is ahead of 'origin/master' by 11 commits." message. Is there any equivalent way of easily displaying this info in bzr?
<fullermd> missing I presume.
<lifeless> SmileyChris: 'bzr missing' - or do you mean it shows up in other commands?
<SmileyChris> lifeless: thanks, that was the command I wanted to know. But yes, it'd be great if it showed me that on a bzr status
<SmileyChris> fullermd: and thanks for your answer too, I just didn't grep it (or know if it was targetted at me)
<SmileyChris> how would I return just the "You have 46 extra revision(s)" message when using "bzr missing" rather than the full revision log?
<fullermd> Well, you could use --minie-only/--theirs-only to limit to showing one side, then use head(1) to throw away the rest of the info.
<fullermd> I don't think there's an arg to not output it directly.
<SmileyChris> bleh. but thanks
#bzr 2009-09-23
<johnf> jelmer: ping
<poolie> SmileyChris: when do you want that shown?
<poolie> only when you ask for it?
<poolie> or on every commit?
<SmileyChris> poolie: I found how the equivalent shows up in "git status" useful
<poolie> i can see how that would be useful
<poolie> robert was asking for status to also tell you what branch you're working on
<Peng_> Git keeps every branch on-hand, but bzr doesn't, so it isn't really possible..
<fullermd> Sure it's possible.  It's just really painful.
<SmileyChris> yeah, thinking about it I realise it's a bit different, git has the remote origin branch stored locally in it's repo
<poolie> well...
<poolie> in at least some cases we could easily do it
<SmileyChris> if the parent was local
<zsquareplusc> something tag like that points at the revision i pushed/pulled last could be useful. so you find out by looking at your local history if you did offline work
<zsquareplusc> hm, something like that could be hacked as plugin? pre-push hook: remove tag, then in post-push hook: add tag, move tag in post-pull and merge
<zsquareplusc> there could even be multiple such tags, one for each location one used in the past to push to
<spiv> Good morning.
<poolie> hello spiv
<spiv> poolie: I've got good progress on bug 429747 I think.
<ubottu> Launchpad bug 429747 in bzr "errors during cleanup mask underlying errors" [High,Confirmed] https://launchpad.net/bugs/429747
<spiv> I think I have a reasonable interface and implementation for the higher-order-function suggested in the bug, and I'm just fleshing out the tests and experimenting with how it works in actual code.
<spiv> There are a couple of variations, like "convenient way to run N cleanups so that they all run even if some fail", which commit at least ideally wants.
<spiv> I have some code for those too, but there's also a simple "run_cleanup" function that just runs a function and logs/reports any error without letting it propagate.
<spiv> poolie: still planning on coming up today?
<poolie> spiv, hi
<poolie> on phone atm, still basically planning
<poolie> depending on weather
<spiv> Yeah, it's a bit unpleasant.  Fascinating though...
<jkakar> lifeless: There?
<spm> spiv: with any luck the rain we've copped overnight and is still happening should settle it all down for you. big mud puddles everywhere but an improvement.
<spiv> spm: yeah, looking forward to that.
<spiv> spm: in the meantime, I've been admiring http://www.flickr.com/photos/plasticbag/galleries/72157622310168099/
<spm> wow! we got nothing like that. dusty, but wow.
<lifeless> jkakar: phone call
<jkakar> lifeless: Ah, okay.
<jkakar> spiv: Amazing photos!
<thumper> lifeless, poolie: just an FYI, but upgrading stacked branches works now (just tested on staging)
<thumper> for Launchpad anyway
<ub3rst4r> Hi
<ub3rst4r> does anyone know if tortoisebzr and tortoisesvn can be installed on the same system?
<SamB_XP_> ub3rst4r: is there any reason it wouldn't be possible ?
<ub3rst4r> i dunno
<igc> ub3rst4r: I believe they can be
<lifeless> jkakar: hi
<jkakar> lifeless: Heya!
<jkakar> lifeless: I'd like to use cmd_alias in Commandant, ideally making it automatically available to any Commandant-based program.
<jkakar> lifeless: I've implemented a prototype and got it working.
<jkakar> lifeless: There's a couple of warts though:
<jkakar> 1. It prints 'bzr' in it's output.  I've dealt with this in the help text produced by Command.get_help_text by using text.replace("bzr", "my-program").  This trick isn't really possible with the cmd_alias command.
<jkakar> 2. I have to monkey patch the bzrlib.config.config_filename to return the patch to my program's configuration file, instead of ~/.bazaar/bazaar.conf.
<jkakar> lifeless: So, I'm thinking about making the change in Bazaar to make this easier.
<jkakar> I think these are: 1. Add a set_config_filename function to bzrlib.config.
<lifeless> if I can tempt you with doing a little more
<jkakar> 2. Add get_program_name and set_program_name functions (probably to bzrlib.__init__) which default to 'bzr'.  Change places that use 'bzr' to use the function.
<lifeless> we'd like /etc/bazaar/*.conf to work (bazaar/locations/..)
<jkakar> 3. Make %(program-name)s work in docstrings.
<lifeless> this would seeem to conflict with just set_config_filename
<jkakar> lifeless: Yeah, it feels like what I'm proposing is good for me, but not necessarily clean for Bazaar.
<jkakar> lifeless: That's why I wanted to chat you up, to figure out what the right thing to do is.  I'm happy to be tempted to do more than I originally intended. :)
<lifeless> jkakar: so I think if you got /etc/bazaar/* working, and then added something that works for you, we'd both be happy
<lifeless> for get/set program name.
 * fullermd is very worried about implementations of /etc/bazaar/*
<lifeless> that's fine, I wouldn't add it to __init__ though
<lifeless> commands for now please
<jkakar> lifeless: Ah, so for /etc/bazaar/* you want something like a set_config_path?
<jkakar> lifeless: commands sounds like a good place for that, yeah.
<lifeless> and 3 seems kindof obvious
<jkakar> Cool.
<lifeless> fullermd: in what regard?
<lifeless> jkakar: for substitions, uhm, there should be a method on Command
<lifeless> or something like that, so it can be locally controlled yada yada yada
<lifeless> either to do, or to look up the thing being substituted
<lifeless> we have 2 primary use cases today: manpage generation, and online help
<jkakar> lifeless: Yeah, I was thinking about something like adding a check for a get_substituted_variables function on command, and then passing the dict of default + command variables to Command.get_help_text.
<fullermd> Well, in a sentence, because it brings up a lot of problems in our config structure, which means either (a) a very long process of working them out, or (b) an implementation that explicitly disavows doing that, and probably makes it worse in the long run.
<lifeless> fullermd: what sort of problems - I'm completely at a loss here
<jkakar> lifeless: I'll have to figure out how manpages are generated to make sure the substitution logic lands in the right places.
<lifeless> jkakar: see make docs
<jkakar> lifeless: Ta.
<fullermd> It relates to the issue of "branch.conf parameters that should be propogated by branch vs shouldn't", which we unsatisfactorally sidestep at the moment.
<fullermd> Some things we'd want to hard-override per system, some we'd want to default.  Mechanism, blah blah.
<fullermd> (and the unrelated issue of "/etc?  No, it should be..." of course)
<lifeless> fullermd: will you be unhappy if jkakar puts a patch forward that makes /etc/bazaar/bazaar.conf & locations.conf work ?
 * fullermd shrugs.
<fullermd> I don't get a vote in such things anyway.
<fullermd> I'm just rather pessimistic today, and it feels lose-lose to me.
<fullermd> If the discussion doesn't come up, we've added another layer of pre-existing conditions we have to somehow not screw up when we DO add such capabilities.
<fullermd> If it does, I'm sure it will get to a useful conclusion almost as fast as per-branch rules.
<lifeless> fullermd: so per branch rules stuck because the folk needed in such a discussion where backlogged way above eyeballs with performance
<lifeless> fullermd: and its non trivial.
<lifeless> fullermd: If you agree that system wide configuration is useful [do you?]
<fullermd> I know.  I don't claim it's because of malice or indifference, but it still bogs down.
<poolie> i think we certainly want system-wide config
<poolie> we can always say 'we suggest you don't set X system-wide'
<lifeless> yup
<lifeless> jkakar: so - we have a go ;)
<poolie> jkakar: can i suggest that rather than setting these things individually there should be some kind of ConfigFactory
<fullermd> Absolutely.  We very much need many levels of configuration beyond "OK, tell all your users to manually edit this file to add these lines"
<poolie> and you replace that wholesale to make it think it's called something other than bzr
<jkakar> poolie: Sounds like a plan.
<jkakar> lifeless: Yep, I'll start on it tonight. :)
<poolie> lifeless: do you know off hand how to ask apt whether a set of packages would be installable, short of installing it?
<lifeless> nope, sorry
<lifeless> theres a graph resolver thingy
<poolie> justinstall --dry-run?
<lifeless> oh
<lifeless> I thought you meant pyapt :)
<lifeless> thingywhatsit
<jkakar> apt-get -u install foo?
<lifeless> apt-get -s install foo
<poolie> mm
<poolie> https://bugs.edge.launchpad.net/ubuntu/+source/devscripts/+bug/434987
<ubottu> Launchpad bug 434987 in devscripts "chdist fails with "E: Internal Error, Could not perform immediate configuration (2) on libattr1"" [Undecided,New]
<jkakar> Ah, -s it is indeed.  I'm used to using -u with upgrade and dist-upgrade so thought it might work with install (it doesn't).
<poolie> -u shows what will be upgraded
<poolie> lifeless: http://images.apple.com/macosx/technology/docs/GrandCentral_TB_brief_20090903.pdf <-- a bit interesting
<lifeless> images...pdf :P
<lifeless> [reading]
<lifeless> this explains why they did the C code blocks work :P
<Meths> I needed to use non bzr diff and patch.  The patch is only changing a few lines in the files but bzr diff shows that bzr wants to change the whole file for those changed.  Can I do anything about this?
<davidstrauss> Meths: you may be dealing with some EOL issues
<lifeless> Meths: are you on windows?
<Meths> yeah
<lifeless> patch has probably changed the line ending on the file
<lifeless> you could see if it has an option to control that, and if it does bzr revert then apply the patch again with that option
<Peng_> Diff and patch? Like, GNU diff and patch?
<Meths> ah, so a dos2unix should get a normal diff, I'll go try now, thanks.
<Meths> Peng_: yep
<Peng_> What are you doing? Why not use 'bzr merge' or a revision bundle or somesuch?
<Meths> Sweet, dos2unix fixed them up nicely, shoulda known
<thumper> :(
<thumper> a crash
<Peng_> What crashed?
<thumper> bzr
 * thumper is filing a bug
<Peng_> Ah.
<thumper> https://bugs.edge.launchpad.net/bzr/+bug/435000
<ubottu> Launchpad bug 435000 in bzr "bzr crashed on commit after removing a directory of files" [Undecided,New]
<Peng_> Nice bug number.
<thumper> I've made a local branch
<thumper> and I've just committed to it
<thumper> but I want to push the branch as of one revision ago to LP
<thumper> is there an easy way to do this?
<Peng_> bzr push -r 123
<Peng_> Well, -2
 * igc lunch
 * thumper tries
<spm> spiv: more dust photo's, tho .. I dunno. 'shopped maybe? http://www.militaryphotos.net/forums/showthread.php?t=165656
<spiv> spm: nah, I used to live near there.  That was a regular sight ;)
 * spm thinks for a suitable response. can't, so just sniggers.
<poolie1> hello all
<lifeless> hai
<lifeless> versioning yourself now?
<Peng_> poolie1.1.1.1.1.1
<Peng_> :D
<poolie1> is irc bug
<Peng_> No, it would be like poolie1.1.1.1.1397.1.
<Peng_> Anyway, I'm done now.
<poolie> lifeless: any particular reason for bug 435026?
<ubottu> Launchpad bug 435026 in bzr "bzrlib.ui docstring references factories not in the module" [Wishlist,Confirmed] https://launchpad.net/bugs/435026
<spiv> Hmm, I think clearing test._log_contents in more cases (e.g. not applicable, known failure) significantly cuts the test suite's memory consumption...
<Peng_> How significantly?
<spiv> it's only at 59M after 1500 tests, and growing very slowly.
<spiv> Give me a few minutes and I'll have a decent direct comparison.
<lifeless> poolie: yes, fixing a deprecation warning you added ;)
<lifeless> poolie: in conflictchecker, its cron is annoying everyone watching it ;)
<poolie> ?
<poolie> which one?
<lifeless> poolie: direct construction of ProgressBar
<poolie> and what checks the docstring?
<lifeless> programmers
<lifeless> I read pydoc to find out what I should be using
<lifeless> and had forgotten that things were in submodules, so when I added ui_factory=bzrlib.ui.TextUIFactory() - well it failed ;)
<poolie> i'll fix that bug if you're not immediately going to
<lifeless> poolie: please
<lifeless> poolie: its not major, but having observed it I just wanted to capture it
<poolie> sure
<poolie> i just wondered if you were running an api doc tool or something
<lifeless> no, interesting idea though
<spiv> Hmm, or maybe it's making less difference than I thought.  I thought I was seeing much worse memory consumption yesterday though... hmm.
<Peng_> ~1514 tests == VmPeak of about 205 MB for me.
<spiv> Peng_: I'm running the "(?i)commit" subset, for no particular reason.
<spiv> And on 32-bit.
<Peng_> I was running no particular subset, on 32-bit.
<spiv> I'm not sure VmPeak is very useful, I think Python tends to allocate lots more address space than it actually uses.
<Peng_> VmPeak is interesting because everything else is the current value, not the peak value.
<Peng_> VmRSS:     85584 kB
<spiv> I tend to look at VmHWM.  I wouldn't mind an authorative link for exactly what the different fields in -Dmemory mean...
<spiv> I know *roughly*, but details tend to matter.
<Peng_> I have no idea what VmHWM is.
<spiv> Peng_: man proc claims "Peak resident set size ("high water mark")"
<Peng_> Oh, cool!
<Peng_> That sounds perfect!
<Peng_> spiv++
<poolie> lifeless: http://pastebin.ubuntu.com/276214/ - pre-review welcome
<lifeless> what am I looking at?
<RenatoSilva> is there how to query bzr status of a file?
<lifeless> bzr st file
<RenatoSilva> I'm doing a rebase but when I commit the change list shows "missing some_file.OTHER"
<poolie> lifeless: the whole file is new, it's an attempt at interface testing of uifactory
<lifeless> poolie: ok
<poolie> i think it's uncontroversial
<poolie> but that's why i'm asking
<lifeless> poolie: I just needed some context :)
<poolie> there's a comment explaining the point, but we also talked about this a while ago
<RenatoSilva> a conflict occurred in rebase, so I solved it manually and bzr resolve filename, but now when I commit filename.OTHER shows as missing
<lifeless> poolie: I'd be very strongly inclined to use injection rather than subclassing here.
<RenatoSilva> is this normal? I don't want that artificial info on the history
<lifeless> RenatoSilva: I don't really know, few folk in the bzr community use rebase.
<poolie> if the files were added on separate branches that you're now rebasing together
<RenatoSilva> lifeless: it seems very interesting!
<poolie> it's reasonable that you'd end up with
<poolie> that kind of conflict and it's not necessarily a problem
<poolie> lifeless: tell me why? just because we're generally doing that?
<RenatoSilva> poolie: I'm not asking about the conflict itself, which was solved
<poolie> i was originally going to do that but the problem i ran into is that the resource i want to inject includes some code that makes assertions about what happened
<RenatoSilva> poolie: I'm asking about the artificial "missing xxx.OTHER" when committing
<poolie> and that code can most conveniently be written within a subclass of TestCase
<lifeless> poolie: I think it would fit and scale better
<poolie> to use scenarios?
<lifeless> poolie: yes
<poolie> mm
<lifeless> poolie: possibly in combination with resources, or something the encapsulates the setup of the fixture
<poolie> how would you handle having assertion-making code be parameterised?
<lifeless> s/the/that/
<RenatoSilva> lifeless: I just achieved a clearer, natural history, as described in http://pastie.org/625271
<RenatoSilva> lifeless: a guy from #git said that it may work for small feature branches, but not for long-lived
<lifeless> so
<lifeless> your conflict is probably a name conflict
<lifeless> xxx.OTHER means rebase is trying to readd a file already on the other side
<lifeless> this could be a bug in rebase
<lifeless> or in how you're using it.
<RenatoSilva> lifeless: weird! I uncommitted, then committed again and the xx.OTHER is not reported anymore
<lifeless> thats because the pointer to it was removed on the first commit
<RenatoSilva> so it's a bug right
<lifeless> you may find you get a delete+add when you merge to the other branch
<lifeless> and that your history of that file is disconnected
<lifeless> RenatoSilva: no, it may be you using rebase when you shouldn't :). Or it may be a bug. I don't know.
<RenatoSilva> lifeless: bzr resolve --all maybe does not clean .OTHER files
<lifeless> poolie: well, when I look at your code, you have 'create a resource' code, 'execute the test' code, and 'check the resource' code.
<lifeless> RenatoSilva: the file was deleted, but your tree still wanted it.
<lifeless> RenatoSilva: because it was part of the conflict
<RenatoSilva> lifeless: conflicts on a merge are displayed as BASE and THIS, in rebase it is BASE and OTHER, maybe bzr resolve does not know OTHER
<lifeless> RenatoSilva: conflicts within a file are BASE+THIS+OTHER, conflicts about *names* show up differently.
<lifeless> RenatoSilva: but I'm having to guess because I don't know what happened
<RenatoSilva> lifeless: well, I think bzr resolve --all should have deleted all info about those files
<jkakar> Woot, Command.get_help_text is using the program name from a centrally registered ProgramInfo instance!
<poolie> spiv: https://bugs.edge.launchpad.net/bzr/+bug/435048
<ubottu> Launchpad bug 435048 in bzr "many get_parent_map calls during walk to common revisions" [Medium,Confirmed]
<spiv> poolie: thanks
<lifeless> is that new or old ? :)
<spiv> lifeless: the bug?  Dunno, that's why I asked him to file it ;)
<RenatoSilva> lifeless: http://yfrog.com/0ximagemxap
<RenatoSilva> lifeless: better resolution: http://img33.yfrog.com/img33/5295/imagemxa.png
<lifeless> RenatoSilva: yes, I understand what you're doing
<lifeless> RenatoSilva: that doesn't mean I know what happened
<lifeless> RenatoSilva: you need to look at the per file graphes
<lifeless> I will also note that you're publishing these branches as you develop, so rebase really isn't a good choice.
<RenatoSilva> lifeless: for solving the .OTHER issue? I think it's ok now
<lifeless> RenatoSilva: Until you've checked the per file graph in both branches after merging back, you can't know.
<RenatoSilva> lifeless: confusing
<lifeless> RenatoSilva: how so?
<RenatoSilva>  publishing these branches as you develop, so rebase really isn't a good choice. ----> I don't know how would that rebase affect another derived branches, I think that it would make merge easier. I don't know...
<RenatoSilva> maybe I need to get more experienced
<RenatoSilva> try it and see....but as you say that rebase is bad, maybe I'll keep the former approach (update merges)
<RenatoSilva> the wonderful thing of that rebase is that it's just liked I branched trunk today, and I could bzr push (not merge) to trunk now
 * RenatoSilva flips a coin for pushing userprefs or userprefs.rebase
<lifeless> RenatoSilva: rebase _breaks_ the ability to pull or merge the old branch
<lifeless> RenatoSilva: it breaks the links in history
<lifeless> RenatoSilva: in the git world, rebase is used for private branches, not for ones shown to the world
<RenatoSilva> well, I can't understand it atm, hope to do in the future as I get more used to it...
<RenatoSilva> thank you anyway!
<vila> hi all
<lifeless> hi
<lifeless> http://paste.ubuntu.com/271990/ have you reproduced at all?
<vila> lifeless: actually, yes, just this morning on gentoo, but it's still... random
<lifeless> vila: open a bug please
<lifeless> was it ext4 again?
<vila> lifeless: err, let me check, I think the last time was on karmic no ?
<vila> no ext4 on my gentoo VM
<vila> lifeless: so tmpfs or ext3
<jkakar> lifeless: I think I've done the basic things necessary to have customizable program information (name and version right now) and substitution in help text generated from docstrings.
<jkakar> lifeless: I'm going to start a second branch, based on this first one, to update bzrlib.builtins, since I've only touched bzrlib.commands so far.
<jkakar> lifeless: Should I create a merge proposal for the first branch now, or would you prefer them together?
<vila> lifeless: bug #435065
<ubottu> Launchpad bug 435065 in bzr "Random test_hammer_hashcache failure" [Medium,Confirmed] https://launchpad.net/bugs/435065
<vila> lifeless: I'll comment to add the new occurrences if ever
<AfC2> at first I thought that said "test hammer headache failure" which I would think would be an easy test to pass; apply hammer to head, and assert().
<vila-dentist> AfC: :D
<lifeless> vila-dentist: thanks
<jkakar> Are there tests for the bzrlib.builtins module?
<jkakar> Ah ha, bzrlib/tests/commands.
<lifeless> jkakar: not really
<lifeless> jkakar: they are ... odd
<lifeless> jkakar: bzrlib/tests/blackbox/test_foo is our current preferred place
<jkakar> lifeless: Yeah.
<jkakar> lifeless: I'd like to write a test that basically goes through each builtin command and calls Command.get_help_text() on it, to make sure that the interpolation works properly.
<jkakar> I don't want to misspell %(program-name)s and not find out until it's too late.
<lifeless> jkakar: don't
<jkakar> lifeless: Heh, okay.
<lifeless> jkakar: I think thats essentially a CPU time waste
<lifeless> because, the code is in command.py
<jkakar> lifeless: Yeah, I can see that.  On the other hand, I do want to make sure users don't get a broken experience.
<lifeless> so we should have a test there
<lifeless> if a particular command wants to vary, it should be able to
<lifeless> I don't think that e.g. 'cmd_push' should show up as anything other than 'bzr push' in its help
<jkakar> There's a test for the generic logic, just not each actual docstring for each builtin command.
<jkakar> lifeless: Oh, hmm.
<jkakar> lifeless: I've gone and replaced all the 'bzr' instances in the help text with %(program-name)s.
<lifeless> there are commands that are general and reusable
<lifeless> such as alias, where it makes sense
<jkakar> lifeless: Maybe I should only do it for commands that are obviously reusable?
<lifeless> jkakar: I think you should do it for the ones you want to reuse, so we can evaluate if it makes sense etc
<lifeless> cmd_help :)
<lifeless> I don't see that branding the front end for 'cmd_serve' makes a lot of sense though.
<jkakar> lifeless: Also cmd_version.
<lifeless> the text is easier to read for program authors as 'bzr this'
<lifeless> and 'bzr that'
<jkakar> lifeless: Okay, I guess I'll revert the changes that aren't necessary.
<jkakar> lifeless: It is, yeah.
<lifeless> so we should only pay the price of having it have subst vars when there is a benefit
<jkakar> lifeless: Right now it always tries to.
<lifeless> [a benefit we want :P]
<lifeless> jkakar: the cost to calculate them is low, I'm fine with the program always translating
<jkakar> lifeless: Okay, cool.
<lifeless> jkakar: cmd_version seems surprising to me, I would have expected --version to be what you advertise/want folk to see
<jkakar> lifeless: I was just looking at it and it's not as trivial to replace as I'd hoped.
<jkakar> lifeless: I have a cmd_version in commandant.builtins that prints the program name and version and has a --short option.
<jkakar> lifeless: I was hoping to remove it and use the version in bzrlib, but it's not obvious just now how to do that nicely.
<lifeless> I have two thoughts here
<lifeless> one is that --version != 'frontend version'. I wish bzr didn't have a 'version' command.
<lifeless> the second is that you can probably write an appropriately hookable thing, but its such a shallow thing I'd rather we encouraged people to do what bzr does
<lifeless> and include all sorts of useful things there
<lifeless> by not giving the a fork
<lifeless> the second is kindofweakandarguable
<jkakar> Yeah, makes sense.
<jkakar> Being able to install a custom bzrlib.version.show_version would be the trick I guess.
<lifeless> fullermd: hey
<lifeless> fullermd: you still around?
<bialix> hello bzr
<AfC> Where do you say in Launchpad what version of Ubuntu you're running when reporting a bug?
<beuno> AfC, in the comment?  :)
<beuno> otherwise, you file the bug against the package in the specific series
<lifeless> AfC: ubuntu-bug will do that for you
<lifeless> beuno: garh no
<AfC> lifeless: what's that?
<lifeless> AfC: are you filing a bug upstream on e.g. bzr, or on something in ubuntu itself?
<AfC> beuno: really? You mean their bug tracker devoted to bugs about a Linux distro doesn't have concrete metadata for which distro version something is being reported about?
<AfC> lifeless: ubuntu
<lifeless> AfC: then you should run, on your machine 'ubuntu-bug PACKAGE'
<lifeless> AfC: and thats all :>
<AfC> oh
<beuno> AfC, correct. Primarily because it's not ubuntu-specific
<AfC> [well, in this case not sure what package, but I guessed]
<AfC> beuno: well that's stupid.
<AfC> beuno: because it may not be Ubuntu specific, but it's surely Ubuntu central!
<lifeless> AfC: the feature of tracking versions <->packages is called 'infestation'. We had it, but not polished, so it was removed to avoid the massive scaling problems it engendered.
<lifeless> beuno: I think you should have some coffee; or some sleep.
<AfC> lifeless: sure
 * igc dinner
<beuno> lifeless, I've had both!
<AfC> lifeless: but I mean, you'd think it'd be important for me to concretely be able to say
<lifeless> beuno: because you're suggesting things the ubuntu bugs team would be quite unhappy with!
<AfC> "THIS IS A RELEASE CRITICAL BUG IN KARMIC". You know, just FYI. Trying to help. Hello? Anyone?
<lifeless> AfC: so by definition we can only have RC bugs with unreleased code ;)
<beuno> lifeless, I don't think I'm suggesting anything at all. I'm stating how things work!
<lifeless> AfC: a floating bug is presumed to be in karmic
<lifeless> beuno: only ubuntu-bugs & teams with similar privileges can open series bugs; other folk have to nominate.
<AfC> lifeless: well, sure. I'm taking the definition from what it meant in Debian terms ~ 10 years ago. I'm sure things have involved.
<AfC> evolved*
<lifeless> beuno: and its used to track planned work, not present-in
<lifeless> beuno: in Ubuntu's usage of launchpad today.
<AfC> anyway, it just seems kinda important to be able to indicate I'm actually using Karmic so that maybe this report is timely, etc
<AfC> oh well
<AfC> they'll see it some time in 2012.
<lifeless> AfC: the vast bulk of reports are from $current
<lifeless> end users rarely file bugs compared to contributors
<AfC> lifeless: so am I running $current or $current + 1?
<lifeless> (and by running karmic you're a contributor)
<AfC> lifeless: yeah, not for long
<lifeless> in my lingo you're running $current
 * AfC can't wait to not be a contributor anymore. This is hell
<AfC> Yesterday it was "crash the system on logout".
<AfC> I mean, sure, that's one way to shut down, but not quite what I had in mind :)
<jnz_> Hi, where's the plugins directory? it isn't ~/.bazaar/plugins?
<AfC> jnz_: yes
<jnz_> it isn't there :\\\
<beuno> jnz_, you can create it
<AfC> lifeless: and, of course, "try to use 3G card a 2nd time makes CPU spin to 100%, no workie for you" is not exactly fun either. Especially when it was working fine 4 days ago.
<jnz_> ok, and what about this: Unable to load plugin 'filters'. filters I don't know what kind of plugin it is.
<AfC> Sorry, I'll stop venting now. Just been a really frustrating few days. Not really what I was expecting.
<ronny> how do i add the actual root to a MemoryTree on a fresh branch
<AfC> jnz_: does the command
<AfC> $ bzr plugins
<AfC> jnz_: give you sane looking output?
<ronny> here is some random stuff i tried, im a bit puzzled http://paste.pocoo.org/show/141082/
<jnz_> yes AfC, but I don't see filters
<ronny> bzr is v2.0rc2
<lifeless> jnz_: run the failing command with -Derror
<lifeless> jnz_: that will give a backtrace
<lifeless> ronny: look in the bzr test suite for  MemoryTree, you can see example usage
<lifeless> ronny: note that when you drop the lock on a MemoryTree it resets to no-changes
<lifeless> AfC: well, to be fair we haven't hit Beta yet. its a shame its rough though
<ronny> hmm, now i have to check, why i loose the lock
<lvh> If I use a different repo format than the launchpad mirror, pulls will b ereally slow, right?
<lvh> eh, I mean branch (someone is trying to get a copy of an existing branch on lp)
<ronny> lifeless: thnaks for the hint with the lock, didnt think that one would have an issue
<lvh> (basically he wants git clone)
<lifeless> lvh: if the format is different, some degree of transformation will be needed
<lifeless> lvh: just doing 'bzr branch lp:foo /tmp/foo' will preserve the format
<jnz_> the command is ok, then the problem is the bzr plugin for eclipse
<lvh> lifeless: yeah, but hes' going to make a lot of branches off of that, so I started with bzr init-repo
<lvh> lifeless: not sure if that changes anything
<lifeless> if the thing you're branching from isn't in the default format, init-repo would have a different format
<lvh> right
<lvh> would you notice that in the form of ridiculously slow bzr branching? (eg, 10kb/s while 'Finding revisions')
<lvh> i thought that transformation happened afterwards
<lvh> current repo format: Packs 6 rich-root (uses btree indexes, requires bzr 1.9)
<AfC> lifeless: _really_? I thought alpha [that you warned me away from] was only the first month / six. Damn. My mistake. I really should have been running Intrepid after all.
<lvh> I'm not entirely sure about what he's using, but if I use bzr init-repo I get 2a
<lifeless> lvh: right, and yes
<jkakar> lifeless: Woot, it's ready: https://code.edge.launchpad.net/~jkakar/bzr/custom-project-name/+merge/12267
<jkakar> And now it's time for bed.  G'night and thanks for the help!
<lifeless> gnight
<lvh> lifeless: so I should tell him to get rid of the current repo dir, and just use bzr init-repo --1.6.1-rich-root twisted
<lvh> jkakar: bye :-)
<lvh> err, --1.9-rich-root
<lifeless> lvh: yes
<lifeless> or be very very patient
<AfC> lvh: you kinda want to avoid cross format all the time. It's really ok to use one or the other [assuming you're not in a corner case that the newer format (and the code that leverages it) requires]; if you use an older one then all upgrade in concert you'll be ok
<lifeless> lvh: I believe the twisted wiki page documents this already
<lvh> lifeless: ah, yeah, I should probably link him to that
<lvh> lifeless: Thanks!
<jml> jkakar, I like your new patch.
<jml> (I have a few questions, but sadly bzr patch code review has to wait on days that Launchpad is releasintg)
<lifeless> jml: btw, you can trim -some- content out in mail replies ;)
<ronny> hmm
<ronny> lifeless: is there any other stupid thing one could do to get that exception
<ronny> (im pretty convinced i keep the lock)
<ronny> lifeless: here is my session: http://paste.pocoo.org/show/141106/
<lifeless> ronny: you haven't made the directories
<lifeless> ronny: I'm not sure if you can on MemoryTree; as previously discussed its a test double, its not 'complete'
<fullermd> lifeless: You pung?
<lifeless> fullermd: yah; thinking I might tap you for a few BSD packages
<lifeless> testtools, junitxml & subunit
<ronny> hmm, appearantly it has mldir
<ronny> eh mkdir
<ronny> lifeless: all that path2id/id2path stuff is pretty frustrating
<lifeless> ronny: all what stuff; you should only rarely need to call it
<ronny> lifeless: well, i need it for setting file contents for example
<lifeless> its late here and I'm not really up for an API discussion right now, but perhaps you could mail the list?
<fullermd> Mmm.  Possible I guess, but not with any alacrity.
<lifeless> fullermd: I'll drop you a mail
<fullermd> I'm leery of setting myself up as maintainer for something I don't myself use and understand.
<lifeless> fullermd: fair enough; I just want to bootstrap stuff for drizzle:)
<nevans> Q: Is there some special shell I could/should use for a user who only has access to a server for bzr?
<Kinnison> How do I convert an old *old* subtree-capable tree to the new repo format?
<Kinnison> Hmm, s'not that old I think
<Kinnison> Standalone tree (format: pack-0.92-subtree)
<Lo-lan-do> bzr upgrade --format=2a
<Kinnison> bzr: ERROR: Cannot convert from format <RepositoryFormatKnitPack3> to format <RepositoryFormat2a>.    Does not support nested trees
<Lo-lan-do> Ah, subtree, sorry.
<Lo-lan-do> I mixed with rich-root.
<jelmer> Kinnison: you can't upgrade directly
<bialix> Kinnison: IIRC, subtree should be possible to convert to rich-root
<jelmer> Kinnison: But you should be able to pull from a subtree repo into a rich root repo
<jelmer> Kinnison: so the work around is basically:
<jelmer> Kinnison: bzr init --2a /tmp/foo; bzr pull -d /tmp/foo /path/to/subtree/branch
<Kinnison> jelmer: aha, ta
<jelmer> Kinnison: if you actually have nested trees this may give strange errors
<jelmer> Kinnison: which is why upgrading is refused at the moment
<jelmer> Kinnison: we should really just do a check of the contents of the repo and only allow upgrading if there aren't any nested trees
<Kinnison> It was simply that it was an old svn upgrade i think
<eagles0513875> hey guys im having an issue when running the bzr bd command it keeps complaining about my secret key not available
<eagles0513875> i uploaded my key to the keyserver.ubuntu.com as well as verified the email and activated so the public key is active
<eagles0513875> anyone have any idea :(
<Kinnison> What is the 'bd' command?
<james_w> eagles0513875: the name in the changelog doesn't match any UIDs on your GPG key
<eagles0513875> ahhhh james_w ok
<eagles0513875> Kinnison: builds packages
<eagles0513875> thanks james_w
<james_w> https://wiki.ubuntu.com/UbuntuDevelopment/Uploading#Signing%20the%20package
<james_w> "The UID must be byte-for-byte identical to the Changed-By value (including the key "comment"), so any changes in the name or email address (even down to whitespace) will cause the match to fail"
<james_w> see the bit under that for checking this is the case and the ways to fix it
<eagles0513875> ahhhhhhh
<eagles0513875> ok thanks
<eagles0513875> james_w: does that link still apply if im only packaging somethign to test on my local machine
<james_w> in that case you don't need to sign it
<james_w> "bzr bd -- -uc -us"
<eagles0513875> bzr bd --uc -us
 * idnar scratches his head
<idnar> bzr: ERROR: Cannot commit from a lightweight checkout to a stacked branch. See https://bugs.launchpad.net/bzr/+bug/375013 for details.
<ubottu> Launchpad bug 375013 in bzr "lightweight checkout commit to a stacked branch does not work" [High,Triaged]
<idnar> I just read that bug, but I don't understand the part about "lightweight checkout"; as far as I know, I don't have any lightweight checkouts involved here
<idnar> I guess I'm misunderstanding something about stacking
<idnar> should I be using a shared repository instead?
<bialix> idnar: run bzr info -v and you'll see what you actually have
<idnar> "Standalone tree (format: 1.6)"
<bialix> I don't understand what is stacked then
<bialix> idnar: is your tree stacked?
<idnar>   parent branch: /home/mithrandi/code/Fusion/trunk
<idnar>      stacked on: /home/mithrandi/code/Fusion/trunk
<igc> james_w: will you get a chance to look at bug 425507 before karmic beta freeze?
<ubottu> Launchpad bug 425507 in bzr-explorer "[needs-packaging] bzr-explorer should be packaged in ubuntu and the ppa" [High,Confirmed] https://launchpad.net/bugs/425507
<james_w> no, afraid not
<bialix> idnar: bzr info /home/mithrandi/code/Fusion/trunk
<Lo-lan-do> I thought bzr-explorer was Windows stuff?
<idnar> bialix: that's also "Standalone tree (format: 1.6)", not stacked on anything
<bialix> Lo-lan-do: it was joke?
<sidnei> igc should have called it bzr-nautilus
<sidnei> or bzr-navigator
<igc> james_W: would pitti or someone else be able to tackle it do you think?
<bialix> or RapidBzr
<Lo-lan-do> bialix: No, I must have been confused.  What was the alternative to TortoiseBzr?
<bialix> idnar: I'm give up
<james_w> igc: well, we're well past the time when new packages are normally accepted
<idnar> I guess I'll try shared repositories instead
<bialix> Lo-lan-do: bzr-explorer is
<Lo-lan-do> Oh.  But it's portable then, right?
<james_w> igc: someone may have time, but they will also need a freeze exception
<bialix> Lo-lan-do: yes, it's Qt-based as QBzr
<Lo-lan-do> bialix: I see. Thanks.
<bialix> Lo-lan-do: but bzr-explorer can use bzr-gtk plugin
<bialix> funny, eh?
<igc> james_w: I thought poolie's ffe was going to cover explorer as well as bzr core - maybe it didn't
<igc> Lo-lan-do: see http://doc.bazaar-vcs.org/explorer/en/
<igc> time for some sleep
<igc> night all
<bialix> igc: night
<igc> night bialix
<james_w> igc: https://bugs.edge.launchpad.net/ubuntu/+source/bzr/+bug/430467/comments/4, so it wasn't clear if that was how it was intended to be
<ubottu> Launchpad bug 430467 in subvertpy "[ffe] please ship bzr 2.0.0 or 2.0.0rc2 in Karmic" [Undecided,Fix released]
<james_w> night igc
<jkakar> jml: Cool.  I'll be happy to try and answer whatever questions you have.
<magcius> What does bzr use for an SSH client on Windows?
<Lo-lan-do> Paramiko or Putty, I think.
<magcius> How would I add an ssh key to that in Windows?
<Peng_> Looks like bzr can use paramiko, putty, OpenSSH or SSH Corp. SSH.
<Lo-lan-do> I know Putty can. No idea about Paramiko though.  And I don't have a Windows box :-)
<Peng_> Whether you can run the latter two on Windows...
<Peng_> Paramiko can use either Putty or OpenSSH's keys, IIRC.
<dsuch> magcius: Use Pageant for that http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
<magcius> Peng_, what does Bazaar use in the Windows distribution.
<Peng_> I honestly don't know which one is preferred.
<Peng_> What matters is which one it's using for *you* anyway.
 * Peng_ tries to dodge question.
<bialix> hello jam
<jam> hi bialix
<bialix> may I ask you some questions about reference counting in Python?
<jam> magcius: We generally use paramiko first, and I recommend using Pageant (from the putty utils)
<jam> you can use that as an agent, and add your keys there
<jam> (putty is a decent manual tool, it makes a bad subprocess, so we prefer not to use it for the ssh connection)
<jam> bialix: sure
<meoblast001> hi
<meoblast001> i had a 3 MB ogg and mp3 file in my project's examples at particular points
<meoblast001> isn't that bad for people who are checking out my project? wouldn't it increase the download time?
<Peng_> Yes, but 3 MB isn't all that much.
<Peng_> Besides, it's too late to remove it from the history now.
<meoblast001> i know :(
<meoblast001> i was contemplating rerolling my revisions
<meoblast001> Peng_: is a 10MB .bzr directory for a 77 revision project normal?
<bialix> you can try to use rebase plugin
<meoblast001> it's 10.3 MB
<bialix> 100MB would be much worse
<meoblast001> bialix: would the rebase plugin allow me to remove an entire directory from every commit?
<bialix> mmm, not really
<bialix> you can replay your revisions
<bialix> you can delete some revisions
<meoblast001> oh
<meoblast001> a rerolling script sounds better if i would have to
<meoblast001> and what do you mean "100MB would be much worse"
<bialix> to remove entire directory you can look at fast-import pluign
<meoblast001> is 10.3MB bad?
<bialix> it depends
<meoblast001> what does fast-import do
<bialix> fast-import has filter feature
<bialix> you can filter out some files or directories
<meoblast001> from everything?
<Peng_> Just out of curiosity, which repo format are you using?
<meoblast001> 1.x
<Peng_> And does the 10.3 MB include junk in .bzr/repository/obsolete_packs and .bzr/repository/upload?
<bialix> I don't understand your question: "from everything"
<meoblast001> obsolete_packs is empty here
<meoblast001> so is upload
<Peng_> Overall, a 10 MB repo isn't very interesting... Lots of large projects are many times larger.
<Peng_> If you don't mind, got an URL?
<Peng_> I'm just curious.
<bialix> 10MB usually means you have a lot of files, or several big files inside
<bialix> for 77 revisions
<meoblast001> https://launchpad.net/amethyst-mm
<meoblast001> i want the examples to be gone pretty much, they are quite unnecessary
<meoblast001> well, at least the ogg and mp3 file that i had
<Peng_> I could go either way. 10 MB isn't that much data, but the longer you wait, the harder it'll be to recreate the branch...
<Peng_> In my case, laziness would probably win out over tidiness. :P
<ronny> jelmer: what am i supposed to put into dulwichs object_stroe.add_objects(objects)
<ronny> jelmer: trying a list of git objects, but it wants a list of tuples of path, object
<meoblast001> bialix: so, i could use fast-import and basically just tell it to chop these 2 files out off all the history?
<meoblast001> and then overwrite the repo in launchpad
<bialix> you can try, yes
<Peng_> Any preexisting repos would keep all of the revisions, actually increasing their size. :D
<meoblast001> i can try meaning i would have to hack around and try to get it to do something it's not meant to do?
<bialix> after fast-import processed your branch all old branches will be totally incompatible with new one
<meoblast001> what do you mean old branches?
<meoblast001> we only have 1 branch
<Peng_> All copies of it.
<meoblast001> oh, yes, that shouldn't be a big deal
<meoblast001> only like 3 people actually have pulled a copy of my project :P
<bialix> meoblast001: you have big files in revno 8 and 71
<bialix> maybe you need relax and live with them
<meoblast001> i do?
<meoblast001> what are those big files?
<bialix> your mp3 and ogg
<meoblast001> exactly
<bialix> mp3 committed in revno 8, then deleted in 71 and replaced with ogg
<bialix> rebase will rewrite entire history post revno 7
<meoblast001> yup, i want to chop both of those out completely, sure, it would break the examples, but it's not necessary we have those files
<bialix> so almost everything
<meoblast001> that would be bad, right?
<bialix> it depends
<bialix> fast-import will rewrite entire history
<bialix> rebase nost of history
<bialix> rebase most of history
<meoblast001> hm
<bialix> fast-import will be simpler
<meoblast001> i know someone who wrote a bzr to git script
<meoblast001> maybe i could use that?
<bialix> rebase will require manual work
<meoblast001> bzr to bzr
<bialix> you can
<bialix> git has filter feature
<bialix> to convert form bzr to git you anyway needs fast-import ;-)
<meoblast001> well, this would be bzr to bzr minus a few files
<bialix> converion bzr->git->bzr will destroy your history identity as well
<meoblast001> no
<meoblast001> not bzr->git->bzr
<meoblast001> just bzr->bzr_minus_some_files
<bialix> fast-import is bzr->anything
<meoblast001> rewriting everything but removing specific files
<bialix> yep
<meoblast001> fast-import can do that?
<bialix> fast-import is yhe answer
<bialix> fast-import is the answer
<bialix> install this plugin and read its docs, there is examples
<meoblast001> ok
<meoblast001> if i need help i'll ask you :P
<meoblast001> but first i will read the docs
<bialix> if you catch me ;-P
<bialix> time to sleep for me
<meoblast001> oh, good night
<meoblast001> "bzr fast-import clean.fi clean.bzr"
<meoblast001> what is ".bzr" and ".fi"
<bialix> fi is fast-import stream
<meoblast001> hm, is it a directory?
<bialix> no, fi it's the file
<meoblast001> should i just use this "bzr fast-import-filter -x missile-codes.txt > clean.fi"
<meoblast001> i don't know what "the file" is
<meoblast001> the file i want removed?
<bialix> fast-export command produce stream of your history in special format
<bialix> format called git-fast-import
<bialix> hence fi -- it's the stream saved on the disk
<bialix> fi = fast-import
<meoblast001> that doesn't sound good
<meoblast001> i just want it to remove the stuff from my bazaar repository
<bialix> you can use |
<meoblast001> |?
<bialix> bzr fast-export YOURBRANCH | bzr fast-import-filter -x mp3 | bzr fast-import NEWBRANCH
<bialix> something like that
<bialix> pipes?
<meoblast001> if i want the MP3 and the OGG out, do i just add a second "bzr fast-import-filter -x ogg?
<meoblast001> and "yourbranch" would be ./ if i'm cd'd into it?
<meoblast001> and newbranch would be the new directory?
<bialix> no, you can combine several -x options
<meoblast001> can i do *.mp3 and *.ogg?
<bialix> I don't remember exact details about NEWBRANCH
<bialix> meoblast001: I dunno
<bialix> try
<bialix> save the stream of original history to orig.fi file
<bialix> and then filter it
<meoblast001> i don't know where the ".fi" file is
<bialix> the size of this file will be hundred of MBs but it's all locally
<meoblast001> where is the file at?
<bialix> bzr fst-export YOURBRANCH > somefile.fi
<bialix> bzr fst-export YOURBRANCH > othernameyouwouldlike.xxx
<bialix> anything will work
<bialix> I mean "fast-export" above
<meoblast001> why am i importing the new branch
<meoblast001> and exporting the current branch?
<bialix> you export current branch, filter it and thus get new stream, then convert the stream to the branch
<bialix> fast-import working in the terms of "history stream"
<meoblast001> woah woah woah
<meoblast001> this is going to remove revisions with these files?
<bialix> no, filter out files from revisions
<meoblast001> ok
<meoblast001> the last part is giving me bzr: ERROR: [Errno 2] No such file or directory: u'new.fi'
<bialix> "woah"?
<meoblast001> i thought it was going to remove any revision that had to deal with that file
<bialix> what is the last part?
<meoblast001> bzr fast-import new.fi
<bialix> do you have new.fi file?
<meoblast001> no
<bialix> hence error
<meoblast001> should i just do  bzr fast-export YOURBRANCH | bzr fast-import-filter -x mp3 > file.fi?
<bialix> fast-import read the stream and re-create the branch
<bialix> yep
<meoblast001> bzr: broken pipe
<bialix> bzr fast-export YOURBRANCH > orig.fi
<meoblast001> why ?
<bialix> bzr fast-import-filter orig.fi -x mps > new.fi
<meoblast001> oh, ok
<bialix> I dunno why, are you on windows?
<meoblast001> no
<bialix> I dunno twice
<bialix> ah
<bialix> ahbzr fast-export YOURBRANCH | bzr fast-import-filter - -x mp3 > file.fi
<meoblast001> >.< it's printing to console
<bialix> you'd better look at examples for filter command
<meoblast001> i forgot to output it to a file >.<
<jelmer> ronny: for blobs and trees that should be the path they have  but it may also be None. It's used for finding optimal delta bases
<ronny> jelmer: ah, i see
<jelmer> ronny: you can without problems just use None as path everywhere
<ronny> jelmer: i kind of did that (using '' as path)
<meoblast001> bialix: how do i reexport this to a directory?
<ronny> jelmer: im currently extending anyvc commit building to more complex cases
<bialix> reexport?
<bialix> run fastexport again
<RenatoSilva> Why do I get this error? http://pastie.org/628005
<RenatoSilva> Is it bzr 1.18.1 bug?
<RenatoSilva> Or is it because of this line: email                C:\Arquivos de Programas\Bazaar\plugins\email [unknown]
<bialix> look at branch.conf
<RenatoSilva> I've committed two merges from personal bzr-email branches
<meoblast001> i'll take a look at it more later, thank you
<meoblast001> i've gtg
<bialix> RenatoSilva: try bzr --no-plugins info
<meoblast001> bye
<bialix> RenatoSilva: it seems you have wrong characters in branch.conf, have no idea why. Maybe disk failure?
 * bialix disappears
<RenatoSilva> bialix: oh, it's the "OlÃ¡", non-ascii is not supported there :(
<zsquareplusc> RenatoSilva: the error was with utf8. so i'd think its more than asci. but maybe the file was saved with the wrong encoding. did you edit it?
<RenatoSilva> zsquareplusc: ok let me try OlÃ¡ as utf-8, probably it was the encoding really
<rbelem> hello all, is there an way to delete an old revision? like my current revision is 756 and the revision that i want to remove is 746.
<zsquareplusc> rbelem: what do you expect to happen? edit the history?
<zsquareplusc> if you just want to "unapply" the changes of that revision, that's possible. you'll just end up with a new commit undoing the changes
<RenatoSilva> zsquareplusc: saved as utf-8 without bom and worked just fine, thanks :)
<rbelem> zsquareplusc, yes... :-) i want to remove that revision because now see that revision do not make sense
<RenatoSilva> lifeless: I was trying to understand what you said about rebase breaking pull and merge
<RenatoSilva> lifeless: you mean branches based on the rebased branch in the past, right?
<rbelem> zsquareplusc, but with unapply what with earlier revisions?
<rbelem> * happens
<RenatoSilva> lifeless: however I wasnt really thinking of rebasing trunk or branches that potentially could be branched
<zsquareplusc> rbelem: nothing. the old revisions are  kept as they are
<rbelem> zsquareplusc, oh! i got
<RenatoSilva> lifeless: the branch in question isn't really targeted for being branched, it's a personal branch targeted for merging into trunk
<rbelem> zsquareplusc, ok... so if i want to make that revision vanish i will have to create another branch and reapply patch by patch?
<kfogel> LarstiQ: https://code.edge.launchpad.net/~kfogel/bzr-hookless-email/byte-limit/+merge/11233 :-)
<RenatoSilva> lifeless: I don't think it's a good idea to rebase project branches either, but when your feature branch personal and you know that no one will branch it (you can put a warning in description), well, in this case I think rebase is a good option
<RenatoSilva_> lifeless: I don't think it's a good idea to rebase project branches either, but when your feature branch is personal and you know that no one will branch it (you can put a warning in description), well, in this case I think rebase is a good option
<RenatoSilva_> RenatoSilva_: another good reason for rebase is that the feature diff becomes clean, only one single diff between revision can tell you how code changes compared to trunk
<RenatoSilva_> lifeless: ^
<RenatoSilva_> lifeless: using updating merges it may be a bit hard as trunk may have changed since your work
<zsquareplusc> rbelem: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#reverse-cherrypicking
<lifeless> RenatoSilva_: bzr diff -r ancestor:../trunk - will tell you whats different in the branch easily as well
<jelmer> ronny: cool
<zsquareplusc> are the devs working on TortoiseBZR here?
<rbelem> zsquareplusc, i will test here
<rbelem> thanks :-)
<ronny> jelmer: with some luck i'll have a nice api for building and introspecting usefull commits on all important vcs's at the end of the week
<RenatoSilva> lifeless: sorry, being disconencted all the time
<RenatoSilva> lifeless: bzr diff -r ancestor:../trunk -, including the '-'?
<RenatoSilva> lifeless: well in my example here http://img33.yfrog.com/img33/5295/imagemxa.png,  rev. 18 in the former is rev.23 in the latter
<RenatoSilva> lifeless: I just have to diff -r 22..23 and I'll have the changes according to the latest code
<RenatoSilva> lifeless: for the former the same diff -r 17..18 is --outdated--
<RenatoSilva> lifeless: I'll have to go through the brach and look at all merges from trunk till the end, to get a view on the updated change
<RenatoSilva> lifeless: by elimitating update-only merges, I make the feature diff more natural
<RenatoSilva> lifeless: unfortunately I don't have the diffs now but in that example what happened was that...
<RenatoSilva> lifeless: I had pt-br_solenoid.Theme.po in branch root, then I created the feature branch and modified this file
<RenatoSilva> lifeless: in the meantime, the file was moved in trunk to a subfolder /translation, and was renamed to pt_BR.po
<RenatoSilva> lifeless: using update merges, the rev that implements the feature is now outdated because it relates to old /pt-br_solenoid.Theme.po
<johnf> abentley: you about?
<RenatoSilva> lifeless: that diff is not enougth to know how the feature changes the code, you have to also look at the specific merge feature --> trunk where the conflict occurs and is solved
<lifeless> RenatoSilva: that why you use 'diff -r ancestor:../trunk', not 'dff -r 17..18'
<Peng_> RenatoSilva: Just out of curiosity, what's up with your connection?
<mwhudson> hmm
<mwhudson> bzr log -r $revno:$branch
<mwhudson> shows $revno in the context of $branch in the output
<mwhudson> not $revno in the context of .
<RenatoSilva> lifeless: (i.e  pt-br_solenoid.Theme.THIS and pt-br_solenoid.Theme.BASE, then you move THIS to /translations/pt_BR.po and bzr resolve --all and merge)
<mwhudson> that wasn't what i was expecting
<RenatoSilva> lifeless: sorry I will read your answer now
<RenatoSilva> Peng_: I don't know what's up with my conn :9
<RenatoSilva> lifeless: literally as you typed? is it possible in ui?
<RenatoSilva> lifeless: I'll try diff -r ancestor:../trunk at home anyway
<RenatoSilva> mwhudson: so bzr log -r $revno:$branch? how would that be in my example?
<lifeless> RenatoSilva: mwhudson is talking about something completely different
<RenatoSilva> ok sorry then
<mwhudson> RenatoSilva: yeah, sorry for dropping in with something that looked similar but is in fact entirely different
<RenatoSilva> lifeless: diff -r ancestor:../trunk, s/ancestion/feature-branch's name, right?
<lifeless> s/..\/trunk/path_to_trunk
<RenatoSilva> lifeless: I'm sorry can't grok that command atm
<lifeless> cd $feature_branch
<lifeless> bzr diff -r ancestor:$trunk_url
<RenatoSilva> lifeless: trunk is lp:moin-solenoid
<RenatoSilva> lifeless: and feature branch is ~/moin-solenoid/userprefs
<RenatoSilva> lifeless: so bzr branch [...]userprefs, cd userprefs, bzr diff -r ancestor:lp:moin-solenoid right
<lifeless> yes
<RenatoSilva> ok
<RenatoSilva> lifeless: I'll check later if I'll get the same diff as with rebase, thanks!
<RenatoSilva> is .bzr's branch.conf pushed to lp too?
<RenatoSilva> I'm worried about some bzr-email confs I don't want to share
<zsquareplusc> the one in your home direcotry, not
<zsquareplusc> you can have a branch specific config in the .bzr folder i guess that one is pushed
<fullermd> No, it's not.
<zsquareplusc> ok
<RenatoSilva> ok thanks!
<milli> Here's a potentially stupid and probably inflammatory question that Google hasn't been able to help me with...  I have a Client (customer) that has decided to move to bzr for source control from git (long story omitted about git's UI being "too hard" to use).  What repository format will get me closest to the performance of git?  --2a?  --1.9-rich-root ?  --1.14-rich-root?  I.e., what is the fastest repo format given half a dozen developers using a semi-de
<milli> centralized approach with some folks using a sandbox (git-like) workflow and others using a subversion-like workflow?
<zsquareplusc> what's the point of holding in in the braches .bzr directory then?
<thumper> milli: 2a
<fullermd> milli: What thumper said, assuming everyone's on a new enough (2.0.0 ideally, 1.18 OK) version.
<milli> thumper: that's it?  Hands down it's the fastest?  No caveats?
<fullermd> 2a is supported since 1.16 (I think offhand), but it's a little rough early on.
<thumper> milli: I'd say yes
<milli> I saw the 2.0.0 just hit Karmic...
<milli> that
<milli> ok
<RenatoSilva> Ursinha: ^
<lifeless> milli: 2a fixes a number of big-O scaling problems with older formats. Its got lets; we know of a handful of minor regressions, and they won't require format changes to fix.
<lifeless> milli: with bzr 2.0.0 you should have fine performance; if you don't _please_ file a bug and we can figure out why
<milli> lifeless: nod
<lifeless> s/lets/legs/
<poolie> hi there
<lifeless> hai
<poolie> lifeless: i put up the uifactory tests
<poolie> for review
<poolie> however lp is readonly atm
<lifeless> yah
 * fullermd read that as "olfactory tests"...
<poolie> mm
<poolie> i'd like to do some import tariff tests soon :)
<poolie> blah
<poolie> i guess it's better than being offline entirely
<fullermd> I figured that meant "tests to tell you if your code stinks".
#bzr 2009-09-24
<m3ga> on karmic, have bzr 1.18-0ubuntu1 and python-paramiko 1.7.4-0.1 installed, trying to pull from sftp url and getting "Unable to import paramiko (required for sftp support): No module named paramiko". Clues?
<m3ga> hmm, did "apt-get install --reinstall python-paramiko" and that fixed it. weird!
<Peng_> Wasn't there a plan to quiet all of the muttering in groupcompress's _trim_block and _rebuild_block?
<Peng_> "creating new compressed block on-the-fly in 0.177s 618357 bytes => 293599 bytes" and all.
<jelmer> "bzr branch hg.hg hg.bzr" now works and takes less than 5 minutes :-)
<jelmer> it still needs more work (corner cases, tests, memory usage improvements) but the basis is there
<Peng_> hg -> bzr? Wow.
<jelmer> Peng_: yep. It's a local conversion though, not sure what it would take to clone a remote hg repo
<Peng_> Does it use the Mercurial Python library or what?
<jelmer> Peng_: Yeah
<Peng_> Very cool. :)
<Peng_> Is it read-only?
<lifeless> Peng_: we had it 3 years back, but it bitrotted :)
<lifeless> jelmer: I'm very glad you've cleaned it up and made it work well
<hoelzro> hello bzr devs and users, I'm trying to do the following: 'bzr branch lp:gwibber' and I get a strange error
<hoelzro> bzr: ERROR: Invalid url supplied to transport: "lp:gwibber": OOPS-1362ED11069
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1362ED11069
<lifeless> launchpad is in maintenance at the moment
<lifeless> thumper: ^ bugworthy?
<hoelzro> ubottu: auth required =(
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<hoelzro> lifeless: I noticed, but the repos are read only, so it should work, right?
<zsquareplusc> the lp: shortcut uses the smart server, i guess it would work if you use a http: url manually
<zsquareplusc> at least that's what i observed last time i had problems being behind a proxy and firewall
<lifeless> zsquareplusc: thats not really connected to this issue
<jelmer> peng_: yeah, it's read-only for now
<lifeless> hoelzro: yes it should work
<mwhudson> lifeless: the lp-resolution problem is already reported
<zsquareplusc> lifeless: my idea was that http should work as it's guaranteed read only. "lp:" doesn't use http i think
<mwhudson> (reported by me, just after the last rollout)
<lifeless> zsquareplusc: lp: will use http if you're not logged in, and http still does db access
<lifeless> zsquareplusc: all of launchpad *should* work in readonly mode, with write *attempts* failing. branching isn't a write attempt.
<wgrant> But codehosting is entirely down during read-only mode ATM.
<thumper> lifeless: LP is in readonly
<thumper> lifeless: we need better errors
<thumper> lifeless: so yes, bug worthy
<poolie> igc: did you see ej around at all?
<igc> morning
<igc> poolie: I didn't
<GPHemsley> I upgraded to 1.18 from 1.14 and I got this error when I ran `bzr version`: "Key 'foreign-mapping-upgrade' already registered"
<GPHemsley> Unable to load plugin 'rebase' from '/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/bzrlib/plugins'
<lifeless> you need to upgrade your plugins too
<GPHemsley> I thought I did
<GPHemsley> lifeless: Doesn't the installer do that?
<GPHemsley> (Mac OS X 10.4)
<meoblast001> hi again
<meoblast001> if you use fast-import to filter a directory out, does it work on all files within it?
<GPHemsley> hmm... unusually quiet tonight...
<meoblast001> hm
<lifeless> GPHemsley: only the plugins it included; you may have installed others
<lifeless> GPHemsley: also I think there was a bug in the 1.18 installer or something, now that I think about it
<GPHemsley> meh
<GPHemsley> I seem to recall that being the case a couple of version ago, too :(
<GPHemsley> actually, yeah, this problem was causing trouble the last time I was here
<GPHemsley> when I was trying to get svn-bzr (or bzr-svn, I forget) to work
<lifeless> your bzr.log should show the path to the failin import
<GPHemsley> lifeless: http://gphemsley.pastebin.com/d20033a0a
<lifeless> GPHemsley: it does look like an old rebase to me
<GPHemsley> lifeless: It's 0.5.4, from what I can gather
<GPHemsley> oh
<GPHemsley> hmm
<GPHemsley> bzr_plugin_version = (0, 5, 4, 'dev', 0)
<GPHemsley> bzr_compatible_versions = [(1, 14, 0), (1, 15, 0), (1, 16, 0), (1, 17, 0)]
<GPHemsley> I may have compiled this myself when I was having the problem with svn
<GPHemsley> lifeless: WCS, how do I uninstall these plugins?
<poolie> igc, i'll try to set up the site somewhere on orcadas this afternoon
<lifeless> GPHemsley: delete the directory
<RenatoSilva> lifeless: hi, it seems that the diff generated by bzr diff -r ancestor:lp:moin-solenoid on the update-merged branch is exactly the same for -r 22..23 on rebased one :)
<GPHemsley> oh, that simple?
<lifeless> GPHemsley: yes, plugins are discovered bywalking the directory layout on disk
<RenatoSilva> lifeless: but the problem is: how to make that diff --after merging with trunk-- :(
<RenatoSilva> lifeless: in the rebased branch, the diff can be extracted from the trunk, even after deleting the feature branch
<RenatoSilva> lifeless: unsing branch diff, I need to keep all feature branches forever even after merging them into trunk
<RenatoSilva> Is there a way to run a bzr diff -r ancestor:$trunk *after merging into trunk*? that is, some command on trunk that will result in the same diff
<meoblast001> ok, i successfully removed the contents of my examples/ directory from every revision of my project with the fast-import, but how do i actually remove the directory?
<meoblast001> >.< scratch that, i still have a 10 MB .pack file
<RenatoSilva> sorry if I'm being unclear, am I?
<meoblast001> hm, seems like everything is smaller though
<lifeless> RenatoSilva: it can without rebase too
<lifeless> RenatoSilva: diff -c -1
<meoblast001> i did this bzr fast-import-filter ame.fi -x examples/ > amethyst-mm/new.fi
<meoblast001> should i do bzr fast-import-filter ame.fi -x examples/ -x examples > amethyst-mm/new.fi
<GPHemsley> Is there a way to edit the information of a commit after it's already been committed?
<GPHemsley> specifically, the committer info
<GPHemsley> (`bzr whoami`)
<meoblast001> you can reroll the whole repository, but i think that's overkill
<igc> poolie: that would be great. I need to head off around 3pm for a medical appointment but I should be back later
<lifeless> GPHemsley: imediatelt after you can use uncommit + commit
 * igc lunch
<RenatoSilva> lifeless: oh! it's just a single diff command :)
<GPHemsley> excellent, thanks, lifeless
<RenatoSilva> lifeless: bzr diff -r 22..23, bzr knows here that 22 is a merge and switch to a branch diff, right
<RenatoSilva> lifeless: I'll try to understand it later, what matters atm is that it just works :)
<RenatoSilva> but because of the clearer history, it still seems to me that rebasing is a good option for "unbranchable" branches :)
<meoblast001> ugh :/
<meoblast001> how do you filter out a directory with fast-export
<lifeless> meoblast001: I don't know; I'm not answering because I don't know.
<lifeless> meoblast001: if the docs don't tell you, file a bug about that; then ask a question on the project :)
<meoblast001> i read the help page
<meoblast001> lifeless: i honestly don't know if i'm understanding the docs
<idnar> I also couldn't figure that out the other day, so I'd go ahead and file the bug
<lifeless> meoblast001: if you can't understand it, it needs to be clearer :)
<SamB> if you can't TELL, they still need to be clearer ;-P
<meoblast001> i'm not sure if it's actually addressing the point i'm wondering about, or not
<meoblast001> i don't think it is though
<meoblast001> i think it's just saying you need a trailing slash on directories (which i did)
<lifeless> again, you're not sure. So its a bug.
<lifeless> please file it? Pretty please?
<meoblast001> lifeless: i have to double check things before i file a bug, so i'll reread it again to make sure i didn't just have a "brain fart"
<lifeless> meoblast001: we like bugs.
<meoblast001> ok, i checked it over, i understand it
<lifeless> meoblast001: the fact that you can have a brain fart is usually a sign of something we can improve. Please share these opportunities with us!
<SamB> meoblast001: well, file one anyway
<meoblast001> but i think the problem is that it's not deleting the directory
<meoblast001> only the contents of the directory
<meoblast001> lifeless: if i file a bug we'll hit 4294967296 bugs
<meoblast001> and we all know what happens then
<RenatoSilva> meoblast001: there's another line of thinking where you just file a bug, even if it is invalid. In lp it can be converted to a question/answer. The point here is have a documentation of the issue itself, so that other people can find iformation about the same problem
<RenatoSilva> meoblast001: for example you file a bug because you want Ubuntu blue. Then it's marked as won't fix. When other people go file the same bug, they'll find that bug and know that it won't be implemented. They can comment and ask please please. Maybe if millions of people do that Ubuntu could become blue someday :)
<meoblast001> RenatoSilva: i want Ubuntu to be blue to be honest
<meoblast001> ouch, my eyes
<RenatoSilva> meoblast001: well, me too :)
<meoblast001> i want to switch to gNewSense sort of, it's a stripped down Ubuntu
<meoblast001> i wonder if Canonical would ever make gNewSense official :)
<meoblast001> they would need permission from it's creators (one of which i know on IRC)
<lifeless> I'm pretty sure we'd be delighted to be able to stop shipping firmware etc, but its very bad for users to do that at the moment.
<meoblast001> bad for users to do?
<meoblast001> someone on Ubuntu brainstorm thinks i'm RMS :P
 * RenatoSilva don't want Ubuntu blue, maybe
<RenatoSilva> is there any way to ignore spaces / tabs /line-break style on bzr diff?
<lifeless> meoblast001: users being unable to use their own hardware
<lifeless> RenatoSilva: content filters can do it; you need to be using 2.0.0
<meoblast001> ah yes
<meoblast001> i recently had to use a firmware (i switched from NVIDIA to ATI)
<meoblast001> at least my drivers are freed now :)
<RenatoSilva> lifeless:   I'm worried about plugin compatibility like bzr-xmloutput and bzr-email
<RenatoSilva> lifeless: I wonder whether UNIX diff command can do that too, it should I think
<RenatoSilva> lifeless: if you just s/\r\n/\n, diff will think yo've replaced the file completely, when in fact it is semantically equal
<lifeless> only for some languages
<lifeless> other languages consider them semantically different
<lifeless> [many of which are 'binary']
<RenatoSilva> because of style of line breaks ? o.O
<meoblast001> this is so strange
<RenatoSilva> well a diff ignoring \s and kind of \n wouldn't be a real diff, e.g. for patching, it's just a nice view of the diff for the user
<meoblast001> my examples/ directory still exists :/, i wonder if specifying "examples/./" would help?
<lifeless> meoblast001: filed the bug ?
<meoblast001> i'm not sure if it's a bug though
<poolie> lifeless: you asked before 'did i commit a conflict' and i didn't mean to commit a conflict
<poolie> and now i see spiv has also got conflict markers in his cleanups mp
<poolie> so i suspect a bug in lp
<poolie> thumper: ^^
<mwhudson> poolie: merge proposal diffs are merge --preview style diffs now
<mwhudson> poolie: so conflicts are possible
<spiv> Huh.
<meoblast001> lifeless: so you want me to file a bug?
<lifeless> yes!
<meoblast001> even if it might not be one
<meoblast001> on bazaar?
<meoblast001> i should probably do it on this plugin
<lifeless> mwhudson: thumper: will they update now?
<lifeless> meoblast001: bug reports are a sign that something might be wrong, not a statement.
<mwhudson> lifeless: yes
<lifeless> meoblast001: and yes, on the plugin please.
<lifeless> mwhudson: _THANKS_
<mwhudson> lifeless: thank abentley, i had nothing to do with it!
<lifeless> it was to the team :)
<lifeless> abentley: thanks
<meoblast001> lifeless: is this related https://bugs.launchpad.net/bzr-fastimport/+bug/410140
<ubottu> Launchpad bug 410140 in bzr-fastimport "pruning of empty directories" [Medium,Fix committed]
<meoblast001> it looks like a similar problem
<meoblast001> it appears from that bug that it should be fixed
<meoblast001> but i'm not seeing it here, and this is a fresh checkout
<thumper> lifeless: the script isn't running
<thumper> lifeless: but it should soon
<thumper> lifeless: the losas have been busy
<lifeless> thumper: naturally
<meoblast001> lifeless: https://bugs.launchpad.net/bzr-fastimport/+bug/435621 happy now? :P
<ubottu> Launchpad bug 435621 in bzr-fastimport "Specifying Directories to Filter only Deletes Subdirectories/Files, Not the Directory Itself" [Undecided,New]
<lifeless> meoblast001: thank you
<meoblast001> :)
<meoblast001> lifeless: i was just kidding, you're the one who helped m
<meoblast001> me*
<meoblast001> my only problem is that i planned to fix this by tonight >.<
<RenatoSilva> what's a submit branch in zbr info?
<RenatoSilva> *bzr
<spiv> RenatoSilva: the default branch used by "bzr send", any maybe other things.
<RenatoSilva> ok thanks
<spiv> I sometimes use "bzr diff -r submit:" in my feature branches to see what I've changed vs. that branch (which is usually lp:bzr, for me).
<RenatoSilva> isn't it bzr diff -r ancestor:$trunk?
<spiv> Yes, that's often the same.
<spiv> or rather, if $trunk in your example is the submit branch, then it's exactly the same.
<spiv> But "submit:" is shorter to type :)
<RenatoSilva> true, gotta write it down somewhere :)
<meoblast001> lifeless: i fixed it now :/
<meoblast001> so the bug report was useless
 * RenatoSilva doesn't like bugs that much either
<RenatoSilva> how to find revisions that fixed certain bug (committed with --fixes=)
<RenatoSilva> can't find anything in bzr help diff
<RenatoSilva> *log
<meoblast001> sleep time, good night
<lifeless> vila: nice
<vila> lifeless: ?
<igc> bbl
<poolie> hi vila
<vila> poolie: not really there yet :-) I'll say 'hi' then...
<poolie> ok :)
<poolie> reading your new shell-like diff now
<jtv> What's the proper way to get a revision's timestamp into a datetime?
<jtv> (I should say timestamp plus timezone)
<Peng_> Oh god. Just thinking about that makes my brain shut down.
<jtv> Peng_: I take it that's a "no" on an easy solution?
<lifeless> ugh, where has the day gone
<lifeless> jtv: it is one ?
<jtv> lifeless: it's gone over here, to the west of you
<Peng_> jtv: That's my standard reaction to mention of datetime.
<jtv> lifeless: that's what I thought, but when I try to subtract a timedelta, I get an error saying the timestamp was a float.
<Peng_> There shouldn't be anything bzr-specific about converting timestamp + tzoffset into a datetime.
<Peng_> Unless bzr has a nice API for it or something.
<jtv> Peng_: the timezone offset doesn't seem to be the one that datetime.fromtimestamp expects.
<lifeless> jtv: pydoc bzrlib.osutils
<Peng_> datetime.fromtimestamp can take timezone offsets?
<jtv> Peng_: yup
<lifeless> jtv: has bits in there.
<jtv> lifeless: they all seem to involve turning it into text and then parsing that text though
<jtv> seems brittle
<lifeless> jtv: well, I"m not saying there is exactly what you need
<lifeless> just that you should find the closest function, and then refactor it;)
<jtv> I think I can use datetime.utcfromtimestamp
<jtv> but then should I add the timezone to the timestamp, or subtract it?
<jtv> Hmm... contrary to reason it also seems to produce a timezone-naÃ¯ve datetime.
<lifeless> the python datetime module?
<vila> hi all
<lifeless> you need to subclass tzinfo
<jtv> lifeless: yes
<jtv> !?
<lifeless> have I mentioned I hate that module?
<lifeless> have a look at subunit.iso8601
<lifeless> or if its bundled on your system is8601
<jtv> lifeless: you haven't mentioned it to me yet, but I'll have you know it wouldn't shock me
<jtv> what is subunit?
 * vila takes a deep breath and restart yet another build failing on a time related issue...
<lifeless> its a testing protocol library I develop
<lifeless> its relevance here is simply that iso8601 is an MIT licenced module I embedded
<vila> . o 0 ( The common cause between all of them seems to be..... using a virtual host.... )
<jtv> lifeless: I have an iso8601.py lying around.
<lifeless> look for Yoinked
<jtv> lifeless: nope
<jtv> not found
<lifeless> class Utc(tzinfo)
<jtv> lifeless: got it on google
<jtv> okayyyy... what's wrong with regular UTC?
<jtv> datetime.fromtimestamp(revision.timestamp + revision.timezone, UTC) does complete successfully...  the + is a guess though.
<lifeless> jtv: where is UTC defined? its not in the datetime module ...
<jtv> lifeless: pytz
<lifeless> ah
<lifeless> not in the stdlib :)
<poolie> vila, shell-like-ears +1
<poolie> also http://www.phrases.org.uk/meanings/414550.html
<vila> poolie: wow :D A bit of explanation may be ? Should I continue or should I stop using "shell-like" ?
<poolie> continue :)
<poolie> it's a nice name
<lifeless> jtv: timezones
<vila> Can it be interpreted as "we listen to you: we help you write tests" ? :D
<jtv> lifeless: ?
<lifeless> jtv: the offset is the offset of the time when it was recorded; so if it was recorded at +3600, you would subtract 3600 to get UTC
<lifeless> however, what you probably want
<lifeless> is fromtimestamp(timestamp, magic_tzinfo(offset)),
<jtv> magic_tzinfo?
<lifeless> you get to write that
<lifeless> a factory to get the right thing from pytz, or curry a class on the fly
<lifeless> datetime is _not_ a good example of easy to use API
<vila> poolie: that's the kind of surprise I love after using a word (shell here) for more than 20 years without realizing some of its other meanings
<jtv> lifeless: seems overkill...  I don't give a rat's kidneys about the timezoneâall I want is the UTC time.
 * jtv fondly reminisces the lady who tried to get "the real time" from a stewardess on a transcontinental flight...
<jtv> (The continent in question being Eurasia)
<jtv> "Yes but what time is it on the plane?"
 * vila giggles about the TRUE things (time is a funny example of that, but many people also have strong views about pasta, chocolate, ice cream, you name it ;)
<jtv> vila: don't get me started about True Internet, basically the only alternative to state-run internet here...
<vila> jtv: hehe
<LarstiQ> kfogel: ah! I'm going to look at your merge proposal today (after all my lectures are over in ~9 hours). Sorry it took so long
<ronny> jelmer: whats the purpose of subvertpy.NODE_NONE/NODE_UNKNOWN
<ronny> jelmer: oh, and RemoteAccess.check_path doesnt normalize leading '/'
<igc> back
<jtv1> lifeless: printf debugging tells me that the timestamp in a revision is already in UTC, so I can ignore the timezone.  Just datetime.fromtimestamp(revision.timestamp, pytz.UTC) does the trick.
<lifeless> jtv1: hmm, I'll have to check the source to be sure.
<lifeless> time to learn more RDF
<jtv1> lifeless: I commit to a branch, then I look up the revision and run its timestamp through that, and it gives me (roughly) the current UTC time.
<johnf> Can anyone besides abently do a bzrtools release?
<johnf> jelmer: will you be doing a bzr-svn 1.0 release before tomorrow?
<poolie> hi johnf!
<johnf> poolie: howdy
<bialix> hello bzr
<poolie> johnf: i don't think anyone but abentley regularly _does_ releases
<poolie> this is a drawback of having them version-locked and recommended by the package...
<johnf> yeah
<johnf> bzrtool 2.0.0 is released
<johnf> but it expects bzr to be version 2.0 not 2.0.0
<johnf> I'll just fix it manually for now in the PPA
<poolie> good idea
<jelmer> johnf: no, I doubt I will have time for that.
<johnf> I'd love to move to a process where when bzr goes rc1 all the plugins aim to do a final release or something. Trying to keep plugins in synx seems to be the most difficult task
<johnf> jelmer: no probs I'll just use the rc
<jelmer> johnf: there's still a couple of test failures that have to be fixed before a final release
<johnf> jelmer: Are they major enough to not copy it to ~bzr PPA?
<jelmer> johnf: no
 * bialix shocked by new LP UI
<bialix> they killed Kenny!
<thumper> bialix: you don't like it?
<bialix> mmm, not really
<bialix> I'm very conservative perhaps
<bialix> and used to old UI
<bialix> this new UI is TOO radical change for me
<bialix> but my first reaction was not positive, sorry
<bialix> although big green button for release downloads is definitely cool
<bialix> never mind me
<Peng_> Is it...chartreuse?
 * igc dinner
<garyvdm> Hi all
<garyvdm> Please will someone take a look at https://code.edge.launchpad.net/~garyvdm/bzr/get_trees_and_branches_to_diff/+merge/12077 </nag>
<Peng_> garyvdm: There's no newline at the end of test_diff.py. :P
<garyvdm> Peng_: Ok - I'll fix that.
<Peng_> I don't have the knowledge to do real reviews, but I figure my nitpicking makes things a little cleaner, and saves someone else from having to think about it...
<Peng_> Thus Peng_ explains the justification for his existence.
<Peng_> I should've gone with "In which Peng_ attempts to justify his existence." instead.
<AfC> Peng_ is clearly attempting to pass the Turing test.
<garyvdm> Superseded request: https://code.edge.launchpad.net/~garyvdm/bzr/get_trees_and_branches_to_diff/+merge/12341
<strk> error: must supply either home or prefix/exec-prefix -- not both
<strk> ^^^ following instructions in the INSTALL file
<strk> being: python setup.py install --home ~
<strk> bzr-2.0rc2
<strk> Python 2.6
<Peng_> strk: That's exactly the command line you ran?
<strk> python setup.py install --home $HOME
<strk> python setup.py install --home ~
<strk> tried both..
<strk> same error
<Peng_> .....Huh.
<garyvdm> strk: I think what you want is python setup.py install --home
<bialix> hi garyvdm
<garyvdm> Hi Alex
<bialix> can you refresh my memory: why qbzr needs branches for diff?
<strk> error: option --home requires argument
<strk> garyvdm: ^^
<strk> for: python setup.py install --home
<garyvdm> To get the revno for the revisions to display in the title, and if the branches are different, it also show the locations of the branches.
<garyvdm> strk: sorry - I don't know then.
<bialix> garyvdm: ok, understood
 * garyvdm -> lunch
 * bialix too
<Peng_> Does installing other Python apps work?
<strk> haven't tried
<strk> lemme try paramiko...
<strk> alright, same error with that command line for paramiko
<strk> using --prefix instead of --home seems to work fine for bzr
<strk> worth noticing in the INSTALL file
<asabil> hi all
<asabil> I have a small query concerning qbzr
<asabil> maybe qbzr log should sort revisions based on the commit timestamp when there is a tie about what to show
<asabil> I have got multiple release branches that represent the release series, and that are not merged in the mainline and will never be
<asabil> qlog shows the release branches at the top of the graph even if the commit is 2 months old
<johnf> jelmer: what should I be branching off to create debian packages of bzr-svn?   http://bzr.debian.org/pkg-bazaar/bzr-svn/unstable
<garyvdm> asabil: https://bugs.launchpad.net/qbzr/+bug/321389
<ubottu> Launchpad bug 321389 in qbzr "bzr visualise: sort by date" [Low,Confirmed]
<asabil> garyvdm: ah thanks, didn't see that one
<jelmer> johnf: yeah
<jelmer> johnf: I've just released 1.0 btw
<lifeless> johnf: theres a new loom release too :)
<johnf> jelmer: Also I finally got back my DD status today. So when you have a moment would like to talk about the bzr-pkg team and how to start helping out
 * lifeless shoves work johnf's way
<lifeless> johnf: package shit & up load it ;) ?
<johnf> lifeless: I'm in total package mode and aim to keep working through plugins till midnight :) Feel free to prioritise. bzr-svn is at the top of the list
<lifeless> johnf: loom isn't high, but would be nice to have; it breaks switch -b rather badly using the packaged version :)
<jelmer> johnf: bzr-loom in debian needs some work in particular
<lifeless> jelmer: what does it need?
<jelmer> lifeless: somebody to keep an eye on it mainly
<johnf> Although I fell I'm about to be sidetracked by continuing jelmer's work from a year ago and making autoppa use builddeb
<jelmer> lifeless: and I think you have an open bug about it being out of date
<jelmer> johnf: I've also orphaned trac-bzr earlier, you might want to pick it up if it interests you.
<james_w> yay johnf
<garyvdm> johnf: I would like to get qbzr in to debian. I got to run now, so I'll send you a mail...
<Lo-lan-do> johnf: I'm half inclined to start a bzr-miscplugins package.
<Lo-lan-do> I'd shove bookmarks and extcommand into there.
<lifeless> jelmer: its out of date cause it hasn't been updated ;P
<lifeless> What I'd like to do is plugin-info -> debian/control
<lifeless> and bzr-log -> debian/changelog
<lifeless> possibly wants doap rather than plugin-info
<jelmer> lifeless: we did a simple script that does the first bit (plugin-info -> debian/control) at debconf
<jelmer> lifeless: basically will update dependencies on bzr based on info in plugin-info
<lifeless> jelmer: cool
<lifeless> jelmer: have you seen moap?
<jelmer> lifeless: yes
<jelmer> lifeless: I mentioned it in my reply to you about doap
<garyvdm> Bye all.
<lifeless> jelmer: oh hmm, must have dropped that mail somewhere
<lifeless> I spent this avo looking at rdf tools; rather a sad landscape after so many years
<jelmer> lifeless: indeed
<jelmer> lifeless: I can forward that email again if you can't find it. It contains some complaints about moap :-)
<lifeless> please
<lifeless> ah found it
<lifeless> you did a pile of bug noise after it
<lifeless> I'm crashingish, too tired to reason well
<OllieR> How do you find out what version a checkout is on?
<IslandUsurper> bzr revno
<OllieR> thats tells you the latest revno of the tree not what the local checkout is updated to...
<fullermd> The branch, not the tree.  revno --tree tells yo uabout the working tree.
<jelmer> hmm, could it be that 2.0rc2 isn't tagged yet?
<OllieR> fullermd: ty :)
<OllieR> IslandUsurper: thank you (should of looked up its parameters)
<OllieR> is it possible to update just one file in bzr like you can in svn?
<bialix> ÑÑ
<bialix> no
<kfogel> LarstiQ: cool
<OllieR> isn't that a major drawback to bzr?
<kfogel> OllieR: not really.  You could always just duplicate the branch (cheap, in a shared repository), update the copy, and use that version of the file.
<IslandUsurper> I don't think so. About the only time files are truly independent of each other are when they are binary files, and Bazaar doesn't handle those very well anyway
<IslandUsurper> it's better to think of revisions as snapshots of the whole project, not separate snapshots of each file
<OllieR> kfogel: interesting book :)
<kfogel> IslandUsurper: (how does Bazaar not handle binary files well?  just curious)
<kfogel> OllieR: thank you :-).
<IslandUsurper> kfogel, if they're changed a lot, the changes don't pack very efficiently, so it slows bzr down
<kfogel> IslandUsurper: ah, gotcha.
<james_w> IslandUsurper: I don't think that's the case
<james_w> not any more at leat
<IslandUsurper> james_w, oh, well that's good to hear
<james_w> though if you are storing random data it's not going to compress different versions very well
<james_w> and I wouldn't expect too much extra compression on changes to files that are themselves compressed
<IslandUsurper> I'm just going off hearsay, anyway
<james_w> in the past bzr only did line based storage, so depending on the data that might not work very well at all
<jblount> Hi! How do I tell bzr that the branch I'm merging in should have preference over my existing branch?
<james_w> if there were zero \n bytes in the file the storage would be one line that changed completely every time
<james_w> that obviously doesn't work too well
<james_w> jblount: hey, preference in what way?
<jblount> Something like: bzr merge lp:~someguy/project/some-work --please-use-these-changes-not-my-branch
<james_w> pull?
<jblount> james_w: the branch I'm merging wins over the existing branch.
<james_w> you want to resolve all conflicts in favour of OTHER?
<james_w> or you just want to use everything in that branch?
<jblount> james_w: resolve conflicts in favour of OTHER (I think)
<james_w> ok
<james_w> there's no clean way to do that currently unfortunately
<james_w> you're stuck with "bzr merge" and then fix up afterwards
<kfogel> james_w: :-(
<james_w> for i in $(bzr conflicts --text); do mv $i.OTHER $i; done; bzr resolve
<james_w> that will get you most of them
<james_w> bzr conflicts will then list the tricky ones
<jblount> james_w: I'll try that. Thanks for the clarity :)
<james_w> and I can't come up with a shell fragment to fix them up off the top of my head
<james_w> jblount: please file a bug though, this would be something that would be useful to have
<jblount> james_w: Will do!
<kfogel> james_w: https://bugs.edge.launchpad.net/bzr/+bug/257297
<ubottu> Launchpad bug 257297 in bzr "Add option to resolve to either THIS or OTHER" [Low,Confirmed]
<kfogel> james_w: https://bugs.edge.launchpad.net/bzr/+bug/232512
<ubottu> Launchpad bug 232512 in bzr "Command line tool for resolving all conflicts in favor of 'merge-source'" [Wishlist,Confirmed]
<kfogel> james_w: I think one of those might be a dup of the other
<james_w> aha
<kfogel> james_w: on phone, so can't look further right now
<james_w> thanks kfogel
<james_w> and hi :-)
<kfogel> james_w: np, and hi! :-)
<jblount> kfogel: Thanks!
<james_w> kfogel: are you in London at the moment/soon?
<james_w> jblount: ooh
<james_w> check Aaron's comment in bug 232512
<ubottu> Launchpad bug 232512 in bzr "Command line tool for resolving all conflicts in favor of 'merge-source'" [Wishlist,Confirmed] https://launchpad.net/bugs/232512
<kfogel> jblount: my personal goal is to organize the world's information and make it universa... Oh, wait.
<kfogel> james_w: no, in NY, but in London next week.
<james_w> kfogel: cool, might catch you then
<kfogel> james_w: +1  you know about the launchpad meetup monday, right?
<jblount> kfogel: I'll sadly miss the LP meetup next week, but hanging out with beuno and crew this week in Millbank.
<james_w> kfogel: I do, I don't know if I'll still be in London then though
<kfogel> jblount: ah dang, but cool you're in Millbank now.
<kfogel> james_w: hope you can make it!
<bialix> thumper: I think I can articulate why new UI is shocked: absence of lines, borders around buttons, too much white background in which letters fly as in outer space.
<jelmer> lifeless: any chance you could have a look at https://code.edge.launchpad.net/~jelmer/pqm/merge/+merge/6122 ?
<kfogel> LarstiQ: eventually I will run https://code.edge.launchpad.net/~kfogel/bzr-hookless-email/byte-limit/+merge/11233 through a lolcatz filter.  Don't say I didn't warn you :-).
<LarstiQ> kfogel: euh :)
<sque> I am not sure if this is the right place to ask. But can someone please explain me what (loggerhead's) serve-branch --user-dir exactly does? This thing comes with no ducemantation at all.
<beuno> sque,
<beuno>   --user-dirs           Serve user directories as ~user
<beuno> ./serve-branches --help?
<sque> beuno, have you used it?
<sque> beuno, If you set this arguments it demands to set --trunk-dir too. What should I do there?
<sque> beuno, I tried various configurations but didn't managed to do http://loggerhead-server/~sque and work
<sque> beuno, bbl in 10 minutes.
<sque> I hope you have a clue for me to solve this puzzle :)
<davidstrauss> I can't help but notice that Bazaar 2.0 is recommended from the Launchpad blog but not actually released yet.
<jam> davidstrauss: the code is cut, the official announcement hasn't happened because we haven't built all the installers yet
<davidstrauss> jam: Since when did installers hold back a release? ;-)
<jam> davidstrauss: for 1.18 and 2.0 and onwards
<davidstrauss> ah
<jam> we now have a "gone gold"
<jam> separate from "officially released, come get some"
<davidstrauss> jam: 1.18 still lacks an os x 10.5 installer
<jam> I'm a bit surprised that launchpad blog would announce it before we do...
<davidstrauss> jam: http://blog.launchpad.net/releases/launchpad-3-0-is-here-new-ui-and-more
<jam> davidstrauss: apparently mac installers are a very manual and painful process
<davidstrauss> "To use Bazaarâs new 2a repositories, you should upgrade to Bazaar 2.0."
<davidstrauss> jam: Yes, I've build them for Bazaar before.
<Tak> what can I do about a DirstateCorrupt error?
<Tak> suicide?
<james_w> Tak: "mv .bzr/checkout /tmp/; bzr checkout; bzr status" should fix you up
<james_w> then looking at /tmp/checkout/dirstate might give a clue as to what happened
<james_w> usually it is truncated
<Tak> I think what happened is that I was trying to pull while something else was trying to look at statuses
<james_w> that shouldn't cause a problem
<james_w> it is supposed to have locking so that that will not cause this
<james_w> there may be bugs though
<LarstiQ> kfogel: you online by chance?
<jfroy|work> jelmer: Congratulations on bzr-svn 1.0. Been a long time coming ;)
<Tak> james_w: hmm, that fixed it; not really any indication as to what the issue was, other than the aforementioned
<meoblast001> hi
<meoblast001> i have a question.... this isn't necessary that i'm able to do this, but it would help if i could... is there a way to rewrite old commit messages?
<zsquareplusc> meoblast001: when the branch is published you'll have different comment for the same rev..
<meoblast001> ?
<zsquareplusc> well if you publish your branch and then you edit  the history
<zsquareplusc> so someone else could have a copy of your old commit message
<meoblast001> doubt it, my project isn't too popular yet
<zsquareplusc> meoblast001: i think bzr does not support editing them directly. you probably could use fast-export, edit the data and do a fast-import again
<meoblast001> yeah, with fast-export, how would i edit this
<zsquareplusc> for the last commit you can also uncommit, but i guess you already know that
<meoblast001> yeah
<zsquareplusc> fast-export generates a semi readable text file (XML? did not look at it). it should be editable with your favorite editor
<meoblast001> hexedit
<meoblast001> nothing else will really edit it
<meoblast001> well, at least Gedit can't open it
<meoblast001> it has binary
<zsquareplusc> you write source code using a hex editor? wow ;-)
<meoblast001> no
<zsquareplusc> oh
<meoblast001> perhaps Wine Notepad can open this
<LarstiQ> you really don't want to do that
<zsquareplusc> i can perfectly view the contents: bzr fast-export . |less
<meoblast001> it uses NT line braks?
<meoblast001> breaks*
<LarstiQ> meoblast001: you could use `bzr uncommit` and commit again with a better message
<zsquareplusc> its a simple line based protocol it seems
<meoblast001> LarstiQ: well, i used fast-import to remove a directory that shouldn't be in my project
<meoblast001> i wanted to remove all references to that directory from commit messages so people don't get confused
<LarstiQ> meoblast001: using fast/ex/import should be fine
<meoblast001> well, people might get confused "where is this examples/ directory the commit message speaks of"
 * LarstiQ thought you were trying to hexedit commit messages in a revision
<LarstiQ> meoblast001: how many revisions are we speaking about?
<meoblast001> well, i have 74 revisions in my project
<meoblast001> probably not a ton, but they would be scattered around
<LarstiQ> and how deep down are these?
<LarstiQ> ok
<meoblast001> i found the commit messages in the bzr-export data
<meoblast001> should i just edit those there?
<zsquareplusc> sure
<meoblast001> would Wine Notepad mess anything up?
<zsquareplusc> you probably want to import the data in a fresh branch to check it out before you trash your original ;-)
<meoblast001> i know Windows Notepad on Windows computers i had to use a few times have had trouble reading files i wrote on my Ubuntu machine
<zsquareplusc> notepad? what's this???
<LarstiQ> why would you use notepad?
<meoblast001> Wine Notepad because Gedit can't open files containing any binary
<LarstiQ> I doubt that
<zsquareplusc> try SciTe if you need a programmers editor thats small and simple :-)
<meoblast001> i get errors opening the output file
<meoblast001> ok
<meoblast001> i don't even use WINE anymore.. i don't know why i have it installed >.<
<meoblast001> zsquareplusc: turns out there's an integer saying how long these commit messages are
<LarstiQ> meoblast001: isn't there something else to filter these streams?
<LarstiQ> I'm pretty sure there is
<zsquareplusc> ok. so you have to count the characters? some editors show how many characters you have selected in the status bar
<meoblast001> yes, for filtering
<meoblast001> not for directly editing
<meoblast001> hm i suppose i do :/
<zsquareplusc> heh, so there is your next project ;-)
<zsquareplusc> fyi, the fast-import/export format is documented in the bzr wiki
<LarstiQ> it comes from git land actually
<LarstiQ> so there is more documentation/tools for it
<zsquareplusc> yes i think the bzr wiki guides you there. however it also says something like "forward compatible"
<meoblast001> zsquareplusc: ok, what text editors count characters, i need one
<meoblast001> :O emacs probably does
<meoblast001> since emacs is insane
<zsquareplusc> SciTE, at  least with the settings i have counts them. vim with default settings should work too (if your brain is vim compatible ;-)
<meoblast001> zsquareplusc: i can't find that option
<meoblast001> zsquareplusc: by count characters i mean count the ones you have selected
<zsquareplusc> sure
<zsquareplusc> in SciTe?
<meoblast001> yup
<LarstiQ> vim does
<zsquareplusc> meoblast001: http://paste.ubuntu.com/277378/  put that in Sciteuser.properties (opened in options->open user config)
<meoblast001> i can't figure vim out
<meoblast001> thanks
<meoblast001> with the bzr fast-import filter, can i replace a particular file with another?
<RenatoSilva> How to list all $revno - $commit_msg?
<lifeless> moin
<meoblast001> bzr: ERROR: Bad restart - attempted to skip commit :47 but matching revision-id is unknown
<meoblast001> how do i fix that?
<zsquareplusc> meoblast001: you probably need to run the fast import on a new, empty repo
<meoblast001> what do you mean?
<meoblast001> mkdir dir && cd dir/ && bzr init?
<zsquareplusc> isn't it failing to import your edited fast export?
<zsquareplusc> yes
<meoblast001> ok, that worked thanks
<_habnabit> Is there a way to make bzr-svn remember the HTTP auth username/password used when connecting to a svn repository over HTTP?
<mwhudson> _habnabit: i *think* that if you connect with svn and get it to remember the credentials, bzr-svn will use that
<_habnabit> What do you mean by 'connect with svn'?
<lifeless> do a svn operation
<_habnabit> Yeah, I already tried that.
<mwhudson> ah
<_habnabit> I did a checkout and then an update and it didn't remember my credentials.
<zsquareplusc> with the svn binary?
<_habnabit> No, with bzr.
<_habnabit> I did 'bzr checkout https://example.com' and then 'bzr up'
<lifeless> _habnabit: do one with svn itself
<_habnabit> Okay.
<_habnabit> Oh hm.
<_habnabit> 'svn co https://habnabit@example.com/' isn't using 'habnabit' as my username.
<_habnabit> Never mind, I forgot about --username.
<_habnabit> And nope, it's still asking me for my username and password.
<_habnabit> I checked out the repository over svn and I can 'svn up
<_habnabit> ' without entering it, but bzr doesn't recognize it.
<meoblast> hi
<meoblast> with bzr fast import, can i replace 1 particular text string with another?
<spiv> Good morning.
<meoblast> ugh
<meoblast> doing this manually is going to be a PITA
<meoblast> is there a bazaar plugin for replacing a particular string with another in every commit
<meoblast> if anyone knows of any plugins that do that, please tell me, i'll be up all night manually editing this fast-import file
<lifeless> 'sed' ?
<meoblast> no, won't work
<meoblast> there's a "data" line
<meoblast> and it says how many bytes are in the proceeding data
<meoblast> i have to edit all those fields manually
<meoblast> lifeless: know of anything that can automate this process for me?
<meoblast> lifeless: thousands of lines i'm going through :(
<lifeless> meoblast: git has some filter scripts for fast import streams
<meoblast> i don't think i can handle this any longer
<meoblast> i'm 9000 lines into the file and can't take it anymore
<meoblast> this is taking forever
<meoblast> lifeless: someone in #git told me that git doesn't actually take the same streams as bazaar
<meoblast> now i understand why Linus Torvalds was using tarballs and patches
<lifeless> meoblast: they are lying :)
<lifeless> bzr's fast-import/fast-export use the common fast import format created by git
<lifeless> igc is discussing various extensions to improve the format, but its not a bzr invention
<james_w> meoblast: there is "bzr fast-import-filter" or similar isn't there?
<james_w> not sure it can do that operation though
<meoblast> yes there is
<meoblast> but i can't find anything on filtering the actual contents of source files
<Ng> how do I remove a tag from a remote branch? (a bzr+ssh branch on bazaar.lp.net)
<Ng> I removed the tag locally and pushed some changes, then retagged locally and now when I push it tells me the tag conflicts
<spiv> Ng: push --overwrite
<Ng> aha :)
#bzr 2009-09-25
<onox> can I make a branch of a checkout or a checkout of a checkout?
<fullermd> You can branch a checkout (of course, what you're really doing is branching the branch the checkout is of).
<lifeless> johnf: is there an ETA on 2.0.0 in the PPA  ?
<lifeless> [not the beta PPA, the PPA]
<fullermd> Checking out a checkout doesn't make much sense though.
<johnf> lifeless: about 20 minutes
<johnf> just finishing off bzrtools
<lifeless> mtaylor: ^
 * mtaylor is excited
<onox> fullermd: ok, I was just wondering :)
<thumper> any eta on windows installers?
<poolie> hello all
<bombcar_> How can I push a tag to a remote bzr+ssh repository without doing a pointless commit?
<spiv> bombcar_: just "bzr push"
<spiv> bombcar_: the message about "nothing to push" is misleading :(
<bombcar_> oh, really?
<bombcar_> so it does push it?
<bombcar_> It does! Thanks
<meoblast> with the fast-import-filter, can you filter text in all source files?
<bombcar_> I wonder if there's a bug on that ...
<zsquareplusc> will i be able to install svn-bzr and bzr itself together again from the PPA when 2.0 is out? because upgrading to bzr 1.18 removes bzr-svn (both from the PPA, jaunty 64 bit)
<bombcar_> does a commit push it, too?
<bombcar_> hmm
<bombcar_> it doesn't seem to need a commit
<lamalex> Does anyone know anything about bzr-fastexport? I'm trying to export into git but it's failing
<meoblast> bzr fast-export mybranch/ thestuff.fi
<mwhudson> wow doing a standalone branch of launchpad is slow....
<johnf> lifeless: actually maybe an hour since PPA builders seem a bit busy
<meoblast> does bzr have tree-filtering ability?
<lamalex> anyone know about fast-export/
<lifeless> igc
<lamalex> lifeless: are you telling me to ask igc, or talking to someone else
<lifeless> lamalex: I'm telling you that igc knows about fast export
<lamalex> thanks
<poolie> hello lifeless, spiv
<lifeless> johnf: bzr-svn too?
<lifeless> hi poolie
<johnf> lifeless: I've got latest versions of bzr, bzrtools, subvertpy and bzr-svn ready to go
<lifeless> awesome
<lifeless> johnf: its an ubuntu archive rebuild
<lamalex> igc: http://paste2.org/p/436081 <-- log
<lifeless> johnf: your build should score in front of it
<poolie> lifeless/igc/spiv: so, 2.0.0 or not?
<poolie> i said i'd do it today
<poolie> s/do/announce it
<poolie> we have no site update yet afaics
<poolie> and maybe no windows installers?
<igc> hi poolie, lifeless, lamalex
<igc> hi spiv
<poolie> jelmer: still around at all?
<johnf> Eww really don't like the ordering of https://launchpad.net/builders Can't easily see what the PPA builders are up to
<poolie> johnf: say it (also) in #launchpad where bigjools or someone can hear you
<poolie> also try clicking the 'status' heading
<lamalex> igc: lifeless said you know about fast-export
<igc> lamalex: I do - I'll take a look in a few moments
<lamalex> igc: thanks :)
<lamalex> ill be around just ping me
<igc> poolie: I'm not sure why there's no windows installer built
<igc> lamalex - shall do
<poolie> jam, still here?
<igc> poolie: I though jam had all he needed but maybe he was waiting on an rc2 for bzr-svn or something like that
<igc> poolie: I certainly don't want to announce 2.0.0 until a few people have tested the 'final' windows installer
<poolie> mm, me either
<poolie> i was wondering in the shower whether i'd wait for the web site
<poolie> but i don't want to announce without windows installers
<lifeless> softpedia is odd
<igc> poolie: so I suspect the holdup on the windows installer was that the official branch didn't have you patch for going 2.0.0 gold
<igc> poolie: it looks like jam has fixed that overnight
<poolie> maybe so, but i thought john said yesterday he would just change it in the tree
<poolie> i'll look in to why it didn't get in, as i'm pretty sure it was submitted
<meoblast> lifeless: i'm writting a program to automate this :P
<poolie> i just tried to call jam but couldn't reach him
<lamalex> igc: anything?
<igc> lamalex: just getting to it now
<lamalex> k :) let me know if you need anything
<igc> lamalex: so that's a git crash report, yes?
<lamalex> igc: yah
<lamalex> http://paste2.org/p/436137
<lamalex> that's the terminal output aside from the log
<igc> lamalex: there's a known bug with a patch
<igc> https://bugs.launchpad.net/bzr-fastimport/+bug/427188
<ubottu> Launchpad bug 427188 in bzr-fastimport "bzr fast-export --plain into git fast-import fails" [Undecided,New]
<igc> lamalex: I'm yet to check the patch so it's not merged into the trunk yet
<igc> lamalex: but it will be in the next few days
<lamalex> thanks
<igc> lamalex: can you let me know if that fixes things for you?
<lamalex> yah, it's at least gotten farther thatn it did before
<lamalex> igc: works!
<igc> lamalex: cool
<lamalex> erm, maybe..
<lamalex> it doesn't crash at least
<lamalex> igc: how is this supposed to work. Can you maybe give me a summary from start to finish? Do I run this in a bzr branch that I want to convert to git? It shows all of my files as deleted since the dir I ran it in was empty, but I guess I thought it copied content
<_habnabit> Is there a way to make bzr-svn remember the HTTP auth username/password used when connecting to a svn repository over HTTP?
<igc> lamalex: I didn't think it mattered which directory you ran it in but to be safe, run it in the root directory of the bzr branch you want to import into git
<lamalex> igc: Do you think I should "git init . ; git add" first?
<igc> lamalex: I'd generate the dump file first
<igc> lamalex: I don't know exactly how git-fast-import works so see it's man page for usage
<lamalex> igc: k, thanks a lot for your help on that crash
<Raim> _habnabit: run something like 'svn ls $URL' once, bzr will use the credentials stored by svn AFAIK
<_habnabit> Raim, do I have to login via svn before I do the 'bzr co'? I tried doing the 'bzr co' and then 'svn co' but bzr didn't use svn's credentials.
<lifeless> _habnabit: there is a ~/.svnsomething dir with auth cache under that
<lifeless> poolie: a while back you considered making subunit test output the default, or perhaps for -v, or something. Have you had further thoughts?
<poolie> yes, and the answer is no
<poolie> it's too unreadable
<lifeless> yup, I was surprised at your suggestion :)
<poolie> my suggestion?
<lifeless> you suggested it
<poolie> actually i asked the question "would it be reasonable to just always use it?"
<poolie> and the answer is no.
<lifeless> To me thats suggesting the possibility ;)
<poolie> so you said "I'm happy typing --subunit always"
<poolie> and i'm happy you're happy :)
<lifeless> anyhow, I only brought it up now because I remembered that the thread hadn't been closed
<poolie> the thing i want to fix here is to actually make progress bars still display with subunit redirected
<poolie> should be easy
<poolie> oh btw, zsh love:
<poolie> bzr selftest --subunit >subunit.out |subunit-filter --failures
<poolie> does what it should
<lifeless> mini-tee ?
<poolie> yes
<lifeless> btw subunit2pyunit --progress will show a bzr progress bar
<lifeless> poolie: you were going to show me how to get zsh to do a Y pipe
<lifeless> a -> process B and a-> process C
<poolie> mm
<poolie> i can't recall
<poolie> it should be possible
<lifeless> 1>3 & manual handling I guess
<lifeless> 1>3 | B 3>1 | C
<poolie> btw tell your team mates when you'll be away
<lifeless> sure thing
<lifeless> poolie: bzrlib/tests/blackbox/test_breakin.py, wait_for_process - can you comment on why it sleeps at the start of the loop, rather than the end?
<johnf1> ppa packages are building now
<lifeless> johnf1: awesome
<zsquareplusc> i'm versioning my editor settings with bzr. now i thought about making some of the plugins public. but that would somehow require that i needed to "overlay" two (private/public) repositories in one place. that's probably not supported but how can i do it differently?
<lifeless> zsquareplusc: I think we'd need some more information, I don't know what 'it' entails.
<bob2> ghetto solution is symlinks
<igc> poolie: any word from emmajane?
<poolie> igc, no :-(
<zsquareplusc> lifeless: like having two files that are maintained in two different branches that have to be in the same directory. but there can only be one .bzr
<lifeless> zsquareplusc: and how does this tie into bzr plugins?
<zsquareplusc> bzr plugins? no no, editor plugins and settings
<lifeless> can you symlink to the editor plugins
<lifeless> e.g. ~/bzr1/foo ~/bzr2/bar ~/.editor/foo->~/bzr1/foo ~/.editor/bar->~/bzr2/bar
<zsquareplusc> if i would use two different VCS i could manage half of the files with e.g. svn and the other half with bzr. but 2x bzr probably wont work
<zsquareplusc> yes, symlinks would work, but it will be many symlinks :/
<lifeless> well you only need a symlink for the public stuff [or the private stuff]
<lifeless> poolie: its all pure technical, just needto change the template
<poolie> what is?
<lifeless> the slides
<zsquareplusc> sure, but thats still a number of symlinks that have to be maintained manually for each file in the second branch
<poolie> ok +1
<lifeless> the phone call wasn't MITM'd was it ? :)
<poolie> yes by jam
<lifeless> say hi!
<lifeless> and perhaps ring me from the car?
<zsquareplusc> hm, maybe i can get around the symlinks, it seems the editor can be configured to load plugins from several places
<lifeless> \o/
<meoblast> lifeless: my program is lieing to m
<meoblast> me*
<meoblast> the one i wrote for my bazaar repository
<meoblast> :P
<thumper> lifeless: I'm grabbing some mysql branches for testing
<thumper> lifeless: I hit the branching into empty shared repo problem again
<thumper> lifeless: so I branched into a standalone
<thumper> lifeless: then pulled into a shared repo
<thumper> lifeless: now I'm branching a second branch into the repo
<thumper> lifeless: and it is streaming very slowly compared to the first one
<thumper> lifeless: is this expected?
<thumper> seems to be maxing out at about 20KB/s
<lifeless> do you have hpss logging on?
<thumper> not sure, possibly not
<lifeless> I suspect the branches have little shared history, or something, and its doing a massive history walk.
<lifeless> *or*
<lifeless> its doing conversion on the fly because you're using a different repo format
<thumper> same repo format
<thumper> 1.9
<lifeless> \o/ 2.0.0
<johnf1> ok Packages are ready
<lifeless> spiv: is asyncore in 2.4?
<johnf1> Can someone to an upgrade from the bzr-beta-ppa? If that works ok I'll copy to ~bzr
<spiv> lifeless: it's ancient
<spiv> lifeless: it's probably in 1.5.2
<igc> poolie: I've pushed some updates to the website. Please check them
<igc> poolie: I'm out to lunch for a while - bbl
 * igc lunch
<mwhudson> spiv: it was new in 1.5.2 it seems
<mwhudson> heh, 1.5.2 was just over a decade ago
<spiv> mwhudson: heh :)
<spiv> mwhudson: I just said that version because it was more-or-less the first I used
<mwhudson> yeah, me too
<mwhudson> i think i just about remember 1.5.1 being released
<mwhudson> actually i probably hit comp.lang.python for the first time just after 1.5 was released
<johnf1> hmm the bzrtools 2.0.0 in karmic is broken
<johnf> jelmer: you about?
<lifeless> johnf: please file a bug on bzrtools then; flag it critical or point me at it and I will
<johnf> lifeless: https://bugs.launchpad.net/bzrtools/+bug/436331
<ubottu> Launchpad bug 436331 in bzrtools "bzrtools 2.0.0 in karmic thinks it is 1.18.0" [Undecided,Confirmed]
<johnf> I can't change the importance
<johnf> So I'm wondering what to do with Build-Depends for bzr-svn. Currently it is Depends: bzr (>= 1.16~), bzr (<< 2.1~)
<johnf> but that makes a bold assumption on what the next version is
<johnf> I'm tempted to change it to just Depends: bzr (>= 1.16~)
<johnf> since we release pretty much in lockstep anyway so I don't know that the << has much value
<mzz> am I correctly assuming the contents of "bzr help formats" in 2.0 isn't quite right?
<mzz> specifically it is recommending 1.14 for projects with big trees or deep history (instead of the default format)
<AfC> mzz: I'd have to say so. Use 2a.
<mzz> would this be worth filing a bug on?
<AfC> mzz: yes
<lifeless> johnf: can you prepare a fix for bzrtool?
<johnf> lifeless: bzrtool itself is fine. I don't think that package was built against the release tar ball
<johnf> ie my packages in the PPA are fine
<lifeless> johnf: so the orig.tar.gz in karmic is whack?
<johnf> just confirming now
<meoblast> configure, the endless file
<lifeless> johnf: if so, you'll need to make a debdiff that includes the actual changes to 2.0 upstream against that bad orig
<lifeless> you/we/us/coders
<johnf> Ahh no I know what it is
<johnf> For some reason the debian repo has the version set to 1.18.0 and it is overriding the tar.gz. ie the diff.gz in that package is setting it to 1.18.0
<johnf> If I fix up debian package on alioth and then we request a reimport to ubuntu that will do the trick right?
<lifeless> if you upload to debian unstable, yes
<lifeless> syncs go from unstable
<johnf> ok let me try and do that. Should be a good test of if I'm really a DD :)
<lifeless> also that bug should be on the package
<lifeless> fixing
<johnf> good point
<mzz> (filed it, I'd write the patch but I don't know what the wording for existing projects should be, if not the current)
<lifeless> johnf: can you upload 2.0.0 to experimental and/or unstable?
<lifeless> johnf: experimental has 2.0rc1, which is brain damaged
<mzz> and just confirming: running "bzr check" and possibly "reconcile" in the root of a shared repo is sufficient, right? No need to run it in all the branches too?
<lifeless> mzz: for upgrading, yes
<mzz> yay
<lifeless> johnf: and yes for http://packages.qa.debian.org/b/bzrtools.html fixing it then asking for a sync
<meoblast> ok, this makes no sense
<meoblast> bzr: ERROR: line 36528: Invalid command 'sr/share/fonts/truetype'
<meoblast> let me show you line 36528
<meoblast> 	@(echo "$(distdir) archives ready for distribution: "; \
<lifeless> meoblast: is there a $u somewhere there ?
<meoblast> not that i see
<SmileyChris> LarstiQ: I'm using the Bazaar (PPA https://launchpad.net/~bzr/+archive/ppa) and bzr-svn is too old in there. Noticed you were the uploader of the last version. Any chance of getting bzr-svn 1.0.0 pushed there?
<meoblast> lifeless: my checks are saying that everything is perfect
<jam> igc: ping
<johnf> SmileyChris: Will be happening very soon. Just waiting for it to rebuild in beta-ppa
<meoblast> the minute these errors make sense is the minute i can actually fix this
<SmileyChris> johnf: cheers, it's been pestering me for a while so I thought I may as well ask :)
<lifeless> SmileyChris: please file bugs on such things; tells us stuff we may not have noticed :)
<SmileyChris> you're right - I should have done as much
<lifeless> no worries
<mzz> mmm, bzr check is apparently not very fast
 * mzz is running it on a shared repo with a bunch of branches of bzr itself in it
<jam> igc: the windows builds aren't working because of whatever you did to add the new icons
<jam> I'm getting:
<jam> Error on line 22 in C:\home\shared\bzr\bzr-windows-installers\build-win32\release\bzr.2.0.
<jam> 0\tools\win32\bzr.iss: The system cannot find the file specified.
<jam> and line 22 is
<jam> WizardSmallImageFile="bzr-48.bmp"
<jam> I don't really have the time to fix this up tonight, unfortunately.
<jam> I tried just adding a 'copytree' to the Makefile, but that didn't seem to be enough
<jam> then again, I don't know why it is using 'bzr.2.0.0\tools/win32\bzr.iss' rather than using the one from bzr-windows-installer, etc.
<jam> something certainly doesn't seem right
<jam> (given that it sort of has to be using the source file from bzr-windows installer, or it wouldn't have those lines from a pure bzr-2.0.0 tree...)
<jam> igc: Anyway, if you get back online and have a chance to look at it, it would be nice to get the windows installers built
<jam> worst case, I guess I can revert your changes
<lifeless> hi jam
<jam> hi lifeless
<jam> I'm pretty close to bedtime
<jam> but I responded to some of your emails
<lifeless> cool
<meoblast> Bazaar is really starting to tick me off
<lifeless> what is it [not] doing?
<meoblast> i need to change a particular text string in every single file in every revision
<meoblast> i'm completely removing a font we used and replacing it with another
<meoblast> and i need revisions 1 - 70 to still work
<lifeless> did you grab gits fast import filter tools?
<meoblast> i was told i'd have to convert my repo into a git repo
<lifeless> huh? no
<lifeless> who told you that
<meoblast> the people in #git
<lifeless> and you listened to them :(
<meoblast> they told me to write a program that automates this
<meoblast> i spent the past few hours trying to perfect a small C (++) program
 * mzz boggles
<mzz> revising history is certainly a bit awkward, but I don't see why it should involve c++
<meoblast> well, the fast-import dumps are very awkward
<meoblast> they contain the string "data XXXX" followed by the data
<meoblast> the XXXX has to be an integer matching the amount of bytes proceed
<mzz> ah, I didn't know that detail.
<meoblast> so if i switch Vera.ttf with LiberationSans-Regular.ttf, i need to add 18 to each of those numbers
<mzz> while awkward c++ wouldn't be what I'd use to muck with this
<lifeless> meoblast: but what is it you're changing?
<lifeless> the commit messages?
<mzz> the font name, presumably
<mzz> oh, or the actual font
<meoblast> well, the commit messages would be easy
<meoblast> i'm trying to change the actual code so that things will still function with Liberation sans
<meoblast> if all the code still says "Vera.ttf" yet there's only a LiberationSans-Regular.ttf, revisions 1 - 70 will be completely broken
<lifeless> so, personally I'd accept that you did it differently and just commit a change; I really don't understand deep history rewriting like this.
<lifeless> that said
<lifeless> lets try and help you
<lifeless> bzr'-fast-import has a command fast-import-filter is likely a good place to start to be editing the content like you need to
<meoblast> lifeless: want to see the program i wrote?
<lifeless> sure
<meoblast> it's ugly and inefficient but as i went down the file, it seemed to be doing _most_ things right
<meoblast> http://codepad.org/BOTe3oKK
<meoblast> what made me finally say "wtf" is when i saw a bunch of "NULL" bytes all over the place in the output
<meoblast> one major problem is that it's not good at crossing the digit border
<meoblast> from 98 to 116 let's say
<mzz> well, if there's no pre-existing way of doing this I'd attempt to hack up bzr's fastimport plugin
<mzz> since it already has to know how to read fastimport files, so you should be able to get at the raw text you want to manipulate as python strings
<meoblast> i don't know python
<mzz> ah
<meoblast> only a little
<mzz> that explains why you went for c then
<meoblast> doubt i know it enough to do anything useful
<meoblast> that program is "C++" but i'm sure it could be compiled with a C compiler and run fine
<lifeless> I'm fairly sure \0 is valid in a .fi
<lifeless> its a binary file
<meoblast> yes, but i'm unsure why a ton of those started showing up
<lifeless> because you have binary content in your repo?
<lifeless> such as, oh, fonts? :)
<mzz> ah, neat, the fastimport plugin already has a filters concept
<meoblast> yeah, i still have to actually remove the Vera font from the stream
<meoblast> and pop in the Liberation
<meoblast> Liberation's license looks a lot prettier
<meoblast> i'm trying to use very unrestrictive licenses
<lifeless> not sure why this means you have to rewrite history
<meoblast> because i have OCD?
<ScottK> The whole point of history is that it reflects the actual history.
<meoblast> trust me, the actual history of this project isn't too pretty :P
<lifeless> ScottK: how did you go with that performance thing?
<mzz> well, I wouldn't bother rewriting history for this, I think, but if I did anyway I'd probably write a custom "processor" for bzr's fastimport plugin
<mzz> it looks like the ones currently in there can't quite do this
<meoblast> due to me not having a thorough grasp of version control early on, i quickly brought sizes up
<ScottK> lifeless: Got sidetracked.  The 'milli' that was here yesterday asking about formats was the git freak on the project in question.
<lifeless> heh :)
<meoblast> i thought i might as well clean things up before more than 2 people have a checkout
<ScottK> We have a little time to play as the project can't really get started until some contractual details are resolved.
<meoblast> if the line numbers on these errors weren't misleading, that would be great :P
<mzz> meoblast: so what were you trying to do again? simple search/replace on raw file content across all commits?
<meoblast> yup
<meoblast> all the numbers seem right on my end
<meoblast> i'm testing the file
<mzz> oh, you got it working already?
<meoblast> i see no problems (at least not where it tells me the problems are)
<meoblast> no, i should have it working
<mzz> was going to say this seems pretty doable by hacking up fastimport, so I could do that if you can throw me a .fi file to test with
<meoblast> bzr: ERROR: line 89879: Invalid command ''
<meoblast> it's been telling me bad line numbers on errors all day
<meoblast> i'm expected to figure out where the error is manually
<meoblast> i checked that line, it was counted perfectly
<RenatoSilva> how to view --fixes information in bzr log?
<meoblast> mzz: this is just karma getting me back
<meoblast> i've been telling another developer that bazaar kills git for weeks now
<mzz> well, this is history rewriting
<mzz> is that really something git's good at? because it's not usually a good idea
<lifeless> mzz: git has some fairly polished tools
<lifeless> mzz: callback per commit style thing.
<mzz> (because like you said yourself it breaks pretty badly if people already got their hands on your branch)
<lifeless> mzz: we need to do a lot better here :)
<mzz> lifeless: there's a "foreach" plugin, I noticed
<mzz> although I guess that doesn't mutate
<mzz> hrm
<meoblast> i probably should have made a rerolling script
<meoblast> lifeless: i go through all these files in this dump thinking "oh i hope this one has some kind of discrepency"
<meoblast> no, all the number match  :(
<meoblast> yay, it works
<meoblast> it was those NULLS at the end of the file
<johnf> OK packages now copies to ~bzr PPA
<meoblast> last step, and i'm failing at it
<johnf> and bzr and bzrtools now both uploaded to debian
<meoblast> java :O
<meoblast> anyone know of any text editors that can let me copy and paste binary without corrupting it?
<mwhudson> emacs, i think?
<meoblast> how do you copy and paste in emacs?
<meoblast> wait, i have GTK emacs
<igc> hi jam
<jam> meoblast: vim if you ':set binary'
<meoblast> how do you select all in emacs?
<mzz> meoblast: C-x h
<jam> hey igc, any ideas about why the build would fail?
<jam> I assume you had it working when you committed it
<mzz> (it's silly but I actually had to type that into emacs, I have it in muscle memory)
<igc> jam: I'm just trying it now
<igc> jam: the images are meant to be copied across so it should be finding them
<meoblast> i'm getting angry :(
<meoblast> there has to be a way to just pop this file into this stream without something breaking
<igc> jam: I hadn't tested it sorry on the bzr installer (as I never had that fully working) but I did on the explorer one
<meoblast> i'm not getting errors but i'm not getting any font data
<meoblast> just a title
<meoblast> if emacs can't do it, nothing can
<meoblast> looks like i'm writting a new program?
<meoblast> one that will insert a binary file right in here
<jam> igc: k, I think it just needs to be pointed to the right location
<jam> I just don't know exactly where that would be with all the copying, cogifying, etc.
<jam> meoblast: i would really recommend looking at the 'filter-branch' portion of the fast-import code.
<meoblast> but i'm so close :(
<jam> and poke at igc since he's the one that has done most of the work for fast-import
<jam> but let him fix my problem first :)
<meoblast> you have to understand how close i am
<meoblast> last thing i have to do is get this font into the stream
<meoblast> that's it
<meoblast> i'm trying to write a program that will do it
<igc> jam: so I'm copying the images into the top build directory - maybe it needs to be a subdirectory of that
<igc> jam: I'm trying it now fwiw
<igc> jam: lines 142-143 in build-installer.bat.in ...
<igc> maybe the target destination needs to be %TARGET% instead of ...
<igc> win32_bzr.exe
<jam> igc: I would guess you could just change the path in bzr.iss.cog
<jam> to be ../../bzr-48.bmp
<jam> given that you are creating tools/win32/bzr.iss
<igc> jam: the path is relative to wherever issc is run btw, not the location of bzr.iss
<igc> I *think* it being run in %TARGET% ??
<jam> igc: if that is true, then either the cp needs to go to .
<mzz> also, am I the only one who always forgets to check shelve before deciding a branch is obsolete and can be deleted?
<jam> or the path updated to win32bzr.exe/xxx.bmp
<mzz> perhaps I should extend status to have a single line "shelved changes present"
<igc> mzz: that would be good
<mzz> has someone beaten me to that yet? :)
<igc> jam: it's taking forever here for my various branches to be refreshed so ...
<igc> jam: if you could try chagning those copy statements, that would be good
<jam> igc: it takes just as long on kerguelen when things are up to date
<jam> problem is that IO on kerguelen is awful
<jam> but I'll try it, start it running
<jam> and go to bed
<jam> so no 2.0.0-1 installer tonight
<igc> jam: yeah, I'm hitting that refresh bug so it keeps falling over on tags not being present
<jam> but maybe tomorrow early
<jam> igc: yeah, that's pretty annoying
<jam> given that the point of using buildbot
<jam> was so that we could have it autorefresh
<jam> my 'build_release.py' did that just fine
<jam> so far, my net experience of the buildout.cfg switch has been a net loss
<jam> a lot more complexity without it actually working better
<jam> and 'bin/buildout' seems to spend a huge amount of time verifying stuff
<jam> at least on kerguelen
<meoblast> this is impossible
<jam> that may just be I/O being awful there
<meoblast> no D':
<meoblast> these streams are defective
<igc> jam: so I've needed to start from scratch with a clean build_win32 directory :-(
<jam> igc: ouch
<jam> though I updated it so that all clients will share your local repo
<jam> rather than building one per plugin
<jam> so at least you will only redownload everything 1 time
<jam> (I did it *because* of stuff like this)
<meoblast> i think i might have this working
<meoblast> i have to test
<meoblast> the font i have in here isn't working in KFontView but Gnome font viewer is displaying it fine
<meoblast> time to see if my app can display it
<lifeless> jam: dropped you a callgrind you might find interesting; not urgent.
<meoblast> nvm.. i'm seeing some epoch fail
<meoblast> good night
<meoblast> mom's yelling at me.. like always
<lifeless> ITYM 'epic'
<meoblast> no comprendo
<meoblast> ITYM?
<lifeless> I think you mean
<meoblast> yeah
<meoblast> i used the word epoch to describe how epic the fail was
<meoblast> anyways, i'll work more on this tomorrow
<meoblast> i'm seeing tons of work to do
<meoblast> good night
<mzz> is there a helper for subclassing a builtin command? things like the help text (__doc__) don't survive if I just subclass
<lifeless> mzz: you can decorate instead.
<lifeless> or say __doc__ = builtincmd.__doc__
<mzz> that's what I thought, but it doesn't actually work
<mzz> "attribute '__doc__' of 'type' objects is not writable"
<mzz> unless I did something braindead, of course
<mzz> what does "decorate" mean in this context?
<lifeless> did you say 'class.__doc__ = ..'
<mzz> yes
<lifeless> or __doc__ = .. ?
<mzz> what should I be saying instead?
<mzz> oh, gah
<mzz> I am a moron
<mzz> "decorate" sounds promising though, how does that work in this context?
<mzz> I definitely don't want to replace the whole thing, I just want to add a line of output unless certain switches were passed
<jderose> FYI, there is a problem with the bzrtools package in the PPA: bzrtools: Depends: bzr (< 2.0~) but 2.0.0-1~bazaar1~jaunty1 is to be installed
<jderose> i filed a bug: https://bugs.launchpad.net/bzr/+bug/436371
<ubottu> Launchpad bug 436371 in bzr "bzrtools 2.0 package broken in PPA" [Undecided,New]
<jderose> great job on the 2.0 release, everyone.  i'm lovin' it!  ;)
<lifeless> jderose: cool
<lifeless> mzz: have a look at cmd_switch in bzr-loom
<mzz> ah, thanks
 * mzz is rarely too lazy to read the manual or example code, but occasionally too lazy to go hunting for sane example code to read
<mzz> ah, I see. That should hopefully allow multiple plugins extending the same command?
<mzz> probably unrelated, but what's up with those getattr(commands, 'cmd_switch') calls in __init__.py? Can't that just be commands.cmd_switch?
<jam> mzz: old versions of bzrlib didn't have cmd_switch
<lifeless> loom still runs with bzr's that don't have a built in switch
<lifeless> jam: inore that .callgrind; the user had 256MB of ram allocated to his VM ><
<lifeless> jam: so its swapping showing up
<jam> lifeless: interesting
<jam> I'm curious what the peak memory was
<jam> if those 165MB files are moderately compressible
<jam> we should have been able to do it in <=256MB
<jam> though not that + system
<jam> anyway, me sleep
<lifeless> shoo
<lifeless> talk to you monday :)
<mzz> I know, that's what the hasattr call is for. But why does it do getattr(commands, 'cmd_switch')? Even if it wasn't inside a hasattr it still wouldn't do anything different from just commands.cmd_switch
<lifeless> dunno, not looking at the code right now :)
<lifeless> probably a buglet snuck in
<mzz> I don't think a bug, it just seems like an unnecessarily complicated way of writing the same thing, unless I'm confused about how python works again
<mzz> lp:~marienz/+junk/shelfstatus is now a plugin adding one line "%d shelved changes" to "bzr status" if there are any. Does that seem like a good idea to anyone else? Perhaps I should file a feature request bug.
<lifeless> please
<lifeless> that would be good in core
<mzz> yay
<mzz> drat, already filed
<mzz> bug 403687 that is, which I commented on.
<ubottu> Launchpad bug 403687 in bzr "bzr status should show shelved changes" [Wishlist,Confirmed] https://launchpad.net/bugs/403687
<mzz> (it's obviously not hard to implement, although figuring out exactly what modes of the status command it should shut up in might require a bit more thinking than I did)
<mzz> I'm glad there's a plugin mechanism so I can scratch this kind of itch without having to run a patched bzr :)
<vila> hi all
<vila> hmm, looks like I tried to run update-manager *just* at the wrong time :-/
<vila> I thought copying packages from one PPA to another will avoid such synchro issues... bur bzrtools-2.0.0-2 is still pending publication while bzr-2.0.0-1 has been published 2 hours ago ?
<vila> james_w: Can you shed some light ? ^
<igc> hi vila!
<igc> poolie: I've update the website branch with a 2.0.0 news item, better executive summary and working links
<jderose> vila: there is an error in debian/control: Depends: bzr (<< 2.0~)
<jderose> vila: https://bugs.launchpad.net/bzr/+bug/436371
<ubottu> Launchpad bug 436371 in bzr "bzrtools 2.0 package broken in PPA" [Undecided,New]
<igc> poolie: is it worth rolling this out somewhere?
<jderose> ubottu: ;)
<vila> jderose: I'm pretty sure someone is already working on that
<jderose> vila: ah, oops.
<vila> yeah, it's already fixed for jaunty at least
<vila> jderose: no oops, you were right to file  a bug
<vila> jderose: are you on jaunty too ? Can you check it's fixed fir you
<vila> s/fir/for/
<jderose> vila: yeah i am, just apt-get update and it works now, thanks
<vila> hehe, thanks jonhf instead, I was just whining :D
<jderose> vila: works on my hardy vm too
<vila> jderose: great, I'll mark it fix released then
<jderose> cool
<igc> poolie: http://people.canonical.com/~ianc/dancingmonkeys/ (latest website live)
<bialix> hello bzr
<bialix> anybody can provide me hints what I need to write plugin which controls default format in bzr?
<bialix> maybe there is already one?
<bialix> just yesterday I've stepped in the problem with undesirable upgrade to 2a format of branbch which should be in 0.92
<Peng_> bialix: It's set with bzrlib.bzrdir.format_registry.set_default('2a')
 * bialix looking
<Peng_> bialix: (it's the last line of bzrdir.py)
<bialix> I see
<bialix> so all I need is to override this in my plugin?
<Peng_> Probably. Try it and see.
<mzz> I don't recall bzr implicitly upgrading branches on me though.
<Peng_> I've been slowly upgrading to 2a anyway. :P
<bialix> mzz: easy: create shared repo in 2a and branch there from 0.92
<mzz> yes.
<mzz> I don't see changing the default format helping with that though, unless you mean by making it harder to create a 2a repo
<bialix> yes
<bialix> Peng_: this does not work: "Key 'default' already registered"
<bialix> I can't change default
<bialix> help?
<Peng_> Oh, darn.
<Peng_> bialix: .remove it first, I guess?
<mzz> shrug, it's python, if you really want to you can find a way around it
<vila> wow, karmic VM booting in 10 secs... (shutdown in 20s though.... surprising :)
<LarstiQ> bialix: isn't there a setdefault() call?
<bob2> bialix: https://code.launchpad.net/mbp/+junk/default2a
<bob2> bialix: maybe hack that?
<vila> bialix: poolie wrote such a plugin
<bialix> bob2: Page not found
<vila> bialix: lol, yeah, what bob2 said
<vila> bialix: it's a branch
<bob2> https://code.launchpad.net/~mbp/bzr/default2a
<bialix> This branch has not been pushed to yet.
<bob2> hmmm
<bialix> bob2: third try?
<bob2> bialix: I got the initial link from https://bugs.launchpad.net/bzr/+bug/398668
<ubottu> Launchpad bug 398668 in bzr "2a format should be the default but some tests fail" [Critical,Fix released]
<bob2> ask poolie I guess
<bialix> vila: any help?
<vila> bialix: searching
<bialix> poolie is not here
<vila> bialix: lp:~bzr/+junk/default2a
<vila> third is a charm :)
<bialix> ok, thanks
<bialix> working
<bialix> anybody need it? do I need to publish my format switcher?
<bialix> vila, Peng_, bob2: thanks, I'm almost happy now
<bialix> 2.0 is unblocked for me
<vila> great
<bialix> now waiting for jam and installer
<Lo-lan-do> 2.0 in unstable \o/
 * Lo-lan-do throws flowers all around
<igc> bbl
<awilkins> 2.0! Shiny.
<vila> lifeless: are you kidding with leaving a zombie from test_breakin ? I explicitly spend time ensuring that we don't... or may be you think it rarely occurs ? Want some stats to change your mind or do you trust me on hat one ?
<vila> s/hat/that/
<maxb> Hmm. I'd dearly like to see bug 45719 fixed, but the more I look at it the more complex it seems
<ubottu> Launchpad bug 45719 in bzr "update command cannot take a revision number" [Medium,In progress] https://launchpad.net/bugs/45719
<maxb> Especially as I've never hacked on bzr before :-)
<awilkins> jelmer: Is bzr-svn 1.0 really Python 2.5 and up only?
<awilkins> jelmer: I've been using Python 2.4 on earlier versions.... is there a version where it specifically changed?
 * awilkins runs bzr selftest svn    bzr 2.0.0 / bzr-svn 1.0.0 / subvertpy 0.6.9 / python 2.4.3 / CentOS
<AfC> awilkins: I was just going to suggest that. Presumably that'll give you at least some indication
<awilkins> AfC: Very reassuring ; compared to the codebase I'm working on, which is 277 thousand lines of Java and about ooooo, a hundred lines of tests.
<AfC> awilkins: yeah, well, I very deliberately don't use libraries like that.
<AfC> admittedly, testing end-user GUI code is hard, but I try my best.
<awilkins> I'm ashamed to have written 22k lines of Java last year with no tests (mostly not GUI).
<awilkins> In my defence, I get about 1 bug reported every 2 months
<awilkins> And that's tailing off.
<awilkins> This thing.... we've had a new release, seemingly with new bugs, every day this week.
<awilkins> Bloody contractors
<lifeless> vila: if its going to leave a zombie thats not desirable, but 10 seconds on fail isn't either
<lifeless> vila: perhaps you could tweak it to meet the intent of my change?
<vila> lifeless: by reducing the delay ?
<lifeless> vila: yes
<awilkins> Bah, needs tdb to run all the tests.... <install/run/curse>
<lifeless> vila: right now, about one run in 3 it XFAIL's
<vila> lifeless: to say the truth, when I reviewed it I was secretly hoping you will be deleting that tests :-)
<lifeless> vila: my patch still closes it, no zomibie
<lifeless> vila: if there is a zombie left it fails()
<vila> oh, I was wrong then ?
<lifeless> vila: I think you may be assuming something, yes.
<vila> but then you comment is misleading since that from it that I based my comment ?
<vila> errr
<vila> I thought it left a zombie from:
<vila>  # process isn't gone, user will have to hunt it down and kill
<vila> 128	+ # it.
<lifeless> look at the current code, it can do that too
<lifeless> and if that happens, it does self.fail(...)
<vila> ooooooh
<vila> but you try to killl it once only
<vila> ok, +1 then, I'll comment for mor e ideas
<james_w> vila: no idea, sorry.
<vila> james_w: np. I thought you encountered the same kind of issues for karmic yesterday or the day before ?
<james_w> don't think so
<vila> james_w: nm then
<lifeless> vila: we wait once, we kill it 3 times
<lifeless> vila: capped 0.4 seconds overhead
<vila> lifeless: I seem to recall other numbers and experiences but things may have changed or my memory may betray me, I like your cleanup anyway, let's try it and wait for more evidence (if any !)
<lifeless> vila: http://www.informationweek.com/blog/main/archives/2009/09/a_gpl_court_vic.html - did that make the mainstream press in france?
<vila> lifeless: first time I hear about it, but I'm not really paying attention to mainstream press myself (but my friends know me enough to warn me for such subjects generally...)
<jelmer> awilkins: no, it should work with 2.4 as well
<awilkins> jelmer: I read INSTALL and thought the worst :-) ; I've been successfully using it on Python2.4 for a while though (version 0.6.5)
<Lo-lan-do> lifeless: It did.
<Lo-lan-do> lifeless: Didn't make a large splash, but the main papers reported it.
<awilkins> jelmer: That's odd ; I installed python-tdb but it still says "Missing feature 'tdb' skipped 23 tests."
<awilkins> jelmer: Still, it passed the other 1200 or so...
<Lo-lan-do> lifeless: However, strictly speaking, the court decision isn't upholding the GPL.  It's mostly about a contract that wasn't completely fulfilled, and the GPL was only incidental.
<vila> lifeless: researching the subject a bit: 1) it's mentioned on zdnet which is well known but not mainstream.  2) There seem to be a lot of discussions about whether the GPL was really exercised there as opposed to a simple contract violation (evidence points to the later)
<vila> lifeless: summary, good, but not that big a victory IMHO
<awilkins> vila: Open source proceeds via incremental small victories :-)
<vila> lifeless: ie I think Germany has more real GPL  uses in court
<awilkins> Think of it as a small but useful patch :-)
<vila> awilkins: sure, I'm happy with that, just giving lifeless feedback on my "local" POV
<davidstrauss> vila: There was a brief period where the 9th circuit court in the U.S. had some interesting findings on GPL violations being contract (not copyright) violations, but those were reversed later.
<vila> which may or may not be relevant...
<vila> davidstrauss: the contract didn't involved the GPL explicitly here
<vila> sounds more like crass ignorance than wrong behaviour to me, but IANAL and I'm tend to be naive too sometimes (just to compensate for my natural cynical inclinations :D
<vila> lifeless: oh, and they had to pay 8000 euros, just to give some scale...
<lifeless> heh
<awilkins> That would buy me a new car. As long as it was a very small one.
<awilkins> Heck, with my "eco-friendly" scrappage bonus for having an old junker, it might even buy me a _nice_, new, small, car
<Lo-lan-do> Or a new motorbike, moderately flashy.
<awilkins> Lo-lan-do: I like having cargo space... and ungrated knees
 * Lo-lan-do got a new bike for 6000â¬ this week :-)
<awilkins> I'd really like a small car powered by one of these (currently vaporware) new ultracapacitors they are supposedly making in Texas
<awilkins> But I've had the one I've got 10 years and it's only done about 43,000 miles
<davidstrauss> awilkins: Wait, what are we supposedly making?
<awilkins> It's called EESTOR
<awilkins> They claim to have found a way of producing a capacitor that can store 52kWh in under 200kg
<awilkins> It's an array of 38,000 elements made of some sintered glass/alumina/barium titanate composite
<lifeless> woo
<davidstrauss> awilkins: Both EESTOR and the UT Austin supercapacitor teams are within ~10 miles of my office
<awilkins> davidstrauss: Heh, don't tell the nutters at eestory.com, they'll want you to go and scout them out
<davidstrauss> awilkins: eestory.com is a 404
<awilkins> davidstrauss: Sorry... theeestory.com
<awilkins> And bariumtitanate.blogspot.com
<awilkins> If it works I'll be pretty enthused
<awilkins> It would make electric vehicles and domestic microgeneration somewhat more practical
<awilkins> Hmm. Isn't --2a supposed to make your repository smaller
<vila> davidstrauss: 404 is well known old Peugeot french car, I don't think it's related :D
<davidstrauss> awilkins: --2a is the zombocom of repo formats.
<awilkins> up to 1.7G from 949M
<davidstrauss> awilkins: Run pack once more
<Kinnison> awilkins: did you then try repacking?
 * awilkins is doing that now
<davidstrauss> awilkins: Bzr archives a lot of junk during the first pack
<davidstrauss> awilkins: there's a good reason, but the junk doesn't get dumped until the *second* repack
<awilkins> Am I imagining it or does 2a take a lot longer to repack than previous formats :-/
<awilkins> Ok, it's a large repo
<lifeless> awilkins: 1) make sure you have the C extensions
<lifeless> 2) remove the contents of .bzr/repository/obsolete_packs after doing a sync()
<awilkins> Got my 2.0 install from the ubuntu package manager
<lifeless> davidstrauss: your advice is outdated btw
<davidstrauss> lifeless: how so?
<lifeless> awilkins: you don't need to pack after converting if you used 2.0.0 to do the conversion
<lifeless> davidstrauss: ^
<lifeless> davidstrauss: bzr packs if it needs to while converting
<awilkins> I thought it said "repacking" a lot :-)
<Kinnison> lifeless: What's the obsolete_packs stuff and why doesn't bzr clean it up itself?
<lifeless> Kinnison: ext4 insurance
<davidstrauss> lifeless: oh, i just mean how pack archives stuff and doesn't dump archives until the second repack
<awilkins> Aha, obsolete_packs has 865M
<Kinnison> lifeless: bah, I don't use ext4.  Can I opt out of the insurance?
<awilkins> I should know this, I've been using it that long
<lifeless> Kinnison: no, because I was trolling. More details...
<lifeless> fsync() is silly, we want fbarrier.
<lifeless> obsolete_packs is our manual fbarrier basically; when we delete a data containing file we:
<lifeless> rm obsolete_packs/*
<lifeless> mv foo obsolete_packs/
<lifeless> it will typically carry about 10 commits worth of content [thats the most common autopack size]
<Kinnison> Mine was 33% of the size of my branch (which has many more than 30 commits)
<lifeless> Kinnison: even if we had barrier, FTP & windows would be an issue
<lifeless> Kinnison: it does this at power of 10 intervals
<Kinnison> What's the semantics you need from fbarrier() ?
<lifeless> if you have 123456 commits
<lifeless> the max pack counts is 1 + 2 +3 + 4 +5 +6
<lifeless> if the pack count in the repo is larger autopack is triggered for the excess packs (taking the smallest packs first)
<lifeless> so if you (say) were at 109 commits
<lifeless> your most recent autopack would have aggregated 100 commits, and moved your entire prior repo contents
<lifeless> bbiab
<awilkins> Down to 866 MB from 949... well, not too bad
<Peng_> What's the change that means users no longer need to pack twice after a conversion to 2a? The thing in NEWS about more stable sorting?
<vila> lifeless: final word about that GPL in court in France, the suit was an appeal of a first suit that granted ~1Meuros to the plaintiff, and was reverted tp give 8000euros to the defender (sp ?), so more important than I thought (I had to read the judgement to get a bit more context)
<vila> and the GPL is clearly cited in one of the last conclusions, so it is in fact clearly an real use in court
<vila> and the story started in 2000...
<vila> ... and for the fun stuff, it involved using VNC with an hidden undisclosed to the client password for PC installed in public places....
<vila> tenths of PCs if the contract had been completed
<awilkins> Bet it wasn't Linux machines with the VNC in a chroot jail either :-)
<vila> windows indeed
<vila> and the full contract was ~3Meuros
<vila> So yes, basically even with that bunch of money involved they try to replace the GPL with their own copyright...
<vila> idiots
<orattue> is there a command to check what revision a working tree is on. bzr revno will tell me the revision of the repo tree,  but not my working tree.
<awilkins> orattue: There must be a way, because qbzr does it in some of it's dialogs, but I don't know the CLI version off the top of my head
<orattue> hmm
<awilkins> Heavens, `bzr help commands` is really long now, even with --no-plugins
<awilkins> orattue: bzr revno --tree
<orattue> hmm so that must be in newer version of bzr
<orattue> will update my bzr now
<orattue> odd that parameter is not in the online manual
<orattue> ah no it is :)
<Peng_> Random off-topic question: Do they sell C5-size notepads?
<awilkins> Question ; would it be possible to pull multiple branches in a single ssh / bzr+ssh session?
<Lo-lan-do> awilkins: Yes, with SSHÂ connection multiplexing.
<awilkins> It's not a real concern but I'm finding that the session creation and teardown is much more time consuming than the actual pull
<awilkins> Lo-lan-do: How might I achieve that?
 * awilkins googles
<Lo-lan-do> awilkins: The keyword is "controlmaster" in man ssh_config
<Lo-lan-do> This only avoids the SSH session overhead though, the remote bzr will still be invoked several times.
<awilkins> Lo-lan-do: Hmm. Working, but not that much faster
<awilkins> Lo-lan-do: Maybe it is the remote process  creation. Never mind, wasn't critical
<AfC> awilkins: as an alternative you might try running a bzr:// on the server side. {shrug}
<AfC> [one process, period]
<awilkins> Yes
<AfC> [for pulling, anyway. Still gotta use bzr+ssh to push]
<awilkins> AfC: Not if it only listens to a local port that you have to tunnel to with ssh
<awilkins> AfC: And you use --allow-writes
<awilkins> But not critical, it's just very slightly annoying when the rest of it is so fast :-)
<lifeless> visik7: thanks
<jml> jelmer, you around?
<jelmer> jml: somewhat
<lifeless> visik7: sorry, typo
<lifeless> vila: thanks
<lifeless> hi jml
<jml> jelmer, I was just talking to beuno about the ohloh import of Bazaar
<jml> lifeless, hello
<jml> jelmer, it's really slow, and I'd like to help them. He said that you knew some of the people involved.
<jelmer> jml: yeah
<jelmer> jml: obnox (a fellow samba developer) did the original support together with Robin from ohloh.
<jelmer> jml: robin_at_ohloh hangs out in #ohloh, he's probably the best person to talk to
<jml> jelmer, what would it take to get them to ask "we're doing <<DETAILS>> and it's really slow, how can we do it better?"
<jml> jelmer, ok, thanks.
<jelmer> jml: the source code importer in ruby is open source and on github somewhere
<jelmer> jml: unfortunately it's all in Ruby
<jml> jelmer, ahh, I see.
<jml> jelmer, I'm sure we can do _something_ to make it better.
<Peng_> Wow, SSH connection multiplexing is coool. I should've set that up long ago.
<jelmer> jml: They're basically invoking bzr cat for every file+revision combination IIRC
<jelmer> jml: Let me see if I can find the repo URL..
<jelmer> jml: git://labs.ohloh.net/git/ohloh_scm.git
<jml> jelmer, thanks.
<mthaddon> lifeless: any objections to updating the chroot for bzr pqm from dapper -> hardy (will make python-subunit dependency much easier)?
<Lo-lan-do> jelmer: Unstable's bzrtools 2.0.0 has a version.py that still says 1.18â¦
<vila> mthaddon: check with lifeless but I think one reason to stay with dapper is python-2.4 compatibility, if we can get that with hardy (and I think we can), there shouldn't be a problem
<mthaddon> vila: that's why I was asking lifeless :) but hardy has 2.4 no problems
<vila> mthaddon: hehe, sry was trying to help without knowing the full context :D
<mthaddon> np :)
<Tak> does this suggest anything particular? http://paste2.org/p/437109
<vila> Tak: that you're trying to open a None object ?
<Tak> I wish, then I could fix it!
<vila> you mean 'directory' is not None ?
<Tak> this is all happening internal to cmd_pull
<vila> Tak: huh ? From the command-line ?
<vila> Tak: are you using bzr.dev ?
<vila> that 1552 line is different her
<vila> that 1552 line is different here
<Tak> no, I'm using cmd_pull from code
<vila> ha, no silly, site-packages, installed version ?
<vila> Tak: did you set .outf and are you sure your encodings are correct ? Can you show me the code ?
<Tak> bzr --version gives me 1.18
<vila> what os/distro ?
<Tak> debian sid
<Tak> http://paste2.org/p/437125
<Tak> is basically the code
<vila> did you load the plugins ?
<Tak> bzrlib.plugin.load_plugins() â½
<vila> yes
<Tak> then yes
<vila> Tak: use cmd._setup_outf()
<vila> errr
<vila> hmm, yeah, should work better than cmd.outf = sys.stdout for roughly the same results
<vila> funnily enough I whine about that today on the ML...
<Tak> two other things: 1) I'm evaling this code from libpython  and  2) I see this error intermittently with the same arguments
<vila> Tak: well, try usin g_setup_ouf() first, then we'll see :-D
<Tak> heh, ok
<vila> What do you mean by libpython ?
<vila> you main program is ?
<Tak> I mean...not natively from python
 * Tak cough
<Tak> c#
<vila> hmm
<vila> any idea what is persistent in your env ?
<vila> between lazy_loading, encodings being cached, etc, *not* using _setup_outf().... blurry the things a lot
 * Tak nod
<Tak> I'm basically calling PyRun_SimpleString repeatedly with blocks of code, and trying to make sure everything's cleaned up with each block
<vila> Tak: also are you pulling a lot of different branches ?
<vila> wow, what do you mean by cleaning ??
<Tak> explicitly deleting instances
<vila> ha, of the blocks run you mean /
<vila> ha, of the blocks run you mean /
<vila> ?
<Tak> no, of temporary variables that get reused within the blocks
<vila> by the way, if you do: mycmd.run('lp:blah', directory='/path/to/blah') you'll be protected against changes in the command parameters
 * Tak nod
<vila> temporay like mycmd ?
<Tak> well, in other instances: mytree = workingtree.WorkingTree.open_containing('blah')[0] # like mytree
<Tak> switching to _setup_outf() eventually results in: http://paste2.org/p/437130
<Tak> maybe my whole approach is flawed
<vila> I don't understand how an import can raise such an error....
<Tak> yeah, nor I
<jam>  anyone know if bug #436467 means I should be trying to package a qbzr 0.14.3 for Windows?
<ubottu> Launchpad bug 436467 in qbzr/trunk "show log from browse inventory" [Critical,Confirmed] https://launchpad.net/bugs/436467
<jam> (still don't have packages because changing the installer icon broke the build for me, and I'm still sorting it out)
<jam> vila, Tak: import runs the script it is importing
<jam> which is why you need the "if __name__ == '__main__':" workaround if you want a script to both be importable, and runnable directly
<jam> my guess is that osutils is being lazy imported
<jam> so that you're getting a slightly strange timing issue
<vila> jam: wow... and python can't report that ?
<jam> so something is seriously weird about the traceback
<vila> or is the lazy stuff masking it ?
<jam> vila: I'm guessing the problem is in osutils.get_terminal_encoding() giving an exception, and osutils is lazy imported
<jam> I don't know why it is claiming line 425
<jam> That looks bogus to me
<vila> it's bzr-1.18
<jam> If I was guessing, this is the code that is failing:
<jam> # check encoding
<jam> try:
<jam>     codecs.lookup(output_encoding)
<jam> except LookupError:
<jam> to get that, it looks like both stdout and get_user_encoding() have to return None
<jam> though this should prevent that:
<jam> if user_encoding in (None, 'cp0', ''):
<jam>     user_encoding = 'ascii'
<jam> vila: anyway, given the final exception is consistently: TypeError: expected string or Unicode object, NoneType found
<jam> I wonder if there isn't a latent exception that he squashed but didn't clean up
<jam> I've run into that with extensions
<jam> you can accidentally leave an exception pending
<vila> "he" ?
<jam> even though you don't return NULL, or whatever to signal that an exception is coming
<jam> Tak
<Tak> hmm, I am doing some exception handling in a couple of places
<Tak> I didn't realize there was something I needed to do to "clean up"
 * Tak python noob
<Tak> what should I be doing/
<jam> PyExc_Clear()
<jam> if you are doing stuff in python lib
<jam> so if you are doing something like
<Tak> will that have adverse effects if there are no exceptions pending?
<jam> result = Py_DoSomething();
<jam> if result == NULL: # There was an exception
<jam>  # do something else
<jam> at that point you *should*
<jam> call "PyExc_Clear()"
<Tak> yeah, I'm scraping the exception output already
<jam> Tak: http://docs.python.org/c-api/intro.html#exceptions is the details
<jam> sorry, PyErr_Clear()
<jam> http://docs.python.org/c-api/exceptions.html
<jam> or specifically: http://docs.python.org/c-api/exceptions.html#PyErr_Clear
<jam> Tak: which says: "Clear the error indicator.  If the error indicator is not set, there is no effect."
<jam> so it sounds safe to do whenever you won't be propogating an exception
<jam> I forget the specific cases, but there are some Python functions that return '-1' to indicate an error
<jam> and there are some where '-1' is also a valid value, so when it returns they have to check
<jam> PyErr_Occurred()
<jam> and if you leave an exception around
<jam> that will trip accidentally
<Tak> I'm intentionally keeping my api exposure minimal
<Tak> so I'm only using PyRun_SimpleString, PyMapping_GetItemString, and one or two others
<Tak> hmm...first try didn't resolve the issue
<Stavros> hello
<Stavros> is anyone working on bzr-git here?
<jam> Stavros: I believe jelmer is the primary person working on it, though I don't think he is here right now
<Peng_> jelmer was here a few hours ago.
<Stavros> oh :/
<Stavros> i have investigated a windows bug i'd like to report, and i wouldn't want to file a duplicate
<Stavros> but i guess i'll have to
<jam> Stavros: you can certainly ask in here
<jam> but launchpad has a decent de-dup feature
<Tak> aha - a more liberal sprinkling thus far appears to have resolved it
<Stavros> jam: i searched and there aren't any that appear to be duplicates, so i can file it
<Stavros> bzr expects to find a tempfile that isn't there, and crashes
<Peng_> Stavros: Filing a dupe isn't a big deal. Don't worry about it!
<Peng_> I mean, do try to make sure you're not filing a dupe, but if it happens, it's fine.
<Peng_> It's a lot better than not filing bug reports at all.
<Stavros> Ah, thanks
<Stavros> i'll do that then
<shled> I accidently added a confidential sqlite db about 30 commits ago. How can I completely remove it from the repository?
<Lo-lan-do> shled: You'll need to uncommit, then garbage-collect.
<Lo-lan-do> Unfortunately, I don't think garbage-collection is implemented right now, so you'll have to rebuild your repository.
<Lo-lan-do> Well, depending on whether you're in a repo or in a standalone branch.
<Peng_> Ehh, rebase and/or fastimport can help you not totally destroy the last 30 revisions of history.
<shled> Lo-lan-do: that sounds like lots of work
<shled> Peng_: that sounds better
<Peng_> shled: There isn't any super-easy way out of this. It will take a bit of work.
<Lo-lan-do> shled: Not necessarily.  If it's just a single branch, the rebuilding won't be too hard.
<Peng_> Still, I think fastimport is supposed to be quite easy, once you learn how to do it.
<shled> Lo-lan-do: it is a single branch
<shled> Lo-lan-do: so what would I do exactly?
<Lo-lan-do> Try something like "bzr branch -r $goodrev $oldbranch $newbranch ; cd $newbranch ; bzr replay -r $badrev+1.. $oldbranch"
<Lo-lan-do> With $badrev=$goodrev+1=the rev where you committed the file.
<Lo-lan-do> I don't really know fastimport.
<LeoNerd> Hrm... shelve in a svn checkout really doesn't seem to work nicely when some of the changes are added files
<LeoNerd> I think I've broken it so now I can't unshelve. :/
<shled> Lo-lan-do: sweet, many thanks!
<Peng_> Lo-lan-do: Oh, that works? Nice.
<Lo-lan-do> Oh, yes, you could also do it with repeated uncommit+shelve then unshelve+commit
<Peng_> You'd lose the commit metadata.
<Lo-lan-do> Peng_: I don't know for sure, but it should.
<Lo-lan-do> Right.  replay it is, then.
<smoser> is there anythign in bzr like git-format-patch and git-am ? i'm looking for some way that i "export" a commit (or series of commits), and then import them in another bzr branch.
<smoser> i want to keep the commit messages
<Peng_> smoser: bzr send
<vila> smoser: why don't you just merge ?
<smoser> another can of worms
<Peng_> smoser: If you just want to generate a patch, "bzr send -o foo.patch", then in the other branch, "bzr merge foo.patch" (or probably "bzr pull foo.patch", I dunno)
<smoser> i'm having issues with merge due to repository format issues.
<Peng_> smoser: Transferring the revisions in another way won't change that.
<Peng_> smoser: That's easy enough to solve, though. What's going on?
<shled> Lo-lan-do: bzr: ERROR: unknown command "replay"
<Lo-lan-do> shled: It's in the bzr-rebase plugin
<shled> Lo-lan-do: Thanks!
<smoser> Peng_, well, transfering thenm in another way *should* solve that... ie, if i make a patch , copy it, change repos, patch -p0 < patch , bzr commit -m ....
<Peng_> smoser: Well, then you wouldn't be transferring the revisions themselves. Just the patch, no metadata.
<Lo-lan-do> In which case, maybe a "bzr dpush" would do the trick?
<smoser> Peng_, i dont care about metadata other than commit messages
<Peng_> smoser: Anyway, details. What are the repository formats involved? Did you "bzr upgrade" anything? Convert to rich-roots or subtrees?
<smoser> http://paste.ubuntu.com/277965/ is what shows my issue. i seem to constantly be facing issues with different archive formats on launchpad and elsewhere, and just want a way to say forget it
<Lo-lan-do> I think dpush is what you want.
<smoser> in git, i would just git-format-patch, and then on the other side git-am
<Peng_> Eh.
<Peng_> Ohhhh.
<smoser> is there just no equivalent in the bzr world ? if someone wants to send an email with a patch, and you (the bzr branch maintainer) want to say "yeah, that looks good" or even "i'd like that applied to my tree to test" is there no way to do that ?
<smoser> without sending merge metadata and dealing with archive format issues ?
<Peng_> smoser: You didn't do anything wrong, and and using a patch won't help.
<Peng_> smoser: s/and using a patch/throwing out the metadata/
<smoser> yes it would help
<Peng_> smoser: Not with the issue you pastebinned.
<smoser> i dont care about the metadata.
<Peng_> Actually, wait, no, you could downgrade. Umm.
<smoser> so i would "fix" this issue by branching from the branch that launchpad would want
<Peng_> Hmm.
<smoser> and then sending my patches to that new copy
<smoser> and then pushing
<smoser> thank you for your help.
<Peng_> The problem is that your parent branch and your branch are in one format, and LP is trying to automatically stack on a third branch for efficiency, but that branch is in a different format.
<smoser> correct. so i'm saying "forget about my branch" . other than i just want to get the 5 commits *out* of my branch in a way that is easy to pull in in another branch
<Peng_> Ideally, LP and bzr would be less dumb, and lp:~soren would upgrade lp:~soren/ec2-init/0.5 to 2a.
<Peng_> Hold on a second.
<Lo-lan-do> You could export each of the commits with bzr send and only apply the patch but not the metadata.
<soren> It would be rude to just update my branch without asking me.
<soren> Maybe I don't run a recent enough bzr.
<luks> bah, gmane is broken and doesn't let me to send a mail to the bzr ml
<smoser> Lo-lan-do, how would i do this ?
<Peng_> smoser: This should work: http://paste.pocoo.org/show/141468/
 * Peng_ hates stacking.
<Peng_> (Well, not as a concept, but the current implementation is a format minefield.)
<james_w> Peng_: thanks, but we're past that issue now, and still smoser wants to be able to do this
<james_w> Peng_: we've created two unrelated branches of the same code and are dealing with the fallout
<Lo-lan-do> smoser: "bzr send -r $rev --no-bundle -o $rev.patch" or so
<Peng_> @_@
<james_w> smoser: there is no equivalent currently
<Peng_> Peng's brain doesn't have room for technical things right now. Bye! :P
<smoser> Peng_, and then would that allow soren to easily merge ?
<james_w> wouldn't be too hard to write, but except in weird situations like this "send" is preferred
<soren> Hardly. It doesn't solve the "no common ancestry" problem.
<Peng_> Oh, hi soren!
<Peng_> soren: You should upgrade your branches to 2a! :D
<Peng_> soren: It's spiffy and cool and wrecks backwards compatibility!
<soren> You should be a salesman.
<Peng_> Mixing rich-root-pack and 2a is not a problem for merging. It's just a problem for stacking.
<smoser> git-cherry-pick and git-format-patch and git-am is just something i dont understand how you're supposed to live without
<Peng_> Eh, I have no attention span right now. I'm mostly basing what I say on the last 3 lines of conversation. :P
<smoser> Lo-lan-do, thank you. i will at least keep that around.
<soren> smoser: I use "bzr log -c <revno> -p", fwiw.
<luks> smoser: what's better about git-format-patch/git-am instead of bzr send/bzr merge?
<soren> luks: The former do not care what sort of vcs the submitter is using.
<luks> I doubt it would do something smart a bzr diff
<soren> Huh?
<luks> does git-am import the commit message from a patch generated by bzr send?
<soren> smoser: ^
<luks> er, there is missing 'with' in the line
<luks> but if you have a project in bzr, it's expectable that you work with bzr
<soren> No, it's not.
<smoser> luks, i dont know if it does from bzr send. it does from git-format-patch or git-send-email
<soren> vcs-imports on Launchpad. nuff said.
<smoser> luks, i'm *trying* to work with bzr
<soren> smoser: https://bugs.edge.launchpad.net/bzr/+bug/227340
<ubottu> Launchpad bug 227340 in bzr "Simple way to prepare patches for submission" [Wishlist,Confirmed]
<soren> smoser: You may want to subscribe to that one.
<luks> right, so it does care about the VCS the submitter is using
<luks> it must be git
<smoser> no
<smoser> its patch and a comment
<soren> luks: Eh?
<luks> with metadata
<luks> like author, date
<smoser> metadata like "From:"
<smoser> thats about it
<luks> you expect people to write those by hand?
<soren> I think it's being horribly abused in git, but I certainly do see its usefulness.
<luks> I find it weird
<smoser> you find sending emails to mailing lists wierd ?
<luks> bzr send/merge/pull is a much simpler concept
<luks> you can treat the patch as a standalone branch
<smoser> and then wanting to *use* those emails without a bunch of hassle
<soren> luks: Look, not everyone's upstreams are using bzr.
<luks> soren: why not use the project's VCS then?
<soren> luks: Because I happen to like bzr, and I can import all sorts of stuff into bzr.
<LaserJock> soren: +1
<luks> btw, there bzr send --format=git in bzr-git
<soren> I don't use bzr-git.
<luks> how do you convert the git repository to bzr?
<soren> Launchpad.
<luks> whoa, did they create another incompatible importer?
<Peng_> I think they use bzr-git.
<soren> I have no clue what they do. It's magic.
<luks> then bzr send --format=git should work
<Peng_> They have interns type it all out.
<luks> it will give you a patch with all the metadata git-am expects
<luks> so that you can use native git tools to work with it
<soren> I also occasionally receive patches from git users.
<smoser> i really didn't mean to start a dvcs war
<smoser> i promise
<smoser> drcs
<soren> I would like to import them.
<smoser> can someone maybe just help me with a simple (i think) problem.
<smoser> i have this branch, that has 4 commits on it. i'd like to export those 4 commits to some format that i can then import into another branch.
<luks> well, my point was that it's wrong trying to use bzr as if it was git
<luks> because it's not
<smoser> the other branch is in a different format (which i dont thin kshould matter)
<smoser> bzr send -r 34 --no-bundle -o -
<smoser> is what i tried.
<luks> there are different tools and methods when working with patched in bzr
<smoser> i tells me:
<luks> use bzr send without any -r argument
<smoser> bzr: ERROR: No public branch specified or known
<luks> see bzr help send for that
<Peng_> smoser: Which formats are the two branches?
<soren> luks: When we create importers for all sort of other VCS's we can't expect the upstreams to just accept bzr bundles or whatever. They should get patches or whatever in the format THEY prefer.
<james_w> it's not about formats
<luks> soren: that's why bzr-svn has send --format=svn, bzr-git has send --format=git
<luks> which produce patches in native formats
<soren> Right. I want to /IMPORT/ patches from these people as well.
<luks> bzr patch foo.patch
<james_w> but that doesn't do the metadata
<smoser> ok, i'm apparently missing something in the help, or a concept even.  because i would think that my request to 'send -r 34 --no-bundle -o -' would be a compmletelyi offline operation
<soren> luks: I'm not talking to you anymore.
<luks> james_w: neither does git-am on a bzr send patch
<luks> soren: ok :)
<soren> luks: It's pointless. You refuse there's a problem, and that's just silly.
<smoser> that woudl be very similar to 'log -3 34 -p'
<james_w> luks: please stop. I'd like to help smoser get his work done
<soren> It's bloody rude to create importers for other VCS's and be a prick about submitting patches to them and then going ahead and being a prick when they do the same onto you.
<soren> If we want to work with other VCS's, we should do so both ways. Expecting everyone else to submit the the ways of bzr is a losing battle.
<soren> And extremely arrogant.
<james_w> smoser: there is currently no way in bzr to apply a plain patch and commit it with metadata from that patch
<james_w> smoser: we can hack up a shell pipeline to approximate it
<LarstiQ> soren: it seems to me that the foreign vcs would be the way to apply their format, then pull across?
<smoser> james_w, yes, i can hack up similar shell pipeline.
<smoser> thanks.
<luks> soren: look, I regularly work with svn repositories over bzr
<luks> soren: bzr send --format=svn was created becasue of that (thanks to jelmer for finishing it)
<soren> LarstiQ: Different VCS's, different customes.
<soren> customs, I mean.
<soren> LarstiQ: git users tend to submit patches by e-mail, not by pushing a branch somewhere.
<luks> I'm not trying to be arrogant, I know what are the problems when working with a foreign VCS
<soren> I don't blame them. Pushing git trees is a hassle.
<luks> and I wrote code to support that
<LarstiQ> soren: yes, so I'd apply the patch with git, then pull to bzr, at first.
<soren> LarstiQ: That's the thing. That's quite different from how git users work.
<LarstiQ> soren: isn't that how git users integrate the work, apply the patch?
<Tak> I agree with LarstiQ - I'd have a local git branch that I used as a gateway
<soren> Take a look at lkml.
<soren> People don't usually have their own tree. They submit patches by e-mail. That's the custom.
<jam> vila: do you know what ESRCH is used for?
<jam> I don't recognize the error code, and lifeless is probably sleeping
<LarstiQ> soren: yes. So how does Linus integrate their contributions?
<vila> jam: in a kill context ?
<jam> vila: yeah
<vila> jam: I'm 80% sure it means the process doesn't exist anymore (failure during some SeaRCH)
<Tak> vila, jam: with continued use, it looks like that error is resolved - thanks for all the help
<Tak> I would never have tracked that down on my own
<vila> Tak: what was it then ?
<jam> vila: not clearing an exception that he silently squashed
<jam> doing that leads to random exceptions when some python function decides to check if an exception is pending
<smoser> LarstiQ, the difference is that linus can 'integrate' from a that patch, or from their published git repo wholescale or from theri public repo with cherry-pick
<Tak> not even that I necessarily squashed, but that possibly got squashed somewhere in library code
<smoser> (and cherry-pick does the commit, it doesn't just leave you there having to do it yourself)
<LarstiQ> smoser: ok, so why not do the same, and then bzr pull from the resulting git branches?
<smoser> the difference is that there is no option (as far as I can tell) to take a commit from an email
<smoser> with metadata without by-hand or shell scripting
<LarstiQ> ok
<smoser> its an extremely simple work flow that works for lots of things.
<smoser> i open up my email program, type a 'To', 'Subject:' describe a set of changes in a patch (ie write the commit messgae), and then append the patch.
<smoser> and you just say 'git-am < mbox' to apply it
<james_w> (not that we will copy the git-am interface, it's one of the most unpleasant things I've ever used)
<jam> smoser: so *if* you are using bzr bundles 'bzr merge' just works, and if you are using patches 'bzr patch' will apply the data, but not the commit message.
<jam> One possibility is to try to recognize the git "patch+" format as another bundle format
<jam> so that you can use 'bzr merge' if in a slightly lossy fashion
<Tak> that seems like the most sensible option
<jam> It is probably non-trivial
<jam> and if done
<jam> it would be probably first implemented in bzr-git
<Tak> either that or extend `bzr patch` in bzr-git the same way that `bzr send` was extended
 * Tak nod
<jam> and if I read the traceback correctly smoser didn't want to install bzrgit
<jam> etc
<smoser> i have no problem with bzr git
<vila> jam: is there a way to display the working tree revid from the command line ?
<jam> vila, igc: \o/ windows installers finally worked out, and being uploaded now
<jam> vila: not the wt
<vila> jam: thks
<sidnei> jam: congrats!
<jam> though I thought fullermd was trying to fix stuff like 'bzr revision-info' to add a '--tree' option
<vila> bug # ?
<jam> vila: it has been merged
<jam> 'bzr revision-info --tree'
<jam> $ bzr revision-info --tree
<jam> 4683 john@arbash-meinel.com-20090924221525-5vezfwzai1d2ajnn
<vila> excellent, thanks
<jam> vila: landed in bzr 1.17 in fact
<jam> well, at least according to NEWS
<vila> Never needed it...
<vila> ..and didn't grepped it when doing bzr revision-info --help :-/
<vila> jam: congrats for the installers !!! (Missed that one :D)
<jam> vila: I think you mean 'grok' it
<vila> vila: thanks, but I meant that I didn't *see* it at all
 * zsquareplusc is waiting for 2.0.0 for windoze
<fullermd> Yeah, I added it to rev-info and revno.  The only places that looked likely...
<Lo-lan-do> Is there a way to know if a repo contains ghost revisions faster than a bzr check?
<james_w> Lo-lan-do: I'd reach for "python -c", why do you need to know?
<Lo-lan-do> james_w: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538056
<ubottu> Debian bug 538056 in bzr "bzr: push should (optionally) push ghosts" [Wishlist,Open]
<Lo-lan-do> I'd like to be sure the bzr branches I provide are complete.
<james_w> ah
<james_w> I'm not sure of any other command that can tell you I'm afraid
<Lo-lan-do> I'm currently pushing into a fresh repo on the server, from which I'll "bzr fetch-ghosts", but it's a bit meh.
<Lo-lan-do> (Largeish repo and ADSL)
<garyvdm> Hi all
<garyvdm> jam: please will you take a look a https://code.edge.launchpad.net/~garyvdm/bzr/get_trees_and_branches_to_diff/+merge/12341
<garyvdm> jam: it's to fix a bug you loged :-)
<garyvdm> Hi vila
<vila> hey gary :D
<garyvdm> err - just been summoned for dinner, bbl
<vila> lol at garyvdm, but daughters are likely to do the same quickly :D
<zsquareplusc> bzr branch using a bzr+ssh URL (Windows cmd) it says "command-line: line 0: Bad configuration option: ClearAllForwardings" followed by a connection closed error. can someome translate this error from "techincal" to "english"?
<LarstiQ> zsquareplusc: what ssh client is that using?
<zsquareplusc> i dont know. i hope paramiko that was installed with the BZR windows standalone setup
<zsquareplusc> hm, i see just launching bzr explorer gives the same error
<luks> what version of bzr?
<Peng_> That's one of the args bzr passes when running OpenSSH.
<luks> https://bugs.launchpad.net/bzr/+bug/47414
<ubottu> Launchpad bug 47414 in bzr "sftp doesn't work on windows" [Medium,Fix released]
<luks> oops, that's from 2006
<luks> ignore that :)
<zsquareplusc> oh no, my last comment was wron, explorer gives no warning
<zsquareplusc> it is the 2.0.0 release i'm using. though i had the same error with 1.16 (which i deinstalled)
<luks> do you have cygwin or something in %PATH%?
<zsquareplusc> yes
<jam> zsquareplusc: given that I just uploaded it... 10 minutes ago, did you already download it?
<zsquareplusc> jam yes, jam :-)
<jam> Do you have an 'ssh.exe' somewhere on your path?
<luks> try with "set BZR_SSH=paramiko"
<jam> It looks like a case where someone may have renamed "putty.exe" to "ssh.exe"
<jam> and then bzr is trying to interact with a putty executable as though it was an OpenSSH one
<jam> alternatively, there is another SSH implementation out there, can't remember the name off hand
<jam> as mentioned, I would recommend "set BZR_SSH=paramiko"
<jam> which should be bundled with the installer
<zsquareplusc> there is a ssh.exe (openssh). maybe from mingw
<jam> zsquareplusc: well, if you have an ssh.exe around we will default to using it
<Peng_> bzr does check "ssh --version", no?
<luks> is there a bazaar.conf option for BZR_SSH?
<jam> though if it was openssh it should support "ClearAllForwardings"
<jam> luks: no
<jam> you can set the global env var
<zsquareplusc> ok it works when i set BZR_SSH thanks
<luks> hm, something like this could be configurable in qconfig
<jam> My Computer / Properties / Advanced System Settings / Environment Variables / New... user variable
<luks> yeah, but that's not as nice
<zsquareplusc> jam: using an existing ssh is probably the best thing on every OS except windows. i don't know if it is a good idea there.
<jam> zsquareplusc: the main issue is that 'it depends'
<jam> because if you have ssh.exe on your path, it is 'somewhat' likely that you have it configured
<maxb> Have the columns in "bzr viz" ever been dynamically resizable? I thought they were, but they don't seem to be now.
<jam> maxb: I think they are, but there are limits. And IIRC if you have a very wide graph, it pushes everything to their limits and then you can't adjust it
<jam> maxb: (I might recommend 'bzr qlog' instead...)
<maxb> I have a very thin graph, and I can't see the tags
<zsquareplusc> well if the error would at least somehow indicate that the problem happened when executing an external "ssh" i would have been so puzzled
<maxb> and it doesn't seem to want to let me resize anything at al
<jam> zsquareplusc: we've certainly talked about disabling the ssh.exe check on Windows, and instead having the user "set BZR_SSH=ssh" manually if they want it
<jam> just trying to find the right balance
<jam> leaning towards it, though
<zsquareplusc> i would agree. well at least i was expecting that it is using the bundled ssh client. anyway i've made a bug report
<Peng_> You can check the SSH client being used in .bzr.log.
<zsquareplusc> if you knew that file file exists and where it is located
<garyvdm> jam: Thanks for doing the review :-)
<Peng_> zsquareplusc: "bzr version" will tell you.
<beuno> jelmer, ping
<beuno> do you happen to know anything about this: http://launchpadlibrarian.net/32430314/opensim-new-trunk-log.txt
<james_w> beuno: that looks like a difference between path names that git will store and those that bzr will store
<james_w> I think part of the reason is that the serialiser doesn't or can't escape some of the things that it should
<james_w> but there's also a question of whether you should e.g. store paths that you can't create on ntfs
<beuno> right
<rubic> looking for docs to upgrade repository format from 1.x to 2.0
<beuno> rubic, bzr check && bzr reconcile && bzr upgrade
<beuno> that should do the trick
<mzz> http://doc.bazaar-vcs.org/latest/en/upgrade-guide/index.html if you want a document but it's pretty much that
<rubic> beuno: mzz: thanks
<jam> beuno: for your traceback, I'm pretty sure that is a filename that has a literal '\' character in it
<jam> and currently bzrlib refuses to allow you to add files with '\'
<barry> hi all.  i have a (hopefully) quick question about read locks.  i'm trying to update setuptoolsbzr to bzr 2.0 but something that was working earlier is now failing with an ObjectNotLocked error
<barry> here's what the code does:
<barry>     # Open an existing branch which contains the url.
<barry>     branch, inpath = Branch.open_containing(path)
<barry>     # Get the inventory of the branch's last revision.
<barry>     inv = branch.repository.get_revision_inventory(branch.last_revision())
<barry>     # Get the inventory entry for the path.
<barry>     entry = inv[inv.path2id(path)]
<barry>  
<jam> barry: as soon as you open something, you should probably do 'lock_read()'
<jam> and put the rest of the code into a try/finally and unlock at the end
<jam> unless you will be writing to it
<barry> jam: nope, i'm just reading from it
<barry> jam: is where is lock_read() and how do i unlock?
<jam> barry: lock_read() basically sets the lifetime for caching
<jam> branch.lock_read()
<jam> branch.unlock)(
<jam> branch.unlock()
<barry> jam: super, thanks!  let me try that...
<jam> so if you did "for x in range(10): branch.last_revision()"
<jam> if it is locked, we read the remote file 1 time
<jam> if it isn't
<jam> we read it 10 times
<jam> we used to have more of our api have @needs_read_lock() which auto-locked for us
<jam> but that ends up just letting people write things that perform poorly
<jam> because it doesn't maintain the cache
<jam> between calls
<barry> jam: that makes sense
<jam> note that the lock_read() calls have always been supported
<jam> so it works with older bzr versions
<barry> jam: excellent, i was going to ask about that
<jam> we just weren't as likely to complain when you didn't
<barry> jam: so i was getting away with things by being lazy :)
<barry> AttributeError: 'BzrBranch6' object has no attribute 'lock'
<barry>  
<fullermd> Laziness is a virtue.
<barry> jam: am i doing the right thing by calling .lock() on the first item in the tuple returned by Branch.open_containing() ?
<jam> barry: 'lock_read()'
<jam> (vs lock_write())
<jam> not just "lock()"
<barry> jam: gah!  i r an idiot
<ronny> bw, what is lock()
<jam> ronny: there is no plain 'lock()'
<jam> hence the 'AttributeError"
<ronny> oh, i see
<ronny> i suppose i could use some rest
<barry> jam: thanks!  worked like a charm
<jam> barry: great to hear
<Stavros> hello
<Stavros> how do you guys debug bzr?
<Stavros> which debugger do you use?
<luks> I guess most people just print some debug info, or use pdb.set_trace()
<Stavros> luks: i tried pdb, but it crashes bzr
<garyvdm> stavros: pastebin the error
<Stavros> http://dpaste.com/98287/
<garyvdm> stavros: I use komodo, but I can't get it to break on raise, so then I use pdb.
<Stavros> garyvdm: how do you get komodo to start debugging? a breakpoint will work, but i couldn't get it to work
<garyvdm> stavros: set break point, run with bzr as the script.
<Stavros> garyvdm: tried that, no dice :/
<garyvdm> stavros: run bzr --version from komodo, and make sure the bzrlib is where you think it is.
<Stavros> let me try again
<Stavros> ah, let me try that
<garyvdm> stavros: what is bdb? Have you tried with pdb?
<Stavros> ah, version does run
<Stavros> garyvdm: i was trying with pdb, no idea what bdb is
<Stavros> oh, debugging worked now
<Stavros> odd
<Stavros> what the hell, it worked in the debugger
<Stavros> damn, i hate nondeterminism in programs
<Stavros> who is the maintainer of bzr-git?
<fullermd> No, who's on first.
<dsuch> Martin Torvalds?
<dsuch> sorry, couldn't resist :)
<garyvdm> Stavros: I believe jelmer is the author and maintainer of bzr-git.
<garyvdm> dsuch - Took me a while to catch that...
<Stavros> ah, he's away :/
<fullermd> Yeah, you might THINK that...   that's how he catches you.
<Stavros> haha
<Stavros> i think i've gotten pretty far with the debugging
<Stavros> unfortunately, i have no clue what i'm doing
<Stavros> so i need his help
<Stavros> i have to go now, though
<Stavros> later all
<Stavros> thanks for your help
<der|> hello, when you use bzr revert, it generates some files like  x.~1~, etc. Is there a bzr command that removes those ?
<jderose> der|: bzr clean-tree --detritus
<jderose> see bzr help clean-tree
<der|> jderose, got it, thanks
<jderose> np
<Meths> Also bzr revert --no-backup so they aren't created in the first place
<vila> garyvdm: do you have pqm access ?
<jderose> Meths: hmm, i didn't know about that option, nice
<garyvdm> vila: No. I believe I need to ask lifeless, with a gpg key.
<vila> garyvdm: send him  a mail then and welcome :)
<vila> fullermd: nasty comment on that bug :D Afraid we can forgot ?
<garyvdm> vila: I'm confused by what you said.
<vila> garyvdm: let's talk to clarify that, I ahd enough misunderstandings today ;)
<awilkins1> Bah, bzr-explorer things lightweight checkouts are their parent branch
<fullermd> Hm?  What bug?
<fullermd> Oh, you mean the checkout thing?
<vila> fullermd: yup :D
<vila> fullermd: at least it seems I didn't say anything wronger :D
<garyvdm> vila: I just started on a threaded version of qbzr :-0
<fullermd> Hm.  I didn't mean nasty per se.
<fullermd> But your statement DID seem a little like it was saying "that's not a bug, that's just how it works".
<fullermd> The two aren't mututally exclusive   :>
<vila> fullermd: oh, good point, I didn't mean that, thanks for clarifying that
<vila> In fact I refrain to add that we plan to rework the way checkouts works
<vila> I refrained
<vila> work
<vila> gha
<fullermd> Tpying is hrad.
<LarstiQ> but jokes comes easy to the fullermd
<LarstiQ> or seemingly
<dsuch> garyvdm: yea, I was visiting launchpad.net/bzr five seconds prior to that
<fullermd> Yeah, I just wink at 'em and they fall all over me.
<jam> 2.0.0-2-setup.exe is available
<jam> includes updated chm files
<jam> (2.0.0 docs rather than 2.0rc2 docs.)
<lifeless> mthaddon: I think it should be fine as long as we stay on 2.4; our advertised support is '2.4' not 'dapper'
<lifeless> mthaddon: if you could please take a backup of the dapper state, in case we change our mind :P
<fullermd> lifeless: Hey, I wanted to run something by you...
<lifeless> poolie: sysadmins would like to move the pqm chroot to hardy; will still be python2.4. I ack'd and asked for a back up in case you disagreed. Do you ?
<poolie> hi lifeless
<poolie> good with me
<poolie> and good timing too
<lifeless> mthaddon: don't worry about that backup :P
<fullermd> Re: bug 430672 (and the dupe filed today)
<lifeless> poolie: thanks
<ubottu> Launchpad bug 430672 in bzr "Crash when renaming a directory" [High,Confirmed] https://launchpad.net/bugs/430672
<fullermd> This seems pretty easy to trigger, and it leaves you in an ugly state afterward.
<jam> hi poolie, lifeless
<jam> I was just about to head out
<lifeless> hi jam
<fullermd> I feel like it should probably be made Critical, but I don't feel comfortable making that strong a statement.
<jam> poolie: bzr-2.0.0-2-setup.exe is available
<poolie> hi jam, i'm not going to stay on for long either
<poolie> thanks for the builds
<lifeless> fullermd: yes
<lifeless> fullermd: so frequency of impact say it doesn't happen to a large % of our users.
<lifeless> fullermd: I think its high
<lifeless> fullermd: does it fail check?
<poolie> i wondered if anyone would reply about uifactories :)
<fullermd> No, but it does move the file and then lose track of it.
<lifeless> recovering from a clean dirstate is easier than a corrupt on
<lifeless> I think this is very important but straightforward to deal with, with a low incident rate, thus high
<fullermd> Fair enough.
<fullermd> (this of course is why I don't permit myself to judge Critical  :p)
<lifeless> fullermd: ;)
<lifeless> fullermd: one reason to be slightly more careful with critical is that there is confusion about whether it == release-blocker
<lifeless> its not /labelled/ release-critical; but opinions vary. And expectations too.
<fullermd> Yah, that's a source of my concern.
<fullermd> I'm neither doing the work, nor managing the release, so making declarations about work needed for the release is slightly hubristic.
<fullermd> I mean, even by MY standards.
<lifeless> but even if it clearly-unambiguously didn't mean 'block'
<lifeless> I'd still only label this high, by our guidelines
<zsquareplusc> when i committed after a merge it told something about pending merges in the text below, do i have to do something special now? merging again just says "nothing to do"
<fullermd> zsquareplusc: No, that's informative; like the list of files, it's tell you what you're committing.
<zsquareplusc> yup, it's just that "pending merges" that was new for me.
#bzr 2009-09-26
<enigma42> Hm...I ran into a strange bzr-svn error.
<enigma42> It's throwing out stack trace.
<enigma42> bzr-svn 0.6.5
<jelmer> enigma42: please file a bug
<enigma42> OK
<enigma42> Oh...should I try 1.00 first?
<jelmer> enigma42: probably
<enigma42> How much of a difference is there between 0.6.5 and 1.0?
<enigma42> OK.
<enigma42> Oh...another quick question...
<enigma42> How do I clear the svn cache now that it's using sqlite
<enigma42> ?
<jelmer> enigma42: it's always been sqlite :-)
<enigma42> Oh. Where did the cache move to?
<jelmer> enigma42: ~/.bzaar/svn-cache ~/.cache/bazaar/svn
<enigma42> Oh...OK.
<jelmer> either of thoes locations
<zsquareplusc> is there a bzr command to remove a remote branch? (bzr+ssh URL)
<enigma42> jelmer: I'm curious, where does the svn repo ID come from? Such as: daff2dd8-1c3d-0410-9cd2-f6297dd8f964
<enigma42> Does subversion generate that itself?
<enigma42> I've noticed that bzr-svn always seems to come up with the same ID no matter which machine
<enigma42> So long as I'm pointing to the same repo.
<lifeless> svn has a GUID repository ID
<jelmer> enigma42: yeah, svn generates it itself
<meoblast001> lifeless: i just wanted to tell you i think i got everything straighted out
<meoblast001> i'm making a backup copy of the old branch just in case
<meoblast001> scratch that, getting errors
<meoblast001> http://codepad.org/3P2U2cGQ
<enigma42> jelmer: https://bugs.launchpad.net/bzr-svn/+bug/436971
<ubottu> Launchpad bug 436971 in bzr-svn "NoSuchRevision error when trying push a new branch into branches directory for the project in subversion" [Undecided,New]
<enigma42> it just affects a couple of my projects.
<enigma42> We have about 70+ projects using trunk1 layout.
<enigma42> But just a couple of them get this error when I try to push a new branch into /project/branches
<meoblast001> is that because i init'd a new branch on my system and imported my stream into it?
<enigma42> Cooincidentally, only the problematic projects have been used with bzr-svn since the dawn of time. I'm wondering if it's an old metadata problem.
<meoblast001> how do i make these repositories compatible
<meoblast001> i have a stream of my branch, so all i have to do to create a new branch with the contents of this one is init it and then import it
<fullermd> Those two in particular?  You don't.  Working across a rich root divide isn't practical.  You'd have to switch one or the other.
<meoblast001> what do you mean?
<fullermd> Revisions with rich root info can't be put into a repository with an impoverished-root format.
<meoblast001> what is rich root and impoverished root?
<fullermd> (in this case specifically, 2a is the trigger pull; it's the first default format that's rich-root.  Previous rr formats were all non-default choices)
<meoblast001> oh, you mean because i have bzr 2.x and my old repository was 1.x?
<fullermd> Well, impoverished root is just my term, 'cuz I feel silly typing 'non-rich-root' or variants of it all the time...
<fullermd> Any opportunity to play games with language.
<meoblast001> well, how do i make an impoverished root branch?
<fullermd> Specifically, your 'old' repository is in a non-rr format.  So you'd have to use one compatible with that (something like 1.9, say).
<meoblast001> so i have to install Bazaar 1.9?
<fullermd> Alternately, upgrade the poor branch to a rr capable format; that's the future.
<meoblast001> but 2.x is still in RC
<fullermd> No, just use --format=1.9.
<meoblast001> so bzr init --format=1.9?
<fullermd> Sure, but there've been rr formats back as far as bzr 1.0 (rich-root-pack), and rr versions of every format since.
<fullermd> It's just with 2 that the _default_ starts being rr.
<fullermd> Yah.
<meoblast001> ok
<meoblast001> i can upgrade to rich-root later without causing problems, right?
<fullermd> Yeah, that way works fine.  It's going the other way that doesn't.
<fullermd> (rich root stores strictly more information, so trying to go the other way would be throwing things away)
<meoblast001> yes, but throwing away useless information
<meoblast001> i want to upgrade when everything is for sure stable
<meoblast001> i'm a little cautious
<fullermd> No, it's not useless information.
<meoblast001> oh, i heard it was :/
<fullermd> And throwing it away would mean you now had two versions of the same revision out there.  That's a serious no-no.
<meoblast001> i heard instead of saving whole lines in the differences, it would only store character changes
<fullermd> No, it's nothing like that.
<fullermd> And that change wouldn't be incompatible anyway, as long as it assembled the same text in the end.
<fullermd> Specifically, the different is that rich root formats store an identity for the root of the tree.  Poor roots don't.
<mzz> http://doc.bazaar-vcs.org/latest/en/upgrade-guide/index.html says I should "unset the current trunk from being the development focus" in launchpad. Where's the control for that? I can find a way to set a different development focus, but not to unset it completely.
<wgrant> mzz: You unset the branch from the series, not the series from the development focus.
<wgrant> mzz: https://launchpad.net/PROJECT/SERIES/+edit
<mzz> wgrant: and set "Branch" to the empty string there?
<wgrant> mzz: Probably.
 * mzz tries
<mzz> ok, that did something, let's see if the rest of the steps work
<mzz> does it make sense to just delete ~me/project/trunk and re-push it from scratch?
<mzz> no, wait
<mzz> I should push a new one just in case anyone stacked on the old branch. Bleh, naming. migrated-trunk?
<wgrant> You can't delete the old one if anything is stacked on it.
<SamB_XP> wgrant: oh, that's nice!
<SamB_XP> what happens if you try it from the command line ?
<mzz> wgrant: ah, so if launchpad lets me I won't really inconvenience anyone by doing it?
<wgrant> mzz: Well, unless they have local stacked branches, in which case they're insane.
<SamB_XP> indeed
<SamB_XP> what if they lost connectivity for a time?
<mzz> well, this *is* a pretty insane project, but I seriously doubt anyone branched off it at all, let alone stack on top of it
 * mzz smites the branch
<wgrant> SamB_XP: Or if they want to do anything even slightly unslowly.
<SamB_XP> wgrant: yes, or that
<SamB_XP> it's about as insane as doing a lightweight checkout from launchpad or SVN
<mzz> hey, I just did that
<mzz> (to look at a file, I didn't need any history)
<mzz> ok, this seems to have worked
<mzz> let me do the same delete and fresh push on my two +junk branches
<SamB_XP> mzz: if I wanted to look at just one file, I'd probably just use loggerhead or the HTTP URL ...
<SamB_XP> ... if I could figure out what the latter was
<SamB_XP> since I clearly can't type lp:foo in my browser's URL bar
<mzz> SamB_XP: I was already on the commandline, not a browser. Typing "bzr co lp:whatever" and feeding the file to less was faster than switching to a browser and navigating through loggerhead
<SamB_XP> mzz: oh, that defaults to --lightweight now?
<mzz> (I have co aliased to checkout --lightweight)
<SamB_XP> oh
<mzz> I have a probably slightly odd setup where most of my code lives in no-trees repositories on a fileserver on my lan, while I work in local lightweight checkouts of those
<SamB_XP> mzz: that's a bit less dumb
<mzz> thanks? :)
<SamB_XP> I sometimes work in directories that are themselves on a fileserver
<SamB_XP> well, it's an NFS server, really
<SamB_XP> and something about the setup makes the time to access a file pretty high ...
<SamB_XP> I mean, if you untar something it can take quite a while
<mzz> this setup is usually fast enough, and if it isn't I can always do a full local branch
<mzz> advantage is that I can't forget to push changes off my desktop onto the fileserver so they're accessible remotely when the desktop is off
<fullermd> ...  computers turn off?
<mzz> my fileserver doesn't
<SamB_XP> someone keeps turning off the print server here ...
<mzz> my desktop occasionally does
<SamB_XP> ... might be something to do with the fact that it runs windows 98 ...
<mzz> hah
 * mzz is upgrading all his stuff to 2a while simultaneously clearing out cruft
<mzz> apparently I have a lot of that
<Peng_> I keep my server on the latest formats and relatively clean, but my PC is a huge mess of formats. :D
<RenatoSilva> Is it common to develop oriented to bugs? I mean, every change you developer want to do, you register a bug before that, making every or many commits having a bug id assigned?
<fullermd> That sounds like a "community standards" question.
<RenatoSilva> fullermd: mine?
<fullermd> Yeah.
<RenatoSilva> fullermd: I think I'll do that only for important bugs, even though it's not possible to tell launchpad since what milestone the bug applies
<RenatoSilva> thansk anyway!
<fullermd> Oh, see, now you're trending toward one of the two Great Unanswerable Questions.
<fullermd> (1) What is the meaning of life?
<fullermd> (2) Is it possible to make a bug tracker that doesn't suck?
<fullermd> (obviously, of course, the answers are "chocolate" and "no".  But I haven't figured out for sure which answer goes to which question yet.)
<RenatoSilva> chocolate means you're fat?
<RenatoSilva> and lp's bugtracker does not suck
<fullermd> I've known plenty of rail-thin people who understood the preeminence of chocolate over everything else...
<RenatoSilva> and?
<fullermd> All bugtrackers suck.  They just suck in different ways.
 * RenatoSilva suffers of /clearing-screen-all-the-time syndrom and didn't read last message
<RenatoSilva> fullermd: I think when I release the targeted milestone 'next-release' (I use date-based versions) that info will stay on the bug. So the bug affects at least the prior milestone
<jderose> bzr sattus
<jderose> bzr diff
<jderose> hehe, crap, wrong window  ;)
<meoblast001> is 725.3 KB a good file size for the .bzr directory on a 70 commit project?
<mzz> that doesn't sound completely insane
<mzz> wh?
<mzz> why, even?
<Peng_> meoblast001: Is this the one that had 10 MB of binaries?
<meoblast001> yup :)
<meoblast001> i think i cleaned it up a bit
<meoblast001> Peng_: do you think it is good?
<Peng_> Sure, why not?
<Peng_> I don't have any actual studies to say how good that is for a project of its size, but it's not a significant amount of data unless you're on dial-up, so at that point, who cares?
<Peng_> s/studies/data/ -- don't have to be *that* scientific
<Peng_> meoblast001: What disk format?
<meoblast001> SATA?
<meoblast001> or EXT3
<Peng_> meoblast001: I mean bzr repository format.
<meoblast001> 1.9
<Peng_> 2a will be smaller. And faster and just generally cooler.
<meoblast001> i will upgradt to 2a soon
<Peng_> :D
<rsvp> can the new BAZAAR v2.0 write to the older formats? (assuming it can convert to the new 2a format, right?) -- must everyone on a team use the same bzr version?
<Peng_> rsvp: Bazaar 2.0 didn't drop any of the old formats.
<Peng_> rsvp: You don't even have to convert or anything. (Though you should. 2a rocks!)
<rsvp> Peng_, thanks for your response -- just want to make sure to confirm answers over at #python.
<AfC> rsvp: no, everyone on a team does not need to use the same bzr version.
<rsvp> AfC, thanks --
<AfC> rsvp: they just need to all be using a version that supports whatever format the team repo is in. Just the usual lowest common denominator thing.
<AfC> rsvp: though you will accrue much greatness that lowest common denominator is 2a. It'll be worth pushing for (ie, getting people onto newer code as fast as possible, rather than lallygagging) because that format will be extant for the foreseeable future but of course bzr versions >= 2.0 will improve in other ways but building on that base.
<rsvp> I've been upgrading using Ubuntu repository, but to upgrade via "bzrÂ branchÂ lp:bzrÂ bzr.dev" from which directory should that be issued (sudo bash first)?
<mzz> you mentioning sudo there scares me
<AfC> rsvp: the PPA at https://launchpad.net/~bzr/+archive/ppa should always have the latest bzr release. Can you use that?
<mzz> what are you trying to do?
<mzz> if you're just trying to run a recent version of bzr use that ppa
<rsvp> mzz, I want to install v2 from source.
<mzz> why?
<mzz> to just install v2 just use that ppa
<rsvp> ok
<mdz> jml, thumper, anyone around?
<mdz> I need help with a branch incompatibility issue
<lifeless> mdz: 'sup?
<jelmer> Lo-lan-do: ping
<Lo-lan-do> pong
 * Lo-lan-do highlights jelmer
<jelmer> Lo-lan-do: Sorry, was wondering whether a particular bug was fixed
<jelmer> Lo-lan-do: but it seems your patches already took care of that
<Lo-lan-do> Which one?
<Meths> The Windows downloads show bzr-2.0.0-2-setup.exe and bzr-2.0.0-1-win32.py2.6.exe.  Is there a -2-win32 file being built or was the -2-setup only produced to fix an error in the setup file and the py2.6 file is perfectly okay to use?
<emmajane> igc, ping?
<awilkins> Meths: The -setup is an encapsulated py2exe applications, with it's own libraries and pre-installed plugins
<awilkins> Meths: The python variants have no plugins and require python of the quoted version installed ; they are more suitable for someone who has more intensive plugin needs, or needs to configure a smart webserver.
<Lo-lan-do> Shouldn't the topic mention that 2.0 is *released* now (rather than frozen)?
<emmajane> igc, not sure if you're still up, but I'm headed out for breakfast if you want to try the merge. if not I'll look at it later this afternoon.
<dash> congrats on the 2.0 release :)
<dash> I am trying to upgrade Twisted's bzr repo to 2a, but it's hosted on a low-memory box, and it didn't complete before being killed
<dash> is there a way to do the upgrade incrementally or should I just try again on a box with better specs and copy it?
<Lo-lan-do> dash: (From a not-too-involved bystander) You may try using a swap file first.
<dash> mmh... yeah. this is a kind of small VM
<Lo-lan-do> My feeling is that bzr uses lots of memory, but not necessarily repeatedly, and the actual accesses feel like they're mostly local and not all around.
<dash> maybe that'd work. can't say it excites me :)
<Lo-lan-do> So maybe swapping won't be a performance killer.
<meoblast001> hi
 * SamB_XP has a feeling he's seen meoblast001 somewhere before 
<meoblast001> yes you have
<meoblast001> i'm the guy who constantly fears he's doing something inefficient
 * awilkins just increased the execution time of a unit test in his project by 80% - he's definitely doing something inefficient
<meoblast001> ok, so i just moved about a 25 line group of contiguous data up a few lines in one of my headers, is bazaar optimized to do this efficiently?
<meoblast001> or does it just basically memorize "delete these 25 lines here, add these 25 lines here"
<SamB_XP> awilkins: without changing the test, you mean?
<awilkins> SamB_XP: I changed the code that's it's testing
<awilkins> SamB_XP: I didn't think it would be that much of a change... but clearly I was wrong
<awilkins> SamB_XP: Now I'm struggling to get the profiler installed in Eclipse because the update site is sooooo slow.
<SamB_XP> what profiler would that be ?
<awilkins> TPTP
<SamB_XP> ... and why the heck would eclipse only have one update mirror ?
<awilkins> SamB_XP: I suppose I could hunt for update mirrors.... what it needs is a way of switching between them automatically because lazy people like me are going to just check the box and hit gi
<awilkins> go
<SamB_XP> awilkins: what, no dialog with a list of 'em ?
<awilkins> The update system has a list of update sites, but not a list of mirrors of update sites
<awilkins> Even the eclipse.org site is as slow as molasses today
<awilkins> So it's hard to find a list of mirrors :-(
<LarstiQ> meoblast001: I wouldn't worry about it
<meoblast001> ok
<awilkins> It probably would remember something like that... but the group compression will probably catch that the two blocks are identical and reduce them to one object
 * awilkins dances on "probablies"
<SamB_XP> meoblast001: that's a tiny change anyway ...
<SamB_XP> unless the lines are gigantic!
<meoblast001> yeah, but it's only to make things conform with the coding standards
<SamB_XP> I mean, as disk usage goes
 * SamB_XP wants a dilbert tie ...
<SamB_XP> ... you know, gravity-defying ;-P
<SamB_XP> ... I guess if I managed to get one, I could study it and maybe win a nobel prize
<meoblast001> SamB_XP: do you have coding standards with any of your projects?
<SamB_XP> meoblast001: well, yeah
<SamB_XP> a few
<meoblast001> do you strictly enforce them
<meoblast001> like, if you find something doesn't conform, do you fix it?
<SamB_XP> er, well, they aren't really *my* projects
<meoblast001> oh, ok
<SamB_XP> at this point, I mostly work on other people's open source projects
<SamB_XP> some of them have coding standards
<meoblast001> oh, well, do you find it normal to strictly enforce those standards?
<SamB_XP> some more strict than others
<meoblast001> and clean up parts that don't follow them
<SamB_XP> well, I guess it would depend on a few things
<awilkins> The anal tension of the project lead, first and foremost
<SamB_XP> some of those standards are generally pretty strict
<SamB_XP> awilkins: well, with the less typographical standards, it may even depend on what makes more sense in the particular case
<meoblast001> i don't think mine is too strict, but it has gotten a little more strict since i created it
<SamB_XP> meoblast001: what specifically are you thinking about ?
<meoblast001> what do you mean? what i'm fixing?
<SamB_XP> I mean, what ... requirements of the standard have you tightened up on ?
<SamB_XP> ... oh, it also can depend on whether anyone has time to fix the violation ;-)
<meoblast001> i'm fixing the violation :P
<meoblast001> here's my standards http://mysticgalaxies.com/wiki/index.php/Coding_Standards
<meoblast001> but yes, i have tightened up a little so that things can be a little more consistent, and now i'm trying to fix it
<SamB_XP> http://mysticgalaxies.com/wiki/index.php/Coding_Standards you say ...
<meoblast001> yes
<SamB> yeah, I just repeated it so I could open it on this computer ;-)
<meoblast001> ah, ok :P
<meoblast001> brb, breakfast
<SamB> meoblast001: huh, I would call it "two space indents", given that you (wisely) require spaces rather than tabs be used for indentation ;-)
<SamB> weird requirement on the call-parens ...
<SamB> and calling access specifiers a level sounds weird, too -- I don't know if many editors can handle that
<awilkins> One problem I have with coding standards is the mess they make of version histories when someone has a mass-enforcement session....
<SamB> awilkins: yeah
<SamB> meoblast001: oh, and I'm fairly certain that "proceed" is not the opposite of "precede" -- you probably meant "succeed" ;-P
 * awilkins blinks    - he just managed to totally change the performance again, now it's more than 400% of it's previous execution time
<LarstiQ> SamB: acccess specifiers as a level is the default afaik?
<SamB> LarstiQ: I think emacs usually indents them between actual levels?
<awilkins> Somehow I went from 31s to 49s to 130s ... I think it's all down to object boxing....
<LarstiQ> awilkins: cricket is a much more civil sport
<meoblast001> SamB: hm, you know what, you may be right
<meoblast001> SamB: English is my native language but i always have trouble finding the right word when i'm writing a formal document
<meoblast001> "following" was the word i was looking for
<meoblast001> SamB: would you recommend i update my code to conform with it though? i suppose it's for the best
<meoblast001> i suppose my fear is that if i let myself fix everything my OCD tells me to, before you know it i'll have a 60 GB branch and more commits than 32-bit possible
<idnar> pfft, that's what 64-bit is for
<meoblast001> am i freaking out way too much?
<SamB> meoblast001: how big is your project?
<SamB> and probably you are indeed worrying too much
<meoblast001> big as in commits?
<SamB> big as in lines of code
<meoblast001> let me go check
<meoblast001> SamB: http://www.ohloh.net/p/amethyst-mm/analyses/latest
<meoblast001> 2000 lines of C++
<awilkins> Teenytiny
<SamB> indeed
<awilkins> Let me see
<SamB> and C++ needs quite a bit of wrangling
<meoblast001> wrangling?
<meoblast001> yes, it is very small
<meoblast001> this project started in March
<SamB> it's very badly behaved ;-P
<meoblast001> my .bzr directory totals 724.7 KB
<SamB> however, I think in future you may want to add more substantive things to your coding standard ;-)
<meoblast001> substantive?
<SamB> you know, things about what code should and should not *do*
<meoblast001> oh, why's that?
<meoblast001> well, what kinds of things could that be
<meoblast001> don't set an unsigned integer to a negative number?
 * awilkins has 22k lines of Java which is 1.7MB of code in a branch that's 14MB of packs
<SamB> oh, I don't know
<meoblast001> what's a good ratio of repository_size:commits
<awilkins> And most of that 14MB is java libraries that I committed to the branch before I removed them and went all Maven on it's ass
<SamB> meoblast001: well, it depends what you are doing ;-)
<meoblast001> SamB: well, is 724.7 KB a normal amount for a 70 commit typical C++ applications?
<SamB> I try to stay away from C++ programs of that size for the most part
<SamB> the only thing I can think of that might draw me to such a thing is LLVM ...
<meoblast001> SamB: wait, so it's too big?
<SamB> meoblast001: too many lines of C++ for *me*, yeah
<SamB> I don't really like C++
<meoblast001> too many lines or too large of a repository size?
<SamB> wait, wait, there was no size there ..
 * SamB is confused
<meoblast001> 724.7 KB
<SamB> I meant, there was no amount of code there
<meoblast001> 2000 lines
<meoblast001> plus some build tools
<LarstiQ> meoblast001: the code style changes will make annotation less useful
<LarstiQ> meoblast001: that's the only thing I'd worry about
<meoblast001> annotation?
<LarstiQ> meoblast001: `bzr annotate`
<LarstiQ> meoblast001: anyway, you can test what the result is, and if you don't like it, roll back to a previous revision
<meoblast001> origin of each line in a file?
<LarstiQ> meoblast001: yup
<meoblast001> what use would that have?
<LarstiQ> meoblast001: finding out when/why/by whom bugs are introduced
<meoblast001> oh
<Lo-lan-do> Automated finger-pointing!
<meoblast001> :P
<Lo-lan-do> Well, assisted, anyway.
<Lo-lan-do> "Automated" would be with bisect.
<meoblast001> POTFILES is not required if there's a POTFILES.in, right?
<meoblast001> ok, just ran a test, it is not
<Lo-lan-do> Okay, I'm fed up.  How do I fix stuff like "sha1 mismatch: ('â¦', 'â¦') has sha1 f10eb6688e35bb6da12bb960b0ef58a3573e26d1 expected da39a3ee5e6b4b0d3255bfef95601890afd80709 referenced by lolando@debian.org-20090921073025-t9nre0sg59ma0i0z" errors?
<LarstiQ> Lo-lan-do: reconcile?
<Lo-lan-do> Done.  Several times.
<jelmer> Lo-lan-do: that suggests dat ahas been inserted with the wrong sha1
<jelmer> Lo-lan-do: unless you have data corruption on disk, it's probably a bug somewhere
<Lo-lan-do> I recently did a check, found that the *one* revision listed was a head, uncommitted/recommitted it, and another check gives me another revision.
<Lo-lan-do> This is on a fresh repo cloned from an old one, so IÂ would have expected the stuff to be correctly inserted.
<Lo-lan-do> 2.0.0-1Â from Debian, 2a format, no frills.
<Lo-lan-do> And it takes my computer about two hours to run bzr check in there, so I'd rather avoid fixing all these errors by hand.
<meoblast001> SamB: it jumped to 731.9 KB
<meoblast001> i uppose that's not much
<meoblast001> 7.2 KB in 1 commit
<Lo-lan-do> meoblast001: What format are you using?
<meoblast001> 1.9
<Lo-lan-do> 2a is more compact, if you can afford it.
<meoblast001> afford it?
<meoblast001> i will switch to 2a once 2.x is stable and most people are using it
<LarstiQ> don't have older clients that can't read the format
<Lo-lan-do> It needs all clients to be at least 1.17, I think.
<meoblast001> oh, that should be no problem
<meoblast001> i have no problem with forcing people to upgrade >:)
<meoblast001> i suppose i'm worrying because i don't want my project to be one of those annoying projects that makes people say "30 minutes and you're still not done?!"
<meoblast001> i've ran into projects that have huge source repositories
<Lo-lan-do> You're at 70 revisions and 700 KB.  Unless you're doing dial-up over smoke signals, you're fine.
<meoblast001> ok
<SamB> meoblast001: this is how I feel today, btw, so if I say something strange-sounding... http://naesten.blogspot.com/2009/09/cant-haskell.html
<meoblast001> SamB: you program in Haskell?
<meoblast001> i kant python today... i has the dumb
<SamB> meoblast001: I'm not saying I can't haskell, but I definately feel like I has the dumb!
<meoblast001> :P
<SamB> though python might actually be harder for me when I feel like this ...
<meoblast001> speaking of Python, i think Bazaar is the best Python program out there
<meoblast001> one of the developers on my project says he doesn't like our use of Bazaar because it depends on the unstable Python.. i said at least Bazaar is written well enough in Python to be stable :P
<SamB> what, you mean the way they keep changing it?
<SamB> no, that can't be what you mean
<SamB> bazaar changes way more often than Python does ;-)
<LarstiQ> unstable Python?...
<SamB> LarstiQ: I guess maybe he was thinking of what happens when you make a typo and don't retest your code?
<LarstiQ> SamB: or maybe that it has more language changes than Fortran in a 10 year period?
<SamB> LarstiQ: I'm going to need to see sources on that
<SamB> I mean, unless you're talking about Python 3000
<LarstiQ> SamB: all 2.x versions have introduced something
<LarstiQ> SamB: I still don't find that unstable, I'm just speculating as to what meoblast001' colleague could mean
<meoblast001> i'm not upgrading for the same reason people often doing take a vaccine when it first comes out
<meoblast001> the amount of people who have tested it isn't high enough
<LarstiQ> sure
<meoblast001> once 2.x is stable, most people will be using that, and most people will probably use 2a repositories
<LarstiQ> meoblast001: but python 2.4 surely is welltested by now
<meoblast001> ooh, regarding Python
<meoblast001> i thought we were talking about 2a repositories
<LarstiQ> meoblast001: no, "one of the developers on my project says he doesn't like our use of Bazaar because it depends on the unstable Python"
<LarstiQ> is what I was responding to
<meoblast001> ah, yes
<meoblast001> he thinks Python is unstable
<SamB> LarstiQ: do you have any idea how much fortran has changed in the last decade?
<SamB> well, I don't have all that much idea either, to be honest
<fullermd> I dunno about the last decade, but I know it changed a lot in the decade prior.
<fullermd> My fortran book is slightly out of date.  But that's OK 'cuz I haven't really read it closely.
<fullermd> Actually, I haven't gotten past the exercise in the first chapter about learning how to punch a card with my name on it...
<LarstiQ> meoblast001: any idea why?
<meoblast001> i think he thinks the API changes too often
<LarstiQ> SamB: a bit, but it has standards that don't change
<\u03b5> hi, is it possible to make a "link" to another branch with bzr?
<SamB> you mean like lp:bzr-svn is a reference to something on samba.org ?
<SamB> (iirc)
<\u03b5> "branch blabla can be checked out in this directory"
<zsquareplusc> \u03b5: what exactly do you expect to happen? e.g. that updating one branch also upgrades an other?
<\u03b5> or (branching+)checking out one indeed
<zsquareplusc> migrating from SVN? ;-)
<\u03b5> nah, SVN is far away behind from me
<\u03b5> I figured out about that feature in svn and thought it could be pretty nifty
<\u03b5> but no biggie if it's not in bzr
<zsquareplusc> i once asked about something similar to svn:exetrnals and was told that the same feature does not exits in bzr, but https://launchpad.net/config-manager would be helpful in such cases
<\u03b5> oh well, that would be a bit overkill :)
<davidstrauss> I'm having trouble building 2.0.0 on RHEL 5: "bzrlib/_annotator_pyx.c:30:27: error: python-compat.h: No such file or directory"
<jderose> davidstrauss: do you see python-compat.h in brlib/?
<mzz> davidstrauss: full build log may be of use
<matthewlmcclure> jelmer: got a few minutes to chat about bazaar/perforce concept mapping?
<jelmer> matthewlmcclure: hi
<jelmer> matthewlmcclure: yeah
<matthewlmcclure> perforce is pretty similar to subversion, at least at a high level of abstraction
<matthewlmcclure> it's a centralized vcs
<matthewlmcclure> it uses some different names for commands, but for the most commonly used commands, I think there's a one-to-one mapping with Subversion
<jelmer> does it have a concept of branches?
<jelmer> or is everything a directory like in subversion?
<matthewlmcclure> it versions files rather than directories
<matthewlmcclure> you can branch/copy individual files from any path to any other path in a "depot" (repository)
<matthewlmcclure> there is a concept of a "branch spec", which is a metadata file describing how one path is branched to another
<matthewlmcclure> however, you can "integrate" (branch) from any path to any other path without a branch spec also
<jelmer> hmm
<matthewlmcclure> i've been thinking that a first version of bzr-p4 might support only a single Perforce "view" and be ignorant of any branch relationship among its files
<jelmer> can you do operations on entire directories?
<matthewlmcclure> yes, in the sense that such an operation would apply to all files within the given directory
<matthewlmcclure> but i don't believe there is any versioning, or data stored associated with the directory itself
<matthewlmcclure> (like CVS)
<matthewlmcclure> unlike CVS, and like Subversion, Perforce has a monotonically increasing "changelist" number per server
<jelmer> ah, ok
<matthewlmcclure> and each changelist contains n files changed
<jelmer> so directories are implicit I guess rather than explicit (such as in svn or bzr) ?
<matthewlmcclure> yes, i believe so
<zsquareplusc> the bzr-explorer "edit my tools" isn't very useful.. it opens an almost empty xml file. how am i supposed to know what to write there?
<matthewlmcclure> i've only begun to experiment with bzr-svn.  i gather that it allows viewing an svn path as a bzr branch, letting bzr commands operate directly on the svn path.  and it supports branching from the svn path, and pushing to it.
<matthewlmcclure> to me, branching from a perforce "view", rebasing on it, and pushing to it, would be the most valuable operations to support in bzr-p4.
<matthewlmcclure> do you have any recommendations on where i should start, or what code i should look at to see what's necessary?
<jelmer> matthewlmcclure: I would recommend looking at the Branch and Repository classes in Bazaar
<jelmer> those are the objects you have to provide implementations of that are answered by p4
<jelmer> matthewlmcclure: the wikipedia page says perforce has a commercial license
<jelmer> do you have an indepenednt python implementation or something that is available under a GPL-compatible license
<jelmer> ?
<matthewlmcclure> true.  it is commercially licensed.
<matthewlmcclure> they make some concessions for open source development.  http://www.perforce.com/perforce/price.html#opensource
<matthewlmcclure> i haven't executed anything with them yet.
<matthewlmcclure> git-p4 uses the command-line interface of the p4 command
<matthewlmcclure> i've been migrating away from that toward their P4Python API
<jelmer> so all operations would have to invoke the p4 command?
<jelmer> matthewlmcclure: is their p4python API GPL-compatible?
<matthewlmcclure> I don't know if the FSF would say it's compatible, but redistribution in source form is permitted.
<matthewlmcclure> the license text is in the tarball ftp://ftp.perforce.com/perforce/r09.1/bin.tools/p4python.tgz
<jelmer> looks like a BSDish license
 * ScottK dons his archive-admin hat and says it's GPL compatible.
<jelmer> ScottK: :-)
<jelmer> matthewlmcclure: it looks like the bindings link to the p4 libraries though - what's the license of those?
<matthewlmcclure> yes, it is.  i'm not sure what the license of the C/C++ API is.  i'm looking for it now.
<matthewlmcclure> i can't find any license that explicitly applies to the C/C++ API
<awilkins> SamB_XP: Heh, that Java I was writing earlier now takes 12 seconds. Seems the hashtable was really slowing it down
<SamB_XP> awilkins: what are you using instead ?
<awilkins> I was using a fixed-depth bucket trie... I just had a hashtable in the back as well that I forgot about
<awilkins> It eats 150MB of data files and writes the row IDS to 1000-row files in a trie folder structure on disk in that time
<jelmer> matthewlmcclure: as I mentioned in my other mail I think a next good step would probably be to define a clear mapping between the bzr and the p4 concepts
<jelmer> matthewlmcclure: bzr-svn has some documents in its specs/ folder
<jelmer> matthewlmcclure: in particular, how would bzr revision ids for p4 revisions be generated, what information should they contain, etc.
<matthewlmcclure> thanks.  i'll have a look at what bzr-svn does in that respect and write up what i think the equivalent mapping is for p4.
<matthewlmcclure> jelmer: i have to sign off.  thanks for your help.
#bzr 2009-09-27
<RenatoSilva> is it usual to use bzr commit --fixes=id more than one time for the same bug?
 * jelmer sleep
<dash> I'm trying to upgrade Twisted's bzr mirror to 2a
<dash> it seems to be stuck halfway. would I be better off just creating a new repo and branching into it and/or using svn-import than to do bzr upgrade?
<mzz> I found upgrade to not be all that fast
<mzz> I haven't noticed stuck though.
<dash> this is on our dinky little VM
<mzz> I think it took several minutes or so on a 20M repo with about 5000 revisions
<mzz> (on a basic linux system, not a vm)
<mwhudson> dash: doing the import again with bzr-svn will probably be just as fast
<dash> mwhudson: yeah ok
<jderose> does anyone know how to toggle bzr-builddeb between behaving like debuild -S -sd and debuild -S -sa?
<naoki_> I want to upgrade lp:tortoisebzr to 2a format
<naoki_> I read upgrade guide. http://doc.bazaar-vcs.org/bzr.dev/en/upgrade-guide/index.html#migrating-branches-on-launchpad
<naoki_> The guide says "On Launchpad, unset the current trunk from being the development focus."
<naoki_> I don't know how to unset "development focus"
<wgrant> Clear the Branch text box at https://launchpad.net/PROJECT/DEVFOCUSSERIES/+edi
<wgrant> +edit, that is.
<naoki_> Wow!
<naoki_> lp:tortoisebzr is now 2a!
<naoki_> Thank you!
<dash> ok so i've got a 2a edition of trunk now
<dash> if i had permissions i'd put it on launchpad
<jfroy> whoever here is Ian: I'm almost done with the 10.6 package. It's a "core" package (no frills, basic set of plug-ins).
<Peng_> jfroy: Which Ian are you looking for?
<jfroy> Ian Clatworthy
<Peng_> jfroy: That's igc, unless I'm making some horrible mistake.
<hman> Hi
<hman> I've got a unshelving question.
<hman> $ bzr unshelve 1
<hman> bzr: ERROR: No such file: None
<hman> I've read that it was a known bug, and I was wondering if anyone knows how to manually recover my shelved files.
<hman> Does anyone know about how to manually recover shelved files?
<hman> I guess I could read the shelving source code.
<itistoday> how do I display the contents of a single file from a past revision?
<itistoday> I don't actually want to bring that old file back, just want to see what was there
<dash> 'bzr cat -r'
<itistoday> damn, how did i not see that
<itistoday> thanks dash
<itistoday> also, i have a branch i'm currently working in that was branched off from the trunk, i haven't done anything in the trunk since, what should I do to essentially make the current branch the trunk?
<itistoday> should I push? or should I merge?
<itistoday> or perhaps switch and pull?
<itistoday> (my working dir is a lightweight checkout)
<itistoday> it points to the experimental branch that i'd like to merge/pull/push back into the trunk branch
<itistoday> and apologies if this is a stupid quetsion
<itistoday> *question
<dash> itistoday: i'd just merge it into the trunk
<dash> if you merge, 'bzr log' for trunk will show a single revision where you merged your branch, with the changes in the branch as subrevisions
<dash> if you just push it to trunk, bzr log will show all your commits to the branch just as if you'd made them to trunk.
<itistoday> dash: thanks, i guess that is useful to see
<hman> Does anyone have an idea about how to manually unshelve?
<hman> I have lost some important changes to code in a shelve that I need to recover. Ideas?
<mzz> I don't think I've seen the issue you describe
<mzz> have you searched the bug tracker for it?
<hman> Yes, I found this: https://bugs.launchpad.net/bzr/+bug/319790
<ubottu> Launchpad bug 319790 in bzr "bzr unshelve crashes losing all changes" [High,Fix released]
<hman> It mentions manually recovering the changes, but not how to do it.
<mzz> hman: what version of bzr are you on?
<hman> 1.13.1
<hman> When was the fix applied?
<mzz> hman: hmm, looks like the bug report doesn't say. Are you sure you're actually hitting the same bug (did you delete any files recently)?
<hman> There was a deleted file in the changeset.
<hman> I shelved on 1.3.1 and just upgraded to 1.13.1 but I get the same error.
<hman> I see the shelve-1 file but I don't know how to manually get to my changes.
<mzz> I don't know what format that file is actually in, but last time I peeked at it it wasn't very human-readable.
<hman> Yeah. I'll keep digging around.
<rsvp> are the C extensions necessary -- in other words, is bzr written so that it can be run solely on python code? and if so how much slower is the performance typically?
<mwhudson> rsvp: the c extensions are not necessary
<mwhudson> i'm not sure what the performance impact is these days
<bob2> the packages in the ppa have the extensions built, though
<mzz> rsvp: they are sufficiently unnecessary that there have been a few releases accidentally omitting their source from the source tarball, but it's not like they're hard to build either.
<mzz> ("a few" being "at least two" but I forgot the actual number)
<rsvp> so going the source code route (not ppa packaging) one should make those C extensions, else there is some (significant?) performance hit.
<Peng_> Compiling the C extensions is as simple as a "make", so why not do it?
<mzz> exactly
<Peng_> But you certainly can get by without them. It just won't be as fun.
<mzz> also, why were you not using the ppa again?
<Peng_> BTW, with the 2a disk format, the C extensions will use less disk space.
<Peng_> (Line-based vs. byte-based deltas.)
<mzz> ohh, I forgot about that.
<Peng_> Still totally compatible, of course.
 * mzz is now mostly done cleaning up and upgrading all the branches randomly spread over his hds
<Peng_> I hope I never decide to do that.
<mzz> well, it was not just the format upgrade that made this something I wanted to do.
<mzz> also, there weren't *that* many. Although there was some embarassing ancient code in there.
<project2501a> hey guys: i'm finding the instructions on how to publish a repo over http, a bit confusing: 0) there is no bzr-smart.py script readily available 1) it doesn't look that bzr likes multiple repos from the same root, and 2) it doesn't look that there's a landing page
<mzz> what instructions?
<project2501a> these instructions: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html
<rsvp> mzz, thanks for your response yesterday by the way... I wanted to understand the comparison with hg (without C extensions) ...
<mzz> project2501a: what section?
<project2501a> mzz: under 'mod_pythong'
<project2501a> d-oh. freudian slip
<project2501a> mzz: under 'mod_python'
<project2501a> that tong tong tong
<mzz> rsvp: mercurial has c extensions, although I don't know if they're also optional
<Peng_> mzz: They are, but unless something changed while i was away, it's a bit of a pain to use the Python versions.
<mzz> project2501a: afaik mod_python isn't the best choice for serving stuff. Is the manual recommending it over other options?
<Peng_> project2501a: The smart server script is given in the docs.
<project2501a> no, it's not. but the manual is not offering much guidance or solutions
<Peng_> project2501a: What do you mean about "multiple repos from the same root"?
<project2501a> like hg or git does: gives you a root dir, ie, http://marsel.is/repos/git and you can have multiple repos under that url
<project2501a> each independant of the other. plus it serves as a landing page
<rsvp> mzz, I think the early hg versions required c extensions.
<mzz> project2501a: the script is given below (under "configuring bazaar", subsection "mod_python")
<Peng_> rsvp: That's correct.
<mzz> project2501a: but I'd use fcgi. and afaik you can just expose more than one smartserver instance that way (although I don't think it automatically creates a landing page)
<project2501a> yes, i saw it. that's why i said "there is no readily available script"
<mzz> project2501a: there are plugins (loggerhead mainly) that serve html to humans.
<Peng_> project2501a: You can have as many branches and repos as you want...
<Peng_> Aside from bug 348308, which broke bzr+http with shared repos.... But that's not the same thing. And it can be worked around anyway.
<ubottu> Launchpad bug 348308 in bzr "Smart server jail breaks bzr+http with shared repos" [High,Triaged] https://launchpad.net/bugs/348308
<project2501a> maybe i should go back and read some more
<project2501a> maybe i should take it with the bzr maintainer in debian, cuz apparently neither the bzr nor the bzrtools package includes bzr-smart.fcgi
<rsvp> I'm thinking of switching over to mercurial because I get the impression the python(.org) community is going that direction (under Guido's nudge wink wink say no more) -- any good counter-arguments?
<SamB_XP_> don't be a sheep
<project2501a> rsvp: get a brain
<mzz> project2501a: notice that script is also included in the manual, and mostly consists of configuration
<mzz> project2501a: I don't think including it makes sense
<SamB_XP_> sheeple are annoying
<mzz> rsvp: do you hack on python itself?
<project2501a> SamB_irssi: reddit rules
<dash> rsvp: i've used hg, main reason i stick with bzr is that I think the way it handles branches and merges is better
<project2501a> mzz: i'm a sysadmin mate; i code, but my bread and butter is sysadmin. inclusion would make my life easier. happy sysadmin == happy office
<project2501a> unhappy sysadmin == wrath of root.
<mzz> project2501a: I guess it could live under /usr/share/doc/bzr/examples or something
<project2501a> it could. it doesn't
<mzz> that's what I meant
<project2501a> <3
<mzz> my point is that just running it doesn't make any sense, you have to edit roughly half of the roughly a dozen lines in there. So sticking it in /usr/bin or the like would just be weird.
<Peng_> Mine is 130 lines long. How did that happen? >.>
<mzz> rsvp: neither mercurial nor bzr is likely to go away anytime soon, so what projects you don't hack on use isn't important
<mzz> Peng_: serves too many repos?
<project2501a> from my humble BOFH point of view is that svn, hg and git took me 40 minutes each to set up, and that's because i was lazy. and bzr is currently taking the piss
<mzz> hmm
<project2501a> i understand what you are saying, by the way
<mzz> project2501a: iiuc it's just a wsgi app, and there are multiple ways to actually expose those to the net. I guess the manual doesn't go into as much detail as it could about how to do that.
<project2501a> i'm not trying to argue against you, i'm just mounting a retort
<Peng_> mzz: There isn't per-repo stuff. It's just customizations: mostly logging, working around that bug, and something else.
<project2501a> mzz: that is correct mate.
<mzz> (and I'm assuming just plain "bzr serve" doesn't suit your needs)
<project2501a> no
<project2501a> that would mean more ports open
<project2501a> bad karma, sysadmin gets less sleep
<mzz> nod
<mzz> so there's a bit of a documentation hole there.
<Peng_> What's wrong with opening a couple ports?
<project2501a> the size of a small moon.
<Peng_> You have the exact same exposure either way.
<Peng_> Well, I suppose it would take some bot attacker longer to find a bzr+http server.
<Peng_> But they both do the same thing.
<Peng_> Anyway, what were we talking about?
<project2501a> no you don't. much much easier to use Simple Event Correlation with one port and tell SEC to ban an ip for 40 minutes when the IP is takign the piss
<project2501a> Peng: reddit
<project2501a> that's what we're taking about
<project2501a> specifically /r/jailbait/
<rsvp> mzz, an important factor is the format of the (most popular/useful/institutional) repositories -- if hg or bzr had plugins which makes the interchange convenient then there's no question, however, that might be incompatibilities which could be annoying down the road.
<mzz> rsvp: fastimport is supposed to help with that
<bob2> it's 2009
<mzz> rsvp: although I once actually used that and hit some bug on removal of files, so I know what you mean
<bob2> you're going to have to use more than one revision control system, anyway
<project2501a> what bob said
<project2501a> these days SCMs tend to be a trend anyway
<mzz> but yeah, just make sure you at least pick a dvcs that isn't totally obscure and you'll usually be ok.
<bob2> no monotone
<mzz> no?
<project2501a> factors include which way is guido pissing, if joel got laid last night, and if paul graham wrote another essay portraying hackers as painters
<SamB_XP_> project2501a: but ... nobody would read it
<project2501a> oh and if the stock for va linux is still plummeting or not. ESR gets frisky about that
<project2501a> SamB_irssi: lol :)
<SamB_XP_> they would not realize it was new
<SamB_XP_> and believe that they had already read it
<project2501a> i tell you there are people who are total fan boys of graham
<project2501a> they would re-read it and suck his dick in the process
<SamB_XP_> ... okay
<project2501a> and then declare that he's a genious can we have more funding from y-combinator?
 * SamB_XP_ amuses himself by following his own newly-minted blog
<project2501a> you have a blag?
<SamB_XP_> http://naesten.blogspot.com/ -- just one post, started the thing because I'm sick and tired of having to fish for lambdacats when I want them ...
<project2501a> SamB_irssi: yo dog, i'm gonna let you finish, but i just want you to know that blogspot sucks
<SamB_XP_> project2501a: yeah, sure
<SamB_XP_> I guess I knew that
<SamB_XP_> but if I used something else, I would have to decide what!
<project2501a> you can use a blog inside a blog so you can blog while you blog
<Peng_> Use WordPress! Constant security problems make life fun!
<project2501a> yeah, php! it's not a language, it's a brand new estate for it's creators!
<SamB_XP_> project2501a: wouldn't putting a toilet in the blog make more sense?
<project2501a> that's putting a toilet in the blog so you can defecate while you blog
<project2501a> SamB_XP_: i take it you're not up to date with your memes
<SamB_XP_> I was thinking of words more like "shit" and "crap"
<project2501a> that's slashdot mate
<SamB_XP_> project2501a: I can't remember all the ones I've even heard of
<SamB_XP_> I accidentally the memes
<project2501a> all of them?
<SamB_XP_> and I don't read slashdot very often
<project2501a> you're not missing anything
<SamB_XP_> project2501a: I them all
<project2501a> taco is vested, cowboy neal likes young boys
<SamB_XP_> chuck norris doesn't like where this is headed
<project2501a> talk to jack cuz the hand aint hearing it
<rsvp> bob2, it a real hassle with multiple version controls -- I'd go with the one that can read the others the most without hassle.
<SamB_XP_> wow, big surprise, rsvp is recommending bzr in #bzr ;-)
<project2501a> or hg
<rsvp> voila
<SamB_XP_> hg can read other VCS branches?
<project2501a> rsvp: do you use vi or emacs?
<SamB_XP_> what other VCS's branches can it read ?
<rsvp> vim
<project2501a> SamB_XP_: svn afaik, but i'm just taking the piss here
<project2501a> yeah, ok, time for sleep
<project2501a> so
<project2501a> no landing page
<project2501a> no easy way to publish repos over http
<SamB_XP_> project2501a: okay, that's about what I thought I might have read
<project2501a> no multiple repos under a single root
<SamB_XP_> no easy way to publish repos over http ... what ???
<SamB_XP_> it's not harder than with darcs!
<project2501a> sorry, it's kinda late here and my brain is slowing down
<project2501a> SamB_XP_: no easy way to publish multiple repos under a single root over http
<project2501a> ^-- better?
<SamB_XP_> project2501a: sure there is ... you just push them into subdirectories of a directory in your www tree ...
<wgrant> There's even a plugin to push a whole directory of branches, I think.
<lifeless> project2501a: bzr push bzr+ssh://webhost/srv/www.site/b1
<lifeless> etc
<project2501a> SamB_XP_: that doesn't make them independent repos
<rsvp> project2501a, (but you see text is text, to both vi and emacs -- and one chooses the unix newlines in vim because ms can handle that but NOT vice versa -- so always go with the set that encompasses the other)
<SamB_XP_> project2501a: what do you mean?
<lifeless> project2501a: what do you mean 'independent'
<project2501a> anyway, i apologize. as i said it's late over here. i'm gonna go take a nap and i'll be back in the morning
<SamB_XP_> I mean, you just stick the directories in a directory
<project2501a> brain no worky worky
<SamB_XP_> oh, you feel like I felt this morning maybe ?
<project2501a> have you been feeling like you should stop being a sysadmin doing admin spotting
<project2501a> ?
<SamB_XP_> well, no, but there's a reason I posted that lambdacat today
<project2501a> pissing your last in a miserable newsgroup, nothing more than an embarrassment to the f*cked up lusers gates spawned to replace the computer literate?
<project2501a> heh
<project2501a> import import_beer; import more_women;
<lifeless> project2501a: could you tone down the language please, we like a friendly channel
 * SamB_XP_ generally tries to do his pissing into the toilet
<project2501a> oh, the p****g part
<project2501a> that's just brittish idiom
<project2501a> could mean wasting
<project2501a> anyway, long live the GPL, see you tomorrow morning where i will have had more sleep
<SamB_XP_> no, down with the GPL and up with SPLs!
<rsvp> the other interesting thing between mercurial and bzr... if one uses Ubuntu, bzr shows up in updates in the week of the release, whereas for hg you can probably hang on to your stale version for a longtime.
<lifeless> rsvp: thats because we push updates to Ubuntu; the hg community could do that if they wanted
<SamB_XP_> how often does hg get a new release ?
<lifeless> its not time based
<rsvp> lifeless, I understand, that's the "institutional" aspect of releases.
<SamB_XP_> I meant approximately
<SamB_XP_> I wasn't meaning to imply time-based-ness
<lifeless> SamB_XP_: couple of times a year, more or less
<rsvp> and Ubuntu of course uses bzr, not hg, internally.
<lifeless> http://arcanux.org/lambdacats/tail-recursion.jpg nice
<lifeless> there is that
<lifeless> but its not why releases get to ubuntu :P
<SamB_XP_> lifeless: well, it might be if you didn't push them so hard
 * rsvp is LOL allowed in here?
<lifeless> SamB_XP_: in the past, they've trickled down from Debian
<SamB_XP_> rsvp: after looking at a specialized type of lolcat ? yes!
<SamB_XP_> lifeless: ah, sure
<lifeless> SamB_XP_: and thats still the process, just we get in and own it
<SamB_XP_> ... so you're blaming this on jelmer then ?
<lifeless> blaming ?
<Peng_> Isn't hg trying to release more frequently now?
<SamB_XP_> whatever word you want to use
<lifeless> sure thing Christopher Robin :)
<zsquareplusc> bah, i have a problem. pushing ends with the message ConnectionReset, unexpected end of message. in bzrlib\smart\message.pyo:286
<zsquareplusc> the remote branch then has the lock set and loggerhead fails to display it
<SamB_XP_> darn it
<SamB_XP_> zsquare should know to wait longer than that at 11:30 EST!
<meoblast001> is what i'm told true? you can make a checkout of the last x amount of revisions of a project and work with that?
<Peng_> SamB_XP_: 'specially on a weekend.
<lifeless> meoblast001: kindof, who is saying that
<meoblast001> some people in #gamedev
<lifeless> well, did they give an example command line?
<meoblast001> no
<meoblast001> i saw you in there
<lifeless> just popped in for a sec
<lifeless> see if I recognised folk
<meoblast001> so i suppose you know it's raining over here now :P
<johnf1> say I have a a local branch with rich-root support and an upstream shared-repo which doesn't. How can I push my branch to that repo?
<johnf1> The branch was originally a branch of an svn tree which I'm not going to use any longer
<lifeless> upgrade the the shared repo
<johnf> lifeless: :) Yeah trying to avoid that. I'd have to bug everyone else using it. Which I suppose I could do
<lifeless> make a a new repo at the subdir you want to push to then
<lifeless> bzr init-repo URL; bzr push URL
<johnf> A repo can exist within a repo?
<project2501a> helloooo
<project2501a> good morning
<project2501a> i'm trying to start loggerhead manually so i can test it. i get this error: bzrlib.errors.NotBranchError: Not a branch: "/repos/bzr/.bzr/branch/". any clues please?
<johnf> project2501a: can you put your loggerhead.conf on a pastie somewhere?
<project2501a> sure mate
<project2501a> give me 2 clicks
<project2501a> johnf: http://pastebin.com/m7f0dd30b
<johnf> what do you have in /srv/repos?
<project2501a> there's no such path in my machine mate
<project2501a> there's /repos/bzr
<johnf> ahh sorry that's what I means
<project2501a> jibber:/repos/bzr# ls -la
<project2501a> total 12
<project2501a> drwxrwxr-x 3 bzr  www-data 4096 2009-09-27 10:18 .
<project2501a> drwxr-xr-x 6 root root     4096 2009-09-22 01:01 ..
<project2501a> drwxrwxr-x 4 bzr  www-data 4096 2009-09-27 10:18 .bzr
<project2501a> did i init the  repo wrong?
<johnf> hmm does the repo have anything in it yet?
<project2501a> no, it's blank
<project2501a> i'll import code later
<LarstiQ> so there are no branches then
<project2501a> i'm setting up the infrastructure right now so i will be spanky-comfy later and not sweat about it
<LarstiQ> project2501a: which is what loggerhead was complaining about
<project2501a> yeah, no branches.
<project2501a> LarstiQ: yup.
<lifeless> its rather unsurprising to get 'not branch error' with no branches.
<project2501a> well, shouldn't loggerhead account for a brand-new repo?
<project2501a> and say "hey, there's nothing to serve here"
<project2501a> "empty page"
<project2501a> or something like that
<lifeless> if you run bzr serve --http, I think thats what it will do
<project2501a> LarstiQ: so,  you're saying, just check in something?
<lifeless> loggerhead.conf is a different beast
<project2501a> lifeless: well yeah, i'm trying to make it all pretty :)
<project2501a> so, just check in something?
<project2501a> can i make just a silly branch without committing anything?
<lifeless> 'bzr init'
<lifeless> '
<project2501a> ooh
<project2501a> i used bzr-initrepo something
<project2501a> my bad :)
<project2501a> thank you :)
<lifeless> init-repo makes a repository
<lifeless> repositories are an optional container for branches
<project2501a> it looks like i'll have to read up
<lifeless> my general advice for folk getting started with bzr [and contemplating large deployments etc] is
<lifeless> 'play with it'. put something small in, fresh import, no history, and fiddle round
<project2501a> very true mate
<lifeless> get used to the UI and how to push pull and merge with other branches.
<project2501a> i has ideas :)
<project2501a> yay, loggerhead now seems to work
<project2501a> now if i can just solve that damn [client 93.97.20.215] client denied by server configuration: proxy:http://127.0.0.1:8080/, referer: http://marsel.is/
<project2501a> now, we're getting along :)
<project2501a> lifeless: thanks mate
<project2501a> thanks everybody
<project2501a> YAY!
<project2501a> works
<project2501a> i love you guys :)
<project2501a> if you ever come by sheffield, UK, i'll buy you a pint
<project2501a> http://marsel.is/repos/bzr/
<lifeless> I'm glad you're up and running
<lifeless> gnight everyone
<mdke> any ideas about the cause of this? http://paste.ubuntu.com/279609/ and whether a bug already exists? I can't understand python tracebacks
<mdke> this occurs when I'm trying to branch into a shared repository
<mdke> I'll be afk for a bit but picking up any hilights
<spiv> mdke: known bug; launchpad needs to upgrade its bzr; fix is to upgrade your local repo format to match the remote format, probably 2a
<spiv> mdke: oh, hmm, LP is running 2.0.0 now.
<spiv> mdke: best bet is to file a bug report on bzr
<spiv> mdke: workaround will probably still be making your local format match the remote one
<spiv> mdke: but off the top of my head now that LP is running 2.0 on the server this shouldn't happen anymore.
<meoblast001> does "bzr log" always return a local log if i have a heavyweight checkout?
<meoblast001> just need to do a sanity check
<mdke> spiv: thanks, so just a bzr upgrade?
<meoblast001> i was doing my final cleanup on my branch, and got this http://codepad.org/bUF52JMr
<meoblast001> it looks like my original branch had 73 commits too, so i'm confused
<mdke> spiv:I wonder if it is a downgrade I need, my local repo is already using 2a
<mdke> spiv: bzr upgrade --1.9-rich-root has done the trick
<mdke> spiv: thanks!
<DGMurdockIII> is there a easy to use bzr client for windows like tortoisesvn?
<sque> spiv: ping are you here?
<sque> This bug: https://bugs.launchpad.net/bzr/+bug/109143 is fixed in 2.0.0 ? or in later version?
<ubottu> Launchpad bug 109143 in bzr "hpss does not support ~ (tilde) for home dir access on bzr:// or bzr+ssh://" [High,Fix committed]
<sque> I have installed 2.0 on client and server pc and does not seem to work
<LarstiQ> reading the comments, I don't think it's in bzr.dev yet
<sque> LarstiQ: It seems that this branched is merged to 2.0 https://code.launchpad.net/~spiv/bzr/bzr-ssh-homedir-take-3
<LarstiQ> sque: ah, you are right
<sque> LarstiQ: I downloaded the source of 2.0 and the patches are not in there. I checked the lp:bzr/2.0 branch and no patches are there too. The patches are merged at the lp:bzr (the dev branch). So this bug will be fixed in 2.1 probably
<sque> damn.
<Fly-Man-> Morning
<Fly-Man-> When I try to download the latest version of launchpad, the bzr gives me this error
<Fly-Man-> ./rocketfuel-setup: line 372: 19633 Segmentation fault      bzr branch http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/ $LP_TRUNK_NAME
<Fly-Man-> Is there a way to install bzr 1.18 instead of 2.0 ?
<awilkins> Fly-Man-: Branch 1.18, compile the extensions, and bung the folder on your PATH
<Fly-Man-> awilkins: No other way ?
<Fly-Man-> because for some reason, it's stuck with either 1.16 or 2.0
<awilkins> You could use a source tarball, I suppose
<Fly-Man-> uhm, i'm more a apt-get person ;)
<Fly-Man-> not a source tarball eater
<awilkins> Well, I bet you a cookie on a stick it's quicker than the fiddling with apt configuration to make it stick to a particular version
<lamalex> Hey guys, i'm getting a wierd bzr-buildpackage error. bzr: ERROR: Could not find changelog at "debian/changelog".
 * awilkins downloads tarball
<lamalex> does anyone know what the deal with that is?
<lamalex> there's definitely a changelog..
<Fly-Man-> awilkins: Already found a ppa package that has 1.16
<Fly-Man-> thanks :)
 * awilkins deletes tarball
<lifeless> moin
<jfroy> verterok: ping
<johnf> lifeless: Do you know the process to get a package pulled into ubuntu during freeze. Namely bzrtools
<lifeless> requestsync --lp -e bzrtools
<johnf> hmm is that the right process?  -e          Use this after FeatureFreeze for non-bug fix syncs
<johnf> this is technically a bug fix right?
<lifeless> johnf: then no -e
<johnf> will that give it the right priority to make sure it happens for kamic though?
<lifeless> orthogonal concerns
<lifeless> 1) get the bug filed, 2) NAG AN RM
<johnf> hmm. Does someone else have time to do it. I have to run out the door and requestsync is core dumping on me right now
<lifeless> doing
<johnf> thanks
<lifeless> bug 437869
<ubottu> Launchpad bug 437869 in bzrtools "Sync bzrtools 2.0.1-1 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/437869
<lifeless> james_w has said he'll walk it through
#bzr 2010-09-27
<spiv> Good morning.
<jbowtie> spiv: Is PQM happy with bug 596239 now?
<ubot5`> Launchpad bug 596239 in Bazaar "Bazaar supports https! Update documentation (affected: 1, heat: 4)" [Medium,Confirmed] https://launchpad.net/bugs/596239
<spiv> jbowtie: good question, let's find out...
<poolie> hi there spiv, jbowtie
<jbowtie> I'm just wondering if it's actually using sphinx on Python 2.4 - if it's using pure docutils it won't recognize the ref directive even with the better line wrapping.
<jbowtie> That might put a crimp in my plan to fix up all the links.
<spiv> I *think* we stopped using pure docutils, but I might be wrong.
<spiv> I'm fairly sure we intended to, at least :
<spiv> :)
<jbowtie> HI, poolie, sorry for the lack of bug fixes this weekend, should land some mid-week.
<poolie> np, no obligation, we appreciate them
<spiv> jbowtie: same error, the Makefile still invokes the 'docs-plain' as part of 'check' target
<spiv> poolie: any reason why we haven't switched to just Sphinx in trunk?
<spiv> poolie: I thought that was the plan, maybe we just never got around to flipping the last switch?
<poolie> spiv, there may be some snags
<poolie> perhaps that it's not in the pqm chroot?
<poolie> you should check with vila
<spiv> Ok
<lifeless> there is an rt open for sphinx in th chroot
<lifeless> the chroot should be upgraded from hardy too
<spiv> The Makefile has a comment about how "Post 2.0" we will most likely switch the 'docs' target from 'docs-plain' to 'docs-sphinx'.
<poolie> spiv, want to chase it with spm etc?
<spiv> Sure.
<spiv> spm: ping?  I'm wondering about the status of installing sphinx in the PQM chroot.  lifeless says an RT open, is it blocked on anything?
<spm> spiv: time probably
<spiv> That's both good and bad news, then :)
<spm> mmm :-)
<spm> spiv: fwiw, it's 9th in priority in the LP queue atm, exclusive of all the other stuff going on.
<spiv> Is that good or bad? :)
<lifeless> bad
<lifeless> I have several month long things in there ;)
<jbowtie> spiv: So should I rework the patch to be docs-plain compliant, or leave it as a useful test case?
<spiv> jbowtie: I think rework it to be docs-plain compliant.  You can leave a XXX comment in the source about how to improve it when we can require sphinx.
<jtv> This conflict looks incorrectly bracketed: http://paste.ubuntu.com/501267/
<jtv> One line is near-identical between the two conflicting versions (the only difference being punctuation at the end),
<jtv> but it is shown as occurring only in one of the two conflicting versions.
<spiv> jtv: I think a case like that came up on the list, or perhaps a bug report, recently...
<spiv> jtv: https://bugs.edge.launchpad.net/bzr/+bug/616749 ?
<ubot5`> Launchpad bug 616749 in Bazaar "Incorrect merge - Lines missing inside conflict markers (affected: 1, heat: 5)" [Medium,Confirmed]
<jtv> spiv: thanksâI'll click "this bug affects me."
<vila> hi all
<poolie_> hi there vila
<vila> poolie: helllooo !
<poolie> hi there
<spiv> Interesting; running a 'bzr pack' top reports Python is using ~160% CPU (on a 4 CPU laptop), but vmstat consistently shows 25% for the same period.
<spiv> I suspect one of these tools is coping better with a process bouncing between CPUs.
<spiv> (to be fair I imagine vmstat probably has an easier job here)
<spiv> That does mean I need to avoid trusting 'top' as an indication of whether a process is productively using more than one CPU (or even using more than one concurrently at all).
<poolie> interesting
<spiv> Probably for per-process information on that I should be using perf anyway :)
<poolie> that will tell you about all the cpu transitions, if you want that data
<knittl> hey poolie *wave*
<spiv> Hmm, interesting that sometimes top says Python is on just 100
<spiv> I wonder if that's when it's in pure python code that isn't frequently dropping the GIL?
<vila> spiv: quick question: does the news_merge plugin takes releases into account and sort them in chronological order or does it just left them untouched ?
<vila> spiv: leaving the unreleased one at top that is... (there should be only one at a time right ? :)
<spiv> The current version punts as soon as it sees a conflict involving more than sections and bullets.
<vila> spiv: ok
<spiv> There's a work-in-progress prototype of one that can cope with more, but it doesn't try re-ordering releases either.
<spiv> Although it probably could if we wanted it too...
<poolie> hi knittl
<vila> spiv: ok, I didn't respect this order when releasing, so I'm fixing it right now and was wondering...
<knittl> poolie: do i really have to sign that agreement?
<vila> weird weird stuff: a VM suddenly colliding with its own ipv6 address...
 * vila suddenly remembers he didn't sacrifice any chiken or goat this morning...
<vila> spiv: bah, there *could* be several releases in progress in the same NEWS file
<spiv> vila: yeah, but they'd all have version numbers...
<vila> spiv: yes, but no release date
<vila> I thought the consensus was to sort them by release date, intermixing series, did I get this wrong ?
<vila> now since we can't predict release dates (haha), 'NOT RELEASED YET' should probably stick to the last know one in its series
<vila> and be on top if it's the first in a new series
<spiv> I'd thought it was by version, not date.
<spiv> But I'm not very sure of that.
<vila> grep ^:2. NEWS
<vila> spiv: at least during the 2.1b era we did sort by date, I think it makes more sense but I'll respect the consensus, so poolie, what's your remembering here ?
<vila> though :2.2b4: 2004-07-09 is not very convincing ;)
<poolie> vila i think we should split the news out into one file per series and avoid the issue
<poolie> also i think we should not copy news where things are just merged up
<poolie> just say "includes everything from 2.0.6" etc
<poolie> knittl: yes, i see you already did put "copyright Canonical" but we do need the email signature too
<poolie> spiv istm that regarding network performance, we should file (or just mention) bugs about there being too many startup roundtrips
<poolie> i think there is one, at least for the graph
<poolie> and then i guess there's another about the stream holding fulltexts
<vila> poolie: so you mean we stop using NEWS in favour of NEWS-2.0, NEWS-2.1, etc ?
<poolie> yes
<vila> poolie: there will be some fallouts regarding the news_merge plugin and the doc generation
<vila> spiv: how far from completion is your wip on the news_merge plugin ?
<vila> poolie: getting away from NEWS will rejoice jam ;)
<knittl> poolie: i didn't do for my last patch
<knittl> and i don't really want to
<spiv> vila: I don't recall off the top of my head, but probably about 50%?
<vila> poolie: hmm, thinking a bit more about this proposal, I think the consequences are a bit heavy to switch to it quickly and transparently: we'll need to teach evrybody to use the new scheme, update the news_merge plugin, update the doc generation and fix all the quirks encountered doing that (and who knows what I forget here). I'm not that comfortable doing it without giving it a lot of publicity...
<vila> spiv: and can it easily be extended to target NEWS-* instead of NEWS ?
<spiv> vila: yes, with the caveat that the hook is per-file
<spiv> vila: so it can't really cope with situations that need to consider multiple files together.
<vila> spiv: does this matter ? If a news entry should now appear only in a single file no ?
<vila> s/should/would/
<spiv> Right.
<vila> or did I forget something ?
<spiv> It just means it would be hard to make it to implement something like "automatically propagate NEWS entries when merging 2.x -> 2.x+1", if we wanted to do that.
<spiv> vila: as far as doc generation goes, I'm pretty sure it would be a clear improvement
<spiv> vila: currently the doc generation has to basically do the NEWS -> NEWS-* split itself
<vila> yeah, poolie, I'm not sure the incremental step you're proposing really address the "where did this bug get fixed" need as conveniently as the duplication does today
<spiv> So if we start keeping the data in that shape in the first place, we can just delete that cruft.
<vila> spiv: yup, code wise it will simplify this part, but as a communication mean ?
<spiv> Well, it apparently is how we are communicating â see the generated docs ;)
<spiv> Certainly, as someone that looks at the NEWS file fair frequently to see what changed and/or when something was done, I think I'd find it a little more convenient, if anything.
<vila> spiv: no, I mean about duplicating the news entry or not
<spiv> That's orthogonal, surely?
<spiv> Besides, we aren't consistent on that today, I think.
<vila> spiv: right, but part of the same proposal ;)
<spiv> (Certainly we haven't been in the past)
<spiv> Well, as an orthogonal issue, I'm mildly in favour of it.
<spiv> But I don't really see it as being related to the split-NEWS proposal at all.
<vila> <poolie> vila i think we should split the news out into one file per series and avoid the issue
<poolie> it's true it's mildly related
<vila> ha, hmm
<poolie> i don't care strongly about them
<spiv> Well, I don't know why poolie considers it related, but that doesn't change my view :)
<poolie> i'd like to get the news merge plugin working
<vila> sorry about the confusion, I ran into it *while* duplicating entries and I mixed the two
<vila> and I ran into this while merging up the bugfixes targeted at running the tests during the package build and I try to avoid losing my focus which I seem to failing :)
<spiv> (Separately, it would be nice to explore how to have nice hooks that deal with situations involving multiple files.  I think actually it might be possible with the current hook after all, at least in some cases...)
<vila> s/to failing/to be failing at(sp?)/
<vila> so, do you (poolie, spiv) mind if I finish my NEWS cleaning *before* looking at changing the scheme ?
<vila> (which will also leave us a bit of time to at least prepare the new_merge plugin)
<spiv> I don't think any preparation for news_merge is required to maintain the same quality of merging.
<vila> <vila> spiv: and can it easily be extended to target NEWS-* instead of NEWS ?
<vila> <spiv> vila: yes, with the caveat that the hook is per-file
<vila> spiv: You mean it already accepts a glob ?
<poolie> vila, what do you mean by 'news cleaning'?
<poolie> i don't think i'll mind anyhow
<spiv> I mean, developers will need to update their configs
<spiv> But that's not a big deal.
<spiv> It would be nice to improve, certainly.
<spiv> But sufficiently minor to be a blocker.
<vila> poolie: I'm duplicating the news entries while merging up 2.0 -> 2.1 -> 2.2 ... -> bzr.dev
<spiv> vila: the "per-file" aspect I was referring to isn't about globbing
<vila> and sorting them while doing it
<spiv> vila: it's that imagine you have a single semantic conflict that spans two files
<spiv> vila: maybe one branch renames a function, the other moves the definition from file A to file B
<vila> spiv: sure, different topic, I thought you couldn't use a glob right now
<spiv> I don't think you can, but it's not a big deal.  Update your news_merge_files right now to say news_merge_files=NEWS,NEWS-2.0,NEWS-2.1,NEWS-2.2,NEWS-2.3,NEWS-2.4,NEWS-2.5,NEWS-3.0 and you're sorted for probably the next year at least ;)
<spiv> It'd be a nice improvement, and relates I think to a feature request for the bzr-changelog-merger, so I'll definitely look at it quite soon.
<spiv> But I don't see that as a blocker for reorganising NEWS.
<vila> spiv: me neither, only as an interruption in another unrelated task
<spiv> Well, changes in general do tend to be a bit disruptive.
<spiv> So long as we do what we reasonably can to minimise the disruption, I think that's acceptable.
<vila> spiv: I'm not saying it's bad, I'm just saying I don't want to do it while I'm already doing something else than can be done without it in less time :)
<vila> (both elapsed and CPU)
<spiv> vila: well, get that other thing done soon then ;)
<spiv> More seriously, I'm sure this isn't going to happen overnight.
<spiv> Because of the need to tweak doc generation, etc.
<spiv> Anyway, EOD for me.  Happy autumnal hacking!
<vila> spiv: happy evening
<rom1> Hi all
<rom1> Can we rollback packs to obsolete packs ?
<vila> rom1: that sounds like a really weird and bad idea, may be you can explain the rationale ?
<rom1> well, i have a corrupted repository (i still look for the cause of the corruption). When a user does any operation in the shared repository, a file nopt found error is returned from an indice which is in obsolete packs.
<rom1> i guess that an operation has been interrupted while the repositry was packing...
<vila> rom1: it's generally worse than that: a crash or a file system corruption
<vila> rom1: os/fs versions ?
<rom1> That's why i am wondering if we can use the obsolete packas as a rollback
<rom1> etch/bzr 2.1
<vila> file system ?
<rom1> ie ?
<vila> ext2 3 4 ?
<ddaa> ext3 / xfs / reiserfs / ntfs / bttrfs
<vila> nfs (urgh)
<rom1> ext3
 * ddaa blames cosmic mind-control rays
<vila> rom1: first, try: md5sum .bzr/repository/packs/*  and look for files whose name doesn't match
<vila> rom1: you can do the same for obsolete_packs
<rom1> ok, what if i have some ?
<rom1> I have made the following test in a copy of my corrupted repository : i copied the expected indices from obsolete to indices & packs
<vila> rom1: the files are created with a name matching their content and *never* modified by bzr, so the files that don't match indicate a problem with the fs or worse the hd
<rom1> I could do the blocked operations (ie the previous file not found errors)
<rom1> then i repacked the repository, all worked fine
<vila> rom1: we'll come to that shortly, can you do the md5sum check ?
<rom1> vila : thx, i understand
<rom1> is has been done, and effectively, i have some differences
<vila> bad bad, are these files empty ?
<rom1> no
<vila> even worse :(
<vila> rom1: now try: bzr dump-btree .bzr/repository/pack-names --raw
<rom1> :(
<Glenjamin> would it be eaiser to reconstruct the repo from people's branches/checkouts?
<vila> Glenjamin: last resort, yes
<vila> rom1: pack-names is where the pack files *used* by the repo are recorded
<rom1> ok done
<vila> !paste
<ubot5`> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<rom1> http://paste.ubuntu.com/501397/
<vila> hmpf, a single pack file
<vila> rom1: now we need a .pack file with this base name and the associated index files
<vila> rom1: and we need to know whether they are in packs/ dir or the obsolete_packs/ dir
<rom1> found in obsolete
<vila> rom1: depending on the format you use there could be .cix .iix .rix .six .tix index files
<vila> rom1: which ones ?
<rom1> all
<rom1> *ix and pack
<vila> bah
<vila> rom1: then sorry for annoying you, you were just right to begin with :-) Puth them all in the packs/ dir and all should be fine
<rom1> vila : there's no annnoying. Really thx.
<rom1> My concern is about the reason of such a failure.
<rom1> You seem to target the filesystem ?
<rom1> io error, taht's it ?
<vila> rom1: now, bzr move these files *before* creating the new pack-names file, so what you're seeing is X-file-esque, and all reports of such result have *always* been tracked down to a fs failure, generally a system crash
<rom1> :)
<vila> rom1: it's an ordering issue with the file system, things happened in a way that doesn't match what the fs is telling us
<vila> rom1: when operations are buffered and the system crash, *some* operations are lost, somehow :-/
<rom1> ok, get it. It the first and only repository that causes such a failure. It is a huge one, a really huge one. I suspect the time consuming in packing such a repository and something done/undone during that time...
<vila> rom1: but if you *also* have f.pack files that doesn't pass the md5sum check... it's an indication that your hd may be dying...
<rom1> thx vila
<vila> rom1: even ctrl-C'ing a 'bzr pack' should not lead to such a result
<rom1> vila : hope so because with 250 developers, i cannot imagine the mess ;)
<rom1> but the users are always stonger in the worst !
<vila> rom1: now 2.1... we've fixed some related bugs in the last.. monthS, nothing recent, which 2.1.x are you using ?
<Glenjamin> in theory, pushing all the tips should leave you with a complete repo.
<rom1> 2.1.0
<vila> rom1: and your users access the repository with which protocol ?
<rom1> bzr+ssh
<Kamping_Kaiser> are there known problems with pulling LP repos with bzr head? http://paste.debian.net/91961/
<vila> rom1: the last fix I had in mind seem to be part of 2.1.0 already... so I'm pretty sure you're safe on bzr side.. which leave only the fs/crash or hd theories
<vila> rom1: now, as Glenjamin hinted, as a last resort, you can ask all devs to push *all* their branches again... hoping that they didn't locally delete some relying on the server...
<rom1> vila : thx again. I gonna track this disk/repository. If i find something, i keep you informed.
<vila> rom1: thanks
<vila> rom1: at least for the record, it would be good to file a bug mentioning the file sizes for the .pack files that failed the md5sum check
<rom1> ok
<vila> Kamping_Kaiser: you need to upgrade your local repo if I read this right
<vila> Kamping_Kaiser: which will be faster if you compile the extensions too ;)
<Kamping_Kaiser> vila: cheers. i could probably have extratged that from the error, perhaps i'll readit a few more times in future :)
<vila> Kamping_Kaiser: yeah, can be a bit hard to read :-/
<Kamping_Kaiser> :\
<vila> Kamping_Kaiser: but the reward is a faster bzr ! :-D
<Kamping_Kaiser> well yes. but i'd rather it succeeded in doing it automagically ;)
<vila> Kamping_Kaiser: the rich_root frontier is a no return one, this can't be done lightly when many people are involved
<Kamping_Kaiser> vila: the error implies it tried to though. i wouldn't mind it saying 'manually update', i just object to the 'tried, failed, you do it'
<vila> Kamping_Kaiser: hmm, that's convincing :) I don't remember the details though, may be you can file a bug with your rationale to get more feedback or luckily a fix ;)
<Kamping_Kaiser> grrr, i should have seen that coming :p
<Glenjamin> can anyone reproduce the :bound alias not working on lightweight checkouts?
<Glenjamin> example use case: bzr branch; bzr colo-ify; bzr pull -d :bound :parent
<mobby> Hi, I wonder if someone could clear something up for me please? It is to do with the "move" command...
<mobby>  If I have "folder_one/FileOne.txt" and I decide to move things around a bit using windows explorer rather than "move" command
<mobby> so I end up with "folder_two/blah/FileOne.txt", when I do a "bzr status" I get.. removed: folder_one/ folder_one/FileOne.txt, Unknow: folder_two
<mobby> that seems ok
<mobby> so I do a "bzr move folder_one folder_two"
<Kamping_Kaiser> mobby: try --after
<mobby> bzr status gives me - removed: folder_one/FileOne.txt, renamed folder_one/ => folder_two/, unknown: folder_two/blah
<Kamping_Kaiser> yvmf
<Kamping_Kaiser> *yvmv
<mobby> if i try to "bzr move" FileOne.txt I get an error saying it already exists. If I commit I end up with...
<mobby> renamed folder_one => folder_two, missing folder_two/FileOne.txt renamed folder_one/FileOne.txt => folder_two/FileOne.txt
<mobby> but folder_two/FileOne.txt doesn't exist in my working copy
<mobby> is this correct? I'm not saying it's wrong, I'm just trying to better understand Bazaar :)
<mobby> *Kamping_Kaiser I did wonder about --after but seeing as the commands were working without it I assumed it was automatically guessing the "--after" flag
<sysRPL> hello
<sysRPL> a new bazaar user here .... Q: how do i add user accounts to a new bazaar project?
<sysRPL> i.e. i want to allow other people to log into my zerver and check out/check in sources
<rubbs> sysRPL: there is no bzr specific user authentication. bzr respects filesystem permissions, so the best way to allow people access is to create accounts either via ssh/sftp, or ftp. And regulate their permissions with existing user management tools
<rubbs> I'll see if I can dig up a link
<sysRPL> so i need to setup an ftp server?
<sysRPL> i thought bazzar ould BE the server
<rubbs> bzr can be a server, but there is no user authentication. Also bzr's built in server isn't secure for write access. It's ok for read-only access.
<rubbs> http://doc.bazaar.canonical.com/bzr.2.2/en/admin-guide/index.html
<rubbs> This is the admin guide. It may be a little over kill for you, but it covers everything you need. I'll pick out the parts most important to you.
<rubbs> http://doc.bazaar.canonical.com/bzr.2.2/en/admin-guide/simple-setups.html
<rubbs> http://doc.bazaar.canonical.com/bzr.2.2/en/admin-guide/security.html
<sysRPL> okay ... i am on windows here
<sysRPL> no sshd
<sysRPL> i'll explore getting it setup to share via ftp
<rubbs> That link should help you out.
<rubbs> the first one I mean
<sysRPL> hrmmm
<rubbs> http://doc.bazaar.canonical.com/bzr.2.2/en/user-reference/serve-help.html
<rubbs> this might help too. it's the command for serving directly with bzr
<rubbs> http://doc.bazaar.canonical.com/bzr.2.2/en/admin-guide/other-setups.html#direct-smart-server-access
<jml> hello
<jam> hi jml
<jml> we'd like to import non-master git branches in Launchpad
<jml> I heard you guys were doing something that could help us with that
<jam> jelmer has been working on describing the url format to be able to access it
<jam> I'm not 100% sure why it can't be done in just bzr-git
<jam> but he seems to say it still needs changes in bzr itself
<jml> ok.
<jam> I think we settled on http://path/to/something,name with something,branch=name allowed to be more specific
<jml> makes sense.
<jeremiah> Hi :)
<jeremiah> bzr: ERROR: Unknown repository format: 'Bazaar repository format 2a (needs bzr 1.16 or later)\n'
<jeremiah> I'm getting that error ^^
<jeremiah> from launchpad.
<ddaa> you're probably not getting that from launchpad
<jeremiah> Ah, okay. But I am trying to download from Launchpad, that's for sure.
<ddaa> instead, you are probably trying to get a branch in format 2a on launchpad using a version of bzr that's too old
<ddaa> so you get the error from your bzr client
<jeremiah> But my version of bzr is 1.5
<ddaa> so, that's older than 1.16
<jeremiah> Which ought to be older than the required 1.16
<ddaa> later = newer
<ddaa> later != older
<ddaa> so you DO need to install a newer bzr to get that branch
<jeremiah> Well, 1.16 would be released _before_ 1.5
<jeremiah> So presumably 1.5 is newer.
<jeremiah> Hence 1.16 being the opposite, older
<fullermd> Um.  No, 16 > 5.
<jeremiah> Wha?
<fullermd> At least, it used to be.  Who knows what they've done to math lately...
<jeremiah> So 1.50 < 1.16?
<fullermd> 1.5 isn't 1.50.  It's 1.5.
<ddaa> 1.5 < 1.16 < 1.50
<jeremiah> EBADVERSIONNUM
<fullermd> 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16
<ddaa> but there is no bzr 1.50 anyway
<jeremiah> okay, well, I guess I'm off to download a newer bzr.
<fullermd> EVERSIONNUMBERSARENTDECIMALS
<jeremiah> meh.
<fullermd> (and cpp should learn to handle apostrophes in #define's, 'cuz it's really hard for me to misspell "aren't"  :p)
<maxb> Perl is the only thing I know crazy enough to treat versions as floats
<fullermd> I think everything goes through a cycle of trying, with increasingly ugly hacks, until finally giving up and just treating them implicitly or explicitly and n-ples.
<maxb> The Java world annoys me
<maxb> Life would be so much easier if they just adopted debian-style versioning
<fullermd> I know I went for a while trying increasingly rococo schemes before realizing I was being an idiot.
<mtaylor> ok... what's the way I can fix a branch on launchpad to not be stacked on anything anymore?
<fullermd> reconfigure has an --unstacked arg.  Whether it works through LP's black magic I don't know.
<maxb> It does work
<maxb> Provided the old stacking branch exists
<mtaylor> it does. cool
<maxb> Otherwise, we can tell you about more esoteric solutions
 * mtaylor moved the trunk focus branch of a project
<mtaylor> but pushing the new branch wound up stacking it on the old focus (of course)
<maxb> I keep meaning to attempt to write a 'bzr push --unstacked' option
<mtaylor> fullermd, maxb: thanks! that worked and was _hella_ easier than the last time I had to do that :)
<nekohayo> hey there, am I doing something wrong when doing "bzr push lp:~username/project_name/branch_name" ?
<nekohayo> 'cause it returns "bzr: ERROR: Invalid http response for https://xmlrpc.edge.launchpad.net/bazaar/: Bad status line received"
<vila> nekohayo: sounds like a bad proxy, what os/bzr versions are you using ?
<nekohayo> using ubuntu 10.04, but I'm in a SSH tunnel right now (SOCKS in gnome's proxy preferences)
<vila> nekohayo: but if it try to use https instead of bzr+ssh, it's probably because you didn't 'bzr launchpad-login' (once)
<maxb> I believe the thing that resolves lp: URLs doesn't integrate well with proxies. You might like to try manually replacing the lp: with bzr+ssh://bazaar.launchpad.net/
<nekohayo> maxb: is there a bug report about that?
<nekohayo> or should there be?
<nekohayo> vila: nah, I'm logged into launchpad already
<maxb> probably, somewhere :-)
<vila> nekohayo: I'm not sure, it depends on how you configure your proxy... we shouldn't give such an obscure error... but I'm not sure I understand what happens here
<vila> nekohayo: we had bugs with proxies, I don't remember the exact versions, what does 'bzr version' says ?
<vila> nekohayo: there is also a 'bzr ping' plugin that could help validate your proxy
<nekohayo> bzr version 2.1.1
<vila> bug #558343 may apply
<ubot5`> Launchpad bug 558343 in Bazaar 2.1 "NotImplementedError: "should resend request to http://feeds.edge.launchpad.net/bazaar/, but this isn't implemented" during lp name lookup (affected: 17, heat: 105)" [Undecided,In progress] https://launchpad.net/bugs/558343
<vila> ha, may be not ;)
<maxb> feeds?!
<vila> maxb: that message was totally obscure too but coming from lp :)
<mgz> nekohayo: I'd file a bug, your specific symptom doesn't turn up any other bugs though as vila says one of the wider proxy issue ones might cover it
<nekohayo> ok
<vila> nekohayo: or you can just try to file a bug and see if lp find a dupe... mgz types faster :)
<mgz> redoing the (failing) command with -Dhpss and putting that in the bug may help.
<nekohayo> yeah
<vila> and -Dhttp since the error message refers to it
<nekohayo> vila, mgz: putting either -Dhpss or -Dhttp between "bzr" and "push" = same output
<nekohayo> no diff
<mgz> ah, sorry, I meant then paste the contents of .bzr.log for that command
<mgz> (which will have the extra debugging stuff)
<mgz> vila: I've got a fix for tests not having times on babune, but it's ridiculous
<vila> mgz: now you got me interested :)
<nekohayo> filed as https://bugs.launchpad.net/bzr/+bug/649124
<ubot5`> Launchpad bug 649124 in Bazaar "push to launchpad doesn't work through a SOCKS proxy (SSH tunnel) (affected: 1, heat: 6)" [Undecided,New]
<mgz> to get started, here's a picture of the test result classes involved when running selftest --parallel <http://float.endofinternet.org/temp/subcomprehensible.txt>
<nekohayo> thanks folks, gotta go now :)
<maxb> nekohayo: Do you have a moment to try one more command?
<nekohayo> sure
<maxb> Does bzr push bzr+ssh://bazaar.launchpad.net/~kiddo/recipe-manager/performance work?
<nekohayo> damn, my top secret url! :P
<maxb> If so, we can pin the problem squarely on the lp: xmlrpc resolved
<maxb> *resolver
<nekohayo> maxb: yes, it works
<maxb> bug 186920 I think
<ubot5`> Launchpad bug 186920 in Python "bzr xmlrpc client doesn't use http proxy, causing network errors trying to resolve lp: urls (affected: 18, heat: 139)" [Unknown,Confirmed] https://launchpad.net/bugs/186920
<vila> mgz: shudder
<vila> mgz: the time is measured on the wrong side of the process boundary ?
<maxb> nekohayo: According to comments in that bug, apparently bzr 2.2 will handle this better
<maxb> If you are able to upgrade and retest, that would be greate
<mgz> well, subunit doesn't actually time tests, it just has a think that whams timestamps in all over the place
<mgz> anyway, can fix without touching subunit but need changes in both bzr and testtools
<vila> :-(
<vila> will your changes be *compatible with older testtools ? (Installing 0.9.6 on pqm is still pending for... unkown)
<mgz> mmm, good crÃ¨me caramel
<mgz> ^I think so, but working out a way of fixing this without breaking the world (across three projects) was a pain
<vila> mgz: worth mentioning :-/
<barry> hi folks.  i'm working on a branch that adds some functionality to a plugin (bzr-builddeb).  obviously i want to do tdd, but i'm not sure of the right/best way to run tests locally.  i'd like to disable all plugins but run the tests from my working branch of the bzr-builddeb trunk.  the online testing guide didn't help too much with this scenario (or i missed it).  any suggestions?
<james_w> barry: bzr selftest -s bp.builddeb
<james_w> "run all the tests with ids starting with bzrlib.plugins.builddeb"
<james_w> if your local branch is where builddeb plugin is currently being taken from
<barry> james_w: cool.  do i need to fiddle with ~/.bazaar/plugins to point to my branch?
<barry> james_w: ah, i guess "yes" :)
<james_w> if not, then BZR_PLUGINS_AT=builddeb@$PWD bzr selftest -s bp.builddeb
<barry> james_w: nice
<barry> thanks!
<james_w> we're closer to being able to have a test.py in builddeb that runs the tests from where it is invoked from
<barry> james_w: that would be a nice addition
<barry> james_w: what version of python does bzr-bd have to remain compatible with?
<james_w> barry: bzr sticks with 2.4, and I tend to stick with that
<barry> james_w: cool, so no ''.format() :)  (and i'll have to install py24 and py25 from source)
<james_w> barry: yeah, sorry
<james_w> barry: I don't actually test on 2.4 anymore though :-)
<barry> no worries
<barry> :-D
<james_w> it was just that until recently I didn't know any >=2.5 features, so would never write any ;-)
<ScottK> Do it in a Debian VM and you won't have to build 2.5 from source.
<barry> ScottK: yeah.  james_w: 2.6 is a nice sweet spot.  has some great features (.format among my favorites)
<barry> but anyway... thanks
<james_w> I've been enjoying context managers
<james_w> haven't tried .format() yet
<maxb> 2.5 for lucid is still lurking in the launchpad PPA
<maxb> which reminds me, I should propose removing that
<barry> james_w: with statements are highly awesome
 * barry is old skool and builds python from source in his sleep
<barry> james_w: so BZR_PLUGINS_AT doesn't override a different version of the same plugin in ~/.bazaar/plugins, right?
<james_w> barry: I thought it did
<vila> barry: yes it does or it will be useless, or did I misunderstood the question ?
<barry> james_w: oh, nm.  i had conflicting registration code in a differently named plugin
<james_w> hi vila
<vila> james_w: hey :)
<mwhudson> BZR_PLUGINS_AT is awesome, btw
<barry> vila: no, it's pebkac.  i register ubuntu: in bzr-debuntu but i'm moving that to bzr-builddeb ;)
<barry> and testing the latter
<barry> duh
<vila> barry: ouch 8-)
<vila> barry: there is also BZR_DISABLE_PLUGINS, just for you :)
<barry> vila: you guys think of everything! :)
<vila> barry: nah, just hacked it furiously and bzr pqm-submit --two-days-ago
<agruman> is it possible to have a (binary) file in bzr that there is only one version of (ex update will delete old one completely)?
<beuno> agruman, no, not possible
<git__> is there a way to bzr upload to a remote ftp site without having it delete the log file there that's not in the working tree
<beuno> git__, I *think* we added a bzr-upload ignore command with vila a while back
<vila> beuno: hehe almost, there is .bzrupload-ignore file, but don't forget to commit it as it applies to the uploaded revision
<vila> git__: ^
<beuno> that's right
<git__> let me try
<git__> works like a charm, thanks !!!
<vila> beuno: thumbs up !
<beuno> woo
<roryy> huh. launchpad is pretty awesome.
<ddaa> yup
<roryy> g'night!
<mgz> vila: put up both branches for the test timings fix, if you want to give 'em a run on babune. now I can go to bed and have nightmares about being chased by subunit streams.
<vila> mgz: testools branch and bzr.dev branch ?
<mgz> yup.
<vila> urls ?
<mgz> lp:~gz/bzr/use_testtools_timings_625594 and p:~gz/testtools/result_timings_forwarding_625594
<vila> mgz: caveats ?
<vila> mgz: can use this testtools with an unmodified bzr, can we  use this bzr with an unmodified testtools
<vila> mgz: I don't want to sound too demanding, I just want to know what will break if mess things up :)
<mgz> I think it's fine both ways, but the testtools change is more invasive.
<vila> mgz: any significant subset we can try it against crosses your mind /
<vila> mgz: any significant subset we can try it against crosses your mind ?
<vila> -s subset I mean
<mgz> I like bt.test_ or bb.
<vila> oops, wrong branch :)
<vila> mgz: http://babune.ladeuil.net:24842/view/debug/job/selftest-subset-all/ in progress
<mgz> oo, is that new?
<vila> not quite, but the plan is to make it open to devs
<vila> and *that* is not done yet
<vila> http://babune.ladeuil.net:24842/view/debug/job/selftest-subset-gentoo/lastCompletedBuild/testReport/
<mgz> ...I was just pasting that too
<mgz> looks good!
<vila> !
<vila> yup :)
<bialix> good sleepless night, evryone
<vila> finally... we may get some idea why FreeBSD is so slower than the others (I'm pretty sure it's self specific but why...)
<bialix> \o_ vila
<vila> bialix: hey !
<vila> mgz: http://babune.ladeuil.net:24842/view/debug/job/selftest-subset-all/lastCompletedBuild/aggregatedTestReport/
<bialix> \o_ mgz
<vila> ^ is the right page to track for completion
<mgz> hey bialix!
<fullermd> It's slower because bialix isn't sleeping?
<bialix> that will explain many problems
<vila> ...and the solution will be sooo elegant: Hey ! Bialix, go to sleep
<fullermd> To think, AMD and Intel are spending $kadzillions on speeding up CPU's, when they could just spend a few bucks on sleeping pills for you instead.
 * fullermd has a revoluationary new business plan.
<bialix> kill the chicken?
<bialix> or just me
 * fullermd has TWO revolutionary new business plans!
<vila> bill the kitchen >
<vila> bill the kitchen ?
<vila> grrr
<vila> bialix: nah, fullermd is in the goats business now
<fullermd> "Your computer systems too slow?  Pay us $2750 a day and provide a cot, and we'll fly bialix out to your location to take a nap!"
<bialix> man who stares on the goat?
<bialix> fullermd: that won't scale
<bialix> or you need to buy a cloning license as well
<vila> bialix: no, just selling goats to be killed, works better than chickens
<fullermd> It doesn't have to scale; I'll split the proceeds down the middle with you, and I can live very happily on $1375 a day.
 * ddaa applaudes fullermd for his business acumen
 * bialix mutters: a day or a night?
<fullermd> And heck, it'll be great for you; you'll have a boss who never yells at you for sleeping on the job.  What more can you ask?
<ddaa> the thing, is you'll need to sleep 24/7
<vila> bialix: fullermd doesn't care, he lives in a cave, no light there anyway
<ddaa> lest customers start complaining
<ddaa> so maybe it's not such a good deal for you
<bialix> hey ddaa
<ddaa> but at least it will sustain your wife and children ;-)
<fullermd> Well, we price for risk.  For an extra $20k, we'll put bialix into an induced coma.
<bialix> sounds good, but the price is too slow, I think
<fullermd> Well, that's per day.
<fullermd> Anyway, if it kills you, I figure we can keep you from smelling for a week or so, and keep charging them for the extra days.
<fullermd> (I know, it's hard to believe nobody's offering me senior executive positions, isn't it?)
<bialix> yes, it is
<ddaa> I figure ukrainians are essentially imputrescible, with all the vodka...
<vila> mgz: don't forget to add the babune url in your mp
<ddaa> otoh, the french decay very fast, with all the smelly cheese
<fullermd> So, if we cross-bred them, we'd get...   moldy vodka?
<mgz> vila: which one? :)
<vila> mgz: the aggregated one I thin, it gives access to all the details
<vila> oh, hmm, you need in number in there
<vila> http://babune.ladeuil.net:24842/view/debug/job/selftest-subset-all/93/aggregatedTestReport/
<mgz> I've got a free bsd slowness guess.
<mgz> Seems to be on writing to the filesystem. Different sort of tmp partition?
<maxb> abentley: Hi. Could you upload the bzrtools 2.2.0 tarball to Launchpad? Thanks.
<vila> mgz: tmpfs configured there AFAIR but I haven't checked for... pfew, never since I started hudson
<dobey> how does one do _iter_revisions() on a RemoteRepository, since it doesn't seem to have an _iter_revisions() method?
<bialix> dobey: it seems the closest method you can use is get_revisions()
<dobey> yeah, i'm trying that now
<lifeless> _iter_revisions is private ;)
<lifeless> dobey: what are you trying to calculate?
<dobey> lifeless: i have a graph result, and i am iterating over the revisions in it, to get the apparent authors for all the revisions in the set
<lifeless> kk
<dobey> and _foo isn't truly private in python, __foo is though.
<bialix> it's a convention
<lifeless> dobey: __foo is no more private.
<lifeless> dobey: There's no enforcement ever; _ is widely recognised as not-public-thanks.
<dobey> lifeless: trying to access __foo raises an exception.
<dobey> accessing _foo does not
<lifeless> thats because __foo is compiled to __ClassName_foo
<lifeless> or something approximately like that
<lifeless> anyhow
<dobey> anyway, get_revisions() is sufficient
<dobey> thanks
<bialix> dOxxx: hi
<dOxxx> bialix: hey :)
<bialix> can you comment something on bug #505692 ?
<ubot5`> Launchpad bug 505692 in Bazaar Explorer "Bazaar Launcher (dock icon) for Mac OSX (affected: 4, heat: 20)" [Wishlist,Confirmed] https://launchpad.net/bugs/505692
<bialix> dOxxx: ^
<bialix> dOxxx: is it something that Mac installer should provide or?
<dOxxx> bialix: the mac installer should provide an .app bundle for launching bzr explorer, I just haven't gotten around to doing it.
<dOxxx> I think there's already a bug for it on the installer project
<dOxxx> hmmm or not
<dOxxx> ah it's in bzr-explorer project
<dOxxx> https://bugs.launchpad.net/bzr-explorer/+bug/505692
<ubot5`> Launchpad bug 505692 in Bazaar Explorer "Bazaar Launcher (dock icon) for Mac OSX (affected: 4, heat: 20)" [Wishlist,Confirmed]
<dOxxx> err
<dOxxx> ues
<dOxxx> yes
<dOxxx> um
<dOxxx> that's the same bug XD
<bialix> yep
<dOxxx> I can take a look at it, if you like.
<dOxxx> It does seem to be something that should belong to the installer.
<bialix> I need some comment along the bug discussion
<bialix> so I can understand what needs to be done
<dOxxx> ok, I'll add something
<bialix> or change the project to mac-installer
<dOxxx> I'll do that
<bialix> or add mac-installer as affected too
<bialix> something
<bialix> anything
<bialix> dOxxx: thank you
#bzr 2010-09-28
<dOxxx> bialix: do you have any opinion about whether a Terminal window should be visible?
<bialix> for explorer?
<bialix> windows people always beg to hide it
<dOxxx> yes, some of the comments mention that a Terminal window is required for entering ssh passwords
<bialix> and we finally have bzrw.exe for this
<dOxxx> Windows people have PuTTY and it's all-GUI solution for SSH
<dOxxx> I believe on the Mac, paramiko will prompt in the console (Terminal window) for the ssh password if the key has not been added to the ssh-agent
<bialix> paramiko can ask password, and I believe bzr will use the standard bzrlib.ui password propmpt for this
<dOxxx> will bzrlib.ui password prompt display a graphical prompt in bzr-explorer?
<bialix> therefore qbzr should start GUI dialog
<bialix> someone should check, I guess
<dOxxx> hmm ok, I'll experiment with this myself
<bialix> if explorer+paramiko won't start the GUI dialog for password then it's definitely the bug in explorer
 * bialix needs to check on windows too
<dOxxx> bialix: so I just tried it with bzr 2.2.1 and qbzr 0.19.1 -- I get a password prompt in the console window, no GUI prompt
<dOxxx> on Mac
<bialix> that's a bug in Explorer
<bialix> can you file it?
<dOxxx> this was with "bzr qbranch bzr+ssh://user@host/path/to/repo
<dOxxx> ok
<bialix> are you sure you're using paramiko as your ssh client?
<dOxxx> how would I make sure?
<bialix> set BZR_SSH=paramiko will helpto force
<bialix> check the .bzr.log
<dOxxx> aha
<dOxxx> now it shows a GUI prompt
<bialix> usually bzr mutters to .bzr.log which ssh client it's using
<bialix> bingo
<dOxxx> should I still file a bug?
<dOxxx> i.e. that paramiko should be default for Mac?
<bialix> can you open the same branch from Explorer?
<dOxxx> testing
<bialix> and check if it has the GUI prompt
<bialix> I'm not sure about default
<bialix> does ssh (openssh) on mac has ssh-agent>
<bialix> ?
<dOxxx> hmmm different bug... text fields in qbranch window are like 5 characters wide
<dOxxx> was also visible when starting qbranch from cmdline though
<dOxxx> I'll file that separately
<bialix> hmm, for Explorer just use open action, not branch
<dOxxx> ok
<dOxxx> using Open Location in bzr explorer, I get the GUI password prompt
<bialix> good
<dOxxx> Mac does have ssh-agent, I use it myself. It's automatically started at login.
<bialix> thank you
<bialix> if there is ssh-agent then there is no sense to force paramiko as default
<bialix> imo
<dOxxx> so users invoking qbzr from bzr commandline, not from explorer, should be expected to know to set BZR_SSH=paramiko if they want GUI prompts?
<bialix> hmm
<dOxxx> on the other hand...
 * bialix scratched the head
<dOxxx> if they're commandline, then they might be expecting console prompts, it's just a little icky having to switch between the windows
<dOxxx> does paramiko use ssh-agent?
<bialix> I know for sure only about pageant
<dOxxx> let me check quickly
<bialix> I think ssh-agent used by open-ssh clients directly, without paramiko
<dOxxx> well, it looks like it is using keys in ssh-agent
<dOxxx> I don't have the right key though so gimme a sec to get it
<dOxxx> and I can test properly
<dOxxx> bialix: yes, with BZR_SSH=paramiko set, it does use the ssh-agent
<bialix> cool
<spiv> Good morning.
<dOxxx> hi spiv
<poolie> hi spiv, doxxx
<maxb> Does 'bzr --no-plugins selftest bzrlib.tests.test_config.TestGlobalConfigItems.test_absent_user_id' fail for people other than me? (lp:bzr/2.3)
<poolie> i'll try
<poolie> hi mkanat ?
<mkanat> Hey poolie. :-)
<poolie> maxb, wfm
<poolie> really the 2.3 branch?
<poolie> i don't know what's in that
<poolie> normally 2.3 just comes off trunk at this point
<maxb> Well that's perplexing
<poolie> maxb: how does it fail?
<poolie> mkanat: how are things with loggerhead?
<maxb> The test appears to be picking up my id from ~/.bazaar
<mkanat> poolie: Well, I'm having quite a Monday over here. :-) But I'm hoping to get to the testing of the 1-thread solution this week.
<mkanat> poolie: By the way, remember that discussion about releasing 1.18 on the mailing list? Do you want me to actually go ahead and spend the hours to do that?
<maxb> huh. So if I run the exact same command as ./bzr, it passes. Compared to failing if I run it as "bzr" via PATH
<poolie> maxb, ah, i see, vincent recently fixed some bugs like this
<poolie> please file a new one if it's not already known
<maxb> hah, actually, If I run bzr via the path with my cwd being anything other than /home/maxb, it passes
<poolie> mkanat: is it really 'hours'?
<mkanat> poolie: Well, I've never done a loggerhead release before, and I don't know what it entails.
<poolie> mkanat: i'd say for not just make the branch
<vila> maxb: test isolation bug, nice catch, the fix should be a one-liner s/TestCase/TestCaseInTempDir/
<poolie> hi there vila
<vila> poolie: still up ? :D
<poolie> :)
<poolie> and you?
<vila> oh, me, just passing around ;) I'll go back to bed.
<spm> heya vila!
<spiv> poolie: could I interest you in reviewing https://code.edge.launchpad.net/~spiv/bzr/hooks-refactoring/+merge/36101 ?
<spiv> I think the line count must be scaring people off, but it's not too hairy, I promise :)
<poolie> spiv, sure
<poolie> it's not _that_ big
<poolie> compared to john's lp-serve one
<poolie> could i interest you in reading that, if you didn't alreaody?
<spiv> Sure
<poolie> hm i thought i read this already
<poolie> but perhaps i just commented here on irc
<poolie> and i didn't read it in detail
<poolie> https://code.edge.launchpad.net/~jameinel/launchpad/lp-service/+merge/35877
<spiv> Yes, I think I got some brief positive responses on IRC, but no-one prepared to click 'Save comment' apparently ;)
<poolie> :)
<poolie> ok done, tweak
<poolie> hi spiv?
<poolie>  you're going to read john's branch?
<spiv> Hi poolie, yep.
<poolie> thanks
<nprasath002> hi how can i add an existing folder to revision without creating a trunk?? always do i need to create a trunk and add files to it??
<poolie> nprasath002: can you explain more?
<spm> *** FYI codehost is about to go down shortly for a Cherry Pick ***
<spm> and all done
<vila> spm: wow, *that* was short ;)
<spm> vila: hey there!
<spm> yeah, codehost is one of the simpler restarts
<lifeless> there is an RT to make it no-downtime.
<lifeless> *hint*
<vila> hi all !
<vila> poolie: pingeling for a quick chat if you have time for it
<poolie> hi there vila
<spiv> Oof, jam's branch reviewed.
<poolie> yay
<poolie> well done
<poolie> that was a blockbuster branch
<poolie> even allowing the diff including a bit of extraneous stuff
<spiv> The diff was unfairly large due to a some sort of branch targetting snafu, I think.
<poolie> right
<spiv> But yes, quite big even so :)
<poolie> devel vs db-devel
<poolie> "resubmit" is such a harsh color of red :)
<poolie> kind of YOU FAIL IT
<poolie> it should be a kindly burgundy or something
<spiv> poolie: give firefox a custom style sheet to fix it ;)
<spiv> Let's just ditch labels entirely, and review in colours.
<spiv> Review: Taupe
<maxb> Bzr really doesn't like being asked to version a tree with 430k files :-/
<spiv> maxb: using trunk?
<maxb> 2.1.2 actually, I should update this box
<spiv> maxb: trunk has some modest improvements over 2.2 for trees with lots of files.
<spiv> Oh, definitely try trunk (or the latest 2.3 beta, anyway) then.
<maxb> (It's a Debian stable box, at work, you see)
<maxb> Could be worse. We still have bost boxen on oldstable
<maxb> *most
<poolie> vila, so, re releases
<poolie> it seems to me there are factors in tension here:
<poolie> doing several releases all at the same time is perhaps easier than switching in and out of that mode
<poolie> at least i find it so
<poolie> it is somewhat bursty work and you can parallelize a bit
<vila> yeah, but there are long delays involving pqm
<poolie> that's true
<poolie> also, i was going to say
<poolie> if we wait to announce any of them until all of them are done
<poolie> that gives more lag
<vila> exactly
<poolie> (for others, this is http://paste.ubuntu.com/501962/)
<poolie> spiv thanks so much for doing that, i'm sure john will appreciate it
<poolie> now we just  need someone from lp to actually sponsor it
<poolie> once he does those changes
<vila> even if I focus on releasing 2.2.1 first, 2.3b1 is in fact delayed too and also 2.1 and 2.0 and anyway people *misunderstood* when they'll see all the releases
<spiv> Yeah.  I think from LP's perspective I still count as launchpad reviewer, which is probably not really right anymore.
<vila> if we decide to focus on 2.2 and 2.3 only for all users, keeping 2.1 and 2.0 for Ubuntu and whoever want to package them, I think the communication will be clearer
<spiv> So by reviewing I may have actually reduced rather than raised the visibility of that merge proposal.
<poolie> well, we can request a new review
<spiv> Right.
<poolie> john probably wants to resubmit against devel anyhow
<poolie> vila in some ways it's only worth doing an old-branch release when there's a critical fix there
<poolie> that would qualify for an SRU
<vila> poolie: absolutely, that's already what we are doing with 2.0, even if we neglect it a bit too much in this case
<poolie> in some ways i really doubt whether it's worth doing a 2.0.7
<vila> poolie: right
<vila> but then we can't say we support 2.0 if we don't intend to ever fix it
<poolie> if it's true most people running 2.0 are doing that because they're on karmic(?) then they'll need to plan to move soon
<poolie> but otoh the whole world is not ubuntu, and there will be people on debian stable, or rhel
<vila> indeed
<vila> so we can say: we support stable releases for 2 years and will deliver a last release for pending critical bugs at the end of these two years.
<vila> We can than release more for critical bugs if needed but only *during* these two years.
<vila> After two years: please upgrade if you want more fixes.
<vila> At the other end, for the most recent series, we keep doing time-based releases every month
<poolie> i'm not sure we have to make a promise in advance about how many releases there will be
<poolie> it's different to an OS distro where the fixes are being upstream and the question is whether Ubuntu will pass them on to you or not
<vila> yup, we don't promise a *number* of releases, only that there will be *one* last *if* needed
<poolie> istm that most of the people who are not running the current stable series
<vila> I put some in the draft base dof wild guesses
<poolie> are on an old one not specifically because they don't want a major upgrade
<poolie> but because they want to track what their OS ships, and they'll only ship bug fixes
<poolie> to start with the easiest bits: we could say, betas every month, stable series releases also every month
<poolie> and then for the old series, we could just pick a larger window
<poolie> 3, 4, or 6 months
<poolie> probably 6 is unreasonably long for a fix to sit in the branch
<vila> on the other hand we *alrady* backport less and less on 2.0, so less releases de-facto
<poolie> right
<vila> so, the idea is to define rules focused on RM availability and amount of work rather than hard numbers and have a proposed planning to ensure we don't delay some series for too long
<vila> The RM can then just update the planning if a series doesn't need to be released.
<poolie> hm
<poolie> because your patch does seem to propose some hard numbers
<poolie> i don't understand
<vila> incomplete for now
<vila> One major input the how long we support one stable series, 1 year could be the minimum, 2 years seems reasonable. The impact is direct on the number of series we maintain concurrently.
<vila> s/input the/input is/
<vila> hence my feedback request :)
<vila> Ideally there would never be two releases in the same week and at most 2
<vila> even to maintain 4 series concurrently
<poolie> why do you say that?
<poolie> to me it's better to have 4 in one week than 4 in successive weeks
<vila> because then packagers have a lot more work which delay all releases
<vila> and I want to reduce the delay between freeze and release
<vila> because ultimately there is more entropy in such long delays
<poolie> ok
<poolie> so we could stagger from oldest through to newest
<poolie> (maybe stagger is a bad word :)
<poolie> cycle
<vila> stagger ?
<poolie> release 2.0.x, get that packaged and announced, then 2.1.y, then 2.2.z, then 2.3b
<vila> dunno if it's bad but I don't understand it :)
<vila> yes, I would favor that
<vila> which also means fixes on 2.0 bubble quicker than today
<vila> bubble up
<vila> and using separate NEWS files helps for that ;)
<poolie> ok, bubble up
<poolie> i think that's fitne
<poolie> i'd rather construe it as: do 2.0.x through to the finish, then start the next one immediately
<poolie> i don't see much point in waiting, and it seems likely that it will just make things stall there
<poolie> but i don't really mind either way
<vila> there is some value in *not* doing that (2.0 before 2.1, etc): it avoids constraints on 2.3
<vila> we *can* release the backported/bubbled up fixes without releasing 2.0 anyway
<vila> that's what I did yesterday for the run-test-while-build ones
<vila> and that's where I get convinced that splitting NEWS allows more automation
<vila> The current 'process' if far too error-prone (I made several mistakes even if doing it in the same day, as a background-not-super-concentrated way though)
<poolie> ok, so, i think
<poolie> avoiding coupling them together definitely makes sense
<poolie> having some concept on the frequency of releases also does
<vila> sorting releases has one nice result: grep ^2.: gives a nice overview and helps to find when did we fix that,
<poolie> though perhaps it's better to just see that as a maximum and do them when we fix something really important
<vila> so I wrote a little tools/fin-fixed.py to address that which means we don't care anymore and can split NEWS ;)
<poolie> if the RM wants to do them all on one day or a few days apart i don't really mind
<poolie> i feel i would probably try to do them all together
<vila> +1
<vila> this adds some pressure on the packagers though
<vila> ..until we better automate this part
<poolie> right
<poolie> let's just do that more
<poolie> can we broadly agree on updates for old series approximately every quarter year, for two years?
<poolie> subject to what comes up
<vila> we do
<vila> this fits with aligning our series with Ubuntu releases
<vila> which we almost do right now except we didn't clearly state for how long we intend to support the series
<vila> we *could* say: if someone want to maintain a series longer, please do, but... I think we'd better have several different RMs than just forking this part out
<poolie> i'm inclined to go by what people say on the bugs
<poolie> occasionally they'll indicate they're on 2.0.x and want a fix
<vila> so regarding 'it's better to just see that as a maximum and do them when we fix something really important' translates literally to: create anew milestone when you release
<poolie> at least then you know you're specifically helping someone
<poolie> for example we very rarely hear now about 1.x bugs
<vila> indeed
<poolie> i think if 2-3 months have gone by and we have not done a stable series release, we should consider whether we want to do one
<poolie> your spreadsheet is fine as a tool for thinking it over but it feels wrong to consider it firmly scheduled
<vila> but it's open-ended, saying: two years then upgrade, put a sage-guard (sp?)
<vila> that's the intent
<vila> it doesn't make sense to plan two years (hence 4 series) ahead
<vila> I don't know where to keep it though as it's likely a tool we'll want to update every 2, 3 or even 6 months
<vila> hehe
<vila> I *know* where to keep it: where it is right now in ~/src/bzr/releases
<poolie> what's a sage-guard?
<vila> ok, good enough for me the needed feedback unless you have more input ?
<vila> safe-guard /
<vila> safe-guard ?
<poolie> oh ok
<vila> I meant to type safe... of course :)
<poolie> wfm
<poolie> hm
<poolie> i'm not sure i understood what was really important to you here
<poolie> i guess it's that we shouldn't tie all the releases together?
<vila> 2 years
<vila> most important bit
<vila> and the overall idea of making the releases lighter, I'll submit something along those lines in the coming days
<vila> may be today even
<vila> err, I mean something we can discuss of course
<vila> Release provisional planning or Provisional release planning ?
<vila> or Releases provisional planning
<vila> poolie: http://paste.ubuntu.com/501984/ :D
<poolie> heh, just by reading news?
<poolie> neat
<vila> http://paste.ubuntu.com/501986/ for duplicated entries and using a specified file
<vila> yeah just reading NEWS, small step to 1) stop vgrepping NEWS, 2) towards automating tidying up NEWS files and bugs
<vila> oh, regarding configs, quick quizz:
<vila> if I define a variable both in branch.conf and locations.conf, which one is taken into account ?
<vila> all readers are invited to answer, I just want to check what people think about it, so don't test, don't look at the code, just give the first answer that crosses your mind (and no cheating by reading other answers please ;)
<poolie> <poolie> i think locations overrides it, but i think this is not the way it should work, and there is a bug about this
<poolie> vila, a week after the freeze, let's just do the announcement as we planned
<poolie> with whatever installers are ready then
<vila> right, so I'll ... what's the name of the script to copy from propose bzr/proposed to bzr again ?
<poolie> lp-promote-packages i think
<vila> maxb: you confirm we can do that right ?
<poolie> in hydrazine
<maxb> hmm?
<poolie> vila i think we should just fix that, we don't need another conf file
<maxb> "lp-promote-ppa bzr/proposed bzr/ppa"
<vila> poolie: I'm sure some people rely on it
<vila> maxb: thanks !
<vila> maxb: and thanks for making it ready above all !
<vila> poolie: it can be used to override *remote* settings you don't have write access to
<vila> poolie: and whether or not there are valid use cases already used today, I can't answer and don't want to break
<maxb> locations.conf overrides branch.conf, and IT REALLY ANNOYS ME
<lifeless> ditto
<maxb> Because it means that once you set up an appendpath based policy, you can't override it on an individual basis AT ALL
<ddaa> +1
<vila> poolie: but I clearly remember abentley reminding that it was an intent in the original proposal
<poolie> +1
<ddaa> The problem however is that locations.conf definitely should override branch.conf in some cases
<ddaa> like the default parent branch set by "bzr branch"
<poolie> vila i think we may need a plan for setting the priority between them
<ddaa> or the default push branch set by the initial "bzr push" w/o --remember
<vila> I have a plan ;)
<maxb> Well, perhaps we can add a new flag, which, in any given locations.conf section, changes it from "override" to "default" behaviour
<poolie> perhaps like the policy thing, there needs to be a way to make a high-priority setting
<vila> maxb: eeerk
<vila> poolie: eerk
<poolie> what was your plan?
<vila> adding another .conf file will avoid my head exploding
<poolie> doesn't the same issue exist between other config files?
<vila> not now because there is only place (and a half) where we define a hierarchy between conf files
<maxb> hmm. Separate config file means I don't have to specify an option in every locations.conf section
<vila> make that 2.5: bzr-svn, locations/branch and pqm ?
<vila> maxb: it means you specify it in one file or the other
<maxb> on the other hand, I don't like splitting things into multiple files when it can be avoided
<vila> it depends on the variable use
<vila> it seems to me that the feedback is: we want this new file, not locations.conf (including me)
<maxb> It feels more discoverable/explainable to say "to change the priority of this, make a setting", rather than "to change the priority of this, move the content to a file with a different name"
<vila> I can't parse that
<vila> set defaults in defaults.conf, set overrides in locations.conf
<vila> or whatever file name we chose
<maxb> Putting one specific bit of the semantic meaning of a block of configuration into its location, when the rest is in a key/value format, feels kludgy to me
<vila> exactly
<vila> I want policy to be for conf files, not for variables
<vila> append_path being the notable exception
<maxb> Oh, hmm
<vila> but even that may be useless
<maxb> I think you may have just convinced me
<maxb> In a perfect world, we'd rename locations.conf to location-overrides.conf, but aargh compatibility and all that
<maxb> location-defaults.conf could be good
<poolie> ok
<vila> and as a first step I want 'bzr config' to show me what is defined where so I can grasp what is selected in various cases
<vila> *then* we can add repo.conf, wt.conf, project.conf (versioned, propagated), mymum.conf and kitchen_sink.conf but the later may be overkill
<vila> Also, for security reasons (among others) we may also want to define, at the *variable* level where it could be defined (so we can forbid overriding some variables in locations.conf instead of the actual implementation that does it with STORE_* in specific accessors, some end result but declarative instead of procedural)
<vila> s/some end/same end/
<vila> http://paste.ubuntu.com/502016/ woot ! Ok, enough fun.
<vila> poolie: ping, regarding https://code.edge.launchpad.net/~vila/bzr/323111-orphan-config-option/+merge/35690 , I think the discussion and landing this are two different things, care to re-review (the pre-requisite may need a vote too)
<poolie> in a brief skim it looks good
<poolie> i should really go
<poolie> i can read it more tomorrow?
<vila> poolie: sure
<vila> Didn't mkanat said it will report a bug about a test isolation problem about a grabbing its ~/.bazaar/bazaar.conf ?
<poolie> i don't know what 'it' is, but i think there is a bug about that
<poolie> oh, it=max
<poolie> yes
<maxb> .oO( /nick it )
<bialix> vila: how's your feebsd this morning? I'm not really awake so you can expect some speedup...
<vila> bialix: lol
<bialix> bonjour vila :-)
<vila> maxb: he's not online but I typed its nick anyway
<vila> maxb: oooh ! But it wsa *you* not mkanat ! Sry abouth the confusion it was 2:30 AM :)
<vila> maxb: did you file it ?
<maxb> I've made a note to investigate and bugreport properly
<maxb> I think it was around 2:30 AM for me too
<maxb> :-)
<vila> maxb: I reproduce locally.. hehe :)
<vila> maxb: is it close to 11:51 for you right now ?
<maxb> ah, so maybe it was 1:30AM for me. Close enough :-)
<vila> maxb: sure, so we are close time-zone wise, good to know
<Q__x> Hi all
<Q__x> just a question
<Q__x> we are making this very cool game Wesnoth Tactics, we are just beginning...
<Q__x> we have branch that is like 1GB or so
<Q__x> but checkout takes under 400MB
<Q__x> it took me over an hour to commit, adding a single 45KB file
<Q__x> from checkout
<Q__x> is it normal?
<Q__x> is this how bzr should behave?
<Q__x> is there a way for making it work faster?
<ddaa> Q__x: maybe
<ddaa> can you provide the url to a public branch, so people can try it for themselve
<ddaa> in particular, so developers can figure out what's taking so long if they can reproduce the problem
<Q__x> we use this place: http://bazaar.launchpad.net/~wtdevs/wtactics/trunk/changes
<ddaa> oh lite checkout
<ddaa> try using a normal checkout
<ddaa> you really only want to use lite checkouts when the repository is local or on a very fast network
<Q__x> for a price of increasing speed I'd use a branch instead. If I have to aim something this big it doesn't make a difference
<Q__x> but thanks anyway
<ddaa> in bzr, a "checkout" is actually a branch
<ddaa> with some magic that makes it automatically push on every commit
<ddaa> and make commit fail if push would fail because of a divergence
<Q__x> uhm
<ddaa> The "light checkout" is something different
<ddaa> that needs to ask the remote repository for anything
<ddaa> another way of thinking of it is "a plain checkout is a light checkout with a full copy of the history as a local cache"
<ddaa> bottom line being, only use light checkouts if the repository is local or on a fast LAN.
<Q__x> I guess I'm too much accustomized to how SVN works :/
<ddaa> because what you save in initial checkout time, you pay back in slower operations
<ddaa> Q__x: actually, if you just do "bzr checkout" "bzr commit"
<ddaa> it should work right
<ddaa> that's tuned to be easy to svn users
<ddaa> you're just making it complicate for yourself by using a lightweight checkout as a way to try and make it work like svn.
<Q__x> sure, I;m OK with pphilosophy, just don't have a place for all this GBs of our history
<ddaa> then you're out of luck
<Q__x> and time for working with lite checkout often...
<steshaw> ddaa, do you know why the light checkout is slower?
<ddaa> steshaw: I don't KNOW why it's slower in this particular case.
<ddaa> but generally, using a light checkout with a remote repository involves a lot more network traffic
<steshaw> I wonder why is causes more network traffic on commit?
<ddaa> with a normal checkout, the revision data is generated entirely from local data, and bzr only needs to upload the result.
<ddaa> steshaw: because the repository is across the network
<steshaw> ah, I figured it would have enough information locally to manage a commit
<ddaa> nope, use a plain checkout for that
<steshaw> ok, np
<ddaa> there is a perennial wanted feature that would make you happy
<steshaw> I'm been wondering whether bzr has a way to "prune" and "splice" repositories
<ddaa> that's called "history horizons"
<ddaa> but it has complex ramifications and has never been urgent enough to implement
<steshaw> thanks ddaa, I am googling for it :)
<ddaa> if you can't cope with a few GB of history data, just take a couple dozen bucks and buy a new hard drive.
<ddaa> Bought 500GB 2.5" for 50â¬
<ddaa> couple of days ago
<steshaw> I personally prefer a full copy of the repo. I was just curious why the shallow one was slower.
<Kinnison> ddaa: To be fair, it's more bandwidth than storage which makes me anxious for horizons
<Q__x> its incompatible with FLOSS ideology to demant new hardware for developing software, ddaa
<ddaa> Q__x: okay, I'm probably violating some code of conduct by saying that. But That's a stupid statement you just made.
<ddaa> You are working on a project with has hundreds of MB of data.
<Q__x> nah, bzr is just bizarre :D
<ddaa> It's not a matter of ideology, you just need a few GB of storage space to work on that.
<Q__x> yes, hundreds MB of content, but in a year we'll have a half terabyte of data if it will be growing that fast :(
<ddaa> if your repo is polluted by unwanted bulky cruft, you can trim it out with a combination of fast-export and fast-import.
<ddaa> Q__x: nothing specific to bzr there
<ddaa> maybe you do not want a DVCS if you cannot cope with that
<ddaa> you'll have the same problem with git or mercurial
<Q__x> ok, thanks for pointing fast import/export things
<Q__x> it may solve lots of issues to delete the history after the project will be operating more vertically and less horizontally
<ddaa> frankly, I'm not convinced svn would not make you more happy
<Q__x> i think it would
<ddaa> people would still have the option to use bzr-svn if they want
<ddaa> also
<ddaa> bzr-svn provides the option to serve the bzr branch using the svn protocol
<ddaa> mhhh
<ddaa> but that does not work for commit, yet
<Q__x> did'nt knew that :)
<ddaa> bzr-svn is like awesomeness topped with love
<Q__x> frustration, not love in my case
<maxb> bzr-svn is awesomeness
<maxb> The frustration occasionally occurs when it's not ultimately awesome
<Q__x> not, its constantly with me
<maxb> Well, talk to people here, we can probably help :-)
<maxb> I have to admit, it helps a lot that I understand a lot of the guts of bzr-svn now
<Q__x> Just did it, maxb
<maxb> Hmm? I thought the previous conversation was about lightweight checkouts, not bzr-svn?
<Q__x> I don't want to get into guts, really... I need a documentation, guide, working GUI (which is not in latest stable XP version), not a helpful hand, wasting other's time and energy with any minor problem
<Q__x> ok, thanks a bunch once again folks
<vila> maxb: thanks anyway :D
<ddaa> oh, I did not think to ask about windows
<ddaa> lightweight checkouts + windows is probably quite pathologic
<ddaa> because the dirstats don't work very well
<ddaa> ... but people generally don't like it when they are told their filesystem sucks...
<chmouel> hi is it here the newbies question about bazaar?
<ddaa> all questions welcome, just ask, don't ask to ask
<ddaa> you can also check https://answers.launchpad.net/bzr
<vila> jam: ping
<james_w> yay, another inconsistent delta bug
<jam> morning vila
<vila> jam: hey !
<vila> jam: Did you heard about GaryvdM lately ?
<jam> vila: about him? no
<jam> from him? Only on the mailing lists
<vila> yeah, but nothing since 2010-10-24 :-/
<vila> as discussed with poolie, I'll release 2.2.1 without the windows installer
<jam> vila: he just wrote to bzr-explorer-dev about 6 hours ago
<jam> he wanted to release the new bzr-explorer to put it into the windows installer
<vila> >-/ I'm not sunscrined there :-/
<vila> that's subscribed under the sun probably...
<jam> but yes, prior to that the last word from him was 9/19
<maxb> btw, is Andrew Starr-Bochicchio on IRC at all?
<vila> jam: is this clear enough: http://paste.ubuntu.com/502131/
<maxb> I need to ask questions about the qbzr debian branch
<vila> maxb: lp-promote-ppa works like a charm !
<maxb> :-)
<maxb> I really ought to give it --dry-run and --sourcepackagenames options
 * vila sends gratitude to maxb to help ;)
<jam> vila: I would probably swap the first two paragraphs, say what we are doing, then say what it is :)
<jam> otherwise, seems fine to me.
<jam> If we could get ahold of gary, then I'd like to know what's up, but I guess we have  to see
 * vila fixes (and fixes releasing.txt too :)
<vila> jam: me too
<vila> jam: the first one gives feedback to the other ok ?
<vila> jam: or tell Gary :)
<jam> vila: certainly, I'll try emailing him directly. Did you want to release *today*?
<jam> gary's email said he wanted to release bzr-explorer tonight to put it into the installer
<jam> so it sounds like he wants to build it *today*
<vila> vila: I did mail him yesterday. Well, we are already at 10 days after freeze and I updated the ppa already, the OSX installers are ready and people have already dl'ed them, FreeBSD includes it, etc..
<jam> vila: I certainly understand. You did say 5-days
<jam> Its up to you as RM, I was always *really bad* at it.
<vila> :-/
<vila> I'm a noob RM though and accept all feedback :-D
<james_w> maxb: yes, at least something
<james_w> asomething IIRC
<maxb> I don't think I've seen him around then. I guess I'll fall back to mail
<vila> jam: 'announce availability' or 'announce the availability' ?
<jam> vila: well, it is a release, not an rc, so we can just say "we have released"
<jam> the availability stuff is for 'gone gold' and for 'announcing the availability of a release candidate'
<vila> 8-/ This is so passing way above my head :-/
<vila> I mean, the tiny english differences... I think I understand the difference between a micro release and a rc ;)
<vila> Grr, forgot the [ANN] in the subject
<ddaa> I think the general idea is that RC are not "releases" (noun) (as in, not supported), so the verb "release" cannot be used for them
<ddaa> so we use the periphrase "annonce availability"
<vila> ddaa: right so 'announce availability of a new release' is correct, my question is 'announce *the* availability of a new release' was correct too :D
<ddaa> grammatically speaking, I would think both are acceptable
<ddaa> but my point is that it's a mouthful which is better avoided
<vila> yeah, excuse my english I'm French (and also excuse my president...)
<ddaa> Ahem Vincent, tu te ne te souviens plus de moi? Si je me souviens bien, on s'est vu chez Steve.
<ddaa> And I am not any less french than you are.
<GaryvdM> Hi all
<vila> GaryvdM: !!!!!!
<vila> hellllooo, I was beginning to worry that you lost internet connection or even worse :)
<vila> hmm, may be I've been too enthusiastic... GaryvdM ? Still there ?
<GaryvdM> Yes - doing BE release, for first time
<GaryvdM> sorry, timing has just been bad - busy at work
<vila> ouch
<vila> Are you including a *new* be in 2.2.1 ?
<GaryvdM> I hope it's not to different to qbzr.
<GaryvdM> vila: did not understand *new* question.
<vila> Is the BE version you're releasing based on the one included with 2.2.0 or based on trunk or  newer ?
<GaryvdM> vila: Based on trunk, but I could make a cherry picked version.
<GaryvdM> vila: Looking at the log since the last release, it's only really bug fixes.
<vila> GaryvdM: Do your best
<GaryvdM> vila: My gut is to release from trunk, even though I know that deviates from our general procedures.
<vila> GaryvdM: and keep me informed about the windows installers availability ;) I guess you don't know when that will be ?
<GaryvdM> vila: I'm sure I can do it tonight.
<vila> follow your guts ! (Not doing it can lead to weird stuf  ;)
<vila> great
 * bialix waves at GaryvdM
<GaryvdM> Hi bialix
<bialix> heya Gary!
<bialix> if you need my help - say
<GaryvdM> bialix: I had a look at the mp's you wanted to do before the release, but it seemed a bit involved, so I left it.
<GaryvdM> sorry
<bialix> GaryvdM: np, I'm starting 1.1.1
<GaryvdM> bialix: I've tag a release and uploaded the .tar.gz
<bialix> do you want me to upload the installer for explorer?
<GaryvdM> bialix: Yes please. my iscc broken for some reason.
<bialix> ok, will do
<GaryvdM> I can fix, but that would allow be to move on the the bzr installer.
<GaryvdM> bialix: Thanks.
<vila> Do we have https://edge.launchpad.net/~bzr-beta-ppa/+archive/ppa users/testers here ?
<vila> dOxxx: ping
<GaryvdM> jam: How did you normally gpg sign the installer that you built on ec2?
<GaryvdM> jam: Copy and sign locally?
<jam> GaryvdM: upload it to my own machine, sign it, and upload them from there
<jam> yep
<GaryvdM> jam: Ok
<GaryvdM> It's a bit slow for me because of bad bandwidth...
<jam> GaryvdM: if it is on that machine, I can grab it and do the upload if you would prefer
<GaryvdM> jam: And you sign?
<jam> GaryvdM: unless you want to give me your key :)
<GaryvdM> jam: Don't worry, I've already started uploading..
<jam> GaryvdM: does that mean you are done with ec2?
<GaryvdM> jam: nearly
<GaryvdM> jam: Um - also want to do a 2.3 beta build.
<GaryvdM> after this is done.
<jam> k
<jam> just let me know when you are done
<vila> GaryvdM: yeah for 2.3b1 build !! With sugar on top :)
<bialix> GaryvdM: explorer installer has been uploaded
<mushookies> can someone help me I have a problem
<bialix> shoot
<mushookies> I am coding with someone who uses firebug for testing
<mushookies> and commits the code
<mushookies> I want to prevent them from commiting or strip fb()
<bialix> GaryvdM: if needed I'll send announcement tomorrow
<mushookies> from the code beging commit or prvent commit
<mushookies> to a bzr repo
<mushookies> the code is PHP
<mushookies> and i want to prevnet commiting of fb() function
<mushookies> in bzr
<mushookies> were would i begin looking for a solution
<rubbs> mushookies: check out this plugin, it may do what you want: http://doc.bazaar.canonical.com/plugins/en/text-checker-plugin.html
<mushookies> I would even pay someone this is a thorne in my side
<rubbs> doesn't look like it will check for specific text yet, but you may be able modify it to do what you need
<mushookies> this is nice
<mushookies> hmm
<rubbs> alternatively you may be able to use testrunner and write a test that greps for that specific function and dissallow commiting if it doesn't pass. Just an idea
<mushookies> wonder how much effort it would be to code what i need
<mushookies> I guess ill check latter
<mushookies> thanks rubbs
<rubbs> np
<bialix> vila: will you send announcements to bazaar-announce ML?
<vila> bialix: I did for 2.2.1
<bialix> for some reason I haven't received it
<vila> maxb: by the way, you know about the selftest '-s' option right ? (Just filed bug #650001 and realized you didn't mentioned '-s' when you first reported the problem)
<ubot5`> Launchpad bug 650001 in Bazaar "bzrlib.tests.test_config.TestGlobalConfigItems.test_absent_user_id fails when run in $HOME (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/650001
<maxb> Ah, that would be faster, wouldn't it :-)
<vila> maxb: especially in this case, try it
<vila> maxb: also, you can use some shorcuts: -s bt == -s bzrlib.tests, bb == bzrlib.tests.blackbox, bp == bzrlib.plugin
<vila> maxb: and you can use it multiple times -s bb -s bt.test_config
<vila> <blinks>
<vila> lp merge proposal display links for bugs if --fixes was used..... obviously I noticed that before... but didn't realize it aws *useless* to mention it in the cover letter...
<jelmer> maxb: hi
<maxb> hi
<maxb> I imported 2.2.1 using 'bzr merge-upstream' for the PPA packaging. I was wondering if it was worth pushing the result of that import somewhere within pkg-bazaar namespace, and mentioning it on pkg-bazaar-maint, so that it would be available if 2.2.x gets uploaded to Debian anywhere
<maxb> Also, I was surprised to discover that the pkg-bazaar qbzr/unstable branch is ahead of unstable, and wondered if there are any team guidelines that apply
<maxb> s/ahead/ahead by an upstream version/
<jelmer> maxb: I think Andrew pushed to unstable before he knew we shouldn't upload to unstable.
<jelmer> maxb: did you merge-upstream while also specifying the upstream branch?
<maxb> yes
<jelmer> maxb: I'm not sure if it would be useful to push that anywhere. experimental has 2.3b1 already, no new versions will be uploaded to unstable.
<maxb> since 2.3.0 will be out before squeeze is, right
<jelmer> maxb: 2.3 won't make it into squeeze
<maxb> Right, 2.3.0 will be released before testing unfreezes, thus 2.2.x will never be uploaded to unstable ever
<jelmer> maxb: right
<maxb> In that case, I think I should "bzr rm .bzrignore" in the pkg-bazaar branches, since that caused me some consternation when trying to figure out how to drive bzr merge-upstream, until I figured out that the fact it's absent in the tarball means it should be absent in the merge-upstream-ed branch
<jelmer> maxb: I disagree, I think that's a bug in bzr-builddeb. After the first merge where .bzrignore is ignored merge should not try to remove it again.
<maxb> Well, the problem with that option is that the .bzrignore in the packaging branch becomes disconnected from the one in mainline, and does not receive future merges of updates
<jelmer> maxb: An out of date .bzrignore is better than none at all imho. The upstream branch (which you're specifying) has the .bzrignore file though so bzr-builddeb /could/ merge it in.
<maxb> I guess it could. It would be a very weird special case of merging, though
<vila> maxb: I agree with Jelmer. There should a way to say: I don't want to hear from this file, at least in the foreseeable future. Please remind me in six months or when this or that change, but please, don't make it a conflict  each time I merge.
<vila> sudobzr don't conflict (and sudo make me a sandwich ;)
<maxb> The issue is not the conflicts
<maxb> The issue is that there are three 'threads'
<maxb> The upstream thread has a .bzrignore
<maxb> The tarball-mirroring bzr-builddeb-maintained intermediate thread does not
<maxb> And the packaging branch does
<maxb> And changes to the .bzrignore ideally need to be merged from the first to the third
<GaryvdM> 2.2.1 windows installers done.
 * GaryvdM busy updating wiki.
<Kobaz> I just broke bzr... http://pastebin.ca/1950530
<fullermd> Uh oh.  You've got insurance, right?
<Kobaz> heh
<vila> GaryvdM: Yeeeehaaa !
<fullermd> Seems to me that error came out of a mismatched plugin.  bzr-svn maybe?
<Kobaz> i dont think so... the error came all of a suddon, when i did a pull
<vila> Kobaz: while I realize you're not on windows, you may have noticed that bzr-2.2.1 is officially out
<Kobaz> i upgraded bzr to 2.2 just to see if whatever bug happened was already fixed
* 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: jam | Release Manager: vila | bzr 2.2.1 is officially out | bzr-2.0.6, 2.1.3 and 2.3b1 need installers, aTdHvAaNnKcSe ! Some of them are already available, please test !| work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/
<Kobaz> fullermd: i did a bzr pull, a bunch of bzr reverts and bzr resolveds, and then bzr st broke
<vila> Kobaz: can't stay here, but this sounds like a known bug. Did you try to report it ?
<Kobaz> not yet
<fullermd> See if you have any fragments of lock files around?
<Kobaz> what are the filenames
<fullermd> .bzr/branch/lock/, any files in there.
<fullermd> Ditto .bzr/checkout/lock/
<fullermd> And .bzr/repository/lock/
<fullermd> The dirs should all exist, but be empty.
<Kobaz> all empty
<vila> bzr st should barf if any lock was involved methinks, your dirstate file may be corrupted see the FAQ on lp on how to rebuild it
<Kobaz> http://pastebin.ca/1950535
<Kobaz> that's the leadup to the st error
<vila> Kobaz: wow, really sorry I must go, but this sounds like a new bug, mention 'inconsistent delta' in the subject
<Kobaz> k
<GaryvdM> 2.3b1 installers done, and uploading.
<GaryvdM> jam: I'm looking at doing bzr 2.1.3 and 2.0.6 installers. I think the best is going to be to branch lp:bzr-windows-installers from rev 93
<GaryvdM> jam: Ian made comments that the new scripts would not work with 2.0/2.1. I'm not sure why, but I guess I should trust him.
<jam> GaryvdM: I'm sure we could make them work, but I don't think he was trying to get it to work
<jam> so yes, I agree
<jam> just use the old version
<GaryvdM> jam: Ok
<vila> GaryvdM: don't rush on 2.1.3 and 2.0.6, we haven't built them for OSX, debian may not use 2.0.6 either
<vila> GaryvdM: the rationale is that since we 'package' for windows and osx, we don't have to maintain compatibility for 2.0 and 2.1
<GaryvdM> vila: Ok.
<vila> GaryvdM: people can just update to 2.2 since we provide *all* the needed parts
<GaryvdM> jam: I'm done with the ec2 host then. Please shut down.
<vila> GaryvdM: I'd say (to dOxxx and to you now), let's wait for people with good reasons to not update to 2.2 before building them
<GaryvdM> lol
<vila> I will post to the ML on the subject soon, so we can discuss it, but I think 2.0.6 and 2.1.3 installers can wait during the discussion
<GaryvdM> ok
<vila> We already have full plates by releasing a first beta and there will be certainly be a bug pike
<vila> 2.1.3 may never land in debian either AIUI
<vila> FreeBSD maintains the latest stable only
<vila> I'm unclear on gentoo (any user or packager of gentoo around ?)
<vila> but anyway, I'm already talking about distributions based on source which can be released without installers
<GaryvdM> Woot - the beta ppa has 2.3 b1 - nice maxb
<vila> GaryvdM: yup, we are ready to release. I'll release it soon.
<AdvancedGarde> Hello there.
<rubbs> hello
<AdvancedGarde> I'm trying to setup a reposity on my server through sftp. I'm getting ~ "/.bzr": [Errno13] Permission denied
<AdvancedGarde> I'm trying to conect from my windows machine.
<AdvancedGarde> If I try to initialise using the gui, it asks for the password, says authentication successful! then asks for the password again before giving a permission denied error.
<AdvancedGarde> The server is running ubuntu
<AdvancedGarde> What else might you need to know?
<GaryvdM> AdvancedGarde: Can you ssh to the box and do a "ls -la"
<GaryvdM> AdvancedGarde: check what the owner and group is, and what the permissions are.
<GaryvdM> you may need to do a chown/chmod
<vila> If the server is Ubuntu use bzr+ssh instead of sftp
<AdvancedGarde> GaryvdM would you like me to paste the result to a pastebin?
<GaryvdM> AdvancedGarde: Ok - just check for private data.
<AdvancedGarde> You mean, don't paste anything private?
<GaryvdM> Yes
<AdvancedGarde> kk
<AdvancedGarde> http://pastebin.com/5y4SaFef
<GaryvdM> AdvancedGarde: Sorry - should have said - please do this in your branch.
<GaryvdM> AdvancedGarde
<GaryvdM> cd branch
<GaryvdM> AdvancedGarde: What user are you doing the bzr init/push?
<GaryvdM> as
<AdvancedGarde> I've created a user on the server called bazaar
<AdvancedGarde> There is no brance on the server at the moment?
<GaryvdM> AdvancedGarde: Are you doing a init, or init-repo, or push?
<AdvancedGarde> bzr init-repo sftp://bazaar@advancedgarde.co.uk
<magge> good evening. i have a bzr repo where i think theres some files with incompatible filenames. bzr says the following on checkout "exceptions.UnicodeEncodeError: 'latin-1' codec can't encode character u'\uf0f8' in position 60: ordinal not in range(256)". how can i get around that? im on ubuntu, the files were checked in on win.
<GaryvdM> AdvancedGarde: You probably want sftp://bazaar@advancedgarde.co.uk/home/bazaar/my-repo
<GaryvdM> AdvancedGarde: with out that, it's going to try create the repo in the root of your file system.
<AdvancedGarde> xd okay, let me give that a try
<GaryvdM> question to others: do we support sftp://user@server/~/my-repo?
<AdvancedGarde> sexy! that worked. Thanks a bundle. I'd assume it would be working in the home dir.
<GaryvdM> Good night all.
<james_w> mgz: have you seen this before? http://paste.ubuntu.com/502332/
<mgz> ...the actual exception doesn't seem to be in that paste, but... upgrade your testtools from 0.9.4
<james_w> mgz: oh, sorry: AttributeError: 'NoneType' object has no attribute 'decode'
<mgz> ...man, I really don't want testtools to stay 0.9.4 for squeeze or I'm gonna be sauing that a lot.
<mgz> *saying
<james_w> mgz: I don't think anything has changed in the environment, so what causes this?
<james_w> lifeless should update it in sid, and then my environment would update
<mgz> cause is one of my branches having a bug that I didn't find till after landing
<lifeless> squeeze is frozen
<mgz> it's been frozen for a while...
<lifeless> yup
<mgz> I remember for lenny that they let bugfixing minor changes land during freeze
<mgz> but it may not be possible.
<poolie> hi there john
<swebo> hi
<swebo> can i edit the bzr-history? i forgot to add a file at a ci lots of revisions ago. i would be great if i can add it afterwards to a defined revision in the past... is that possible?
<dash> swebo: revisions are immutable, you'd have to essentially rebuild the history
<swebo> can i delete a revision?
<poolie> swebo: you can use bzr-rewrite to make a new better history
<poolie> or more lazily, just uncommit everything back to there and make one big revision that's correct
<poolie> depending on how much you care about keeping the detail
<swebo> hmm or i copy the whole branch and copy the files of each revision to check them in again... that are not so many revisions
<mgz> swebo: if you're thinking about that it's easier to do bzr uncommit --force and bzr shelve --all repeatedly, fix the revision you care about, then unshelve and commit, can even preserve the commit messages with a little copy and paste
<poolie> mgz i wonder what would have happened if you'd run annotate to give a leaderboard for misspelling its/it's :)
<lifeless> I would win.
<poolie> i think so
<mgz> I deliberately resisted that, because I'd be standing in a glass house when it comes to spelling :)
<poolie> :)
<poolie> bug 647588 is a bit poignant
<ubot5`> Launchpad bug 647588 in Bazaar "launchpad plugin doesn't work with Python 2.7 (dup-of: 612096)" [Undecided,New] https://launchpad.net/bugs/647588
<ubot5`> Launchpad bug 612096 in Bazaar "XMLRPCTransport is incompatible with python 2.7 (affected: 8, heat: 53)" [High,Fix released] https://launchpad.net/bugs/612096
<poolie> all that careful analysis and then just closed as an already-fixed dupe :)
<mgz> yeah, man I felt bad about that one
<mgz> I wish the close-as-dupe page was like the other status edit pages and let you put a comment in at the same time, nearly always you want to say something
<poolie> i agree
#bzr 2010-09-29
<Thommas> hello. can someone answer my question. I need different perspective on this issue.
<Thommas> hello
<Thommas> hi
<LeoNerd> Ask your question, don't wait for someone to reply
<Thommas> Should we subsidize child rearing?
<LeoNerd> There's 117 of us in here, we're not all going to say "go ahead"
<Thommas> sorry :/
<fullermd> Sure, but not child fronting.  Child siding is great for property values though.
<Thommas> what about my question. child rearing
<fullermd> I'm not sure.  Is there a bzr plugin for that?
<fullermd> (mind you, I'll bet version control would be handy for that...)
<poolie> !?
<poolie> Thommas: no, i don't think we should
<poolie> or are you talking about children in a vcs tree?
<Thommas> can you tell me y
<poolie> uh, do you have the wrong channel perhaps?
<poolie> lifeless: "ker-lick...."
<maxb> jelmer: Hi. Apparently we still have a narrow window open to slot 2.2.1 into maverick-release. I guess it will be one of us who does the packaging.
<lifeless> poolie: wasn't needed :)
<fullermd> Shucks.  I was looking forward to his plugin   :(
<poolie> maxb, maybe pitti can do it?
<maxb> Does pitti do bzr stuff? I assume he was commenting on the bug in an ubuntu-sru / ubuntu-release approver capacity
<maxb> Anyway, I've already done 2.2.1 in the PPA
<maxb> So really what we need now is some aggressive verification of the PPA build as specified by the microreleasexception
<poolie> ok
<poolie> we should also check the diff by hand there
 * maxb wonders what to call this package
<maxb> 2.2.1-0ubuntu1 I suppose
<poolie> maxb, i'm running 2.2.1 from the ppa on maverick and it looks ok so far
<poolie> and i read the diff, and posted on bug 636930 that it looks ok to me
<ubot5`> Launchpad bug 636930 in Launchpad Bazaar Integration "Upgrading a repository fails with 'Inter1and2Helper' object has no attribute 'source_repo' (affected: 5, heat: 48)" [High,Triaged] https://launchpad.net/bugs/636930
<GungaDin> is it possible to change the message of a commit?
<sidnei> GungaDin, bzr uncommit then bzr commit again?
<stub> So being a Launchpad developer I run with the beta PPA. I just got a crash, and it attempted to go via apport, but apport blocks it as I don't have a genuine Ubuntu package. This workflow might need tweaking.
<sidnei> stub, +1 for fixing that!
<poolie> stub, that's interesting, i thought that was fixed
<poolie> please file a but explaining just what happened
<stub> Bug #391015  is inprogress , which seems to be the apport issue
<ubot5`> Launchpad bug 391015 in Bazaar "apport package hook for Bazaar (affected: 1, heat: 7)" [Medium,In progress] https://launchpad.net/bugs/391015
<stub> Oh - I'm running lucid on my main machine so apport changes might not be backported from maverick
<GaryvdM> jam: Don't know if you are still awake? The ec2 instance is still up.
<poolie> hello GaryvdM
<poolie> GaryvdM: do you want me to shut it down?
<GaryvdM> Hi poolie
<GaryvdM> poolie: Yes please
<poolie> GaryvdM: done
<poolie> do you have a gpg key?
<GaryvdM> poolie: Yes: 018A3A1D
<GaryvdM> poolie: The one you signed previously.
<vila> hi all !
<GaryvdM> Hi vila
<vila> GaryvdM: hey ! You're up early or late ? :)
<GaryvdM> During work. :-) Having a lull after the storm.
<vila> GaryvdM: hehe, thanks for your hard work there !
<poolie> hi there vila
<GaryvdM> poolie: Got the mail - thanks
<poolie> np, thanks for your help
<poolie> hi vila, i might ask pitti about the SRU, if you haven't today
<vila> poolie: ok. Thanks for adding the diff, I should have thought about that...
<vila> poolie: and about the 323111-orphans* reviews ?
<lifeless> poolie: do it asap, RC freeze hit about 5 hours back
<vila> poolie: I'm not sure I understand: "i might ask pitti about the SRU, if you haven't today", can you ping me when you have talked to pitti ?
<poolie> vila i did talk to him
<poolie> apparently it froze a few days ago and it's too late for the release but it can go in as an SRU soon afterwards
<poolie> we should have asked for it sooner
<poolie> vila, we should get maxb or jelmer to upload the package
<vila> poolie: ok, so what should we do then ? ha.ok
<vila> maxb: is it what you were referring to earlier when you said:
<vila> * maxb wonders what to call this package
<vila> <maxb> 2.2.1-0ubuntu1 I suppose
<poolie> right
<maxb> vila, poolie oh, asked I asked ScottK last night and he seemed to think a post-RC release pocket upload was still an option
<poolie> oh, ok
<poolie> well, can you do whatever seems best and legal?
<maxb> Well, I have no upload perms, so I'll have to loiter on IRC and beg a sponsor
<vila> ...and update bug #636930 ?
<ubot5`> Launchpad bug 636930 in Launchpad Bazaar Integration "Upgrading a repository fails with 'Inter1and2Helper' object has no attribute 'source_repo' (affected: 5, heat: 48)" [High,Triaged] https://launchpad.net/bugs/636930
<maxb> Also, anyone know how we decide what bugs to list in debian/changelog?
<maxb> jelmer: around? ^^^
<jelmer> maxb: otp
<maxb> k
<jelmer> maxb: hi
<poolie> hi jelmer, maxb
<maxb> jelmer: Hi. So I started to prepare 2.2.1-0ubuntu1 last night, and of all the minor points, got stuck on wondering how we usually decide what bugs to reference in the debian/changelog
<jelmer> 'morning poolie
<jelmer> maxb: we mention the ones that were closed by this particular release
<jelmer> or more specifically, the ones fixed by this upload since the previous upload.
<maxb> so... everything with a LP id in NEWS?
<maxb> jelmer: ok, my hesitation was that there don't seem to be enough entries under 2.2.0-1 to account for that policy
<maxb> for example,
<maxb> * Recursive binding for checkouts is now detected by bzr. A clear error
<maxb>   message is shown to the user. (Parth Malwankar, #405192)
<maxb> in NEWS but not debian/changelog
<jelmer> maxb: Those bug ids are debian bugs, not launchpad bugs
<jelmer> maxb: where I close bugs with launchpad ids it would only be for bugs that have a ubuntu bug task
<maxb> Ah!, so only list in debian/changelog open ubuntu bugtasks to be closed?
<maxb> rather than the entire contents of NEWS
<stewart> jelmer, hi! i'm having some issues with rebase. I'm basically wanting to rewrite history before a certain revision in the repository so that revision 3 (and all after it) are the same, but that the history from another repository is inserted before revision 3. i can't seem to get it to recognise that the directories named the same in each repo are actually the same (i just get foo.moved)
<stewart> jelmer, any ideas/suggestions?
<jelmer> maxb: yep
<maxb> jelmer: great. Well then, I need to go to work now, but I could put together a package at lunchtime and hunt for a sponsor
<jelmer> stewart: bzr-rebase doesn't really help with different file ids
<stewart> jelmer, i had feared that :)
<maxb> stewart: Maybe you could use bzr-fastexport/import, plus some manual hackery on the streams?
<stewart> maxb, that's my next thought
<mgz> morning all.
<vila> mgz: morning marting ;)
<mgz> ;_;
<vila> mgz: I still have a few minutes to joke about this typo, your fix is playing on pqm ;)
<jelmer> maxb: thanks for taking care of that, btw!
<vila> mgz: wow, I couldn't believe there are *no* thread leaks in bzr.dev (at least in the last runs I did) and just create one to be sure... and it was detected :)
<vila> for the record, when I prepared 2.0.6 there was ~2500 leaks
<mgz> nix had that many? there's still work to do on window, though.
<mgz> and urk, I need to leave already, wanted to review the ~mgordan branch before I went
<vila> mgz: yup, but they tend to be stealth... :-/
<jml> jam: I'm really really sorry I haven't got to your patches yet.
<jml> jam: I haven't forgotten them though.
<zyga> my friend is having problems using bzr send
<zyga> he is behind a firewall
<zyga> and cannot push using regular methods
<zyga> gsc, please pastebin the command you executed and the output of that command
<zyga> it seems that bzr thinks there are no changes between his tree and the public tree
<zyga> gsc, could you do bzr missing and tell us if it shows anything?
<gsc> zyga: Using saved parent location: http://bazaar.launchpad.net/~linaro-maintainers/linaro-image-tools/linaro-image-tools/ You have 1 extra revision(s): ------------------------------------------------------------ revno: 121 committer: r65073 <r65073@r65073-imx51> branch nick: linaro-image-tools timestamp: Wed 2010-09-29 17:09:31 -0400 message:   Add imx51 for --dev option support.
<gsc> zyga: sorry, how to use pastebin, i'm new to irc
<zyga> gsc, go to pastebin.ubuntu.com and paste long output there
<gsc> zyga: and then?
<zyga> gsc, paste the url of the result ehre
<gsc> zyga: how can you guys see that?
<gsc> http://pastebin.ubuntu.com/502582/
<zyga> gsc, could you try a shorter version, bzr send -o foo.bundle
<gsc> http://pastebin.ubuntu.com/502587/
 * zyga has no idea what's wrong
<zyga> vila, ping
<maxb> Please pastebin the output of 'bzr info' in the local branch
<gsc> http://pastebin.ubuntu.com/502588/
<maxb> Ah, you are being caught out by that bogus definition of submit branch
 * zyga never understood what submit branch was
<maxb> It is the default location for 'bzr send'ing against
<gsc> how should I state the submit branch?
<maxb> Just manually edit the .bzr/branch/branch.conf and delete the line defining the submit branch
<gsc> maxb: done. what's the correct one?
<maxb> Or, bzr send --remember actual-submit-branch
<gsc> maxb: i am new to bzr, what's the "actual-submit-branch" in my case?
<maxb> uh, lp:linaro-image-tools, I suppose
<maxb> So, try bzr send -o foo.bundle --remember lp:linaro-image-tools
<gsc> maxb: bzr: ERROR: Connection error: Couldn't resolve host 'xmlrpc.edge.launchpad.net' [Errno -2] Name or service not known
<gsc> maxb: fyi, i am beind a firewall
<zyga> maxb, he's behind a firewall of some kind
<maxb> oh, ok, I guess you'll need to use the long form http://bazaar.launchpad.net/~linaro-maintainers/linaro-image-tools/linaro-image-tools/ then
<gsc> Bundling 1 revision(s).
<gsc> succeded?
<maxb> Sounds like it
<zyga> maxb, thanks :)
<gsc> maxb: then what's the url for my branch?
<maxb> gsc: I don't quite understand your question?
<zyga> gsc, there is none
<zyga> gsc, you did not publish your branch
<zyga> gsc, you made something that you can email
<zyga> gsc, without ssh access you cannot publish a branch on lp
<gsc> understood.  Thanks a lot, zyga and maxb.
<zyga> gsc, well actually you can but it's complex
<zyga> gsc, if you can make your branch visible via http
<zyga> gsc, you could ask launchpad to mirror your branch
<gsc> zyga: sound complicated, forget about it. thanks zyga.
<gsc> quick question: how can I change my name and email output by bzr whoami?
<zyga> gsc, just pass them as arguments
<zyga> gsc 'bzr whoami zygmunt krynicki <my@email>
<gsc> zyga: cool, thanks
<maxb> Don't forget to quote the entire string
<gsc> maxb: yeah, I'm seeing the example in help. Thanks.
<vila> gsc: 'bzr send' uses your 'public' branch to reduce the size of the bundle, so you can use any branch that is in the ancestry of your branch, or even the submit branch itself
<gsc> vila: Thanks for the info
<mgedmin> oh woe is me: I used bzr commit in a svn checkout by accident, now the working dir is all fscked up :(
<mgedmin> oh, look removing $Id$ lines and bzr committing seems to have fixed it
<mgedmin> no it hasn't
<mgedmin> grr!
<mgedmin> in case anybody cares: the error is that on svn commit, I get svn: Checksum mismatch for '/home/mg/src/.../.svn/text-base/filename.svn-base'; expected: '2fa79c790b164142e92763cbafd898b7', actual: '01f96e4634bb165ec8d95c4e6ade8e9e' and it aborts the commit
<jml> vila: do you use an emacs frontend to bzr?
<vila> jml: dvc
<vila> but only slightly, the plan is to move to vc itself
<jml> vila: your plan or someone else's?
<vila> mine :)
<dash> dvc is pretty good
<vila> dvc targets *all* dvcs and progress is kind of slow and I can't... easily parse the weird lisp macros they use (which more or less forbids debugging)
<dash> heh heh
<dash> well it's better than eclipse support for bzr
<jml> dash, vila: know anyone who's actually using vc for bzr?
<vila> it serves me well and did so for the last 4 years but I use only a tiny part of: dvc-status and dvc-diff
<vila> jml: emacs hackers ?
<dash> jml: i have, briefly, but it just didn't do as much
 * jml nods sagely
<dash> the diff support is definitely the dvc feature i use the most
<jml> dash, vila: btw, have I shown you lp:difftodo before?
<vila> jml: ideally vc.el should use direct access to bzrlib instead of bzr
<dash> jml: hm! no
<vila> jml: shown no, mentioned, yes, several times, did I install it ? stupidly no :(
<jml> dash: it's a thing that parses Python diffs, extracts new/modified XXX comments and formats them in a compile-mode friendly way
<dash> Fun.
<jml> there's a bzr plugin in it, and it's pretty easy to hook up to emacs.
<jml> M-x bzr-todo RET
<vila> jml: spawning an external bzr or using python from emacs ?
<jml> vila: spawning.
<vila> :-}
 * vila should stop hoping too much :-/
<vila> jml: sorry, that was totally unrelated to difftodo
<jml> vila: np :)
<vila> jml: anyway, as far as emacs and bzr are concerned, the swiss army knive is still diff-mode IMHO when I'm not editing a file, I'm more or less always in a diff-mode buffer (dvc itself only slightly specialize it by adding a list of files at the top and some navigation)
<vila> jml: which is why I still haven't installed difftodo, 'alt-z m' brings me a 'diff -rsubmit:' buffer where my TODO/FIXME *are*
<jml> vila: ahh, I see.
<jml> vila: sometimes having the list can be useful. it's generated from 'di -r submit:'
 * vila nods
<vila> I still plan to try it
 * vila puts it on its TODO now that it's a wikkid instance
<jml> heh heh
<d1b> hi
<d1b> question what file handles https connections
<d1b> and can you link me to it ?
<d1b> please ;)
<GaryvdM> d1b: I think there are more than one implementations in bzr. one is the std python library urllib2
<GaryvdM> d1b: What for?
<d1b> GaryvdM: i might have a vul to report
<d1b> but first i need to see the code
<d1b> im on a bug reporting spree atm
<GaryvdM> Let me look for you
<mgz> it's known that urllib2 doesn't check certs, it's the main reason it's not the only module used
<GaryvdM> d1b: Hint: bzrlib/transports
<d1b> GaryvdM: thank you - just the file in a http location to your bzr thing
<d1b> GaryvdM: im not looking ;)
<d1b> im just reporting it if exists
<d1b> and i need to see code to do that
<d1b> mgz: please link me
<mgz> pycurl however does check.
<d1b> mgz: but you aren't using pycurl anymore i thought
<d1b> bzr doesn't dep on it
<d1b> iirc
<Glenjamin> it uses it if its there
<d1b> Glenjamin: and if it isn't ?
<d1b> because by default it won't be
<d1b> on ubuntu
<GaryvdM> d1b: it's a suggested dep. Maybe we should bump it to a recommended dep.
<GaryvdM> d1b: A bug report would be good.
<d1b> GaryvdM: dude
<d1b> first link me to the file
<d1b> i might have a real vul to report
<d1b> if you can't do that
<d1b> then fail
<GaryvdM> bzrlib/transports/http/(_pycurl.py|_urllib.py)
<GaryvdM> sorry transport not transports
<d1b> um... http://launchpad
<d1b> link
<d1b>  http://bazaar.launchpad.net/ ...
<mgz> http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/files/head%3A/bzrlib/transport/http/
<d1b> thanks
<d1b> and urllib is used if pycurl isn't available right
<mgz> yup.
<d1b> i have a vul to report
<d1b> 50% sure atm
<d1b> confirming now
<d1b> ok 85% sure
<d1b> by default on ubuntu with bzr installed (as pycurl won't be) you are vulnerable to a mitm attack
<d1b> as per python bug  http://bugs.python.org/issue1589
<dash> d1b: but bzr supports signed revisions, so it doesn't matter. :)
<d1b> as you do not check against hte common name
<d1b> dash: supports != use
<vila> mgz: meh, see my last comment on https://code.edge.launchpad.net/~gz/bzr/use_testtools_timings_625594/+merge/36784
<mgz> yeah vila, I just this second read it.
<vila> mgz: wth ?
<d1b> so by default i can mitm your bzr clients
<d1b> gg
<mgz> d1b, go ahead and file a report, it'll get to the right people.
<d1b> mgz: it shall be done :)
<d1b> ill file it against bzr in ubuntu
<d1b> but it probably applies to debian / every other project who won't have pycurl isntalled
<mgz> vila: I don't quite understand, but I'll try to. this code makes me cry.
<d1b> wait
<d1b> i think you are now deping on it
<d1b> not sure
<d1b> weird
<d1b> im still going to report it, it exists against any client without pycurl installed
<d1b> which is a possability
<vila> d1b: people who care about cert verification should use pycurl
<vila> d1b: this is known
<d1b> vila: yes but aren't told this
<d1b> vila: where is it filed?
<d1b> in bzr?
<d1b>  or told to people
<d1b> where do i report the bug to?
<d1b> nm found it
<vila> https://answers.edge.launchpad.net/bzr/+faq/590
<d1b> vila: that has nothing to do with this bug
<d1b> read what it says
<vila> d1b: I read it long ago
<d1b>  Once certificate validation is implemented
<d1b> for urllib (easy for 2.6), we can get rid of pycurl. For python
<d1b> 2.4 and 2.5 though, that will mean replacing the pycurl
<d1b> dependency by a python-https[1] dependency.
<d1b> that means
<d1b> that the vul im reporting right now
<d1b> is kind of there ;)
<d1b> vila: because
<d1b> ssl was implemented using socket for python 2.6 >
<d1b> in bzr
<vila> d1b: I wrote this faq, I know what is said there :)
<d1b> vila: ok
<d1b> so the comment states that when ssl is done using socket and you aren't supporting 2.5 / 2.4 python -> use that
<d1b> and drop pycurl
<d1b> and your comment here is not really true.
<d1b> because now there is an attempt to validate the ssl
<d1b> that's why socket is used
<d1b> erh ssl()
<d1b> but that implemenation is wrong
<vila> yes, and the plan is to implement the cert verification *on top* of what the ssl module provides
<d1b> vila: at the present time you are vul :)
<d1b> get back to me when that is done
<vila> hehe, patches welcome
<vila> if you want cert verification *now* install pycurl
<d1b> patch is remove urllib
<d1b> only suport pycurl
<d1b> from me ;)
<vila> d1b: sure, as long as you had support for ctrl-c pycurl and prompting for passwords and all niceties provided by urllib ;)
<vila> s/had/add/
<d1b> security >
<vila> d1b: use ssh
<d1b> vila: this is true :)
<d1b> except then you need ssh ;)
<vila> d1b: now you're talking about convenience :)
<d1b> confirmed
<d1b> vila: bzr does not dep on pycurl
<vila> d1b: but more importantly, what will a mitm attack will gives ?
<d1b> a copy of the repo
<d1b> and this is bad for private repos
<d1b> aka your corporate users
<d1b> and also commit access ;)
<vila> which can 1) use pycurl (which is still the default for https if installed) 2) use ssh 3) use private networks
<d1b> vila: if installed
<d1b> but it isn't a dep!
<d1b> it suggests pycurl
<d1b> it doesn't dep pycurl
<d1b> woops!
<vila> no, it was a deliberate decision
<d1b> i should state that this is not true i just remembered
<d1b> i have recommends disabled
<d1b> don't nkow if the default bzr will do that ..
<d1b> suggests will be installed right?
<vila> I advocate keeping it but the consensus was that the vast majority of users just don't verify certs anyway
<d1b> so it should be a dep in anycase
<d1b> and not a suggests
<d1b> ok via synaptic
<d1b> it isn't pulling in pycurl..
<d1b> nor via apt-get
<d1b>  http://pastebin.com/Ec0cJ0eA
<d1b> so recommends is not the same as suggests
<d1b> vila: yeah?
 * d1b reports
<vila> d1b: you'd better add your comments to the existing one so your new bug doesn't get marked as duplicated
<d1b> vila: yeah dude how do i make a new bug?
<d1b> launchpad is confusing
<d1b> nm gotit
<d1b> had to put the url in manually can't find a link
<vila> let me introduce you to our lovely bot: bug #82086
<ubot5`> Launchpad bug 82086 in Bazaar "pycurl transport causes tracebacks if the server's SSL cert cannot be verified. (affected: 3, heat: 43)" [Medium,Confirmed] https://launchpad.net/bugs/82086
<vila> thanks ubot5`
<d1b> vila: ;)
<d1b> vila: reported
<d1b>  https://bugs.edge.launchpad.net/bzr/+bug/651161
<ubot5`> 'Error: Could not parse data returned by Launchpad: HTTP Error 401: Unauthorized\nResponse headers:\n---\ncontent-length: 21\ncontent-type: text/plain\ndate: Wed, 29 Sep 2010 14:20:55 GMT\nserver: zope.server.http (HTTP)\nstatus: 401\nvary: Accept-Encoding\nvia: 1.1 wildcard.edge.launchpad.net\nx-powered-by: Zope (www.zope.org), Python (www.python.org)\n---\nResponse body:\n---\nBug 651161 is private\n---\n (https://launchpad.net/bugs/651161)'
<d1b> private?
<d1b> what no
<d1b> this is already public via irc
<d1b> fixed
<mgz> ha, ubot fail. you ticked the 'security' box I take it?
<d1b> mgz: yeah ;)
<d1b>  https://bugs.edge.launchpad.net/bzr/+bug/651161
<ubot5`> Launchpad bug 651161 in Bazaar "bzr fails to verify ssl validity in https connections - by default --> as pycurl isn't a dep only a suggestion (affected: 1, heat: 260)" [Undecided,New]
<mgz> right, can just edit private off via web interface.
<d1b> there we go
<MTecknology> I pulled a branch, then had to overwrite the latest change to the branch, now I get an error when I try to pull the branch from another location - how can I tell it to ignore this last change?
<MTecknology> It says the branches diverged.. I want them back together..
<vila> MTecknology: pull --overwrite
<MTecknology> :D
<MTecknology> vila: awesome- thanks
<CardinalFang> Hi all, jelmer.  I'm trying to use the bzr-svn plugin for the first time, (with versions in Ubuntu Maverick,) and I can't figure out what I'm doing wrong, if anything.
<CardinalFang> https://android-client.forge.funambol.org/source/browse/android-client/
<CardinalFang> Branching "https://guest@androi" gets me 'unknown bzrdir format ""'
<CardinalFang> No http-basic "guest@" and I get 'No route to host' error (perhaps some SSL problem?).
<CardinalFang> Er, no , that gets me 'Unable to handle http code 401', even though I (think) I set "user = guest" in my locations.conf .
<CardinalFang> Finally, "svn://" gets me the no-route-to-host.
<CardinalFang> Hmm, the doc says the plugin can do several things, but none of them is "branch".  I don't think "pull" counts.
<Glenjamin> CardinalFang: whatever location you'd pass to svn checkout, bzr branch/pull/checkout should accept
<Glenjamin> oh, i see you've got some pycurl problems, try using https+urllib://
 * CardinalFang tries.
<CardinalFang> Hell yeah.  Glenjamin, she goes!
<jeremyw> I see in bzrlib.builtins.cmd_ls.run(), there is a cleanup like this: self.add_cleanup(tree.lock_read().unlock)
<jeremyw> What's that for?
<mgz> jeremyw: it's a slightly confusing spelling of "this operation needs a read lock for the duration, that then gets unlocked"
<mgz> roryy: was hoping to catch you, one of the things we need before your branch can land is for you to do this: <http://www.canonical.com/contributors>
<roryy> mgz: hi.  was wondering about that, assumed the patch was too small
<roryy> mgz: will get on it
<mgz> great, shout if you have any questions.
<jeremyw> mgz: Thanks.
<roryy> mgz: send it to contributor-agreement@canonical.com and Martin Pool?
<mgz> yup.
<roryy> ok, done
<mgz> cool. when australia wakes up you'll get added to the right team.
<fullermd> Australia's so lazy.  Sleeping all day, every day...
<jeremyw> Anyone got a minute to help me better understand locking?  I see this stuff is abstracted in the command logic and I just need to better understand it.
<jeremyw> I think I figured it out and was actually confused by my test repository lacking content.  ;)
<jeremyw> So...let's say I have an Inventory[Directory|File], how might one go about getting the last revision the item was changed in?
<jeremyw> I'm looking into the API but if someone beats me to it...
<ovnicraft> hi folks i was searching for alias for location i want to use for push,pull, etc i search in man but nothing result
<fullermd> jeremyw: BTW, did those docs help you back a week or so?
<jeremyw> fullermd: Yeah.  I am figuring out how to get deeper and deeper.  Now, I've got a working tree and I'm listing the files.  In doing so, I'd also like to get more information like the revision at which the files were last modified.
<jeremyw> Of course your docs don't cover that so I'm tracing the API as I go.
<fullermd> Yeah.  I don't really go below the UI  :)
<jeremyw> fullermd: It helped a lot actually.  I know the difference between the higher level objects and can go between them easily.
<ovnicraft> how i can do this?
<fullermd> ovnicraft: I'm not sure I understand the question...
<jeremyw> fullermd: I need to go below the UI.  It's not difficult.  :)  It just takes some deeper learning and it's coming along nicely, I'm just missing something that takes an Inventory[Directory/File] and gives me revision information.
<roryy> ovnicraft: does "bzr help location-alias" help?
<ovnicraft> roryy, yes i found this http://doc.bazaar.canonical.com/bzr.2.1/en/user-reference/location-alias-help.html
<ovnicraft> roryy, but i have 2 locations for pull
<ovnicraft> i want to bzr pull location1 and bzr pull location2
<roryy> ovnicraft: i'm no expert, i'm afraid.  perhaps you can use a command alias for that ('bzr pl1' and 'bzr pl2') or write two shell scripts or cmd files?
<ovnicraft> bzr must do this hg do it XD
<ovnicraft> btw thx
<roryy> does what?  user-specifiable location aliases?
<mgz> got OOPS-1733N1768 commenting on an mp, but comment seems to have gone through anyway
<ubot5`> https://lp-oops.canonical.com/oops.py/?oopsid=1733N1768
<mgz> hm, don't think I quite worded that properly. ah well, lifeless will understand.
<jeremyw> Does anyone know of a better way to get a revision object, or just the revision id, that a file was last changed based on the file's id?
<jam> jeremw: better than what way?
<jam> tree.inventory[file_id].revision ?
<jeremyw> jam: That might be what I need.  :)  Basically, I've looked at how the log module does it and it's very slow.
<jeremyw> jam: Basically, my intent is to get the last modified revision of a path.
<jeremyw> The quickest way.
<bfrog> is there a large repo that has bzr git and hg versions?
<bfrog> linux?
<bfrog> like there's a hg mirror of the kernel which is useful to compare git and hg with
<fullermd> I presume you could translate one with bzr-git or fast-{im,ex}port if nothing else.
<fullermd> https://code.launchpad.net/~vcs-imports/linux/trunk looks like an import of the Linux kernel.
<bfrog> launchpad, joy, so that'll only take like 10 hours to clone
<bfrog> launchpad has to be the slowest site on the internet to host a project, I never get anymore than about 15kbps from there, meanwhile kernel.org is like 1.5mb ...
 * fullermd shrugs.
<fullermd> I didn't say it was better than a chocolate chip cookie.  Just a good first guess to look for a pile of imports of projects in $OTHER_VCS.
<bfrog> yeah I hear you
<bfrog> its more a complaint towards launchpad than anything else
<bfrog> thanks
<roryy> wow - 3000 branches in vcs-imports
<vila> roryy: you mean https://code.edge.launchpad.net/~vcs-imports ?
<vila> hmpf
<vila> talk about ruining jokes... I was about to propose him to have a look at https://code.edge.launchpad.net/ubuntu
<maxb> oooookay
<thumper> hey
<thumper> anyone have definitive knowledge if bzr reconfigure --unstacked works on LP?
<fullermd> I was told the other day that it does.
<maxb> thumper: yes, it does, provided the old stacking location is valid
<thumper> cool
<thumper> yay
<thumper> now I don't have to write an annoying script
<thumper> does it do it server side or client side?
<thumper> over bzr+ssh?
<maxb> Um. Are stacking changes *ever* clever enough to be server-side?
<jam> maxb, thumper: actually the design is explicit that smart process can't see the stacked-upon repository, so it *can't* be done via bzr+ssh smart rpc
<jam> and thumper, we never had our conversation about Branch Revision
<thumper> jam: ok
<thumper> jam: no, we didn't
<thumper> jam: just in the standup now
<jam> thumper: the joys of daylight savings changes
<tsmith> is it possible to get bzr-svn to remember my svn username and password?
<thumper> tsmith: you can add the username and password in the url
<tsmith> i'm not about to save the password in bash_history :O
<tsmith> but thanks for the tip
<jam> tsmith: I think you can look at "bzr help authentication"
<jam> also, I thought there was something about setting username via svn, which we would then remember
<tsmith> jam: omg that worked (remembering the pass via svn)
<tsmith> thanks
<tsmith> !
<jbowtie> Hello all.
<thumper> jam: are you still around?
<jam> thumper: I actually need to go pick up my son now. if you want to talk via phone, we could talk in about 20 min
<thumper> jam: yeah, that could work
#bzr 2010-09-30
<jeremyw> I have a revision id for a file that was merged into the branch.  I try to get the revno of that revision id and I'm told there is no such revision.  How can you get the revno without looping through all revisions and checking the inventory?
<mmclark> got a question about pushing a shared repo to a server
<mmclark> if i setup a shared repo locally: (e.g. bzr init-repo website ; bzr init website/trunk)
<maxb> poolie: ping?
<mmclark> ... hack on the trunk, and then am ready to push the trunk to a server so others can access it, according to the docs I can do something like....
<mmclark> bzr push --create-prefix bzr+ssh://host/path/to/repos/website/trunk
<mmclark> to create the branch on the remote server.  so far so good...
<mmclark> what I don't get is that locally, in the top-level repo, there's a .bzr folder where (if I understand correctly), files will be shared amongst branches
<mmclark> there's no similar .bzr folder on the server, so it appears there's no sharing.
<dash> mmclark: the repo is for sharing _revisions_ between multiple branches
<mmclark> is that correct?  is the approach above the best way to go?
<mmclark> ok
<dash> mmclark: you have to do init-repo on the server side to get the same thing there.
<mmclark> ok, so if i start by doing a bzr init-repo bzr+ssh://host/path/to/repos/website ...
<dash> haven't tried that, but it might work :)
<mmclark> and then push the branch as I did, then we've got the same scenario both locally and remotely
<dash> right
<mmclark> ok - i'll give that a try.  thanks
<poolie> hi maxb
<maxb> poolie: hi
<maxb> You mentioned that pitti said 2.2.1 needed to be a SRU - I was wondering if you had a link to that, as I got a verdict that a post-RC release pocket upload was still reasonable, said about 24 hours ago
<maxb> either way, I've subscribed ~ubuntu-release and requested an official verdict
<poolie> maxb, he said that in #ubuntu-devel about 16h ago
<poolie> i think it will be in the irclogs.ubuntu.com scrollback
<poolie> if we can do better that's brilliant
<maxb> hmm
<maxb> I think we're hearing a slightly different position from different ~ubuntu-release members, so I guess we'll see what they say in response to me subscribing them to the bug
<poolie> from my experience you'll have to actually poll them not just subscribe them
<maxb> Meanwhile, I think we should try to get some bzr selftest analysis of 2.2.0-1 vs. 2.2.1-0~bazaar1~maverick1 in the bug, in the spirit of the MicroReleaseException
<poolie> it could be good to check the failures are a subset
<poolie> maxb i'll try to do that soon
<jeremyw> Anyone have a minute to help me out with the bzrlib API?  I'm completley stumped.
 * maxb is no expert, but perhaps...
<poolie> jeremyw: sure, just ask
<jeremyw> I have a revision_id and when I try to get its revno, I'm told there is no such revision.  I guess that revision_id corresponds to another repository.
<jeremyw> Is there any way to get the revno without iterating over the whole history and seraching each revision's inventory?
<jeremyw> I asked this earlier but got no response.  Pardon the asking to ask thing...didn't want to waste my time again.
<maxb> What API? Branch.revision_id_to_dotted_revno ?
<jeremyw> I got the revision_id using b.repository.get_inventory(youngest_revision)[file_id].revision
<jeremyw> And I later use b.revision_id_to_revno()
<jeremyw> b is a branch.Branch
<maxb> revision_id_to_revno only consults the mainline
<maxb> Use revision_id_to_dotted_revno
<jeremyw> That helps.  :)  The numbers don't match what 'bzr log' would output but I'm sure I can figure out why.
<jeremyw> How easy was that...ugh.
<maxb> uh, they don't match?!
<jeremyw> Well, basically I'm trying to find the last revision (local) a file was modified.  If I use log.find_touching_revisions(), I get some revisions that I'm comparing this other work to.
<jeremyw> Maybe find_touching_revisions() isn't right?  I'll consult the log.
<jeremyw> Okay...so 'bzr log setup.py' shows 425 as the last modified version while the revision_id_to_dotted_revno returns 424.
<james_w> revision_id_to_dotted_revno returns a tuple doesn't it?
<jeremyw> Maybe my approach is wrong.  What I've done is I use branch.list_files(recursive=False) to get the file_id.  I then use the file_id to get a revision_id it was last modified.  I then am using this API you told me about.
<james_w> that's certainly the approach that I would use
<jeremyw> It returns a tuple...going to see what the pieces mean...maybe there is something I can do to get the exact same number that 'bzr log -l1 PATH' gives me.
<fullermd> The tuple woudl be the components of the [dotted] revno.
<fullermd> So it's 424.something.something; you see it listed on log in 425 because that's the rev that merged those changes.
<jeremyw> If I use log.find_touching_revisions(file_id) and I get the last entry, I get a number that matches the same output as 'bzr log -l1 PATH'.
 * jeremyw reads
<jeremyw> fullermd: So how might I get 425 instead of 424?
<fullermd> Well, 425 is sorta a lie.  Depending on semantics.
<jeremyw> But I don't understand the semantics enough to figure out if my code/approach is borked or I've got it right and the CLI is giving you the lie.
<fullermd> 425 just copied in the changes from 424.whatever.whatever.  Collapsed log shows it because otherwise it couldn't show anything, which is flat wrong.  Expanded log shows it because it's too confusing to have a right-side path without showing where it walked off the left side.
<fullermd> Defining changes is a little tricky with branched history.  In this case, 425 has different contents in that file from 424, so in one sense, it changed.  But it's the same contents as 424.whatever.whatever, which is ALSO a parent of 425.  So in another sense, it didn't change.
<fullermd> What bzrlib is telling you is that 424.something.something is the rev where that was actually changed.
<fullermd> log actually does a fair amount of work beyond that to try and make pretty-understandable output on top of the low-level facts.
<jeremyw> Alright.
<jeremyw> So let's pretend you had a repository browser and I showed you 424 but the cli showed you 425.  You'd be confused right?
<jeremyw> Any thought on how I might be able to remedy this?
<fullermd> 424 isn't the answer.  The answer is 424.something.something.  It's a dotted revno, not on the mainline.
<fullermd> I believe you just glue the tuple bits together to get the full thing.
<jeremyw> Okay.  I see what you mean.  But if I wanted to only track mainline, how could I get 425 without doing it the same way log does, which is really expensive?
<jeremyw> I want to lie.  ;)
<fullermd> Well, I'd suspect if there were a cheaper way to lie, we wouldn't have made log expensive for no reason   :)
<jeremyw> I guess not.
<fullermd> At a high level, you'd need to take that rev you found, and walk forward until you first hit the left path.  That's probably not going to be especially cheap.
<mkanat> I think that it's possible to do some things more cheaply if you only care about mainline.
<jeremyw> Here's what I'm talking about: http://dpaste.com/250788/
<mwhudson> if you build the merge sorted revision graph it's easy enough
<mkanat> jeremyw: Yeah, you might just want to try using bzr-history-db?
<mkanat> If it works outside of loggerhead, that is.
<mwhudson> jeremyw: 3.5 s seems awfully slow, are you read locking the branch?
<jeremyw> Yes.
<mwhudson> and it's a 2a format branch?
<jeremyw> Yup.
<jeremyw> Now you see why I'm trying to do this quicker.
<fullermd> I presume that's 3.5 seconds to do log __init.py ; log docs ; log loggerhead ; [...].  That doesn't sound all that slow to me.
<james_w> there might be a Graph call to get first merged point of A in to B, which is what you want here
<mkanat> mwhudson: I've seen that sort of operation take 3.5s before, many times. Although usually on heavily-loaded systems when working with a large history.
<jeremyw> This is the loggerhead sources...only 428 revisions.
<jeremyw> Not really a large history.
<jeremyw> I mean, I'm reporting against the loggerhead sources, the root of the branch only.
<mkanat> jeremyw: The loggerhead sources are deceptive.
<mkanat> jeremyw: They have lots of large merges.
<jeremyw> Okay.
<mkanat> So the mainline history is short, yeah, but the full history is pretty complex.
<jeremyw> Okay.
<jeremyw> I guess I could save some time by only using the find_touching_revisions() for revision_id that aren't on the mainline.  In the case here, it's roughly 60% of the files listed so maybe I could shave off 1.5 seconds from the 3.5 seconds.
<jeremyw> Not a huge gain but, well, if it's the only way to do it...
<fullermd> Well, the most expensive part is probably building the graph.  And once you do that once (in a single process), reusing it should be pretty cheap.
<jeremyw> I can test this by running the same thing twice?
<jeremyw> That wasn't really a question.
<jeremyw> Shaved off .11s.
<jeremyw> Well, sounds like I'm stuck for now.  Using the log, I get cli/mainline accurate results but suffer a performance hit.  I can dig that since it works and wouldn't prompt confusion.
<jeremyw> One of the biggest hits for log.find_touching_revisions() is that it starts from oldest to newest to create the graph and since I want the last changed revision, I'd need to go backwards.
<jeremyw> I'll try that and see if I can speed things up.
<jeremyw> Thoughts?
<poolie> jeremyw: i thought there was a way to go backwards?
<poolie> i'm pretty sure log from newest to oldest doesn't buffer the whole thing
<mkanat> jeremyw: I think you want bzr-history-db.
<mkanat> jeremyw: Its purpose is to speed up that operation, IIRC.
<mkanat> jeremyw: It's jam1's baby.
<poolie> maxb, there is bug 651706, does that sound familiar to you?
<ubot5`> Launchpad bug 651706 in Bazaar ""problem with the SSL CA cert" when running tests from installed 2.2.1 (affected: 1, heat: 6)" [High,Confirmed] https://launchpad.net/bugs/651706
<jeremyw> You guys are going to laugh...writing my own version of find_touching_revisions() that goes backwards, does it in .79s instead of 3.5s and returns the same results.  :)
<jeremyw> http://dpaste.com/250801/
<jeremyw> mkanat | fullermd | mwhudson: ^^^
<jeremyw> Pretty fricking slick.
<jeremyw> I see that the loggerhead directory entry is missing...I bet I can fix that.  Other than that, it's identical and much faster.
<mkanat> jeremyw: Sounds like find_touching_revisions itself should be fixed?
<mwhudson> that seems more like it
<jeremyw> Well, my approach doesn't care about creating a log output for each revision where it's logged, only the last.
<jeremyw> So I don't think find_touching_revisions is the problem.
<mkanat> jeremyw: In that case, isn't there a better way to do it already, iter_...something?
<jeremyw> To do it backwards or to get the last without the rest?
<jeremyw> I wonder why loggerhead is missing from the output in the third list...
<jeremyw> It was my fault...bad range usage.
<jeremyw> My last paste: http://dpaste.com/250802/
<jeremyw> That shows the final results.
<jeremyw> That isn't fricking bad if you ask me.  :)
<mkanat> jeremyw: Nice.
<jam1> jeremyw: just to mention, find_touching_revisions looks to be a pretty terrible function in general, it grabs the full inventory of every revision in the mainline... going in reverse is an option, but it isn't exactly a great option, anyway yes, for your use case going in 'reverse' makes sense, but just loading "revision_history()" is pretty expensive (think emacs)
<jam1> jeremyw: note that "find_touching_revisions" isn't actually used by log, there is only one user, a hidden command "cmd_touching_revisions"
<jam1> definitely not what I would pick as my starting material
<jam1> as reference, try doing the same thing for bzr's source tree
<jam1> jeremyw: one option is to use "for rev_id in repo.iter_reverse_revision_history(branch.last_revision()):
<jam1> possibly batch them, and then call deltas = repo.get_deltas_for_revisions(revison_ids, file_ids)
<peitschie> hi everyone
<peitschie> is there anyone here that might have a shoulder for crying on?
<fullermd> Will there be cake?  'cuz I'll take a lot of crying for good cake.
<peitschie> hmm
<peitschie> depends on whether i can get it out of bzr lol
<peitschie> so not likely :(
<fullermd> ...   OK, I'll take crying for bad cake too.  I'm not particular.
<peitschie> $: make cake
<peitschie> make: *** No rule to make target `cake'.  Stop.
<peitschie> bugger
<peitschie> i dont have the source
<jeremyw> jam1: I'll look into that.  Would repo.iter_reverse_revision_history(branch.last_revision()) be any lighter than just doing what find_touching_revisions() in reverse would do?
<fullermd> That sounds like a bug in make.  Something that important should be built-in.
<peitschie> i agree... i need to go raise a report i reckon
<jeremyw> jam1: I'll probably spend some time with cmd_log.run() to make sure I'm not doing things completely wrong using any version of find_touching_revisions().
<mkanat> jeremyw: I think that's the method I was thinking of.
<jam1> jeremyw: there are a few things
<jeremyw> jam1: If you know of any way to find the last revision a file was changed that is what you'd use, let me know.
<jam1> 1) just doing it in reverse is a good start for you
<jam1> 2) switching to iter_reverse_revision_history() will help *a lot* for large histories like emacs
<jam1> (think 100k mainline revs, vs 400)
<jeremyw> That's the end result here...based on a path, and potentially a revision, find out when it was last changed.
<jam1> 3) Switching the api to do multiple file-ids at once will be a big win for your use case
<jam1> since otherwise you iterate the same history multiple times
<jam1> 4) If you just want the last modified revision tree.inventory[file_id].revision is that value, but it is the 'actually changed' value, not the last revision which merged the last change
<jam1> 5) lp:bzr-history-db makes it fast to find the mainline revision that merged a given revision by writing out some cached info into a sqlite database
<jam1> (as in, low ms not seconds)
<jam1> I don't remember if I have that specific function encoded, but it would be pretty cheap in the datastructure
<jam1> jeremyw: The loggerhead trunk branch has incorporated bzr-history-db into the main process now
<jeremyw> jam1: Cool.
<jeremyw> jam1: That's the next enhancement I was goign to make to my version of find_touching_revisions_in_reverse, to handle multiple file_ids at once.
<jeremyw> What I'll probably do to finish this learning process is to enhance my version to do multiple file_ids at once and another version doing the iter_reverse_...
<jam1> jeremyw: so if it was me, and I was really concerned about performance, I would grab bzr-history-db, use for file_id in file_ids: revision_id = inv[file_id].revision
<jam1> and then look up the mainline revs for all of those in one go
<jbowtie> peitschie: You don't have the source, because the cake is a lie.
<jam1> def get_mainline_where_merged(self, revision_ids):
<jam1> in history_db.py
<jeremyw> jam1: Pretend that isn't an option right now, bzr-history-db.  I'm trying to learn and add a feature at the same time.  I'd deal with a little loss of performance at this state for a solid understanding by doing it myself.
<jam1> jbowtie: the cake being a lie is the lie. If you play through the whole thing, there is a cake in the closing scene
<jbowtie> fullermd: I'm sure you meant to say "baked in"
<jbowtie> jam1: Yes, a plastic cake. It's a double-bluff.
<jbowtie> On topic, I'm wondering how bzr-history-db interacts with foreign branches.
<jam1> jbowtie: its a cache, it will read the whole history one time, and then incremental in the future
<jam1> but some like bzr-git don't really like incremental for some things. Mostly require you to convert first
<jeremyw> Damn...all attemps are horribly slow on larger repositories, like bzr itself.
<jeremyw> dotted_revno was the fastest.  Too bad there isn't some quick way to get from dotted to merged when there are changes off mainline.
<jeremyw> Maybe that's where bzr-history-db comes in.
<jam1> jeremyw: bzr-history-db
<jam1> :)
<jbowtie> I'm just wondering if I could use it to speed up some of the bzr-tfs operations, particularly those that require mapping back and forth between repositories.
<jam1> Basically, bzr stores a map from child => parent, and you need parent => children
<jam1> so you need a new index
<jeremyw> Trust me, I'm hearing what you're saying.  I just wish I understood enough to avoid it.
<jam1> jeremyw: the problem is the only way to invert child => parent is to walk all revisions, which is expensive
<jam1> there are some bits you can make cheaper, but a lot of things are "it may also be a child but you just don't know it yet"
<jam1> jeremyw: I'd be happy to chat with you to increase your knowledge :)
<fullermd> Oh, it's easy; first you stick the history in a relational database...
<jeremyw> Are there any shortcuts that could be made if it was a hosted, no real changes being made to the branch itself, repository?
<jam1> if you were to say do "branch.repository.revisions.get_known_graph_ancestry([(branch.last_revision,)])" you'd end up with a Graph object that can be traversed bidirectionally very quickly
<jam1> with the pain that it has to always load the whole ancestry
<jam1> fullermd: oh wait, that's already been done :)
<thumper> jam1: sorry for not calling before
<jam1> thumper: np
<thumper> jam1: got dragged out to get a new vacuum cleaner
<thumper> I have a problem with some stacked branches
<fullermd> That sucks   :p
<thumper> where one branch is stacked on another but they share no history
<thumper> particularly when I go reconfigure --unstacked
<thumper> ah poo
<thumper> it is worse
<thumper> lp:ubuntu/language-pack-gnome-yo is stacked on lp:ubuntu/lucid/language-pack-gnome-tg
<thumper> rev 1 of lp:ubuntu/language-pack-gnome-yo is dated after rev 2
<thumper> and rev 2 is a merge of  lp:ubuntu/lucid/language-pack-gnome-tg
<thumper> trying to reconfigure lp:ubuntu/language-pack-gnome-yo unstacked fails
<thumper> poolie: any idea ^^?
<thumper> http://pastebin.ubuntu.com/502991/ is the error
<peitschie> hi everyone... I am wondering if anyone could give me a hand trying to get out debug data for: https://bugs.launchpad.net/bzr/+bug/485601
<ubot5`> Launchpad bug 485601 in Bazaar "missing chk node(s) for id_to_entry maps (affected: 2, heat: 5)" [Medium,Incomplete]
<smoser> anyone know what the issue is here:
<smoser> $ bzr branch lp:ubuntu/maverick/ssh
<smoser> bzr: ERROR: Server sent an unexpected error: ('error', '<Fault -1: "Unexpected Zope exception: CannotHaveLinkedBranch: <DistroSeries u\'maverick\'> cannot have linked branches.">')
<thumper> smoser: yes
<thumper> smoser: poor error message mostly
<thumper> smoser: ssh isn't a package name
<thumper> smoser: try openssh
<thumper> https://code.edge.launchpad.net/ubuntu/maverick/+source/openssh
<smoser> pfft.
<smoser> luser error
<smoser> sorry. thanks.
<poolie> thumper: hi there
<thumper> hi poolie
<poolie> thumper: not immediately obvious to me
<thumper> :(
<jeremyw> Anyone having issues with the bzr branch on launchpad?  I get to 14440k and it stops, every time.
<sladen> probably being stupid, but what's the equivalent to  git am?  (There are lots of ways to /export/ patches as emails, but no obvious way I can see to import them with dates/headers automatically)
<jeremyw> Is there a way to use the bzr source tree as a bzr installation without installing?
<jeremyw> My first thought was to symlink bzrlib into site-packages like I do with mercurial.
<jelmer> jeremyw: that should work
<dash> jeremyw: if you're going to do that, why not do the regular install step?
<jelmer> sladen: "bzr send" can generate bundles that you can "bzr pull" or "bzr merge" like a branch.
<jeremyw> dash: Well, I'm trying to just use the bleeding edge so that when my app is done, I can just say that I support the newest version instead of having to stay up to date.
<jeremyw> jelmer: I was running into trouble with it previously...I'll try again.
<jelmer> jeremyw: what sort of trouble?
<jeremyw> Failing to load compiled libs that would halt branching lp:bzr.
<jeremyw> Hard stop every time at the same point.
<jelmer> jeremyw: none of the compiled modules are required to run bzr
<jeremyw> I know but until I did a real install "./setup.py install --home PATH", it would stop at the same place everytime.
<jeremyw> I can't explain it but I've been troubled by it for 3 hours.  Only when I tried the full install on a whim did things work.
<jeremyw> But that was after my machine crashed the first time because of it, losing about 3-4 hours of work.  :-/
<jeremyw> My fault, I know...
<jeremyw> I lost my work on making find_touching_revisions() 77% faster.  Eff me.
<jeremyw> That was bad math on my part.  It's 3x faster.
<sladen> jelmer: thanks.  The "bundles" were coming from git, after git-bzr bzr-git, fast-export/fast-import all failed
<sladen> jelmer: however, 'git format-patches -k' was working
<jelmer> sladen: hmm - I'd be interested in hearing why bzr-git didn't work
<vila> hi all !
<jelmer> 'morning Vincent!
<vila> jelmer: welcome back in civilized TZ ;-)
<jelmer> vila: I don't think there is anything civilized about waking up at 7AM ;-)
 * jelmer is still slightly jetlagged
<vila> hehe
<poolie> hi there vila, jelmer
<vila> poolie: one word: http://pypi.python.org/pypi/bzr :)
<mtaylor> hey all...
<mtaylor> $ bzr push --remember lp:~haildb-core/ubuntu/maverick/haildb/trunk
<mtaylor> This transport does not update the working tree of: bzr+ssh://bazaar.launchpad.net/~haildb-core/ubuntu/maverick/haildb/trunk/. See 'bzr help working-trees' for more information.
<mtaylor> um - I know that - why is it carping about that?
<vila> poolie: can you reproduce bug #651706 or is it sporadic ?
<ubot5`> Launchpad bug 651706 in Bazaar ""problem with the SSL CA cert" when running tests from installed 2.2.1 (affected: 1, heat: 6)" [High,Confirmed] https://launchpad.net/bugs/651706
<poolie> mtaylor: good question
<poolie> i wonder if it thinks that branch has a working tree for some reason
<poolie> vila, i don't know yet, i've only tried once, will try again soon
<mtaylor> poolie: yeah - it's weird. it doesn't recur, but I had it on one push yesterday too
<vila> mtaylor, poolie : Isn't it something that occur when a .bzr dir is left on the server in some corrupted state ?
<vila> like while a push is interrupted or aborted ?
<mtaylor> vila: ah - that would make sense - I did interrupt a push earlier
<vila> mtaylor: IIRC the next push won't complain, but come back if they do
<mtaylor> vila: they don't. just wanted to report in case that was something you guys didn't know about
<vila> mtaylor: thanks for that !
<vila> mtaylor: really appreciated
<mtaylor> anytime!
<poolie> vila, do you think this issue with svn should block 2.2.1 into maverick?
<vila> poolie: the one involving people with 2.2.1 and 2.1.1 ?
<maxb> Have we figured out why 2.2.0 is behaving differently to 2.2.1?
<vila> Since the bug has been fixed in 2.1.3... there is little we can do if people don't upgrade, so the question is what upgrade paths they can use.
<vila> poolie: so my answer to your initial question is: no, this shouldn't block 2.2.1 for maverick
<peitschie> poolie: i'm originator of the 2.2.0 => 2.2.1 svn email warning today if thats what you're discussing :)
<vila> peitschie: excellent !
<vila> peitschie: so, about 2.1.1, what OS is this ?
<peitschie> vila: we're running windows boxes with clients at 2.1.1, 2.1.2 & 2.2.0... with a smart server (bzr+ssh) at 2.1.1
<peitschie> vila: oh.. the server is debian lenny
<peitschie> vila: i'm working with server guys to get that updated to something more recent... potentially bzr 2.2.0... and all the devs will be jumping onto 2.2.1 tonight
<vila> peitschie: I'd kindly suggest upgrading your windows boxes to the same 2.2.1...you're typing and acting faster than I type ;)
<peitschie> vila: if it's related to https://bugs.launchpad.net/bzr/+bug/485601 or https://bugs.launchpad.net/bzr/+bug/522637  like we suspect, in "theory", reconciling the shared repo and getting all the devs to start clean again should fix it
<ubot5`> Launchpad bug 485601 in Bazaar "missing chk node(s) for id_to_entry maps (affected: 2, heat: 5)" [Medium,Incomplete]
<vila> peitschie: that's the idea yes
<peitschie> :)
<vila> peitschie: I think spiv would have the definite answer here about which versions are compatible with which, but in this particular case, trying to ensure compatibility between all micro versions....
<vila> sounds like a nightmare and a waste of time
<peitschie> vila: are there likely to be issues running 2.2.0 on the server and 2.2.1 on the clients?
<peitschie> vila: I agree... it's one of those things I should have been more attenative to at the time... unfortunateyl we are just getting people creeping into bzr at the moment.  I was being a little too cautious about changing things that hadn't yet broken :)
<vila> AIUI the problem was ghosts coming from bzr-svn no ?
<vila> so if you're now using bzr only they shouldn't come back haunting you
<peitschie> that'd be nice... we've had a few discussions about that, but unfortunately we have several dev tools (TeamCity, JIRA to name a few) that don't play terribly well with bzr at this point
<peitschie> the discussions continue, but this project is a little late already and quite entrenched so I suspect moving to pure bzr may end up impractical... I am trying though :)
<vila> ha, so you're still using bzr-svn somewhere ?
<peitschie> svn is our main commit point actually :S
<vila> in this case, I think only the clients matter anyway
<peitschie> to stop the haunting i have a rather strange design setup here
<peitschie> basically, devs commit to a shared repository on a network server, and then merge these changes into svntrunk
<peitschie> so locally most devs have ghosts all over the place
<vila> but if you upgrade the server, stick to our stable releases, that would avoid this kind of weird interactions
<peitschie> but the shared repo on the server at least has a complete view
<peitschie> vila: is the stable the 2.1.X series?
<vila> 2.2
<vila> so 2.2.1
<peitschie> ahh... awesome
<peitschie> I'm getting the server upgraded to 2.2.0 I believe... all clients will be 2.2.X series on fear of me distributing their parts for them :P
<vila> poolie: I can reproduce #651706 with 2.2.*0*
<peitschie> vila: would there be a significant downside to using 2.2.0 rather than 2.2.1?
<vila> peitschie: well, the bug we're talking about has been fixed in 2.2.1 no ? :D
<peitschie> vila: assuming we both mean https://bugs.launchpad.net/bzr/+bug/522637 :)... it was in 2.2.0
<ubot5`> Launchpad bug 522637 in Launchpad Bazaar Integration "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys (affected: 16, heat: 66)" [Low,Triaged]
<vila> ha no ! 2.2.0 already for #522637
<vila> peitschie: could type a little bit slower to stop making me look like a monkey ? :D
<vila> joke aside, also check the bzr-svn plugin version, but for windows 2.2.1 should be good too
<vila> hmm, jelmer wasn't able to reproduce it so I think this means this was a bzr only issue
<poolie> vila, that's actually really good you can reproduce it there
<poolie> that was going to be my next step
<poolie> so we can just say that on 636930
<peitschie> vila: heheh... if I type faster doesnt that make me *more* of the code monkey?
<vila> peitschie: :D
<peitschie> vila: so basically, 2.2.0 should have this fix, and as far as your aware, 2.2.0 in the server should be sufficient (i won't sue you if your wrong btw... just looking for a gut-feeling/opinion :) )
<vila> peitschie: exactly
<peitschie> vila: much awesomeness! thanks :)
<vila> peitschie: thanks for helping sorting this out quickly ;)
<peitschie> vila: is it worth me sending around another email with the summary of our discussion here? i.e., the difficulty was caused by inconsistent clients... therefore probably a good idea to either bulk upgrade, or tread carefully?
<vila> peitschie: that would be awesome
<vila> maxb: this may sounds strange but can a ppa be used for lenny or any debian if we provide the right packages ?
<jelmer> vila: no, this isn't possible
<vila> darn
<vila> jelmer: can you elaborate a bit ? A on-line explanation would be enough :)
<jelmer> vila: https://bugs.edge.launchpad.net/soyuz/+bug/188564
<ubot5`> Launchpad bug 188564 in Soyuz "Build also packages for Debian in PPA's (affected: 38, heat: 274)" [Low,Triaged]
<jelmer> vila: it might be more useful to get newer bzr releases into the Debian backports though, as that would be the first place where debian stable users look
 * vila reading the bug comments
<vila> Ha, right, build infra
<vila> ok, so this is a WIP
<vila> mgz: FYI, I'm going to revert from py27 on the babune's maverick slave
<peitschie> vila: oh... the bug (#522637) is fixed in the 2.2.0 series... but the 2.2.1 release... so it hasta be 2.2.1 I guess
<maxb> vila: Well, I suggested that peitschie use the hardy packages on lenny. As I said in the email, it's a hacky kludge, but in the specific instance of the bzr package for hardy onto lenny, it seems to work
<maxb> It's absolutely not something to recommend as a general procedure, though
<vila> max, peitschie : sounds like the cheapest alternative for the server admins no
<vila> ?
<maxb> jelmer: Question for you - how would you feel about uploaded 2.2.1 to sid, as a feeder for backports?
<peitschie> sounds like our only option atm really
<maxb> vila: cheapest alternative? It's an option which peitschie can use *right* now, if that's what you mean
<peitschie> max: are there likely to be issues updating to the official backport when that eventually makes it out?
<peitschie> i'm assuming no.. but it doesn't hurt to ask :)
<maxb> peitschie: Well, you do have other options: you could install from source, or rebuild the packaged source on debian yourself :-)
<maxb> upgrading... let me remind myself of backports versioning scheme.....
<peitschie> maxb: i'm assuming that isn't going to be much prettier from the ppa...?
<peitschie> worse comes to worse we can purge bzr and install the official one when it hits
<vila> peitschie: you're right and lp is wrong: http://paste.ubuntu.com/503077/
<peitschie> vila: should I update the bug report at all or just leave things?
<maxb> peitschie: ok, so: 1) I expect what hits backports will be an indentical source package, just rebadged with the appropriate version number, so the only difference will be the build environment, and 2) yes the version number should be greater, so apt should just do the right thing
<vila> peitschie: you mean marking it as fix released in 2.2.1 ? Refresh the page :)
<peitschie> vila: :O... you guys are so speedy here!
<peitschie> maxb: that sounds good.  thanks for checking that for me :)
 * vila try to type faster :)
<jelmer> maxb: That doesn't work, backports have to be created from packages in testing and we won't be able to do a new upload that will end up in testing.
<jelmer> maxb: see the backports FAQ
<vila> poolie: can't reproduce bug #651706 on maverick 8-)
<ubot5`> Launchpad bug 651706 in Bazaar ""problem with the SSL CA cert" when running tests from installed 2.2.1 (affected: 1, heat: 6)" [High,In progress] https://launchpad.net/bugs/651706
 * vila tries harder
<poolie> vila, i thought you just said you could?
<poolie> or you can't reproduce it in a source tree?
<vila> I can reproduce with 2.2.0 system install, I can't with 2.2.1 from sources, but both mention leaking tests...
<vila> ... which I could very easily be persuaded that they are the cause of the transient failure
<vila> I'll try again with the stable ppa installed
<maxb> jelmer: There was mention of it being occasionally acceptable to backport from unstable, I was hoping we could convince people that it was a sensible thing to do
<jelmer> maxb: afaik that only applies to things like security uploads
<vila> poolie: wow, reproduced when running from the ppa version 8-/ That would make the debugging interesting...
<vila> hmm, could that be the test ssl certs not installed correctly...
<poolie> i suspect it's something like that
<poolie> maybe ownership or permissions?
<poolie> or not shipped at all?
<vila> shipped, permissions look correct
<poolie> strace time?
<vila> good idea
<poolie> maxb: still here?
<maxb> hi
<vila> poolie: bingo, we don't install ca.crt...
<vila> poolie: the fix is a one-liner in setup.py, should I target 2.0 or 2.2 ?
<poolie> 2.2, i would say
<poolie> but, hang on, do we really need to install a certificate?
<poolie> this is a made-up one just for running the tests?
<vila> for the test sever yes
<poolie> let's make sure it's not installed anywhere someone could mistake it for a real one
<vila> We had a fix long ago for this, I don't understand why this file wasn't spotted earlier, I guess the fix itself wasn't properly tested or... unexpectedly succeeded :)
<vila> look at /usr/lib/python2.5/dist-packages/bzrlib/tests/ssl_certs
<vila> there is a create_ssls.py there that should make it clear enough
<vila> and the script defines... a rather fictional locality and country code, etc
<vila> even if someone pick it up I strongly doubt it will be able to certify anything dangerous
<vila> poolie: https://code.edge.launchpad.net/~vila/bzr/651706-test-ca-crt/+merge/37109
<vila> go lp go, update this diff ;)
<bialix> GaryvdM: it seems we should made release of qbzr 0.20b1 for bzr 2.3b1, shouldn't we?
<vila> bialix: as long as you release 0.20 for 2.3.0
<vila> bialix: I don't think you strictly *need* to release it, but that will be good
<bialix> vila: qbzr has switched to the 1 major release per 1 major bzr release
<bialix> we did 0.14 exclusively for 2.2
<bialix> we did 0.18 exlusively for 2.1
<bialix> we did 0.14 exclusively for 2.0
<bialix> we did 0.19 exclusively for 2.2
<bialix> and 0.20 will be exclusive for 2.3
<vila> you just *rock* :)
<bialix> vila: this is not the first time you asking this
<vila> blame Alzheimer :)
<bialix> nooo
<bialix> :-)
<vila> bialix: who are you ?
<bialix> man with a headache?
<bialix> I said something bad/wrong/weird again?
<bialix> sorry
<vila> bialix: ideally qbzr, like all plugins that are shipped with stable bzr releases should also define stable series, no ?
<vila> ;)
 * poolie looks
<bialix> what it means: should also define stable series
<vila> bialix: exactly what you listed above :)
<bialix> where I should list them?
<bialix> wiki will be OK?
<vila> lp:qbzr home page even
<bialix> it makes sense
<bialix> should do
<poolie> vila, your patch looks good to me
<vila> poolie: thks, already sent to pqm ;)
<vila> poolie: sry, I should have said it earlier
<poolie> np
<GaryvdM> Hi all
 * GaryvdM was afk, reading back
 * bialix waves at Gary
 * bialix wait a minute and waves again
<GaryvdM> Hi bialix
<vila> GaryvdM: \o_ _o_ _o/ \o/
<bialix> round dance
<bialix> dance vila dance
<poolie> hi gary, bialix
 * vila pumps the volume.... oh wait, no music here ;)
<GaryvdM> So for 2.3b1, I included tip versions of most plugins
<vila> pumps *up* grr
<GaryvdM> including qbzr
<bialix> hi poolie!
 * GaryvdM -> afk
<vila> GaryvdM: which is a good way to make people release official versions :) I fully agree with the idea, but will it work ?
<bialix> GaryvdM: the last bug report about QBzrGlobalConfig said user has 0.19
<poolie> that's all for me, good night
<vila> poolie: g'night !
<vila> poolie: try to give the orphans some love tomorrow ;)
<peitschie> wow... it is that time... i'm off too
<peitschie> thanks for all ur help vila... was very much appreciated
<peitschie> hope ur day/night/afternoon/thing goes well :)
<GaryvdM> bialix: so the have bzr.dev/2.3b1 with qbzr 0.19 - they should just upgrade qbzr
<vila> peitschie: np, your clear reports were also much appreciated !
<GaryvdM> bialix: and i think that we should mark the next releases of qbzr 0.18 and 0.19 as incompatible with bzr 2.3
<bialix> GaryvdM: fine with me
<GaryvdM> bialix: the fix was quite a big change, so I'm in 2 minds about backporting.
<bialix> GaryvdM: backporting what?
<GaryvdM> bialix: the config fix
<bialix> is it only required for 2.2?
<GaryvdM> bialix: It is required for bzr 2.3
<bialix> yep, sorry
<bialix> I don't mind to leve it unfixed in 0.19
<GaryvdM> we were using a _method which got removed
<bialix> so that's our problem
<GaryvdM> yes
<vila> bialix, GaryvdM: Excuse my Alzheimer but which python version is used in the 2.2 and 2.3 installers ?
<bialix> 2.6
<bialix> hate it
<vila> thx
<GaryvdM> bialix: I'm hoping to land lp:~garyvdm/qbzr/log_refactor/ soon
<bialix> cool
<GaryvdM> I'm dogfooding, need to fix some last bugs.
<GaryvdM> It's allready in the threads branch, and working well there.
 * GaryvdM -> lunch
<Glenjamin> I don't suppose anyone's ever deployed the http bazaar smart server wsgi app on gunicorn and proxied through to it?
 * jeremyw goes back to finding the last changed revision of a file...
<awilkins> Ooooh. Bazaar job.
<awilkins> Anyone have an idea what the payscale is :-)
<cody-somerville> awilkins, if its a Canonical gig, you normally negotiate your salary
<awilkins> Scary
<awilkins> Would be sweet to work on something useful though :-)
<tsmith> Hi. I have suffered a tremendous security breach due to BZR and would like to know how to prevent it in the future.
<rubbs> may I ask what the breach was?
<tsmith> Well, it could be *really* bad. Fortunately, only a low-grade site was compromised.
<tsmith> I run (among many other things) a PHP course and detected a security breach on the URL for the third session's final exam.
<tsmith> Basically, someone bzr branch http://mywebsite/final_exam, and it worked, and they ended up with all the (supposed to be secret!) source code.
<tsmith> Since this is basically *impossible* w/ SVN and CVS, I didn't realize BZR allowed this, and I have to know how to stop this for every one of my sites.
<Kinnison> So the security breach was that you published the branch on a public website?
<vila> tsmith: lp:bzr-upload
<tsmith> well my deployment practices have not changed from svn to bzr, so obviously I accept responsibility.  I just want to know what is the proper way to deploy to production?
<Kinnison> Personally I use bzr export
<Kinnison> and then rsync
<Kinnison> but as vila suggests, there's a bzr-upload plugin too
<vila> Kinnison: which is what bzr-upload aims to reproduce ;)
<Kinnison> aah, handy-dandy
 * Kinnison shall add that to his list of things to think about when he has time
<Kinnison> tsmith: another good idea is to put a .htaccess in place which denies access to .bzr
<vila> relying on bzr to calculate which files should be uploaded/deleted/renamed
<Kinnison> that way even if you forget, it will keep you safe
<tsmith> villa: what is the difference between upload and export?
<vila> tsmith: export is one-short, upload is incremental (well, it won't patch your files, it needs to upload them again)
<vila> one-shot :)
<tsmith> So export uploads *everything* but upload is more like rsync
<vila> right
<tsmith> ok that's exactly what i need
<tsmith> thank you very much kind sir
<vila> you're very welcome
<Kinnison> Oh, tsmith, welcome to bzr.  It may confuse you at first, but you'll never want to go back in the end :-)
<tsmith> Kinnison, thanks, but I've been using it since the 0.5 days ;-)
<vila> tsmith: wow, you beat me ! I think I started in the 0.7 days ;)
<awilkins> tsmith, And take comfort from the fact that I've clipped that IRC log for an internal training course :-)
<tsmith> an internal training course on how to avoid loss of source? :)
<awilkins> I'm talking about general VCS and specific issues migrating to DVCS
<tsmith> awilkins, ok, cuz I had no idea this **could** happen.
<tsmith> i use bzr+ssh:// for everything
<tsmith> i am pretty sure i'm not the only one, too
<tsmith> bzr: ERROR: Invalid http response for http://repo.phpexperts.pro/driving_app/.bzr/branch-format: Unable to handle http code 500: Internal Server Error
<vila> tsmith: yup, that was one of the reasons to write bzr-upload in the first place
<tsmith> <-- success
<vila> geez, that was fast !
<vila> tsmith: 7 minutes between answer and tested deployment 8-)
<tsmith> well i already implemented upload on incendiary.ws
<tsmith> bzr branch http://www.incendiary.ws/ if you want to help me QA
<tsmith> lol
<tsmith> and the site still seems to live
<tsmith> ok cheers, guys
<mgz> vila: thanks for the heads up on babune maverick change
<mgz> right thing as we're approaching 10-10-10, and I think I have a handle on the remaining python 2.7 issues
<mgz> (though I need to file bugs on a few still)
<exarkun> What are my options if I have a branch with private stuff in it that I want to make public?
<mgz> probably the import/export thing to make a new history
<exarkun> By "new history" you mean a history beginning after all the current history?
<mgz> well, presuming the private stuff you don't want to make public was there to start with, I mean a completely recreated history with that ommitted
<dash> exarkun: it's pretty hard to publish a branch without publishing all the revisions in it, AFAIK.
<mgz> see the bzr-fastimport plugin and using that to filter out certain things.
<exarkun> mgz: I don't see how export/import would recreate the history.  It looks like it just bundles up a particular revision into an archive.
<mgz> 'export' was confusing, forget I used that word.
<exarkun> ah, ok
<exarkun> The other half of the question, I guess, is where people keep their private stuff.  In a separate branch that's not published?
<mgz> depends what you mean by private I guess, if it's code, then yeah. config stuff is often just in the tree but unversioned
<exarkun> in this case it's python source, but it's really configuration.
<exarkun> Hm, maybe I should make someone implement X509 based authentication
<exarkun> Then it wouldn't actually need to be private, I think
<mgz> yeah, making it not need to be private would be the best thing, if it's practival
<vila> mgz: exactly (about maverick). python-2.7 seems to have survived to the operation though, I don't where I got the idea that it was installed by default, in fact I had a symlink in ~/bin, so it's still possible to use python2.7 explicitly for focused tests
<mgz> vila: do you know if Gary or Alexander are working on bug 632465 or should I fix it tonight?
<ubot5`> Launchpad bug 632465 in Bazaar Windows Installers "bzr.exe tried to use the system msvcrt90.dll from system32, not the bundled one (affected: 2, heat: 16)" [Critical,Confirmed] https://launchpad.net/bugs/632465
<vila> mgz: no idea, sry :-/
<vila> mgz: but bialix mentioned a workaround right ?
<vila> There is something more... but I don't remember what
<mtaylor> hey lovely people...
<mtaylor> ValueError: We are missing inventories for revisions: [StaticTuple('jaypipes@gmail.com-20100924204917-evjhm0hc7s5t25ol',)]
<mtaylor> I'm getting a fail when I'm trying to commit to a lightweight checkout ^^
<rockstar> jam, mtaylor is having issues with a lightweight checkout and the remote repository, but I don't know how to help him debug.
<GaryvdM> mtaylor: Please could you pastebin the traceback. I don't think I can help, I'd like to learn more, and having the traceback will tell me what to read.
<mgz> argh, buildout is massive bullshit
<mgz> GaryvdM, are you looking at the manifest thing? because I've not even got as far as getting buildout past the "download stuff" stage yet
<jeremyw> jam: I don't care what everyone else says about you.  You're a gentleman and a scholar.
<GaryvdM> mgz: I'm not, cause I don't know where to start.
<mgz> okay, well, I'm pretty sure I can fix it easily, but I hate build stuff and am failing to actually get to step 0: get installer built
<mtaylor> GaryvdM: yes! .. one sec
<mgz> buildout is currently managing to break my bzr installation by somehow intruding it's bullshit isolation across to the subprocess
<GaryvdM> mgz: please pastebin buildout error. I may be able to help.
<mgz> and actually debuging anything is a pain because everything's in zips that always get redownloaded
<mgz> the error is trivial, gf.recipe.bzr tries to run `bzr get ...` and buildout has screwed with the environment so that it can't find bzrlib
<mtaylor> GaryvdM: http://paste.openstack.org/show/36/
<mtaylor> jam: ^^^
<mgz> I could work around by sticking an installered bzr.exe on the path, but this is dumbness I want fixed
<GaryvdM> mgz: That's the setup on the build host.
<GaryvdM> mtaylor: Thanks.
<mgz> right, there are probably a selection of things that happen to work with how the build host is setup but not on my machine
<mgz> I've avoided a few already.
<mgz> and the buildout docs suck, of course.
<mgz> when is this ever not true.
<GaryvdM> mtaylor: That is happening in autopack. I wonder if the same happens on a manual bzr pack ?
<mtaylor> GaryvdM: can I run that?
<mtaylor> GaryvdM: trying
<GaryvdM> mtaylor: yes
<mtaylor> GaryvdM: bzr pack seems to have fixed the tree
<mtaylor> rockstar: ^^
<rockstar> mtaylor, hooray!
<jeremyw> Anyone that was following my work yesterday to get the last changed revisions for a directory of files: http://paste.ubuntu.com/503509/
<jeremyw> Check those numbers out.
<jeremyw> Thanks to jam I was able to identify the approach that yielded the best results.  :)
<GaryvdM> mtaylor:  hmm - If autopack failed, and pack passed, that's a bug in autopack then.
<rockstar> jeremiah, nice.
<mtaylor> GaryvdM: w00t! I'm helpful
<rockstar> Er, jeremyw... ^^
<jeremyw> Going from 115s to 0.8s...wow.
<jeremyw> And that's without bzr-history-db.  ;)
<GaryvdM> mtaylor: I think we should try log a bug.
<jeremyw> Using find_touching_revisions() going backwards, insted of 1...N, would produce a time ~30s.  I don't have that metric in here.
<mtaylor> GaryvdM: agree
<GaryvdM> mtaylor: I think it's bug 437003
<ubot5`> Launchpad bug 437003 in Bazaar 2.0 "Failure to autopack because of 'missing inventories' (affected: 4, heat: 15)" [High,Confirmed] https://launchpad.net/bugs/437003
<GaryvdM> jeremyw: May I ask what are you building?
<jeremyw> A rocketship powered by the heat generated by producing a rev_id to mainline_rev_id map.
<jeremyw> ;)
<jeremyw> This code is for a repository browser.
<mtaylor> GaryvdM: yes. I agree with you
<GaryvdM> jeremyw: Ah.  For web, gui, or cli?
<jeremyw> Web UI
<GaryvdM> jeremyw: Ah cool.
<GaryvdM> jeremyw: KnownGraph rocks...
<GaryvdM> so dose jam!
<GaryvdM> *does
<jeremyw> The KnownGraph is great but when merge_sorted(), it's a freak of nature.
 * jeremyw feels his bzrlib kung fu getting stronger...
<mgz> is this really true? bzr-windows-installers requires gnu make... just to build windows html help... and there are batch scripts in the bzr tree it could be using anyway
<jeremyw> Ouch.
<jeremyw> How's the Bazaar installer for OS X?
<mgz> that's handled somewhere else entirely I think, you'd need to ask Gordon Tyler
<jeremyw> Cool.
<jeremyw> Just figured I'd ask while we were on the subject of installers.
<poolie> hi all
<FryGuy_> is there any way to do a reverse merge? currently i'm in a checkout of a branch, but I want to switch to another branch, and merge the first branch into the branch I'm going to. If I do a switch then merge it's going to complain about having to delete folders that have temporary files in it, when they're just going to be created again
<poolie> FryGuy_: not quite
<thumper> poolie: hi
<poolie> you could delete the temporary files with clean-tree
<poolie> or make another checkout
<FryGuy_> ya, i was figuring that's the case
<thumper> poolie: I have a local example of the unstacking failure
<thumper> poolie: but it is about 10 meg
<FryGuy_> i don't want to have to rebuild the source though, which is why i didn't do it that way
<thumper> poolie: where do you want it?
<FryGuy_> and checkout takes like 5 minutes to get all the source :(
<poolie> thumper: make a bug and attach a url
<poolie> maybe you should branch locally?
<FryGuy_> it is local
<thumper> poolie: do you want the branches tarred up and put in the librarian or people.c.c
<FryGuy_> it's like 500 megs
<poolie> people.c.c
<FryGuy_> and my hard drive is slow
<poolie> ok
<poolie> it would be nice to add an option to merge in reverse order
<FryGuy_> a merge --switch option?
<poolie> hi jam?
<poolie> something like that
#bzr 2010-10-01
<FryGuy_> whoops wrong button
<FryGuy_> i'm not used to using trillian for irc
<FryGuy_> also, is the person that made the bzr-tfs plugin here?
<jelmer> FryGuy_: I don't think John is here at the moment
<mgz> okay, it's just past midnight, and I have an installer built
<mgz> the actual fix will now take me, I think, five minutes.
<GaryvdM> mgz: Wow. I tried for days, and did not succeed. Well done.
<poolie> well done!
<mgz> I chopped nearly everything out of it, so it's a sort-of cheat
<mgz> hm, and hook_debugger_to_signal is borked, but otherwise it seems to be working
<poolie> mgz, you're talking about trying to get a 2.3 win32 installer?
<poolie> or one that works on windows 7?
<mgz> I'm trying to fix the manifest thing, as it *does* apparently break the installer for people
<mgz> I'm just leaving a trail of smooth yaks behind me
<poolie> :)
<mgz> okay, weirdness to work out later... signal.signal is raising "ValueError: invalid signal value" with signal.SIGBREAK
<mgz> but otherwise that installer works, but links the wrong dll
<mgz> now, to do the change, and confirm it then links the right one
<mgz> new installer built...
<mgz> whoops, forgot one bit.
<mgz> okay, works.
<mgz> tooo late, bed bed bed.
<poolie> night mgz
<mgz> sadly I am not yet in fact in bed, I have just fixed the python trunk bug that was breaking hook_debugger_to_signal though, just need to post it
<jbowtie> Hopefully that will really fix bug 596239
<ubot5`> Launchpad bug 596239 in Bazaar "Bazaar supports https! Update documentation (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/596239
<jbowtie> At least while we still can't have Sphinx features.
<jbowtie> Where do ghost revisions come from?  Uncommits?
<dash> jbowtie: developers of christmas past
<maxb> bzr-svn, afaik, only
<mkanat> jbowtie: I had the same question when I was reading that code.
<mkanat> jbowtie: But I don't remember the answer.
<maxb> A ghost is when you know a revision was merged, but you don't know anything else about the merged revision besides its id
<jbowtie> It's just one of those things mentioned in the docs, but never defined.
<jbowtie> So we should either remove it from the docs, or explain what they are and why we care about them.
<jbowtie> If they're not really visible outside the code I'd vote for removing mentions of it.
 * jbowtie is looking at bug 405452
<ubot5`> Launchpad bug 405452 in Bazaar "document the term "ghost" (affected: 1, heat: 0)" [Medium,Confirmed] https://launchpad.net/bugs/405452
<poolie> i think they should be perhaps in a faq or something similar
<poolie> not normally something users should need to know about but the term might come up and then it's useful if there's a definition
<jbowtie> I was thinking of adding a glossary to the user guide.
<poolie> other than that i'd agree with removing confusing references
<poolie> that would be great
<jbowtie> Yes, it would, but I'm not doing it until we switch to Sphinx so I can use glossary and term directives.
<jbowtie> Which in practice means until PQM gets updated.
<jbowtie> Noticed on python-diversity people asking about female-friendly FLOSS projects, do we have any women on the core team?
<poolie> i don't think so
<jbowtie> poolie: Maybe you should point that out to HR when they send over the next stack of CVs.
<poolie> oh, my
<poolie> what would you like HR to do with that information?
<jbowtie> Maybe we should explicitly reach out?  I can put the word out on python-diversity and geekfeminism if we have some bandwidth to mentor new people.
<poolie> there are female committers on other canonical-related projects, including launchpad
<poolie> i hope they find it a good place to work
<poolie> or good projects to work on, as appropriate
<poolie> we have at least one female applicant for the currently-open bzr job
<poolie> suggesting we should positively tilt things towards them is a difficult topic
<jbowtie> That's great.
<jbowtie> No, I just want to make sure we're not accidentally doing things that discourage women.  :)
<poolie> i would be very happy to see more technical women here
<poolie> and, right, if we are doing anything that discourages them either applying or working here, that's a serious bug and we should fix it
<poolie> i'm probably not best qualified to know if that's true
<jbowtie> So if you mention to HR maybe they could shake the resume tree a little harder.
<jbowtie> I only think of it because where I work now we have had no female applicants to the IT team for 5 years.
<poolie> well,
<jbowtie> And I'm pretty sure it's cultural or unconscious bias on the part of management.
<poolie> we're working on a project to better expose and propagate the job openings we do have
<mwhudson> jbowtie: canonical recruits pretty heavily from open source communities, and women are even less well represented there than in the it industry as a whole
<mwhudson> why that is is an interesting topic, but perhaps not one for this channel :)
<roryy> from my perspective as an outsider, the bzr dev is handled professionally; i can't see anything that would be particularly offputting for women, or anyone
<poolie> i think we have pretty good diversity on other axes
<poolie> race, religion, sexuality, veterans, disablity
<jbowtie> So if I go back to python-diversity and say we're a female-friendly project, y'all are not going to make a liar out of me?  :)
<poolie> :) i hope not
<poolie> i would be delighted if it's true
<poolie> and if there are bugs, i would like to see them pointed out and fixed
<poolie> you could ask maritza and emmajane how they found it
<poolie> or ursinha in #launchpad
<poolie> i guess you know our ceo is a woman, but perhaps that's a different situation to being directly in a technical team
<jbowtie> Thanks, I will do.
<jbowtie> Yes, it's a little different. But I know the Ubuntu community as a whole is pretty progressive compared to open source generally.
<mkanat> I think most FOSS projects are pretty friendly toward people of any sort.
<mkanat> I've never encountered one where there was any sort of prejudice, except perhaps against Windows users. :-)
<peitschie> hi every1 :)
<exarkun> mkanat: not to say anything against the bzr community, but if you think you've never encountered any prejudice, then probably that's a failure of observation.
<mkanat> exarkun: No, I don't think so. I probably just haven't worked with projects where there is any sort of gender or racial bias.
<mkanat> exarkun: Most of the male FOSS developers that I know bemoan the fact that it's such a male-dominated profession.
<mkanat> The only thing that I can't explain about software development is why ANY human being would want to spend 10 hours a day in front of a computer, except for the fact that I do it. :-)
 * exarkun shrugs
<exarkun> as you like
<jeremyw> exarkun: Prejudice about what?
<jeremyw> I mean, a project member would of course be a little biased for their project.
<mkanat> jeremyw: Sure, *technical* prejudice, I see all the time. :-)
<jeremyw> But, truth be told, I'm a Subversion committer and I have no bias toward it.  It's great for some things but I don't use it much these days.
<poolie> well, there are some projects that have a more, say, aggressive or confrontational style
<mkanat> That's practically the whole driving force behind the software industry--technical prejudice. :-D
<jeremyw> Like the Git folks.  ;)
<mkanat> poolie: Ah, yeah, that's true.
<poolie> you said it not me :)
<mkanat> lol
 * mkanat can think of a few other projects of a similar stripe.
<poolie> but, that is sometimes said to be offputting to female contributors
<jeremyw> The Git people are like little mini Linuses.  If it ain't Git, it sucks and should be wiped off the record.
<mkanat> poolie: Sure, I can imagine that. It's offputting to me, too.
<poolie> svn went very far in the other direction to be friendly, was my impression
<jeremyw> You get my drift.  I happen to be open to whatever works.
<poolie> peitschie: hi, there, thanks for your summary mail
<jeremyw> poolie: Subversion people are very nice if you ask me.  I spend a lot of time in #svn answering a lot of help.  I'm nice.  ;)
<dash> well the svn guys _did_ do a whole google talk on how to deal with people messing up your project's community  :)
<mkanat> poolie: Yeah, my experience is that unless somebody around is putting a specific effort into making a community friendly, then it tends to devolve into unpleasantness.
<poolie> i don't have any particular renspose other than that we should/will fix those bugs
<poolie> it's interesting that i'd say most of them, like the ghosts things, do come from bzr-svn
<jeremyw> dash: Well, the idea was more geared towards project governance.  ;)
<poolie> which is a great feature, but also kind of inherently more difficult
<poolie> mm
<poolie> i agree
<peitschie> poolie: i definitely wasn't expecting much more :).  I know a lot of them are being worked on.. just hoped the overall experience story might be interesting :)
<poolie> i think the biggest problems we've had are in code reviews and that's probably now a positive overall
<poolie> but again of course i may be biased
<mkanat> poolie: Yeah, we had that problem as well, with code reviews.
<mkanat> poolie: Because their purpose is to criticize.
<jeremyw> I've pretty much learned that the VCS I used is more geared toward what my employer uses or what the open source project I'm contributing to uses.  Sure, I have my personal preference for private stuff but...
<poolie> see also jml's talk "your code sucks and i hate you"
<mkanat> poolie: lol
<jeremyw> haha
<mkanat> poolie: That's an excellent talk name.
<mkanat> jeremyw: Same here, although I have a strange tendency to cause projects to switch to bzr. :-)
<poolie> i was saying to robert the other day i think the point of code reviews is to improve the people and the relationship and only secondarily the code
<mkanat> poolie: I like that view, because ultimately it's the people who write the code.
<poolie> hopefully to make them more knowledgeable, also more excited, and to know of easier ways to do things next time
<peitschie> poolie: the bzr-svn stuff is also a little disappointing because i've been noticing the latest releases really starting to shine.  I kinda feel like I was a little early with letting this into the company unfortunately :(
<poolie> also, the amoutn of code under review at any time is probably a small fraction of the total that person will ever write
<mkanat> poolie: Yeah, that's a good point.
<mkanat> poolie: That's kind of in line with the community research I did on the Bugzilla Project, that I wrote up here: http://groups.google.com/group/mozilla.dev.apps.bugzilla/browse_thread/thread/520f5aa32917a517/bb7c1a42bcc400d9
<poolie> wow, that's good
<peitschie> mkanat: thats a very interesting writeup :)
<mkanat> poolie: Thanks!
<mkanat> peitschie: Thanks! :-)
<poolie> i strongly agree about freezes
<mkanat> poolie: Yeah, and that one had unarguable corroborating data.
<mkanat> poolie: You can draw a vertical line on the graph of the number of contributors at the freeze dates and see the graph crash from there.
<jbowtie> Hmm... grep shows ghosts only being mentioned in the developer documentation, so I'm off to the next bug.
<jbowtie> mkanat: Yes, that is a great writeup.
<mkanat> jbowtie: Thank you!
<dmuir> doing a first time contrib, so just wanting to make sure I'm doing it right
<dmuir> do I simply commit to my local branch, then push to bzr.dev?
<dmuir> ah, oop, looking at the docs... I push to my branch on launchpad, then send a merge request
<dmuir> is that right?
<roryy> dmuir: i'm going through the process myself for the first time, and that sounds like what i did
<dmuir> now I just need to figure out how to push to launchpad.... :-)
<roryy> it was in one of the docs -- there's an example of how to tweak bazaar.conf to make it fairly easy
<dmuir> I'm looking at the contribution-quickstart article which suggests putting some stuff in locations.conf
<dmuir> which i'm trying now
<poolie> branching is fine but setting things up so changes _must_ stall is poor
<jbowtie> dmuir: Generally I use bzr push lp:~jbowtie/bzr/branch-name  (of course substitute your own launchpad id)
<jbowtie> dmuir: Followed by bzr lp-propose-merge
<dmuir> ah, that's what I was looking for, the docs say to use `bzr propose-merge`, which I guess is wrong.
<dmuir> hmm, bzr crashed
<dmuir> bzr: ERROR: lazr.restfulclient.errors.HTTPError: HTTP Error 401: Unauthorized
<dmuir> odd, since I logged in fine
<roryy> you can propose a merge using launchpad
<dmuir> I think I got it working now
<jbowtie> dmuir: Thanks for pointing out the bug in the docs, I've proposed a merge to fix it.
<dmuir> thanks, was about to do it myself after submitting my current proposal
<dmuir> seems that I got it all working. bzr got all confused because launchpad didn't take me to the screen to authorise access from bzr. When I tried a second time it worked. But then it got all confused about the merge description.
<dmuir> so I updated that... except maybe it should have been the commit message?
<poolie> dmuir: are you ok now?
<dmuir> just wondering if I should update the commit message? I set a description, but then noticed after that there's no commit message.
<poolie> you can set both
<dmuir> ok
<poolie> the commit message will go into the history, and the description can have more text just for the reviewers
<dmuir> ah, ok
<dmuir> done
<dmuir> yay, my first contribution to bzr!
<poolie> :)
<dmuir> minor doc fix, but figured I'd start small :-)
<dmuir> so if I fix more things, do I push them to the same branch and create a new proposal? Or do I put that into a new branch, and propose that instead?
<poolie> if they're related and should land together, put them in the same branch and just push
<poolie> if you're doing a series of small doc fixes, put them togethr
<poolie> if you're going to also fix a bug, i'd do it separately
<jbowtie> I normally do a branch for each bug personally.
<jbowtie> Which reminds me, I can't figure out how to use bzr-colo.
<dmuir> ok, thanks!
<jbowtie> I got the idea it's good for managing lots of little branches like my workflow creates, but I can't figure out how to get started with it.
<poolie> jbowtie: so what i did is
<poolie> bzr colo-init ~/bzr/work
<poolie> (i'm going to use that as my colo workspace)
<poolie> cd ~/bzr/work
<poolie> now it'll be on trunk by default, and have an empty repo
<poolie> so then
<poolie> bzr pull lp:bzr
<poolie> now to start something else
<poolie> bzr colo-branch 189757-stacking
<poolie> and then you have the same tree, on that new branche
<thumper> poolie: got a minute?
<poolie> thumper: hi
<thumper> poolie: skype?
<poolie> ok, give me a sec
<vila> hi all !
 * fullermd quickly hands vila a parrot, a half gallon of milk, and 3 bags of sand, tells him to look natural, and runs the other way.
<roryy> for bug 335577, I'm thinking of parsing the text of the global options text (effectively bzrlib.help_topics._global_options, but obtained via method call).  The idea is to look for lines starting with "--" and treat those as options, an insert the appropriate magic-man-macros.  Does that seem OK?  Alternatively I could just create the man text from that text by hand.
<ubot5`> Launchpad bug 335577 in Bazaar "bzr global options should be added to man page (affected: 0, heat: 5)" [Low,Confirmed] https://launchpad.net/bugs/335577
<poolie> hi there vila
<poolie> wow, the early comments on that bug are pretty weird
<roryy> and the last one is *cough* wrong
<vila> fullermd: not sure about what I should reply there.... What's up doc ?
<poolie> roryy: so they want to be examined in tools/generate_man_page, i think it's called
<roryy> i've ended up in doc_generate.autodoc_man
<poolie> roryy: it would be a good start to just make sure the global options help topic appears as a heading in the man page
<poolie> that sounds right
<poolie> that's not quite idiomatic but it'd be close
<vila> mkanat: wow, there are gems in this mail, you should turn it into a blog
<fullermd> vila: I dunno.  I just started typing...
<poolie> you know as a followon it could be good to generate separate bzr-$command man pages
<vila> fullermd: ha, ok, I wasn't sure, I appreciate the intent ;)
<vila> nah, intent much appreciated sounds more like it
<roryy> poolie: i.e., just a static section 'GLOBAL OPTIONS See "bzr help global-options" ' ?
<poolie> well, ideally wit would have the actual text of it there
<roryy> i've kind of gotten that
<roryy> but the man formatting looks horrible
<roryy> hence the parsing
<roryy> or i could manually put in the man macros, which would be dead easy
<poolie> ah, i see
<poolie> hm
<poolie> it would be better not to have to manually maintain the manpage
<mgz> morning all.
<roryy> ok, i'll have a bash at generating the man source from that text.  shouldn't be hard
<mgz> can't you assign a man to manually manage the manpage?
<poolie> roryy: i think really it would be cleaner to generate it from the option objects
<poolie> mgz :)
<fullermd> Man, you gotta be joking.
<poolie> in both cases
<roryy> poolie: fair enough
<poolie> i guess you'd need to somehow mesh it with the explanatory text
<poolie> i don't think we need to point to the profiling options here
<poolie> that kind of belongs in developer docs
<roryy> if i read commands.py correctly, '--no-plugins' is checked in run_bzr() -- i'm not following what an option object is
<mgz> poolie, as you marked roryy's mp approved you think it's good to go? will go ahead and land that and andrej's changes now if so.
<vila> mgz: wow already up ! You did manage to build an installer finally ?
<poolie> mgz is that the meliae one?
<mgz> I built enough of it to write the fix.
<mgz> poolie, no, the --show-base one
<vila> mgz: I *am* very interested tracking changes you had to do to get there, I hope you will submit some mps soon while it's fresh...
<poolie> roryy: hm, some of them, including no-plugins, are handled a bit specially
<vila> *interested in
<poolie> ok, i'll change that advice to say it would be nice to turn them into objects then format the objects for both cases
<roryy> heh
<roryy> ok
<poolie> however if you want to just quote the text so that it formats properly, i think that would be a step forward
<vila> poolie: Do we have graphs of downloads somewhere and do we have them for ppas too ?
<poolie> i don't think so
<poolie> mgz, re --show-base, it's not the ideal implementation but i think it's reasonable
<mgz> hm, yeah, you mentioned a config thing, have we got a bug on what you were intending?
<poolie> not sure
 * poolie looks
<poolie> what i had in mind is that if there was a per-process configuration,
<poolie> higher level things could map --show-base into setting merge.show_base = True
<poolie> for the duration of the command
<poolie> that would avoid the proliferation of things being passed down
<poolie> it would also let people set it permanently if they wanted
<vila> bzrlib.merge.show_base could be a config option whose value can be overridden from the command line
<poolie> exactly
 * vila rejoices :)
<roryy> that setting of that option (bzrlib.merge.show_base) would still be set in the appropriate commands? (pull, merge, update) ?
<vila> and no spurious failure on babune today !
<roryy> also, would it become --show-base=yes|no if it's an overrideable config option?
<vila> by the way, maverick is back as a regular slave with a single failure, guess which one...
<vila> bzrlib.tests.test_transport.TestSSHConnections.test_bzr_connect_to_bzr_ssh
<mgz> paramiko thing?
<vila> mgz: yup
<vila> I asked spiv for a maverick version of its package that I use on lucid
<poolie> why spiv?
<vila> because he did: https://edge.launchpad.net/~spiv/+archive/packaging-test
<vila> and I use this ppa for the babune lucid slave
<vila> the problem wasn't apparent before because the maverick slave was using python2.7 and paramiko wasn't packaged at all
<vila> but since I switch back to 2.6 to debug the ca.crt thing, I left it at 2.6
<GaryvdM> Hi all.
<mgz> morning Gary.
<mgz> I put up an installers mp that should sort out the manifest thing.
<GaryvdM> mgz: Cool. would you like me to build a full installer with it.
<mgz> We probably want to before 2.2.2 but don't rush.
<GaryvdM> ok
<vila> poolie: you really want to separate show-config and set-config ? I thought bzr config name=value was more... natural ?
<vila> poolie: it's true that at the implementation level this would be almost completely separated though (with a bit of overlap nevertheless since setting applies to a subset of what is shown)
<twb> What's the equivalent of "hg out", i.e. a dry-run push?
<vila> bzr missing --mine-only ?
<twb> Argh, the server's behind a bloody pptp server, so I have to bounce back into a ppp-enabled kernel to try it :-/
<mkanat> vila: Thanks!!
<mkanat> vila: I was actually just thinking about making it into a blog.
<vila> mkanat: :)
<vila> I believe in many of the points you raised, it's nice to see you backed them with data
<twb> bzr missing was the Right Thing.
<twb> Unfortunately there are merge conflicts with upstream, and my patch is trivial, and I don't feel like learning how to resolve conflicts in bzr at 8PM on a Friday, so I'm just going to bzr log -c | ssh foo patch, resolve the conflict by hand, then commit it as a fresh change
<GaryvdM> mgz: I tried to build with your patch. I got this error again: "*** finding dlls needed *** \n error: MSVCP90.dll: No such file or directory"
<mkanat> vila: Thanks. :-)
<GaryvdM> mgz: last time I got that error, I copied msvc*.dll to some where py2exe could find it. The build host has been rolled back, so this is no longer in place.
<GaryvdM> I could do that again, but it did not feel right.
<GaryvdM> I was hopping your patch would fix this with needing to copy the dll's
<GaryvdM> mgz: what do you recommend I do?
 * GaryvdM reads the py2exe doc again
<mgz> GaryvdM: okay, that wasn't what I was trying to fix so it's not suprising it's still happening
<mgz> if you copied the dlls last time to make it work, do it again
<mgz> but tell me where you're copying them to, and I'll look at fixing that as well
<GaryvdM> ok - I see you used self.msvc_redist_dir, and I'm just looking where that comes from.
<mgz> what I changed is all post-py2exe, it's a different issue
<GaryvdM> oh
<mgz> https://lists.ubuntu.com/archives/bazaar/2010q3/070252.html <- what that branch is aimed at
<mandel> hello, I've been trying to use bzr-pqm in an recently updated maverick machine and I get the following error: http://paste.ubuntu.com/503808/
<mgz> something that breaks then installer for users, not the process of building the installer
<mgz> mandel: that's actually (mostly) harmless, but is fixed in the upcoming 2.3
<GaryvdM> mgz: ok - I'm with you
<mandel> mgz, ok, sweet, I was talking with the canonical losas and we had no bloody clue about that, I'll update our wiki so that people know about it
<mandel> mgz, thx a lot!
<mgz> I'll give you a bug number ina sec
<mandel> mgz that would be superb!
<mgz> ...I think Andrew filed a bug rather than just putting up an mp
 * mgz goes for qlog rather than launchpad bug search anyway just in case
<mgz> bug 633745 is what I was thinking of, but I'm not completely sure that's the right thing
<ubot5`> Launchpad bug 633745 in Bazaar 2.2 "bzr+ssh to pre-1.6 server fails with AttributeError: 'NoneType' object has no attribute 'close' in close_ssh_proc (affected: 1, heat: 11)" [Critical,Fix released] https://launchpad.net/bugs/633745
<mandel> mgz, does look like the same one.. I'll just update the wiki so that is someone finds the issue does not have to worry about it, thx a lot for the help!
<mgz> if it is that, 2.2.1 will fix it, file a bug if it doesn't.
<GaryvdM> mgz: Ah, we have a dll exclude for MSVCP60.dll, but not for MSVCP90.dll - Maybe we should add that?
<GaryvdM> in setup.exe line 691
<mgz> if that turns out to help, go for it, but I think we played around with this a week ago and didn't get that far
<mgz> it doesn't really matter if we end up copying it in the script to make py2exe happy because we can seperately just not ship it
<GaryvdM> mgz: ok
<GaryvdM> mgz: https://dl.dropbox.com/u/4494367/bzr-2.2.1-setup-manifest.exe
<mgz> getting, thanks Gary.
<GaryvdM> I've not tested myself yet.
<mgz> it's a bit of a pain to do unless you have a clean vm somewhere
<mgz> ah, uh, er... was just about to declare victory, but everything qt is broken
<GaryvdM> mgz: that may not be due to your patch
<mgz> I'm going to try copying the cpp runtime library in to see if it's that
<GaryvdM> I had to reinstall pyqt oh build the host :-/
<GaryvdM> *on
<mgz> nope.
<mgz> meh, pants
<mgz> it the cpp runtime, wonder what the best way to fix this is
<mgz> the only thing it's actually in there for:
<mgz>     MSVCP90.dll
<mgz>                  BE4   ?uncaught_exception@std@@YA_NXZ
<mgz> also, but unrelated, the crypto compiled bits seem to be missing
<mgz> ...I'm failing to think of a non-ridiculous way of handling this
<mgz> python26.dll has to be in the base dir, and needs the runtime next to it, qt dlls need to be in the lib dir, and have the runtime next to it
<mgz> linking two different copies is asking for pain.
<mgz> okay, that'd work. scrap the lib dir entirely and put *everything* in library.zip in the root folder
<mgz> or install to SxS system dir
<mgz> ah, or maybe just update the python? I'll read through all of <http://bugs.python.org/issue4120> but that's pretty much the issue.
<mgz> nope, not relevent.
<vila> meh, what's the python equivalent for C __FILE__ __LINE__  ?
<vila> __file__ for __FILE__ but __LINE__ ?
<Glenjamin> i think __line__ works
<Kinnison> Or you might just use the inspect module?
<Kinnison> (in the callee)
<vila> Kinnison: :-) I am the callee, I want to know my line number
<Kinnison> hmm
<Kinnison> from inspect import currentframe
<Kinnison> then use currentframe().f_lineno and currentframe().f_code.co_filename
<Kinnison> ?
<Kinnison> (untested)
<vila> Kinnison: works, thanks
 * vila  was stupid to try it under pdb just to get '1' as a result
<Kinnison> note: probably not terribly efficient
<Kinnison> if __file__ works, then use that instead of the latter
<vila> Kinnison: I did
<Kinnison> :-)
<vila> efficiency is not a concern, it's to report an error to the user
<Glenjamin> http://code.activestate.com/recipes/145297-grabbing-the-current-line-number-easily/
<Glenjamin> seems like inspect is the only way, __line__ would be too magic for python i guess :)
<vila> yeah, I think I was climbing the wrong tree, python is an interpreter not a preprocessor, doesn't really make sense to bind a symbol with that (unlike __file__)
<vila> Glenjamin: thanks for the additional bit of info (I will need f_back :-)
<vila> yoo
<vila> too
<vila> ha typos....
<GaryvdM> mgz: I don't have any qt issues with that installer - on a fresh win 7 vm
<GaryvdM> everything just works
<GaryvdM> What error to you get?
<GaryvdM> *do
<mgz> well, I don't think I've made anything worse, but I've probably not fixed anything
<mgz> I suspect windows 7 (and possibly vista) has the vc9 runtime in a shared location anyway
<GaryvdM> I'll try reproduce in a xp vm, with an old installer
<mgz> does your vm have %WINDIR%WinSxS\x86_Microsoft.VC90.CRT_<morestuff>?
 * GaryvdM checks
<mgz> I mean, the good news is this shouldn't really affect many people as various other bits of software will stick the dlls we need were they'll get found anyway, but I think this is kinda borked
<mgz> I've just been looking at mercurial's new msi installer with some envy, the config is horrid but being native it handles these dumb windows 'innovations'
<GaryvdM> mgz: does have %WINDIR%WinSxS\x86_Microsoft.VC90.CRT
<mgz> yeah, so that's good and bad. good in that for people with win7 bazaar will just work
<GaryvdM> mgz: You said qt stuff was broken?
<mgz> bad in that we can't actually test to see if the installer's borked on that vm
<mgz> yeah, basically everything in the subdir that /1) links a vc 9 runtime/ and /2) bundles a manifest/ is borked
 * GaryvdM starts installing a xp vm...
<mgz> including pywintypes (which doesn't actually matter as ctypes works)
<mgz> anyway, this is where I'm happy I'm not a build engineer, at least with coding you create stuff rather than just trying to keep it unbroken
<vila> mgz: I think you're over-optimistic :)
<vila> mgz: your last sentence could be reversed and still holds true for some people :)
<GaryvdM> woot: http://www.youtube.com/watch?v=tMdE4GmFaDQ
<GaryvdM>  Excremental Bazaar qlog selection behaviour.   ^^^^
<Glenjamin> what key's are you pressing there?
<Glenjamin> i was trying to figure out if it was a bug report or a feature demo
<GaryvdM> All mouse draging
<Glenjamin> oh
<Glenjamin> oh i see, it only selects items in the history of the first selection
<GaryvdM> Yes
<vila> excuse my poor english, but... excremental ?
<vila> ex == not in ?
<GaryvdM> experimental
<Glenjamin> thats my interpretation, i'm not convinced it's a real word
<Glenjamin> excremental actually means "pertaining to excrement"
<vila> weird freudian slip :)
<GaryvdM> I can't spell..
<vila> me neither :)
<mgz> okay, written up the pain I experienced earlier today so I can forget about it this evening and do something fun instead
<jam1> mgz: you can never forget :)
<mgz> if I dream about being attacked by dlls tonight it's all bzr's fault
<awilkins> Ah, dll hell
 * awilkins has repressed memories
<GaryvdM> Whats a good name for something that loads data, does some processing on that, and caches it in memory?
<Glenjamin> load?
<GaryvdM> It's a object
<GaryvdM> loader...
<Glenjamin> Loader i guess, to me loading is going from source to somethig usable
<vila> loader and cache
<GaryvdM> Maybe model?
<vila> whether the cache is embedded in the loader or in the caller...
<GaryvdM> On would init it, call .load(), and keep it as a cache
<GaryvdM> almost like a dom
<Glenjamin> does the fact that it's cached need to affect the naming?
<vila> Can it be created without loading ?
<GaryvdM> (I'm trying so come up with a better name for LogGraphProvider
<Glenjamin> ah
<Glenjamin> it's a black-box which provides a log graph, no?
<vila> Or can load be a from_something() class/static method ?
<GaryvdM> vila: no
<vila> GaryvdM: It can't be updated either ?
<GaryvdM> gp = LogGraphProvider([branches])
<GaryvdM> gp.load()
<Glenjamin> any reason load isn't implicit?
<vila> gp hints at removing Log ;)
<vila> GaryvdM: on a totally different topic, what's up with the installers ?
<GaryvdM> vila: it can be filterer, but not modified.
<mgz> that was a nice turn around, python issue 10003 fix committed already
<GaryvdM> vila: we have a regression, caused by py2.6, that only affects some: bug 632465
<ubot5`> Launchpad bug 632465 in Bazaar Windows Installers "bzr.exe tried to use the system msvcrt90.dll from system32, not the bundled one (affected: 2, heat: 16)" [Critical,In progress] https://launchpad.net/bugs/632465
<GaryvdM> but otherwise good.
<mgz> yeah, ideas welcome on that if you have any vila, I posted a summary in the mp
<vila> GaryvdM: so you plan to release a 2.2.1-2 and 2.3b1-2 ?
<mgz> we need a proper fix first unfortunately
<GaryvdM> vila: yes, if we can fix..
<vila> mgz: build on windows95 and let microsoft handle the compatibility with higher versions ? :-D
<mgz> seriously, I build with a version of VC from the last millenium still by preference
<mgz> but we're pretty much stuck with this unless we want to go back to 2.5, and for various reasons (eg, the cert validation thing that just came up) we really want to be on 2.6
<mgz> I think rearranging the layout will probably do it, but it's quite a big change and risks breaking things for people who have the runtimes installed anyway and see no ill effects
<vila> yes, keeping 2.6 is the way to go (sry alex), now will flattening lib into root be required for people running qbzr from sources ?
<vila> is it a regression from 2.2.0 ?
<GaryvdM> no, but from 2.1
<vila> meh
<vila> how was the 2.2.0 built and what broke the 2.2.1 ?
<mgz> 2.2.0 was also broken, but only a subset of users see it.
<GaryvdM> Glenjamin: any reason load isn't implicit? - there was, but they have gone away.
<vila> mgz: then don't fix it for 2.2.1, target 2.3b1
<vila> or even 2.3b2
<GaryvdM> 6m is a long time...
<vila> what were the affected users doing so far ?
<GaryvdM> manually install the sdk
<mgz> but it's not obvious that that's the fix
<vila> great, they still have the option to upgrade to 2.3b1 when we officially release it (which I'll do as soon as we have a working installer)
<mgz> we've had two reports of borkedness, but the thing I worry about it is the people most likely to hit it are non-developers (who won't have visual studio installed) and won't have any idea what the issue is beyond bzr apparently sucking
<mgz> the good bit being win 7 at least doesn't have the problem, and probably not vista either
<vila> mgz: let's fix it on 2.3b1 for people more able to provide feedback *then* we can either release a 2.2.1-2 *or* 2.2.2 depending on how long it takes and how many people are affected
<mgz> I don't have much to base an estimate of how many potential users will be affected though
<vila> GaryvdM: ^ sorry, didn't intend to exclude you
<vila> indeed, but not the majority right ?
<GaryvdM> vila: np - was reading any way...
<mgz> pretty sure not, and I'm happy with that as Gary showed it all worked in his VM
<vila> I think my point is: releasing is not the time to fix bugs, this should as light a process as possible (which it will never be anyway), so we shouldn't add to it
<vila> add a 'be' where missing
<vila> because if we delay releases *all* users are affected
<GaryvdM> I'm going to try reproduce in a xp vm, but not tonight.
<vila> I know this is a hard time for windows installers and I fully appreciate the work you're doing though (and I strongly hope we will be able to replicate the build environment from that)
<GaryvdM> vila: agree, thats why beta installers are important (and nightly builds would be better)
<vila> GaryvdM: see ? That's why we need to replicate :)
<vila> Ideally, releasing should just take the last nightly, rename it and be done.
<GaryvdM> vila: but if we have a fix, then it should be included in the stable update.
<vila> GaryvdM: no, it depends on the fix
<vila> otherwise, you never release because there is always one more bug
<GaryvdM> sure - and that comes down to judgement..
<vila> sure
<vila> 698 people already downloaded bzr-2.2.1-setup.exe anyway
<GaryvdM> :-0
<vila> and 729 downloaded the source... who ? Tell me who ? gentoo ? Really ? They don't have their own repos with their patches ? Or do they keep them separate ?
<GaryvdM> May I revert the topic :-p  It can only be created with a load, and it cant be modified. hence it should be called ...?
<Glenjamin> LogGraphLoader?
<mgz> FooView
<Glenjamin> LogGraphProvider().load() => LogGraph()
<GaryvdM> Ok - I think I'm going to go with : graph_viz = GraphVizLoader()
<GaryvdM> computed = graph_viz.compute_lines(state)
<GaryvdM> And once thats done, I'm going so move to bzrlib \o/
<GaryvdM> And make a bunch of methods and attrs _
 * awilkins downloads the sources
<awilkins> Sometimes
<awilkins> There's a CentOS server I can't be bothered to mess about with packages for so I install from sources
* You're now known as ubuntulog
<bialix> hi, I need some help with English text for Bazaar Explorer
<fullermd> bialix: Make sure you include the phrase "aluminum siding".
 * bialix notes
<bialix> thanks fullermd
 * fullermd is helpful.  Sorta.
<bialix> sorta
#bzr 2010-10-02
<jelmer> fullermd: isn't it spelled aluminium rather than aluminum?
<AfC> http://en.wikipedia.org/wiki/Aluminium
<fullermd> Of course not.
<jeremyw> When browsing a bzr repository in a non-CLI UI, would you expect the "last revision" to be the last physical change to the file, like 'bzr log' does which includes merges, or the revision number that corresponds to the last physical change?
<jeremyw> It seems loggerhead shows the last physical change, omitting revisions where a changed file was merged into the mainline, while 'bzr log' is aware of merges.
<jeremyw> To me, it seems a little confusing but not being a long-time bzr user, I figured I'd ask you guys.
<peitschie> hi everyone :)
<vila> peitschie: hey ! Don't lose hope, VCS is a life-time memory thing, the tool itself matters less than the organization, keep fighting for the organization, your choice of tool will follow :-)
<peitschie> vila: thanks for the support :).  I suspect this "revolution" is just starting to gain a little momentum
<peitschie> as I alluded to in the email, bazaar has really opened up the dev practices of a lot of the other programmers
<vila> peitschie: indeed, it's far too soon to declare the game is over
<peitschie> it was almost satisfying to hear them complaining continually about the features svn lacked in comparison... and this is only after around 2months of dvcs use
<vila> and the decision was to keep svn right ?
<peitschie> we never truly left svn
<fullermd> The sucky part is where ugly fallout from the limitations of svn become recycled as arguments against bzr-sans-svn.
<peitschie> we used bazaar to supplement the main dev activities in svn
<vila> so, *you* can still use bzr-svn transparently
<peitschie> that was part of the challenge actually... the svn core changed some things and caused us a little extra heart-ache than pure bzr likely would have
<peitschie> with the new ghost handling that jelma was saying is in bzr-svn, quite likely :)
<peitschie> initially, I had some major issues with logs and such when trying to have multiple devs privately using bzr-svn
<vila> ghost support is here to stay
<peitschie> unless our changes synced up, annotate and log would crash most of the time
<vila> so file bugs and tag them with ghost
<peitschie> already have :)... i even started fixing one but just keep running out of time to see it through to teh end
<peitschie> python +qt is not my usual dev stack so it takes me a bit to get my way around still right now
<peitschie> at the moment i am definitely still using bzr at work... i suspect a few other programmers will continue as well
<vila> hehe
<peitschie> main trick is keeping my head out of the firing line if another dev gets a little stuck... it seems a lot of this flack was simply because i was the highest profile user of said system
<vila> yeah, with great power come great responsibility :-P
<fullermd> Ah, but this is a corporation.  With great responsibility comes no real power at all   :p
<peitschie> lol... aint that the truth!
<vila> Ah, but the world is changing, everyday :)
<vila> A new power is raising... err wait, no, I didn't say that, far too risky to be wrongly quoted :)
<peitschie> the kind of infuriating part is that i'm a junior dev... and at least 3 other seniors signed off on this move... gah... dev life was never going to be fair though... I should know enough from teh flack that flies around open-source projects
<fullermd> We fear change.
<peitschie> aint that the truth
<vila> Now, that's a fundamental truth
<vila> And this explain a lot why DVCS is hard to deploy (so to speak)
<fullermd> That's why I choose to use bzr; that way I don't have to worry about changing   :p
<peitschie> lol fullermd :P
<vila> or any VCS for that matter
<fullermd> Oh, no, a VCS is easy to deploy.  As long as it's the one you're already using.
<peitschie> yes... in many ways it is understandable
<fullermd> The nuclear strong force is not the greatest force in the universe.  Inertia takes it out behind the woodshop and stomps it silly.
<peitschie> in the case of my recent experience with bzr, those are expensive failures for the company... having said that, the major impossibility is showing the efficiency improvements from use a distributed workflow
<vila> ha ha, expensive failures. Tsk, tsk, the costs you can't prove don't exist :)
<peitschie> oh yes
<peitschie> it's easy so say that half a day for 15devs being unable to commit is expensive
<vila> doesn't exist !
<peitschie> hehe
<vila> They have so many other things to do, they are just whining, come on guys
<peitschie> my thoughts exactly
<vila> anyway, my point was: we welcome refugees (cough, and I'm not saying this to cover my French president :-/)
<peitschie> so much of it was pure knee-jerk as the project schedule is slipping for some very large architectural reasons (and incomplete designs)... which have wasted far more than this hiccup did
<vila> ha ha, but *here* it's easy to see who the culprit is !
<peitschie> vila: i can tell :)... it's been nice to hang out here and chill with some people that aren't claiming bzr just ate some babies when it clearly didnt lol
<peitschie> >.<... oh yes
<fullermd> Don't be silly.  _Important_ people make architectural decisions.  They surely don't make mistakes.  It's those little people screwing with development tools (and unapproved dev tools, at that!  Damn unlicensed hackery...)
<vila> cough, chicken and goats on the other hand
<peitschie> oh yes
<vila> yeah, those hippies... and communists I heard....
<peitschie> and the occasional snake i'm told
<vila> snake ? Sacrificing snakes works ? Nobody ever tell me anything !
<vila> fullermd: That's __Important__ not _Important_, the former carries the idea that they can't be modified while the later is only a convenience that can be worked around with a simple #pragma
<peitschie> rofl
<peitschie> it took you 70mins to come up with that?! :P
 * fullermd looks around for something to smack vila with.
<vila> peitschie: yeah, I'm notoriously slow :)
<peitschie> lol :)
<vila> peitschie: and properly killing a snake takes time
<peitschie> ahh... of course of course!  how thoughtless of me... wouldn't want you to rush that just for a good one-liner!
<vila> avoiding typos (my #1 ruining-joke weakness) is best addressed by staring at them for *at least* 20 minutes too
<vila> fullermd: don't try with a goat, I've got some new very powerful protective spells
<fullermd> That's the sort of statement best taken way out of context   :p
<vila> lol
<vila> wow... http://www.alltelleringet.com/ totally off-topic, sry, but I think a few of you may appreciate
<zyga_> hi
<zyga_> vila, are you familiar with bzr-pipe?
<mkanat> vila: Very cool. :-)
<vila> zyga_: nope, I use looms, but ask your question anyway or I can't try to answer it ;-)
<vila> mkanat: glag you liked it ;)
<vila> glad even
 * vila back to regular typos...
<mkanat> :-)
<fullermd> Ah, good.  The world is back on its axis.
<zyga_> vila, I just noticed bzr switch-pipe does not store local changes
<zyga_> vila, perhaps the version I'm using is not compatible with bzr (on 10.10)
<vila> zyga_: by store local changes you mean shelve ?
<vila> zyga_: keeping uncommitted changes in the working tree while switching is a feature, I often need to commit code I just wrote while not being in the :right" thread (or pipe)
<vila> "right" (I try to keep the world on its axis, excuse my typos ;)
<zyga> vila, no I mean bzr switch-pipeline
<zyga> vila, I found the issue
<zyga> vila, bzr-pipeline is _fantastic_
<zyga> vila, the issue was, untracked files are _not_ stored/restored by the pipeline
<zyga> vila, so if you add a new file and start hacking on it (but not bzr add it) it will not be hidden by bzr switch-pipeline
<vila> zyga: that's a bzr issue then, there are still unversioned files that you want to keep with you (even if there are unversioned files that you want to hide)
<vila> zyga: examples at https://code.edge.launchpad.net/~vila/bzr/323111-orphan-config-option/+merge/35690
<vila> zyga: comments or bugs with your use case welcome
<ashash> hai
<ashash> quick question. i have a branch and modified+commited a file, now the maintainer of the parent branch cherry picked some changes but did so by putting those things in by hand.
<ashash> whats now the best way to revert those files back to the parent?
<ashash> revisionspec is my friend i guess :)
<jelmer> 'evening
<hingwah> hi all, using centralized workflow model and bzr+ssh:// access, is it possible to restrict user which have write access to only use particular username/email as commitor? i.e. to have a binding between the commitor and ssh login user to prevent people faking as another commitor?
<ddaa> nope
<ddaa> and that would also prevent the use of push
<ddaa> and merge
<ddaa> use gpg-signed commits for authentication
<ddaa> using the committer for authentication is as safe as using the From: header in email.
<mkanat> hingwah: Yeah, I have a plugin that does it.
<mkanat> hingwah: It does prevent use of push.
<mkanat> (If the push contains other people's commits.)
<mkanat> hingwah: http://bzr.mozilla.org/bzr-plugins/enforcecommitter
<mkanat> hingwah: It's not a security mechanism, though--it's just a way of making sure that people have set their "whoami" properly.
<hingwah> ddaa, thx, I didn't know there is commit signing
<hingwah> ddaa, bzr sign-my-commits ?
<hingwah> mkanat, let me check,thx
<ddaa> hingwah: also check http://wiki.bazaar.canonical.com/ConfiguringBzr#check_signatures
<ddaa> then there's the entire topic of configuring and using gpg
<ddaa> but this chat window is a bit too small for that :-)
<superm1> hey guys, in maverick what happened to olive-gtk?
<superm1> it doesn't appear to be in the bzr-gtk package anymore
<superm1> err... http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598703
<ubot5> Debian bug 598703 in wnpp "RFP: olive-gtk - Graphical frontend for Bazaar" [Important,Open]
<superm1> that's not good
#bzr 2010-10-03
<Kamping_Kaiser> ever wanted to maintain olive-gtk in debian? ;)
<Kamping_Kaiser> someone should update http://wiki.bazaar.canonical.com/Olive/ with its new source home
<Kamping_Kaiser> since that says its part of bzr-gtk, and i can't find an olive-gtk project on lp
<Kamping_Kaiser> ah, its 'olive'
<sinasalek> Hi, is there any plugin for lock/unlock support in Bazaar?
<sinasalek> https://bugs.launchpad.net/bzr/+bug/109730
<ubot5> Launchpad bug 109730 in Bazaar "want an advisory exclusive lock on files/dirs (affected: 0, heat: 2)" [Wishlist,Confirmed]
<xapantu> Hi all ::)
<xapantu> Is there a "svn propset" command in bazaar ? I mean, an equivalent command ?
<maxb> There isn't any command line way to just merge tags, is there?
<lifeless> --force ?
<fullermd> Well, you could merge then revert.
<lifeless> oh, to pull across just tags? no
<fullermd> Sorta two-wrongs-make-a-right.
<lifeless> because they are meant to be brought over with their history
<lifeless> if you don't pull or merge+commit, they are unusable
<maxb> I'm staring at history that has come across without its tags
<lifeless> was it propogated by something using the API directly?
<lifeless> if so - fix that tool :) - and you can propogate the tags directly via the API.
<maxb> Yes, the UDD importer
<mwhudson> jelmer: are you around?
<mwhudson> jelmer: http://launchpadlibrarian.net/56810799/vcs-imports-gcc-4.5.log is really strange
<jelmer> mwhudson: hi
<mwhudson> jelmer: is bzr-svn trying to write lock the branch twice somehow?
<jelmer> mwhudson: not sure what's happening there. it almost looks like a process that was doing an import dead earlir
<mwhudson> jelmer: that directory is created for each import run
<mwhudson> jelmer: and it's late in the import process isn't it?
<mwhudson> i guess it might be the first time the branch itself is write locked
<jelmer> mwhudson: yeah, it would be
#bzr 2011-09-26
<vila> hi all !
<poolie> hi there vila
<vila> poolie: _o/
 * fullermd waves in some vague direction.
<poolie> hi md
<jam> morning all
<vila> jam: _o/
<vila> mgz: welcome on board !
<fayaz> hi, is there a shortcut to remove the working tree from a branch?
<lifeless> bzr remove-tree
<fayaz> lifeless: thanks
<fayaz> lifeless: what about for a shared repo?
<lifeless> same
<poolie> vila, so we agreed we're going to try to release lazr.restful, package it, etc?
<poolie> if i don't get to it first you can
<jam> poolie: weren't we going to do the 1:1 today?
<poolie> yes, hi
<poolie> was (unnecessarily) waiting for you
<jam> poolie: ah, I said hi around 9, but you probably missed it
<jam> I didn't see you talking, so didn't think you were around
<poolie> shall we talk here or on the phone?
<jam> poolie: either is fine by me
<poolie> ok just busy here for a sec
<jam> np
<leo2007> I am getting this msg with the emacs repo. How to fix it? http://paste.pound-python.org/show/13019
<poolie> leo2007, 'bzr tag --delete  mh-e-8.3' and   mh-e-doc-8.3
<poolie> then pull again
<leo2007> poolie: many thanks.
<mgz> morning all.
<leo2007> I am running Bazaar (bzr) 2.3.1. Is there sth I need to pay attention to when upgrading to 2.4.1
<leo2007> some pages look like this on chrome http://imagebin.org/174112
<poolie> leo2007, no, upgrading to 2.4.1 is safe
<poolie> leo2007, that's interesting
<poolie> i don't think it's connected to  bzr
<poolie> are you in the middle of upgrading your os, perhaps?
<poolie> mgz, hello!
<mgz> hi poolie!
<poolie> hi there
<poolie> welcome
<poolie> :)
<jam> hey mgz! Good morning to you! And welcome to the gang :)
<jam> leo2007: If you're upgrading the OS, I've seen some weird bits with rendering and certain Video drivers. It seems launchpad uses a very large image and then pulls sprites out of it. But its never hidden the text, just certain icons for me.
<poolie> (all, mgz is joining Canonical starting today, there will be mail in a little bit)
<poolie> mgz, when did you plan to typically start your day - around 9?
<mgz> yes, planning to do that to start with then if it turns out to be better to do earlier or later will adjust.
<leo2007> jam: no I am not upgrading os.
<jam> leo2007: the only thing you upgraded was bzr and you started getting weird rendering in Chrome. Seems odd.
<poolie> leo2007, suggest we ask in #launchpad
<leo2007> no, no, I was browsing the bzr website and some of its pages load weirdly
<vila> mgz: |0/
<vila> oops \o/ I meant :)
<leo2007> ok, now I am on 2.4.1 ;)
<fullermd> vila: I should hope that's what you meant.  Otherwise, there's something wrong with your head...
<vila> smoke going out mainly
<mgz> okay, getting there...
<poolie> hi mgz, flapping much?
<mgz> just trying to work out what I'm going to do over email :)
<jelmer> jam: You mentioned making a few updates to your 2.5-soft-hangup MP, but they don't appear to be on lp yet?
<jam> jelmer: I did push, but not commit :)
<jam> should be there now
<jelmer> heh, thanks
 * jelmer waits for the MP to update
<jelmer> I'm looking forward to those longpoll changes to launchpad...
<Riddell> if I have a string of a class's name, how can I instansiate the class?
<jelmer> I guess something like eval(name)() assuming the class is properly imported, etc
<jelmer> Riddell: why would you want to though? It's usually a bad idea
<Riddell> jelmer: because your rewrite plugin lists the commands as strings in the info.py file :)
<jelmer> Riddell: heh, ok
<jelmer> Riddell: there is a method for looking up command classes by string
<jelmer> Riddell: bzrlib.command.get_cmd_object
<Riddell> jelmer: I don't think that'll work though if the plugin isn't installed
<jelmer> Riddell: true
<jelmer> Riddell: what are you trying to do exactly, what do you need?
<Riddell> exporting the strings from rewrite plugin
<jelmer> ... without having it installed ?
<Riddell> I think expecting the plugin to be installed is too much of an assumption
<jelmer> Riddell: why do you need to look up classes though?
<Riddell> I need to instansiate the class to pass it to bzrlib.export_pot._write_command_help
<jelmer> Riddell: if you need to instantiate anything, that requires loading the plugin
<jelmer> Riddell: that doesn't seem too bad though, it's always possible to use the BZR_PLUGINS_AT env variable
<Riddell> it works fine to just run  cmd_rebase()
<jelmer> Riddell: that's not guaranteed for any of the other plugins though, which may rely on other code in __init__.py having run
<jelmer> Riddell: it's odd that just cmd_rebase() would work - did you import anything else, do you have bzr-rewrite installed perhaps?
<Riddell> jelmer: this is what I have http://paste.kde.org/127417/
<jelmer> Riddell: that's only going to work if you have the plugin installed
<jelmer> Riddell: it also assumes that the commands are living in commands.py, which isn't necessarily true
<mgz> okay, I've sent a hello message to the mailing list
<Riddell> jelmer: I don't  have rewrite installed (according to `bzr plugins`
<mgz> if someone is free later to try testing out voip things with me, that would be really handy
<Riddell> jelmer: well this is specific to bzr-rewrite, other plugins would have to adapt
<Riddell> mgz: ah, you're on a new mailing list, that's exiting :)
<Riddell> mgz: I've never done voip, how are you setting it up?
<mgz> on this machine if at all possible, otherwise I'll just use my phone
<jelmer> mgz: hello!
<mgz> jelmer: hi, nice to meet you!
<jelmer> Riddell: I'd personally prefer something more generic, even if that somehow requires loading the plugin
<jelmer> Riddell: importing info and commands is going to load some bits of the plugin anyway, so I don't really see how what it gains us
<jelmer> mgz: :)
<Riddell> jelmer: well this way e.g. packagers can run make update-pot and know it'll work, if you have to have the plugin installed it might pick up the wrong version of the plugin or not work at all
<jelmer> Riddell: This is much more likely to regress because importing commands might require on side-effects from __init__
<jelmer> riddell: there are ways to load plugins from specific locations
<jelmer> vila: ^
<vila> BZR_PLUGINS_AT ?
<Riddell> mgz: doesn't a voip account require asking sysadmin for one, or are you not using canonical's server?
<jelmer> Riddell: I got my VOIP credentials by email automatically on my first day?
<fullermd> It's a rite of passage.  You're supposed to hack into the server and set yourself up...
<vila> jelmer: Not sure I understand the question :-}
<jam> jelmer: if there is anything I can do to make it easier to review my changes, just ask. I'm happy to discuss them line-by-line, etc.
<jelmer> jam: I'm having another look at them now
<jam> mgz: I've got voip set up if you want to test it, or mumble, or whatever
<Riddell> vila: I need objects of cmd_rebase etc from the rewrite plugin so I can pass them to export_pot._write_command_help() and get the translations
<vila> Riddell: about your pasted snippet, beware that '-' is translated to '_' between the command name and command class name, get_command_object which should take care of that
<Riddell> it seems to work fine if I just do  foo = cmd_rebase()  but that might not be reliable for all commands
<vila> not all plugins use the info.py trick and the ones who do don't necessarily declare bzr_commands :)
<jelmer> .. and not all of them have their commands living in commands.py
<vila> yeah, so, bzrlib.commands.plugin_cmds may be a better source
<Riddell> mm
<jelmer> jam: I'm getting an additional leaked thread from bb.test_serve with your MP
<jam> jelmer: I don't....
<jam> but let me check another machine
<jelmer> jam: aren't you missing a call to finish_bzr_subprocess?
<jam> jelmer: could be
<jelmer> that fixes it for me, fwiw
<jelmer> http://pastebin.ubuntu.com/697224/
<jam> jelmer: I'm calling "assertFinishesCleanly" right?
<jelmer> jam: nope
<jam> hmm, I was
<jelmer> jam: IIRC assertFinishesCleanly tries to send a SIGINT
<jam> jelmer: so add assertFinshesCleanly
<jam> after the readline
<jam> for the test involved either is fine.
<jam> All I'm testing is that you *can* connect, and that SIGHUP triggers the shutdown code.
<jelmer> jam: assertFinishesCleanly doesn't work:
<jelmer> a = 'bzr: interrupted\n'
<jelmer> b = 'Waiting for 1 client(s) to finish\nbzr: interrupted\n'
<jam> If we want, I can extend that code and make sure it doesn't actually stop
<jelmer> finish_bzr_subprocess seems fine though
<jelmer> since it doesn't check stdout
<jam> jelmer: and, TBH, that "waiting for 1 client" is going to be random, depending on timeouts, etc.
<jam> jelmer: let me poke at that one, I actually want to do something like the 1MB tests I was doing elsewhere.
<jelmer> here's another one I hit: http://pastebin.ubuntu.com/697229/
<jam> we could certainly leave the test to only make sure that "Requested to stop gracefully" and assume that means everything is hooked up
<jam> jelmer: thx, I've been doing mixed windows and Linux testing. And I changed that line from 'signal.signal.' to signal.getsignal
<jam> but didn't notice because it doesn't run on Windows.
<jam> jelmer: so... What do you think about having a test that writes 1MB to disk? It seems a bit ugly. I want it to be larger than the socket buffer, though.
<jelmer> jam: is it really writing 1MB to disk? from my reading of the test it seemed like it put 1Mb on a memorytransport
<jam> jelmer: that was the other tests. I'm thinking to adapt the 'bb.test_serve' test to do something similar
<jam> 64kB is probably enough
<jam> (waits for fuller-md to notice :)
<fullermd> It's not a real test unless it's a prime number.
<jelmer> jam: It seems pretty well tested at this point, what's the reason you're thinking of having the bb.test_serve test do something similasr?
<jelmer> *similar
<jam> jelmer: acceptance test
<jam> since it is a 'blackbox' test.
<jelmer> hmm
<jelmer> is there a portable way to set the socket buffer size/
<jelmer> ?
<jelmer> jam: if there's no other way to test it, then it doesn't seem too unreasonable. Of course, we shouldn't be doing stuff like this in too many tests..
<jam> jelmer: there is setsockopt(SO_SNDBUF)
<jam> Though I'm pretty sure 64kB is sufficient, 1MB I would think is quite big
<jam> jelmer: the test passes on devpad at 64kB
<jam> jelmer: if I did it correctly, there is only ~1 new acceptance test is bb.test_server
<jam> I agree that we shouldn't do them for most testing
<jelmer> jam: that seems perfectly fine to me, fwiw
<jam> jelmer: updated test pushed
<jam> and the fix for signal.getsignal
<jam> well, pushed now. (had to put in ssh key:)
<jam> r6021
<jam> r6201
<jelmer> jam: lo
<jelmer> jam: sorryu
<jelmer> argh, my keyboard is acting up
<jelmer> jam: Anyway, I was going to say that it all looks reasonable to me. The large number of tests is really nice, and actually helped me understand how things are working.
<jam> jelmer: yeah, it helped me to assemble it as well :)
<jam> There were a couple of races in the code (racing against the test suite), but I was able to think them through, and make sure things were changed
<jam> so that there was always communication between the time variables were inspected.
<jam> (make sure to add the item to the list before you talk on the socket, etc.)
<jelmer> jam: yeah, it seems particularly hard to consider all the corner cases here
<jelmer> jam: was somebody else still looking at your other in-progress MP?
<mgz> okay, had lunch, and am on mumble server
<mgz> ...I probably need a better mic though
<mgz> can someone spare a moment to come on and tell me how much too quiet I am?
<jam> jelmer: poolie approved it offline
<jelmer> jam: cool
 * jelmer stumbles onto mumble for a bit too
<jelmer> working mumble in under 5 minutes!
 * jelmer sees progress
<mgz> cool, mumble experiment worked
<mcepl_> could somebody suggest 100% working way how to get working bzr fast-export on Fedora?
<mcepl_> I have to do symlinking of fastimport to ~/.local/lib/python27/site-modules and yes I get this backtrace http://fpaste.org/RFaK/
<jelmer> mcepl_: do you perhaps also have fastimport in ~/.bazaar/plugins with a different name?
<mcepl_> jelmer: well, I have ... when I don't how is bzr supposed to find it?
<mcepl_> I am sorry, i am not very good with bzr (use fast-export only to get the repository to git so i don't have to bother with bzr anymore ;))
<jelmer> mcepl_: bzr will either find it in the standard Python import path at bzrlib.plugins.fastimport
<jelmer> or you can add the plugin in ~/.bazaar/plugins, e.g. "bzr branch lp:bzr-fastimport ~/.bazaar/plugins/fastimport"
<mcepl_> when I tried to follow http://doc.bazaar.canonical.com/plugins/en/plugin-installation.html
<mcepl_> which doesn't work
<mcepl_> let me give you the error message
<mcepl_> jelmer: http://fpaste.org/PHVY/
<mcepl_> what am I missing?
<jelmer> mcepl_: can you pastebin the output of "bzr plugins -v" ?
<mcepl_> no problems there http://fpaste.org/ZmiO/
<jelmer> hmm
<jelmer> mcepl_: did you try to install fastimport any other way perhaps, are there other copies elsewhere on your system?
<jelmer> it seems that somehow "from fastimport import ..." is loading the bzr plugin rather than the fastimport python module
<mcepl_> I don't think so http://fpaste.org/LiCQ/
<jelmer> mcepl: /home/matej/.local/lib/python2.7/site-packages/fastimport
<jelmer> mcepl_: what's that?
<mcepl_> locate fastimport from whole system
<mcepl_> proof, that there is no other copy of fastimport here
<jelmer> mcepl_: what kind of link is it?
<mcepl_> oh, that's a dead symlink to
<mcepl_> when i remove that I get
<mcepl_> mitmanek:~ $ bzr selftest fastimport
<mcepl_> bzr: ERROR: No module named fastimport
<mcepl_> You may need to install this Python library separately.
<mcepl_> mitmanek:~ $
<jelmer> mcepl_: You need to install the python fastimport module (which is different from the bzr fastimport plugin)
<mcepl_> doh
<mcepl_> where does it grow?
<jelmer> it's in the cheeseshop, or http://launchpad.net/python-fastimport
<mcepl_> I don't think we have it in Fedora
<jelmer> (or packaged in Debian/Ubuntu/Arch/Fink/..., but I guess you're on RH ?)
<jelmer> yeah
<mcepl_> OK, got it
<mcepl_> I accept that this is PEBKAC, but I think there could be something more explicit at somewhere.
<mcepl_> now I have succesful selftest
<jelmer> mcepl_: yeah, it's a bit unfortunate. the bzr-fastimport commands ("bzr fast-import", etc) give a clearer message but not selftest
<mcepl_> jelmer: any ideas about http://fpaste.org/91vw/ ... (it's bitlbee repo BTW)
<mcepl_> bzr: ERROR: 86daca7b9076381129708faf127820de.iix is not an index of type <class 'bzrlib.btree_index.BTreeGraphIndex'>.
<mcepl_> bazaar 2.4.0, git 1.7.6.2
<jelmer> "charis:/tmp/bitlbee.git% bzr fast-export --plain http://code.bitlbee.org/bitlbee | git fast-import" seems to work fine here
<mcepl_> I'll try once more from plain directory
<mcepl_> no error, but
<mcepl_> 16:20:12 WARNING: not creating tag u'1.2.7-1' pointing to non-existent revision wilmer@gaast.net-20100515151824-1bv2apjub0w9c66j
<jelmer> mcepl_: right, git doesn't support ghosts
<mgz> jam: is there extra overhead for a 'def' function in pyrex than a 'cdef' one? I forget.
<jam> mgz: a 'def' function is a regular python func, accessible to other python code
<jam> cdef is a pure C func, not accessible from general python code
<mgz> right, and if I want to expose a (currrently) cdef function, should I wrap it in a new def one, or just change it to def?
<mgz> I'm looking at dirstate.pack_stat
<jam> mgz: 'it depends' :) If it is critical time, you want a wrapper
<mgz> (...which I also have problems benchmarking... the best I've come up with is a big tree and touching every file)
<mgz> okay, a wrapper is what I have, will commit
<jam> mgz: you shouldn't have to touch every file, a big tree should be enough
<jam> specifically, pack_stat gets called for each one to compare it to the stored value
<mgz> ah right, but I can't then see it in the profile because the pyrex version is called directly from another pyrex function
<exarkun> bzr error, <http://buildbot.twistedmatrix.com/builders/winxp32-py2.7/builds/440/steps/bzr/logs/stdio>, "Cannot create a file when that file already exists"
<mgz> hm, can you make your bot use -Derror exarkun?
<exarkun> 'bzr -Derror checkout ...'?  Probably not.
<mgz> could set it in bazaar.conf instead?
<mgz> if you could find that error in .bzr.log that would do too.
<exarkun> I can probably find it in .bzr.log
<exarkun> er, if I can find the directory that file is in.
<exarkun> ah, there it is.  I wonder how to get it off this computer.
<mgz> ...I hope you're not typing it across by hand :)
<vila> ... he needs to learn it by heart before he starts typing
<mgz> okay, end of day 1 aim, fix two bugs with seven duplicates between them.
<vila> mgz: way to go ! Congrats !
<mgz> first, to write some tests...
<Noldorin> hi jelmer
<jelmer> hi Noldorin
<Noldorin> how's it going?
<Noldorin> any much progress? :-)
<SpamapS> Is there a way to force a 'bzr export lp:something' to not use ssh ?
<mwhudson> SpamapS: BZR_HOME=/tmp bzr export ... probably works, for slightly obscure reasons
<mwhudson> SpamapS: why do you want to avoid ssh?
<mwhudson> jelmer: i assume you've seen https://code.launchpad.net/~python-dev/python/trunk and related fun?
<SpamapS> mwhudson: automated test
<SpamapS> mwhudson: in a chroot, so it won't have access to my SSH keys
<mwhudson> ah ok
<SpamapS> actually thats perfect that solves some of my other problems.
<mwhudson> SpamapS: don't set launchpad-login in the chroot?
<SpamapS> I don't
<SpamapS> $HOME is bind mounted..
<SpamapS> so its picking up anything in there
<mwhudson> oh
<mwhudson> right
<SpamapS> exporting that at key moments to /tmp/sometmpdir will work actually
<mwhudson> then BZR_HOME=/random/stuff
<mwhudson> is probably reasonably appropriate
<mwhudson> (or running as a different user in the chroot, or something)
<jelmer> mwhudson: yep, working on submitting an updated bzr-svn
<Kilroo> This is relevant to my interests.
<Kilroo> Hehe. I was actually just revisiting bzr today for purposes of comparing bzr-svn and hgsubversion.
<jelmer> Kilroo: this issue has already been fixed in bzr-svn, it's just because of the snapshot of bzr-svn launchpad is using
<Kilroo> I don't know what issue you mean; I just happened to get home from work and look in here and see you talking about it. I was entertained.
<jelmer> ah, ok :)
<Kilroo> I think I figured out the shortest sequence of steps to combine bzr-svn and bzr-colo to result in the closest possible analog to what hgsubversion does by default with a TBT svn-layout.
<jelmer> I'm not sure what hgsubversion does by default - what did you end up with?
<Kilroo> Ah...well, what I actually tested was...I think... bzr colo-init; bzr svn-import <source> .bzr/branches/origin; bzr switch colo:origin/trunk; bzr colo-prune colo:trunk
<Kilroo> I'm actually curious whether bzr init-repo --no-trees; bzr svn-import <source> .bzr/branches/origin; bzr checkout --lightweight colo:origin/trunk would accomplish effectively the same thing.
<jelmer> you'd definitely need colo-init somewhere in there if you want to use bzr-colo
<Kilroo> ok. That was the part I wasn't sure about, because one of the things I was looking at seemed to imply that switch colo:etcetera would work without it.
<Kilroo> Incidentally, If you have hgsubversion and you hg clone the root of a trunk-based svn repository it just translates it into Mercurial named branches.
<jelmer> Kilroo: we're making colocated branches a part of core bazaar, so in the future just "bzr clone <svn-url>" would do the same thing
<Kilroo> Yeah, I was reading up on that.
<jelmer> mwhudson: still there?
<mwhudson> jelmer: hi
<jelmer> mwhudson: can I trouble you for a quick lp review? It's the update of bzr-svn to fix the tags issue
<mwhudson> jelmer: sure
<mozmck> I'm using tortise bzr in windows.  Can I revert to a previous revision of my code but still keep the changes I'm reverting away from?
<ccxCZ> you probably want uncommit then, not revert
<mozmck> Will this keep my changes in the repository?
<mozmck> The revision I want is 3 revs back.
<ccxCZ> if you want to diff to that revision you can just do that. if you want to create separate working tree on that revision, you can checkout that specific revision
<ccxCZ> not sure what you are trying to do
<mozmck> I guess checking out the specific revsion in another tree will work.
<mozmck> I am trying to go back to some code I had working, but keep my other changes in case I need them later.  A separate tree is probably the best way.
<ccxCZ> probably. you can also shelve your changes
<mozmck> Ah, hadn't seen that command before.  Thanks!
<poolie> mozmck, ccxCZ, if you want to keep uncommitted changes use shelve
<poolie> if you want to leave the committed changes alone but go back to a previous revision, use update
<mwhudson> jelmer: i guess you didn't need me for that review after all?
<jelmer> mwhudson: sorry, I forgot to mention
<jelmer> mwhudson: my kernel oopsed and when I rebooted Curtis had already done a review
<mwhudson> jelmer: hahaha
<jelmer> mwhudson: thanks, though
<mwhudson> don't worry, i haven't been hanging around waiting
<jelmer> mwhudson: heh
<jelmer> mwhudson: thanks for *offering* to review that branch :P
#bzr 2011-09-27
<poolie> hi all
<pzn> need newbie help on bzr, this is my first day with bzr. already did a svn dump, and used svn2bzr.py to create a bzr repository. now I need to know how to "commit"
<pzn> suppose that I want to have a central repository in 192.168.1.1 via ssh. how can I specify bzr to commit to this machine?
<beuno> pzn, so, you may want to use bazaar in a distributes manner
<poolie> hi beuno
<beuno> instead of centralises, like svn
<beuno> poolie!
<beuno> heya
<pzn> beuno, no, I want to use it centralized, for everyone at my work to have a center place to commit
<beuno> pzn, have you seen http://doc.bazaar.canonical.com/bzr.2.4/en/mini-tutorial/index.html?
<beuno> or, I guess, http://doc.bazaar.canonical.com/bzr.2.4/en/tutorials/centralized_workflow.html
<pzn> beuno, thanks! it seems exactly what I need!
<poolie> hooray
<mangojambo> hi
<vila> hi all !
<babune> on 8 slaves, 3 are failing, 1 is hanging spuriously
<babune> 2 are hanging "reliably" freeBSD and OSX, maverick is hanging spuriously
<vila> poolie: and that's after filtering the failure for launchpad appearing dead while making tea locally ;)
<poolie> hi vila
<vila> poolie: _o/
<vila> poolie: feedback on library_state use wanted: https://code.launchpad.net/~vila/bzr/491196-cmdline-options/+merge/77003
<fullermd> Well, stop making tea, if it's breaking launchpad   :p
<vila> fullermd: ok, back to coffee then :)
<vila> I was only waiting for someone to mention it ;)
<fullermd> Good thing I'm around.  So many people are just so unwilling to embrace the obvious solutions.
<vila> poolie: the ip route add/del trick was a good idea despite the babune fallout (unrelated to the hangs though)
<vila> bbiab
<poolie> vila, hey i'm glad to hear it
<vila> poolie, jam, jelmer, Riddell, mgz: standup in five minutes ?
<Riddell> stand up, clap hands, shout bzr
<poolie> yup
<poolie> mgz your mission is to get linux audio working in 5 minutes
<vila> poolie: hehe, I think he still needs to join :)
<poolie> mgz, hi?
<vila> mgz: hey ! Join us on mumble !
<poolie> jam, for "i don't understand the encoding" byte strings there's also the option of doing what py3 does
<jam> poolie: sure. We just need to figure out how we want to represent them internally in bzr, especially how that gets encoded into long-term storage.
<poolie> yeah
<jam> I don't know what happens if you try to create a file from that, etc.
* jam 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: jam
<poolie> i see http://babune.ladeuil.net:24842/view/%20High/job/selftest-osx-10.6/305/console has failed
<poolie> the meaning of the failure is not obvious
<poolie> ok
<poolie> so, vila, could you please propose about two sessions for uds?
<poolie> on, i would guess bfbia and bzr/lp/udd
<poolie> and other topics, if you want
<jam> vila: I see this failure on Maverick: http://babune.ladeuil.net:24842/job/selftest-chroot-maverick/222/testReport/junit/bzrlib.plugins.launchpad.test_lp_directory/TestDebuntuExpansions/test_bogus_distro/
<poolie> perhaps one specifically about merging quilts?
<jam> which indicates it is actually trying to connect to Launchpad
<vila> jam: forget about that one
<jam> lp_directory.py", line 99, in _resolve_via_xmlrpc
<jam> poolie: it would be interesting to get feedback about what people actually expect that to mean
<vila> jam: I was redirecting lp requests to a blackhole at that point in time while testing the make tea stuff
<jam> vila: k. Well, we shouldn't be contacting lp during the test suite in general, it is sort of ugly. I wonder if we can easily do it better.
<jam> certainly, we should be able to run the test suite without an internet connection at all.
<poolie> jam, 'that' meaning quilt merging?
<jam> poolie: yes.
<vila> jam: yeah, this has been discussed in the past
<jam> There are a lot of possible results from merging quilts.
<jam> vila: I think those tests were written by barry, who probably didn't realize
<vila> jam: yes it was and that's when it was discussed
<jam> anyway, thats the only 'failure' for maverick I found, which we certainly could fix.
<vila> silly jenkins doesn't show the killed builds anymore
<jam> I realize you have more knowledge about what is going on than in exposed via the babune webpage, though.
<poolie> jam, ok, so a session about it would probably be good
<poolie> probably better if we go in with an idea about how it ought to work
<poolie> vila, btw, you're pp this week
<vila> poolie: you mean next week ?
<poolie> oops, i meant jam
<poolie> you're fine
<jam> poolie: yep, I updated the IRC topic
<jam> I saw your wiki update
<mgz> is there anything you need me to do or prepare for the UDS sessions poolie?
<vila> poolie: which track did you use at the last UDS ?  Fundations ?  Other ?
<jelmer> vila: yep, foundations though I think the track leads will shuffle things around as they see fit
<poolie> mgz, hm, perhaps you could pair with vila on the proposals?
<poolie> that will give you some mental framework for it
<vila> jelmer: ok, is there a process documented somewhere to do a proposal ? (poolie, mgz, good idea ;)
<poolie> there's some ubuntu discussion in https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2011-September/012901.html
<mgz> cool, I will follow along
<jelmer> vila: I think jono or jorge posted a "how to do a UDS session" thing to the ubuntu-devel list last UDS
<jam> poolie: do you think we should try to close the 'server-read' side after SIGHUP?
<jam> (shutdown(SHUT_RD), etc)
<jam> I don't know if that is going to help us on detecting server-side-wants-to-be-done earlier.
<poolie> hm
<poolie> as you said there's a lot of buffering
<poolie> i think shutdown also has different win32 behaviour
<jam> poolie: looking here: http://msdn.microsoft.com/en-us/library/ms740481%28VS.85%29.aspx
<jam> It seems to say, the local process can no longer '.recv()'
<jam> however, TCP will still queue things up
<jam> so it is only a in-process flag
<jam> so yeah, it does nothing
<jam> ah, I guess shutdown(SEND) will send a FIN packet.
<jam> That may be better than just close()
<poolie> > For TCP sockets, if there is still data queued on the socket waiting to be received, or data arrives subsequently, the connection is reset
<poolie> so the client gets a ECONNRESET
<poolie> this is a bit alarming if the server has in fact read the whole stream
<poolie> and it also breaks the other side of the connection
<poolie> so istr this is pretty useless on windows
<jam> poolie: sure. Also, the most important reconnect to get working is bzr+ssh IMO
<jam> so whatever we do has to cope with how ssh will treat the signal
<jam> but you have a very good point
<poolie> so
<jam> we can't just stop the read side, because the current request may be reading from the client.
<poolie> so the server's going to finish its current request then close the socket?
<poolie> there is one option
<poolie> i forget how the server's actually hooked up
<poolie> on lp
<jam> poolie: i'm pretty familiar with it :).
<poolie> but if stdin and stdout are different fds, eg if they are pipes, then you can simply just close stdin
<poolie> and that will give a clean message to the ssh server that it has closed, which it can pass backto the client
<poolie> :)
<jam> poolie: right, you could close stdin, except that the "current request" may be pushing a stream of data from the client.
<poolie> right
<poolie> you can close it at the point you've decided you're not going to read anything more
<jam> right
<jam> that has to be done pretty much on a per RPC level, though I'm pretty sure all of them are defined as "read for a while" then "write for a while" then done.
<jam> So you could notice "I transitioned to the 'write' phase, and I'm requested to stop after this, close the read side."
<poolie> yep
<poolie> so you said originally 'do i think we should do this'
<poolie> i don't think it's totally necessary
<poolie> it seems like a thing that could be done later
<poolie> it's not clear to me it will actually help, because i'm not sure the client will not get a very clear message that the server's not prepared to read any more
<poolie> i'm not sure it will be any more clear, or helpful, than the server just sending the response to the current rpc and then simply closing the sockte
<jam> poolie: right. Digging into it feels like something we can try in the future, but in reality we have to just handle that we can't reliably detect server has shutdown before we start trying to send the new rpc.
<jam> vila, poolie: Who's sending the standup notes to the list?
<vila> jam: please do
<jam> will do
<vila> jelmer: can't find that in ubuntu-devel, do you have an URL ?
<jam> sent
<jelmer> vila: hmm, not sure
<jelmer> vila: I thought it might have been linked from summit.ubuntu.com, but that appears to be down atm
<jelmer> vila: one of the ubuntu community team members should be able to point you at it
<poolie> +1
<poolie> for instance dholbach
<vila> jelmer: I'll try that too, I'm trying to get touch with slangasek ATM
<poolie> it would be worth engaging with him even if there are documents
 * vila nods
<vila> both pinged
<vila> jam: jenkins hiding the killed builds seems to be a very recent change, in the mean time, I've started builds for OSX and FreeBSD which are longer than usual indicating a hang:          http://babune.ladeuil.net:24842/job/selftest-freebsd/buildTimeTrend     http://babune.ladeuil.net:24842/job/selftest-osx-10.6/buildTimeTrend
<jam> vila: is there a way to get the raw subunit output?
<jam> or something that can give individual test times?
<mgz> jam: with parallel builds there are multiple subunit streams which complicates things
<vila> only on success AFAIR
<mgz> if all goes correctly babune can show the build times
<mgz> ...but yeah, what vila said
<vila> and parallel are the first line of defense against hangs :-/
<mgz> there's no good option when something goes really wrong, having to kill thw whole job without any feedback on where the problem was is... troublesome
<vila> or leaks leading to slave crashes or whatnot
<jelmer> vila: Steve's in Portland I think, so not likely to be up at this hour :)
<mgz> so, I did add a flush at test start to subunit a while back, so if all streams get to disk there's some hope a test name could be obtained
<mgz> whether that would actually be enough to repro is another matter
<vila> mgz: parallel use pipes no ?
<vila> oh you mean, the main one
<vila> jelmer: thanks for the heads-up, I'll retry later today
<mgz> ah, yeah, the concurrent reporter might defeat us. hm.
<vila> mgz: but the main one is what jenkins collect so...
<jelmer> vila: submitted a review to your cmdline-options MP, btw
<vila> jelmer: thanks, let me see that
<vila> jelmer: pushed a new version with some fixes, will look at hiding the option but see my remark
<poolie> jelmer, did your bfbia db patch get unblocked?
<jelmer> poolie: sortof, it's now a trivial one-liner that's not particularly important
<poolie> francis reminded me today that unless you specifically need review from robert, you can probably get a faster answer from stub
<poolie> oh right, i saw it shrunk
<poolie> ok
<jelmer> poolie: I'll take it off +needsreview, thanks for the reminder
<jelmer> poolie: It will most likely still be necessary, but I'd rather get the other stuff landed first; if I have to do more database changes I'd rather do them together
<poolie> no problem, just wanted to see if you were blocked
<poolie> robert gets some kind of prize for bugspam
<poolie> heh, of the kind jelmer used to do :)
<vila> jelmer: hidden options are still shown in the help ! So I've pushed a new fix to hide it.
<jelmer> poolie: :)
<jelmer> vila: ah, cool
<jelmer> vila: I don't think anybody will use --override-config (vs -O), which is also why I'm a bit hesitant to penalize all help texts when adding it.
<jelmer> vila: I'm surprised hidden options are still shown in help though, isn't not showing them there the whole point of hidden?
<poolie> uh, hidden?
<poolie> i would think it should be a global option
<mgz> that was my thought reading the mp
<mgz> showing it in the help for every command seems... unnessersary
<Riddell> does bazaar@canonical .com go anywhere?
<mgz> it might be less discoverable, but as you have to go off and find the config option names anyway...
<vila> doesn't global options require each command to declare it ?
<lifeless> poolie: reminds me, I have another 75 bugs to triage today
<mgz> lifeless: you're insane :)
<poolie> lifeless,  is spamming ~40 people really worth the clarity?
<lifeless> mgz: we're closing a lot that are stale/done/clearly-wont-fix
<lifeless> poolie: they are welcome to unsubscribe :)
<poolie> i refer specifcally to changes that are only mid->low
<lifeless> poolie: and yes, its well worth it
<poolie> yawn
<mgz> launchpad isn't quite smart enough to not send mail for trivial changes yet
<poolie> yeah
<poolie> that would be nice
<poolie> as would having an internal activity view so i could turn off mail
<poolie> one day
<poolie> good night all
<vila> poolie, mgz, jelmer : Right, hidden options should be ouput in help, that's indeed the point, so there is a bug there
<jelmer> have a great night poolie
<jelmer> *evening
<vila> and both standard and global options seem to be affected
<vila> jelmer: bug 860424 filed
<ubot5> Launchpad bug 860424 in Bazaar "standard and global options don't respect their hidden attribute and are shown in help" [Medium,Confirmed] https://launchpad.net/bugs/860424
<vila> jelmer: so, the consensus seem to be this should be fixed ?
<vila> jelmer: should I put the -O proposal as wip in the mean time ?
<vila> jam: jenkins hiding interrupted builds seems to be a very recent change, in the mean time, there are two builds hanging right now for FreeBSD and OSX (  http://babune.ladeuil.net:24842/job/selftest-osx-10.6/buildTimeTrend and http://babune.ladeuil.net:24842/job/selftest-freebsd/buildTimeTrend)
<vila> jam: I killed the previous ones this morning and they were showing up at the same place, I also did a jenkins upgrade which may have introduced this behavior change but... that's not mentioned in the changelog)
<mgz> yeah, the console output isn't very useful because it's been syncronised to make sure all parts of a test appear together
<jelmer> vila: Yeah, I think this should be fixed first
<vila> haa, haa, haa, haaaa, shaving the yack, shaving the yack
<vila> let's do that after lunch :)
<jelmer> well, the problem otherwise is that we'd have to update the help texts and then change them when that bug gets fixed
<vila> jelmer: oh, if it's hidden, is that ok with you to keep --override-config or do you have  (yeah I know)
<jelmer> vila: if it's hidden I don't mind there being a --override-config
<vila> or do you have a less ambiguous proposal than --option (or am I the only one feeling it's ambiguous ?)
<vila> ok
<vila> cool, thanks
<jelmer> vila: btw, have you seen the config system used in bzr-builddeb?
<jelmer> It's also something that could very well use stacks
<vila> jelmer: not in detail, but I mailed you a question about option expansion long ago :)
<vila> jelmer: do you see missing features in the stack based design for builddeb >
<vila> ?
<jelmer> vila: not as far as I can tell
<vila> \o/
<vila> :)
<vila> jelmer: hmm, there is a possible workaround for -O: handle it as --builtin, --profile, --lsprof, --coverage and so on and just forget about making it a standard option and its fallouts
<mgz> vila, that's a choice between `bzr -O... command ...` and bzr command -O... ...` is it?
<vila> wow, dunno, let me check
<vila> doh !
<vila> indeed, that's a side-effect of the implementation but it's not a choice, *both* are handled
<vila> I don't think that was a conscious choice when implemented but thanks for solving that puzzle ;)
<vila> the implementation just remove such options from the argv *before* calling cmd.run() no matter where they appear
<vila> jelmer: ^ ?
<jelmer> ah
<jelmer> vila: I think it should indeed be a global option
<vila> err, as in forcing all commands to declare it ? Or as in those pseudo-globals I mentioned above ?
<jelmer> pseudo-globals mentioned above (how are they pseudo?)
<vila> the distinction is quite blurry as some are registered as globals, some not.. ha, and I think the pseudo-ones  are documented in help_topics._global_options *-)
<vila> 8-) even
<vila> right, the help there makes that clearer
<jelmer> hmm, my upload for 2.2.5 is being rejected
<vila> ghaa, my lp-propose crashed :(
<jelmer> (2.2.5 seems to have only 3 bugs that are actually relevant for ubuntu, btw)
<vila> jelmer: should be the moon, let's retry :)
<jelmer> vila: already tried twice, not sure what's wrong
<vila> jelmer: yeah, I was kidding
<jelmer> I didn't think you seriously meant it could be the moon >-)
<vila> jelmer: but bug #715000 and #710410 sound good to release though and the last release was looong ago
<ubot5> Launchpad bug 715000 in Launchpad itself "Stacking is not fully transitive" [Critical,Fix released] https://launchpad.net/bugs/715000
<ubot5> Launchpad bug 710410 in QBzr "ConfigObj is able to write bad branch.conf which is not possible to read back" [Medium,Confirmed] https://launchpad.net/bugs/710410
<vila> huh ?
<vila> bug #609187
<ubot5> Launchpad bug 609187 in bzr (Ubuntu) "users are not warned when branching ubuntu:foo (or lp:ubuntu/foo) and the package import of foo is out of date" [High,Fix released] https://launchpad.net/bugs/609187
<jelmer> vila: bzr uses the system configobj so bug 710410 isn't relevant
<vila> yeah, read the bad number
<jelmer> but yeah, those other two are still nice to get fixed in maverick
<vila> I really meant 609187
<jelmer> I actually meant 805809 rather than 609187
<jelmer> I doubt there are any Ubuntu developers who are still on Maverick
<vila> yeah, I was about to mention that this one is pita
<vila> jelmer: anyway, I'll ask oulder for more feedback next time I'm about to cut a release for SRUs but... 2.2.5 is ready to release, no bugs are targeted to 2.2.6...
<vila> louder not oulder
<vila> jelmer: and I won't object about a discussion of what we should do we all our series, I don't have objections either about EOL'ing 2.0 (planned for 2011/11 so far, will not be SRUed imho), keeping 2.1 for lucid
<vila> for 2.2 the plan is 2.2.6 in 2012-02 and 2.27 in 2012-09 (if bugs justify that) and EOL too
<vila> the plan for 2.1 is not that clear in my mind ;) But it's an LTS so we may have to support it longer
<jelmer> vila: I think this is still enough to do a release for, but I do think we should consider whether releases are necessary (especially for old series)
<vila> full agreemnt
<vila> I *always* ask for feedback before doing releases for old series, may be I should do that earlier and *louder*, but I'm pretty sure this one was discussed
<vila> jelmer: ç¨ç´ã©³â¼¯æ½£æ¤æ°®ç¡æ®ç¨æ¡æ¸®ç¥ç¸¯æ¥¶æ¬æ¯çºã ¯ã¶ã´â´´æ¥¨æ¤æ¹¥æ¼­ç°æ½©ç®â¬¯æ­æ²â½¥ã·ã±
<vila> grrrr
<jelmer> vila: ehh.. sure?
<vila> jelmer: I swear, I pasted: https://code.launchpad.net/~vila/bzr/860424-hidden-options/+merge/77159
<vila> :)
<vila> jam: http://paste.ubuntu.com/697835/ is what I found on the OSX slave, not sure it's related but the smart server being involved in all cases is suspicious in itself
<vila> jam: http://paste.ubuntu.com/697836/ is for the FreeBSD one (not clearly related to the OSX one, so... both may not be valid starting points)
<mgz> phew, enough starting at pyrex generated C, have reproduced the right error
<jam> mgz: its not so bad once you learn to ignore _pyx_v_ :)
<jam> vila: what I really don't understand is why one parallel subprocess would cause another one to hang. Or is it just that things are *slow* not that things aren't working?
<jam> and can I get ssh access to those machines?
<vila> well, probably the main process is waiting for a hung children
<vila> but as mentioned this morning, I've never been able to debug the jenkins runs themselves, far too many layers involved there
<vila> you can use jenkins (notably the *subset* jobs) to restrict the tests and better identify the culprits but in the end you need to know which race it's about to fix it
<jelmer> Riddell: I reviewed your i18n-plugins branch
<jelmer> Riddell: I wonder if we need some sort of mechanism to prevent loading all po files for all plugins all the time
<jam> vila: are you sure message is a 'global option' ?
<jam> I don't think you can do "bzr status --message"
<jam> I think of global as more "--verbose", etc.
<jam> And your proposed "-O" would certainly be global.
<vila> jam: see option.py
<vila> jam: and see cmd_log which hides it
<vila> jam: and try 'bzr help log'
<jam> vila: cmd_log just implements a regular Option(message, hidden=True)
<jam> I think you want to look at "_standard_option" in option.py
<jam> So, to use better terms.
<vila> that's where I came from :)
<jam> _global_option is just a defined option that Commands can reference by string, rather than having to use the Option class
<jam> _standard_option is an option that is available to all commands without them doing *anything*
<jam> and those probably can't be hidden
<jam> your -O should be a _standard_option and you want it to be hidden.
<vila> no, it's just asking for trouble, it's far easier to make an option similar to --lsprof and the like, read the irc log
<jam> vila, from your patch:
<jam> +_standard_list_option('override-config', short_name='O', type=unicode, +                      help='Override a configuration option value,' +                      ' e.g. -Oname=value')
<jam> sorry about the bad paste, but it is *clearly* a "_standard_option"
<jam> not a global one
<vila> jam: yes, that's a wrong approach, read the other comments and the irc log
<vila> and my last push on this proposal (which lp should be displaying rsn jelmer ;)
<jam> vila: I don't see anything in the "other comments" that it shouldn't be a standard option
<jam> I think it *should* be a standard option
<vila> try the irc log ?
<jam> vila: where ?
<vila> here
<vila> it was discussed earlier
<jam> today, yesterday, 3 hours ago?
<jam> I guess when should have been a better question
<vila> jam: certainly not before the additional revisions on the mo :)
<vila> s/mo/mp
<jam> vila: before or after the standup?
<jam> vila: I'm pretty sure poolie meant to say "standard_option" not global option
<jam> he meant global as in, applies to every command
<jam> which is what I originally thought the bug was, etc.
<Riddell> jelmer: I think plugins can choose to not load the gettext file until needed if they so wish
<vila> jam: from 11:34 my time
<vila> jam: read the log, global options are opt-in for all commands
<jam> vila: I don't think "-O" should be opt-in
<jam> I don't think poolie thought so either
<jam> he never commented
<jam> I'm 75% sure when he said: "i would think it should be a global option" he meant that it should apply to all commands
<jam> not be opt-in
<vila> but of course it shouldn't be opt-in which is why it shouldn't be a global option
<jam> vila: so from what I can tell, the *real bug* is that _standard_options don't respect hidden, which you haven't fixed
<jam> and would thus still block landing -O
<vila> right, if your point is to block landing, I'm sure you can find a way to get there
<jam> i'm not specifically trying to block landing. Jelmer asked that -O be hidden
<jam> you said "global options don't respect hidden"
<jam> but they do
<jam> you noticed that
<jam> you haven't handled "standard options don't respect hidden"
<jam> I'm not trying to block you
<jam> just pointing out that the bug is still there
<vila> now, would you mind reading the log and having a look at bug #860424 and the assiciated mp we may have some progress
<ubot5> Launchpad bug 860424 in Bazaar "standard and global options don't respect their hidden attribute and are shown in help" [High,In progress] https://launchpad.net/bugs/860424
<jam> vila: I've read all of that
<vila> when ?
<jam> vila: I've read them 2 times while we've been discussing it
<vila> ha, you commented on the mp, why didn't you start with that ?
<jam> vila: I was poking you on IRC to point out the MP, I could have linked it, I guess
<vila> right, anyway, for  https://code.launchpad.net/~vila/bzr/860424-hidden-options/+merge/77159
<vila> I think message and log are still appropriate since they show that a global option can be hidden by a specific command
<jam> vila, so yes, global options are already hidden. That doesn't fix the full bug, though, does ti?
<jam> that _standard options are not hidden?
<vila> but my point is: do we really want to hide a standard option ?
<jam> So to start with, yes, I was a bit confused because "global option" isn't a global option
<vila> which of the existing ones would you hide ?
<jam> vila: -O
<jam> as discussed
<jam> which started this whole thing
<vila> you miss the point
<vila> -O is *not* a standard option anymore
<jam> vila: why not? (i think everyone has actually said it should be)
<jam> (caveat the confusion between global_option and standard_option)
<vila> expect it should be hidden which standard options doesn't allow
<jam> which is a bug
<vila> really ? Which use case do you have ?
<jam> vila: I feel like we are talking past eachother.
<jam> Do you feel that -O should be explicitly stated for every command?
<vila> no
<jam> k
<jam> That makes it a standard_option, right?
<vila> no
<vila> see my last revision
<vila> jam: is 'coverage' a global option ?
<vila> jam: is 'coverage' explicitly stated for every command ?
<jam> vila: 'master options' as they are listed were implemented before we had standard_option
<jam> I really think standard_option is a better framework for it
<vila> same goes for a bunch of them, the confusion is that *some* of them are still declared in option.py
<jam> All of the ones in run_bzr should be removed, IMO
<jam> it is a *really* bad argument parser that I wrote way back when
<jam> before we integrated with optparse and made it possible to do nice things
<jam> like "--lsprof-file foo" doesn't work.
<jam> sorry
<jam> '--lsprof-file=foo' doesn't work
<vila> fell free to fix it :) In the mean time it's out of scope for bug #491196
<ubot5> Launchpad bug 491196 in Bazaar "want a way to set configuration options from the command line" [High,In progress] https://launchpad.net/bugs/491196
<jam> You have to spell it "--lsprof-file foo"
<jam> vila: I feel you did it the right way the first time
<jam> we just want to allow hidden=True to work
<vila> jam: hehe, thanks, me too
<jam> which doesn't seem very hard
<vila> jam: yeah, I tried that and saw this wasn't trivial *at all* so I found an alternate way
<jam> vila: Once stacks are generally supported, I think it should stop being hidden.
<vila> everybody is telling me I try too hard but when I use shortcuts you complain, take your pick ;)
<vila> jam: well, I can turn it into a standard option then ;)
<jam> vila: well, different people are saying different things, we are allowed to have different opinions
<vila> sure, but in this case there is a separate bug for the standard option that can't be hidden and that's not blocking bug #491196 anymore
<ubot5> Launchpad bug 491196 in Bazaar "want a way to set configuration options from the command line" [High,In progress] https://launchpad.net/bugs/491196
<vila> in my mp regarding the former I said I don't think hidding a standard option makes sense
<jam> vila: I think lsprof, etc should probably be turned into standard options, at which point we probably would want them hidden as well.
<vila> and I'd rather spend time on migrating the remaining options than implementing a feature nobody needs
<jam> digging into it, I'm having a hard time determining why they aren't hidden
<vila> exactly
<jam> given they seem to go through the same "is_hidden" code paths
<mgz> there seems to be agreement on the basic goal of -O everywhere but not in help
<vila> no they don't
<vila> they never call add_option which is where it's handled
<mgz> just the specifics need sorting out
<mgz> the way global options are done seems like a bit of a hack to me,
<jam> mgz: it was a big hack, written about 5 years ago
<mgz> and all the current ones are --long-likely-unique string form which at least is safe to find and pick out
<mgz> I'm not sure adding a more option like -O that needs arguments is sane
<Riddell> how do I log onto http://blog.bazaar.canonical.com/ again?
<mgz> Riddell: not done it myself since the move from wordpress I'm afraid
<jam> Riddell: I think you go there, click log-in under "Meta" (scroll down on the right)
<mgz> jam: hacks that survive often have things going for them :)
<jam> mgz: The original code in that area says circa "974.1.26"
<mgz> ^*'a more complex option'
<jam> 2005-08-18
<jam> so 6 years ago
<mgz> it's like a crocodile.
<mgz> one little meteor ain't gonna take it down.
<jam> vila: so... updating the new bug to say "options that are here should be migrated to hidden standard options", and then punting on doing that for your patch is ok
<jam> Riddell: did you find your way to the dashboard?
<Riddell> jam: yes thanks
<Riddell> I expected "login" not "log in"
<jam> I agree it is a bit hard to find log in
<jam> given how many portlets there are on the side
<jam> vila: interestingly enough, your diff on: https://code.launchpad.net/~vila/bzr/491196-cmdline-options/+merge/77003 stills says "Updating diff"
<jam> and has since the start of this discussion.
<jam> btw, pointing me to the IRC conversation and the bug etc was a red herring. Nowhere did you actually say the change to make it like --coverage/--lsprof (at least that I can find)
<vila> not for me ;)
<vila> jam: well, you were following the path I followed myself, I tried to point you at the missing steps before talking about the end result
<jam> sure, but you made it seem that things had been decided, which I could not actually find
<vila> for all commands: standard options, help is messed up, use hidden, it's broken, file a bug, oh, it's hard to fix but there is shortcut, use the shortcut
<vila> yeah right, you didn't mentioned you commented on the bug mp, so, are we on the same page now ?
<mgz> Riddell: pretty pictures!
<Riddell> does highlight that the pixel alignment on qdiff's central widget isn't great
<mgz> hm, that's true, it's up a bit. could pretend it's a 3d effect? :)
<Riddell> hmm, licencing breakage, test_copyright requires all files to have "copyright canonical" but with the new harmony agreements that might not be right
<mobby> Hi! Hope you don't mind me asking this here...
<mobby> I've been looking at the Bazaar Docs and came across the "switch" command. Apart from how uncommitted changes are dealt with what is the difference to the colo plugin?
<jelmer> mobby: the main difference is where the branches live
<fullermd> I'm not sure that question makes any sense.  It's like asking how donuts are different from fingers...
<jam> Riddell: potentially, except we haven't had to actually change anything yet
<jelmer> mobby: assuming you're talking about using "bzr switch" in a lightweight checkout
<jam> at least for core bzr
<mobby> Ok my understanding of "switch" is likely to be wrong then. I was reading the Local Sandbox section of the "Organising your workspace" page. It sounded very much like what the colo plugin does.
<fullermd> I think you're confusing (or confusing us) a command with a layout...
<fullermd> colo isn't an alternative to switch (that's nonsensical), it's an alternative to dir-based branches.
<fullermd> You'd need (or not need) the switch command just as much with one as with the other.
<mobby> Yeah sorry. I understand "switch" is a command rather than a layout.
<mobby> It was more the "local sandbox" workspace layout sounded like how the colo plugin works, but is achieved by core Bazaar rather than through a plugin.
<mgz> mobby: that's basically right, and how I do things on this machine
<jml> vila: there's a comment in pkgimport.conf in lp:udd saying that it could use expand_options once bzr 2.4+ is available
<mgz> I have a shared repo, with lots of branches under it without any workingtrees, and one 'tree' branch that I use switch on
<jml> vila: it looks available to me
<vila> jml: not on jubany :-/
<jml> vila: ah, ok.
<vila> jml: it's in the pipes though
<mobby> Ok good, that was my understanding of how it works. Sorry my initial question was misleading.
<vila> jml: so, how did you end up there ?
<jml> vila: I'm fetching information from each package in Ubuntu
<jml> vila: lp:udd does 90% of what I need.
<vila> haaaa, of course, ok, thanks ;)
<jml> vila: it needs to be refactored though
<vila> jml: oh yes, but if you don't need to *write* on lp, may be the udd/lpapi.py cover your needs ?
<jml> vila: well, that needs to be shoved into lazr.restfulclient
<vila> hmm, no, sorry, I thought more have been put there
<jml> vila: I'm thinking more of the stuff around the meta.db, handling job failure, etc.
<jml> parallelization.
<mobby> jelmer, fullermd, mgz: Thanks for your help.
<vila> right, so mass_import is indeed the right target for that
<briandealwis> Martin asked that I add a blog entry about bzr-tiplog to blog.bazaar.canonical.com and added me to ~bzr-bloggers.  How do I actually post an item?
<mgz> jam replied to that message on list saying the same thing before I got as far as hitting sned...
<mgz> briandealwis: Riddell might be just the person to ask :)
<Riddell> hmm, I don't know how to add a new user
<jam> briandealwis: go to that webpage: http://blog.bazaar.canonical.com
<jam> Riddell: he should be added, since he was added to bzr-bloggers
<jam> briandealwis: on the right hand side, (scroll down a bit) there will be a "Log in" link
<jam> follow it, and click a few login buttons, and you should get to the Dashboard
<briandealwis> jam:  ok, thanks
<yshavit> hi all, sorry if this is a dumb question... I've got a branch A that has gotten unwieldy, and I'd like to start from scratch -- but I do want to keep some of my work. My thought is to start a new branch B, and copy just the work I want from A into B. My question is, am I best off just using cp, or should I merge A -> B, then revert the files I don't want? Or does it not really matter?
<fullermd> I think the answer is going to depend on just what is "unwieldy" about it...
<yshavit> fullermd: first off, it's 4000 lines away from trunk at this point...
<yshavit> fullermd: I was trying to do too many things, and some of those things I ended up doing broken. So I'd like to "rewind" it, except the parts I want to keep aren't cleanly delimited by revno
<mgz> yshavit: it's mostly a matter of taste (so I should leave this up to fullermd), but I'd cherrypick bits across from the old branch and clean up as you go
<yshavit> mgz: alright, thanks
 * fullermd is somewhat frightened at the thought of anybody leaving matters of taste to him, and considers it a sign that somebody needs strong medication...
<mgz> so, use merge where it's useful, but with ranges or `bzr revert --forget merges` after
<yshavit> mgz: ah, I hadn't seen the --forget before. That could be what I'm looking for. Thanks!
<mgz> *--forget-merges
<yshavit> Though the more I look at this diff, the less I'm sure it can be separated out so cleanly. API changes ftw... :-\
<jamesw> hello, would someone please kindly explain the difference between pull and update to me?
<fullermd> pull manages a branch relative to another, update managed a working tree relative to its branch.
<vila> jam: natty contaminated by the hangs http://babune.ladeuil.net:24842/job/selftest-chroot-natty/231/
<mgz> right, I need to get ready to leave
<Matt_at_HP> good afternoon all
<Matt_at_HP> I am working on a image-based (hdd clone) style version control system for my department and was just wondering if bazaar has issues with 8GB+ binary files
<Matt_at_HP> so many people connected, but no one actively online :(
<Peng> .... 8 GB O_O
<ccxCZ> since you won't really have meaningful diffs, you might aswell consider using something along the lines of rdiff-backup instead of full vcs
<beuno> Matt_at_HP, I'm pretty sure bzr will have issues with 8GB binary files
<ccxCZ> I'm afraid bzr will load whole files into memory for creating diffs, so you might issues doing that on comodity hardware
<Noldorin> hi jel
<Matt_at_HP> I'm running enterprise hardware... hardware is not the problem
<beuno> Matt_at_HP, I'm sure bzr is not what you want for huge binary files
<ccxCZ> having >16G ram available?
<Matt_at_HP> okay that's cool... just doing some research
<beuno> IIRC, it won't save incremental diffs for binaries either
<beuno> so you'll have a multi-tb branch pretty quickly
<Matt_at_HP> I know this is the bazaar room, but is there anyone here that can recommend another dvcs that may be able to handle 8GB+ binary files?
<Matt_at_HP> ccxCZ: not worried about hardware requirements )
<Matt_at_HP> :)
<beuno> Matt_at_HP, git may be better at it
<Matt_at_HP> beuno: I have been doing some research into Git... will read more
<beuno> Matt_at_HP, http://stackoverflow.com/questions/540535/managing-large-binary-files-with-git
<ccxCZ> Matt_at_HP: consider what features you actually need. rdiff-backup or lvm snapshotting might be sufficient for your task
<beuno> but there seems to be comments about it not dealing well with 2gb+ files
<beuno> yeah, I would not put large binaries in a DVCS
<Matt_at_HP> okay... sounds like HP will need to develop their own
<Matt_at_HP> haha
<beuno> Matt_at_HP, you could write a plugin for bzr
<beuno> that essentially tracked these files
<beuno> but didn't add them to the tree
<beuno> Matt_at_HP, if you drop an email to the list, you may get more ideas: bazaar@lists.canonical.com
<Matt_at_HP> beuno: so let's say that I did write a plugin for this 8GB binary file project, are there any other issues that I may need to worry about?
<beuno> Matt_at_HP, no, plugins can override most of bzr, so you have a lot of freedom there
<Matt_at_HP> beuno: Thank you for help... very informative
<beuno> np
<fullermd> Somebody was talking about an external binary store a month or two ago.
<ccxCZ> sounds that it shouldn't be that hard to do, since you can reuse binary diff algorithm from rsync/rdiff
<Matt_at_HP> beuno: I am assuming that I would need to customize a plugin to handle version controlling for the binary files, as well
<beuno> Matt_at_HP, yeah, I'm unclear about the specifics
<Matt_at_HP> beuno: okay thanks again
<Matt_at_HP> everyone have a good day :)
#bzr 2011-09-28
<poolie> hi all
<poolie> cinerama, the update misbehaviour is bug 557886
<ubot5> Launchpad bug 557886 in Bazaar ""bzr update FILENAME" modifies more than just FILENAME " [Medium,Confirmed] https://launchpad.net/bugs/557886
<cinerama> I see
<cinerama> no me gusta
<poolie> i wonder if an easy fix is possible
<vila> hi all !
<poolie> hi vila
<poolie> that reminds me, dst
<poolie> when does summer time start for you?
<vila> err, good question :)
<vila> end of October according to my family's time keeper ;)
<vila> darn, I thought I could trick jenkins into revealing the aborted builds by reverting its previous version but that doesn't work, the jobs are still there on disk but not in web GUI :-/
<vila> so, you'll have to trust me or look at holes in the numbering, I'll try older versions later
<vila> anyway, natty has been seen hanging yesterday evening and maverick was this morning
<poolie> has it now
<poolie> thanks for telling me
<vila> that's maverick in the chroot, surprisingly the one I left in the vm hasn't so far
<vila> but well, that's the schrodinger nature of races ;)
<poolie> so do you have a reliable view of which revisions caused this?
<poolie> or at least a window on them?
<vila> http://babune.ladeuil.net:24842/view/%20High/job/selftest-osx-10.6/305/ for example
<poolie> cinerama, https://code.launchpad.net/~mbp/bzr/557886-update-file/+merge/77286
<poolie> fixes one of them
<vila> is it just me or is lp slower at displaying diffs ? Or is it because *we* are faster at mentioning the mps ?
<vila> I thought the diff was available in less than 5 minutes but that's already not the case here
<vila> ha, here we go
<poolie> when their rabbit stuff is loaded it should pop up faster
<poolie> well
<poolie> you will not need to reload
<poolie> the overall latency may be no better
<vila> reviewed
<vila> subjectively I prefer that my browser does the boring refresh job and just tell me when it's ready instead of forcing me to poll
<poolie> yup
<vila> it will feel faster because I'll spend *less* time caring about that
<poolie> https://dev.launchpad.net/LEP/NotificationService
<poolie> coincidentally i had that open
<vila> hehe
<vila> puzzling, reverting to a version from 2011-08-16 for jenkins still don't revealed the aborted jobs, stopping the experiment there
<poolie> hm
<poolie> vila, i'm out for a while, happy hacking
<vila> poolie: enjoy !
<jelmer> moin
<mgz> morning all.
<jelmer> hey mgz
<vila> hey jelmer, mgz !
<mgz> hm, we still have the 'giveback' confusion in the doc? I thought that had been changed...
 * mgz edits
<AuroraBorealis> is there anything that i should do to help find out whats causing this bug? https://bugs.launchpad.net/bzr/+bug/855155
<ubot5> Ubuntu bug 855155 in Bazaar "InconsistentDelta error when using bzr update" [Undecided,New]
<jam> jelmer: morning. You replied to bzr-announce about the pipeline release. Do you want me to bounce the message, or let it through?
<jelmer> jam: Whoops
<jelmer> jam: please bounce it
<jam> I expected as much, but I figured I'd check first
<AuroraBorealis> its been sitting at new for a while
<jelmer> AuroraBorealis: you'd need somebody with inventory delta experience for that
<AuroraBorealis> hmm
<AuroraBorealis> that i dont have
<jelmer> me neither..
<AuroraBorealis> k
<AuroraBorealis> i'll keep poking around
<AuroraBorealis> now, bed
<mgz> wow, launchpad marks up bundles emailed to mps, I've not seen that before
<mgz> preety.
<jam> AuroraBorealis: well, the change seems to indicate that 252test.pl is being added but the directory prog1/testcases doesn't exist.
<jam> You might try "bzr repair-workingtree" in case it is a local issue. Though it would be nice to save a snapshot of .bzr/checkout/dirstate
<jam> in case we can figure out what the difference is.
<mgz> might be good to put that in the bug jam as he's zzz
<jam> mgz: thanks for the heads up
<jam> done
<jam> mgz: so how are your first couple of days going?
<mgz> pretty well, the admin stuff hasn't killed me and I've had time to work on code :)
<mgz> jam: I think I need to run a few pyrexy things by you, shall I just put up a mp later or do you want to be bothered seperately?
<jam> mgz: I'm happy to give early feedback if you want it.
<jam> I know sometimes it can be hard to get traction on something.
<jam> We generally call it "a teddy bear" to talk to :)
<mgz> :D
<jam> mgz: You can just mention a branch, or you can put up an MP and comment that it may not be ready, and then poke me on IRC, or whatever works for you
<mgz> cool, I'll write a few things down
<jml> vila: hi
<jml> vila: would you please merge my lp:udd branch?
<vila> jml: sure
<jml> vila: thanks.
<vila> jml: sorry for the delay, I missed your reply :-/
<jml> vila: np.
<vila> jml: done, will be deployed later but I don't expect fallouts or will fix them
<jml> vila: what's the deployment schedule like?
<vila> sche.. what ? :-}
<jelmer> heh
<jml> vila: ah, ok.
<vila> mgz: thanks for the review on shelve-line-based, I replied, should we talk here to speed things up ?
<mgz> vila: perhaps, but I don't see much harm in just landing that
<mgz> especially if we can get benoit's change landed later which is a more complete solution
<vila> ha, important point, yeah, I could delay the tests waiting for his branch
<vila> that still leave the config option name, any suggestion ?
<mgz> I wouldn't worry about config.
<vila> I can't leave INSIDE_EMACS there, it's just wrong ;)
<mgz> just doing char-based if possible and line-based if not is enough
<vila> nope, would break on windows
<mgz> define a little function called _char_input or something with that logic
<mgz> _can_do_char_input
<mgz> then that at getch can be removed at the same time when the ui module takes over
<vila> still needs help from outside to tie the break about isatty()
 * mgz looks again
<vila> getchar() should not be attempted is isatty() is false, but that doesn't tell me which char/line should be used + I want line-based to work *even* (and especially if) isatty() is false (i.e. isatty() is relevant only if we want to try char-based
<mgz> I don't see why that can't be one logical statement
<mgz> if isatty() is false, or if magic emacs variable is set, or we're in tests, _can_do_char_input is false
<vila> right, so I want some env var or config option to cover both emacs and the test use cases
<vila> the emacs magic var doesn't work as there are ways (unusual but existing) to get char-based input under emacs
<mgz> use a config option if that's the easiest way for you, I just don't want it to be the kind of thing people need to be setting manually
<mgz> at least till it's an option that works for all bzr input rather than just the shelf command
<vila> err, but there is no way to switch to line based without setting it manually. That's the current bug, you can't use shelve when line-based is required and this can't be decided automatically >-/
<mgz> I thought that's what checking your magic emacs var did?
<vila> hmm, unless benoit's branch address that but I don't remember seeing a way to do that in his proposal
<vila> yes, it worked my limited env where I wanted to check the line-based stuff was working but... oh, I'm trying too hard ?
<vila> you mean *you* are ok with landing with INSIDE_EMACS ???
<mgz> yes, on the basis that a proper fix would be moving the logic to bzrlib.ui and that can happen later.
<spiv> vila: maybe sys.platform should be set to "emacs" :P
<vila> spiv: :)
<vila> mgz: ooookay ! Sorry, I'm dense, not enough sleep
<vila> mgz: can you say so and vote in the mp ?
<mgz> will do.
<vila> very much appreciated
<mgz> the isatty stuff if shelf_ui is already a hack so adding a little more isn't making life worse
 * vila nods
<vila> lunh time
<vila> c
<mgz> have a nice clunh
<AfC> Hm. I just tried
<AfC> $ bzr branch lp:ubuntu/maverick/linux
<AfC> and it didn't work.
<AfC> Am I missing something obvious?
<AfC> I mean, it says "linux" is the source package name...
<jelmer> AfC: odd, it says here there are no branches for the linux package
<jelmer> https://code.launchpad.net/ubuntu/+source/linux
<jelmer> http://package-import.ubuntu.com/status/linux.html#2011-04-22 01:24:13.263528
<AfC> jelmer: ok, thanks. Is there anything I can do about that?
<AfC> (right now I have `bzr branch lp:linux` running, not sure if that's what I actually want; I would have preferred a packaging branch if it existed)
<AfC> jelmer: that branch just completed, took real 101m36.019s
<jelmer> AfC, sorry, I think I missed that. which branch just completed?
<AfC> jelmer: lp:linux
<AfC> (just a data point)
<AfC> kernel.org is still down, so I can't immediately compare it to a git clone of Linux
<ccxCZ> it's now hosted at github
<briandealwis> Is there a way to override a config var from the command-line?  I'd like to use 'bzr pull -v' to show the log entries since the pull point, but use the line formatter.  I can set 'log_format=line' in my bazaar.conf, but that affects everything...
<vila> briandealwis: bug #491196 pending review, but the log_format config option is not migrated yet, on the other hand --log-format-line is recognized by pull IIRC
<ubot5> Launchpad bug 491196 in Bazaar "want a way to set configuration options from the command line" [High,In progress] https://launchpad.net/bugs/491196
<vila> grr --log-format=line
<vila> briandealwis: you're welcome to metoo the bug though ;)
<briandealwis> thx vila: it doesn't show in the help, so I assumed I couldn't do that
<vila> briandealwis: that's worth another bug ?
<briandealwis> vila: âlog-format=line doesn't work (with 2.5.0b1 at least)
<vila> wow, that's... bad, but you should be able to use '--line' even
<briandealwis> nor does --line
<vila> ha crap, I was looking at missing >-/
<vila> ctrl+alt+del
<briandealwis> I'll submit a bug
<vila> briandealwis: see bug mentioned above, this is a first step, it will also require migrating the --log-format option to adress your need
<vila> briandealwis: filing one with your specific use case sounds appropriate (-Olog-format=line for pull)
<briandealwis> ok
<mgz> can someone remind me what we do with news now if a change is landing on multiple release branches?
<vila> if you know the target ahead of times, file news in the oldest one and that's it
<vila> it's a bit less clear when you start landing on trunk but the goal is to avoid duplication
<vila> mgz: is that enough or do you want more details ?
<vila> oh, also at one point we stopped using NEWS and switch to doc/en/releases-notes/bzr-2.x.txt so one of the merge is confusing
<vila> because you suddenly get a lot of stuff merged in the wrong place, in that case remember to move each part in the specific release notes file
<mgz> cool, that should be okay then.
<vila> mgz: a bit confusing the first time but rest assured that it's still confusing after 20 or so occurrences ;)
<mgz> hm, 2.1 usec down from 2.7, not a bad side effect
<LeoNerd> What are you measuring that's that small?
<mgz> teeny function for encoding stat results as base64
<mgz> won't make anything run faster, but some overflow issues needed fixing
<mpt> Hi, on my first commit after upgrading to Ubuntu 11.10 beta I get "bzr: ERROR: Failed to GPG sign data with command "[u'gnome-gpg', '--clearsign']"" ... It looks like there's no gnome-gpg in 11.10. What should I be using instead?
<mpt> So it looks like I need to update gpg_signing_command ... I just need to figure out where, and to what
<mpt> ... ~/.bazaar/bazaar.conf is the answer to the first question
<mpt> ok, deleting the line altogether defaulted it back to asking for my passphrase at the terminal
<mpt> that's good enough for now I guess
<mpt> btw the "Configuration Settings" link is broken in <http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/configuring_bazaar.html>
<jblue> looking for suggestions on how to manage merging in many commits.. I'd like to inspect each commit, along with their commit comments, but not sure how to do this on the command line.  'bzr status -v' shows the pending merge tips, but I'm not sure how to do a diff for each tip
<briandealwis> jblue: see log -p
<jblue> 'bzr help log' doesn't say much about diffing pending merges
<bpierre> Hi
<poolie> hi jelmer, all
#bzr 2011-09-29
<AfC> What does
<AfC> AttributeError: 'Tree' object has no attribute 'encoding'
<AfC> mean?
<AfC> (doing bzr branch on a git repo)
<spiv> Sounds like some code is expecting one kind of object but encountering another
<spiv> Which could be due to a plugin needing to be updated to work with your version of bzrlib, or something like that.
<AfC> spiv: It's the Bazaar PPA, on a Lucid box & `apt-get install bzr-git`
<AfC> spiv: and, I suspect you're right, seeing as how this works on my Natty laptop.
<poolie> afc, spiv, hi
<AfC> (or at least, has worked for the use cases I have tried with small Git trees)
 * AfC bows to poolie
<poolie> !
<AfC> (don't get too excited now)
<poolie> please file a bug, with the traceback, against bzr-git, and post the number?
<AfC> [there's also a problem where bzr-git refuses to branch from a github https URL, but that's for another day]
<AfC> poolie: do you just want the dump to stderr, or the full commend run from .bzr.log?
<spiv> When in doubt, scream and shout^W^W^W er, I mean, give more information rather than less ;)
<AfC> poolie, spiv: as requested https://bugs.launchpad.net/bzr/+bug/861973
<ubot5> Ubuntu bug 861973 in Bazaar "bzr crashes when trying to branch a Git repo, with "AttributeError: 'Tree' object has no attribute 'encoding'"" [Undecided,New]
<poolie> thanks
<AfC> I hope it's just a dependency problem; this has really messed me up.
<poolie> it was working recently?
<AfC> poolie: as I noted in the bug and above, this workflow does work on my Natty system.
<AfC> [not, admittedly, with the large repo in question, but with other projects' locally cloned git repos]
<poolie> huh
<poolie> i can see how it would happen
<poolie> i think
<poolie> it got the hash of a tree when it expected a commit
<AfC> poolie: I can try and duplicate this on my laptop, but I'll need to get to a fatter pipe first.
<poolie> it might help if you can either attach or describe how to get the git branch that causes trouble
<AfC> poolie: that doesn't sound like a missing dependency, then
<AfC> poolie: oh, that's easy
<poolie> no i don' think it is
<poolie> it sounds like there is something in the structure of the repo it can't deal with
<poolie> normally an attributeerror is a version mismatch but i think not in this case
<AfC> poolie: git clone https://github.com/torvalds/linux.git linux
<AfC> poolie: bzr branch linux upstream
 * AfC just remembered he hadn't fetched the tags. I'll try that now
<AfC> same crash
<AfC> Like I said, on this Natty system, admittedly against smaller projects, I have git cloned then bzr branched many times.
<AfC> {shrug}
<AfC> Upgrading this server to Natty isn't really an option, y'know? :)
<poolie> well
<poolie> if you're using the ppa there should be no need to upgrade to natty
<AfC> poolie: (fwiw, this isn't makework; I really do need an import of the kernel tree)
<AfC> poolie: that's what I would have thought, yes
<poolie> i'll see if i can reproduce it on tip, at leaste
<poolie> you could usefully try bzr-git from https://launchpad.net/~bzr/+archive/daily?field.series_filter=lucid
<AfC> poolie: just bzr-git or change the whole PPA?
<AfC> [you guys have been pretty ruthless over the years about warning people off the dailies]
<poolie> hm
<poolie> how i would describe the dailies is:
<poolie> - don't be surprised if there are intermittent version incompatibilities, because they are just snapshots and they have had no time to settle against each other
<AfC> [the "what? plugins don't work together? gee, too bad, that's what releases are for"]
<poolie> - there is a somewhat higher chance of bugs
<poolie> but not much
<poolie> i think that's the main warning
<AfC> right, well in this case we're talking about plugins, which is why I prevaricate
<AfC> anyway, will try as requested
<AfC> is that ppa:bzr/daily then?
<poolie> yes
<poolie> the answer to the version incompatibilty thing is basically to just be prepared to downgrade to the betas
<poolie> iwnbni launchpad kept a little bit of history of ppa packages so that you could downgrade to an older daily
<poolie> but, not yet
<AfC> so, back to my original question, should I just grab the bzr-git .deb and dulwhich .deb from there?
<AfC> or upgrade bzr as well
<AfC> [whichever, I'm asking for your help so I will do either one as you request for diagnostics purposes]
<poolie> probably everything
<AfC> ok
<poolie> obviously you know there may be some fallout, but also that you can downgrade again
<AfC> kaboom :(
<AfC> same error
<AfC> well, I'm up against the bleeding edge incase you [can] fix something; otoh, if it's a missing dep then we can try that quicky too, in both scenarios
<poolie> ok, that's useful to know at least
 * AfC swears quietly
<AfC> poolie: oh,
<poolie> ?
<AfC> [oh, I just discovered I wasn't logging here[
<AfC> Jelmer discovered that the packaging branches of linux were missing
<AfC> fyi
<AfC> (they would have been useful, and, indeed, import-tar was my next fallback, but if your imports are breaking then I have a bad feeling mine won't work either)
<AfC> here we are,
<AfC> poolie: https://code.launchpad.net/ubuntu/+source/linux and http://package-import.ubuntu.com/status/linux.html#2011-04-22 01:24:13.263528
<AfC> hm
<AfC> second is <http://package-import.ubuntu.com/status/linux.html#2011-04-22%2001:24:13.263528>
<AfC> that
<poolie> hm that looks like a different probelm
<poolie> one possibly fixed by retrying it
<AfC> poolie: ok, (but, meanwhile, there are no packaging branches for Linux there; is that expected?)
<poolie> oh there is a bug https://bugs.launchpad.net/udd/+bug/792193
<ubot5> Ubuntu bug 792193 in Ubuntu Distributed Development "'linux' import fails due to deleted librarian file (orig.tar.gz) in .dsc for 2.6.24-5.9 in hardy" [Low,Confirmed]
<poolie> well, it's known
<AfC> Hardy?
<AfC> hm. I was trying to find Maverick's packaging branches. Anyway.
<poolie> so
<poolie> i'm still waiting for that to download
<poolie> if you run 'BZR_PDB=1 bzr branch ...'
<poolie> and then you should get a debugger prompt; please type 'p locals()'
<AfC> ok
<AfC> poolie: :
<AfC> {'rev': <Revision id git-v1:c39ae07f393806ccf406ef966e9a15afc43cc36a>, 'self': <bzrlib.plugins.git.mapping.BzrGitMappingv1 object at 0x1699450>, 'commit': <Tree c39ae07f393806ccf406ef966e9a15afc43cc36a>, 'decode_using_encoding': <function decode_using_encoding at 0x33167d0>, 'lookup_parent_revid': <bound method type.revision_id_foreign_to_bzr of <class 'bzrlib.plugins.git.mapping.BzrGitMappingv1'>>}
<poolie> ok that's useful
<AfC> gesundheit
<poolie> and try 'up' 'p locals()' again
<AfC> ok
<AfC> > /usr/lib/python2.6/dist-packages/bzrlib/plugins/git/repository.py(332)lookup_foreign_revision_id()
<AfC> -> mapping.revision_id_foreign_to_bzr)
<AfC> {'foreign_revid': '5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c', 'commit': <Tree c39ae07f393806ccf406ef966e9a15afc43cc36a>, 'self': LocalGitRepository('file:///home/andrew/torvalds/linux/'), 'mapping': <bzrlib.plugins.git.mapping.BzrGitMappingv1 object at 0x1699450>}
<AfC> [linux clone from github took 15m01s so you should be able to dup all this hopefully soon]
<AfC> Always disappointing to read in a bug "Low priority because no one is ever going to use this so we don't really ever need to fix it" :(
<poolie> which one?
<AfC> https://bugs.launchpad.net/udd/+bug/792193/comments/17
<ubot5> Ubuntu bug 792193 in Ubuntu Distributed Development "'linux' import fails due to deleted librarian file (orig.tar.gz) in .dsc for 2.6.24-5.9 in hardy" [Low,Confirmed]
<AfC> (the one you found 5 minutes ago)
<AfC> My actual objective is to get a 2.6.35 kernel into bzr; Maverick shipped a 2.6.35 so that's what I was aiming at packaging wise. And meanwhile at Oneiric https://code.launchpad.net/ubuntu/+source/linux is still empty.
<poolie> that would be nice
<poolie> ok so i can reproduce the crash
<poolie> which is a good start
<AfC> great!
<AfC> poolie: you on Lucid or Natty?
<poolie> pah, oneiric
<AfC> ok
<poolie> :)
<AfC> that means its not a Lucid problem, as such, but more likely a Bazaar problem, yeah?
<poolie> i'm 80% sure it's a quirk in the linux.git history that bzr-git is not coping with
<AfC> yeah
<poolie> such as perhaps a tag pointing directly to a tree, not to a commit
<AfC> that wouldn't surprise me
<AfC> Not withstanding the whole "no one will ever use this vibe", (and as I said this isn't makework), it might be worth tracking down if for no other reason that we all know the Linux tree is kinda the canonical reference case for the "Git being better than Bazaar" bullshit
<AfC> poolie: I have to relocate ... be back on in ~an hour. Ok if I ping you then? [or, I should just watch that bug?]
<poolie> just watch it
<poolie> jelmer can probably solve it much faster than me but i'll have a go
<AfC> sweet
<AfC> you guys rockl
<poolie> :) thanks i hope we can get it unstuck
<poolie> it may be fairly shallow
<AfC> Hope s
<AfC> o. I realize it may take a bit more than trivial engineering if it is some relation that Git allows that Bazaar doesn't yet model.
<poolie> afc, it was indeed a quirky tag; deleting it lets the import proceed
<poolie> i'm going to see if jelmer agrees with my approach
<AfC> poolie: huh. Is that a condition you can anticipate (or, rather, when you hit that glitch in the future you can just programmatically skip past it?)
<poolie> yep
<poolie> i just want to know what j thinks about just how we will skip past it
<poolie> i put a workaround on the bug
<vila> hi all !
<jelmer> hi vila
<jelmer> AfC: hi
<vila> jelmer: hey !
<AfC> jelmer: yo
<AfC> jelmer: Hit a funny bug in an unavoidably prominent tree I was trying to parse with bzr-git
<jelmer> AfC: I'm just reading the bug report now
<AfC> jelmer: if you need | want to reproduce, I can give you the git URL
<AfC> jelmer: (also, bzr-git choking when given a github https URL, *is* fixed by the daily PPA, nicely done)
<jelmer> AfC: thanks
<jelmer> AfC: let me see if I can reproduce it manually first though\
<AfC> â city
<vila> today's hang is on gentoo :-/
<jam> morning all
<ccxCZ> good morning
<ccxCZ> vila: what's the issue with gentoo?
<vila> ccxCZ: there is hang in the test suite spuriously affecting various babune slaves, it's the gentoo one today, it was natty and maverick yesterday, I don't think it's specific to gentoo
<jam> vila: I haven't been able to reproduce locally, is it possible to give me access so I can try it on the slaves themselves?
<ccxCZ> I see. Anyway if you need some gentoo magic feel free to poke me.
<jam> and have you tried running older versions to make sure that it is a change in *bzr* and not something else causing the problems?
<vila> jam: you already have access via babune
<jam> vila: except you never restored my account there
<vila> the important bit above is "via babune*
<jam> vila: I mean having me manually run "bzr selftest"
<vila> you never had access to slaves
<jam> vila: babune is not giving us enough insight into what is failing
<jam> I was hoping to directly run selftest so that I could see a failing test, etc.
<vila> jam: and you probably won't be able to reproduce outside of babune
<poolie> hi jam, vila
<jam> hi poolie
<jam> vila: I thought you said that the schroots were failing, but the vms were not, did I misunderstand?
<jam> Is it just purely random?
<vila> it is random
<vila> I saw one case where for the same revision the chroot hung but the vm passed
<jam> vila: I saw this: http://paste.ubuntu.com/698934/
<jam> in the failing babune run of gentoo
<poolie> vila, thanks for spotting that bug in my update patch
<poolie> it now works from a subdir
<jam> I wonder if -Werror is causing a thread to die
<jam> because of a Warning from gzip
<poolie> do you want to rereview it or should i just send it?
<jam> causing something to hang.
<jam> (note, that is the only line in the raw console output that looks at all different from the rest.)
<jam> vila: and *that* would certainly be random, if it requires a gzip stream to somehow create a value that wasn't signed/unsigned etc.
<jam> that one, in particular, looks to be line 21 of gzip.py, part of "write32u"
<jam> and has the comment:     # The L format writes the bit pattern correctly whether signed
<jam>     # or unsigned.
<vila> poolie: you're welcome :)
<vila> poolie: oh, please go ahead
<vila> jam: may be, but it there has been no hang on gentoo for .... months, so pretty unlikely
<vila> s/it//
<vila> and the gentoo job currently running (and hung) is already a re-try, so could also be a different test split that is revealing another issue
<jelmer> 'morning jam, poolie
<poolie> hi jelmer, can you help me with bug 816973?
<ubot5> Error: Launchpad bug 816973 could not be found
<JackWinter> i want to checkout the source from a prj on sourceforge using bazaar.  the url i'm given is: bzr://dxx-rebirth.bzr.sourceforge.net/bzrroot/dxx-rebirth (read only), tried bzr init, and then bzr banch/checkout, but it tells me that bzr: ERROR: Not a branch: "bzr://dxx-rebirth.bzr.sourceforge.net/bzrroot/dxx-rebirth/".
<jelmer> poolie: looking now
<jam> vila: well, I do see the gzip warning, I'll go check if it exists in a non hanging run
<jam> interestingly, the passing test has the hanging message on a line by itself, while the failing one has it intermixed
<jam> I don't know if that is significant or not, I'm trying to diff the raw logs now
<poolie> jelmer, https://bugs.launchpad.net/bzr-git/+bug/861973
<jam> not very helpful, as the --parallel means the ordering is ~locally random
<ubot5> Ubuntu bug 861973 in Bazaar Git Plugin "bzr crashes when trying to branch a Git repo, with "AttributeError: 'Tree' object has no attribute 'encoding'"" [High,In progress]
<vila> ccxCZ: since you asked :) There is a weird failure documented in #830545
<jam> bug #830545
<ubot5> Launchpad bug 830545 in bzr-buildbot-net "Update for Gentoo testing routines" [High,In progress] https://launchpad.net/bugs/830545
<vila> jam: thanks :)
<jam> vila: something pretty weird. The failing test seems to be missing every 6th test or so.
<jam> vila: across the test suite. Would one of the subprocesses have hung/died early, causing all of its partition of the tests to get discarded?
<vila> jam: BZR_CONCURRENCY=6 on gentoo's slave
<jam> I'm not particularly familiar with how --parallel=? is splitting stuff out
<vila> possibly
<lifeless> jam: round robin split for bzr, equal-time-buckets for testr
<vila> jam: the last change here is spiv spreading the tests across the subprocess instead of giving a slice of the whole
<lifeless> (with round robin for unknown time tests)
<jam> vila: http://imagebin.org/176688
<lifeless> vila: oh? I'm out of date then :)
<jam> vila: that is after 'sort' ing the output
<jam> of the raw log
<jam> that is gentoo run 520 vs 522
<vila> lifeless: no, not at all
<vila> lifeless: but testr is not used there
<JackWinter> oops out of swap :( but figured it out.  had to use bzr://dxx-rebirth.bzr.sourceforge.net/bzrroot/dxx-rebirth/d2x-rebirth
<vila> jam: yup, sounds like more evidence there is a hang in one subprocess while the others work normally
<vila> the '----' line is weird though
<jam> vila: that is Vim
<jam> it is just saying "no content on left"
<vila> oh, not from selftest then, ok
<vila> jam: note that the 1/6 may be just caused by a test taking longer
<vila> but of course a hung test takes forever
<ccxCZ> vila: you mean the pyc stuff? is there a log for that somewhere>
<jam> vila: how so? I sorted all tests, and then did th ediff
<jam> so those tests are *not in the output*
<jam> I went back and then searched the sorted log for the first tests that are missing
<jam> http://paste.ubuntu.com/698951/
<vila> haaa
<vila> well, just saying. You didn't explain your pastebin so I guessed (wrongly ;)
<vila> what is this one about ?
<jam> vila: so, first, I grabbed the raw console output from a success and a fail
<vila> jam: ohh, re-reading the log you mentioned it ws sorted, I missed that
<jam> then I sorted them, and did a diff
<jam> finding ones that are in success
<jam> then I iterated success in its original order
<jam> and found ones that were marked missing in the hung test
<jam> tests
<jam> those are the first 10
<vila> so the hanging one should be before ?
<ccxCZ> found the log, not sure what make of it though, never had issues with .pyc not loading
<jam> vila: arguably, the first one should be the hung one, right?
<jam> vila: ah, wait a sec
<vila> hmm, the first or the preceeding one... you may be right...
<jam> +bzrlib.tests.test_bundle.V4BundleTester.test_non_bundle ... /usr/lib/python2.6/gzip.py:21: DeprecationWarning: struct integer overflow masking is deprecated
<jam> is the only interesting line in hung that isn't in success, except that is just because of the warning
<vila> ccxCZ: ha, you neither, damn
<jam> there is an "ok" still in the output for it.
<jam> I'm guessing that is just noise.
<vila> jam: I'm pretty sure the ok is output after the cleanups, mgz ?
<jam> vila: the other thing that is missing in the output is the Cython lines
<vila> whic cython lines ? WHile compiling the extensions ?
<jam> vila: The 'diff' was just confused because the 'ok' ended up on a different line.
<vila> jam: I'm confused as well about what fallouts this implies :)
<ccxCZ> vila: you sure this is gentoo specific? do you have other slaves with same version of python?
<jam> vila: this is the complete list of sorted-but-missing lines: http://paste.ubuntu.com/698953/
<jam> if you go to the end
<jam> there are Cython lines
<jam> Now, Cython only ~recently started writing "skipping XXX (up-to-date)"
<jam> but something about hung isn't showing those lines.
<vila> ccxCZ: which python version is that ? (I'm pretty sure we cover the whole range but I can't remember the specific one used on gentoo)
<ccxCZ> and the first error seems to be related to pyc loading rather not loading
<ccxCZ> vila: depends
<vila> :)
<vila> ok, let me check
<jam> vila: ah, they show up at the end of the success log
<jam> maybe because it is to stderr?
<ccxCZ> it's rolling release, y'know :-)
<vila> ccxCZ: yeah, I wsa hoping you spotted it when looking
<jam> vila: all the way at the *end* of http://babune.ladeuil.net:24842/job/selftest-gentoo/520/consoleText
<jam> It says "python setup.py build_ext -i"
<jam> shouldn't that be happening before the test run?
<vila> jam: depends :-}
<ccxCZ> 2.6 something
<vila> but extensions are re-compiled only when needed relying on make
<jam> vila: sure, but compiling them after running the test suite seems odd
<vila> ccxCZ: covered then, at least by lucid and maverick
<jam> is it just a Jenkins-ism that it puts stderr after stdout ?
<vila> jam: no, no
<ccxCZ> you might want to consider having testing gentoo slave along stable one btw, quite a few people use that
<vila> jam: there are various cases where the ouput appears in a weird order, but basically all jobs do: make; bzr selftest
<vila> ccxCZ: lack of resources :-/ And I minimally understand admin'ing gentoo so I try to use something is close to the "default" install (understanding that's pretty arbitrary for gentoo)
<vila> s//that is close/
<ccxCZ> really hard to tell error just from the exception
<vila> ccxCZ: what could help ?
<ccxCZ> well, first I'd have to understand what the tests actually do :-)
<ccxCZ> but something along of strace might help
<mgz> morning all
<vila> ccxCZ: these tests checks that we import the plugin from the right place either from the .py or .pyc depending on the test
<vila> ccxCZ: the test plugin code is generated on the fly by the test itself
<ccxCZ> about the resources, I recently bought phenom x6 machine for a server, so I probably can spare some cpu time
<vila> ccxCZ: last time I looked I was wondering if there was some python compile trick on gentoo can be different during the ebuilds
<vila> ccxCZ: things like right access or putting the compiled files in a different place, things like that
<vila> ccxCZ: interesting, would you be interested in setting up a slave ? (Not especially complex but requiring some ssh setup with dedicated keys mostly)
<vila> ccxCZ: you'll keep full control about opening hours of course ;)
<ccxCZ> I have vserver set up there, so I can create one or two dedicated systems for it easilly
<ccxCZ> lets see, I'll look into python's ebuild if I see something out of ordinary, but I don't think there's some gentoo-specific thing
<vila> ccxCZ: the unusual thing I can see there is that we use a specific import hook and there may be a bug there (but it works everywhere else)
<ccxCZ> it does make sure that it uses system version of expat, libffi and zlib instead of the bundled ones, but I doubt that's related
<vila> ccxCZ: yeah, doubtless
<vila> on the other hand if this is achieved by sys.path trickery...
<ccxCZ> there are some patches, btw did you enable tests when compiling python?
<ccxCZ> nope, it just rm -rf the relevant directories in python sources
<vila> ccxCZ: that went way above my gentoo knowledge, how is that achieved ?
<ccxCZ> FEATURES=test
<ccxCZ> also adding PORT_LOGDIR="/var/log/portage" into make.conf would provide you complete build logs, containing list of patches applied
<ccxCZ> seems the only patches there are related to crosscompiling
<vila> ccxCZ: FEATURES=test in /etc/make.conf ?
<ccxCZ> yup, add it to other features if it's defined already (whitespace delimited list)
<ccxCZ> man make.conf for details
<vila> nope, no features there: http://paste.ubuntu.com/698963/
<ccxCZ> then just add it, here's mine for reference http://codepad.org/XdRh5So7
<vila> 8-)
<vila> ccxCZ: done
<ccxCZ> just fyi, there are four variants how software can be built on gentoo: as root or portage user and with or without sandbox
<ccxCZ> these are controlled by userpriv sandbox and usersandbox features respectively
<ccxCZ> now that you added logging feature and tests you may reemerge python so we can inspect the build log closely
<vila> I think I use root/no sandbox
<vila> just 'emerge python' then ?
<ccxCZ> yup. but I doubt anyting would come from that. what would be interesting is look at the strace of the test run for particular test on gentoo and on platform where it succeeds
<ccxCZ> you can run emerge --info to see how are features set
<ccxCZ> I think sandbox is enabled by default
<vila> ouch, will be noisy
<ccxCZ> can we run particular tests only>
<ccxCZ> ?
<vila> yes, but even running a single will load a bunch of stuff
<ccxCZ> we can grep for the output then
<vila> emerge running
<ccxCZ> that will take while, especially when tests are enabled
<vila> the tests are running
<vila> hmm
<vila> http://paste.ubuntu.com/698974/ but sounds unrelated
<ccxCZ> oi, you seem to be merging python-3.1, that's probably not what we want
<vila> eeerk, what's up there ?
<ccxCZ> I usually disable that one globally so I forgot to tell you to use version specifier
<ccxCZ> ctrl-c that one
<vila> done
<ccxCZ> do you want py3k on that system? if not it's probably best to mask it
<vila> no
<vila> how ?
<ccxCZ> echo '>=dev-lang/python-3' >>/etc/portage/package.mask
<ccxCZ> now you can emerge -av python
<ccxCZ> it's --ask --verbose, so you see what's portage up to
<vila> ccxCZ: sry, had to change kbd batteries :-}
<ccxCZ> okay, what would we benefit from would be logging listdir before test_plugins.py:906
<vila> ccxCZ: ok, i propose 2.7.1-r1
<vila> err, portage proposes
<vila> I'd rather stay with 2.6 unless most gentoo users use 2.7 ?
<ccxCZ> I assume 2.7 is stable now then. I myself use testing systems practically everywhere
<vila> ok, i'll update it later then, let's not change too many things at once
<ccxCZ> yup, 2.7 is now stable on all architectures http://packages.gentoo.org/package/dev-lang/python
<ccxCZ> for now you can do emerge -av '<python-2.7'
<vila> with s/-3/-2.7/ emerge proposes 2.6.6-r2, sounds fine for now
<vila> ok, running
<vila> http://paste.ubuntu.com/698978/
<Merwin> Hi guys. I just used merge to get some branch into mine, did a few modifs and commited.
<ccxCZ> okay I guess I missed some patches that were hidden in eclass
<Merwin> I would liek to generate a patch of my modifs, not of the merge !
<Merwin> How can I do this ?
<ccxCZ> bzr log -n 0 will get you the revno of the last commit before the merge (something like 80.1.1 or so)
<ccxCZ> you can diff against that
<Merwin> Thanks ccxCZ :)
<vila> so, it looks like jenkins hide the aborted jobs when it's restarted
<vila> which I did quite often lately.
<vila> mgz: by the way, regarding the windows slave, it uses the same versions of testtools. subunit BUT it uses --parallel=subprocess instead of --parallel=fork
<vila> mgz: so the leaks may come from that ?
<mgz> qua leaks?
<vila> mgz: sorry, the apparent leaks in the output
<mgz> link? I'm not sure which problem you're referring too
<mgz> -o
<vila> http://babune.ladeuil.net:24842/view/%20High/job/selftest-windows/lastFailedBuild/console
<vila> scary, did anybody ever heard a tickling sounds when recharging a battery (coming from the battery itself)
<mgz> the little man is trying to get out
<ccxCZ> so as I was saying, could you look at test_plugins.py:906 and add listdir() there?
<ccxCZ> not sure what convention for logging you have there
<vila> ouchy the noise is related to some bubbles on the + end 8-)
<vila> ccxCZ: not easy, the ebuild is controlling which sources is used
<vila> ccxCZ: is there a way to tell it to use  apply a patch ?
<ccxCZ> hmm, is there way to run testcase on bzrilb I just just fetched from bzr?
<mgz> ah, that's a bit of a mess at the end there
<ccxCZ> I meant tests in bzrlib
<mgz> possibly fixing the tilde issue will help there too?
<ccxCZ> I wouldn't concern myself with python further
<vila> ccxCZ: ./bzr selftest -s bt.test_plugin.<TestClass>.<TestName>
<vila> mgz: I wasn't referring to the failures but to the noise in the output
<ccxCZ> vila: gee the failing test runs fine on my machine
<vila> which looks like subunit stuff that is not supposed to end up here
<vila> ccxCZ: yeah :) That's the trouble, it failed "reliably" there ;)
<poolie> jelmer, ok, i see, http://bazaar.launchpad.net/~bzr-git/bzr-git/trunk/revision/1403 is more or less what i had in mind
<poolie> glad i was on the right track
<ccxCZ> probably try upgrading python to 2.7 then, you'll need to emerge app-admin/python-updater that will rebuild any modules you might have after the upgrade
<mgz> ugh, that wasn't fun to reproduce, this commit message encoding stuff is a mess
<mgz> Riddell: quick question, in bzr-builddeb debian_changelog_commit calls debian_changelog_commit_message twice, is there a particular reason for that?
<mgz> or could the first return be reused?
<jelmer> vila: hi
<vila> oh my 14:30 already !
<Riddell> mgz: I think that could be reused
<mgz> thanks, I'll do that and see if anything breaks
<jam> vila: well, I've managed to trigger a hang. Using my branch: bzr selftest -s bt.per_interrepository.test_fetch -v "g_boundary_smart_old.InterDifferingSerializer,.*2a"
<jam> It isn't guaranteed, but it does happen
<jam> oddly, with bzr.dev I haven't triggered it yet.
<jam> It is a slow test to start with, so I'll poke at it further.
<vila> jam: otp but \o/
<mgz> jam: when you have a spare five mins, could you cast an eye over the prereq mp that moves the pack_stat code around?
<mgz> then I could land those branches
<jam> mgz: Actually, I think I did and meant to approve it, checking
<mgz> vila: or, I guess anyone, is there a test trick for doing something better than `run_bzr([...], stdin="y\n")`?
<mgz> we don't have -y options
<jam> mgz: I didn't see a test suite update
<jam> for the move_pack_stat change
<mgz> jam: right, that branch doesn't change the tests, it just moves code (and relies on the existing end-to-end testing)
<mgz> the subsequent branch adds direct unit test coverage for the function
<jam> mgz: approved
<mgz> thanks!
<mgz> ...I wonder if pqm will let me at 2.4 these days...
<Riddell> I had to ask a sysadmin nicely
<vila> mgz: better trick ? I think I lack context..
<vila> you mean you're forced to use a blackbox test ?
<mgz> yeah, the code that needs testing relates to cmd_commit
<mgz> ...I might be able to get around this another way
<vila> ha, you'd like to create to be able to use a cmd_commit object ?
<vila> meh
<vila> ha, you'd like to be able to use a cmd_commit object ?
<mgz> I think I can just avoid the prompt, provided the test passes
<mgz> ack, wrong button
<vila> hmm, better make sure you don't have a prompt if the test fails though :)
<mgz> okay, 2.4 branch submitted to pqm, when if fails I'll find someone to beg as Riddell suggested
<vila> mgz: I can do that unless you want to keep it as a test when admins ask for one
<Riddell> is there a hook that would be run after a bzr branch command?   I don't seem to find one
<GRiD> hey, can someone tell me what the B+Tree graph indexes are mainly used for now?
<mgz> Riddell: post_branch_init maybe? but briandealwis posted about some hook shortcomings in the tiplog thread on list
<mgz> hey looks like the sysadmins deserve more credit, pqm seems to be letting me land on 2.4
<mgz> also, interesting, some tests seem not to be cleaning up after themselves very well even there: <http://pastebin.ubuntu.com/699125>
<vila> mgz: yup, a handful
<vila> I lost steam to track them at one point :/
<vila> mgz: also, I think there are cases were bzr doesn't delete some tmp file so it's not the test "fault"
<jam> vila: well, it looks like the test is actually exposing some brittle code. We send a request that the server doesn't understand, see that it rejects it, and then don't reconnect, but just keep sending the next request.
<jam> I *think* it means we can get out of sync
<jam> So the next request fails, because it gets into the pipeline.
<vila> urgh, yeah, that can easily hang
<jam> vila: test case traceback: http://paste.ubuntu.com/699160/
<jam> anyway, I might be provoking it more now because of the timeout loop
<jam> maybe we're doing an extra read on the socket or something.
<jam> I need to probe deeper
<jam> ah, I have an idea.
<jam> the old read would have returned the empty string?
<jam> maybe not
<jam> anyway, I can trigger a hang on demand by putting a "import pdb; pdb.set_trace()" in the code
<jam> which gets them more out of sync
<jam> I think
<jam> (I manually 'continue' every pdb trigger, but it still causes a hang)
<mgz> ha, I have a cunning plan
<mgz> if I can become a member of ~canonical-bazaar, that gets me in ~launchpad, which gets me in ~launchpadlib-developers, which means I can at long last land the fix I did months ago
<mgz> and make my todo queue more reasonable
<jml> vila: what python is available for production udd?
<jam> mgz: you should get added to ~canonical-bazaar, email poolie for it. However, you should really poke the launchpad folks if something of yours isn't getting landed.
<jml> vila: (can I use argparse?)
<jam> jml: python says 2.6.4
<jam> sorry 2.6.5
<jml> jam: thanks.
<jam> I'm pretty sure it is ~stock lucid
<vila> jml: 2.6.5
<vila> jml: and your fix has been deployed ;)
<vila> well, fix, your mp I mean
<jml> vila: yay :)
<jam> jml: 'import argparse' says no-such-module
<jam> I'm pretty sure that's py2.7
<jml> yeah, it's a 2.7 thing.
<vila> oh, did I mention the importer has been happily making tea this morning ?
<jml> pity
<jml> vila: that's pretty awesome
<jam> vila: as in a good thing or bad thing?
<vila> Pretty good, no spike of spurious failures
 * jml mumbles something about bzr's awesome cli being more re-usable
<mgz> jam: suggest to me a pokee, there's no need to bug robert again
<jam> vila: I wasn't sure if there was downtime that udd was happily making tea for, or if udd decided that it really needed to drink gallons of tea even though launchpad was working :)
<vila> there was still a minor bug that we didn't get as many log messages as I planned, but I have evidence that 2 import failures were seen as lp down, retried and succeeded later
<jam> mgz: Well, poke on the mp, or go to #launchpad-dev and poke whoever is the on-call-reviewer
<jam> vila: sounds good, as long as LP really was down then :)
<vila> hehe, no, in this case only 2 transient failures, tomorrow may be more interesting
<jam> ah, so it wasn't down, but we still got transient failures
<jam> interesting.
<vila> jam: well, the thing is, according to wgrant, it wasn't :)
<jam> though maybe just a load thing?
<jam> in which case, backing off is reasonable to do anyway
<vila> on the lp side yeah
<vila> exactly !
<jam> let's hammer LP when it is having load problems responding to our requests
<vila> which is why I consider it a small success but wait for a bigger down time to confirm
<jam> vila: interestingly, it isn't the 'select.select()' line that causes the failure, it is the 'if self.finished: return None' line
<jam> it seems that the race is that we've told the service to shut down before we've sent it more data, or something to that effect.
<jam> anyway, I'll poke more tomorrow.
<vila> jam: oneiric seems to be hung :-}
<jam> vila: from what I can tell, it looks like something is stopping the service, and leaving bytes on the socket, which then gets re-used for some reason.
<jam> so sure, random failures
<vila> yeah, 28min instead of the usual 3 or 4, definitely hung
<jam> anyway, EOD, might be around late tonight.
<vila> ok
<vila> Riddell: does http://babune.ladeuil.net:24842/view/Gentoo/job/selftest-gentoo-ebuild/48/console rungs a bell ?
<vila> rings
<vila> bah, silly me, what's that encoding ???
<vila> don't tell me ascii :) The question was: why the hell is it not utf-8 there ? ;)
<vila> Riddell: but for you the question was: have you seen such failures before ?
<Riddell> vila: hmm, well it's a recent test I added
<Riddell> and it works on ubuntu but I suppose the launchpad plugin might be disabled on gentoo
<vila> no
<vila> well, not as far as I know
<vila> Riddell: Can reproduce the failure while running with --no-plugins ?
<vila> grr can *you* ?
<Riddell> let me see
<vila> hmm, the question will then be how can we check that a plugin is available... a simple bzrlib.plugins.launchpad check in sys.modules ?
<vila> Riddell: anyway, it's probably worth fixing it
<jml> what does list_packages achieve?
<jml> At first I thought it was a utility, but I discovered that it's in the crontab
<jml> (Also, what's the right ML for discussing changes like putting config in another branch?)
<vila> jml: we rely on bzr for the config stuff so bzr ml may be appropriate for that, otherwise unbutu-distributed-devel is
<jml> vila: ok. thanks.
<jml> and list_packages?
<vila> oh sorry
<vila> jml: but finishing on config first,
<jml> vila: oh ok, go right ahead
<vila> jml: any option defined in pkgimport.conf can be overridden from locations.conf
<jml> (my laptop is about to shut down due to low battery, but I'll log the conversation anyway)
<vila> jml: so that may help you (or not if you want to track your config in  a branch)
<vila> jml: IIRC, (but james_w can confirm/deny), list_packages is used to make sure we import new packages
<achiang> does bzr have an animal mascot?
<achiang> because i think you should: http://www.herbweb.org/animals-collective-nouns.html
<achiang> "A bazaar of guillemots"
<mgz> ehehe
<achiang> http://en.wikipedia.org/wiki/File:ThickbilledMurre23.jpg
<achiang> http://2.bp.blogspot.com/__q53AR1ORfo/TCe-j2n9lOI/AAAAAAAAHt4/LbwUfJxS-u4/s1600/Common+Guillemots.+25+Jun+10.JPG
<achiang> shall i file a bug? ;)
<mgz> "bzr needs more auks"
<jml> ok.
<vila> jml: as in: the script update the package table and mass_import use it (see AllQueue)
<jml> vila: oh, I thought that add_import_packages did that
<vila> jml: a bit hackish but enough for us and for now (you're lucky I put the crontab in the branch though :)
<vila> jml: inst't add_import_packages adding jobs instead ?
<jml> vila: hmm, yes, but it doesn't need list_packages in order to do that, does it?
<vila> jml: no, AllQueue quiry both tables
<vila> jml: don't ask me why :) I arrive too late in the game and never asked (yet) :)
<jml> vila: ok. thanks.
<vila> jml: I kind of feel the features could be made part of mass_import though
<vila> achiang: make a proposal to the mailing list :)
<jml> vila: yeah.
<jml> scripts shouldn't have code in them :\
<jml> nor underscores in the names, neither
<jml> honestly, young people these days
<jml> they should get off my lawn and turn down their music
<bob921> Can I automatically undo the changes that a revision made? I'm at revno=53, and I want to undo the effects of revno=47
<bob921> Answer to my question: go to directory where file was changed. bzr diff -r48..49 | patch -R
<jelmer> bzr merge -r49..48 should also work
<poolie> good morning
<Noldorin> jelmer, hey
<Noldorin> you around?
#bzr 2011-09-30
<spiv> vila, jam, lifeless: IIRC my change to --parallel was to make it allocate by round-robin
<poolie> hi spiv
<AfC> I'm curious what might be done to help bzr take advantage of multi-core systems.
<AfC> I guess Python is a serious roadblock in here :/
<Peng> Does bzr even doing anything very parallelizable?
<Peng> Other than the test suite? :P
<AuroraBorealis_> what needs to be
<AuroraBorealis_> paralleized
<AuroraBorealis_> honestly
 * AfC is watching a bzr process at "fetching revisions 1566/264178" at about 20 per second on one core, and watching three other cores of this server idle.
<AfC> Gonna be a while, this one.
<AuroraBorealis_> thats probably because
<AuroraBorealis_> its limited by your download speed
<AfC> AuroraBorealis_: its local
<AuroraBorealis_> not because its single threaded.
<Peng> AfC: And how exactly would you multithread that?
<AfC> The system is not in iowait at all.
<AuroraBorealis_> ive copied the bazaar source code which is like 37000 revisions
<AuroraBorealis_> in seconds...
<AfC> It's a quad Xeon. It's not a slow system. Anyway
<AfC> Peng: that is, of course, a fascinating question
<AfC> Peng: I don't know how much the Python runtime is an obstacle here.
<AfC> Peng: but, on e.g. import loads, mapping any one revision would conceivably be independent of mapping any other revision.
<AuroraBorealis_> python probably is not the obstacle
<AfC> I imagine at some point there is the whole "sequence adjacent revision texts" thing
<AuroraBorealis_> branching the bazaar source code which is at 38,000 revisions took less than a minute
<AuroraBorealis_> i feel thats acceptable
<bob2> shared or non-shared repo?
<AfC> AuroraBorealis_: if it's CPU bound, then yes, the Python runtime's global locks will be an obstacle (if threading is the approach one uses to parallelism).
<AfC> 6000 down. Only 258 thousand to go.
<bob2> welll, if it's cpu-bound /and/ parallelisable :)
<AfC> bob2: heh
<AuroraBorealis_> dunno why its taking so long for you.
<AuroraBorealis_> what are you branching
<AfC> Linux
<bob2> it's 10x as many revs as bzr
<bob2> AuroraBorealis_, one minute to branch into a new unshared repository?
<AuroraBorealis_> wait
<AuroraBorealis_> i have it locally
<AuroraBorealis_> so yes
<AuroraBorealis_> well i didnt put it into a repo
<AuroraBorealis_> and where are you getting linux in a bazaar repo
<AuroraBorealis_> it uses git
<bob2> lots of people import lots of things
<AuroraBorealis_> i mean going from git->bzr sounds like it could take a while
<AfC> Interesting data points: getting the kernel from github was 15 minutes. Getting the vcs-import on Launchpad was 1 hour 20 min. I'm assuming that was lp's net I/O fault, but we'll see later today.
<bob2> barely relatedly, 1:04 to git clone linux-2.6 with cold cache, 40s with warm
<AfC> bob2: that is interesting, thanks
<bob2> lp to au is tedious :/
<AfC> bob2: yeah. I'm getting tired of hearing all the reasons why Launchpad can't mirror content.
<AuroraBorealis_> sounds like a problem with lp rather then bazaar :>
<AfC> Just hit the repack at 10k revisions. That was exciting.
<AuroraBorealis_> whats the link to clone the kernel
<AuroraBorealis_> kernel.org is...down
<AfC> AuroraBorealis_: here
<AfC> $ git clone https://github.com/torvalds/linux.git linux
<AfC> AuroraBorealis_: then, see https://bugs.launchpad.net/bzr-git/+bug/861973 as you'll hit a bug when you try to bzr branch from the local copy
<ubot5> Ubuntu bug 861973 in Bazaar Git Plugin "crashes when cloning local git repository with tags pointing at Tree objects" [High,Fix committed]
<AuroraBorealis_> of course the git gui sucks
<AfC> [the local copy being necessary since currently released bzr-git crashes when talking to github. THAT is fixed in the ppa:bzr/daily (yeay) though this bug's fix isn't there yet]
<AuroraBorealis_> again, going through bzr->git seems like some problems...
<AuroraBorealis_> just sayin
<AuroraBorealis_> cause not only bazaar has to support itself but now it has to flawlessly support every other version control software out there
<AuroraBorealis_> also github is sure taking its dear sweet time. siqq no progress indicators
<AuroraBorealis_> yeah. cloning from github does NOT take 1 minute =P
<vila> hi all !
<AfC> AuroraBorealis_: as I said above, I got it in ~15 minutes.
 * fullermd vilas at wave.
<vila> fullermd: :)
<AuroraBorealis_> well
<AuroraBorealis_> the fast-export output for the linux kernel is currently 15 gb
<AuroraBorealis_> i might run out of drive space o.o
<jam> morning all
<vila> jam: _o/
<vila> jam: no hang today, you're getting closer, the hang(s?) is scared and hides ;)
<fullermd> Maybe it's just hanging him out to dry.
<jam> vila: well, in testing, it was hanging around 2pm, and then stopped around 5pm. Apparently it is related to the phase of the moon.
<vila> jam: also note that windows has never hung which is a good sign
<vila> jam: testing locally you mean ? How ? Otherwise, yes, of course it's related to the moon...
<vila> :)
<jam> vila: yes, locally
<jam> and on devpad
<jam> I could reliably get it to hang, and then it started always working...
<vila> jam: infuriating
<jam> yep
<vila> but being able to trigger it more and more is a sure sign you're making progress
<vila> don't let it drive you nuts, you'll win in the end, it knows that...
<vila> jam: which server is involved in the hang, the pipe or the TCP one ?
<jam> vila: tcp, we generally don't use the pipe one in testing.
<vila> jam: did you consider using cethread there ? I seem to remember some hangs being caused by uncaught exceptions...
<jam> vila: cethread?
<jam> CatchingExceptionThread?
 * vila nods
<jam> I don't think that is this specific problem, but i'm still digging.
<vila> bzrlib.cethread
<jam> I'm not getting an uncaught exception traceback on the terminal
<vila> I think I encountered cases where you don't get tracebacks (can't remember the details, that was... hairy)
<mgz> morning all
<vila> mgz: _o/
<jelmer> 'morning
<mgz> jelmer: what's the process for landing things for bzr-builddeb?
<mgz> (thanks for reviewing)
<jelmer> mgz: once you have approval, you can land them manually by doing one merge per MP into trunk
<mgz> hm, I'll need to join the right team
<mgz> does that mean bugging james_w?
<jelmer> yep
 * mgz gets out his butterfly net
<poolie> hello mgz, jelmer, europa
<mgz> hey poolie!
<jelmer> hi poolie
<jelmer> hah, netsplits
<jelmer> mgz: one of the other bzr-builddeb-hackers should also be able to land it for you until you get commit access
<vila> jelmer: _o/
<jelmer> jam: hi
<jelmer> jam: did you see my follow-up to https://code.launchpad.net/~jelmer/bzr/vf-fileids-altered-by-revisions/+merge/76851 ?
<vila> . o O (Using semaphores during net storm sounds appropriate)
<jam> jelmer: approved
<jelmer> jam: Thanks!
<jelmer> vila: wrt https://code.launchpad.net/~jr/bzr/plugin-test-failure/+merge/77569
<jelmer> vila: isn't the test for export-pot ?
<vila> yes, but applied to a plugin
<vila> i.e. it should run if the plugin is available and not run it's not there, so putting it in plugin test suite makes sense
<vila> now it may also makes sense to have another test that we fail gracefully when we try to export-port an unknown plugin
<jelmer> vila: it should run in either case I think; it's a test for 'bzr export-pot', not for bzrlib.plugins.launchpad
<jelmer> vila: perhaps rather than using launchpad the test should register a dummy plugin
<vila> would work too but that seems more complex than two simpler tests
<vila> the dummy plugin stuff is brittle
<jelmer> vila: it seems wrong to put a export-pot test in the launchpad plugin testsuite though
<vila> really ? Why ?
<jelmer> vila: I would never think to look there if I was looking for export-pot tests
<vila> haa
<mgz> hm.
<jelmer> vila: I'd have to check the testsuite of every other plugin too to see if it happens to test export-pot
<mgz> I think it's a question of whether this is just a test that any plugin works at all
<jelmer> vila: using requiresFeature in the tests seems like the right thing to me
<mgz> or whether every plugin that grows translatability will want a test that it works
<jelmer> mgz: it is
<vila> well, it there are bits specific to plugins in export-pot, it makes sense to run that kind of test for all  plugins
<mgz> if the former, the current location and a skip seem fine
<mgz> if the latter, there should be a testcase class that plugins can subclass and use
<vila> mgz: +1
<vila> that'll make plugin autors life easier to have already written tests for them
<vila> authors
<jelmer> mgz: in this case, it's the former
<vila> jelmer: and you won't test the unknown plugin case
<jelmer> vila: The unknown plugin situation deserves its own testcase
<mgz> okay, all caught up on launchpad mails, found some interesting bug reports
<Riddell> ModuleAvailableFeature from tests is deprecated, anyone know what replaces it?
<mgz> Riddell from tests.features instead?
<jam> Riddell: use it from features
<Riddell> right, just a move
<jam> bzrlib.tests.features.ModuleAvailableFeature
<Noldorin> hi jelmer
<jelmer> hi Noldorin
<Noldorin> jelmer, how's it going?
<Noldorin> jelmer, you seem to disappear each time i poke you hehe
<jelmer> alright, how are you ?
<Noldorin> pretty good
<Noldorin> working on various things; putting bzr-git aside for now
<Noldorin> but speaking of which, how's progress? :-)
<Noldorin> jelmer,
<jelmer> Noldorin: nothing new yet
<Noldorin> jelmer, ah okay. any time soon though you think? :-)
<jelmer> Noldorin: no idea, sorry
<Noldorin> okay
<jelmer> it might be very soon, might take a month or so
<Noldorin> haha
<jelmer> it just depends on what else comes my way
<Noldorin> very specific
<Noldorin> oh well
<Noldorin> fair enough
<Noldorin> jelmer, it's okay, i understand. you seem quite over-workd to be fair :-P
<Noldorin> shame there isn't someone else helping you out
<jelmer> Noldorin: nothing stopping you :)
<Noldorin> jelmer, except my lack of knowledge of both python and bzr-git? :-P
<jelmer> that's fixable
<Noldorin> i mean...the code is well-written with doubt...but not exactly well commented heh
<Noldorin> alas, i don't have the many hours required for such a task
<jam> vila: so, I found out why it was hanging, now to figure out what to do next.
<jam> Specifically, if any client causes an exception in SmartTCPServer_for_testing it causes the server to stop
<jam> which also has the side effect that the next connection sees "oh, I'm stopping"
<jam> but doesn't actually close the connection
<jam> and because we keep a list of ".clients" the socket stays around and doesn't get garbage collected
<jam> so the client just hangs indefinitely
<vila> jam: which exception ?
<jam> vila: I'm not sure on that part yet, but this fixes the hang: http://paste.ubuntu.com/699711/
<jam> I think there was a failure in the previous request (which might eventually bubble up)
<jam> but we don't get there, because the next request is denied and just hangs
<vila> that's probably the race
<jam> vila: right, now we might start seeing test *failures* after this
<jam> but we shouldn't see hangs
<jam> which I'm happier with :)
<vila> hehe, progress !
<Noldorin> jelmer, okay, so i'm actually a little bored now. if i can make this fix within an hour or two, maybe it's just worth it :-P
<Noldorin> jelmer, that is, if you could provide any specific details how that function needs to be rewritten...would help a lot
<Noldorin> i know you summarised already, which helps ;-)
<jam> vila: and I *think* what is happening is that we get 3-4 connections to the smart server during the test case
<jam> and some of those start a connection, and then never make another request
<jam> so they eventually timeout as an idle connection
<jam> which is actually true
<jam> they are dead, but just never called disconnect()
<vila> probably related to daemon threads which should be joined instead during tests (at least)
<jam> however, if any of those trigger ConnectionTimeout, that is an exception which gets passed to the server and shuts it down
<jam> because you don't have the "handle a connection timeout" logic in SmartTCPServer_for_testing that is in SmartTCPServer
<jam> we re-implemented the '.serve()' stack
<vila> well, there was no timeout when it was implemented
<jam> vila: sure, though that also meant we just stayed connected on dead connections forever.
<jam> so I think the sequence is
<vila> known thread leaks
<jam> we make an initial request to the server
<jam> and never disconnect
<jam> that connection is then 'idle'
<jam> if the rest of the test takes longer than 4.0 seconds to finish
<vila> when I mentioned the issue, the answer was, we don't want to change the server design because we don't care
<jam> the idle thread wakes up and disconnects the client
<jam> which has a side effect of shutting down the server as a whole
<jam> which causes further requests to get side lined
<jam> causing a hang without the patch, and probably a test failure with ti.
<vila> so ConnectionTimeout just needs to be added to ignored_exceptions
<jam> vila: right, something like that
<jam> I'm still poking around there
<jam> vila: though not exactly that
<jam> because handle_error is the one shutting down the server
<jam> not CEThread
<jam> CEThread would raise it as an exception during thread.join
<jam> but before we get to the point of reaping old connections
<jam> we've already shut down the server because one request failed
<vila> I think you have been mixing two designs
<vila> if ConnectionTimeout is not an error, handle_error should never see it
<jam> vila: I'm not 100% sure about ConnectionTimeout, I am pretty sure about handle_request causing a hang if the server is in shutdown mode.
<vila> jam: I don't quite get why a client can connect if the server is shutting down, isn't the listening socket closed as soon as the server shuts down ?
<jam> vila: *not* if it is shutting down because of handle_error
<jam> vila: If you call "stop_server" then it tries to connect to its own socket to force the server to stop accepting connections
<vila> ha right !
<jam> but if you call handle_error()
<jam> it just sets "self.stopping"
<jam> but it is stuck in "self.accept()"
<jam> socket.accept()
<vila> because only a single client could fail before your patch
<jam> so it will accept *1 more connection*
<jam> that it won't respond to
<jam> vila: yeah probably
<vila> well, that's more than probably :)
<jam> oh, another small bug
<jam> vila: http://paste.ubuntu.com/699723/
<vila> the test runs in the main thread so only one client can run at a time, therefore only one client can fail at a time
<jam> can you point out why close_request won't get called?
<vila> same constraint
<jam> vila: handle_request has a blanket "raise" in it
<vila> the server shutdown takes care of closing
<vila> where ?
<jam> vila: bzrlib.tests.test_server.TestingTCPServerMixin.handle_error
<vila> and ?
<jam> vila: we get an exception, we 'handle it' by re-raising it, which means you won't call close_request() though the code sure looks like it would
<jelmer> Noldorin: I'm not sure if I can really provide much more details without spending a considerable amount of time on it myself
<vila> no
<jelmer> Noldorin: either way, it would be worth reading up on the bzr and git internals if you want to have a stab at this
<jam> vila: TestingTCPServerMixin.handle_request calls process_request in a try/except
<vila> the code calls handle_error and then close_request, if an execption is raised in handle_error, close won't be called
<Noldorin> jelmer, hmm okay sure. anything i should read beside the general code and bug report itself?
<jam> vila: except handle_error calls "raise"
<jam> re-raising the existing error
<vila> that's what I just said
<Noldorin> jelmer, even a rough pseudocode implementation of the new implementation perhaps...? ;-)
<vila> jam: and I said previously: <vila> the server shutdown takes care of closing
<vila> jam: which was based on the same assumption that a single client can fail at a time
<jam> vila: so, it violates the SocketServer paradigm to have handle_error raise an exception. Sure, it may get caught later.
<jelmer> Noldorin: the repository structure (how a tree is built up, etc)
<jam> but it can also cause hangs
<vila> what paradigm ?
<jam> because the client is never disconnected
<jelmer> Noldorin: sorry, I'm not entirely sure what the pseudocode would have to look like yet either
<Noldorin> heh okay
<Noldorin> that's fine
<jam> so say the client makes a bad request, that triggers an exception on the server
<jam> the client then hangs forever waiting for the server to respond
<jam> because the server didn't close the connection.
<vila> doesn't happen in tests
<jam> vila: we haven't triggered it yet in tests
<vila> you can't
<vila> unless you introduce a new kind of failure like you did with the timeout
<jam> vila: if process_request itself was buggy it would be triggering this
<jam> it happens that process_request immediately deferrs to a thread for the actual processing.
<vila> by design
<jam> vila: sure, but if there were a bug in that code, it would cause hangs
<jam> vila: also you have "t.pending_exception()" so if an exception happens at thread start, it will also cause hangs.
<vila> which is why there should be no bug there :)
<jam> again, I haven't tracked down where the actual failure is causing the code to then hang, I'm pointing out that the current implementation is likely to hang if there are failures in a few key aspects of the code.
<jam> rather than getting a test suite failure that we can debug
<vila> well, I suggest focusing on this new failure mode you've introduced first
<jam> vila: I have to get an actual failing test first
<jam> which involved not having the test suite hang
<jam> On windows, because the hang is in a sock.recv() you can't even ^C out of it to get a traceback.
<vila> use cethread to check which exception is shutting down the server then
<vila> jam: the TCP server on windows ?
<jam> vila: socket.recv() is one of those "blocking and cannot be interrupted" calls on Windows
<jam> this is actually during "self.make_repository()"
<vila> jam: the TCP server on windows ?
<jam> vila: the *client* code is blocked
<vila> jam: the TCP server on windows ?
<Noldorin> jelmer, heh. i guess that 'in progress' is for me? ;-)
<jelmer> no, just in general since there's a testcase and some initial work
<jam> vila: Repeating yourself doesn't make me understand what you are asking. Vs what?
<vila> jam: is that when using the TCP server on windows ?
<jam> vila: yes
<vila> as opposed to the pipe server, there are only 2
<jam> vila: as I said way back when, we generally don't use the pipe server in testing
<jam> This is a per_interrepository test.
<jam> But per_repository where Repository format is Remote triggers the same code paths
<jam> We have a SmartTCPServer_for_testing running, it received a request but decided it didn't want to respond because it was shutting down.
<Noldorin> jelmer, ok sure ;-)
<jam> The client is then blocked waiting for the server to respond (or disconnect it)
<jam> On Windows, the client is blocked so badly you have to kill the process.
<jam> On Linux, you can at least do ^C and get a traceback in ~/.bzr.log
<vila> yeah, on linux too
<vila> not always when a hang happens
<jam> vila: for this particular hang, ^C worked fine for me
<jam> it is how I pinpointed the hanging part
<vila> hmm, lucky you then ;)
<vila> jam: so, IIUC, if the client is in a blocking read, you should not shut down the server
<vila> jam: or if you do so, you should close the connected socket in a way that will unblock the client
<jam> vila: right, I think "closing sockets on shutdown" is the most reasonable process.
<jam> and currently the code has a few bugs where during exceptions that will stop the server, it doesn't close the connections
<vila> apart from the timeout case, I think the test server is quite well tested in this regard
<vila> the only problematic case being th TCP smart server because it didn't track the client connections
<jam> an exception during process_request will cause the server to not disconnect the client
<jam> that includes process_request_thread because SocketServer was also written as "self.handle_error(); self.close_request(request)"
<vila> that was the right thing to do as long as a single client thread could fail
<vila> if this is not true anymore for your server, you should probably overload verify_request and handle_error
<mgz> hm, not sure if it'd be better to give instructions or just do the changes.
<jam> vila: so interestingly enough, you had a test case for "test_server_fails_while_serving_or_stopping", but you had wrapped the client.read with a socket timeout and suppressed the socket error.
<jam> It turns out, that if you don't need the timeout if you close the connection.
<jam> however, there is a catch
<jam> if you use SocketServer.StreamRequestHandler
<jam> it creates an "rfile"
<jam> which is *another handle to the socket*
<jam> so just closing the 'request' object isn't sufficient
<jam> you have to either a) Not use StreamRequestHandler, or b) somehow get at the handler to tell it to close its handle because you had an error.
<jam> alternatively, if you don't raise an exception in handle_error, the StreamRequestHandler goes out of scope naturally, and closes its connection
<jam> but with an exception, I think it ends up in the traceback, and thus doesn't get gc'd
<jam> given that we avoid StreamRequestHandler everywhere else because makefile doesn't play very nicely with other bits (in general)
<jam> it would seem reasonable to just avoid it.
<vila> and replace all read/write with recv/send ?
<jam> there is only one or two read write calls anyway.
<jam> The comment on the timeout was that "the server may not get cycles" but the reality was that the server got the cycles, it just wasn't disconnecting the client.
<vila> which comment ?
<mgz> yeah, makefile is more trouble than it's worth
<AfC> That bzr branch of a local git to local bzr tree that I kicked off earlier is at 8h53m22s elapsed, 245 minutes CPU time. Half way done.
<jelmer> hmm
 * jelmer ponders deprecating make_branch_and_tree
<AfC> jelmer: oh, hey
<AfC> jelmer: I applied poolies workaround tag deletes
<AfC> jelmer: and I'm churning though it now.
<jelmer> AfC: cool
<jelmer> AfC: note that his bug shouldn't crop up if you clone from the remote git branch directly
<AfC> jelmer: yeah, I couldn't do that [at the time] because bzr-git choked on github URLs (or, rather, the 405 redirect thereby)
<AfC> jelmer: ppa:bzr/daily appears to have fixed that, I discovered subsequently.
<jelmer> AfC: git:// should work in older versions of bzr-git, too
<jelmer> AfC: but yeah, http/https weren't supported earlier
<AfC> jelmer: plus, old habit - I got tired of things crashing :/
<jelmer> AfC: yeah, this is all still pretty experimental stuff..
<vila> hang on lucid :-/
<vila> I was hoping to *not* see that as it means it can happen on pqm too :-/
<AfC> vila: I don't want to hear these things!
<vila> AfC: sorry, I wasn't talking to you :)
<AfC> heh
 * AfC adds 8GB of swap to his server in hopes that bzr will not OOM on me
<vila> Finally, https://launchpad.net/bzr/+milestones starts to become readable...
<jelmer> vila: still there?
<jelmer> it looks like any bzrlib usage now breaks if bzrlib isn't explicitly initialized
<jelmer> I've filed a bug
<vila> ha, I had some doubts about that :-/
<vila> jelmer: assign it to me, I ~know what is going on
<vila> jelmer: sorry about that :-/
<vila> jelmer: how did you encounter it ?
<jelmer> vila: I was writing a simple test script when I hit it: http://pastebin.ubuntu.com/699875/
<vila> ha. Add 'with bzrlib.initialize():' :-p
<SpamapS> Hi guys, I'm trying to use bzr builder to do a dailydeb for a source tree that has a debian/ dir that differs from the packaging branch..
<SpamapS> Is there a way to tell nest-part to just do a forcible merge?
<vila> jelmer: where did you file this bug ?
<AuroraBorealis> well. converting the linux kernel git repo to bazaar has taken 9 hours so far and only 1/6th done haha
<AuroraBorealis> no i lied its half done
<AuroraBorealis> all this in the name of science!
<AuroraBorealis> :O\
<science> AuroraBorealis: thanks !
<AuroraBorealis> someone here was saying a local branch with a tons of commits took forever
<AuroraBorealis> so i'm trying it out
<AuroraBorealis> but i think he was trying to branch the git repo which means it had to convert it, which of course is taking forever
<mgz> jelmer: if you get a moment, please do merge my bzr-builddeb branches
<mgz> jam: you can review your own fix for bug 856731 if you like
<ubot5> Launchpad bug 856731 in Bazaar "out of memory Fetching revisions:Inserting stream:Estimate on AIX" [Medium,In progress] https://launchpad.net/bugs/856731
<SpamapS> Who would be the best person to ask about build recipes? I am having a hell of a time with one right now. :-/
<SpamapS> james_w: ping?
<jelmer> mgz: will do
<vila> jelmer: still there ?
<vila> jelmer: I'm running a full test run before submitting my fix for bug #863401
<ubot5> Launchpad bug 863401 in Bazaar "now requires explicit initialization" [Critical,Confirmed] https://launchpad.net/bugs/863401
<vindolin> anyone else having problems commiting with bazaar explorer?  bzr: ERROR: exceptions.TypeError: unsupported type u'Collecting changes [0] - Stage'
<AuroraBorealis> does it happen with the command line bazaar?
<vindolin> AuroraBorealis: no.. works perfect
<AuroraBorealis> hmm
<AuroraBorealis> latest version of explorer and all that?
<vindolin> 1.2.1
<vindolin> and all that :)
<vindolin> http://paste.pocoo.org/show/eUq2c1UEqxfo3wHvM2eE/
<vindolin> ^ traceback
<AuroraBorealis> well you are using bazaar 2.5 :o
<vindolin> AuroraBorealis: what's wrong with that?
<AuroraBorealis> well the '2.5dev2' kinda speaks for itself =P
<AuroraBorealis> are you sure its not  a problem with the development version?
<vila> vindolin: check that 'all that' is the tip for all your plugins and if you still encounter the issue: https://bugs.launchpad.net/bzr/+filebug
<vila> vindolin: it looks like qzbr is confused by a progress bar output
<vila> vindolin: so may be you should report at: https://bugs.launchpad.net/qbzr/+filebug instead
<vila> vindolin: unless you played tricks with BZR_PROGRESS_BAR but I fail to imagine which...
<vindolin> i have no idea where the dev version comes from.. checking..
<vila> vindolin: someone installed it from source, there is no released version with 'dev' in its name, but you're using a bzr installed in /usr/lib/python2.7/dist-packages/ nevertheless
<vindolin> ok.. apt-get removed everything bzr.. reinstalled.. works :/
<vindolin> bzr is now 2.4.1.. strange
<vila> vindolin: meh, I'm glad for you, let us know what happened if you ever find out
<vila> It's still a weird behavior even running from sources
<vindolin> ok thanks everyone
<jeff_> hello people, have a silly newbie question.
<jeff_> can't seem to find the answer in the docs for bzr: I just did bzr add, not realising that my .bzrignore filter was not on this machine.  how do i tell bzr to forget my massively incorrect add operation, without any changes to my files?
<lifeless> vila: hi
<lifeless> vila: i thought initialize was mandatory for about 6 months now; surely the break has already been done?
<vila> lifeless: I thought so too but as you can see, that's not the case
<lifeless> vila: jelmers bug doesn't indicate that
<lifeless> vila: 'fetch.py' might be years old
<lifeless> vila: poolies 'new' deprecation thing says its ok to break apis across major releases
<vila> lifeless: what triggered this bug is that the config now needs initialize to be called or bzrlib.global_state is None
<lifeless> vila: sounds fine to me :)
<lifeless> vila: I'm just saying, if its cleaner not implicitly initializing (it is I think), then you've already made that transition.
<vila> lifeless: our own generate_docs.py was calling it
<vila> grr wasn't
<vila> no, it doesn't initialize implicitly
<lifeless> vila: actually, did you just say you're using bzrlib.global_state from config?
<lifeless> thats a bug.
<lifeless> You should be passing the library state *into the config system*
<lifeless> nothing new should ever be accessing bzrlib.global_state
<vila> from where ?
<vila> yeah, there are so many constraints on it that nobody can use it
<vila> without violating at least one
<lifeless> I'm not sure what you mean
<lifeless> the thing was a centralisation of existing globals spread out through the code base
<vila> how should the config system acquire the library state ?
<lifeless> it should be passed in
<vila> by who ?
<lifeless> callers
<vila> you want it to be a parameter to all bzrlib calls ?
<lifeless> or held as an instance variable
<vila> intialized when ?
<lifeless> when you create the object
<vila> in bzrlib.initialize ?
<lifeless> why would bzrlib.initialize need to know about configs?
<vila> which object ? the config ? From where... ELOOP
<lifeless> let me phrase it differently. *a* goal is to be properly isolated in tests from the test runner, which also uses a BzrLibraryState
<lifeless> uses of 'bzrlib.global_state' are in violation of that goal, though we have workarounds today.
<vila> not the bzr one :-/
<vila> what workarounds ?
<vila> either the state is passed all over place or you need to access it
<lifeless> indeed bzrlib/tests/__init__ is missing a push-pop of the library state in each test.
<lifeless> that will be contributing to test isolation issues.
<lifeless> (I haven't pulled recently, you may have worked around it)
<lifeless> yes, thats right - the state needs to be passed around when creating objects that need access to the state.
<vila> since branches needs a config, all branch operation should pass the state then
<lifeless> note the BIG comments in bzrlib/__init__.py
<lifeless> # If using this variable by looking it up (because it can't be easily obtained)
<lifeless> # it is important to store the reference you get, rather than looking it up
<lifeless> # repeatedly; that way your code will behave properly in the bzrlib test suite
<lifeless> # and from programs that do use multiple library contexts.
<vila> and since branches can be obtained from wt, same goes for all wt operations, etc
<lifeless> vila: thats bogus
<lifeless> pass it to __init__. Once.
<lifeless> fin, end of story, done
<vila> which __init__ ?
<lifeless> THE OBJECT INIT
<lifeless> sorry, I have to go, EBABY etc.
<vila> oh come on, where did the caller got it brom ?
<vila> from
<lifeless> vila: the ultimate caller gets it from bzrlib.initialize()
<lifeless> they pass it to Branch.open() which passes it to the constructor of the Branch. All ops on the branch use self.library_state.
<lifeless> for instance.
<vila> that still means a lot of code paths need to carry it
<lifeless> I *have* to go, sorry. This seems very straight forward to me.
<vila> easier said than done, I fully understand *how* it can be done, I just don't think adding such a parameter to a bunch of signatures will outweight the benefits.
<vila> and I probably meant the losses :)
<lifeless> in terms of overheads, its at most 1*number-of-classes + the call stacks for key factory functions like Branch.open
 * lifeless is gone
<lifeless> vila: and back but I suspect you are sleeping now :)
#bzr 2011-10-01
<AfC> jelmer: that import is stuck at about average 10 rev per minute at
<AfC> jelmer: fetching revisions 149790/264178
<AfC> Should I be trying the "pull 1000 revisions at a time in a loop" trick, maybe?
<AfC> (the bzr process is at over 3 GB VSZ, so there's now a lot of swapping going on. It's pretty ugly)
<AuroraBorealis> well that was dissapointing
<AuroraBorealis> bzr ran out of memory =(
<AuroraBorealis> after 15 hours of fast-import xD
<AfC> AuroraBorealis: mine hasn't run out of memory, but at 25 hours elapsed it is essentially stuck, constantly swapping
<AuroraBorealis> are you still branching?
<AfC> [bad Python VM doing reference count based GC, bad]
<AfC> AuroraBorealis: yep
<AuroraBorealis> what are you branching, a git repo?
<AfC> AuroraBorealis: the kernel, yes
<AfC> as we were discussing yesterday
<AuroraBorealis> yeah thats why its taking so long =P
<AuroraBorealis> i thought you were branching a bazaar repo
<AfC> if it's making progress, I don't care. But it's just spinning it's wheels.
<AfC> | fetching revisions 151486/264178
<AfC> It was at 140000 this morning
<AuroraBorealis> mine got to 16,000
<AuroraBorealis> then ran out of memory as it was repacking the repo :>
<AfC> 3 GB virtual memory, 1.5 phys... swap swap swap
<AfC> I'm going to try the pull a 1000 revisions at a time trick.
<AfC> That worked on GTK a couple years ago when pulling from Subversion
<AfC> â pub
<AuroraBorealis> heh
<AuroraBorealis> but yes, this could defenitly be faster. and not run out of memory xD
<iaindalton> I'm following the Emacs Bzr guide. It says to do "bzr branch nosmart+bzr+ssh://iaindalton@bzr.savannah.gnu.org/emacs/trunk trunk", but I get Permission denied (publickey). bzr: ERROR: Connection closed: Unexpected end of message. (etc.) Why is it doing this and how can I fix it?
<lifeless> your ssh key is not present on the server. I don't know why its not, nor the process for getting it on that server - I would hope the guide covers both points.
<iaindalton> It doesn't AFAICT
<rly> Is there any way to know the repository size before downloading it completely?
<jelmer> rly: "bzr info -v" should tell you the number of revisions
<rly> jelmer: also, how does the whole brz foo:bar thing work?
<jelmer> rly: do you mean lp:<project> ?
<rly> jelmer: yes
<jelmer> rly: lp: is a shorthand for addressing branches on Launchpad, provided by the "launchpad" plugin that's bundled with bzr
<andy> hey guys, can someone please help me with an bzr - buildbot issue? It might not be related to buildbot at all, that's why i am asking here
<rly> jelmer: bzr branch lp:calibre is already at 600MB (!).
<rly> jelmer: I want to know how long it will continue.
<rly> I think the Linux kernel is even smaller.
<jelmer> andy: please ask your question, if anybody here can help we'll reply
<andy> alright, thanks
<andy> i  got a buildbot master running. a bzr repo is hooked to it. so the bzr_buildbot.py is my plugins directory. i also adjusted the locations.conf file. but everytime i am trying to check something in, ill get an error:
<andy> $:~/tmp/repo$ bzr ci
<andy> Committing to: /home/.../tmp/repo/
<andy> modified setup.py
<andy> bzr: ERROR: exceptions.AttributeError: 'Revision' object has no attribute 'get_apparent_author'
<andy> the script i used can be found here: https://raw.github.com/buildbot/buildbot/master/master/contrib/bzr_buildbot.py
<Peng> andy: ...What version of bzr?
<andy> andy@europa:~/tmp/buildbot/basedir$ bzr --version
<andy> Bazaar (bzr) 2.3.4
<andy>   Python interpreter: /usr/bin/python 2.7.1
<andy>   Python standard library: /usr/lib/python2.7
<andy>   Platform: Linux-2.6.38-11-generic-x86_64-with-Ubuntu-11.04-natty
<andy>   bzrlib: /usr/lib/python2.7/dist-packages/bzrlib
<andy>   Bazaar configuration: /home/.../.bazaar
<Peng> yeah ok ok ok!
<andy>   Bazaar log file: /home/.../.bzr.log
<andy> sry :-)
<andy> buildbot doesn't even have to be running if you want to get that error
<andy> the problem might be here aswell:
<andy> $ cat locations.conf
<andy> [~/tmp/repo]
<andy> buildbot_on = change
<andy> buildbot_server = localhost
<jelmer> rly: it finished pretty quickly here
<jelmer> rly: what version of bzr are you running?
<rly> jelmer: are you on a 100Mb network?
<jelmer> rly: 336.910  Transferred: 390815kB (1160.6kB/s r:390814kB w:1kB)
<rly> jelmer: I have a 6 as a first number?
<jelmer> rly: what version of bzr are you running?
<rly> jelmer: 2.1.2
<jelmer> there have been some major performance fixes recently, perhaps that's relevant here
<jelmer> rly: I suspect 2.4 will be a lot faster for you, and use less bandwidth
<rly> jelmer: what kind of connection do you have, btw>
<jelmer> rly: it took 5 minutes at 1.1Mb/s
<andy> do you have any idea if gary poster (the maintainer of the bzr_bulidbot.py) is here sometimes?
<jelmer> andy: he's often in #launchpad-dev
<jelmer> andy: though usually during the week rather than in the weekend
<jelmer> andy: still there?
<jelmer> andy: the call to get_apparent_author() should be changed to get_apparent_authors()[0]
<Peng> Ah, I *knew* there was an API compatibility issue around get_apparent_author(), but I was thinking that it was too new, not that it was too old. It was killed around 2 years ago, wasn't it?
<jelmer> Peng: yep, and then deprecated for a long time. I didn't realize it had been deleted
<andy> Peng: sorry, was afk. I found the same solution. should i file a bug for this? or are you able to fix it?
<andy> Peng: in the buildbot IRC they told me to file a bug with the fix.... but if you can fix it right away this might be better.
<Peng> Sorry, not me. Filing a bug's probably the best bet.
<Peng> merge proposal
<Peng> Bah. / merge proposal.
<Peng> (* Actually, I might have commit rights to it, but I've never touched it.)
<andy> Peng: alright. please give it try, otherwise i am gonna file it
<Peng> I don't wanna give it a try. >.> I feel weird jumping in.
<Peng> Wait, it's part of buildbot, not part of bzr? Then I certainly don't have commit rights. And I've only used Github once in my life. :P
<andy> ah, sorry, i missunderstood it
<bpierre> hi
<bpierre> vila: I'm looking at the UI thing, and I'd like to be sure about you use case
<bpierre> *your
<bpierre> on my side, I don't call bazaar from VIM, but rather use VIM python bidings to directly use bzrlib
<bpierre> I provide my own UIFactory implementation, but since shelf_ui does not use get_boolean, it does not work
<bpierre> calling bzr from VIM (e.g. :!bzr shelve), does work
<bpierre> using "yes no | bzr shelve" in a terminal however, does not
<bpierre> so my question is: looking at your change, it seems that the isatty check is not enough, why?
<vila> bpierre: almost not there, I'll try to be quick
<vila> "yes  no | bzr shelve" is seen as 'y' 'e' 's' ' ' 'n' 'o'
<bpierre> not on the version without your patch
<vila> bpierre: with  patch I landed and INSIDE_EMACS=1 it will see 'yes no'
<vila> s//the/
<bpierre> sorry, the example was using the unix yes command
<vila> bah, sorry
<bpierre> :)
<vila> you still need INSIDE_EMACS :)
<bpierre> so can't have a controling terminal when using shell command in emacs?
<bpierre> switch to VIM! (kidding) ;)
<vila> hehe
<bpierre> so now that it's in UI, better to change the environement variable name
<bpierre> no?
<vila> the trick is that the isatty() is not appropriate under emacs, there is no way to automatically detect the right kind (char or line)
<bpierre> I know there is one for progress
<bpierre> ok
<vila> the plan *is* to change that, yes
<vila> gtg, bbl
<bpierre> ok
<vila> i.e. prpose your branch, we'll sort out the details :)
<vila> bpierre: I'm patch pilot next week anyway, so will have more time
<bpierre> ok
<vila> bpierre: back, urgent, but quick ;)
<andy> Peng: i made a pull request for the fix. Thanks for your help
<Peng> andy: It was mostly jelmer's help :P
<vila> bpierre: start by proposing your branch and if you still want to tweak before it's reviewed, you can. Complete your initial cover letter in the commit messages for your tweaks ans just 'bzr push'
<vila> s/ans/and/
<bpierre> ok
<vila> grrr, does someone knows an IRC client with a spell checker ?
<bpierre> can you just tell me the command you use to test in emacs?
<vila> s/knows/know/ crap
<vila> hehe
<vila> bpierre: it won't work for you :)
<bpierre> weechat has an aspell plugin
<bpierre> I tried with M-!, but even with line based input, it does not work
<bpierre> I don't use emacs at all, have not for a long time
<vila> emacs sets INSIDE_EMACS=1, so *I* don't have to type but you do. After that you just use ./bzr selftest -s bt.test_shelf_ui
<vila> to test your changes
<vila> or if you want to observe the behavior of 'bzr shelve': 'INSIDE_EMACS=1 ./bzr shelve'
<bpierre> by how do you control the shelf ui from emacs?
<vila> oh ! Sorry
<bpierre> with VIM, :!bzr uncommit
<vila> I run a shell under emacs
<bpierre> works ok
<bpierre> so how do you start the shell, that's all I'm asking!
<vila> a regular bash shell *except* the input is line based
<vila> M-x shell
<vila> M for meta, 'ESC x' works too
<bpierre> ok! and not M-! command
<bpierre> got it
<vila> bpierre: just curious, how well do you know emacs ?
<vila> hmm, you have it installed obviously
<bpierre> no well at all! just installed it, for that and testing notmuch, started with it, before converting to vim :)
<bpierre> 10 years ago
<vila> bpierre: OMG, you went to the Dark Side ! vi, vi, vi VIVIVI is the editor of The Beast !
<vila> bpierre: I've seen rms in flesh as St IGNUcis for the first time recently, the guy has a strong sense of auto-derision ;)   http://stallman.org/saint.html
<bpierre> yeah
<vila> bpierre: A *good* way to understand what my patch fix: with an older bzr version: add a line in a file, try to shelve it.
<vila> bpierre: and watch your added line still present 8-)
<AuroraBorealis> should i report a bug if bzr ran out of memory doing something?
<vila> bpierre: you just type 'y\n' and shelve sees 'y' '\n' (default n) '\n' (default n) and think you don't want to shelve it finally :)
<vila> AuroraBorealis: es, that would be helpful and awesome! Especially if you mentioned your hardware config ( mem size, proc, etc) and the software one (bzr version, plugin versions, etc) and of course the data (urls, formats, revision ids, etc) so we can reproduce and compare
<vila> AuroraBorealis: we may need time to fix it but we'll know how close we get along the way ;)
<AuroraBorealis> k
<AuroraBorealis> i was trying to...convert the git repo for the linux kernel
<AuroraBorealis> and first i ran out of memory, then i ran into this bug =P https://bugs.launchpad.net/bzr/+bug/541626
<ubot5> Ubuntu bug 541626 in Bazaar "'BTreeBuilder' object has no attribute '_find_ancestors'" [High,Triaged]
<vila> AuroraBorealis: <cough> 2.1.0 ??
<AuroraBorealis> do you mean thats the bzr version i'm using?
<AuroraBorealis> i'm using 2.4.0
<vila> AuroraBorealis: You'd really get better performance and memory consumption with 2.4 which is stable or 2.5b1 which is beta
<vila> oh, known bug ! Sorry, let me finish reading
<AuroraBorealis> xD
<AuroraBorealis> i also have 8 gb of memory, but i guess the version of python bzr uses is 32 bit
<vila> AuroraBorealis: sry, gtg, metoo the bug and subscribe
<AuroraBorealis> kk!
<vila> AuroraBorealis: and the informations mentioned above (and check the comments ?)
<udp> so I have a recipe set up for my project, and the source is being imported from a git repository by launchpad
<udp> I need to add a tag "upstream-0.2.4t"
<udp> I don't know anything about bzr, but I assume that's to tag a particular revision as 0.2.4?
<udp> since the debian packaging info says it's building 0.2.4
<udp> I'm not sure how I'd do this since the branch is coming from git
<jelmer> udp: hi
<jelmer> udp: still there?
<udp> Hi jelmer, yeah I am
<jelmer> udp: git imports should import tags as well, so if you create one in Git it should create a matching tag in bzr
<jelmer> udp: that said, why do you need that particular tag? It shouldn't be necessary for the recipe.
<udp> ah, I didn't realise it did
<udp> thanks - well, I'm getting "bzr: ERROR: No such tag: upstream-0.2.4t hooks - Stage 5/5"
<jelmer> udp: try building with --allow-fallback-to-native
<udp> I guess it'd be building HEAD if I did that?
<jelmer> udp: well, this is about how it determines the upstream source
<jelmer> udp: if you specify --allow-fallback-to-native then it will simply create a "native" debian package if it can't find the upstream source
<udp> OK, I don't get the error if I use --allow-fallback-to-native
<jelmer> I'm fixing the error message to be a bit clearer.
<udp> can I add --allow-fallback-to-native to the recipe itself?
<jelmer> udp: no, but launchpad has it enabled already
<udp> ah ok - cheers
<udp> odd, there's a *_source.changes file being generated in the working directory when I run dailydeb - it includes an incorrect Changed-By email address which is causing lintian to fail (it uses my local hostname)
<udp> it's not the address from `bzr whoami`
<jelmer> udp: I'm not entirely sure what the logic behind that is
<AuroraBorealis> jelmer i posted my bzr version to that MemoryError bug
<udp> never mind, starting a new terminal solved it - I tried to build on launchpad again, but it failed with "bzr: ERROR: Failed to apply quilt patches"
<udp> there aren't any patches
<jelmer> udp: is there a debian/patches/series file?
<udp> yes, it's blank
<jelmer> udp: launchpad is still running a fairly old bzr-builder which has problems with that
<jelmer> udp: if you remove debian/patches it should work
<wgz> AuroraBorealis: ha, I should have refreshed the bug page
<jelmer> AuroraBorealis: thanks
<AuroraBorealis> i have 8 gb of memory, so i would think that it shouldn't..run out o.o
<jelmer> AuroraBorealis: I'm not sure about bzr-fastimport, but I remember importing linux with bzr-git at some point
<wgz> you need to install it youself from parts if you want that to be true.
<jelmer> auroraborealis: I'm also pretty sure the Launchpad vcs-imports don't have that much memory
<AuroraBorealis> yeah i would think not
<wgz> because bzr only provides 32-bit windows installers
<AuroraBorealis> it seems that the importing was fine
<AuroraBorealis> but repacking it caused it to run out of memory
<wgz> jelmer: launchpad doesn't run on widnows.
<wgz> ...or windows
<jelmer> true
<jelmer> maybe John will have something useful to say about this on Monday
<wgz> I posted some observations to the bug.
<wgz> there are like, three things we could fix that I can see, but I don't know which are important without actual memory measurements
<AuroraBorealis> is there a way to do memory measurements?
<AuroraBorealis> is that what lp:meliae is?
<udp> jelmer: It built successfully on launchpad - thanks for your help  :-)
<jelmer> AuroraBorealis: yep, meliae can indeed help with memory usage analysis
<wgz> yup, if you have that when you OOM it does a dump.
<jelmer> udp: cool, glad I could help
<AuroraBorealis> ok i shall try this out
<AuroraBorealis> i might run out of disk space though haha
<AuroraBorealis> the fast export file is 20 gigs >.>
<wgz> AuroraBorealis: I'd really like if you tried a 64-bit bzr if you're okay with building python things yourself
<AuroraBorealis> yeah i can try that
<AuroraBorealis> not sure how i do that on windows
<wgz> you need a 64 bit python and the compiler it built with for starts...
<jelmer> wgz: ah, you're Martin!
<AuroraBorealis> which compiler is that?
<jelmer> wgz: What made your "m" go upside down?
<wgz> weekend!
<wgz> ...I didn't quite stick to irc hours discipline
<jelmer> yeah, it's hard on all of us :)
<wgz> AuroraBorealis: let me check, I'm slightly concerned that the old free beer MSVCs were 32 bit only
<AuroraBorealis> i *should* have access to all of the microsoft visual studio stuff, just need to ask my school
<wgz> ..I've typed "54 bit" like, three times now
<wgz> okay, this is the first thing I've turned up on google that looks even vaguely useful: <http://mattptr.net/2010/07/28/building-python-extensions-in-a-modern-windows-environment/>
<wgz> as with all such things, some of what it says is probably out of date
<AuroraBorealis> ive heard that vs2008 is the correct one too
<wgz> this no doubt still stands though  "Visual C++ express works, as long as itâs 2008."
<wgz> so, you should be able to get it to work.
<AuroraBorealis> ok
<AuroraBorealis> so then, i just download bzr from source
<AuroraBorealis> and then what do i compile?
<wgz> hm, jelmer, do you know if the C-from-pyrex sources in the tarball can be used straight up?
<jelmer> wgz: I think so; the ugliness of the generated code is in part due to it trying to support all possible compilers
<wgz> if so, you should just then be able to do `...Python2.7/python.exe setup.py` for Bazaar... then you'll need to do a similar thing for the two fastimport packages
<wgz> and meliae... anything else?
<wgz> *`python setup.py install`
<wgz> ask in here if you get stuck at any point or need more help.
<AuroraBorealis> haha
<AuroraBorealis> which fast import packages do i need?
<AuroraBorealis> or are those included in the bazaar source
<wgz> lp:bzr-fastimport and lp:python-fastimport
<AuroraBorealis> k, and do i need VS2008?
<wgz> yup.
<AuroraBorealis> so what exactly do i build with vs2008
<AuroraBorealis> i know i run setup.py for most everything
<wgz> setup.py will call the compiler for you, for the modules that need compiling
<wgz> (*should, see that blog post if it doesn't work)
<AuroraBorealis> yay!
 * AuroraBorealis starts the download
<lifeless> wgz: mgz by another nick?
<wgz> lifeless: otherwise I'd forget to logout and be ghosting come Monday all the time
<lifeless> wgz: welcome to Canonical!
<AuroraBorealis> i can't seem to branch lp:bzr
<AuroraBorealis> it just sits there at "starting" =/
<wgz> AuroraBorealis: I suggest you get the tarball, will save you needing cythong
<lifeless> AuroraBorealis: are you behind a proxy perhaps ?
<AuroraBorealis> i'm not
<wgz> lifeless: and welcome to not being able to stay logged out over the weekend? :)
<lifeless> wgz: working on something we're passionate about, from home, tends to lead to blurred lines ;)
<wgz> <http://launchpad.net/bzr/2.4/2.4.1/+download/bzr-2.4.1.tar.gz>
<wgz> you have <http://www.python.org/ftp/python/2.7.2/python-2.7.2.amd64.msi> already right?
<AuroraBorealis> yeah
<lifeless> wgz: for instance, I've just triaged a hundred or so stale LP bugs
<wgz> lifeless - he's passionate about stale bugs
<wgz> they eat funny things in nz...
<AuroraBorealis> bzr seems to be trying to open the repo with subversion or something
<lifeless> wgz: :P I'm passionate about LP
<wgz> :P
<wgz> !pastebin the log quickly AuroraBorealis?
<ubot5> wgz: I am only a bot, please don't think I'm intelligent :)
<wgz> !pastebin
<ubot5> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<AuroraBorealis> this is unrelated to the memory error thing, its just not branching lp:bzr and creating a repo has weird output o.o  http://paste.ubuntu.com/700769/
<wgz> yup.
<wgz> ugh, yeah, that's not pretty.
<AuroraBorealis> no idea why its doing it, i'm just creating a new repo >.>
<AuroraBorealis> it also seems to be denying my public key
<AuroraBorealis> back to what i was doing, its saying that no cython or pyrex is installed. do i need those?
<wgz> shouldn't say that if you went with the tarball?
<wgz> otherwise yeah, you'll need one
<AuroraBorealis> yeah its with the tarball
<AuroraBorealis> just did python27_64 setup.py and its saying "no cython, trying pyrex...pyrex is not available"
<wgz> http://www.lfd.uci.edu/~gohlke/pythonlibs/#cython
<wgz> did it then fail?
 * wgz checks the setup.py logic
<AuroraBorealis> i was just checking the arguments
<AuroraBorealis> it said that then printed the usage
<wgz> ah, it looks like it'll say that
<wgz> but then build anyway
<wgz> so, don't worry
<AuroraBorealis> now its saying cython is there
<AuroraBorealis> so yay
<AuroraBorealis> booooo
<AuroraBorealis> "valueerror"
<fullermd_> Obviously, it thinks you have questionable values.
<wgz> pastebin traceback?
<wgz> did you get the windows 7 sdk?
<AuroraBorealis> http://paste.ubuntu.com/700774/
<AuroraBorealis> no i didn't
 * AuroraBorealis installs that
<wgz> <http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=3138> is what you want I think
<wgz> ^that error might be one of the ones the blog post from earlier had a workaround for
<AuroraBorealis> yeah i'm installing it now
<wgz> see the "Trick distutils" section
<wgz> which comes after "Install the Windows 7 Platform SDK"
 * wgz hugs fullermd and his underscore
<AuroraBorealis> annnnd installation failed on the sdk
 * AuroraBorealis cries
 * wgz offers emotional support
<AuroraBorealis> the error was "see the config html page for more information"
<AuroraBorealis> thanks microsfot
<AuroraBorealis> soft*
<wgz> did it dump a html log anywhere obvious?
<AuroraBorealis> i have the log
<AuroraBorealis> no idea what its actually doing
<AuroraBorealis> http://paste.ubuntu.com/700777/
<fullermd_> Aiee!  There's an underscore on my back??  Get it off!  Get it off!!
 * wgz swats at it
 * fullermd_ spins around barking and biting as his tail.
<AuroraBorealis> found something promising on google, one se
<AuroraBorealis> c
<wgz> http://blogs.msdn.com/b/windowssdk/archive/2009/09/16/windows-7-sdk-setup-common-installation-issues-and-fixes.aspx
<wgz> the list of errors there is amusing
<AuroraBorealis> the fix is diving deeep into the registry
<AuroraBorealis> and now i apparently need to reboot
#bzr 2011-10-02
<wgz> right, I should really go to bed.
<AuroraBorealis> night =)
<AuroraBorealis> i'll be on
<wgz> I'll stay logged in here, say how far you get
<AuroraBorealis> kk!
<AuroraBorealis> wgz, I finally got the sdk installed and created the vcvarsamd64.bat file, but its still giving me ValueError: [path] (which i guess means it failed to call vcvars)
<AuroraBorealis> i guess i'll talk to you about it when you are up =P
<AuroraBorealis> i seriously hate compiling things haha
<wgz> AuroraBorealis: I think you need to read "Trick distutils" onwards in <http://mattptr.net/2010/07/28/building-python-extensions-in-a-modern-windows-environment/>
<AuroraBorealis> i did that
<AuroraBorealis> still doesn't work
<AuroraBorealis> i might of put that line in msvc9compiler in the wrong place but i dont think i did
<wgz> okay, I'll take another look at your traceback and see if I can work out what's up
<wgz> http://bugs.python.org/issue7511
<wgz> "You can work around it
<wgz> by finding and executing vcvars32.bat or vcvars64.bat before running
<wgz> setup.py
<wgz> "
<AuroraBorealis> yep thats the exact error i'm getting
<AuroraBorealis> http://paste.ubuntu.com/700959/
<wgz> did you get the 64-bit components installed correctly as well?
<wgz> <http://www.mathworks.com/support/solutions/en/data/1-6IJJ3L/index.html?solution=1-6IJJ3L> has some step-by-step it might be worth reviewing
<AuroraBorealis> it says to check an option that was checked by default
<AuroraBorealis> but i don't have 'cl.exe'
<AuroraBorealis> cause the folder wasn't created there
<AuroraBorealis> (that was the folder i created in the 'trick distutils' blog post
<wgz> checked by default is fine, is you have the `bin\amd64\cl.exe` fine somewhere
<AuroraBorealis> well the folder they say that cl.exe is in wasn't created by default
<AuroraBorealis> i had to create the directory and the vcvarsamd64.bat file
<wgz> sure, but can you find it somewhere else?
<AuroraBorealis> i see cl.exe in Microsoft Visual Studio 9.0/VC/bin
<wgz> if so, I'd go ahead and open a new cmd window, call vcvarsamd64.bat, then run setup.py and see what happens
<AuroraBorealis> oh gee
<AuroraBorealis> i think its screwing up on the uf-8 bom
<AuroraBorealis> well
<AuroraBorealis> i ran it, the terminal text turned green
<AuroraBorealis> and now its compiling
<wgz> heh, that's possible
<AuroraBorealis> it said <randomgibberish>call is not a windows batch file/command
<wgz> yeah, that's an annoying way to have got stuck :)
<AuroraBorealis> so when i install this
<AuroraBorealis> will it always use this version of bzr lib? or will running the exe from the windows installer override it
<wgz> it won't interfere with the exe version
<AuroraBorealis> k
<AuroraBorealis> Well. now that installed
<AuroraBorealis> i forget what else i need to do
<wgz> lp:meliae lp:python-fastimport lp:bzr-fastimport
<wgz> I recommend testing the bzr you've just installed, should be able to run it with Python27\Scripts\bzr.bat
<AuroraBorealis> seems to of worked!
<wgz> good good!
<AuroraBorealis> ok
<AuroraBorealis> all 3 installed
<AuroraBorealis> now what!
<wgz> well, it would be nice to test that the memory dumping worked but...
<wgz> could just start the import
<AuroraBorealis> start it again from the beginning?
<wgz> `Scripts\bzr fast-import ..\tmp_linux\linux.fe \bzr-import` or similar
<wgz> hm.
<AuroraBorealis> cause i can't seem to continue cause of another bug
<wgz> yeah
<wgz> you could try repacking the failed import for a faster big-memory usage
<wgz> but with 64 bit process you probably won't OOM now anyway
<AuroraBorealis> is there a command to repack?
<wgz> `bzr pack`
<wgz> ...it took me way too long to find that, I fail at name guessing/remembering
<wgz> you can look the windows task manager for ball park memory usage numbers
<AuroraBorealis> yeah i'm watching it
<AuroraBorealis> 280,000 KB
<lifeless> wgz: have you installed bzr guess ?
<wgz> the -Dmem_dump option is needed to write the stats on OOM, but that probably won't happen now so breakin and calling bzrlib.trace._dump_memory_usage directly is probably more useful anyway
<wgz> lifeless: nope
<lifeless> wgz: give it a spin :)
<lifeless> $ bzr repack
<lifeless> Command 'repack' not found, perhaps you meant 'pack'? [y/n]:
<AuroraBorealis> will it dump the memory automatically using meliae or do i have to do the -Dmem_dump thing
<wgz> ha, and I was just about to doubt that it'd know to remove the 're' prefix
<wgz> I should have more trust in lifeless.
<lifeless> wgz: it uses a distance calculation :)
<lifeless> wgz: $ bzr pdck
<lifeless> Command 'pdck' not found, perhaps you meant 'pack'? [y/n]:
<wgz> ^It will only auto dump if you OOM, which with a 64-bit process and 8 gigs probably isn't going to happen
<wgz> (and needs the flag)
<AuroraBorealis> k
<wgz> but with ctrl+break then a bit of typing in the debugger we can get what we want anyway
<AuroraBorealis> so this seems like its going to work, although its using 600,000KB atm hehe
<AuroraBorealis> 64 bit is a lost faster o.o
<AuroraBorealis> lot*
<wgz> scusi, just going to pick apples, but I'll be around - try the import from the beginning if that works
<AuroraBorealis> kk =)
<wgz> okay. how high did the repack get up to on its own?
<AuroraBorealis> well
<AuroraBorealis> its currently repacking "chk:chk node 861000/987188"
<wgz> that's good, and what's the mem usage?
<AuroraBorealis> right now 650,000 KB
<AuroraBorealis> highest was around 850,000 KB
<wgz> ha, so it has stabilised.
<AuroraBorealis> it jumped up a lot when it started doing the chk: index/nodes and whatever
<wgz> so, if you want to try something
<wgz> do ctrl+break in the terminal
<AuroraBorealis> the pause|break button?
<wgz> yup.
<wgz> this should then put you in the python debugger
<wgz> then you can do...
<wgz> pdb> from bzrlib.trace import _dump_memory_usage
<wgz> pdb> import sys
<wgz> pdb> _dump_memory_usage(sys.stderr)
<wgz> and finally to resume,
<wgz> pdb> c
<AuroraBorealis> well that crashed it
<wgz> paste me the output?
<AuroraBorealis> didn't give any output
<AuroraBorealis> just said "python27_64.exe has stopped working"
<wgz> ah, msgbox from windows?
<AuroraBorealis> yeah
<wgz> at which point?
<AuroraBorealis> there are the windows dump files
<AuroraBorealis> _dump_memory_usage(sys.stderr)
<wgz> okay... meliae apparently has issues on win64 then >_<
<AuroraBorealis> gahhhhh
<wgz> if you could file a bug against and stick the stuff windows gave you as an attachment, that would be great
<wgz> the good news is that using 64-bit process looks like it'll let the fast-import succeed
<AuroraBorealis> yeah
<AuroraBorealis> but running out of memory on 32 bit still seems like a problem
<wgz> yup, and the usage of both fast-import and repacking seem to both be problematic
<AuroraBorealis> yes
<AuroraBorealis> i restarted it again, using 600,000 at stage 2 so yeah.
<AuroraBorealis> so file a bug against meliae?
<wgz> right.
<wgz> you could also run it's testsuite to see if that crashes (and can then be narrowed down to one test)
<wgz> can do that with... `cd meliae` `Python27\python setup.py build_ext -i` `Python27\python -m unittest meliae.tests.test_suite`
<wgz> just use a new window, no need to interrupt the repack
<wgz> ...I get two failures, but they look shallow
<AuroraBorealis> haha
<AuroraBorealis> the unit tests crash.
<wgz> that's good.
<AuroraBorealis> what debugs the debugger?
<AuroraBorealis> WATCHMENNNNNNN
<wgz> you can now try smaller subsets till you find one test that does it
<AuroraBorealis> how do i run the individual tests? replace the meliae.tests.test.suite with the individual files?
<wgz> start with meliae.tests.test_scanner
<AuroraBorealis> crash :<
<wgz> and then you can narrow further with the classes in that file, then the methods
<AuroraBorealis> i found the names i'll run em all
<AuroraBorealis> is it because i'm not running cmd.exe in administrator mode?
<wgz> it's likely one (or more) type errors where the extension code is assuming sizeof(int) == sizeof(*ptr)
<AuroraBorealis> test__intset works, test__loader works, test__scanner crashes, test_loader crashes, test_perf_counter works, test_scanner crashes
<wgz> which is true for win32 and the 64-bit scheme used on nix
<AuroraBorealis> ah :3
<wgz> anyway, you've got enough to file a bug now
<AuroraBorealis> yeah
<wgz> there should be a way to get debugging symbols for a proper C stack trace, but I've not done it with cython before
<AuroraBorealis> doing that now
<AuroraBorealis> i have no idea either xD
<AuroraBorealis> https://bugs.launchpad.net/meliae/+bug/864593
<ubot5> Ubuntu bug 864593 in Meliae "Crashes on win64 when running test suite" [Undecided,New]
<AuroraBorealis> another note, bzr is using over 1,200,000 KB when repacking now o.o
<wgz> hm.
<AuroraBorealis> i'll just let it run. never debugged python stuff this indepth before ..
<wgz> can you run another smaller chunk of the meliae test suite? start with meliae.tests.test__scanner.TestSizeOf
<wgz> if that still crashes, add .test_None
<AuroraBorealis> that didn't crash, 3 tests failed
<wgz> okay, that's what I was hoping for
<wgz> failing tests on the sizeof things implies logic errors, that could cause crashes in bigger chunks of code
<wgz> stick those three failed tests output in a comment on the bug
<AuroraBorealis> it seems that they are always off by 4
<wgz> yeay! alignment.
<AuroraBorealis> 37 != 33, 102437 != 102433, 38!=34
<wgz> paste them in the bug report and I'll have a look
<AuroraBorealis> posted!
<wgz> hm, just strings, probably just the 2.7 check above not taking alignment into account rather than something more fundamental.
<AuroraBorealis> aww
<wgz> try each of the other classes in that file in turn
<AuroraBorealis> TestDumpInfo crashes python
<AuroraBorealis> all others pass
<wgz> okay, that's good, gives us a narrowed scope.
<wgz> not much, but a bit.
<wgz> this pyrex `    ctypedef long size_t
<wgz> is wrong, but probably unimportant, I'm never sure what the manual definitions actually matter for
<AuroraBorealis> can i try an individual method in a test case?
<wgz> that's in _scanner.pyx and there are some similar ones in the other pyx files, could try deleting them and recompiling, I'll keep looking
<wgz> ^yup, just .method_name on the end
<wgz> in the TestDumpInfo case they all call the same helper which goes to dump_object_info so should all crash
<AuroraBorealis> yeah they all crash
<wgz> ...this could be something as silly as the IO failing
<AuroraBorealis> oh? :o
<wgz> have you tried deleting those size_t defs yet?
<AuroraBorealis> in __scanner.py and then recompiling?
<wgz> yup, then run one of the TestDumpInfo cases again
<AuroraBorealis> what do i delete? these? size_of = _scanner.size_of
<AuroraBorealis> oh
<AuroraBorealis> nvm haha
<wgz> nope, just the ctypedef at the top.
<wgz> long is 4 bytes on win64, and size_t is 8 bytes
<wgz> I think cython should ignore that decl and use the right thing, but you never know
<AuroraBorealis> sorry i suck at c, what do i delete? lots of size_t things
<wgz> just the one line at the top of _scanner.pyx "ctypedef long size_t"
<AuroraBorealis> oohhh the pyx file
<wgz> hm, yeah, that shouldn't matter I think.
<AuroraBorealis> yeah, still crashes
<wgz> okay, let's eliminate the possibility of it being the io
<wgz> okay, I've added a test to TestDumpInfo that does a bit less
<wgz> http://paste.ubuntu.com/701020/
<wgz> then run with meliae.tests.test__scanner.TestDumpInfo.test_int_no_file and it passes here
<wgz> I'm interested if that simplified version still crashes for you.
<wgz> ugh, tabs, <http://paste.ubuntu.com/701022/>
<AuroraBorealis> i dont need to recompile right
<AuroraBorealis> and that test passed
<wgz> eh he he.
<wgz> it printed my two little notes as well, right?
<AuroraBorealis> yeah
<wgz> now change recurse_depth=0 from 0 to 1 and try again.
<AuroraBorealis> printed a period too
<AuroraBorealis> that works as well
<wgz> okay, change that back, and change `sio.write` to `file("nul", "wb")`
<wgz> which, if the IO is indeed the problem, will crash.
<AuroraBorealis> yeeeup. crashes.
<wgz> so, either meliae and python are linked against different runtime libraries, or there's a bug
 * AuroraBorealis whimpers at the fact of runtime libraries not working :<<
<wgz> okay, so, nothing's jumping out at me, and I need some lunch
<AuroraBorealis> haha
<AuroraBorealis> take your time, its 6 am here so i probably should go to bed sometime.
<wgz> but there are two things I can think of that would help (bar getting a stacktrace... which may have actually been just as easy)
<wgz> one is to use dumpbin.exe to look at python27.dll and _scanner.pyd to see if they're importing from the same runtime
<wgz> the other is to try commenting/printing in _scanner.pyx to narrow down exactly what crashes, using our minimal test
<AuroraBorealis> what is dumpbin.exe?
<wgz> it just lists symbols in the exe/library, either msvc or the win7 thing should have come with it
<wgz> on the trial and error front, for starts
<wgz> in dump_object_info comment the _dump_object_info calls so just the fflush happens, and see if there's still a crash
<wgz> remember to rerun `setup.py build_ext -i` each time after changing a pyx file
<wgz> if that works, can just commenting the fwrite call in _file_io_callback
<AuroraBorealis> which test do i run, yours?
<AuroraBorealis> running your test again and commenting out the _dump_object_info it still crashes
<wgz> heh, that does seem just like mismatched FILE* then
<wgz> how did the install get that wrong...
<wgz> so, possible workaround for now
<wgz> <http://paste.ubuntu.com/701043/>
<AuroraBorealis> doesn't crash, i get this: http://paste.ubuntu.com/701045/
<wgz> cool, now run the rest of those tests
<wgz> (that one fails because we were just discarding the output as what we cared about was if the IO crashed)
<AuroraBorealis> i get all the failures i was getting before, yours and then TestMemObj and TestObjManager failing
<AuroraBorealis> http://paste.ubuntu.com/701050/
<wgz> okay, so reverting everything but the workaround should mean you have a functional meliae to install and use on bzr
<wgz> can do `bzr shelve -destroy` to get rid of the other changes
<wgz> *--destroy
<AuroraBorealis> i was just downloading the tarballs cause launchpad is still not accepting my ssh key for some reason =/
<wgz> ha, well, I think we didn't change anything else important so go ahead and install
<AuroraBorealis> yeah
<AuroraBorealis> just restored the tarballs copy and redid the change
<AuroraBorealis> you should probably post that workaround to the bug report as i have no idea what that did xD
<wgz> I'll do it
<wgz> okay, so as a test, start a repack, then do the ctrl+break and my instructions from earlier before we got side-tracked, you should get a .json dump of where the memory usage is
<AuroraBorealis> ok
<AuroraBorealis> so, where is it dumping the json
<wgz> it should tell you, but in %TMP% basically
<AuroraBorealis> k. still dumping xD
<wgz> whereever the tempfile module creates things
<AuroraBorealis> well
<AuroraBorealis> the json file is 4 gb
<AuroraBorealis> and cannot be opened by my text editor
<wgz> that's not overly suprising.
<AuroraBorealis> do you think paste.ubuntu.com would be mad if i pasted it there? =P
<wgz> ehehe
<wgz> the strip_duplicates.py script may reduce it somewhat, and 7z or bzip2 should compress it quite well
<AuroraBorealis> yeah
<AuroraBorealis> trying with 7z
<AuroraBorealis> oh yeah. compression on text files is sexy
<wgz> <http://jam-bazaar.blogspot.com/2010/08/step-by-step-meliae.html> gives some ideas of what you can do with the dump
<wgz> the summary should be pastebinable at least :)
<AuroraBorealis> yeah
<AuroraBorealis> loading~
<AuroraBorealis> omgggggg
<AuroraBorealis> it failed x.x
<AuroraBorealis> 'address <number here> not present"
 * AuroraBorealis tries the dump again
<wgz> any luck second time?
<AuroraBorealis> stillll dumping
<AuroraBorealis> keeps saying an address is not present =/
<wgz> how frustrating.
<AuroraBorealis> yeah D:
<AuroraBorealis> no idea whats going on now...
<wgz> try with a much smaller bzr process first, so at least you can then send me the dump and it won't take as long to retry?
<AuroraBorealis> k
<wgz> eg, `bzr info` and interrupt if (if you're fast enough)
<wgz> there are still some casts in the meliae source I don't like but the problem might be elsewhere
<AuroraBorealis> www.kramidnarg.com/stuff/bzr_memdumptn8bb_.7z
<AuroraBorealis> that still gives the same error if i try to laod it
<wgz> okay, I get the KeyError too.
<AuroraBorealis> k
<AuroraBorealis> i'm probably going to go to bed now
<AuroraBorealis> when i get up i guess we can figure out why its not loading the dumps :<
<wgz> looks like there are some refs that aren't in the dump, probably doesn't need to be a fatal error
<wgz> sleep well!
<wgz> don't dream of running out of memory.
<AuroraBorealis> =P
<Enma_Hinobara> I have a quick question about something really trivial that is disproportionately hard to figure out how to do in Bazaar.
<Enma_Hinobara> I have a directory containing a program, and I want to import it into Bazaar. However, I don't want to make said directory a branch (easy), I want the branch to be in a shared repository (already created) and the original directory become a working tree for that branch. How might this be done?
#bzr 2012-09-24
<_kbulgrien> Ok, distributed newb here.  I have a distibuted setup and have pushed/pulled as needed to take a mod from a subordinate branch up to the parent branch.  bzr status shows nothing.  I expected it to show I needed an update.  bzr update got the change.  What should have I done to see that an update was required?
<bob2> missing
<bob2> you're pushing commits around
<_kbulgrien> Thanks.  I guess I read `bzr help missing` bzr missing [OTHER_BRANCH] as indicating a branch other than the one I am checked out from... hmm...
<_kbulgrien> So if I pulled or pushed something into my checked out branch, I would not expect, from help, to need `bzr missing`.
<bob2> well
<bob2> it depends what 'checked out' means
<fullermd> In a light checkout, I believe status tells you when the branch has moved ahead.  In a heavy it won't because that would require connecting up to the remote branch every time, and avoiding that sort of stuff is why you have heavy in the first place.
<bob2> if it's a bound branch/lightweight checkout, be super careful
 * _kbulgrien has forgotten how to tell if a co is lightweight or not
<fullermd> If you didn't explicitly make a light one, it's heavy.
<lifeless> bzr info
<lifeless> if it says 'checkout of' its heavy.
<_kbulgrien> bzr info -v doesn't seem to make it clear.   (Yeah, I forgot if I did --lightweight or not)
<lifeless> paste the output ?
<_kbulgrien> ok. gotcha.  heavy.
<_kbulgrien> ok, I  can see the heavy/light thing.  Will just need to try to assimilate this mentality.  Am used to non-distributed where getting a status tells you everything.
<_kbulgrien> well, successful night then... finally got bzr working to help keep a web host and a local test server tied together via version control so I can develop and push up, etc. to roll out changes.
<lifeless> cool
<_kbulgrien> So now I have something real to practice with.
<_kbulgrien> I sure appreciate irc folks helping here and there to make it happen.  I think I shall call it an evening.  BBL
<bob2> bound branches:(
<mgz> hey
 * SamB_MacG5 wonders why bzr-svn has to fetch so much revision info in order to grab -rsvn:1
<flea> Hi, I wish to convert a current/live working directory into a bzr-controlled branch
<flea> i'm a bit confused about the paths involved compared to when starting a repo from fresh
<SamB_MacG5> anyone know jelmer's preferred TAB width?
<SamB_MacG5> oh, it looks like the number I was looking for was "3"
<SamB_MacG5> hmm, no, wait...
<jelmer> SamB_MacG5: ideally, tabs in the C code, 4 spaces for python code
<jelmer> SamB_MacG5: though subvertpy isn't sticking to that everywhere in the C code I think
<SamB_MacG5> yeah, I hit a place where it doesn't line up without setting `tab-width' to 3
<SamB_MacG5> obviously I didn't mean for the Python code
<jelmer> SamB_MacG5: where is that?
<SamB_MacG5> jelmer: adm_add() in wc.c
<jelmer> SamB_MacG5: that's got all tabs here
<SamB_MacG5> maybe I'm pulling from the wrong branch...
<jelmer> SamB_MacG5: http://people.samba.org/bzr/jelmer/subvertpy/trunk/ ?
 * SamB_MacG5 was lazy and used lp:subvertpy
<SamB_MacG5> hrmm
<SamB_MacG5> no new revisions
<SamB_MacG5> what the heck, trying to pull from the https: version dies on me ...
 * SamB_MacG5 blames Subversion
<SamB_MacG5> or not, the traceback was from the middle of the smart protocol code :-(
<SamB_MacG5> jelmer: check the line after this again:
<SamB_MacG5> RUN_SVN_WITH_POOL(temp_pool, svn_wc_add2(
<jelmer> SamB_MacG5: right, so there is one misalignment.
<SamB_MacG5> but, don't fix it now, because it'll conflict with what I'm working on ;-)
<SamB_MacG5> sweet, it built
 * SamB_MacG5 looks into the __future__ to figure out how to make the test suite run ..
<lifeless> SamB_MacG5: which test suite ?
<SamB_MacG5> lifeless: subvertpy's
<SamB_MacG5> darn, now it's segfaulting :-(
<lifeless> Possibly make check
<lifeless> or setup.py test
<lifeless> failing that read the README :)
<SamB_MacG5> lifeless: that's what's segfaulting ;-)
<SamB_MacG5> (no, not the README ;-)
<lifeless> jelmer may be around, he's in the US atm - jelmer: ^
 * jelmer waves
 * SamB_MacG5 is trying make gdb-check right now
<lifeless> jelmer: oh hai
 * SamB_MacG5 wishes Apple had provided debugging symbols for Python
<jelmer> hey lifeless:-)
<lifeless> jelmer: any thoughts on SamB_MacG5's subverypy segfaults ?
<lifeless> jelmer: also, have fun and sambacamp :)
<lifeless> s/and/at/
 * SamB_MacG5 tries to puzzle out how to get a Python traceback without any debug symbols ...
<SamB_MacG5> oh, whoopsie ...
 * SamB_MacG5 discovers com.mygreatcompany.pkg.python-fastimport in his receipt database
<delinquentme> ok so I've got this dir:  BETY  ... and all of my project files within the BETY folder.  I would like to relocate all of the working files into BETY/trunk  .. .so that I might make another branch ( which contains a bunch of redesign stuff ) in BETY/redesign
<delinquentme> right now I've attempted to move all the files from BETY/* to BETY/trunk/* .. but I get complaints in bzr
<lifeless> delinquentme: what complains
<SamB_MacG5> delinquentme: tried moving also BETY/.* to BETY/trunk/.* ?
<delinquentme> well as far as bzr status is concerned ... every file was removed
<delinquentme> and then I've just got an Unknown:  trunk/
<delinquentme> NM!
<delinquentme> for some reason the mv * didnt copy the bzr files
<lifeless> well
<delinquentme> niiice
<lifeless> the problem is that trunk is part of BETY/*
<lifeless> so I think you need to be more specific
<lifeless> starting from scratch
<lifeless> assuming BETY is the root of your branch
<lifeless> bzr mkdir trunk
<SamB_MacG5> lifeless: what?
<SamB_MacG5> why would he want to add a directory called trunk to the branch, exactly?
<lifeless> SamB_MacG5: thats the scenario given
<SamB_MacG5> lifeless: I'm pretty sure he wants that to *be* a branch
<lifeless> delinquentme: then bzr mv <file> trunk/ - don't use *, because it will pic up trunk as well
<lifeless> SamB_MacG5: for that, he needs to move them and then use bzr split
<lifeless> delinquentme: is BETY the root of a branch, or just a container that contains multiple branches ?
 * SamB_MacG5 is pretty sure that delinquentme was just not expecting * not to match names with leading .s
<delinquentme> yeah :D
<SamB_MacG5> jelmer: so, when you "fix compatability with svn 1.4", do you remember to actually run the test suite?
<delinquentme> what SamB_MacG5 said
<jelmer> SamB_MacG5: it's been a long time since I've run with 1.4 myself
<delinquentme> is trunk a bad name for the local version of master branch?
<SamB_MacG5> well, I think this segfault is beyond me :-(
<delinquentme> and pushing my newly branched "redesign" dir up onto the primary repo?
<delinquentme> can I just do bzr push :parent  and have it make the redesign branch on the remote / primary repo?
<SamB_MacG5> jelmer: could you try running the tests against https://code.launchpad.net/~naesten/subvertpy/1050949-svn-1.4-compat ?
<SamB_MacG5> delinquentme: probably not ?
<SamB_MacG5> delinquentme: try "bzr config" to see
<delinquentme> bzr: ERROR: unknown command "config"
<SamB_MacG5> huh
<SamB_MacG5> works on Bzr 2.3!
<delinquentme> 2.1.4
<delinquentme> ahhhh
<SamB_MacG5> wow that's old
<SamB_MacG5> and I thought I was behind
<jelmer> SamB_MacG5: trying
<SamB_MacG5> test_committed_queue (subvertpy.tests.test_wc.AdmTests) ...
<SamB_MacG5> Program received signal EXC_BAD_ACCESS, Could not access memory.
 * SamB_MacG5 gets that when he runs "make gdb-check TEST_OPTIONS=-v"
<delinquentme> umm was there a way to add just specific files for a commit?
<delinquentme> I know how to add just one file to a commit .. what if I just want to pick out 10 files ?
<lifeless> bzr commit filename
<delinquentme> lifeless, yeah i mean how can I add only a selected number of files
<delinquentme> SamB_MacG5, I think I asked about this before .. but the adding multiple files .. but not all files to a commit?
<delinquentme> or say .. how to add multiple files and stage them to be comitted
<lifeless> delinquentme: there is no staging area in bzr
<lifeless> delinquentme: bzr commit file1 file2 file3 etc
<mark06> hi all, is it possible to overwrite committer in commit log for adding email info (that is, apply bzr whoami "Name <email>" to all places where bzr whoami "Name" has been used)
<lifeless> there is a bzr rewrite patch in the bug tracker somewhere
<lifeless> IIRC jelmer rejected it as not being a common enough use case :)
<delinquentme> lifeless, can I add all files within a dir?
<delinquentme> say $ bzr commit -m "testing" dir1/*  dir5/* dir7/file.txt
<lifeless> bzr commit -m testing dir1 dir5 dir7/file.txt
<delinquentme> to add everything in dir1 and dir5 .. as well as file.txt
<lifeless> bzr add says *track these files for changes*
<delinquentme> thanks!
<lifeless> bzr commit says *commit everything*
<lifeless> bzr commit path1 path2... pathN
<mark06> some decisions may be painful in future, I should have set an email since beginning, I used to think that was privacy, now I think that was paranoia
<lifeless> says commit anything in these paths (that is already tracked)
<delinquentme> lifeless, so if I havn't added a file yet IE it comes up under "unknown" on a bzr status
<lifeless> right
<delinquentme> those files wont be committed ?
<lifeless> right
<delinquentme> ah ok ok
<lifeless> have you gone through the tutorial ?
<delinquentme> yeah I just get wonked up on some of the difference between this and git
<delinquentme> what about something akin to git commit --amend
<delinquentme> like if I want to add new information to a previous commit ( one which I only have locally )
<lifeless> bzr uncommit; bzr commit
<mark06> --amend? ugh. So lifeless, if I ever find that bug, I would need to patch bzr myself, right? (and also, change the patch as it's likely outdated)
<lifeless> mark06: bzr-rewrite is a plugin
<lifeless> mark06: but yes, with s/bzr/bzr-rewrite/
<mark06> ok thanks lifeless
#bzr 2012-09-25
<jelmer> SamB_MacG5: sorry, I can't test at the moment
<SamB_MacG5> oh well :-(
<jelmer> SamB_MacG5: libsvn-dev conflicts with heimdal so I can't build subvertpy
 * SamB_MacG5 installs a thing
<jelmer> SamB_MacG5: ask me again next week when I don't need this Kerberos stuff as badly :)
<SamB_MacG5> this is NT's fault, isn't it?
<jelmer> it's libpq-dev's fault for depending on krb5-dev
 * SamB_MacG5 doesn't get why libapr depends on so much stuff either ...
 * SamB_MacG5 *poof*
<mark06> anyone knows which bug is the one mentioned above about adding email change to bzr-rewrite? I have searched for email and mail but can't find any http://bit.ly/PTiVqw
<mark06> wouldn't sed work over .bzr for replacing committer field if we ever get a way to uncompress the relevant files?
<bob2> not really
<lifeless> mark06: in principle yes, but for referential integrity you need to change the revids too
<mark06> referential integrity like in relational databases?
<mark06> or are revids some sort of hash out of commit data?
<lifeless> they are guids
<mgz> morning!
<trkv> Hi all. Whom can I ping to review my little merge-request? :) It has "pending" status for 2 months already.
<mgz> here is good.
<trkv> okay, it's https://code.launchpad.net/~torkvemada/bzr/commit_hooks/+merge/115348
<mgz> I think yours is the one I pass... right
<mgz> I skipped that in my last big review-all-pending-branches sweep
<mgz> the main reason being there's been a bunch of discussion about where to put commit hooks before that I wanted to dig up, and your proposal didn't include examples of how you intended to use these new ones to quickly compare about
<mgz> but, as concrete things you can do to get this landing, adding some tests would be the main thing
<trkv> mgz: I've already pointed in this very conference, what I added it for (it was 2 months ago, yes :) )
<trkv> just a little link: http://bazaar.launchpad.net/~torkvemada/+junk/bzr-cimage/view/head:/__init__.py
<mgz> referencing that stuff in the merge proposal is the kind of thing that helps the reviewer
<trkv> ok, I'll add the reference
<trkv> could you point out the place in sources, where I should add the tests?
<trkv> I'm not familiar with bzr sources
<mgz> only seeing https://lists.ubuntu.com/archives/bazaar/2012q2/074812.html on cursory mailing list search for similar questions...
<mgz> trkv: I'll try and find some earlier hook addition proposals for you for reference
<mgz> trkv: see the following mps for some hints
<mgz> <https://code.launchpad.net/~jelmer/bzr/transform-hooks/+merge/89007>
<mgz> <https://code.launchpad.net/~jelmer/bzr/pre_post_command_hooks/+merge/87254>
<trkv> ok, thanks, I'll look at it
<tictacbum> Hello, I'm new to bzr, but I usually use git, there's an equivalent command to "git remote add ..." ?
<fullermd> Well, since there's not an equivalent to git remote's...   8-}
<fullermd> What larger task are you trying to accomplish?
<tictacbum> but I can have different origins in bzr?
<tictacbum> I want to pull from a public repositroy, make changes and commit them  to a private one
<tictacbum> then pull from public again...
<fullermd> Mmph, I have a feeling terminological differences are going to bite us here...
<tictacbum> :)
<fullermd> But pull and push (and merge, which you probably want in the mix here) use different saved locations.
<tictacbum> what do you mean with saved locations?
<fullermd> Where 'bzr push' pushes to if you don't give it a URL on the command line.
<fullermd> (ditto pull pulling from and merge merging from)
<tictacbum> ah ok, it is the last one used no?
<fullermd> First one used, actually.  If there's no saved location, the first run saves what you set.
<fullermd> Future explicit locations aren't saved unless you use --remember.
<tictacbum> you know where does bzr save it?
<fullermd> It's in the branch config.  You can see the list in 'info'.
<fullermd> And some other config-related command that vila will remind me of at some point.
<vila> fullermd: bare 'bzr config'
<fullermd> Not in public!
<tictacbum> thanks, will try to understand better the concepts now
<fullermd> tictacbum: The main concept to keep in mind is the branch-centric as opposed to repo-centric worldview.  You'll confuse yourself into knots if you try thinking the wrong way (about either system)
<fullermd> (and the somewhat different usages of 'repo' and so forth, but that's second tier)
<tictacbum> fullermd: thanks :)
<fullermd> tictacbum: http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief  may be helpful.  With a fair amount of existing DVCS experience, it may seem a little elementary, but it's still worth a careful read to catch differences in the worldview.
<fullermd> Also the PiecesInLength sibling has bits that may help, especially some of the stuff at the end comparing terminology among different DVCSen.
<fullermd> Which is probably not completely accurate, but the author's always a bit sloppy about stuff.  It's mostly right, anyway.
<mgz> the author is sloppy about kisses?
<fullermd> Hey, some people are into that sort of thing!
<fullermd> (obviously not MANY, or he wouldn't have time to write about version control, but still)
<tictacbum> fullermd: great article, thanks to the author if you see
<fullermd> Well, I try to avoid him, but it's probably unavoidable to run into him sooner or later.
<tbf> after merge: how do i see what commit deleted a file?
<tbf> need to know whom to kick
<fullermd> Through the UI, you're pretty much limited to doing a log -v and /-ing through it.
<tictacbum> back to my qÃ¼estion, can a project have more than one repository?
<tictacbum> I tried to push and pull with repo after the command, and ended with a diverged branch
<LeoNerd> Crazy request:  bzr shelve;  bzr unshelve-on-another-machine ssh://...
<vila> LeoNerd: bzr commit; bzr push; bzr uncommit * 2
<LeoNerd> *twitch*
<vila> LeoNerd: do you prefer 'scp .bzr/checkout/shelf/<n> another-machine/..../.bzr/checkout/shelf/<omg-hope-it-doesnt-exist>
<LeoNerd> I'd prefer theabove :P
<LeoNerd> But it doesn't exist.. so never mind
<cmars232> hi, is there a UI for bzr like gitk?
<cmars232> i want to see branch ancestry, see where merges have happened, where branches diverge, which one is missing a commit, etc
<vila> cmars232: qlog from the qbzr plugin
<cmars232> vila: thx, checking it out
<cmars232> vila: qlog is exactly what I needed, thanks
<vila> cmars232: make sure to not miss the ability to run it with multiple branches
<matsubara> Hi there, I'm getting an error very similar to https://bugs.launchpad.net/bzr/+bug/819604 but that's fix released for awhile now and I'm using 2.5.1. I'm running tarmac and while it runs the pre-commit hook, bzr keeps the ssh connection open to the branch but when the tests are over and tarmac resumes, I get the broken pipe error. Any way to workaround the issue?
<ubot5> Ubuntu bug 819604 in Bazaar 2.4 "when an idle ssh transport is interrupted, bzrlib errors; should reconnect instead" [High,In progress]
<mgz> matsubara: jam has some branches up aimed at fixing this, see the latest mp linked from that bug
<matsubara> mgz, the one superseded?
<matsubara> mgz, and is there any known workaround before this is released?
<mgz> bug 1047325 is probably the other one you're interested in
<ubot5> Launchpad bug 1047325 in Bazaar "not properly interpreting EPIPE as connection reset" [Critical,Fix released] https://launchpad.net/bugs/1047325
<mgz> basically we only got really good testing of the reconnect stuff when launchpad's copy of bzr was upgraded, so some follow on fixes were needed
<mgz> so, you can run a trunk bzr, or cherrypick that fix, or persude tarmac to discard the transport
<mgz> I'm not sure which you'll find easiest
<matsubara> hmm
<matsubara> I guess running from trunk should do
<matsubara> I'll try it and come back if it doesn't work
<mgz> or lp:bzr/2.5 trunk
<matsubara> thanks mgz !
<mgz> rather than dev
<jelmer> hey mgz, matsubara
<mgz> we'll try and get a release done when the maas stuff is less pressing
<matsubara> hi jelmer
<mgz> (which we want to bug you about doing some testing for tomorrow)
<mgz> jelmer! how's the rain?
<jelmer> mgz, absent!
<matsubara> mgz, cool. let me know
<mgz> alas.
<jelmer> mgz: how's things here?
<mgz> jelmer: bouncing along okay (and sunny)
<mgz> found any samba bugs yet?
<mgz> (I know, I know, shocking to even consider the possibility)
 * SamB_MacG5 reconfigures LimeChat to stop highlighting SamB when it occurs as part of a word
<jelmer> plenty (-:
<mgz> SamB: heh.
#bzr 2012-09-26
<poolie> jam: hi!
<poolie> vila, hi!
<vila> poolie: hey !!!
<poolie> hi there, how are you?
<poolie> i was just thinking of you the other day and thought i'd drop by
<vila> fine, fighting a cold but I'm on my way to winning ;)
<vila> hehe, good to hear, I often think about you :)
<vila> err, off you ?
<vila> argh, of you :0D
<vila> see ? still tyoping like hell :)
<mgz> morning!
<vila> mgz: hey ! look who's here :)
<poolie> hi mgz :)
<poolie> vila: see my pm?
<jam> hi poolie
<poolie> hi jam, hi mrevell
<jam> poolie: so the big question, is Google Cafeteria or Google Yoga winning ? :)
<jam> hi w7z, good to see you around today. I have an lzma stream for you :)
<poolie> haha
<poolie> it's a tough race
<poolie> you were very inspirational
<poolie> at the moment, yoga
<mrevell> Hey poolie!
<jam> poolie: thanks. ATM I'm trying to figure out how I managed to avoid eating 1000 calories every day for 6mo (loosing 1KG/week)
<jam> I now eat what I'm supposed to, and I feel hungry...
<pabs3> is there any command I can run to tell me if there is anything I need to get merged upstream
<fullermd> missing
<pabs3> fullermd: that seems to touch the network, can I avoid that?
<mgz> seems like in bzr 2.6 authentication.conf is not auto generated from an existing bazaar.conf, vila is that a deliberate change?
<mgz> it used to be that if bazaar.conf existed with a launchpad_username set, first run of bzr needing auth would do "Setting ssh/sftp usernames for launchpad.net"
<vila> mgz: auth.conf has never been auto generated AFAIK
<mgz> but that scenario just resulted in `bzr pull` failing, until I ran (no arguments) `bzr launchpad-login` which then did it
<vila> I have never heard about this scenario you describe and I'm pretty sure auth.conf is created in a very ad-hoc way by bzr-login
<mgz> aa, or maybe that's always required, but I'm used to having it as a side effect...
<vila> sounds like missing tests to me :)
<mgz> I'll investigate and file a bug if needed :)
<anant> On running "bzr branch lp:nux", I get the error message "Permission denied (publickey). ConnectionReset reading response for 'BzrDir.open_2.1'"
<mgz> anant: you need to set your ssh key up with launchpad correctly.
<anant> mgz: I already did that. :( .. Is there a way to verify it was set up correctly?
<mgz> anant: try `ssh -vv bazaar.launchpad.net` which should give more info on the failure
<anant> mgz: From the output of the command you gave, "No such Launchpad account: asogani" caught my eye. I then did `ssh -vv <my-launch-pad-id>@bazaar ..` and it worked
<anant> turns out that my ssh id_rsa.pub has listed "asogani@ubuntu" .. since that's the username on my laptop
<mgz> okay, so you want to do `bzr launchpad-login <your-launchpad-id>` I suspect
<anant> strange, that's already there ... asogani@ubuntu:~/src$ "bzr launchpad-login" gave anant-sogani as output
<mgz> check you authentication.conf as well, see `bzr version` for where that is
<anant> shows up the right values ... anyways 'bzr branch ...' commands have started working :)
<anant> thanks a lot mgz!
<mgz> anant: ace. :)
<mgz> ha, just realised what that bug was earlier
<mgz> bazaar.conf exists with launchpad_username set, authentication.conf does not exist
<mgz> operations on bzr+ssh: fail... operations on lp: create authentication.conf and succeed
<mgz> so, pull on a fresh machine blew up because we store urls resolved, which doesn't trigger the launchpad plugin magic
<LarstiQ> mgz: oooh that is a pet peeve of mine
<anant> mgz: wow :)
#bzr 2012-09-27
<lifeless> vila: could you pqm-submit the env-variable branch for me? I've let my pqm-submit setup bitrot...
<vila> lifeless: done
<lduros> hi, for some reason I can never find in the docs the part that talks about what OTHER, THIS, BASE, and diff files represent when there's a conflict
<lduros> can anyone point me towards the documentation for this?
<lduros> Thanks,
<lduros> hmm I guess this works: http://doc.bazaar.canonical.com/beta/en/user-guide/resolving_conflicts.html
<lduros> not so much
<lduros> haha
<bob2> OTHER is the other branch
<bob2> THIS is your branch
<bob2> BASE is their common ancestor
<bob2> it's a regular diff3 thing
<lduros> bob2: so OTHER is the branch that I tried to merge into the current branch, right?
<lduros> i did: bzr merge upstream
<lduros> so OTHER is upstream, yeh ok
<mgz> just about still morning!
<lduros> bob2: thanks much
<lduros> so when I see <<<<<<< TREE what does it mean?
<bob2> that you shouldn't use bound branches
<lduros> huh?
<lduros> they are not bound
<bob2> did you have uncomited changes?
<lduros> no
<lduros> everything was fine before I did the merge
<lduros> no uncommited changes
<lduros> ah well, I just got rid of that :-)
<bob2> er
<bob2> of course you need to resolve the conflict
<lduros> right
<lduros> bob2: I have a lot of conflicts to resolve. I'm merging an upstream branch that's Firefox 15.0.1 into my 'IceCat' branch. So from one version to the other there are thousands of changes, and about 80 conflicts
<lduros> so far bzr works really well for this purpose though
<lduros> helps catch changes that you don't want applied etc, ...
<fullermd> Pretty sure 'tree' is just the normal name for the local side.
<mgrandi_> its still confusing on what file you actually edit to resolve the conflicts, or i can never figure it out
<lduros> hmm ok
<mgrandi_> in combination with random diff programs
<lduros> mgrandi_: yeh, it can get confusing, especially when you have myriads changes
<lduros> I guess it's part of the fun though! :-)
<mgrandi_> in tortoisesvn, their diff program just has a middle thing where you say 'use these changes'
<mgrandi_> can't seem to get that =/
<lduros> hmm cool
<mgz> mgrandi_: if you use a mergetool, several provide a similar interface
<mgz> but the rule for manually resolving conflicts in a plain text editor is you just use the actual file, not any of the ones with extensions
<lduros> mgz: you mean, you just "modify" the actual file? Or you only "look" at the actual file?
<fullermd> Modify.  The .WHATEVER files aren't versioned or anything, they're just droppings bzr leaves to help you if you want to use them.  Only the file itself matters.
<lduros> right
<mgriffin> is there a way with an LP project to see what size each revision was?
<mgz> what do you mean by size exactly?
<mgriffin> i was looking at a project and it has a 140M .pack file
<mgriffin> Thought might be similar to something like https://answers.launchpad.net/bzr/+question/194724
<mgz> so, I have the start of a plugin for diagnosing bloated revisions
<mgz> but it's not polished or real world exercised yet
<mgriffin> no problem. there isn't a way in LP i guess then to see what size a bzr branch lp:foo will result in?
<mgz> but feel free to try it on a local branch
<mgz> get lp:~gz/+junk/bzr-repobloat and run `bzr find-bloat`
<mgriffin> alright, will do.
<fullermd> It wouldn't be too hard to just get the size of the pack files and add 'em up.  Won't necessarily tell you how big your local branch would be, but it's probably within a factor of 2, at least on branches with reasonably long history.
<mgz> right, if you just want to know repo size sftp into launchpad and ls I guess
<fullermd> So there's at least one advantage to LP having no shared repo support  ;p
<mgz> fullermd: oh, but stacking
<mgz> that could make the adding up complicated in a hurry
<fullermd> That's what stacking is for, isn't it?
<mgz> complicating things? yes.
<fullermd> Prexactly.
<mgriffin> so just put bzr-repobloat/ (includes a setup.py) in  .bazaar/plugins/  cd .bazaar/plugins/bzr-repobloat/ and run python setup.py build_ext -i  then bzr plugins?
<mgriffin> i seem to have missed some step
<fullermd> Just call it repobloat
<mgriffin> also didnt have any luck connecting to code.launchpad.net with ftp client
<mgriffin> :/
<fullermd> sftp, not ftp
 * fullermd sharpens an extra dagger to plunge into the black burning heart of FTP.
<mgriffin> i thought sftp required auth.
<mgriffin> thanks.
<fullermd> Oh, yes.  But FTP would too, if LP supported it.
<fullermd> Unauth'd, I guess you could grab the pack names file over HTTP then do a bunch of HEAD's to get sizes.
<mgz> lp admits http/sftp/bzr+ssh only
<mgriffin> very noobish questions, thanks for the help anyway (i was putting the branch in plugins dir because i have no idea what i am doing, the plugin is listed now)
<fullermd> Putting it in there is the right thing.  's just a quirk of bzr (rather, python) and lp that you have to rename it along the way.
<mgz> mgriffin: did you get any output running that? if not, you probably want to poke the (currently magical private) variable _TOO_BIG in repobloat/commands.py
<mgriffin> mgz: actually i was getting a python traceback and kinda moved on
<mgz> mgriffin: fair enough
<mgriffin> i was just curious why lp:percona-xtrabackup/1.6 was 8.4M and lp:percona-xtrabackup/2.0 was 172M
<mgriffin> http://privatepaste.com/649985e3c9
<mgz> that does sound like the sort of thing the plugin was aimed at (find bad rev, nuke it, and make repo a reasonable size again)
<fullermd> Well, 2.0 - 1.6 is 0.4.  172:8.4 is a factor of ~20.4.  There are 2 branches, with a difference of 0.4, thus we get 20.4.  Makes perfect sense   ;p
<mgz> mgriffin: upgrading your bzr from 2.1.1 to something modern would fix that error
<mgz> I can probably support older versions easily enough though, that's a simple module rename that's failing
<bjp_> i have a branch with a revision on 9/22 and one on 9/25, when i do 'bzr revno -rdate:2012-09-24' i get  Requested revision: 'date:2012-09-24' does not exist in branch
<bjp_> shouldn't it grab the 9/25 one?
<fullermd> Oh, that leads down the rathole of "look how touchy date: is"...
<mgz> bjp_: it should really
<bjp_> :(
<bjp_> is it a bug in the version i'm using? 2.5.1
<mgz> poke fullermd more, I need to run :)
<fullermd> It's probably a bug in the sense that "this really should work".  I'm not sure it's a bug in the sense of "code not doing what it's expected to do", or in the sense of "regression from previous state".
<fullermd> date: has always been pretty finicky about how it gets interpreted.
<fullermd> (which, to be sure, shouldn't be read as praise or justification or claims that it _should_ be.  Just always has, and nobody's ever buckled down to define and fix all the edge cases)
<bjp_> seems like a pretty strait forward case imo :)
<bjp_> according to bzr help anyway
<fullermd> Famous last words   8-}
<mgriffin> 2.1.1 is what ships with RHEL6 :/
<bjp_> "Matches the first entry after a given date" :)
<fullermd> mgriffin: Well, RHEL6 2010-11-10, for bzr 2.1.1 from 2010-03-24 isn't entirely insensible (though 2.1.3 was out before then, and there's another 2.1 release after that).  Still, a long time ago in bzr terms...
<ScottK> jelmer: Looks like some bzr packages are in need of love in Quantal: http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20120922-quantal.html#bzr
<jelmer> ScottK: Andrew S-B was looking into those
<ScottK> OK.  Wanted to make sure someone bzr'ish was aware.
#bzr 2012-09-28
<mgz> morning
<SamB_MacG5> can someone please review https://code.launchpad.net/~naesten/bzr-bisect/683822-bisect-start-range-argument/+merge/124565 ?
#bzr 2012-09-29
<CarstenG> Hi at all.
<trashbird1240> hi
<trashbird1240> I'm getting "bzr: out of memory"
<trashbird1240> I've narrowed it down to one particular revision
<trashbird1240> this is during a pull over the network
#bzr 2012-09-30
<exarkun> How do I see what branch has been merged (not commited) into a working copy?
<fullermd> As in the URL?  Don't think it's stored anywhere.
<exarkun> How about the branch alias?
<exarkun> Anything that might identify what was merged
<w7z> the branch alias is available, but not printed by `bzr st` (just the commiter and date of the tip)
<exarkun> The information is available after I commit from the log, since the merged revisions have a branch alias that "bzr log" will show.  But before committing?
<fullermd> Well, the WT knows the head rev that was merged, and you could dig it up from that.
<fullermd> Don't think there's anything in the standard UI that shows you it though.
<fullermd> I have vague memories that qbzr does though.
<w7z> however, merge sets the submit branch if it wasn't there before, which includes the link
<w7z> so `bzr info` may tell you in some cases
<exarkun> oh, so that's why I have some silly random submit submit branch for most of my trunk working copies
<fullermd> Well, that's really only good for running through your memory and saying "was it this", since you have no way of knowing when it was set etc.
<w7z> I think qlog does show pending merges
<fullermd> 'd be better off looking at your shell history.
<exarkun> fullermd: I think I'd be better off if "bzr st" showed what was merged. :/
<fullermd> Well, it does, but it doesn't show you the revid, so you can't get at more than it shows easily.
<w7z> ...don't leave before I can bug you into filing a bug.. >_<
<fullermd> I think I may have filed on a while back asking for --show-ids on stat to show the revids.
<w7z> found that one, but it's not really the same?
<fullermd> I know I grumbled about it years back...
<w7z> it could just be used to discover the info another way
<w7z> bug 355649
<ubot5> Launchpad bug 355649 in Bazaar "bzr status --show-ids does not show revision ids of pending merges" [Wishlist,Confirmed] https://launchpad.net/bugs/355649
<w7z> really, log needs to grow a way to show pending merges
<fullermd> I don't think it would be too hard in theory to make a revspec for the second parent of the WT.
<fullermd> But there are a lot of nasty details.  Like, what if there are multiple, and even with that, the log would go backward forever unless the user went through extra hoops to find the first bit in that history that isn't already in the branch, and...
<w7z> workaround mentioned in bug 56011 doesn't seem usable any more, there's no .bzr/checkout/pending-merges?
<ubot5> Launchpad bug 56011 in Bazaar "bzr status provides only truncated log messages" [Low,Confirmed] https://launchpad.net/bugs/56011
<fullermd> I thought the revid was just in the dirstate.  Maybe that's on older formats.
<fullermd> (dunno, really.  That's lower level than I deal with)
<w7z> seems likely, I thought it was all in dirstate these days
<w7z> log has to show something after you commit an octopus merge, so (naÃ¯vely) I don't think it could be that much harder to show much the same thing before the commit
<fullermd> Because log only starts from (or ends with, depending on how you think of it) one rev.
<fullermd> After the merge is committed, there is that one, but before on an octopus there isn't.
<w7z> there must be ways to lie :)
<fullermd> That would take very deep changes to how log works.  With a unique head, you just add a revspec to get the id.
<fullermd> (which doesn't really have anything to do with log at all)
<leo2007> is there something similar to 'git grep'?
<fullermd> leo2007: There's a grep plugin.  How closely similar it is to git's grep command I don't know.
<leo2007> thanks
#bzr 2013-09-24
<mwhudson> jelmer: did you rebase dulwich today?
<Yaniel> how well does bzr work with binary files?
<jpds> Yaniel: Quite well.
<jpds> Yaniel: http://wiki.bazaar.canonical.com/FAQ - 4.1.
<Yaniel> thanks
<jelmer> mwhudson: jup
<mwhudson> jelmer: i loved every one of those 950 mails
<jelmer> whoops :-)
<alex_id> Hi everyone, wiki.bazaar.canonical.com is throwing some errors, does anyone know who I should report it to?  e.g. I'm getting a Python stack trace on this page: http://wiki.bazaar.canonical.com/BzrEclipse/SettingUpADevEnvironment
<elmo> alex_id: I'll fix that, thanks; for future reference, you can ping the Canonical sysadmins in #canonical-sysadmin
<elmo> alex_id: (fixed)
<alex_id> elmo: thanks, looks good
#bzr 2013-09-25
<osfd> Hi there. How to do you downgrade to a former branch of your favorite software, please
<osfd> -r 'version'
<LeoNerd> $ bzr shelve --diff-options=-c2
<LeoNerd> bzr: ERROR: no such option: --diff-options   <== Feature Request? :)
<LeoNerd> I want to shelve with a smaller diff context size, because two of my changes are a bit too close to each other
<fullermd> Pretty sure it doesn't really use diff, so that would be tricksy.
<vila> LeoNerd: 'bzr shelve --help' talks about a  'change_editor' config option, pretty sure it allows splitting hunks on the fly (never used myself though)
<LeoNerd> Hrm....
<vila> LeoNerd: yeah, not ideal, hard to discover (without that option I think the shelve prompt does not mention the ability to edit) but it should address your immediate need ?
<LeoNerd> I'm not sure I follow - how do I use that?
<vila> you setup change_editor in bazaar.conf and then you should see an additional option in the shelve prompt
<vila> which should allow you to shelve the part you want to shelve and keep the rest ?
<vila> at least that's my understanding of the feature...
<LeoNerd> Ahhhyes.. I remember now
<LeoNerd> So how do I do vim with that?
<vila> LeoNerd: bzr config change_editor='emacs @new_path @old_path' ?
<vila> err, vim ;)
<LeoNerd> Ahyes...
<vila> LeoNerd: I have to leave but will read log, let me know if it worked for you
<LeoNerd> Yeah.. seems fine now, thanks
#bzr 2013-09-27
<thumper> jelmer: sorry, will promise to look soon, freeze time is coming up don't ya know :)
#bzr 2014-09-23
<nopf> hi. so what's the matter with symlinks on windows? i have a project with *1* symlink which i'm willing to delete right now and make a new version -- but won't that 1 create and 2 then remove that on 'pull' on the win machine and still fail in step 1?
<nopf> ok. bzr is wise enough to replay in one big step, so this works. thanks
<Elimin8er> Im trying to build a package.. when I use checkinstall everything works great. but I want to build it with the intent of putting it on my ppa.. anyhow when I use bzr builddeb -- -us -uc, I get error at the end, take a look here: http://paste.ubuntu.com/8408128/ .. I just dont get it.. Hopefully someone can give me a pointer or two..
<fullermd_> Well, that's nothing to do with builddeb, or bzr for that matter.  's just compiler warnings/errors.
<Elimin8er> fullermd_,  umm what can I do? anything ?
<Elimin8er> it works fine when I use chdeckinstall and make a nice deb file.. but I need it to package for my private ppa.
<fullermd_> Fix the b0rked C code   :)
<Elimin8er> I was thuinkjing it was the rules file..
<Elimin8er> broken code? its hexchat. compiles just fine.. its the dev 2.11.0 version..
<Elimin8er> just doesnt compile with bzr issued
<fullermd_> Then something in the build process is using different warn flags.
<Elimin8er> im still pretty new to this.. anyway to debug that and see whats being passed to display that?
<fullermd_> That way out of my baliwick.  Something in the chain of makefiles or invocations.
<Elimin8er> fullermd_,  thank you anyhow... and yes it seems to do the same thing in anything that I build that I know build with checkinstall or just reg. make..
<fullermd_> Yes, there's a lot of terribly b0rked an insecure C out there   :)
<Elimin8er> so your saying bzr is more picky then everything else?
<fullermd_> It's nothing at all to do with bzr.  bzr doesn't know anything about any compiling of anything.  It MAY be something embedded in builddeb.
<Elimin8er> fullermd_,  yea I figured that too. I understand bzr is just a main function calling.. im thinking its the mh_make making the rules thats causing the problem..
<Elimin8er> not sure though
<Elimin8er> seems to have problems with debian/rules area
<fullermd_> And what I know about debian build processes could be written in 72 point type on one side of a grain of rice...
<Elimin8er> debian seems much more easier.. this is for ubuntu that seems to be picky about alot of crap.
<Elimin8er> even though they both use deb packages
<Elimin8er> and are based of the same concept
<fullermd_> Obviously, the fix is to install a real *BSD   O:-}
<Elimin8er> call me stupid but what does BSD mean? yes ill still new to all this
<fullermd_> Oh, I'm just trolling a little.
<Elimin8er> I been working with computers since 1980 (commodore64) then PC later years.. but only messed with linux a short time.
<Elimin8er> I been a windows person for some many years..
<Elimin8er> fullermd_, I managed to get one test project to work. I compiled qbittorrent 3.2.0alpha with no problems.
<Elimin8er> using the bzr package way
<LeoNerd> Just occasionally, I wish it was possible to have multiple independent bzr workdirs/branches in the same physical directory, each maintaining separate sets of files
<CcxCZ> LeoNerd: hou
<CcxCZ> how do you suppose it should look on commandline?
<CcxCZ> also; howdy :-)
<LeoNerd> Hmmm, yeah it'd be quite awkward I'm sure :)
#bzr 2014-09-24
<thrustcore> I keep running out of memory when trying `bzr update' -- can I do a partial update?
<jelmer> thrustcore: yes, you can specify a revision to update
<jelmer> thrustcore: though that might not help
<thrustcore> jelmer: I tried bzr update -r100 and that failed, so I tried bzr update -r1 and that also ran out of memory :p
<thrustcore> can I run bzr as 64 bit?
<jelmer> thrustcore: yes
<thrustcore> jelmer: do I have to download the 64 bit binary separately or is it somewhere in the distribution?
<jelmer> thrustcore: bzr is a python application, so there is not really a binary as such
<jelmer> thrustcore: are you on Windows perhaps?
<thrustcore> yeah :(
<jelmer> I have no idea how things are there
<jelmer> sorry
<thrustcore> it's cool
<thrustcore> jelmer: any idea what I can do though, since I'm running out of memory? I need to get back on track... can't I update like half the tree or something
<thrustcore> or is there perhaps a switch that doesn't do everything in-memory?
<thrustcore> how do I find the location I need to "pull" from to mimic bzr update?
<CcxCZ> pull takes changesets from one repository to another. update merges changesets and a working tree
<CcxCZ> maybe revert would work for you?
<thrustcore> CcxCZ: why would revert work though, I'm trying to get to the latest revision
<CcxCZ> because it doesn't try to merge the changes in the working tree but rather overwrites them. but that's a wild guess on my side
<thrustcore> you know what.... I seem to be running out of memory a lot slower now
<thrustcore> I'm starting to think that there was one file >= 2GB that I was unable to merge
<thrustcore> oh man
<thrustcore> the file id "..." is not present in the tree
<CcxCZ> thrustcore: installed python with bzr or separately?
<thrustcore> CcxCZ: doesn't look like I have python in my path at least
<thrustcore> I think I may have installed it with ninite though
<CcxCZ> aww :-( https://bugs.launchpad.net/bzr/+bug/331342
<ubot5> Launchpad bug 331342 in Bazaar Windows Installers "bzr python-based installer requires 32-bit python on windows; unclear message" [Medium,Confirmed]
<thrustcore> CcxCZ: what does that mean?
<CcxCZ> you might be able to install 64bit version by hand though
<CcxCZ> thrustcore: you should be able to install 64bit python, then 64bit pywin32 along with other dependencies and then bzr http://wiki.bazaar.canonical.com/WindowsInstall
<CcxCZ> if you do it by hand you should have >2GiB capable version of bzr
<thrustcore> CcxCZ: I actually figured out what the issue is, the repository was renewed without me V_V
<thrustcore> so I'll just check it out again and wait like 40 hours :P
<thrustcore> why does bzr take such a long time to "repack text" all the time?
#bzr 2014-09-26
<queso> What could be some causes of this error?   "bzr: ERROR: Corruption while decompressing repository file, zlib: Error -3 while decompressing data: incorrect data check"
#bzr 2015-09-23
<bjmgeek> is there an easy way to force bzr to use a SOCKS proxy?
#bzr 2015-09-25
<bac> hi all, bzr seems to be missing from pypi this morning.  what's up?
<bac> jelmer: ^^ ?  (hello, btw!)
 * yashi_ still learning the concept of branches
<frankban> hi all, anyone know what's happening with "pip install bzr"? It errors with "Could not find any downloads that satisfy the requirement bzr" and  https://pypi.python.org/pypi/bzr/ is a 404 indeed
<vila> bac, frankban: I've heard confusing news from pypi, can you pinpoint when it started happening ?
<bac> vila: it worked last night around 2300UTC but i discovered it was missing about one hour ago.
<vila> bac: excellent, that confirms my suspicion that they broke bzr on pypi very recently
<bac> yes.  there was the email from pypi about externally hosted files that went out recently. in it they said no action would be taken for three months.  related?
<vila> bac: you bet
<vila> bac: I did upload a tarball one year ago and they seem to have completely removed the project
<bac> vila: do you know who the other pypi maintainers were?
<vila> bac: https://bugs.launchpad.net/bzr/+bug/1323805
<ubot5> Ubuntu bug 1323805 in Bazaar "bzr is not pip installable" [Critical,Fix released]
<vila> bac: lifeless and poolie but I think they are screwed as me since the project is nowhere to be seen anymore on pypi
<bac> vila: so do i read correctly in that bug that bzr 2.6.0 download file was hosted at pypi?
<vila> bac: you read perfectly right :-/
<vila> bac: so it seems they removed bzr because old versions weren't hosted on pypi despite the latest (and only relevant one) was
<bac> vila: so, the email i referenced really should have not been applicable to the project
<vila> bac: yes, I got the same email and I agree
<bac> vila: by "they" do you think pypi admins or a bzr maintainer?
<vila> bac: I replied this morning but no response yet
<bac> nothing should have happened for a while.  :(
<vila> bac: pypi, if it's a bzr maintainer..... I would be speechless ;)
<vila> bac: it's hard enough without saboters ;-D
<vila> bac: and what's your use case by the way ? (I'm ready for the worse)
<bac> vila: we have test suites that rely on bzr to be pip installed in a virtualenv.  those projects now fail our CI and are doa at the moment
<vila> bac: ok, if we're lucky CI is warning us soon enough...
<bac> abentley, mgz: can either of you shed any light or a way forward on the pypi issue?
<abentley> I got the same email, about another project.  I don't know what happened here.
<mgz_> bac: nope, I have been reading along, seems we need to poke pypi admins
 * barry waves
<vila> barry: waves as in: you're a pypi admin ?
<vila> barry: hi ;)
<vila> abentley, mgz_ : hi too ;)
<barry> vila: i'm not.  i also don't think i am an owner of bzr on pypi
<bac> barry: i don't think anyone is now. :)
<barry> vila: so i don't know what's going on, but two things come to mind
<vila> barry: I think I was :-/ Well, I was able to upload
<vila> barry: yeah, as bac said, I think nobody is anymore :-(
<barry> (as i'm sure you know) there was some discussion on the mlist about transfering ownership from mpool.  i never saw a follow up but maybe there was a snafu there
<barry> vila: do you know: were the tarballs hosted on pypi or externally (i.e. *only* on lp)?
<vila> barry: I think it happens at the same time but I'm pretty sure neither lifeless nor poolie checked pypi
<vila> barry: all were on lp *EXCEPT* 2.6.0 that was uploaded on pypi a year ago, see https://bugs.launchpad.net/bzr/+bug/1323805
<ubot5> Ubuntu bug 1323805 in Bazaar "bzr is not pip installable" [Critical,Fix released]
<barry> bzr 2.6.0 still comes up
<barry> in a search, but the link 404s
<vila> barry: yup
<vila> barry: may be you know a pypi admin that can be poked ?
<barry> so, the other thing that is happening recently is that pypi (and the whole stack) will stop chasing external links, so *only* tarballs hosted on pypi will be pip installable.  there are good reasons for this, but it should be something like 6mo away.  just yesterday there were some tests of the email that was going to get sent out.  i wonder if something got deployed too early
<vila> barry: that's my gut feeling (something on the pypi side)
<vila> bac: apart from the CI jobs (juju ?), what could be the impact from your pov ?
<dstufft> Hi
<barry> dstufft: hi!
<vila> dstufft: \o/
<barry> dstufft: i'm not a bzr admin on pypi
<barry> dstufft: only the 2.6.0 tarball was on pypi
<dstufft> I just registered bzr to my name on PyPI, it was deleted from PyPI by someone named "tanner" on PyPI at 2015-09-24 22:38:33
<dstufft> the whole project was deleted
<vila> O_o
<barry> dstufft: so this isn't related to the external tarball thing?
<vila> dstufft: can you revert that ?!?!
<dstufft> Do you know who tanner is?
<barry> i don't
<bac> vila: we have a lot of projects (i'm mostly concerned with juju-ish ones) that rely on bzr.  so they are all affected wrt CI and automated landings
<vila> dstufft: he is/was a bzr contributor, not sure why he had the power to delete the project
<dstufft> barry: No, we've not made any actual changes for external tarballs yet, just emailed people to tell them that in 3 months we're going to do a thing
<vila> bac: right, so the fire is coming, that's what I was afraid about
<dstufft> tanner might have been spurred on by the email I sent him though
<vila> dstufft: or clicked the wrong button and hiding under his couch right now
<barry> dstufft: cool.  it was suspicious timing, but it sounds like its unrelated
<dstufft> anyways, I can't really revert it. I can give it back to you and release all the filenames so you can reupload
<dstufft> I registere dit to my name so nobody else registered it and put up something malicious
<barry> dstufft: that sounds like a plan.  vila, bac i'm happy to co-own it if that helps
<bac> barry: +1
<vila> dstufft: good, I changed my password on pypi this morning in case something was wrong, 'vila', I'll deal with given back the project to the rightful owners
<vila> barry: thanks !
<dstufft> If you really need it, I can probably fish stuff out of a backup, but that's probably going to burn at least a day for me
<dstufft> Ok
<dstufft> I'll give vila admin on PyPI and let you take it from there
 * vila runs to check if the 2.6.0 pristine tarball is still there
<bac> vila: should be easier to re-upload than restore from backup, right?
<barry> sounds good, thanks for the quick response!
<bac> vila: i saw it on launchpad
<vila> bac: yes
<vila> dstufft: we've got a plan, thanks so much !
<bac> thanks everyone
<dstufft> I just removed myself from the bzr project, so it's all you now vila
<dstufft> It'll be just a minute for me to release the filenames
<bac> vila can you ping me when you think it is restored
<dstufft> (once a filename is uploaded to PyPI, you can't ever reupload the same filename without me releasing it)
<vila> bac: you bet I'll ping you to test ;)
<bac> excelelnt
<vila> dstufft: crystal clear and matches my expectations
 * vila finds the 2.6.0 tarball and starts breathing again
<vila> now to find the right setup.py command...
<dstufft> you want twine
<dstufft> setup.py doesn't let you upload an already created tarball
<dstufft> (also setup.py is bad)
<dstufft> anyways, filenames released ^
<dstufft> gonna drop out of channel, if y'all need anything else feel free to PM me or pop into #python-infra or #pypa(-dev)
<vila> dstufft: ack, thanks, uploading from the web page as I don't want to re-generate/sign a new tarball
<vila> Invalid version, cannot be parsed as a valid PEP 440 version. :-(
<vila> barry: ^
<barry> vila: i'll jump over to #python-infra
<vila> barry: I'm in #pypa talking with dstufft
<barry> vila: i'm there now too
<vila> icu
<vila> bac: ping me once your CI jobs get greener just to make sure
<bac> vila: one just passed CI.  i think we're good
#bzr 2017-09-29
<quicksilver> if you add the 'same' file in two different branches
<quicksilver> how do you force them to have the same file id
<quicksilver> so they'll be considered the same?
<erry> Hi, if you add the--
<erry> :|
<erry> :D
<fullermd> You could look at add's --file-ids-from
<quicksilver> yeah I think was the trick last time but I couldn't remmebr - or google - how to use it
